HP48 Clock Variableness

[TomC]

So, as you may have guessed, my concern with the HP48 clock variability is how/why it affects the 'Human Read Clock' [HRC] - I am using this terminology/abbreviation to differentiate it from the '32,768Hz Clock (crystal)' - [32H], or the 'Microprocessor Clock' - [uP] (about 4MHz).

As we all have known, the HRC is not very stable - I believe it is most always slow; losing on the order of 10s of seconds a week. While this may be stable for most of us, I rely on this clock as an alarm, chime and it would be nice to have it a bit better. As we know, the HP48 internally keeps track of 'Ticks' (1/8192 per second), that are likely updated by the uP.

I have in the past measured various machines variance and set an alarm during the night that would apply a 'CLKADJ' command with an appropriately calculated factor that will help this. I have not been able to complete that analysis and plan on redoing it.

But this has gotten me wondering - what are the factors that may affect this lack of accuracy of the HRC?
1. How often the machine is not being used?
2. The clock display active?
3. Port memory? Amount of memory?
4. How often the machine is being used (and how-do memory accesses affect timing)?
5. Is this lack of accuracy constant?
6. Battery Status?
7. Is this level of accuracy related to the difference of the (diagnostic measured) clock speed from 4MHz? (which is always a bit less than 4MHz).

I plan to redo this 'experiment' again shortly - with a few machines, monitoring their accuracy over a week period, calculating the appropriate CLKADJ factor, applying and checking results.

Of course all of these machines are at Standard temperature, Humidity and Pressure, so we can rule that out.

Thank you all again for your thoughts/ideas,
TomC

[Jonathan Busby]

(02-12-2021 06:12 PM)TomC Wrote:  So, as you may have guessed, my concern with the HP48 clock variability is how/why it affects the 'Human Read Clock' [HRC] - I am using this terminology/abbreviation to differentiate it from the '32,768Hz Clock (crystal)' - [32H], or the 'Microprocessor Clock' - [uP] (about 4MHz).

As we all have known, the HRC is not very stable - I believe it is most always slow; losing on the order of 10s of seconds a week. While this may be stable for most of us, I rely on this clock as an alarm, chime and it would be nice to have it a bit better. As we know, the HP48 internally keeps track of 'Ticks' (1/8192 per second), that are likely updated by the uP.

I have in the past measured various machines variance and set an alarm during the night that would apply a 'CLKADJ' command with an appropriately calculated factor that will help this. I have not been able to complete that analysis and plan on redoing it.

But this has gotten me wondering - what are the factors that may affect this lack of accuracy of the HRC?
1. How often the machine is not being used?
2. The clock display active?
3. Port memory? Amount of memory?
4. How often the machine is being used (and how-do memory accesses affect timing)?
5. Is this lack of accuracy constant?
6. Battery Status?
7. Is this level of accuracy related to the difference of the (diagnostic measured) clock speed from 4MHz? (which is always a bit less than 4MHz).

I plan to redo this 'experiment' again shortly - with a few machines, monitoring their accuracy over a week period, calculating the appropriate CLKADJ factor, applying and checking results.

Of course all of these machines are at Standard temperature, Humidity and Pressure, so we can rule that out.

Thank you all again for your thoughts/ideas,
TomC

AFAIK, the system time ( and TIMER2, which controls the system time ) is directly controlled by the crystal oscillator and not by the PLL. I had thought that the crystal oscillator, from my experience at least, was stable, but I guess I was wrong. Do you have any specific measurements of the crystal's amount of deviation from its nominal frequency?

Regards,

Jonathan

[Jonathan Busby]

(02-12-2021 06:12 PM)TomC Wrote:  [snip]
7. Is this level of accuracy related to the difference of the (diagnostic measured) clock speed from 4MHz? (which is always a bit less than 4MHz).

Actually, the nominal CPU clock speed for the Yorke-based Saturn CPU is 3932160Hz . But, as we all know, for some reason this can vary and be as low as 3.68MHz ( Although, I have only seen slower frequencies around 3.69MHz in the wild ).

Regards,

Jonathan

[TomC]

I've got an experiment running. 3 machines, synchronized.
Will check periodically, then setup CLKADJ alarm, etc...

TomC

[Jonathan Busby]

(02-15-2021 12:10 PM)TomC Wrote:  I've got an experiment running. 3 machines, synchronized.
Will check periodically, then setup CLKADJ alarm, etc...

TomC

Neat! Thanks for taking the effort and the time to do this!

Please keep us updated

Regards,

Jonathan

[Christoph Giesselink]

(02-12-2021 07:38 PM)Jonathan Busby Wrote:  AFAIK, the system time ( and TIMER2, which controls the system time ) is directly controlled by the crystal oscillator and not by the PLL. I had thought that the crystal oscillator, from my experience at least, was stable, but I guess I was wrong. Do you have any specific measurements of the crystal's amount of deviation from its nominal frequency?

Regards,

Jonathan

Jonathan is right, the HP48 clock is driven by the 16384Hz TIMER2 directly derived from the 32768Hz crystal. A 32768Hz crystal is a low budget component available in many qualities. Quote: "a typical quartz clock or wristwatch will gain or lose 15 seconds per 30 days" from https://en.wikipedia.org/wiki/Quartz_clock#Accuracy.

I can remember of quartz wristwatches in the 90'ties where the owner replaced the orignal 32768Hz crystal in the hope of better accuray. The existence of the CLKADJ command shows directly, that HP knows about the quality and temperature stabilization of the used crystal.

[TomC]

This is a very interesting thread.

I've long suspected that there is some inaccuracy induced by the OS- perhaps the interrupt structure:
1. A few quick tests I have done in the past show a loss of about 2 seconds per day - the equivalent of about a minute a month.

2. The clocks are always slow.

3. The 'measured' microprocessor clock speed is always 'slow' (relative to 4MHz), and varies (I suppose this could be a measurement issue in the diagnostic code)

Again, these are just suspicions/beliefs.

The bottom line is, after my testing, I'm hoping I'll come up with a CLKADJ constant for each machine.

Regarding the accuracy spec of crystals, I wonder how consistent the resonant frequency is - if it (let's say for instance) 1%, does this mean it is always 'wobbling' within 1% around the center frequency, or stays constant - at a constant freq within 1% of 32768Hz?

I may have (or may acquire) some high precision crystals.
There are other hardware ideas - swapping crystals in different hardware, etc...I could ramble on, but will stop for now.

Thank you all for your attention!

TomC

[Jonathan Busby]

(02-16-2021 07:37 PM)Christoph Giesselink Wrote:  Jonathan is right, the HP48 clock is driven by the 16384Hz TIMER2 directly derived from the 32768Hz crystal.

AFAIK, it's 8192Hz I think you accidentally multiplied the rate by two

Regards,

Jonathan

[Christoph Giesselink]

(02-16-2021 10:43 PM)Jonathan Busby Wrote:  

(02-16-2021 07:37 PM)Christoph Giesselink Wrote:  Jonathan is right, the HP48 clock is driven by the 16384Hz TIMER2 directly derived from the 32768Hz crystal.

AFAIK, it's 8192Hz I think you accidentally multiplied the rate by two

Regards,

Jonathan

Hi Jonathan,

that's correct, the TIMER2 frequency is 8192Hz. I accidentally mixed it up with the scan rate for CPU slow down in Emu48.

[TomC]

Thank you all again for your contributions here.

Just some 'sidenotes' from me:

1. The experiment continues - I have a number of machines that all were synchronized (within a 'secondish') and started on Feb 14. I will gather some data perhaps in a week or so after the start time.

2. I've found that I have some 20ppm 32768 crystals in my stock.

3. I've found that 5ppm crystals are available at a reasonable cost (approx 0.63 USD).

4. A calculation shows that 11 days is about 1million seconds.
This means that a 20ppm crystal could be 'off' by 20 seconds in 11 days, or about 1 minute in 2 months.
-or-
a 5ppm crystal would be 'off' by 5 seconds in 11 days, or about 1 minute in 4 months.
(these calculations are 'rough' - you can check/detail at your convenience! ) This calculation is only based on the crystals frequency accuracy and does not account for frequency stability.

The bottom line is, I don't anticipate that it will be worth my effort to open up these machines to improve the performance to this level.

So, after my ongoing experiment, I will simply set some 'middle of the night' CLKADJ alarms. I may then setup a group time update - Establish a 'main machine', then IR its time to the other N machines.

[I do wonder what some devices used - I do recall VCRs back in the day (in the early 1980s - before the autoadjust feature) that were very accurate - within a minute over a year. I realize that later, the VCRs would 'autoadjust' and get time data from a local broadcaster.]
[I wonder if these VCRs used the powerline frequency - I have heard that this 60Hz source (here in the USA), is extremely accurate over long time periods.]

Cheers,
TomC

[Dave Shaffer]

Yes, those VCRs almost certainly used the 60 power line as the clock reference. In the long run, as you discovered, it is pretty good - the power company can diddle the frequency so the total number of cycles over time is correct.

Here's some more info on the 32768 crystals as used in watches: https://tf.nist.gov/general/pdf/2276.pdf

[TomC]

Good Information; Thanks Dave.

TomC

[TomC]

So, after 1 week (and a few hours), I have measured 6 machines, mostly all Version R (one version L), some 48G+, a 48GX and a 48G.

The ppm error on all is right around 20ppm. It is curious that all were slow. 20ppm seems to be the 'common' variety of crystal that is likely used in 48G.

So, I will either reset these manually, or perhaps write some code that will calculate and store an updated CLKADJ constant.

Thanks all for your feedback and comments,
TomC

[BillBee]

(02-22-2021 12:50 AM)TomC Wrote:  So, after 1 week (and a few hours), I have measured 6 machines, mostly all Version R (one version L), some 48G+, a 48GX and a 48G.

The ppm error on all is right around 20ppm. It is curious that all were slow. 20ppm seems to be the 'common' variety of crystal that is likely used in 48G.

So, I will either reset these manually, or perhaps write some code that will calculate and store an updated CLKADJ constant.

Thanks all for your feedback and comments,
TomC

Good Morning Tom,

The 41CX had a correction factor for the clock. IIRC the manual had a +/- 3 sec/day for the clock as a possible deviation. Does the 48 series have such?

Take Care,
Bill

[TomC]

Hi Bill:

Yes, the HP48 has a 'CLKADJ' command that can adjust the system time - with 1/8192 second resolution. Thus the system does support a very high resolution adjustment - I've fiddled with this, setting a weekly 1am alarm that applies an appropriately calculated adjustment factor.

Regards,
TomC