50g Random Turn ON

[DavidM]

(12-14-2016 11:03 AM)Gerald H Wrote:  How do I access the warm start log?

The command WSLOG will return 4 strings to the stack, each representing a recorded warmstart.

[Gerald H]

Thank you, David, nice of you to take the trouble to help.

[DavidM]

(12-14-2016 11:03 AM)Gerald H Wrote:  Turned on the 50g turned off in post #25.

NOTHING on the stack.

LASTARG recalled the timestring "SUN 11.12.16 09:32:31"

So if I'm understanding things correctly:

You powered down this 50g on the morning of 2016-12-07 and checked it on the morning of 2016-12-14.

Your STARTOFF should have left a string on the stack if it had run, but nothing was there. Correct? If so, either STARTOFF never ran, or something cleared what it left (or pushed a virtual stack entry and restored it, or invoked a system error, etc.).

LASTARG reports a string in the format you expected, which appears to indicate that something may have happened with STARTOFF on 2016-12-11 at 09:32:31. Kudos for checking LASTARG! I hadn't thought to do that.

Observation: <2016-12-11 09:32:31> - 2^31 ticks is approximately <2016-12-08 08:43:27>, which is about 24 hours later than would normally have been expected for the 262144-second TIMER2 reset (if I've understood your situation correctly). At a minimum, this tells me that I need to let more time pass before checking my 49g+/50g test units the next time.

Thanks for posting your results!

Also, FWIW regarding warmstarts:

WSLOG doesn't show all warmstarts. For example, manual warmstarts activated by ON-C don't create entries. There may also be other types that are excluded as well.

The usual question that comes up after mentioning WSLOG is "what are the codes at the beginning of the entries for?" This is the list of possibilities as found in the 50g Advanced Users Guide:

Code:

0: The warmstart log was cleared.
1: The interrupt system detected a very low battery condition at the battery
contacts (not the same as a low system voltage), and put the calculator in “Deep
Sleep mode” (with the system clock running). When ON is pressed after the
battery voltage is restored, the system warmstarts and puts a 1 in the log.
2: Hardware failed during transmission (timeout).
3: Run through address 0.
4: System time is corrupt
5: A Deep Sleep wakeup (for example, ON, Alarm).
6: Not used
7: A 5-nibble word (CMOS test word) in RAM was corrupt. (This word is checked
on every interrupt, but it is used only as an indicator of potentially corrupt RAM.)
8: Not used
9: The alarm list is corrupt.
A: System RPL jump to #0.
B: The card module was removed (or card bounce).
C: Hardware reset occurred (for example, an electrostatic discharge or user reset)
D: An expected System (RPL) error handler was not found in runstream.

I've seen references to codes E & F as well, though I've not seen any "official" documentation for what they mean. One post on comp.sys.hp48 lists them as:

E: Corrupt configuration table (bad checksum for table data)
F: System RAM card pulled

[Gerald H]

Yes, David, all your assumptions concerning my report are correct.

My next report in a week will be more explicit.

[Paul Berger (Canada)]

I set up my 49G+ with STARTOFF program that would add the date and time to a list when ever it executed. I turned it on today and there where two entries in my list
12/13/2016 15.4001555786
12/17/2016 16.4504594726

I did not record the exact time when I turned it off but the gap between the second two is just over 4 days and 1 hr.

I am setting up a 48GX, 49G, 49G+ and 50G with the same STARTOFF procedure and leaving myself a reminder to check them in the new year, I think I will turn them off with STARTOFF so the record the present time.

Paul.

[DavidM]

I checked my 49g+/50g this evening, and both had logged events since being manually powered down on 2016-12-12.

In both cases, the pattern was the same. The timing was slightly different, but the effect was similar. Both calculators have a TOFF set to 2 minutes.

49g+
Manually turned off at 2016-12-12 11:00:00A (#1DA385FE60C39h TICKS)
Automatically turned on at 2016-12-16 12:01:00P (#1DA390A6F82BBh TICKS)
Automatically turned off at 2016-12-16 12:03:15P (#1DA390A806B0Fh TICKS)
Auto wake-up occurred at #AA897682h TICKS after manual power down. That translates to about 349260.7 seconds.

50g
Manually turned off at 2016-12-12 11:00:04A (#1DA385FE68324h TICKS)
Automatically turned on at 2016-12-16 12:00:03P (#1DA390A687992h TICKS)
Automatically turned off at 2016-12-16 12:02:19P (#1DA390A7964AFh TICKS)
Auto wake-up occurred at #AA81F66Eh TICKS after manual power down. That translates to about 349200.7 seconds.

The auto-powerdown on both units was slightly above 135 seconds (about 2:15), which makes sense to me because the logging utility waits 15 seconds for the user to press a key to determine if it was a manual or auto power-on situation. That timeout added to the TOFF period matches 2:15.

Combining this with Gerald's and Paul's results, it appears that the ARM-based systems in this relatively small sample all seem to be "waking up" at approximately 97 hours after a power-down event.

I'm hopeful others will continue to report their results as well.

[HrastProgrammer]

(12-01-2016 03:35 AM)Claudio L. Wrote:  I can say that at some point during newRPL development, my machine didn't have auto power off. Therefore if it had turned on by itself it would've remained on and drained all the batteries. This did not happen during those couple of weeks, so I'm inclined to think it's a software issue, but needs some more confirmation as newRPL doesn't enable all sources for powerOn, just the On key (at the time of testing, now we have alarms but I haven't tested if if powers on by itself or not).

Another way to check it is to use HRAST BASIC with this simple program:

REPEAT OFF ? "ON" WAIT 16*5 UNTIL 0

Run the program, leave it for a couple of hours/days, then turn it on, press ON again to break the program and you'll see if it has been turned on in the meantime - more than one ON displayed ...

[Gerald H]

Here is the update to posting #40:

I turned my 50g off on

14/12 approx 12.05

& on at

23/12 approx 16.50, all times Vienna time.

The programme

« SPONT.REC DATE TIME TSTR + 'SPONT.REC' STO { 4111.2 4444 2222 } .3 BEEP OFF »

stored the time strings to the Home variable SPONT.REC, initialized as an empty string, & the contents at turning on were

{ "SUN 18.12.16 13:55:27"
"THU 22.12.16 15:00:29" }.

Does this seem to make sense?

Is any pet theory confirmed?

[Paul Berger (Canada)]

(12-23-2016 04:05 PM)Gerald H Wrote:  Here is the update to posting #40:

I turned my 50g off on

14/12 approx 12.05

& on at

23/12 approx 16.50, all times Vienna time.

The programme

« SPONT.REC DATE TIME TSTR + 'SPONT.REC' STO { 4111.2 4444 2222 } .3 BEEP OFF »

stored the time strings to the Home variable SPONT.REC, initialized as an empty string, & the contents at turning on were

{ "SUN 18.12.16 13:55:27"
"THU 22.12.16 15:00:29" }.

Does this seem to make sense?

Is any pet theory confirmed?

4 Days 1 Hour and 5 minutes, almost exactly what I got in my first run on my 49G+ . I have 4 calculators set up right now 2 ARM based and 2 Saturn. I heard at least one of them go off at about 3 days and another one the next day but I want to leave them until after the new year.

[DavidM]

(12-23-2016 04:05 PM)Gerald H Wrote:  { "SUN 18.12.16 13:55:27" "THU 22.12.16 15:00:29" }. Does this seem to make sense? Is any pet theory confirmed?

Well at the very least it seems to coincide nicely with other reports of ARM-based systems turning themselves on at intervals of 97 hours ( + the appropriate auto-shutdown period for your calculator).

(12-23-2016 06:17 PM)Paul Berger (Canada) Wrote:  4 Days 1 Hour and 5 minutes, almost exactly what I got in my first run on my 49G+ . I have 4 calculators set up right now 2 ARM based and 2 Saturn. I heard at least one of them go off at about 3 days and another one the next day but I want to leave them until after the new year.

Which fits with the above for the ARM systems, and also the previously-discussed 262144-second interval for non-ARM RPL systems.

Also for what it's worth:

I put together a Saturn code object to return the value of TIMER2 as a test, and ran it on a couple different systems in different scenarios.

On a 48gx:
- With the running clock turned off, pressing the key to get TIMER2 returns a value just a few ticks shy of 1-hour. That seems to coincide with the comments from comp.sys.hp48 made by Dan Kirkland that pressing a key would set TIMER2 to a 1-hour value.
- With the running clock turned on, the reported TIMER2 value was always just shy of 1 second (8192 ticks). So pressing a key also resets that timer value, but obviously at the lower value. This wasn't a surprise, but it was nice to confirm expectations.

On a 50g:
- With the running clock turned on, the behavior was the same as the 48gx.
- With the running clock turned off, the returned TIMER2 value was always just shy of 72 hours. This was much higher than I expected, but I see no inherent problems with that value.

All of this did cause me to doubt the concept of the "auto-off" timeout being serviced by TIMER2, though. If it was, there should never be a value greater than the remaining time before shutoff in TIMER2. Also, the above values weren't impacted at all when I changed the TOFF value. That implies that the auto-off timeout is serviced by some other means (TIMER1? Display refresh? Something else?).

[TravisE]

Okay, my turn to report. A while back (around December 7, I believe; I unfortunately didn't happen to record the exact date and time) I started my own test and checked the results just now (2006-12-28 14:06 local time).

STARTOFF: « 'OFFTEST' DATE TIME TSTR STO+ OFF »

After storing {} in OFFTEST and turning the 50g off and letting it sit undisturbed for roughly the last 3 weeks, the contents of OFFTEST are now:

{ "SUN 12/11/16 03:47:13"
"THU 12/15/16 04:52:14"
"MON 12/19/16 05:57:14"
"FRI 12/23/16 07:02:15"
"TUE 12/27/16 08:07:16" }

I'll leave it again starting 2016-12-28 14:19 and see if the pattern continues (or in particular, if it starts to “miss” 4d1h5m intervals).

[TravisE]

I decided to watch my HP 50g at around the time it would be expected to turn itself on and see if I could observe the event. It turns out I forgot to recalibrate the clock (or take its drift into account), so I missed the actual turn-on, but the calculator was already on when I took it out and later turned itself off a minute or two later. In other words, the automatic wake-up appears not to be just a brief turn-on, reset the “next event” timer, and then turn right back off again; rather, it waits the full TOFF time, just like a manual power-on.

[Paul Berger (Canada)]

Well I just checked my calculators and for the 49G+ and 50G the interval between power offs is consistently 4 days, 1 hour 5 minutes each one of them reported 3 times in the period they where turned off. I also had a 49G set up and it reported 4 times in the interval it was off, and the time between power offs is less than expected, I am only seeing a consistent 3 days and 5 minutes. I have not observed any of them when this wake up cycled occurred, but if they are actually waiting the auto off timeout period, that would mean that the time between turning off and wakeup would be 5 minutes less than the recorded times between turn offs. In any case it appears that the wakeups are anything but random, varying only by a fraction of a second in my case and that is likely due to temperature cycles affecting the clock speed.

[rprosperi]

(01-02-2017 02:06 AM)Paul Berger (Canada) Wrote:  Well I just checked my calculators and for the 49G+ and 50G the interval between power offs is consistently 4 days, 1 hour 5 minutes each one of them reported 3 times in the period they where turned off. I also had a 49G set up and it reported 4 times in the interval it was off, and the time between power offs is less than expected, I am only seeing a consistent 3 days and 5 minutes. I have not observed any of them when this wake up cycled occurred, but if they are actually waiting the auto off timeout period, that would mean that the time between turning off and wakeup would be 5 minutes less than the recorded times between turn offs. In any case it appears that the wakeups are anything but random, varying only by a fraction of a second in my case and that is likely due to temperature cycles affecting the clock speed.

The machines with the HP-made Saturn CPU (48 family, 49) follow the auto-power-on cycle with the shorter ~3-day period, while the ARM-based machines cycle on the ~4-day period. I don't know the exact reason for the different counters, but obviously related to the emulation layer.

[HrastProgrammer]

I did a test with HRAST BASIC program which shows "on times" and puts the calculator to sleep again 1 second after that.

The HP-50G results are:

2016/12/25 15:30:11 (initial power off)
2016/12/29 16:30:11
2017/01/02 17:30:12
2017/01/06 18:30:13
2017/01/10 19:30:14
2017/01/14 20:30:15

Those times are consistent with the previous findings (turning on every 4 days 1 hour).

The reason why this works with HRAST BASIC is because I am returning control to the calculator firmware when powering down.

[DavidM]

I know this is an old thread, but its topic is one that takes some time to explore. Please forgive my adding a followup.

After leaving a 49g+ and 50g in a drawer for about three months, I checked their status. Not too surprisingly, both systems powered on automatically at the 97-hour intervals already discussed.

Perhaps the most interesting thing about these results is their consistency. Given the evidence I (and others) have seen about alarm execution inconsistencies on the ARM-based units, I was prepared to find some missing or delayed power-up events. There were none, however. Could it be that the alarm-triggering bug doesn't affect the 97-hour power-up? This is an admittedly small sample, but based on my experience, a repeating user alarm over this same time period would have resulted in noticeable problems.

Just a tiny bit more data to add to the pile.

[TravisE]

I ran my experiment since my last post a couple of months ago up until a few days ago when I finally stopped, with the same result. No anomalies at all.

If only we could pin down precisely what triggers the alarm bug and understand it enough that it's no longer such a seemingly-random occurrence, that'd really help shed some light on things. Does anyone happen to know exactly how the alarm code works? Is there any chance at all it could have some relation to the “busy” (keystroke on CPU idle) bug?