WP34S - possible to correct RTC in SW?



#2

Hi:

I've noticed the (crystal equipped) clock on my WP-34 has an annoying drift - probably due to some mismatch in the crystal/capacitor/chip combination. Is there any way to correct this in the WP-34 software (e.g. like in the HP41c Time Module)? Perhaps by adding/subtracting a correction factor of "x" seconds at some reasonably easy to detect epoch (e.g. date/time roll-over at midnight, etc.)?

What I'm thinking of is a routine that, when the calculator is turned on, will look to see if the date rolled over and, if so, read and correct the clock, then reset it. Possible? If it would slow the calculator could it be made dependent on a flag (e.g. the stored correction value being non-zero)?

While trying to figure this out, I also noticed that the WP-34S doesn't seem to have an "auto execute" flag for user programs? Or did I miss it somewhere?

(I went through the processor data sheets hoping for a clock correction at the hardware level, but no such luck.)

I've got no good reason for worrying about this, other than it just bugs me :-)

Thanks,
Bob


#3

At some velocity near the speed of light this would be relatively unnecessary :)

In reality, not as easy as the suggestion above due to crystal aging, supply voltage, temperature gradient, and a host of other factors.

#4

Quote:
I've noticed the (crystal equipped) clock on my WP-34 has an annoying drift - probably due to some mismatch in the crystal/capacitor/chip combination.

I'd suspect the crystal being wrong. When you buy a X ppm crystal, you can pretty much guarantee that it will fall in the range X to X - small ppm. Better crystals get sold as smaller ppm for more $.

Quote:
Is there any way to correct this in the WP-34 software (e.g. like in the HP41c Time Module)?

Not in the firmware as it currently stands and there isn't any spare RAM to add the necessary calibration constants. However, it should be possible to write a user program that, when run, fixes the clock based on the time since the last run.

Quote:
While trying to figure this out, I also noticed that the WP-34S doesn't seem to have an "auto execute" flag for user programs? Or did I miss it somewhere?

There isn't one. It didn't seem all that worthwhile given the complete absence of I/O and peripherals. Likewise, we don't have the 41's ON function since we couldn't see a use for it, why wouldn't you want to save your batteries?

Now it wouldn't be all that hard to add either or both of these, so give us a compelling reason or three as to why they are vital.

- Pauli

Edited: 12 July 2011, 11:15 p.m.


#5

Thanks Pauli.

The lowest crystal spec I've seen for 32 KHz crystals is around 20 ppm and I'm seeing significantly greater errors. I suspect it's more likely the caps aren't exactly the correct values consequently pulling the frequency off.

I was tinkering with exactly the program you suggested as a fix when I discovered the lack of auto execute. But running it manually as you suggest may make more sense now that I think about it - why fix it until you need it?

Actually that suggests another approach. Could the correction routine be added to the "TIME" function (i.e. the correction gets run when TIME is called)? I was thinking of writing a user program replacement for TIME to do this, but perhaps it's worth including in the firmware?

I see two ways to do it - either reset the clock with the corrected time on every call, or just compute and store a bias value in EEPROM, and add it to the RTC value when TIME is called (saving the time/effort of actually resetting the clock).

Re: Autorun flag. Well, you can't play all those fabulous tricks on your friends that we used to do back in the 41c/42c days using it :-)

Allen: Well, it IS running fast. If my math is correct all I need to do is to store in a drawer that's moving at 3.5E6 m/s and that would fix it right up....

Cheers,
Bob


Edited: 13 July 2011, 12:01 a.m. after one or more responses were posted


#6

Quote:
Actually that suggests another approach. Could the correction routine be added to the "TIME" function (i.e. the correction gets run when TIME is called)? I was thinking of writing a user program replacement for TIME to do this, but perhaps it's worth including in the firmware?

As I mentioned, there is no RAM left to store the calibration information so this is very unlikely to end up in flash. Putting a hook into the TIME routine to call some user code if it exists would be possible but it hardly seems worthwhile introducing such support for one lone function.


- Pauli


#7

But the correction factor would be stored in flash, no? For instance, if my clock is running 6 sec/day fast, I was thinking that a value of -6 would be stored in flash, along with a date/time string of when RTC was last set ("TIMESet").

Then when TIME was called it would read the RTC and compute the correct time as

Correct time = RTC + (RTC - TIMESet)*correction factor

Then return "Correct time" to the user?

Sorry if I'm being a bit thick here...

Or is the issue there's no way for the user to store the correction factor to flash (i.e that would require writing another function)? If so, perhaps the user could patch the binary with an appropriate value before flashing the calculator?

Bob

Edited: 13 July 2011, 12:26 a.m.


#8

Writing a value to flash requires writing an entire 256 byte page.
Seems a lot to dedicate for one little value. We could possibly squeeze it onto one of the program pages which have a few bytes free at the end but managing this wouldn't be a lot of fun.

So yes it would be possible but we're unlikely to I suspect. Of course, feel free to code the changes and submit them :-) If they are small enough they'd likely go in.


A user program could dedicate a register or two for the purpose and the user would then know not to use that register or registers. Seems like a workable solution to me.


- Pauli


#9

Yep - 256 bytes would be overkill. I'm thinking it only needs 9: one signed byte for the correction factor and 8 for the time/date that the RTC was last set. But if you wind up with a few extra bytes when you're doing something else, perhaps you can keep this in mind?

A user program seems like a good solution and an excellent opportunity for me to figure out how to use PSTO. By using the offset computation approach neither of the constants will have to be rewritten, so it should work well with a program stored in flash.

Thanks very much for the explanations!

Cheers,
Bob

Edited: 13 July 2011, 8:29 p.m.


#10

There are only eight bytes clear at the end of a program segment so a different scheme would be required to sneak the data in there.

- Pauli

Edited: 13 July 2011, 8:51 p.m.


#11

Well...we could drop the seconds (one byte) and the century (one byte) from the standard RTC format, leaving six bytes for the starting time/date, plus one more byte for the correction factor (limiting it to +/-128 sec/day), for a total of seven bytes.

The century can be ignored (there I go, creating a Y3K problem); I don't think the error caused by rounding to the nearest whole minute is enough to worry about, either. Any higher accuracy would probably require keeping a periodic watch on the temperature and calculating a thermal compensation in addition to the fixed drift rate.

I'm using RTC data descriptions in sections 14.5.3 & 14.5.4 of the "AT91SAM7L128/64 Preliminary" data sheet for this, btw.

#12

Quote:
The lowest crystal spec I've seen for 32 KHz crystals is around 20 ppm and I'm seeing significantly greater errors. I suspect it's more likely the caps aren't exactly the correct values consequently pulling the frequency off.

32Khz crystals vary in their required load capacitance. Many crystals have a 6pf load spec, if you're using 18pf capacitors you'll be way off in frequency. Make sure that the crystal and caps match, but even then you'll only be within the manufacturing tolerance of the crystal.

Alternatively, you can try to fit a tiny trimmer cap in place of one of the fixed capacitors, this will allow you to adjust the clock rate. If you have a good frequency counter you can get it near perfect at least for a given ambient temperature.


#13

You're probably right about the mismatch, or it may be due to not getting the crystal, leads or caps exactly lined up right on the board. It's running about 4 sec/day fast - not sure if that's horrible or within specs for the layout.

I do have a frequency counter, but I'm not sure how much luck I'd have installing a trimmer on the tiny pads they put on the board. Have to poke around on Digikey and see what the options are.

Thanks!

Bob


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP-41 Clonix&NoV's SW Update. (For the non-Primer's guys out there... :-) Diego Diaz 21 1,760 11-13-2013, 09:00 AM
Last Post: Ángel Martin
  Correct me if I am wrong Denis Doyon 51 3,390 08-14-2013, 02:53 PM
Last Post: Carey
  Latest Clonix/NoV's SW update. Diego Diaz 5 658 02-15-2013, 12:12 PM
Last Post: Ángel Martin
  HP200LX Connectivity SW Luiz C. Vieira (Brazil) 6 679 11-07-2012, 04:07 PM
Last Post: Luiz C. Vieira (Brazil)
  [WP34S] WP34S firmware on the AT91SAM7L-STK dev kit? jerome ibanes 1 391 10-04-2012, 04:59 PM
Last Post: Paul Dale
  [wp34s] Incomplete Gamma on the wp34s Les Wright 18 1,427 12-06-2011, 11:07 AM
Last Post: Namir
  [wp34s] Romberg Integration on the wp34s Les Wright 2 476 12-04-2011, 10:49 PM
Last Post: Les Wright
  Correct 15C information Tim Wessman 35 2,289 09-06-2011, 08:54 PM
Last Post: Dan W
  NoV-64 SW update (RAM2ROM4) Diego Diaz 0 178 07-17-2010, 09:50 PM
Last Post: Diego Diaz
  hp20b hacking: SW reset problem hugh steers 21 1,520 04-14-2010, 08:08 AM
Last Post: hugh steers

Forum Jump: