01-18-2014 08:50 PM
I use to use the alarms of my HP-48 years ago and haven't really done much with alarms on my HP-49g+ and HP-50g. And this may be a 'dead horse' subject by now anyway. I remember years ago after I obtained my '49g+ and played around with the alarms a few times, I noticed that sometimes alarms would not happen or be delayed. I kinda dismissed it then as I really didn't use alarms much (personal alarms are more taken care by my phone, etc. now anyway). But recently I noticed it again as I was thinking about writing some programs that need to be 'automated' at various times.
I then looked at the '50g and it has the same problem. I even made an experiment and set up a periodic alarm to execute a simple program object at a set interval that simple puts the current time on the stack (<< TIME SWAP DROP OFF >>). Then I let it run a while. When enough was enough, I examined the times on the stack (there were 100 of them). 95 percent of them were one minute late, with the rest within seconds.
Since this probably an widely known problem (though I have not seen any info about on this board), I was wondering if anyone knows the cause of it and if there is a work-around of best acceptance. What is the 'offical' story?
Again, I'm not looking to use an HP-50g as my personal alarm clock or appointment reminder (as phones today do that pretty well). However, I may have an inclining of using one as a control device in an experiment (using the serial port for I/O with the experiment) and the alarm functionality would need to be deterministic.
01-24-2014 06:26 PM
I don't see any replies to my last message. I am surprised. Either I have a unique problem (with two calculators?) or alarms are not used anymore. I am surprised I didn't receive an answer like "Oh, everybody knows about that problem, you #@!, this is how we all fixed it (or worked around it)". Or at least some HP tech saavy one could have explained technically why the problem occurs.
Nevertheless, I have a kind of work-around. When the calculator is already powered on when an alarm activates, it seems to not have the minute delay but a mere second or two (or less). I confirmed this by a similar experiment to what I did but actually set a control alarm about two minutes before the "measurement" alarm that effectively does nothing but get the calculaor powered on (which would be delayed about a minute itself). So it would be sitting on and idle for about a minute when the second alarm activated. With about 150 instances, this scheme worked in every case.
Now I can go off and make those precise measurements using my HP-50 on the Hadron Super-Collider.... (just kidding, I think, or maybe I'm not [there's a quantum physics joke here somewhere, maybe])
01-25-2014 12:43 AM
>make those precise measurements using my HP-50 on the Hadron Super-Collider.... ([there's a quantum physics joke here somewhere, maybe])
Because if you measure precisely the time, you don't know the energy? :-)
01-25-2014 02:02 PM
I have also had the problem of late alarms. It's sporadic and sometimes I think it's as much as an hour late. Your solution is great for the slightly-late issue. In my case the alarms are almost all notifications (e.g. "time go put down your toys and go home" or "Doctor's appointment, no breakfast today") so being late by a minute isn't an issue and being late an hour wouldn't be addressed, sadly. I would hope someone would be able to find where in the ROM the problem lies; since the calculator is different hardware than original running an emulator of an emulator (I think ... maybe one step less gnarly than that) it's maybe not too surprising that a watchdog function would be hard to get working right.
01-27-2014 03:15 AM
Sorry you are disappointed by the lack of replies.
Yes, it is a known problem.
Apparently this has to do with the emulation of the 50g Saturn-based firmware on the ARM micro-processor. HP contracted out the development of this emulation layer to Kinpo. There seems little chance of a fix.
http://bugs.hpcalc.org/show_bug.cgi?id=237. This bug report was opened in Jan 2008. Although reported on ROM version 2.09, it claims the problem was known on v. 2.08. The problem still exists in the current ROM version is 2.15.
At the bottom of the bug report also see: Additional Comment #2 From Eric Rechlin 2009-07-31 22:16, it references a post on the newsgroup comp.sys.HP48:
02-01-2014 05:48 PM
Well, at least there is some closure on this ( to paraphrase the thread, "suck it up" ;-) ). I'm still using my 50g rather than a Prime because I have a lot of User RPL code that I have developed over (tens of) years and I understand that there's no way to run it on the new machine. If that's no longer true I would be delighted to hear about it.
Maybe when I retire I'll think about porting it all to the HP Prime. Or maybe I'll trade in my flip phone (now I am really dating myself) for a smartfone and run everything on an emulator. The 50G is fine, but eventually the hardware will die. Maybe it will be moot ...