Making the faulty HP-50g alarm function predictable and useful

[Johnny Shek]

Long story short. Create the STARTOFF variable with a simple program « OFF » in the HOME directory. Create appointment or control alarms as usual and confine their number to 2. The calculator will wake up with a delay of 1 minute at most for each alarm. In nearly all cases, the delay is exactly 1 minute.

ROM version: 2.15
Number of test cases: 24

[Johnny Shek]

UPDATE:

In previous tests, I created more than 20 entries in the system alarm list. Only the top 2 to 3 alarms could wake up the calculator with 1 minute delay. Other alarms had unknown amounts of delay as they woke up only after I turned it on. Apparently, too many entries caused it to behave erratically.

I am working on tests with incremental number of entries starting from 3 to try to touch the limit of the calculator. An initial test showed that 3 entries made by any permutation of appointment and control alarms worked perfectly.

Stay tuned!

[Johnny Shek]

UPDATE:

Having finished a test of 19 entries with half of them being appointment alarms and another half being control alarms, the calculator did not show any erroneous behaviour. Increasing from 3 to 19 entries for the tests, those 187 alarms had a delay of 1 minute. Some users reported that an alarm came due without any delay when the calculator was still on. It was also found that an alarm came due exactly at the instant when I turned it on within the 1 minute delay.

I am in search of the maximum number of entries that the calculator can hold. For the moment, 19 entries should suffice for any purpose.

Stay tuned!

[Johnny Shek]

UPDATE:

In a test of 25 entries, the 15th and 16th ones failed to execute properly. They executed when I turned on the calculator. I stopped the test and deleted all entries. Normally, I created entries with 1 hour alarm time apart. In this test, I mistakenly entered an alarm with time 10:20 instead of 10:00. The alarm time just above it was 09:00 and the alarm time just below it was 11:00.

Unfortunately, I could not replicate the same problem after conducting another test with correct entries. Later, I conducted a test with 12 entries with 2 hours apart and no problem was found. Besides, another similar test with 24 entries was passed. I will stop here. It appears that the maximum number of entries the calculator can hold is 24. I will begin to examine the behaviour of alarms with a repeat interval. All previous tests ignored the repeat interval.

Stay tuned!

[Johnny Shek]

UPDATE:

After conducting a test of 6 entries each having a repeat interval of 1 day, it was found that the 6th entry with an alarm time of 10:59 failed to execute properly. In the light of this irregularity and the irregularity found earlier in the test of 25 entries, it appears that an alarm with non-integer time will not wake up the calculator properly. Early tests only took integer alarm times, e.g. 1:00:00, 2:00:00, 3:00:00...... Over 360 entries have executed with a delay of 1 minute without any exception. Although my tests had flaws and failed to discover the irregularity, their results might provide a clue to arrive at the ultimate solution.

Before finding the STARTOFF variable as a starting point, many tests were conducted. It was found that an alarm that would come due within 59 minutes from its creation time always had a delay of 1 minute. If an alarm took more than 59 minutes to come due, only 2 durations of delay, 1 minute and 1 hour and 1 minute, were observed. Based on the tests and findings above, a control alarm can be set using just the hour part of the desired alarm that has a non-integer time. The control alarm also has an action to ‘carry’ the desired alarm for its subsequent execution. Here are some examples:

Control alarm set for 10:00:00 with the following action to carry an appointment alarm set for 10:59:

« DATE { 10.59 « DELALARM ACK OFF » } + STOALARM DATE { 10.59 “GOOD MORNING!” } + STOALARM 3. DROPN OFF »

Control alarm set for 5:00:00 with the following action to carry another control alarm set for 5:30:

« DATE { 5.3 « DELALARM DATE TIME 2. →LIST OFF » } + STOALARM DROP2 OFF »

The 6th entry in the above-mentioned test was replaced by a control alarm that carried the desired alarm and then the test was repeated. It did execute properly! 2 full cycles of another similar test with 6 desired alarms each having a non-integer alarm time were completed successfully. I have no idea how scalable this method is but further tests will be conducted. The above-mentioned test with 25 entries containing a desired alarm set for 10:20 will be repeated using this method. This test will also be modified with 25 desired alarms each having a non-integer alarm time and a repeat interval of 1 day.

Stay tuned!

[Johnny Shek]

UPDATE:

24 entries were my estimated maximum number of entries allowed by the calculator. However, this ‘limit’ was surpassed by 25 entries for an old test using the new method and a new 2-cycle test of all 25 entries each having a non-integer alarm time and a repeat interval of 1 day.

A further attempt of 30 entries suffered a setback! Based on the previous 25 entries, I added 2 entries on the top and 3 entries on the bottom. In the earliest 1.5 cycles, everything seemed to work fine before I started to revise a few times the action of each control alarm that carried an appointment alarm. It was found that 3 entries failed to wake up. This was also the first time an alarm with integer hour did not execute properly. In both cases, there was a desired alarm that would come due at hh:59. Plus 1 minute delay, it did come due at hh+1:00. It in turn triggered indirectly control alarms that would come due at hh+1:00. Unexpectedly, they could not execute! After performing a factory reset by pressing ON-F1-F6-NO, I re-created nearly the same set of those 30 entries from scratch except a corrected digit in the minute part of the desired alarm of the last entry. 2 of the 3 entries worked again but not all. I suspected that some memory problems might have occurred.

I had to go back to 25 entries where those 3 entries had once worked. After performing another factory reset, I created them one by one each having a revised action yet the same alarm time from scratch. 3 cycles were completed successfully. It appears that 30 entries would be too many for the calculator. I will begin at 29 entries and decrease the number one by one until I find the maximum number of entries without causing any irregularity.

Apparently, the use of a control alarm to carry a desired alarm seems to make the faulty alarm feature predictable and useful. My focus will turn to the test of boundary scenarios.

It is time to summarise some information at this stage.

Make sure the ROM version is 2.15. The STARTOFF variable that stores a program « OFF » should be ready before using the following actions. No matter what the alarm is, it will come due with 1 minute delay. One of the exceptions is that other alarms trigger it at its entered alarm time. Practically, it is very rare for 2 alarms to be set so close that an alarm will trigger another. However, it should be avoided. See the example in the 2nd paragraph.

For a desired alarm having an integer alarm time or having an alarm time within 59 minutes from its creation time, set it as usual. If the desired alarm has a non-integer time, always create a control alarm with an integer time that is the hour part of the desired alarm and use it to carry the desired alarm. To make the actions look more consistent, I replaced the more hard-coded yet shorter hh.mm with a code segment “TIME IP .mm +” and probably a + sign.

Here are some examples without a repeat interval.

Control alarm set for 10:00:00 with the following action to carry an appointment alarm set for 10:20:

« DELALARM DATE TIME IP .2 + { “M2” } + + STOALARM DROP OFF »

Control alarm set for 6:00:00 with the following action to carry another control alarm set for 6:50:

« DELALARM DATE TIME IP .5 + { « DATE TIME 2. →LIST SWAP DROP OFF » } + + STOALARM DROP OFF »

In the previous reply, 2 actions were shown each having a repeat interval of 1 day. Now their less hard-coded versions are ready to accept an integer repeat interval in hours, days or weeks.

Control alarm set for 10:00:00 with the following action to carry an appointment alarm set for 10:58:

« DATE TIME IP .58 + 2. →LIST DUP { « DELALARM -44 CF ACK OFF » } + STOALARM SWAP { “GOOD MORNING!” } + STOALARM 3. DROPN OFF »

Control alarm set for 5:00:00 with the following action to carry another control alarm set for 5:30:

« DATE TIME IP .3 + { « DELALARM DATE TIME 2. →LIST OFF » } + + STOALARM DROP2 OFF »

There will be cases that the repeat interval is in minutes, seconds or any unit in non-integer values. As it is not straightforward to handle such cases, programs should be developed. If you feel that the above actions are too tedious to enter, programs will also be developed to simplify entry. They will be posted here later.

Stay tuned!

[Johnny Shek]

UPDATE:

One thing suddenly strikes my mind. In the summary I made in the last reply, I forgot to mention how an alarm could be set for less than an hour from the current time. This is exactly the idea of using a control alarm to carry a desired alarm to make sure that it comes due with 1 minute delay if it is set for less than or equal to 59 minutes from its creation time. Suppose I want to set an alarm for 12:26 at 12:01 now. According to the ‘59 minute rule’, set the alarm as usual and it will come due at 12:27. The above reply has been updated accordingly.

I am working on boundary tests. In my first attempt to stretch the ’59 minute rule’ to its limit by extending it from 59 minutes 1 second to 59 minutes 59 seconds, I encountered various kinds of unacceptable behaviour. It is better for me to leave the discussion to the next reply.

29 entries were created from scratch based on the alarm data of the first 29 entries of the above 30 entries. After performing a factory reset, the test was conducted. 3 cycles were run without any problem! 29 entries might be the maximum number of entries allowed by the calculator. No more stress tests will be conducted.

Stay tuned!

[SammysHP]

Instead of empirically finding rules how to set alarm so that it works in some mysterious way, I'd be more interested in actual reverse engineering or technical analysis of the alarm handling. Is there a layer that uses the watchdog and an interrupt to wake up? Is it implemented directly in the ROM?

[Johnny Shek]

(08-31-2024 11:14 AM)SammysHP Wrote:  Instead of empirically finding rules how to set alarm so that it works in some mysterious way, I'd be more interested in actual reverse engineering or technical analysis of the alarm handling. Is there a layer that uses the watchdog and an interrupt to wake up? Is it implemented directly in the ROM?

Thank you very much for your reply.

This has been a long-standing issue since probably the earliest ROM version of the HP-49g+. Some users posted the issue to user groups or forums, which caught the attention of some HP’s ‘internal guys’. They told Kinpo to fix it. According to the conversations and my understanding, this issue is related to a synchronisation problem between the Saturn emulation layer and the ARM CPU. It has nothing to do with the Saturn code and so the HP-49g has no such issue. Unfortunately, this issue still exists in the latest ROM version of the HP-50g. It seems that the fix would not be simple.

https://groups.google.com/g/comp.sys.hp48/c/Pn7xRbcM5Ow

I had not used the alarm feature since the era of the HP-48SX until recently. In June, I started to look into the issue and designed a lot of programs as well as tests to identify certain patterns to enable me to find a workaround. Hopefully, some users find my information helpful if they still want to use the alarm feature under ROM version 2.15.

[cdmackay]

thanks very much, for the detailed notes, Johnny.

[Johnny Shek]

UPDATE:

To conduct boundary testing for this black box is something like a trial-and-error exercise based on only a few observed patterns of the calculator’s behaviour. The tests are not exhaustive too. Sometimes, previous findings become invalid in later tests and changes should be made. Certain tests should be conducted again to verify if these changes work fine.

Tests on the ’59 minute rule’ gave disappointing results. Being carried by control alarms, desired alarms set for hh:59:ss did not wake up as expected at times. Besides, they might cause an alarm just below it to fail. However, replacing hh:59:ss with hh:58 could work. A preliminary test of 30 entries after doing such change to 2 entries also worked. Therefore, the ’59 minute rule’ should be changed to the ’58 minute rule’.

Based on the observations of previous tests, 3 rules might avoid irregularities:

1. The maximum span for a desired alarm from its creation time is 58 minutes*.
2. Avoid setting an alarm for hh:59:ss.
3. Any 2 alarms should have their preset times at least 4 minutes apart if they are under 2 neighbouring integer hours.

* A desired appointment alarm with a repeat interval might fail to wake up if it is set for more than 58 minutes from its creation time. However, other desired alarms with or without a repeat interval can be set with an extended maximum span of 58 minutes 59 seconds.

If you use a control alarm set for 12:00:00 to carry a desired appointment alarm with a repeat interval, the maximum time for the desired alarm is 12:58:00. If you want to set a desired alarm right now, the maximum time for the desired alarm is the time obtained by adding 58 minutes 59 seconds to the current time.

If a desired alarm set for 12:56 co-exists with other alarms, the others should be set for 4 minutes later. In this case, the nearest alarm can be set for 13:00 as they are under 2 neighbouring integer hours, 12:00:00 and 13:00:00.

In actual operation, there might be more than one approach to set an alarm. Suppose you want to set a repeat alarm for 07:00 (approximately) every morning. Assume that there is no intervention from the user, alarms or programs.

Approach 1: Use a control alarm set for 06:00:00 to carry a desired appointment alarm set for 06:58 with a repeat interval of 1 day. Taking the 1 minute delay into account, the desired alarm will wake up at 06:59. I just copy the action from the above reply and make some modifications below.

« DATE TIME IP .58 + 2. →LIST DUP { « DELALARM -44 CF ACK OFF » } + STOALARM SWAP { “GOOD MORNING!” } + STOALARM 3. DROPN OFF »

I have also updated the action from the above reply accordingly.

Approach 2: Set a desired alarm for 07:00 normally. It will wake up at 07:01.

Approach 3: A control alarm set for 06:00:00 is used to carry a desired appointment alarm set for 06:58:59. It will wake up at 06:59:59, which is just 1 second shy of 07:00.

« DATE TIME IP .5859 + { “GOOD MORNING!” } + + STOALARM DROP2 OFF »

However, you need to include a control alarm set normally for non-busy hours, say 03:00:00, with the following action and a repeat interval of 1 day to acknowledge all appointment alarms every day.

« -44 CF ACKALL DROP OFF»

Don’t set a desired alarm for 06:59 to expect it to wake up at 07:00. It might fail!

More boundary conditions will be explored. A forthcoming program will also be developed to steer away from irregularity-prone situations.

Stay tuned!

[0db]

You're not getting much feedback with this project, but I appreciate your efforts and published results. At this point I've settled on the 50g as my main HP calculator, so I'm interested in anything related to the 50g, but not so much the CAS, as I use Mathematica for that kind of work.

Perhaps, what with smart phones and all, people don't really need to use the 50g for notification alarms, but the control alarms still have some uses, for example, to improve the accuracy of the built-in clock.

[Johnny Shek]

(09-30-2024 03:11 PM)0db Wrote:  You're not getting much feedback with this project, but I appreciate your efforts and published results. At this point I've settled on the 50g as my main HP calculator, so I'm interested in anything related to the 50g, but not so much the CAS, as I use Mathematica for that kind of work.

Perhaps, what with smart phones and all, people don't really need to use the 50g for notification alarms, but the control alarms still have some uses, for example, to improve the accuracy of the built-in clock.

Thank you very much for your reply and your praise.

I had searched for topics related to the bug of the HP-50g alarm feature. According to the following link, discussions on it can date back to January 2008, which is the earliest I can find on the net. However, the latest official ROM update 2.15 still cannot fix it! Some users did mention it in some later related discussions but no fix or workaround has been suggested.

https://groups.google.com/g/comp.sys.hp48/c/Pn7xRbcM5Ow

To a lot of users, the alarm feature of an RPL machine is not that important. I just used it for testing recently on the HP-49g+ and the HP-50g since I bought the HP-48SX shortly after it was released. I rely on my physical clock or my mobile phone to wake me up every day. However, the alarm feature in a computing device can be used in so many ways. It would be great if some users find my suggested workaround useful and gain confidence again in using it to adjust the clock, as you say, do routine tasks or control devices.

[Johnny Shek]

UPDATE:

Under an integer hour hh:00:00, the maximum time for a desired alarm ranges from hh:58:00 to hh:58:59, depending on the approach of setting a desired alarm. There is another story in the other end. The minimum time is expected to be after hh:01:00 considering that a control alarm set for hh:00:00 has a 1 minute delay. Therefore, it is impossible to set an executable desired alarm for hh:01:00. I tried to set it for hh:01:01, which worked in non-coincidental entries. Coincidental entries are alarm entries having exactly the same date and time, which are very rarely used. If you want to use coincidental entries for a special purpose, add 1 second or more to each desired alarm, say, hh:01:02. Otherwise, an irregularity might occur!

Tests indicated alarms set for hh:01:01 would wake up at hh:01:02. By hh:02:00, the behaviour was the same. Starting from hh:02:01, the 1 minute delay returned.

The following table summarises what is going to happen after setting an alarm without intervention from the user, alarms or programs.

Code:

Preset alarm time                       Expected alarm time

hh:00:00 (normally set)                 hh:01:00
hh:01:00                                never executes
hh:01:01 (non-coincidental)             hh:01:02
hh:02:00                                hh:02:01
hh:02:01                                hh:03:01
hh:58:00                                hh:59:00
hh:58:59 (might need an extra alarm)    hh:59:59

In the above table, it is very clear that it is impossible for an alarm to wake up from hh:02:02 to hh:03:00 and from hh:00:00 to hh:00:59. In the first time range, use hh:01:59 as a ‘secondary’ control alarm to carry the desired alarm. I know it is a bit of overkill and so leave it to a program. In the second time range, tests showed that setting a desired alarm for hh:59:ss might be the ‘kiss of death’!

Many users usually just have a try on the alarm feature by setting an alarm for a few minutes to less than 59 minutes from the current time. This is the only time range for which one can set an alarm in the normal way. Tests showed that doing so has never triggered any irregularity. The maximum delay was 1 minute 1 second.

Code:

Preset alarm time          Expected alarm time

current time + 10 s        delay of 1 s
current time + 30 s        delay of 1 s
current time + 1 m         delay of 1 s/2 s
current time + 2 m         delay of 1 s    
current time + 3 m         delay of 1 s
current time + 5 m         delay of 1 s/2 s
current time + 10 m        delay of 1 s/1 m/1m 1s
current time + 20 m        delay of 1 s/1m/1 m 1 s
current time + 30 m        delay of 1 m/1 m 1 s
current time + 40 m        delay of 1 m/1 m 1 s
current time + 50 m        delay of 1 m/1 m 1 s
current time + 58 m 59 s   delay of 1 m/1 m 1 s

Stay tuned!

[Johnny Shek]

UPDATE:

I happened to find 2 newsgroup messages posted in 2006 and 2007 respectively, relating to the alarm bug, earlier than the one I gave before, but only a few people participated in the discussions:

https://comp.sys.hp48.narkive.com/1gWINQ...n-when-off
https://groups.google.com/g/comp.sys.hp4...4656a98022

In the course of finding ways for the calculator to wake up in the time range, hh:00:00 to hh:00:59, certain test results are very promising. I observed that an alarm could be set for hh:59:ss normally with its action using the STARTOFF/TOFF pair instead of the OFF command to turn off the calculator. More importantly, this discovery could be used in the current method. Now a control alarm can itself be set normally for hh:00:00 and carry another alarm (including the use of a secondary control alarm) for the calculator to wake up from hh:01:00 to hh+1:00:59. Although some previous tests are yet to be re-tested, it is expected that alarms would cause fewer irregularities. At least, there is no longer any ’58 minute rule’ and the ‘kiss of death’ is gone!

With the new mechanism, the action should contain the following code that changes the value of the TOFF variable to shorten the auto power off time to, say, #2000h ticks (1 second):

Code:

……PATH HOME #2000h ‘TOFF’ STO EVAL……

After the action finishes, it immediately releases control to the system. It then appears to ‘tweak itself’ and subsequent alarms appear to be less prone to irregularities. The OFF command, however, does not offer such ‘break’. The program stored in the STARTOFF variable is triggered in 1 second to restore a reasonable auto power off time, say, its default, and then turn off the calculator.

The program in the STARTOFF variable is:

Code:

« PATH HOME ‘TOFF’ IFERR PURGE THEN END EVAL OFF »

In the tests, setting two neighbouring (the nth and the (n+1)th) alarms for hh:59:ss where their alarm times were less than 1 hour 1 minute apart might cause an irregularity. However, there were exceptions that the (n+1)th alarm worked properly if their alarm times had the same number of second(s), say, 00:59:00 and 01:59:00, or the auto power off time was set to default. A closer examination of this behaviour will be conducted.

With simple replacement of the OFF command in the action of the single-occurrence appointment alarm mentioned in a previous reply, the alarm set for hh:59:00 to show the message “GOOD MORNING!” becomes:

Code:

« DELALARM DATE TIME IP .59 + { “GOOD MORNING!” } + + STOALARM  DROP PATH
  HOME #2000h ‘TOFF’ STO EVAL »

Other actions are treated in the same way.

The action of the single-occurrence control alarm set for hh:59:00 to show the current date and time becomes:

Code:

« DELALARM DATE TIME IP .59 + { « DATE TIME 2. →LIST SWAP DROP PATH HOME
  #2000h ‘TOFF’ STO EVAL » } + + STOALARM DROP PATH HOME #2000h ‘TOFF’ STO EVAL
  »

The action of the repeating appointment alarm set for hh:59:59 to show the message “GOOD MORNING! “ becomes:

Code:

« DATE TIME IP .5959 + 2. →LIST DUP { « DELALARM -44. CF ACK PATH HOME #2000h
  ‘TOFF’ STO EVAL » }  + STOALARM SWAP { “GOOD MORNING!” } +  STOALARM 3. DROPN
  PATH HOME #2000h ‘TOFF’ STO EVAL »

The action of the repeating control alarm set for hh:59:59 to show the current date and time becomes:

Code:

« DATE TIME IP .5959 + { « DELALARM DATE TIME 2. →LIST PATH HOME #2000h ‘TOFF’
  STO EVAL » } + + STOALARM DROP2 PATH HOME #2000h ‘TOFF’ STO EVAL »

Don’t forget that each alarm will wake up with 1 minute delay if there is no intervention from the user or system. For example, an alarm set for 06:59:00 will wake up at 07:00:00.

With this discovery, it might be easier to explore how to handle alarms repeated in minutes, seconds or non-integer values of any other time units. Besides, the forthcoming program that facilitates alarm creation might be simpler to develop.

Stay tuned!