The clock gains two seconds a week making the error 114 seconds per year.
My $40 Timex wrist watch is accurate to one minute a year. The wrist watch is kept at a relatively constant temperature due to its location on my wrist.
I am sure that the crystal is temperature sensitive and has xxx parts per million sensitivity. I might be able to rig a miniature temperature sensor and heating element on the crystal and run experiments.
The clock gains two seconds a week making the error 114 seconds per year.
My $40 Timex wrist watch is accurate to one minute a year. The wrist watch is kept at a relatively constant temperature due to its location on my wrist.
I am sure that the crystal is temperature sensitive and has xxx parts per million sensitivity. I might be able to rig a miniature temperature sensor and heating element on the crystal and run experiments.
Discovery
That's well within specs, even better than I have gotten. Just reset the clock every six months.
If the drift is consistent (more or less) then you could also change the number of cycles per second from 80_000_000 to something else. If you're gaining two seconds per week then perhaps 79_999_750 or so would compensate.
But as Publison said, 114 seconds per year isn't bad at all. If you really need more accurate timing then you'll probably need a GPS module.
I have only every used incredibly cheap crystals that were highly affected by PCB capacitance. Usually, I am timing things in the "minutes" order of magnitude. So, 3.3ppm is a dream to me. It is an open-loop system, after all.
why should changing the clock speed of the propeller change the crystal based frequency of the rtc-chip?
curious
Mike
It will not affect an rtc chip clock, but it could affect an rtc object running in a cog if the frequency setting was used in the timing calculation. I suspect that is not the case here.
Since the clock gains two seconds a week (or 2s every 604800s) it might be better to increase the number of cycles counted for incrementing the seconds from 80,000,000 to 80,000,265 counts. That change would need to be made to the rtc object.
Changing the 80_000_000 instruction in Bean's RTC program does not affect the clock time at all. I changed the instruction to 80_004_000 which produced no change in the computed time. The clock continues to run fast.
I don't know the internal construction of the Propeller Chip but it seems to me that the crystal circuit itself needs to have an adjustable component in order to affect the clock time. If so, I could make a PCB that includes this adjustable component or components.
Does anyone know of a tried-and-true method for tweaking the Propeller's crystal?
It appears that changing the 80_000_000 term does not affect the clock speed significantly.
The clock runs fast whether the term is reduced by 250 or increased by 250.
I may make a large change in the term as another test.
Which code are you actually running ?
Note that Bean's example, has 80_000_000 in more than one place, so you will need to adjust all places ( or, recode to use one define, better practice )
I don't know the internal construction of the Propeller Chip but it seems to me that the crystal circuit itself needs to have an adjustable component in order to affect the clock time. If so, I could make a PCB that includes this adjustable component or components.
Does anyone know of a tried-and-true method for tweaking the Propeller's crystal?
Manual adjust of the WAIT adder is your best approach, and with 80M, that's a LSB step adjust of 12.5 parts per billion!
If for some reason, that is not fine enough, the Prop does have 3 settings for Xtal C, 36pF / 26pF / 16pF
You could dither between 36pF and 26pF in a compact loop, to tune / average the oscillator within the kHz the XTal moves, with those C values.
Of course, if what you need is outside that band, you are out of luck.
Another option, is to drop the Xtal, and use a TCXO, if you need guaranteed low ppm levels. (or GPS lock, even better...)
TCXOs are rare/expensive at 5MHz, but they do readily come 19.2MHz, 26MHz etc so you could just run the prop at those speeds (no PLL).
If you are adventurous, and need more MHz than 19/26, Digikey stock NT1612AA-48MHZ-END5173A (clipped sine), which you could try AC coupling to P1 set to highest MHz Xtal option ?
With a TCXO, you can also use the adjust WAIT tune, and that combination should go under 1ppm stability. (even at 19.2MHz, over 1 second LSB adjust /step is 52ppb)
Changing the 80_000_000 instruction in Bean's RTC program does not affect the clock time at all. I changed the instruction to 80_004_000 which produced no change in the computed time. The clock continues to run fast.
I don't know the internal construction of the Propeller Chip but it seems to me that the crystal circuit itself needs to have an adjustable component in order to affect the clock time. If so, I could make a PCB that includes this adjustable component or components.
Does anyone know of a tried-and-true method for tweaking the Propeller's crystal?
Discovery
The actual frequency of the crystal is fixed, although it might change slightly by changing the capacitance value. Better to find and change the number of clocks to count in the RTC code.
I'm not sure which 80_000_000 you changed in Bean's program, but the only one that matters is the one in the waitcnt in the TASK RTC. For completeness you could also change the initialization of clocks just before that, but that'll only affect the phase, not the frequency:
clocks = CNT + 80_000_000 ' this sets the initial clock value for the first second
DO
WAITCNT clocks, 80_000_000 ' this waits 80_000_000 cycles for the next second
If you change the WAITCNT for example to:
WAITCNT clocks, 160_000_000 ' wait 160_000_000 cycles for the next "second"; slows it by 2x
then the clock will run twice as slowly, each "second" displayed will actually be close to 2 seconds of real time. That's way overkill, of course, but a good way to do a sanity check.
Now, to calculate the actual value you want in there, figure out how much you want it slowed by. Suppose your clock is gaining 2 seconds per week, for example. In a week there are 7*24*60*60 = 604800 seconds, but our clock has counted 2 extra, so it's getting 604802 seconds instead. We want to slow it down by a factor of 604802 / 604800, so we want the waitcnt to change from 80_000_000 to (80_000_000 * 604802 / 604800) = 80_000_265:
WAITCNT clocks, 80_000_265 ' wait for the next second
The instruction WAITCNT clocks, 80_000_265 did the trick!
The clock is very close to WWV and over the next few months I will be able to tweak the clock to high accuracy.
Also, Bean's original program that he posted takes anywhere from 5 to 9 seconds to compile, error check, download, and start the clock. So, I wrote a wait loop tied to P0 input and a push button. Now, the program with the time is downloaded but runs the clock program only after the push button is depressed. Now I can start the clock accurately.
Also, Bean's original program that he posted takes anywhere from 5 to 9 seconds to compile, error check, download, and start the clock. So, I wrote a wait loop tied to P0 input and a push button. Now, the program with the time is downloaded but runs the clock program only after the push button is depressed. Now I can start the clock accurately.
Push buttons are somewhat variable, you should be able to download a compiled-time of say 10-15 seconds ahead, then download the code and then wait for the exact time on the PC, and separately pulse DTR to reset exactly, and start 'on time' ?
The instruction WAITCNT clocks, 80_000_265 did the trick!
The clock is very close to WWV and over the next few months I will be able to tweak the clock to high accuracy.
Without a TCXO, a few ppm is the best you can hope for.
If you want high initial accuracy, you could feed in a 1pps signal from a GPS module, and a wait measure of same-edges on that, will give you the exact WAITCNT preload.
Average over 4~10 pulses would let you correctly round to the nearest SysCLK.
Comments
My $40 Timex wrist watch is accurate to one minute a year. The wrist watch is kept at a relatively constant temperature due to its location on my wrist.
I am sure that the crystal is temperature sensitive and has xxx parts per million sensitivity. I might be able to rig a miniature temperature sensor and heating element on the crystal and run experiments.
Discovery
That's well within specs, even better than I have gotten. Just reset the clock every six months.
But as Publison said, 114 seconds per year isn't bad at all. If you really need more accurate timing then you'll probably need a GPS module.
Setting the cycles to 79_999_750 looks good...I will try that.
Also, the chances are fairly good that I may have to make a parameter change in 6 months so the clock will be reset.
Very good.
Discovery
Discovery
So, I will run another test with the setting at 80_000_250.
Discovery
The clock runs fast whether the term is reduced by 250 or increased by 250.
I may make a large change in the term as another test.
Discovery
curious
Mike
It will not affect an rtc chip clock, but it could affect an rtc object running in a cog if the frequency setting was used in the timing calculation. I suspect that is not the case here.
Since the clock gains two seconds a week (or 2s every 604800s) it might be better to increase the number of cycles counted for incrementing the seconds from 80,000,000 to 80,000,265 counts. That change would need to be made to the rtc object.
I don't know the internal construction of the Propeller Chip but it seems to me that the crystal circuit itself needs to have an adjustable component in order to affect the clock time. If so, I could make a PCB that includes this adjustable component or components.
Does anyone know of a tried-and-true method for tweaking the Propeller's crystal?
Discovery
Which code are you actually running ?
Note that Bean's example, has 80_000_000 in more than one place, so you will need to adjust all places ( or, recode to use one define, better practice )
Manual adjust of the WAIT adder is your best approach, and with 80M, that's a LSB step adjust of 12.5 parts per billion!
If for some reason, that is not fine enough, the Prop does have 3 settings for Xtal C, 36pF / 26pF / 16pF
You could dither between 36pF and 26pF in a compact loop, to tune / average the oscillator within the kHz the XTal moves, with those C values.
Of course, if what you need is outside that band, you are out of luck.
Another option, is to drop the Xtal, and use a TCXO, if you need guaranteed low ppm levels. (or GPS lock, even better...)
TCXOs are rare/expensive at 5MHz, but they do readily come 19.2MHz, 26MHz etc so you could just run the prop at those speeds (no PLL).
If you are adventurous, and need more MHz than 19/26, Digikey stock NT1612AA-48MHZ-END5173A (clipped sine), which you could try AC coupling to P1 set to highest MHz Xtal option ?
With a TCXO, you can also use the adjust WAIT tune, and that combination should go under 1ppm stability. (even at 19.2MHz, over 1 second LSB adjust /step is 52ppb)
The actual frequency of the crystal is fixed, although it might change slightly by changing the capacitance value. Better to find and change the number of clocks to count in the RTC code.
clocks = CNT + 80_000_000 ' this sets the initial clock value for the first second DO WAITCNT clocks, 80_000_000 ' this waits 80_000_000 cycles for the next secondIf you change the WAITCNT for example to: then the clock will run twice as slowly, each "second" displayed will actually be close to 2 seconds of real time. That's way overkill, of course, but a good way to do a sanity check.Now, to calculate the actual value you want in there, figure out how much you want it slowed by. Suppose your clock is gaining 2 seconds per week, for example. In a week there are 7*24*60*60 = 604800 seconds, but our clock has counted 2 extra, so it's getting 604802 seconds instead. We want to slow it down by a factor of 604802 / 604800, so we want the waitcnt to change from 80_000_000 to (80_000_000 * 604802 / 604800) = 80_000_265:
Thank you.
Discovery
The clock is very close to WWV and over the next few months I will be able to tweak the clock to high accuracy.
Also, Bean's original program that he posted takes anywhere from 5 to 9 seconds to compile, error check, download, and start the clock. So, I wrote a wait loop tied to P0 input and a push button. Now, the program with the time is downloaded but runs the clock program only after the push button is depressed. Now I can start the clock accurately.
Thank you everyone
Discovery
Push buttons are somewhat variable, you should be able to download a compiled-time of say 10-15 seconds ahead, then download the code and then wait for the exact time on the PC, and separately pulse DTR to reset exactly, and start 'on time' ?
Without a TCXO, a few ppm is the best you can hope for.
If you want high initial accuracy, you could feed in a 1pps signal from a GPS module, and a wait measure of same-edges on that, will give you the exact WAITCNT preload.
Average over 4~10 pulses would let you correctly round to the nearest SysCLK.
Thank you,
Discovery
Due to the particular crystal and board capacitance on my Propeller Activity Board,
the instruction WAITCNT clocks, 80_000_600 did the trick! The clock was slowed just enough to make the time very accurate for my application.
Thank you all for the help.
Sincerely,
Discovery