Reciprocal Counter Demo

13

Comments

  • evanh wrote: »
    ...
    ... You would need a very fast specialized oscilloscope to capture cycle-to-cycle jitter decently. ...
    Note the 20 GS/s at the top. It's a speciality of that scope. I've never used the feature till working the prop2 though.

    EDIT: If you scroll up a little before the linked post, I described how it does that.
    Sorry, Evan. My mistake.

    Kind regards, Samuel Lourenço
  • When I purchased the scope, it was the bottom-end range of Yokogawa's tools. DL-1640 model.

    I really really wanted a 4-channel deep memory scope I could setup inside machinery cabinets, but such tools were so expensive back then. Well before Rigol appeared on the scene. I had put up with a Tektronix for a few years but the lack of deep memory made it near useless for me.

  • jmgjmg Posts: 14,278
    samuell wrote: »
    But how does that translates to jitter? And how one can infer that a source is more jittery than the other, especially when direct measurements prove otherwise (at least concerning cycle-to-cycle jitter)?

    Jitter has many forms, and meanings. It can also mean variance or uncertainty in measurements.
    There is cycle to cycle to jitter that a Scope shows, and the P2 here is a gated counter, that on average lets thru ~12.5 or ~12.99 sysclk edges per gate, but over 100002 gates.
    So that's a longer average.
    On an ideal gated counter, over the 100002 cycles of 10MHz in, that should always give an answer just as stable as the MHz value.
    This number shows how many sysclks actually were gated (seen by P2), over that 10.0002ms window.

    Here, the results show that does not happen. Something is different between the sources. Broadly, the first test varies in the 4th digit, whilst the 2nd one is better, varying in the 5th digit.

    There is a larger variance in gated totals, than expected, and it is different for your 2 sources.
    It may be jitter/variance in duty cycle itself, as notice the captured duty is quite different (not 50.0% in both cases), or it may be the sampling aperture jitter of the FF.
    A 10MHz signal is tough here, but someone might want to use P2 to capture PWM from a SMPS, and 500k~2MHz is common there.
    Adding a Flipflop to force duty to always 50% would be one useful test..


    There will be some fractional ns window, where the pin-check is not cleanly digital.
    Thus my suggestion to clock P2 from a more precise but not locked clock as another test here.
    Note a P2 with a VCTCXO and a trimpot, would make this type of 'almost sync' testing easier to setup.


  • jmgjmg Posts: 14,278
    evanh wrote: »
    Okay, nope, not even close. Attached is a bunch of consecutive densities (states) as reported by Chip's frequency counter program. Doing what JMG did gives about 180 ppm.

    And I think I know why. In the attach screenshot I've increased the interval of full range view to see the jitter narrow again. It's about 1/10th the amount of jitter every 3.9 4.0 us. So that means, in this particular case, the crystal oscillator is stable but the PLL instability is causing very short oscillations back and forth across the ideal.

    The absolute jitter of about 110 ns then fades wrt the long average (10 ms) of the frequency counter.

    Not all jitter types will act that way though. And indeed 110ns / 10ms only equals 11 ppm so the counter is picking up something more.

    Wow, what is the test setup there exactly ? - What PLL settings ?
    wait, I now see a later post....
    evanh wrote: »
    Don't worry, I am abusing the PLL to get that result, pushing it outside its spec and found a particularly bad spot.
    PS: The setting is 20.5 MHz sys-clock with XDIVP = 1. Normally, XDIVP should be something like 4 when this low. This way the VCO in the PLL will be operating 4x faster.
    Ah, yes the PLL will be seriously current starved to get so low, and so you would expect visible modulation effects.
    if you get a final 20.5MHz that suggests a PFD of 500kHz, so that's lower than the ~ /4 modulation you see here ( ~ 5MHz of FM ?)
    Wonder where that 5MHz comes from ?
  • evanhevanh Posts: 8,960
    edited 2019-12-10 - 19:41:12
    It's same software and same settings from last time you commented in the other topic. The software tries to produce a 1 MHz square wave using smartpin mode NCO_FREQUENCY with Y=$8000_0000 and X with closest match rounded down.

    The "modulation" looks to be 4.0 μs period (250 kHz), or 1/80 of crystal. EDIT: And this could be the half wave I guess.

  • jmgjmg Posts: 14,278
    samuell wrote: »
    Plus, can I extract a 10MHz clock generated by the P2, given that it is derived from the PLL, in the same conditions that it is being used by Chip's program?
    That's a good idea.
    Code could set up any other pin in Chip's code to output a signal, but 10MHz and 50% is not going to be easy.
    The 250MHz sysclk he chose here, could give 12 cycles hi and 13 cycles low for 10.00MHz (/25) in a pwm mode.

    Hooking that test point to Fin, I'd expect to give 1200000 gated result every time (48.000%), as it is a sync clock.
  • jmgjmg Posts: 14,278
    evanh wrote: »
    The software tries to produce a 1 MHz square wave using smartpin mode NCO_FREQUENCY with Y=$8000_0000 and X with closest match rounded down.

    The "modulation" looks to be 4.0 μs period (250 kHz), or 1/80 of crystal. EDIT: And this could be the half wave I guess.
    Ah, thanks, I skipped over the time base, and thought that was still 10MHz.
    Asking for 1MHz from 20.5MHz is not going to give a great test case, as it needs to /20/21/20/21 alternating which is 48.78ns of edge wobble just in the NCO effect.

    A PLL PFD of 500KHz could be expected to give a 'go up' alternating with 'go down' correction at 500KHz and that will modulate at 250kHz

  • evanhevanh Posts: 8,960
    edited 2019-12-10 - 20:44:48
    Y=$8000_0000 The square wave is constant regular. It's just a little faster than 1 MHz is all.
  • I've brought up the FFT on the scope. Not sure of it's effectiveness. Here's both a clean 80 MHz sys-clock reference and the dirty 20.5 MHz sys-clock.
    80.0MHz_FFT.PNG
    20.5MHz_FFT.PNG
    640 x 480 - 12K
    640 x 480 - 14K
  • jmgjmg Posts: 14,278
    edited 2019-12-10 - 22:27:33
    evanh wrote: »
    Y=$8000_0000 The square wave is constant regular. It's just a little faster than 1 MHz is all.
    Ah yes, the NCO distracted me.
    Configured that way, you have SysCLK/2/N, and N=10 gives a predicted time of 3.90243us for 4 cycles, which is what your scope shows as the mean, now I look closely at the scales.

  • @cgracey
    @evanh

    I found this thread and tried the code as is. Nothing on my scope, tried three pins, and nothing on the PST. Thanks Chip the code is filling me in.
    I have a fairly good understanding on the process. Studying it.

    But nothing on the scope nor the the PST is there something I'm missint??

    Thanks

    Martin
  • @ersmith

    Howdy, can you tell me why Chip's code did not work as is?

    Thanks
  • @cgracey
    Got nothing with this baud rate, tried others, no joy
    got for a second some gobbley gook but that was it. Nothings on the scope

  • pilot0315 wrote: »
    @cgracey
    Got nothing with this baud rate, tried others, no joy
    got for a second some gobbley gook but that was it. Nothings on the scope

    Are you using PNut or FlexGUI? It was written under PNut. There could be some difference between tools.
  • pilot0315 wrote: »
    @cgracey
    Got nothing with this baud rate, tried others, no joy
    got for a second some gobbley gook but that was it. Nothings on the scope

    loadp2 defaults to 115200 baud. I think FlexGUI uses -b230400 parameter to loadp2. If you want to use faster then -b1000000 will match Chip's baud setting.

    Pin P2 is the measuring input. There is no generated signal so touching the first accessory header with your finger will be enough to get numbers sent to the comport.

    The stuff I did above with the scope was another program with a square wave output.

  • @evanh

    got it thanks
  • @cgracey

    Pnut. @evanh told me about touching the header. Gonna try it.
  • pilot0315pilot0315 Posts: 570
    edited 2020-02-11 - 09:10:44
    @cgracey or @evanh
    cgracey wrote: »
    evanh wrote: »
    Yeah, I corrected it as you were writing that I guess. The point is still valid. Calling it states is worse than periods, IMHO.

    Density is an average. We need a word that is a plural, to express what is being counted.

    clocks
    highs
    periods

    -or-

    time
    density
    quantity

    To a novice like me the time density and quantity makes easy sense to me. Except "frequency" is that the frequency of time between touches to the pins??
    Your serial terminal code is clear to me after @evanh and a couple of others guided me. Learned a lot.
    Thanks to all.
  • evanhevanh Posts: 8,960
    edited 2020-02-11 - 11:32:31
    pilot0315 wrote:
    To a novice like me the time density and quantity makes easy sense to me. Except "frequency" is that the frequency of time between touches to the pins??
    Err, sorry, the input pin is P0 rather than P2. The frequency is of the electrical discharge. One as your finger comes into contact with P0 and the other when it separates again.


    Now, for something more meaningful ... If you have a typical oscilloscope then it'll have a 1 kHz 1 Volt square wave output as a calibration test point. You can hook this up and measure it with the prop2. Two wires: One for GND, the other is the 1 kHz to P0.

    However, for the prop2 to see the 1 Volt it needs a small tweak to the program. Update this one line:
    msr_time	long	%0000_0000_000_1100_000100000_00_10101_0	'msr_pin+0 config
    
  • @evanh


    I will do that thanks
  • Would someone please explain this in plain english for me:



    tx_mode long (round(sysfreq / baud * 65536.0) & $FFFFFC00) + 7 '8N1


    I got the long part but I assume that this is round times sysfreq devided by the baud rate times 65536.0 "where does the 65536.0 come from? Also please explain the anded hex code.

    Is there a link to explain when and how the hex codes are applied?

    Thanks

    @evanh
    I would enjoy a nudge in the right direction
    Thanks
  • jmgjmg Posts: 14,278
    pilot0315 wrote: »
    Would someone please explain this in plain english for me:

    tx_mode long (round(sysfreq / baud * 65536.0) & $FFFFFC00) + 7 '8N1

    I got the long part but I assume that this is round times sysfreq devided by the baud rate times 65536.0 "where does the 65536.0 come from? Also please explain the anded hex code.

    I think the intention is to not lose precision, so items are kept as floats, as long as possible.
    The 65536.0 is 2^16 in floating point, and is equivalent to shift left 16.
    The anded mask, then keeps the wanted shifted bits, and removes the unwanted ones.
    IIRC Chip as some fractional baud support in P2, so the mask is keeping some bits that would be to the right of the decimal point.

  • evanhevanh Posts: 8,960
    edited 2020-03-01 - 01:08:52
    I'll give it go ...
    1 - The fundamental equation is just sysfreq / baud. Everything else, except the +7, is support.

    2 - Round() is doing a type cast from float type to integer type of result of equation within (). It pays to control where each type gets used.

    3 - The * 65536.0 is to scale sysfreq/baud, while still as a float, to be a usable integer or, more precisely, to become a 16.16 fixed-point format from the round() above. Suits async serial smartpin WXPIN config.

    4 - In reality the smartpin X register only needs 16.6 fixed-point, so the ( & $FFFFFC00) is masking off, clearing, the least ten bits. This is an important field allotment for point 5 below.

    5 - And finally, the least five bits of X register are used for specifying word length of the serial shifter. "+ 7" meaning 8 data bits plus a start and stop bit. I could have also used "| 7". Either will combine the two parts correctly when the other part is all zeros in this field.

  • evanhevanh Posts: 8,960
    edited 2020-03-01 - 01:17:24
    Here's an alternative that produces the same outcome
    tx_mode    long (round(sysfreq / baud * 64.0) << 10) | 7
    
  • Thanks @evanh and @jmg .

    I will study this.
  • Yes, it retains some fractional precision that can be directly used by the smartpin serial hardware.
  • evanh wrote: »
    pilot0315 wrote:
    To a novice like me the time density and quantity makes easy sense to me. Except "frequency" is that the frequency of time between touches to the pins??
    Err, sorry, the input pin is P0 rather than P2. The frequency is of the electrical discharge. One as your finger comes into contact with P0 and the other when it separates again.


    Now, for something more meaningful ... If you have a typical oscilloscope then it'll have a 1 kHz 1 Volt square wave output as a calibration test point. You can hook this up and measure it with the prop2. Two wires: One for GND, the other is the 1 kHz to P0.

    However, for the prop2 to see the 1 Volt it needs a small tweak to the program. Update this one line:
    msr_time	long	%0000_0000_000_1100_000100000_00_10101_0	'msr_pin+0 config
    


    I added the code and commented out the original. No square wave. Was using the Propscope.

    Will try again later.
  • pilot0315 wrote: »
    evanh wrote: »
    pilot0315 wrote:
    To a novice like me the time density and quantity makes easy sense to me. Except "frequency" is that the frequency of time between touches to the pins??
    Err, sorry, the input pin is P0 rather than P2. The frequency is of the electrical discharge. One as your finger comes into contact with P0 and the other when it separates again.


    Now, for something more meaningful ... If you have a typical oscilloscope then it'll have a 1 kHz 1 Volt square wave output as a calibration test point. You can hook this up and measure it with the prop2. Two wires: One for GND, the other is the 1 kHz to P0.

    However, for the prop2 to see the 1 Volt it needs a small tweak to the program. Update this one line:
    msr_time	long	%0000_0000_000_1100_000100000_00_10101_0	'msr_pin+0 config
    


    I added the code and commented out the original. No square wave. Was using the Propscope.

    Will try again later.

    I tried the program with your change. Attached the Propscope to P0 It appears to ground out P0. Remove scope ground from the ground pin and the program works. With or without scope grounded to the board, nothing shows on the screen.

    Any suggestions??

    Thanks
  • pilot0315 wrote: »
    I tried the program with your change. Attached the Propscope to P0 It appears to ground out P0. Remove scope ground from the ground pin and the program works. With or without scope grounded to the board, nothing shows on the screen.

    Any suggestions??
    Does PropScope have a square wave output? Most likely, without a ground reference, your probe will be acting as an antenna and wiggling pin0 input on the prop2.
  • I had no idea what "reciprocal counter" meant, but I got curious just now and googled this up:
    https://community.keysight.com/community/keysight-blogs/general-electronics-measurement/blog/2018/02/26/how-does-a-frequency-counter-work

    It's a simpler thing than I imagined...
Sign In or Register to comment.