[MB Premium Twin HD] Box failed to wake up from Deep Standby for a recording

[judge]

Well - "ticker" maybe?

In all fairness to Rob, as a non native English speaker, he does a much better job in typing readable English than many of our native English speaker support requests.
http://www.world-of-satellite.com/showthread.php?41560-tm-nano-t3&p=321473&viewfull=1#post321473
Fair play to Abu for making sense of that one...

 

[Rob van der Does]

Well - "ticker" maybe?

Hehe, yeah, that's the word

I rely too much on my spelling checker, which did allow me to write 'thicker'

 

[Joe_90]

It's just a fun poke We were all getting a bit "thick" about the wakeup timer in the thread. Rob knows that I have huge respect for his command of English and its idioms.

 

[Joe_90]

Well, this may have helped to explain why command-line shutdown doesn't work, as well.

/proc/stb/fp/wakeup_time is the next wake-up time. and this seems to be left at 0 when the box is running.

There is a Python function - setFPWakeuptime (from Tools.StbHardware) - to write the (Epoch) time of the next wakeup to this. So presumably(?) something uses this to set the next time to wakeup as part of the shut-down process.

[Perhaps there's some reason not to have this always populated with the next event time - such as odd things happening if the front-panel tried to start the system when it's already running?]

So, if I really want a command line shutdown then I just need to grab the setting code which is in mytest.py in the OpenVIX enigma2 git repository and run that before shutdown (or even add it is a generic shutdown script if the current wakeup_time is 0).

Did you get any further with this? Any googling I did on front panel controllers indicated that there was an RTC running plus wake-up timer once there was a 3V supply to the chip. Presumably the interface to linux C (or Python) is dependent on the drivers supplied, but I really can't figure out why the clock doesn't seem to be available after boot from deep standby. Needs a view from linux or driver devs methinks

 

[birdman]

Did you get any further with this?

No. Once I'd found out the cause I could just stop using shutdown so I concentrated on getting my Bouquets set up with standard Freeview HD channel numbers instead.

 

[Rob van der Does]

None of the actual E2-running STB's has a RTC in the frontpanel, only a 'ticker' (xxx ticks untill wake up time).
That's the reason E2 needs to get the time (from the transponder or from internet) at start up.
Just start the box with no coax and no LAN connected: system start time will be 1-1-1970.

 

[Joe_90]

None of the actual E2-running STB's has a RTC in the frontpanel, only a 'ticker' (xxx ticks untill wake up time).
That's the reason E2 needs to get the time (from the transponder or from internet) at start up.
Just start the box with no coax and no LAN connected: system start time will be 1-1-1970.

Hey Rob - this was all discussed earlier in the thread - I know it's difficult to keep up with everything at our age . I even quoted you on the "ticker" in post #30 and #34. I just have an issue understanding why there is no RTC available. Most of the chip controller information (from the chip manufacturers) I could find on the web would indicate that there IS an RTC and alarm present on these chips. You can read the time by issuing cat proc/stb/fp/rtc on a running system. In the power down sequence the RTC is loaded in the fp and so is the wakeup time (StbHardware.py). The fp must have a clock running so that it triggers a boot from deep standby at the wakeup time. I just thought it maybe is an issue with the linux kernel on these systems that maybe can't access the fp clock at boot? The normal linux method to get the hwclock is through /dev/rtc but maybe there are no drivers provided to allow access to the clock on boot up? Do you have any links to where developers have discussed this issue?

 

[birdman]

You can read the time in /cat/stb/fp/rtc on a running system.

That's actually /proc/stb/fp/rtc

The fp must have a clock running so that it triggers a boot from deep standby at the wakeup time.

but that just needs a countdown timer, not a real-time clock (although I agree that these do sound very similar - they are both just counters that increment/decrement at the same rate).

 

[Joe_90]

That's actually /proc/stb/fp/rtc
but that just needs a countdown timer, not a real-time clock (although I agree that these do sound very similar - they are both just counters that increment/decrement at the same rate).

Sorry about the typo - cut and paste error!
As regards the countdown timer, I think I argued for that earlier in the thread also. It's just that lots of cheapo FP controllers seem to have a proper clock available. I even ended up on an arduino forum where I could see that the clock function on it would continue to run in the absence of power due to the fact that there was a supercapacitor on board which could supply power for up to three days. It looked like a normal electrolytic capacitor.

I think your initial posts in this thread triggered thoughts with me with regard to similar queries I had raised some time back as to why there was no time stamping of log entries and why the clock/date settings were lost on reboot. I suspect the answers are probably deep in the origins of enigma code. I may have to take my Quad Plus apart to check the actual FP controller chip model and see if I can find the spec. I just find it difficult to believe in this day and age that the functionality for continuously running clock is not there. Rant over...

 

[birdman]

I may have to take my Quad Plus apart to check the actual FP controller chip model and see if I can find the spec.

If it's of any help, mine reports this at boot-time:

input: dreambox front panel as /devices/virtual/input/input0

and there is an id directory there with these 4 files in:

root@mbtwin:/sys/devices/virtual/input/input0/id# for f in *; do printf "%7s: " 
$f; cat $f; done
bustype: 0019
product: beee
 vendor: deaa
version: 0001

Perhaps you can work out the FP type from those 4 items?

 

[Rob van der Does]

I suspect the answers are probably deep in the origins of enigma code.

I don't think so; keeping time (from an RTC) would be a Linux thing, not E2.

Reading a bootlog you can see things like:
RTC not ready... wait for transponder time

So E2 seems ready for RTC, but it simply isn't there.

 

[Joe_90]

Yes I suspect that the front panel drivers may not "expose" any method for linux to get the time from a HWCLOCK (normally /dev/rtc) and @birdman has already shown that the RTC clock access after boot to /proc/stb/fp/rtc seems to return a low value as if the clock has been set to zero initially. I don't know why this is the case but was interested in finding out.