Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
hp50g missed appt alarm solution
266 views
Skip to first unread message
Jim Dumas
Oct 26, 2012, 1:10:16 PM10/26/12
to
Just to say that I have had good success waking up the hp50g for
appointment alarms. The method uses no text label/tag for the alarm and
places a backup appointment alarm in the alarm queue as well. The backup
alarm is 30 seconds before the required alarm time and the primary alarm
is 1 minute and 30 seconds before the required alarm time.
The hypothesis is the ARM emulator checks each minute for a new alarm
while the 50g is off. If it misses the first alarm, one minute later it
will see both alarms and wake up.
I've only been using the 50g since late July this year, and this alarm
backup method without a text argument for two months with good success.
So what have others done to solve missed alarms? Google not much help.
--
Jim Dumas
hp48sx->gx->50g Lib 849 DMIT Dynamic Mathematical Insulin Therapy
Lib 849 is unpublished work for liability reasons.
Email mangled: change SeeSig2Fix to mindspring SVP.
appointment alarms. The method uses no text label/tag for the alarm and
places a backup appointment alarm in the alarm queue as well. The backup
alarm is 30 seconds before the required alarm time and the primary alarm
is 1 minute and 30 seconds before the required alarm time.
The hypothesis is the ARM emulator checks each minute for a new alarm
while the 50g is off. If it misses the first alarm, one minute later it
will see both alarms and wake up.
I've only been using the 50g since late July this year, and this alarm
backup method without a text argument for two months with good success.
So what have others done to solve missed alarms? Google not much help.
--
Jim Dumas
hp48sx->gx->50g Lib 849 DMIT Dynamic Mathematical Insulin Therapy
Lib 849 is unpublished work for liability reasons.
Email mangled: change SeeSig2Fix to mindspring SVP.
Han
Oct 26, 2012, 1:58:40 PM10/26/12
to
On Friday, October 26, 2012 1:10:16 PM UTC-4, Jim Dumas wrote:
> Just to say that I have had good success waking up the hp50g for
>
> appointment alarms. The method uses no text label/tag for the alarm and
>
> places a backup appointment alarm in the alarm queue as well. The backup
>
> alarm is 30 seconds before the required alarm time and the primary alarm
>
> is 1 minute and 30 seconds before the required alarm time.
>
>
>
> The hypothesis is the ARM emulator checks each minute for a new alarm
>
> while the 50g is off. If it misses the first alarm, one minute later it
>
> will see both alarms and wake up.
>
>
>
> I've only been using the 50g since late July this year, and this alarm
>
> backup method without a text argument for two months with good success.
>
>
>
> So what have others done to solve missed alarms? Google not much help.
>
> --
>
> Jim Dumas
>
Somewhat tongue-in-cheek response: I don't rely on my HP50G for alarms -- or even to keep track of time. This was something one could do on the HP48 series w/out having to do "backup" alarms. When HP decided to go the cheap route with Kinpo, they got what they (didn't) pay for: a cheap device that does not always work as designed.
> Just to say that I have had good success waking up the hp50g for
>
> appointment alarms. The method uses no text label/tag for the alarm and
>
> places a backup appointment alarm in the alarm queue as well. The backup
>
> alarm is 30 seconds before the required alarm time and the primary alarm
>
> is 1 minute and 30 seconds before the required alarm time.
>
>
>
> The hypothesis is the ARM emulator checks each minute for a new alarm
>
> while the 50g is off. If it misses the first alarm, one minute later it
>
> will see both alarms and wake up.
>
>
>
> I've only been using the 50g since late July this year, and this alarm
>
> backup method without a text argument for two months with good success.
>
>
>
> So what have others done to solve missed alarms? Google not much help.
>
> --
>
> Jim Dumas
>
Travis Evans
Nov 4, 2012, 6:02:35 PM11/4/12
to
On Fri, 26 Oct 2012 10:58:40 -0700 (PDT), Han <rs...@hotmail.com> wrote:
> On Friday, October 26, 2012 1:10:16 PM UTC-4, Jim Dumas wrote:
>> Just to say that I have had good success waking up the hp50g for
>> appointment alarms. The method uses no text label/tag for the alarm and
>> places a backup appointment alarm in the alarm queue as well. The backup
>> alarm is 30 seconds before the required alarm time and the primary alarm
>> is 1 minute and 30 seconds before the required alarm time.
>>
>> The hypothesis is the ARM emulator checks each minute for a new alarm
>> while the 50g is off. If it misses the first alarm, one minute later it
>> will see both alarms and wake up.
>>
>> I've only been using the 50g since late July this year, and this alarm
>> backup method without a text argument for two months with good success.
>>
>> So what have others done to solve missed alarms? Google not much help.
>
> On Friday, October 26, 2012 1:10:16 PM UTC-4, Jim Dumas wrote:
>> Just to say that I have had good success waking up the hp50g for
>> appointment alarms. The method uses no text label/tag for the alarm and
>> places a backup appointment alarm in the alarm queue as well. The backup
>> alarm is 30 seconds before the required alarm time and the primary alarm
>> is 1 minute and 30 seconds before the required alarm time.
>>
>> The hypothesis is the ARM emulator checks each minute for a new alarm
>> while the 50g is off. If it misses the first alarm, one minute later it
>> will see both alarms and wake up.
>>
>> I've only been using the 50g since late July this year, and this alarm
>> backup method without a text argument for two months with good success.
>>
>> So what have others done to solve missed alarms? Google not much help.
>
> Somewhat tongue-in-cheek response: I don't rely on my HP50G for alarms
> -- or even to keep track of time. This was something one could do on
> the HP48 series w/out having to do "backup" alarms. When HP decided to
> go the cheap route with Kinpo, they got what they (didn't) pay for: a
> cheap device that does not always work as designed.
Even if the alarms worked perfectly 100% of the time, the beeper is so
> -- or even to keep track of time. This was something one could do on
> the HP48 series w/out having to do "backup" alarms. When HP decided to
> go the cheap route with Kinpo, they got what they (didn't) pay for: a
> cheap device that does not always work as designed.
faint I wouldn't find them at all usable for anything critical, unless
I kept the calculator strapped to my ear all the time. :-)
I haven't found the 50g too terribly bad with time accuracy personally,
especially after measuring the drift over a few weeks and setting up a
program to recalibrate it every once in a while.
--
Travis
Jim Dumas
Nov 5, 2012, 11:15:16 AM11/5/12
to
On Sun, 04 Nov 2012 23:02:35 +0000, Travis Evans wrote:
> Even if the alarms worked perfectly 100% of the time, the beeper is so
> faint I wouldn't find them at all usable for anything critical, unless I
> kept the calculator strapped to my ear all the time.
>
> Even if the alarms worked perfectly 100% of the time, the beeper is so
> faint I wouldn't find them at all usable for anything critical, unless I
> kept the calculator strapped to my ear all the time.
>
> I haven't found the 50g too terribly bad with time accuracy personally,
> especially after measuring the drift over a few weeks and setting up a
> program to recalibrate it every once in a while.
Hi Travis,
> especially after measuring the drift over a few weeks and setting up a
> program to recalibrate it every once in a while.
I have never had a blank "" text message double alarm fail to alert me.
But I have had text message double alarms fail to alert me. Why this
makes a difference is not clear. But I have not been working on the text
message failure of appointment alarms very long.
The 50g time keeping works well for me too w/clckadjust+ AAD function.
Travis Evans
Nov 5, 2012, 4:37:26 PM11/5/12
to
On Mon, 05 Nov 2012 10:15:16 -0600, Jim Dumas <j_d...@SeeSig2Fix.com> wrote:
> On Sun, 04 Nov 2012 23:02:35 +0000, Travis Evans wrote:
>
>> Even if the alarms worked perfectly 100% of the time, the beeper is so
>> faint I wouldn't find them at all usable for anything critical, unless I
>> kept the calculator strapped to my ear all the time.
>>
>> I haven't found the 50g too terribly bad with time accuracy personally,
>> especially after measuring the drift over a few weeks and setting up a
>> program to recalibrate it every once in a while.
>
> Hi Travis,
>
> I have never had a blank "" text message double alarm fail to alert me.
> But I have had text message double alarms fail to alert me. Why this
> makes a difference is not clear. But I have not been working on the text
> message failure of appointment alarms very long.
>
> The 50g time keeping works well for me too w/clckadjust+ AAD function.
Interesting. I actually haven't seen text message alarms for sure fail,
> On Sun, 04 Nov 2012 23:02:35 +0000, Travis Evans wrote:
>
>> Even if the alarms worked perfectly 100% of the time, the beeper is so
>> faint I wouldn't find them at all usable for anything critical, unless I
>> kept the calculator strapped to my ear all the time.
>>
>> I haven't found the 50g too terribly bad with time accuracy personally,
>> especially after measuring the drift over a few weeks and setting up a
>> program to recalibrate it every once in a while.
>
> Hi Travis,
>
> I have never had a blank "" text message double alarm fail to alert me.
> But I have had text message double alarms fail to alert me. Why this
> makes a difference is not clear. But I have not been working on the text
> message failure of appointment alarms very long.
>
> The 50g time keeping works well for me too w/clckadjust+ AAD function.
but then again I haven't used them for anything critical. When the
calculator is off, alarms usually seem to trigger eventually, but can be
somewhat late. I haven't investigated the issue very thoroughly, but
something fishy does seem to go on at times.
(I know program alarms, but not text alarms, interfere in a number of
adverse ways with normal calculator operation--they tend to interrupt
the current application or POL in some way and apparently leave the
stack corrupted or not return to it properly, though I believe that's an
unrelated issue.)
--
Travis
Jim Dumas
Nov 8, 2012, 11:30:37 AM11/8/12
to
On Mon, 05 Nov 2012 21:37:26 +0000, Travis Evans wrote:
> Interesting. I actually haven't seen text message alarms for sure fail,
> but then again I haven't used them for anything critical. When the
> calculator is off, alarms usually seem to trigger eventually, but can be
> somewhat late. I haven't investigated the issue very thoroughly, but
> something fishy does seem to go on at times.
>
> (I know program alarms, but not text alarms, interfere in a number of
> adverse ways with normal calculator operation--they tend to interrupt
> the current application or POL in some way and apparently leave the
> stack corrupted or not return to it properly, though I believe that's an
> unrelated issue.)
Just to say that the 50g seems to be dropping interrupts. Almost like
> Interesting. I actually haven't seen text message alarms for sure fail,
> but then again I haven't used them for anything critical. When the
> calculator is off, alarms usually seem to trigger eventually, but can be
> somewhat late. I haven't investigated the issue very thoroughly, but
> something fishy does seem to go on at times.
>
> (I know program alarms, but not text alarms, interfere in a number of
> adverse ways with normal calculator operation--they tend to interrupt
> the current application or POL in some way and apparently leave the
> stack corrupted or not return to it properly, though I believe that's an
> unrelated issue.)
interrupts are turned off (or masked) for too long in the ARM code. So
events are dropped/missed.
That's what I suspect is the problem with the Kinpo OS.
Bart
Nov 8, 2012, 11:41:35 AM11/8/12
to
On Thursday, November 8, 2012 4:30:37 PM UTC, Jim Dumas wrote:
>
>
> Just to say that the 50g seems to be dropping interrupts. Almost like
>
> interrupts are turned off (or masked) for too long in the ARM code. So
>
> events are dropped/missed.
>
>
>
> That's what I suspect is the problem with the Kinpo OS.
>
> --
>
> Jim Dumas
>
As far as I know, the 50g is not Kinpo. It was developed inhouse at HP. There is an emulation layer so the the Saturn code runs on the ARM. Perhaps somewhere there is the problem with masked or missed interrupts.
>
>
> Just to say that the 50g seems to be dropping interrupts. Almost like
>
> interrupts are turned off (or masked) for too long in the ARM code. So
>
> events are dropped/missed.
>
>
>
> That's what I suspect is the problem with the Kinpo OS.
>
> --
>
> Jim Dumas
>
John H Meyers
Nov 14, 2012, 6:58:45 AM11/14/12
to
On 11/8/2012 10:41 AM, Bart wrote:
> As far as I know, the 50g [emulator and internal OS] is not [by] Kinpo.
> It was developed in-house at HP.
All new, replacing Kinpo's original?
(or was the 49G+ Emulator & OS also not by Kinpo?)
Wait for someone who does know, such as TW or ER.
Or look up original articles on the subject,
such as by JYA, who may have explained
all about why the clock & alarms crumped out
when the Saturn (CPU) was replaced by an emulator
(based on ARM processor).
At any rate, the last observations I ever made
about trying to get clock & alarms to work right
on real 49G+ and 50G hardware,
as they once flawlessly did on real HP "Saturn" hardware,
were in the direction of "forget it, they just won't"
Jim Dumas' method, which started this thread,
is to stuff the alarm queue with a bunch of alarms,
30 seconds apart, which he says works for him
(and is in part the same reason why a firing squad
can do a better collective job than a single bad shooter,
or a shotgun is used when hunting birds, rather than a rifle ;-)
[r->] [OFF]
> As far as I know, the 50g [emulator and internal OS] is not [by] Kinpo.
> It was developed in-house at HP.
All new, replacing Kinpo's original?
(or was the 49G+ Emulator & OS also not by Kinpo?)
Wait for someone who does know, such as TW or ER.
Or look up original articles on the subject,
such as by JYA, who may have explained
all about why the clock & alarms crumped out
when the Saturn (CPU) was replaced by an emulator
(based on ARM processor).
At any rate, the last observations I ever made
about trying to get clock & alarms to work right
on real 49G+ and 50G hardware,
as they once flawlessly did on real HP "Saturn" hardware,
were in the direction of "forget it, they just won't"
Jim Dumas' method, which started this thread,
is to stuff the alarm queue with a bunch of alarms,
30 seconds apart, which he says works for him
(and is in part the same reason why a firing squad
can do a better collective job than a single bad shooter,
or a shotgun is used when hunting birds, rather than a rifle ;-)
[r->] [OFF]
Jim Dumas
Nov 14, 2012, 8:39:37 AM11/14/12
to
On Wed, 14 Nov 2012 05:58:45 -0600, John H Meyers wrote:
> Jim Dumas' method, which started this thread, is to stuff the alarm
> queue with a bunch of alarms, 30 seconds apart, which he says works for
> him (and is in part the same reason why a firing squad can do a better
> collective job than a single bad shooter, or a shotgun is used when
> hunting birds, rather than a rifle ;-)
Dear John,
> Jim Dumas' method, which started this thread, is to stuff the alarm
> queue with a bunch of alarms, 30 seconds apart, which he says works for
> him (and is in part the same reason why a firing squad can do a better
> collective job than a single bad shooter, or a shotgun is used when
> hunting birds, rather than a rifle ;-)
You ain't much help.
I have a hpgcc3 modified ROM on the 50g. So thinking I'll do an alarm
system at the ARM level in C to replace the "shotgun" method in the
Saturn emulation.
Interestingly, I did find get the double-alarm method to fail. It seems
to be related to memory use, as the directory structure grew to about 50%
of RAM use, the double-alarm method failed once to date. I have not been
able to do this again. So maybe a garbage collection fixed the issue.
But that's why I'm thinking about a C alternative.
TW
Nov 14, 2012, 9:21:46 AM11/14/12
to
> All new, replacing Kinpo's original?
> (or was the 49G+ Emulator & OS also not by Kinpo?)
Kinpo did the hardware and the underlying OS. The emulator ("Saturnator") was done by people at Hydrix.
> (or was the 49G+ Emulator & OS also not by Kinpo?)
TW
John H Meyers
Nov 17, 2012, 1:58:22 PM11/17/12
to
On 11/14/2012 8:21 AM, TW kindly wrote:
JHM:
along with another "ACO" manager, IIRC)
But if he were solely responsible for the clock and alarms,
it would be a very good bet that they would work correctly,
wouldn't they?
I'm inclined to keep blaming Kinpo for the problems
with clock and alarms, on all HP49G+ and HP50G
(and the HP48Gii?) -- original HP49G (real Saturn) is fine,
including even with the originally last 49G+ ROM,
perhaps even the last minor revision for 50G,
if you can get a 49G file out of it
which doesn't try to replace the 49G "boot block."
Here's a thread from August 2006,
in which JYA supplied some information,
and also indicates not knowing about some details,
which suggests that he is not the author
of the CLKADJ implementation,
which can only adjust the clock by whole seconds:
<http://groups.google.com/group/comp.sys.hp48/browse_thread/thread/f14d115a907b3353&noredirect>
[r->] [OFF]
JHM:
>> All new, replacing Kinpo's original?
>> (or was the 49G+ Emulator & OS also not by Kinpo?)
TW:
>> (or was the 49G+ Emulator & OS also not by Kinpo?)
> Kinpo did the hardware and the underlying OS.
> The emulator ("Saturnator") was done by people at Hydrix.
And "Hydrix" means JYA? (it was his company,
> The emulator ("Saturnator") was done by people at Hydrix.
along with another "ACO" manager, IIRC)
But if he were solely responsible for the clock and alarms,
it would be a very good bet that they would work correctly,
wouldn't they?
I'm inclined to keep blaming Kinpo for the problems
with clock and alarms, on all HP49G+ and HP50G
(and the HP48Gii?) -- original HP49G (real Saturn) is fine,
including even with the originally last 49G+ ROM,
perhaps even the last minor revision for 50G,
if you can get a 49G file out of it
which doesn't try to replace the 49G "boot block."
Here's a thread from August 2006,
in which JYA supplied some information,
and also indicates not knowing about some details,
which suggests that he is not the author
of the CLKADJ implementation,
which can only adjust the clock by whole seconds:
<http://groups.google.com/group/comp.sys.hp48/browse_thread/thread/f14d115a907b3353&noredirect>
[r->] [OFF]
Travis Evans
Nov 18, 2012, 10:47:24 PM11/18/12
to
On Sat, 17 Nov 2012 12:58:22 -0600, John H Meyers <jhme...@nomail.invalid> wrote:
> Here's a thread from August 2006,
> in which JYA supplied some information,
> and also indicates not knowing about some details,
> which suggests that he is not the author
> of the CLKADJ implementation,
> which can only adjust the clock by whole seconds:
> <http://groups.google.com/group/comp.sys.hp48/browse_thread/thread/f14d115a907b3353&noredirect>
Which models/OS versions does this apply to? On my 50g with Rev. 2.15,
> Here's a thread from August 2006,
> in which JYA supplied some information,
> and also indicates not knowing about some details,
> which suggests that he is not the author
> of the CLKADJ implementation,
> which can only adjust the clock by whole seconds:
> <http://groups.google.com/group/comp.sys.hp48/browse_thread/thread/f14d115a907b3353&noredirect>
I ran the following command:
\<< TIME 4096 CLKADJ TIME \>>
and got
21.3955567016
21.3956023437
and then
\<< TIME -4096 CLKADJ TIME \>>
and got
21.4025353393
21.4024882934
\<< TIME -1000 CLKADJ TIME \>>
gave me
21.4439689697
21.4439597534
--
Travis
Travis Evans
Nov 18, 2012, 11:06:58 PM11/18/12
to
On Mon, 19 Nov 2012 03:47:24 +0000 (UTC), Travis Evans
<tra...@ticalc.org> wrote:
> On Sat, 17 Nov 2012 12:58:22 -0600, John H Meyers
> <jhme...@nomail.invalid> wrote:
>> Here's a thread from August 2006, in which JYA supplied some
>> information, and also indicates not knowing about some details, which
>> suggests that he is not the author of the CLKADJ implementation,
>> which can only adjust the clock by whole seconds:
>> <http://groups.google.com/group/comp.sys.hp48/browse_thread/thread/f14d115a907b3353&noredirect>
>
> Which models/OS versions does this apply to? On my 50g with Rev. 2.15,
> I ran the following command:
>
> \<< TIME 4096 CLKADJ TIME \>>
>
> and got
>
> 21.3955567016
> 21.3956023437
[...]
<tra...@ticalc.org> wrote:
> On Sat, 17 Nov 2012 12:58:22 -0600, John H Meyers
> <jhme...@nomail.invalid> wrote:
>> Here's a thread from August 2006, in which JYA supplied some
>> information, and also indicates not knowing about some details, which
>> suggests that he is not the author of the CLKADJ implementation,
>> which can only adjust the clock by whole seconds:
>> <http://groups.google.com/group/comp.sys.hp48/browse_thread/thread/f14d115a907b3353&noredirect>
>
> Which models/OS versions does this apply to? On my 50g with Rev. 2.15,
> I ran the following command:
>
> \<< TIME 4096 CLKADJ TIME \>>
>
> and got
>
> 21.3955567016
> 21.3956023437
On further inspection (because something seemed strange...), it appears
that sub-second CLKADJs initially *appear* to work, but are lost as soon
as the next second hits, which is quite strange and deceptive. I'm
rather annoyed that this whole time I had written routines that assumed
CLKADJ had more resolution, and those routines apparently have actually
done nothing at all. I'm also frustrated that this (and many other
"gotchas" I've had to learn the hard way due to poor documentation) are
not properly documented in the official resources.
I wonder if this could actually be a bug. It would seem that even if
the system clock only has one-second resolution, that the fractional
seconds could simply be saved somewhere and automatically added/
subtracted from queries for the system time, so that one could
effectively still adjust the clock in smaller fractions.
--
Travis
Bart
Dec 7, 2012, 5:44:21 AM12/7/12
to
On Wednesday, November 14, 2012 11:58:49 AM UTC, John H Meyers wrote:
> On 11/8/2012 10:41 AM, Bart wrote:
>
>
>
> > As far as I know, the 50g [emulator and internal OS] is not [by] Kinpo.
>
> > It was developed in-house at HP.
>
>
>
> All new, replacing Kinpo's original?
>
> (or was the 49G+ Emulator & OS also not by Kinpo?)
>
>
>
> Wait for someone who does know, such as TW or ER.
>
>
>
> Or look up original articles on the subject,
>
> such as by JYA, who may have explained
>
> all about why the clock & alarms crumped out
>
> when the Saturn (CPU) was replaced by an emulator
>
> (based on ARM processor).
>
>
Darwin quote:
> On 11/8/2012 10:41 AM, Bart wrote:
>
>
>
> > As far as I know, the 50g [emulator and internal OS] is not [by] Kinpo.
>
> > It was developed in-house at HP.
>
>
>
> All new, replacing Kinpo's original?
>
> (or was the 49G+ Emulator & OS also not by Kinpo?)
>
>
>
> Wait for someone who does know, such as TW or ER.
>
>
>
> Or look up original articles on the subject,
>
> such as by JYA, who may have explained
>
> all about why the clock & alarms crumped out
>
> when the Saturn (CPU) was replaced by an emulator
>
> (based on ARM processor).
>
>
"Ignorance more frequently begets confidence than does knowledge: it is those who know little, and not those who know much, who so positively assert this or that..."
Guilty as charged!! I will indeed do some more research.
0 new messages