Shop OBEX P1 Docs P2 Docs Learn Events
Precise waits — Parallax Forums

Precise waits

average joeaverage joe Posts: 795
edited 2013-11-20 23:54 in Propeller 1
Trying to figure precision waits and having a bit of difficulty. The instruction in bold seems to be the problem. My question is how many clock cycles should I have as the offset. I know I need to subtract something from the delay to compensate for the time the waitcnt takes to calculate. For some reason, the number 384 keeps popping into my head. Any help is greatly appreciated!
CON
  _delay = (_clkfreq * 5) - 1920

PUB Test  |   d       
   outa[_trigger] := 0
   d := cnt
   
   repeat
     [B]waitcnt(d += _delay)[/B]
     dira[_trigger] := 1
     Update(@packet,3000,@timeStamp,@channel)
     dira[_trigger] := 0

Comments

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2013-11-19 00:52
    Used the way you're doing it, you do not need to compensate for instruction overhead. If you want to do something on precise five-second intervals, the delay should simply be clkfreq * 5.

    -Phil
  • average joeaverage joe Posts: 795
    edited 2013-11-19 01:07
    That's what I thought, but I seem to be gaining time. Looks to be about 1/10,000 every 15 seconds (at 64mhz, 4mhz oscillator x 16pll) My clock source should be accurate to +- 10ppm. Is there something I'm missing?
  • BeanBean Posts: 8,129
    edited 2013-11-19 04:06
    Why are you subtracting 1920 from the delay ? That would account for the error you are seeing.

    Bean
  • MagIO2MagIO2 Posts: 2,243
    edited 2013-11-19 08:11
    Is this the whole code? If so, where are your clock settings? If I remember right the clock settings default to fast RC. This is of couse far away from 10ppm.

    Do you overwrite _clkfreq somewhere? _clkfreq is one of the values stored in the first 16 bytes of a propeller binary.
  • average joeaverage joe Posts: 795
    edited 2013-11-19 14:16
    Sorry for being a bit vague, it's by necessity. I am overwriting the clock settings. Here's what I started with :
    CON
     _clkmode=xinput + pll16x 'Clock mode, using crystal and 16X multiplier
     _clkfreq=64_000_000 'Clock frequency
     _delay = _clkfreq
    
    PUB Test  |   d       
       outa[_trigger] := 0
       d := cnt
       
       repeat
         waitcnt(d += _delay)
         dira[_trigger] := 1
         Update(@packet,3000,@timeStamp,@channel)
         dira[_trigger] := 0
    
    Update packet just strips the time stamp from a precision timing source and displays it on my terminal.

    With this bit of code, the count gains 1/10,000 of a second every 14-18 seconds. I was subtracting some clock cycles to try to compensate for this drift. 1920 was around the number of clock cycles that caused me to lose 1/10,000 over a longish period. (40 seconds or so.)

    I started thinking about it last night and I'm beginning to wonder if this the maximum accuracy possible with this clock source (4mhz, x16pll, +- 10ppm). It may be due to connections, stray capacitance / inductance? This is a breadbord test so that might explain some degree. I do see some clock pulses that look suspicious on the LA.
  • Dave HeinDave Hein Posts: 6,347
    edited 2013-11-19 14:30
    1/10,000 of a second every 10 seconds is 1/100,000 of a second per second, or 10/1,000,000 of a second per second. 10/1,000,000 is 10PPM.
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-11-19 16:08
    So, 1/10,000 is 10PPM, and thats 8.64 seconds per day. I have a logger running (but its using the propforth logger not spin) .
    Its been going since September and its off by 9 seconds. So, it drifts in and out, but when it drifts out it, pretty much drift back in later.

    This is in a basement where temperature is stable, the one in the garage drifted around more, but that test ended when I bumped the power supply.

    Does your application require it to be sync'd with a source, or are you just seeing how good you can get it?
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2013-11-19 19:56
    Rather than adjusting _delay, I would go right for the jugular and apply the necessary correction to _clkfreq. That way all the timing in your program will be on the same page.

    -Phil
  • jmgjmg Posts: 15,173
    edited 2013-11-19 21:49
    With this bit of code, the count gains 1/10,000 of a second every 14-18 seconds. I was subtracting some clock cycles to try to compensate for this drift. 1920 was around the number of clock cycles that caused me to lose 1/10,000 over a longish period. (40 seconds or so.)

    I started thinking about it last night and I'm beginning to wonder if this the maximum accuracy possible with this clock source (4mhz, x16pll, +- 10ppm).

    10ppm is reasonably good starting precision for a generic crystal.

    You can trim to better, but expect to need to do that per-crystal,as you chase down the last few ppm.

    Also expect some ppm of wander, with temp and age.

    To go much under 1ppm, you need to move to a TCXO, or use a GPS 1pps as a calibrator, and adjust your Divider value. (I read specs on one today that claimed +/- 11ns, 12mA locked and ~$20, needs antenna )
  • Mark_TMark_T Posts: 1,981
    edited 2013-11-20 05:52
    Definitely sounds like you need a TXCO rated at 1ppm or so. For better performance there are always rubidium frequency standards on eBay!
  • Dave HeinDave Hein Posts: 6,347
    edited 2013-11-20 08:35
    So, 1/10,000 is 10PPM, and thats 8.64 seconds per day.
    1/10,000 is 100PPM. 10PPM is 1/100,000, which is 0.864 seconds per day.
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2013-11-20 10:15
    There are really two separate issues in play.

    A. The accuracy of your computer language.

    pfth can do accuracate delays in the 30 microsecond range and maybe as low as 20 or 15 microseconds... according to the numerical count.

    PASM should be able to precise delays down to much further.

    But only the numbers are precise.. actual time wanders with the stabilty of the oscillator.

    B. The stability of your oscillator... variation is mainly due to changes in ambient temperature.

    A regular crystal is about 3% accuracy due to ambient temperature changes, some are better than that.
    More expensive crystals in ovens are higher stability in the range of hundreds of dollars.
    And you can go much higher if you have deep pockets and care nothing of compact size.

    It get rather silly to chase exceptional timekeeping on Propeller unless you really need it. It is easier to synch with GPS or the internet.
  • Mark_TMark_T Posts: 1,981
    edited 2013-11-20 10:48
    Dave Hein wrote: »
    1/10,000 is 100PPM. 10PPM is 1/100,000, which is 0.864 seconds per day.

    But losing 1/10,000 in 15s is 1/150,000 is 6ppm
  • jmgjmg Posts: 15,173
    edited 2013-11-20 11:57
    A regular crystal is about 3% accuracy due to ambient temperature changes, some are better than that.

    You may want to edit that. A 3% crystal would be sent back as wrongly labeled.
    Crystals are specified in ppm. 50-100ppm is typically the poorest specs.
  • max72max72 Posts: 1,155
    edited 2013-11-20 12:53
    I agree with Loopy.
    For long run stability use someone else's precise clock.
    With gps you have the 1pps signal which is quite tight, as long as you can get a fix signal.
    Moreover not all the gps units handle the 1pps the same way, so it might not be a good solution.
    Internet time is another nice long term clock solution.
    In both cases you rely to the xtal clock, and adjust the time occasionally, in case it fits your requirements...
    Massimo
  • jmgjmg Posts: 15,173
    edited 2013-11-20 13:18
    max72 wrote: »
    With gps you have the 1pps signal which is quite tight, as long as you can get a fix signal.
    Moreover not all the gps units handle the 1pps the same way, so it might not be a good solution.

    ? If it is called 1pps, surely it had pulses once a second ?

    I've seen variances of the leading edge delay from formal exact second, (not usually an issue), and some variances in pulse widths, but they all seem to spec a precise one second cadence.
  • max72max72 Posts: 1,155
    edited 2013-11-20 13:35
    jmg wrote: »
    ? If it is called 1pps, surely it had pulses once a second ?

    I've seen variances of the leading edge delay from formal exact second, (not usually an issue), and some variances in pulse widths, but they all seem to spec a precise one second cadence.

    True, but the delay of the 1pps with respect to GPS time is well defined. I have in mind A1035-H datasheet, but probably many others have similar specs.
    Citing the datasheet:

    Under good signal conditions the 1PPS signal comes between 620ns and 710ns
    after the full GPS system second which is accurately (around 10ns) synchronized to
    UTC. Therefore the 1 second clock can be derived and maintained within around
    90ns under good signal conditions.

    Note: The 1PPS clock accuracy directly depends on the position accuracy! The
    GPS signals travel at the speed of light, therefore a position inaccuracy directly
    translates into 1PPS inaccuracies.

    10 m position deviation ≈ 33 ns 1PPS deviation (typically)
    100 m position deviation ≈ 333 ns 1PPS deviation (typically)
  • jmgjmg Posts: 15,173
    edited 2013-11-20 15:02
    I'm not seeing an example here, of your earlier claim ? :

    Moreover not all the gps units handle the 1pps the same way, so it might not be a good solution.
  • average joeaverage joe Posts: 795
    edited 2013-11-20 18:44
    Thanks guys! You've given me quite a bit to think about. GPS / Internet time sync has been something I've thought about for a while. The problem is most of the time neither will be available, at least not guaranteed. This may change in the future, I'm currently designing the system to be stand alone.

    A bit more information, I am using a TXCO specd at +-10ppm. Later versions will likely switch to +- 10ppb or better. At least I have a good starting point, and have verified my results are within expected specifications. Hopefully I can share more information soon!
  • jmgjmg Posts: 15,173
    edited 2013-11-20 21:14
    ...
    A bit more information, I am using a TXCO specd at +-10ppm.

    You can get 2.5ppm quite cheaply (eg FOX924B) and VCTXCO are slightly more, but VCTXCO allow you to manually trim them.
    (Those will need a small external divider, as 4MHz is less common in TCXO, & tends to be outside the lowest prices)
  • max72max72 Posts: 1,155
    edited 2013-11-20 23:54
    jmg wrote: »
    I'm not seeing an example here, of your earlier claim ? :

    Moreover not all the gps units handle the 1pps the same way, so it might not be a good solution.

    My point exactly, I have difficulty explaining it, sorry.
    The 1pps deviation figures are derived from the specific unit datasheet.
    The 1pps could offer a tighter sync, but it is device dependent.
Sign In or Register to comment.