HP50G - Alarm does not always wake up the calculator

[MaP]

Hello *!

I am using the alarm feature of the HP50G and I found, that an elapsed
alarm does not always wake up the calculator.

Only sometimes the alarm wakeup (+message +sound) is executed at
the right time.

If the calculator misses the wakeup time it starts the alarm program
immediately at the next manual turn on.

I'm using ROM version HP50-C Rev.2.09, but the Problem was already
existing at ROM 2.08.

In this Newsgroup I found some statements mentioning problems like this.
But I couldn't find a solution or any outlook, how or when this bug will
be solved.

a) Will there be a new ROM code solving this?
b) Has the hardware to be repaired/modified?
c) Is there someone working on this topic?

Best Regards,
Marko

[Irl]

I have had this problem, too. I wondered if it was because of how I
turn the calculator off -- what method do you use? I want to avoid
having the calculator turned on by an accidental key-press of the ON
button (I carry it with me on my belt and sometimes this might
happen). So I run a program containing this loop:
DO OFF WAIT UNTIL 61.1 == END
which will turn it off again unless a specific key is pressed.
Are you using something like this, or do you just turn it off via the
ON key?
Irl

I usually turn the calculator off via a program which executes OFF and
whose next step checks for a key-press; if the key-press is anything

[Heiko Arnemann]

You may use bugzilla
http://bugs.hpcalc.org/
to report your findings.

best regards
Heiko

"MaP" <???> schrieb im Newsbeitrag
news:32fa8$47921a2b$557f2cdd$19...@news.inode.at...

[MaP]

Thank you for the hint: I have submitted the bug.
BR, Marko

Heiko Arnemann schrieb:

[MaP]

> I have had this problem, too. I wondered if it was because of how I
> turn the calculator off -- what method do you use? I want to avoid
> having the calculator turned on by an accidental key-press of the ON
> button (I carry it with me on my belt and sometimes this might
> happen). So I run a program containing this loop:
> DO OFF WAIT UNTIL 61.1 == END
> which will turn it off again unless a specific key is pressed.
> Are you using something like this, or do you just turn it off via the
> ON key?
> Irl
>
>
>
> I usually turn the calculator off via a program which executes OFF and
> whose next step checks for a key-press; if the key-press is anything

Hello!

I am using the CST Menu: "Off" Soft-Button:

Both ways show the problem:
a) { {"OFF" <<OFF>>} }
b) { {"OFF" OFF} }

BR, Marko

[Irl]

Dear Marko,
The bug has some interesting behavior: often, if the alarm doesn't
occur when it was supposed to, it will occur exactly one hour later --
or sometimes one hour and 59 seconds. If you have seen similar
effects, it might be worth mentioning as a hint to whomever might be
trying to isolate the problem.
Yours,
Irl

[JYA]

On 2008-01-22 05:18:45 +1100, "Heiko Arnemann" <Heiko.A...@gmx.de> said:

> You may use bugzilla
> http://bugs.hpcalc.org/
> to report your findings.
>
> best regards
> Heiko

I've asked Kinpo to fix this bug or even investigate it in their OS for
years ..

Good luck....

--
They who would give up an essential liberty for temporary security,
deserve neither liberty or security (Benjamin Franklin)

[John H Meyers]

On Wed, 23 Jan 2008 21:27:56 -0600, Irl wrote:

> The bug has some interesting behavior: often, if the alarm doesn't
> occur when it was supposed to, it will occur exactly one hour later --
> or sometimes one hour and 59 seconds. If you have seen similar
> effects, it might be worth mentioning as a hint
> to whomever might be trying to isolate the problem.

The problem is, that the only person who once was trying
took a nap and set the alarm to wake up... ;-)

-[ ]-

[Irl]

On Jan 24, 2:52 am, JYA <nos...@nospam.blah> wrote:

> On 2008-01-22 05:18:45 +1100, "Heiko Arnemann" <Heiko.Arnem...@gmx.de> said:
>
> > You may use bugzilla
> >http://bugs.hpcalc.org/
> > to report your findings.
>
> > best regards
> > Heiko
>
> I've asked Kinpo to fix this bug or even investigate it in their OS for
> years ..
>
> Good luck....
>
> --
> They who would give up an essential liberty for temporary security,
> deserve neither liberty or security (Benjamin Franklin)

Please note, this bug is new in the 50g compared to the 48GX. (I don't
know about the 49). I used the alarm functionality in the 48GX for
years (maybe a decade?) without ever seeing the problem, but I noticed
it within a week on the 50g. Is that consistent with the "Kinpo"
comment? (I'm not conversant with the way the various layers of OS and
emulation play together, nor where they come from.)--Irl

[JYA]

Hi

On 2008-01-25 22:35:43 +1100, Irl <ir...@mindspring.com> said:
>
> Please note, this bug is new in the 50g compared to the 48GX. (I don't
> know about the 49). I used the alarm functionality in the 48GX for
> years (maybe a decade?) without ever seeing the problem, but I noticed
> it within a week on the 50g. Is that consistent with the "Kinpo"
> comment? (I'm not conversant with the way the various layers of OS and
> emulation play together, nor where they come from.)--Irl

There isn't any Kinpo OS in the 48gx and 49g. So alarms work perfectly
on those machine.
The problem only happens on ARM-based calculator

one issue is the lack of 8192Hz timers

[Irl]

On Jan 25, 12:09 pm, JYA <nos...@nospam.blah> wrote:
> Hi
>

The odd thing is that sometimes the alarms happen when they're
supposed to, and sometimes not. Is there anything about the way the
alarms are set that could have an effect on whether they will go off
on time?
Irl

[BartdB]

On Friday, January 25, 2008 5:09:52 PM UTC, JYA wrote:
> Hi

>

> There isn't any Kinpo OS in the 48gx and 49g. So alarms work perfectly
> on those machine.
> The problem only happens on ARM-based calculator
>
> one issue is the lack of 8192Hz timers
>
>
> --
> They who would give up an essential liberty for temporary security,
> deserve neither liberty or security (Benjamin Franklin)

The lack of 8192Hz timers????

Does the 50g not have a Samsung S3C2410 Processor?
http://www.arm.com/markets/embedded/hewlett-packard-hp-50g-scientific-calculator.php

From the S3C2410 datasheet:
RTC (Real Time Clock)
· Full clock feature: second, minute, hour, date,
day, month, and year
· 32.768 KHz operation
· Alarm interrupt
· Time tick interrupt

and guess what 32768 / 4 =?

It seems to me the HP team were negligent in their specification and implementation. A little though and investigation in the planning stages of the emulation would have gone a long way. Oh sorry, I forget, that would mean some form of development process, something that HP calculator development doesn't want to make time for (see interaction between Tim Wessman and myself (Bart (UK)) on 22/23 June 2010 in http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv019.cgi?read=168696).

[Han]

An 8192 timer could be used to create a 32.768KHz timer by sending an special signal (interrupt) every 4th interrupt. However, while 32768 / 4 = 8192, you cannot use a larger clock to emulate a smaller one. If the frequency is 32.768 KHz, then how exactly do you propose that they actually produce a quarter of a cycle? It's as if you were insisting that there is some obvious way to measure time accurately to within 1/4 of an hour on your digital clock that only shows time by the hour. Or am I missing something?

[Han]

> An 8192 timer could be used to create a 32.768KHz timer by sending an special signal (interrupt) every 4th interrupt. However, while 32768 / 4 = 8192, you cannot use a larger clock to emulate a smaller one. If the frequency is 32.768 KHz, then how exactly do you propose that they actually produce a quarter of a cycle? It's as if you were insisting that there is some obvious way to measure time accurately to within 1/4 of an hour on your digital clock that only shows time by the hour. Or am I missing something?

Never mind -- it is I who has things backwards!

[Leviatan]

Han nos ha comentado:

> An 8192 timer could be used to create a 32.768KHz timer by sending an special
> signal (interrupt) every 4th interrupt. However, while 32768 / 4 = 8192, you
> cannot use a larger clock to emulate a smaller one. If the frequency is
> 32.768 KHz, then how exactly do you propose that they actually produce a
> quarter of a cycle? It's as if you were insisting that there is some obvious
> way to measure time accurately to within 1/4 of an hour on your digital clock
> that only shows time by the hour. Or am I missing something?

You are missing a lot... :-)

In fact, you are reversing the ideas. With a 32 khz clock you can
perfectly create an 8 khz signal, taking, as you say, only one tick
from each 4... is the opposite that cannont be done (at least not so
easily).

--
Un saludo,
Alberto

[tomcee]

On Saturday, January 19, 2008 10:43:35 AM UTC-5, MaP wrote:
> Hello *!I am using the alarm feature of the HP50G and I found, that an elapsed alarm does not always wake up the calculator.Only sometimes the alarm wakeup (+message +sound) is executed at the right time.If the calculator misses the wakeup time it starts the alarm program immediately at the next manual turn on.I'm using ROM version HP50-C Rev.2.09, but the Problem was already existing at ROM 2.08.In this Newsgroup I found some statements mentioning problems like this. But I couldn't find a solution or any outlook, how or when this bug will be solved.a) Will there be a new ROM code solving this? b) Has the hardware to be repaired/modified? c) Is there someone working on this topic?Best Regards,Marko

Does this functionality work in ANY version of the HP50G firmware? I was not aware that this bug existed in the 50G.

I use 48G units for a number of home automation functions and was planning on moving it to a 50G, but if the alarms are really non-functional I will have to continue using the vintage units. Shame!!! ! !!!!

TomC

[Joe Horn]

On Saturday, February 1, 2014 9:36:01 AM UTC-8, tomcee wrote:
> Does this functionality [alarms] work in ANY version of the HP50G firmware?

> I was not aware that this bug existed in the 50G.

No, it does not work in any version of the 50g. Nor in the 49g+, which was also ARM-based. It works ok in the 48 series and the 49G, because those are Saturn-based.

To be more precise, it DOES work in the 50g... MOST of the time... but not reliably. Once in a while the ARM-based models read the clock incorrectly, and nobody knows why, even though many hypotheses have been suggested over the years.

One easy way to see the 50g misread the clock is to write a program that starts with MEM DROP and then has a whole bunch of TICKS in a row. The more the better. Then wrap them in a list and perform a DeltaLIST. You'll *SOMETIMES* see evidence that one of those TICKS values is LESS than the one BEFORE it, as if time ran backwards for a very brief moment. I'm quite certain that this occasional misreading of the clock is what causes the alarms to occasionally fail to activate.

The HP-75 had a bad clock bug that occasionally returned incorrect times, seemingly at random, but they finally figured out what the cause was. It only happened when the internal clock "ticked" (changed from one clock value to the next) DURING a clock read. When that happened, the first digit(s) that were read from the clock were of course from the pre-tick time, and the subsequent digit(s) were from the post-tick time. When those two pieces were put together, it yielded an incorrect time. If it happened exactly at the top of the hour, the time returned could be off by as much a one hour.

The HP-71B avoided that problem by always reading the clock twice in a row, and if they differed (which meant that the clock must have ticked during one of those clock readings), then it read the clock a third time (too soon after the previous tick for the next tick to occur) and returned that value. Very clever, those Titan programmers.

I doubt that the 49g+/50g clock bug has the same cause, because if it did, Jean-Yves Avenard would have debugged it many years ago using the same trick as the HP-71B.

[DavidM]

Hey Joe -

I ran into the issue of the 50g clock stepping backwards while working on a stopwatch library a while back. On my 50g, it actually happens quite frequently. To test it, I created a small Saturn loop to compare successive clock reads (source: GetTimChk) and found that the tick count stepped backwards about 100 times/second, roughly 32-38 ticks per event.

I don't have the figures in front of me, but my 49g+ reported different results. The numbers for both units changed noticeably with temperature variation and (I believe) battery condition.

My guess was that the ARM O/S must be doing some kind of on-the-fly correction to emulated clock tick values in an effort to sync things up to the RTC of the CPU, which of course only offers 1-second resolution.

It's not difficult to envision how this could really screw up the "wake up" process if it wasn't originally designed to accommodate the possibility of a jittery clock.

[tomcee]

On Saturday, February 1, 2014 10:59:48 PM UTC-5, Joe Horn wrote:

> On Saturday, February 1, 2014 9:36:01 AM UTC-8, tomcee wrote: > Does this functionality [alarms] work in ANY version of the HP50G firmware? > I was not aware that this bug existed in the 50G. No, it does not work in any version of the 50g. Nor in the 49g+, which was also ARM-based. It works ok in the 48 series and the 49G, because those are Saturn-based. To be more precise, it DOES work in the 50g... MOST of the time... but not reliably. Once in a while the ARM-based models read the clock incorrectly, and nobody knows why, even though many hypotheses have been suggested over the years. One easy way to see the 50g misread the clock is to write a program that starts with MEM DROP and then has a whole bunch of TICKS in a row. The more the better. Then wrap them in a list and perform a DeltaLIST. You'll *SOMETIMES* see evidence that one of those TICKS values is LESS than the one BEFORE it, as if time ran backwards for a very brief moment. I'm quite certain that this occasional misreading of the clock is what causes the alarms to occasionally fail to activate. The HP-75 had a bad clock bug that occasionally returned incorrect times, seemingly at random, but they finally figured out what the cause was. It only happened when the internal clock "ticked" (changed from one clock value to the next) DURING a clock read. When that happened, the first digit(s) that were read from the clock were of course from the pre-tick time, and the subsequent digit(s) were from the post-tick time. When those two pieces were put together, it yielded an incorrect time. If it happened exactly at the top of the hour, the time returned could be off by as much a one hour. The HP-71B avoided that problem by always reading the clock twice in a row, and if they differed (which meant that the clock must have ticked during one of those clock readings), then it read the clock a third time (too soon after the previous tick for the next tick to occur) and returned that value. Very clever, those Titan programmers. I doubt that the 49g+/50g clock bug has the same cause, because if it did, Jean-Yves Avenard would have debugged it many years ago using the same trick as the HP-71B.

Very disappointing. In my mind, an Alarm function that does not function 100% of the time is NOT an Alarm function. One would certainly not purchase an alarm clock if it did not function 100% of the time. I've noticed that HP does not mention the alarm function in its specifications. In the meantime, I will stay with the old trusty 48 machines for alarm functionality.

TomC

[Rocky]

I think it's rather clever. Every HP employee has a good
reason to be late for work. "Gee, Boss, I used the alarm on
my 50g." What's that saying? It's not a bug, it's a
feature.

[Raymond Del Tondo]

"tomcee" <tomcees_c...@yahoo.com> schrieb im Newsbeitrag
news:d491a16b-972d-418d...@googlegroups.com...

>In the meantime, I will stay with the old trusty 48 machines for alarm functionality.
>

You could even limit the suffering of the relatively slow HP 48 UI by trying SpeedUI
for the HP 48G Series;-)

SCNR

Ray

[Mario Lohajner]

Hello,
-please don't be very disappointed
-here's why

Windows CE has a long history on ARM/Embeded platform,
alarms have been somewhat quirky all the way from early versions up to 6.0
and 6.1
consider the budged and man-hour power the windows CE was developed with
compared to
much lower production cost of HP Calculator.

I'm sure you encountered many problems with ARM platform so far:
-you internet router got stuck
-your wireless access point (same thing)
-your digital camera got stuck
-ARM tries very much in sence of power saving
-many functional blocks of the processor/microcontroller are turned off or
clocked down when not in use
-also ARMs are very configurable (hardware pins can work in a couple of
ways)

Now
-when series of events (going to idle mode or such) occur on unpredicted
timeschedule it is possible that
some blocks get misconfigured or simply stuck,
-timer may also be "voulnerable" because of switching from low power "idle
mode" to "full speed" are ometimes occuring
on every keypress (depending on the rate you type) then there are clock
manipulations by software and so on...
Ofcourse these things are very hard to reproduce and debug.

From the economical point of view you can't delay your product until it's
100% right because it would take too much money and time.
Take cars for example... if we waited for a car to be perfect
(powerfull,clean, silent, ecological, economical) we'd wait 100+ years and
we are still not there :-) Yet car industry turned unbelivable ammound of
money and is bringing new inventions and improvements year after year...

Long story short :-)
-if you used it much during the day and want to be sure that everything is
right when you go to sleep :-)
-take a paper clip, use the reset hole to do a "hard" restart
-this will reboot, reconfigure, reinitialize everything properly and it will
wake you up in the morning :-)

Also when doing serious tourture with programming, reseting, restarting,
reprogramming or such, do a hard reset when
putting it away for the day.
You may notice better battery lifetime that way because 49G+/50G tends to
"forget" to go to idle mode from time to time.
By hard-resetting it you help it remember all that "little thigs" it must do
:-)

manjo
http://fly.srk.fer.hr/~manjo

[BartdB]

And so we are encouraged to accept the mediocre. No longer should we demand our providers to strive for excellence. They are neither hot nor cold, but lukewarm.

(Note: with "hot" & "cold" I do not mean good or bad, but rather the desire & effort to reach maximums (i.e. the best that can be done), without which we are left dangling halfway).

[Mario Lohajner]

> And so we are encouraged to accept the mediocre. No longer should we
> demand our providers to strive for excellence. They are neither hot nor
> cold,
> but lukewarm.

> (Note: with "hot" & "cold" I do not mean good or bad, but rather the
> desire & effort to reach maximums (i.e. the best that can be done),
> without which
> we are left dangling halfway).

Well i hear you...
(meaning i do agree with you ... absolutely we should strain for the better)
i honestly belive HP calculator people do give their best to make the best
product.
"the best it can be at the given time", i think...

Because, what's the "maximus" to reach?
How do i know i'm there?

Most of the things running in this world are far less than 50% efficient,
and doing so for
hundreds of years.
50% in a lot of cases means "random coincidence"

As we go along with the progress, technologies coming and going fast,
i belive there is always a shortage of time... and then there are 2 sides of
the development:

There are engeneers who'd like to make it right but always demanding "just a
little bit more time" (and money), and
traders, economy, managers, who'd want to see the product marketed and
investment multiplied (by milions if possible).

I'm not reinventing the obvious (economy) here... i just figure...
this is something we are living with, so, why not accept it and we'll be
less dissapointed instantly.

There are workarounds of may kinds,
and then there are things and devices that need some care from time to time.

HP calculators are no exception in this regard,
-those to need to be outwitted and a bit of care

manjo
http://fly.srk.fer.hr/~manjo

[Leviatan]

A Mario Lohajner se le ha ocurrido que:

> Well i hear you...
> (meaning i do agree with you ... absolutely we should strain for the better)
> i honestly belive HP calculator people do give their best to make the best
> product.
> "the best it can be at the given time", i think...
>
> Because, what's the "maximus" to reach?
> How do i know i'm there?

It is difficult to define this limit... regarding calculators, you
just have to compare the retail prices for old and new products. The
original HP35 was sold for 395$ in 1972; that's 2200$ today. HP41C was
sold for about 300$ in 1980; that is about 850$ today and, finally,
HP42S was sold for 120$ in 1988, that is 240 today. HP35S is sold today
for 43 bucks in amazon. I'm surprise some company can produce this,
quite decent, product for such a price and still earn some money.

Imagine you could design (and sell) a calculator today with a price tag
of 2200$. What do you want? Double shot keys? real metal bezel and/or
front plate? Shapphire glass? Gold trimming?

--
Un saludo,
Alberto

[Travis Evans]

On Sat, 1 Feb 2014 19:59:48 -0800 (PST), Joe Horn <joe...@holyjoe.net> wrote:
> On Saturday, February 1, 2014 9:36:01 AM UTC-8, tomcee wrote:
>> Does this functionality [alarms] work in ANY version of the HP50G firmware?
>> I was not aware that this bug existed in the 50G.
>
> No, it does not work in any version of the 50g. Nor in the 49g+,
> which was also ARM-based. It works ok in the 48 series and the 49G,
> because those are Saturn-based.
>
> To be more precise, it DOES work in the 50g... MOST of the time... but
> not reliably. Once in a while the ARM-based models read the clock
> incorrectly, and nobody knows why, even though many hypotheses have
> been suggested over the years.

I too have noticed this. I have been playing with a program I developed
which reads the clock a large number of times per second in the course
of its operation, and every once in a great while I'll notice an odd
jump forward or even backward in the clock... but not often.

But what angers me even more than this or the unreliable alarms and the
keyboard "busy bug" or the random miss of a "keyboard up" event (so you
end up scrolling or even backspacing your entire input) is the fact that
the calculators HARD LOCK every now and then. I now have two HP
50g's--one I bought a few years back and another I bought more recently.
They both exhibit this. It's fairly infrequent but totally random. It
could happen three times in one day, or it could be a few months before
it happens again. I use both very heavily, so maybe that's the reason I
encounter this so often and no one else seems to have reported it.
Every couple of weeks or so, when the calculator is in power-on idle
state (but never while the CPU is actively running), it will just lock
up. Totally; no [ON]+C or anything. I have to pull the batteries or
press the reset button. Fortunately I've never lost Port 0 or HOME due
to this, but it still wipes the stack and whatever you were working on
in an editor session. I've had much cheaper calculators that don't
constantly crash or lock up randomly like this. This is not acceptable.

I feel it's inexcusable that HP seemingly ignores such severe flaws and
has refused to fix them in the 49g+/50g line for this long.

I'd love to see someone develop a software workaround, if one is
possible. But I fear that it could perhaps be a *hardware* fault
(perhaps in interrupt handling or elsewhere).

--
Travis

[Travis Evans]

On Tue, 11 Feb 2014 02:06:39 +0100, Mario Lohajner <ma...@server.com> wrote:
>
> From the economical point of view you can't delay your product until it's
> 100% right because it would take too much money and time.
> Take cars for example... if we waited for a car to be perfect
> (powerfull,clean, silent, ecological, economical) we'd wait 100+ years and
> we are still not there :-) Yet car industry turned unbelivable ammound of
> money and is bringing new inventions and improvements year after year...

That's all well and good when they actually improve things with time.
But the 49g+/50g have been out for how many years now, and these severe
flaws haven't even been remotely been fixed, nor even so much as a
reasonable workaround been offered by HP? Have they even acknowledged
them at all?

> Long story short :-)
> -if you used it much during the day and want to be sure that everything is
> right when you go to sleep :-)
> -take a paper clip, use the reset hole to do a "hard" restart
> -this will reboot, reconfigure, reinitialize everything properly and it will
> wake you up in the morning :-)

I'm not convinced this would guarantee anything. The malfunctions
appear more or less at random, intermittently. It seems just as easy
for them to happen five minutes after a hard reset as five days or five
weeks.

--
Travis

[Mario Lohajner]

> Long story short :-)
> -if you used it much during the day and want to be sure that everything is
> right when you go to sleep :-)
> -take a paper clip, use the reset hole to do a "hard" restart
> -this will reboot, reconfigure, reinitialize everything properly and it
> will
> wake you up in the morning :-)

> I'm not convinced this would guarantee anything. The malfunctions
> appear more or less at random, intermittently. It seems just as easy
> for them to happen five minutes after a hard reset as five days or five
> weeks.

Hello

Just try it a couple of times, i'm sure it will work:
-setup your alarms as you normaly do
-the last thing you do when putting the Calculator away for the night, hit
the reset with a paper clip on the back

NOTE:
-reset won't erase anything from the memory
-it will just hardware restart and reboot the cpu/system
-"clean boot" will make sure everything is properly configured and running
normaly

regards
manjo
http://fly.srk.fer.hr/~manjo