PropBasic and RTC

2»

Comments

  • 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
  • Discovery wrote: »
    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.
    Infernal Machine
  • 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.
  • Failure is not an option...it's bundled with the software.
  • Thanks for the information.

    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
  • The Propeller Activity Board clock is under test with 79_999_750.

    Discovery
  • It appears that the Propeller Activity Board clock is running even faster with the change to 79_999_750.

    So, I will run another test with the setting at 80_000_250.

    Discovery
  • 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.

    Discovery
  • why should changing the clock speed of the propeller change the crystal based frequency of the rtc-chip?

    curious

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • msrobots wrote: »
    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.
    In science there is no authority. There is only experiment.
    Life is unpredictable. Eat dessert first.
  • PS - is this Propeller RTC Emulator the object you are using?
    In science there is no authority. There is only experiment.
    Life is unpredictable. Eat dessert first.
  • 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
  • jmgjmg Posts: 12,616
    edited November 24 Vote Up0Vote Down
    Discovery wrote: »
    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 )

    Discovery wrote: »
    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)
  • Discovery wrote: »
    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.
    In science there is no authority. There is only experiment.
    Life is unpredictable. Eat dessert first.
  • ersmithersmith Posts: 2,454
    edited November 25 Vote Up0Vote Down
    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
    
  • Wonderful...I will give it a try.

    Thank you.

    Discovery
  • 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.

    Thank you everyone

    Discovery
  • Discovery wrote: »
    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' ?
    Discovery wrote: »
    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.
  • Very good...

    Thank you,

    Discovery
  • I got it right!
    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
  • Cool...this is good to know.
    Failure is not an option...it's bundled with the software.
Sign In or Register to comment.