50g Random Turn ON

[Joe Horn]

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?]

[Han]

(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?]

You (and many others here on this board) always amaze me with your wealth of HP knowledge.

[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.

[TravisE]

I've read that passage in Insights as well, but as DavidM points out, I was under the impression that this brief processor wake-up would be pretty much invisible to the user. I may be wrong, but I figure the display wouldn't even get turned on, and I wouldn't expect STARTOFF to be executed. If this were the case, then my HP 50g's with a STARTOFF routine that calls a backup program would have it executed at least every 3-ish days when not in use. But instead, the frequency of the apparent “phantom” STARTOFF calls I saw on one of my units is much more irregular.

[Gerald H]

Right, I've now installed a STARTOFF programme returning a string to the stack in my 2nd 50g & will let it sit a week to see what happens.

Will report back in a week.

[Joe Horn]

(12-06-2016 09:23 PM)DavidM Wrote:  

(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". ...

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.

But STARTOFF *is* executed every 262144 seconds (if no other interrupts occur in the meantime). The power-up that Wickes is talking about DOES engage the System Outer Loop, and it does turn on the display. If there is no STARTOFF program, and you happen to be looking at your 50g when the 262144 seconds have elapsed, you'll actually see the display blink on VERY briefly, and then turn off again. If STARTOFF exists, it'll be executed. None of this applies if ANY other interrupt occurs before the 262144 seconds have elapsed, in which case that timer gets reset to 262144 seconds again.

(12-06-2016 09:23 PM)DavidM Wrote:  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

Never heard of that last one. Interesting. Every keystroke also causes an interrupt which resets the timer. The blinking cursor is also controlled by a timer, but that has its own separate timer. In any case, when no other "next event" is scheduled, the "next event" is automatically set to 262144 seconds and the calculator turns off. That's what the second-to-last entry in your list above refers to. As Wickes said, this is necessary to keep the system date & time correct.

(12-06-2016 09:23 PM)DavidM Wrote:  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.

It's not a problem. It's a feature. And it's totally predictable: exactly every 262144 seconds, if no other interrupts have occurred.

(12-07-2016 12:08 AM)TravisE Wrote:  I've read that passage in Insights as well, but as DavidM points out, I was under the impression that this brief processor wake-up would be pretty much
invisible to the user.

It's visible if you're looking at it as it happens. The display blinks on and back off all in a fraction of a second. As Ferris Bueller said, "Life moves pretty fast. If you don't stop and look around once in a while, you could miss it."

(12-07-2016 12:08 AM)TravisE Wrote:  I may be wrong, but I figure the display wouldn't even get turned on, and I wouldn't expect STARTOFF to be executed.

Yes, you are wrong. The display DOES turn on, albeit very briefly (unless other factors prolong it), and STARTOFF does in fact get executed.

(12-07-2016 12:08 AM)TravisE Wrote:  If this were the case, then my HP 50g's with a STARTOFF routine that calls a backup program would have it executed at least every 3-ish days when not in use. But instead, the frequency of the apparent “phantom” STARTOFF calls I saw on one of my units is much more irregular.

If your STARTOFF is executed "much more irregular" than every 262144 seconds, then (a) something else is causing interrupts to occur, or (b) there is something in your STARTOFF program that is causing it to exit before the backup is performed, or (c) you have discovered an interesting new bug that involves executing a backup during the execution of STARTOFF. I hope it's c. Would you mind sharing your STARTOFF's listing with us?

[TravisE]

I could do that, but I call some fairly involved utilities that do things like attempt to adjust for clock drift (kind of like the built-in features of some of the previous popular HP devices), and it and the backup program are in a library now along with several other personal utilities, so I'd have to dig up my source code.

I think an easier way for all of us would be if I first just try a very simple STARTOFF that does nothing more than append a timestamp to a list. I think I'll do that. If I don't see a STARTOFF at the expected interval with the calculator completely untouched, I'll try temporarily uninstalling all the libraries and see if the behavior changes.

[DavidM]

I decided that it was a reasonable time to check the 49g+ and 50g I had set aside and left alone for the last 5-6 days to see what their status was. Both calculators had logged a single power-up event occurring, and both events were at times which seemed to coincide with what would be expected for TIMER2 expiring (262144 seconds). I can't be 100% sure, as I didn't note the exact time I turned them off when I started this test. I'll make sure to do that for future ones, or more likely, I'll have the calculators log it appropriately on their own.

(12-07-2016 06:42 AM)Joe Horn Wrote:  But STARTOFF *is* executed every 262144 seconds (if no other interrupts occur in the meantime). The power-up that Wickes is talking about DOES engage the System Outer Loop, and it does turn on the display.

As is usually the case with you, Joe, I'll take you at your word on this one. My own limited testing certainly agrees with what you're saying. This does imply several possibilities, though, given that others are experiencing less-than-predictable results. Some that come to mind:
- Some other interrupt/alarm is occurring on their systems that preempts (and resets) the 262144 second timer reset, and if so, is also not activating or bypassing STARTOFF when it occurs.
- People are using the calculator more often than they think, thereby circumventing the 3 day event.
- Some other software-related issue is occurring in their STARTOFF programs (or elsewhere) that makes it seem like the programs aren't running consistently (ie. beep not activated, etc.).
- An inherent issue in the platform is making the TIMER2 interrupt processing inconsistent.

My own personal experience makes me lean more toward the last item, in that I've already had verified issues with alarms not running consistently. Since the triggering of alarms is very similar to the "timer reset", it makes sense to me that it is a good possibility.

(12-07-2016 06:42 AM)Joe Horn Wrote:  

(12-06-2016 09:23 PM)DavidM Wrote:  - One hour after the last keypress was popped from the key buffer

Never heard of that last one.

That one came from multiple posts on comp.sys.hp48 that I believe were all initially sourced from comments by Dan Kirkland. This one is fairly specific on the topic, but there are other references as well.

(12-07-2016 06:42 AM)Joe Horn Wrote:  It's not a problem. It's a feature. And it's totally predictable: exactly every 262144 seconds, if no other interrupts have occurred.

I feel there's enough anecdotal evidence to question if it is as predictable as it should be, so we will have to agree to disagree on this one.

(12-07-2016 06:42 AM)Joe Horn Wrote:  If your STARTOFF is executed "much more irregular" than every 262144 seconds, then (a) something else is causing interrupts to occur, or (b) there is something in your STARTOFF program that is causing it to exit before the backup is performed, or (c) you have discovered an interesting new bug that involves executing a backup during the execution of STARTOFF.

Or perhaps it's (d): the TIMER2 interrupt doesn't always happen when it should. Sometimes perfect, sometimes late, sometimes not at all, or at least not until some user activity occurs.

In the pre-ARM RPL systems, the system clock was defined as "SysTime = Next_Event - TIMER2", which is why that 3-day NextEvent/TIMER2 reset was needed in the first place. Post-ARM, though, an ARM-specific op-code is used instead: GETTIME (80B11). While I haven't traced through the TIMER2 service routine (and doubt I'd understand it even if I did), I am assuming that it is also different on the ARM systems as a result. Clearly there is still a 2^31 tick timer event, but how those events actually trigger in the ARM environment has to be different -- there's no longer a hardware-driven way to get exactly 8192 decrements to TIMER2 per second. I've never seen any detailed information about the inner workings of timekeeping on the ARM systems, but I know that there are a number of quirks (sub-second adjustments, jittery system time, and alarm problems all come to mind here). It just doesn't seem that far-fetched to think that those differences could result in some of the problems people are experiencing with TIMER2 and STARTOFF consistency.

[Joe Horn]

(12-07-2016 09:00 PM)DavidM Wrote:  ... This does imply several possibilities, though, given that others are experiencing less-than-predictable results. Some that come to mind:
- ...
- An inherent issue in the platform is making the TIMER2 interrupt processing inconsistent.

My own personal experience makes me lean more toward the last item, in that I've already had verified issues with alarms not running consistently. Since the triggering of alarms is very similar to the "timer reset", it makes sense to me that it is a good possibility.

Aha! Now I understand what you mean. Thanks for being patient and explaining it in a way that broke through my mental block. Since the 50g does have at least two known timer bugs (user alarms sometimes fail to come due for no known reason, and keystroke interrupts fail to get handled correctly when they occur at the exact moment that the busy annunciator turns off), yes, I agree with you that it is reasonable to hypothesize that the 3-day auto-turn-on sometimes might similarly fail to occur. HOWEVER, if that ever did happen, then the system real-time clock would at that moment fail to be updated. Wouldn't this cause the system clock to thereafter be off by 262144 seconds? I've seen 50g clocks drift away from the correct time, of course, but never anywhere near that much. So unless my understanding of the system real-time clock update is incorrect, then I reject the above hypothesis, and stubbornly maintain that the 50g (like the 48 & 49) NEVER misses a 262144-second auto-turn-on unless some other system interrupt occurs. Proof that I'm wrong would delight me of course, since I enjoy playing with HP calculator bugs as much as playing with HP calculator features.

I like your test method of storing something in a list instead of leaving something on the stack, so I'll try the same. I'll set up STARTOFF in some spare 50g's and 49g+'s to append TICKS to a stored list, and see what they contain after a few weeks. And see if their date/time is still close to accurate.

[Gerald H]

Is there any reason, Joe, not to rely on alerts being left in the stack?

[DavidM]

(12-08-2016 05:47 AM)Joe Horn Wrote:  ...HOWEVER, if that ever did happen, then the system real-time clock would at that moment fail to be updated. Wouldn't this cause the system clock to thereafter be off by 262144 seconds? I've seen 50g clocks drift away from the correct time, of course, but never anywhere near that much. So unless my understanding of the system real-time clock update is incorrect, then I reject the above hypothesis, and stubbornly maintain that the 50g (like the 48 & 49) NEVER misses a 262144-second auto-turn-on unless some other system interrupt occurs. Proof that I'm wrong would delight me of course, since I enjoy playing with HP calculator bugs as much as playing with HP calculator features.

I hereby reject your rejection. It appears we are both stubborn. I'd much rather delight you than frustrate you, though.

If we were talking about the pre-ARM systems, I would totally agree with you. But we're not. I will offer one possible reason that the clock wouldn't have a problem -- actually, I already have. But before I do that, consider the following:

You already know that alarms don't always trigger properly on these systems. Your observation about the clock not being updated properly should apply to that scenario, too, shouldn't it? If you are rejecting the concept of a 262144-second TIMER2 expiration problem based on the fact that the clock still runs, then it seems to me that you should also reject the concept of alarm problems on the same basis. I've had alarm issues that clearly had no impact on the system clock, and I'm guessing you have as well. I actually saw a 1+ minute delay in an alarm recently when testing my logging facility for this thread's issue -- with no corresponding lag in the system clock. So whatever is causing that problem hasn't caused the system clock to stop updating.

While I disagree that the TIMER2 interrupt not triggering would absolutely stop the clock on an ARM-based calc (see below), I also don't think that's the only possible explanation for these problems. It's perfectly reasonable to consider that the interrupt is still triggering, but something in the service routine could be failing in such a way that "things" are left in a corrupted state. Those "things" may not generate a hard crash, but clearly enough is wrong that, at a minimum, alarms don't always execute properly. I see that same concept as a possibility for anything that depends on the TIMER2 interrupt servicing. I'm also open to the possibility that I'm totally wrong in assuming a link between the TIMER2 interrupt processing and alarm issues. But I've yet to see a reason not to.

One possible reason that these issues aren't causing the system clock to skip a few beats (or have cardiac arrest) is what I mentioned in the last paragraph of my previous post. In the post-ARM world, the system time is no longer computed as TheNextEvent - TIMER2. It is simply retrieved from the Saturnator with a single opcode (GETTIME). Don't take my word for it -- you can see it yourself by looking at the code for TICKS, (SysRPL) CLKTICKS/SysTime, and (ASM) GetTime++/GetTimChk. So the ARM-based systems are now dependent on the Saturnator for getting the system time, which I suspect maintains the current time independent of anything that happens in the Saturn environment (excluding direct adjustment, of course).

I could also be totally wrong about all of this. I'm open to that possibility. But please don't dismiss the whole concept based simply on the clock still keeping time.

[DavidM]

(12-08-2016 07:41 AM)Gerald H Wrote:  Is there any reason, Joe, not to rely on alerts being left in the stack?

I realize you asked Joe this question, but I'd also offer one reason I chose not to do that:

In my original thinking about these issues, I was wondering if a warm-start might be happening somewhere in the process (especially since I know that to be a specific result of the OS identifying a problem with the system clock). Warm-starts clear the stack, so anything left there would be wiped out if one occurs.

Although I'm now less inclined to think a warm-start is happening in this scenario, I'm still thinking that a log object stored as a global variable is safer.

[Joe Horn]

(12-08-2016 07:41 AM)Gerald H Wrote:  Is there any reason, Joe, not to rely on alerts being left in the stack?

Not really. My distrust of the stack is more phobic than rational. Over the years we've all seen how reckless some programmers are with "shared resources" like the stack, flags, and so on. I'm always afraid that some library routine will activate during a power-down or power-up and clear my stack. So I prefer to safely tuck things into variables than to risk their lives by leaving them floating on the stack. Just a personal preference.

EDIT: David makes a good point about warmstarts too. They always clear the stack.

[Joe Horn]

(12-08-2016 04:49 PM)DavidM Wrote:  I hereby reject your rejection. ...

All the points you make are good ones, and I must confess that I do not understand the TICKS function in the 50g. For example, sometimes TICKS goes BACKWARDS in the 50g, which of course is something that it should never do. To see this, perform 8 TICKS in immediate succession, put them in a list, and perform a DeltaLIST. << TICKS TICKS TICKS TICKS TICKS TICKS TICKS TICKS 8 ->LIST DeltaLIST >>. Most of the time you'll get small differences around #40h ticks, as expected. But once in a while you'll get a HUGE difference because TICKS jumped BACKWARDS for a moment. It's rare enough that the only way you'll see it happen is to write a loop and test for it. Very strange. Is this bug related to the unreliable alarm bug and the (alleged) irregular auto-turn-on issue? I have no idea.

[Gerald H]

Thanks, Joe & David, for responses.

I shan't alter my STARTOFF, which only returns to the stack, so trial will finish as scheduled a week after posting #25.

[DavidM]

(12-08-2016 05:32 PM)Joe Horn Wrote:  For example, sometimes TICKS goes BACKWARDS in the 50g, which of course is something that it should never do.

It is fair to say that the system clock moving backward is what started me down the path of thinking about these clock issues in the first place. I ran into that issue several years ago when working on MultiStopwatch, and was quite surprised how often it actually occurs. Whereas RPL code (user or sys) runs slow enough to only see it occasionally, it actually happens more often than many realize.

A simple Saturn ASM test on my older 50g shows "backward steps" happening about 100 times/sec with an average of about 35 ticks per event. My 49g+ sees about 75 of them averaging 26 ticks, and my newer 50g sees about 50 of them averaging 18 ticks (all per second). My guess is that these differences can be explained by slightly varying raw CPU speeds in the individual units.

More difficult to determine would be how often the clock jumps forward, if at all. But these fluctuations are one of the reasons I suspect that the Saturnator is constantly tweaking the system clock. I have long wondered if system clock jitter is behind some of these issues.

[TravisE]

I've noticed the strange TICKS behavior myself, and I sort of wonder if there's some “tick synthesis” going on that tries to simulate the 8192-tick-per-second rate even though the hardware doesn't directly provide it. (I've read of a similar concept used to generate the clock signal for modern CPUs from a master quartz crystal running at a much lower frequency than the CPU's actual rate). This could be the source of jitter, and maybe there are some bugs/quirks that cause occasional very large jumps that seemingly shouldn't be occurring. I figure that a small, constant jitter would be expected for such a setup, but it doesn't seem to make much sense for the clock to ever occasionally jump several whole seconds at a time in either direction.

I don't remember for sure, but it seems like I recall that the jitter appears worse if the CPU is set to run at rate other than the default 75 MHz or whatever it is. Another observation I've made before is that CLKADJ, when given a non-multiple-of-8192 increment, initially appears to work for a fraction of a second, but then something apparently “resets” the clock so that the effective adjustment resolution is only a multiple of 8192.

This is just a guess, but I wonder if the system somewhere maintains an internal, high-precision concept of what time it thinks it is, which gets periodically “refreshed” from a hardware clock (which might have a much lower timing resolution). Maybe the two tend to get out of sync at times for some reason until the system eventually updates one clock's time from the other, causing apparent jumps.

[3298]

(12-08-2016 11:04 PM)TravisE Wrote:  This is just a guess, but I wonder if the system somewhere maintains an internal, high-precision concept of what time it thinks it is, which gets periodically “refreshed” from a hardware clock (which might have a much lower timing resolution). Maybe the two tend to get out of sync at times for some reason until the system eventually updates one clock's time from the other, causing apparent jumps.

The Samsung S3C2410 (i.e. the 50g's brain) has an RTC, which might be what the Saturnator uses to keep track of time. After reading the relevant datasheet section I'm pretty sure (unless I misread it) that the most precise way of reading its value is the tick time interrupt (as the datasheet calls it), with a configurable period between 1/64 s and 1/2 s in steps of 1/128 s. Other than that, fractions of a second are not exposed to the software at all; the RTC register with the smallest unit is the one for seconds, which explains this CLKADJ weirdness:

(12-08-2016 11:04 PM)TravisE Wrote:  Another observation I've made before is that CLKADJ, when given a non-multiple-of-8192 increment, initially appears to work for a fraction of a second, but then something apparently “resets” the clock so that the effective adjustment resolution is only a multiple of 8192.

To me it seems like (though I'm just guessing here) the Saturnator tries to keep the 8192Hz counter up-to-date via software and constantly corrects it using the tick time interrupt. That would explain the "time travel" happening several times per second - the counter is corrected backwards. When the timer is written from within the Saturn world, the ARM system can only adjust the RTC by whole seconds, so it rounds the CLKADJ value to whole seconds (down? up? to nearest?), which causes the fraction-of-a-second part of the clock adjustment to get reverted on the next tick time interrupt.

So what does that mean for TIMER2? I don't know, my knowledge of the Saturn's interrupts is insufficient. But if it somehow depends on the 8192Hz counter working correctly (which I think it does, considering the talk here about a 31-bit counter and a 18-bit number of seconds), it might be broken. The 50G's displayed clock may still be unaffected even if one of the 3-day wakeups is missed if it's simply backed by the RTC which stays (somewhat) accurate.
My hypothesis for these random power-ups is that they are in fact caused by the 3-day wakeup, and if they are rarer than that, the calculator missed one due to clock jitter.

Perhaps someone should test for random power-ups on one of the pre-ARM calculators. Even better, test it together with an ARM-based one - turn both off at the same time and leave 'em for a week. The pre-ARM calculator should list two power-ups (3 and 6 days after turning off), and the ARM-based one should have up to two power-ups; if it has any, they should have occurred around the same times as the ones on the pre-ARM calculator.
Unfortunately I can't perform that test because my only pre-ARM HP calculator is a 48G that fell into water about 15 years ago. It didn't do much since, apart from convincing me to get my other HP calculator, a 50G.

[DavidM]

Just thought I'd share another data point in this ongoing test.

Last Thursday (2016-12-08) I re-synced the clocks on my two test subjects and turned them both off simultaneously at a time I logged. I determined when that time + 262144 seconds would be, and made it a point to observe them both at the appointed time to see if I could witness the "auto wakeup" referred to in other posts in this thread.

That event was scheduled to occur last night, and I watched them for a period of about 10 minutes (starting at 5 minutes before the event time) hoping to witness it. To make sure I didn't blink at the wrong time, I also recorded this time period with my phone (set to capture at 29.97 frames/sec).

I never saw any indication of a power-up on either unit, but didn't want to manually power them up yet thinking that perhaps there was simply yet another one of those random delays occurring. Setting them aside, I scanned through the video looking for any indication that I simply missed the event. Nothing was there.

Today at a time about 11 hours after the targeted event (about 84.24 hours after the last manual power-down), I turned the calculators on and checked the logs. No power-up or -down events had been logged since the powerdown last Thursday. So unlike my previous test, both units seemed to stay powered down well past the 262144-second window. FWIW, the system clocks for both calcs were within 1-3 seconds of actual time, so no unusual drift had occurred.

The logging worked without problems on the previous test, and there's no reason I can think of that it would have been different this time around. All other power events I know of were logged properly (including today's). So it appears that these two systems didn't power up at all over an 84.24 hour window.

I'm planning to continue this testing for a while to see what happens. The sample size of test results is still far too small to be indicative of anything in particular (other than confirming the inconsistencies). I'll be interested in seeing other's experiences as well.

[Gerald H]

Turned on the 50g turned off in post #25.

NOTHING on the stack.

LASTARG recalled the timestring

"SUN 11.12.16 09:32:31"

I shall repeat the experiment storing the timestrings (I expect more than one a week) in a variable.

How do I access the warm start log?