29 replies to this topic

[reg]

Hi guys,

 

The current time shown on my Vu+Duo2 is off by ten minutes. I am not sure why / when this started happening. Rebooting the box doesn't help.

 

I tried to change it manually:

root@vu:~# date
Fri Dec 30 13:38:09 CET 2016
root@vu:~# date -s '2016-12-30 13:28:10'
Fri Dec 30 13:28:10 CET 2016

But no luck:

root@vu:~# date
Fri Dec 30 13:38:11 CET 2016

Any ideas what's causing this? Is there any other way I can change the current time?

 

Thanks,

[Erik Slagter]

Change the "startup" service to a service that gives the correct time (transponder).

[reg]

Hi Erik,

 

Thanks for the suggestion. I have now tried on several services, from different satellites and even from terrestrial, but I'm still running into the same issue.

 

Also the time provided by the TDT on my startup service looks alright:

root@vu:~# date
Fri Dec 30 17:21:34 CET 2016

root@vu:~# dvbsnoop -frontend /dev/dvb/adapter0/frontend0 -dvr /dev/dvb/adapter0/dvr0 -demux /dev/dvb/adapter0/demux0 -n 3 -nph 0x14
dvbsnoop V1.4.51 -- https://github.com/persianpros/dvbsnoop 

------------------------------------------------------------
SECT-Packet: 00000001   PID: 20 (0x0014), Length: 8 (0x0008)
Time received: Fri 2016-12-30  17:21:24.913
------------------------------------------------------------
PID:  20 (0x0014)  [= assigned for: DVB Time and Date Table (TDT), Time Offset Table (TOT)]

Guess table from table id...
TDT-decoding....
Table_ID: 112 (0x70)  [= Time Date Table (TDT)]
section_syntax_indicator: 0 (0x00)
reserved_1: 1 (0x01)
reserved_2: 3 (0x03)
Section_length: 5 (0x0005)
UTC_time: 0xe198161129 [= 2016-12-30 16:11:29 (UTC)]
==========================================================

[Erik Slagter]

Change the startup service and then reboot, from the user interface.

[Pr2]

Reflash your box.

[DeBeek]

Set to correct service, Shutdown your receiver,  switch off powerswitch on back, press and hold power button on front voor 5 sec,

release power button and switch on with power switch on back..

[reg]

Change the startup service and then reboot, from the user interface.

 

Yes, this is what I did.

[reg]

Set to correct service, Shutdown your receiver,  switch off powerswitch on back, press and hold power button on front voor 5 sec,

release power button and switch on with power switch on back..

 

It worked! Perfect! Thank you!

 

Just curious: what did this procedure actually do and how did you know?

[DeBeek]

on my Dreambox 8000 it works the same way, when you do a reboot, standby power stays on, so the clock continues to run.

 

With a complete power down clock goes to zero en has to read the new transponder time when booting up..

Edited by DeBeek, 1 January 2017 - 13:54.

[Tech]

If you powerdown the receiver, a little bit power remains in the powersupply, by pressing the powerbutton after pulling the plug, the last bit of power wich is left in capacitors, will be used and will stop the internal clock in the frontpanel.

[reg]

Thanks guys, good to know!

[Martin_B]

If I'd do so, a programmed timer wouldn't work afterwards?

Edited by Martin_B, 1 January 2017 - 19:21.

[WanWizard]

What do you mean with a "programmed timer"?

 

No STB has a real time clock, so if you put the box in deep standby, there is no running clock. The box does have a wakeup timer (as in "x seconds from now"), which is set before shutdown when there are recordings defined, to make sure the box wakes up just before a recording will start.

[Rob van der Does]

No STB has a real time clock, so if you put the box in deep standby, there is no running clock.

Yes, all VU's do have one. But in most images it's not being used as such.
But if it is being used, the STB has the correct time already when coming out of deep.
Needless to say that when there has been a powercut the clock has lost it's time.

To actually use the RTC the image needs to do something like

#!/bin/sh

if [ -f /proc/stb/fp/rtc ] ; then
    LIMIT_TIME=1388534400 #01.01.2014
    RTC_TIME=$( cat /proc/stb/fp/rtc )
    SYSTEM_TIME=$(date +%s)
    if [ "$RTC_TIME" -gt "$LIMIT_TIME" ]; then
        if [ "$SYSTEM_TIME" -lt "$LIMIT_TIME" ]; then
            date -s @$RTC_TIME
            echo "set rtc time ..."
        fi
    fi
fi

This doesn't change the fact that the wake-up timer is just a ticker.

Edited by Rob van der Does, 2 January 2017 - 06:02.

[Erik Slagter]

Are you sure the RTC on VU+ is not just an emulation, i.e. store the RTC of the kernel in NVR before deep standby and after wake, load it with the value offset by the ticker?

[Rob van der Does]

Yes, I am; it clearly shows to be working when you use it in:
1- the RS232 boot-log, and
2- the correct time being set after waking from deep even if no satellite or internet connection is available.

[Erik Slagter]

The same result could still be achieved using the "emulation" technique I explained. The only way to know is to cut the power for a prolonged time. Even then the RTC emulator could be battery backed up. But OTOH in that case it would start to resemble a real RTC very closely, anyway.

[Rob van der Does]

No: as I said before: on a powercut the clock looses time.

And on the subsequent restart you see in the RS232 log the 1970 date again, and the GUI has no time either (when no satellite & internet is available to the box).

I know for sure that no Xtrend supports this RTC, but maybe some others do.

[Martin_B]

Thanks for the explanation!

I was just curious how it works.

[Erik Slagter]

So, none of them (either VU+ or other manufacturers) feature a RTC.