50g Random Turn ON

[DavidM]

(12-06-2016 07:43 PM)Joe Horn Wrote:  This whole issue of the 50g turning itself on periodically was covered by Bill Wickes on page 622 of his book "HP 48 Insights, Part II". Pertinent excerpt from there:

Bill Wickes Wrote:The current time is encoded in HP 48 memory by means of a 52-bit RAM register and a 32-bit electronic counter. ... With 32 bits for the counter, the longest that the HP 48 can go without a time event is 2^31 ticks, slightly more than 3 days. That occurs when the HP 48 is turned off, and no alarms are scheduled within that time -- then the calculator wakes itself up just long enough to reschedule the next event time. Usually, all of this processing happens so fast that it is not noticeable.

Bottom line: Every HP 48/49/50 which is not awakened by something else will wake itself up every 3 days, 49 minutes, and 4 seconds, and then turn itself right back off. [Maybe the HP 28 too?]

Yes, that's the same thing I was referring to in a previous post about the timer (TIMER2, specifically) that expires and creates a "timer reset" interrupt when it happens.

However...

I don't believe that's the power-up that is being referred to by others in this thread. Why? Because that particular power-up happens as an interrupt that performs its functions and shuts down without engaging the normal System Outer Loop. As such, it shouldn't normally set up a situation where the system is left powered on -- which would presumably be required in order to trigger the "auto power-off" that is happening for folks that have a STARTOFF program defined when these random power-ups occur.

The 52-bit RAM register referred to by Wickes above is actually the date/time (in TICKS format) of the so-called "Next Event". I've seen references to that Next Event being any of several different things, including (but not necessarily limited to):

- The next second transition if powered on and the clock is displayed
- The next auto-poweroff if currently powered-on
- The next time an alarm is due
- The next time an "auto wake-up to reset TIMER2" occurs (if powered off)
- One hour after the last keypress was popped from the key buffer

Whichever of the above would happen soonest is the one that becomes the Next Event and is stored in the 52-bit RAM register. There may be other types of Next Events as well, I've just not seen specific references to them. I do seem to recall reading somewhere that battery conditions can affect the timing of the Next Event as well.

Knowing already that the handling of alarms on the ARM-based systems is problematic, I'm wondering if that "wake up and reset timer" Next Event is also getting tripped up somehow on those systems and thus leaving the calculator turned on. Or perhaps there's some other kind of Next Event that is triggering on these systems that has the same result. Although I'm fairly certain we'll never see a fix, perhaps we can eventually find a way to work around it (or at least predict it better) if we find out more about the source of the problem.