NCO Counter Issue

Jack Scarlet

Hello,

I'm fairly new to Propeller programming and have been playing around with counters.

I'm using the following code to generate 46875 hz output and a 12mhz output.

CON

_clkmode = xtal1 + pll16x ' clkfreq = 80 MHz.
_xinfreq = 5_000_000

PUB CounterTest

frqa := 2_516_582 ' FRQA = 46875 * (2^32 / clkfreq)
ctra[30..26] := %00100 ' Set ctra for "NCO single-ended"
ctra[5..0] := 2 ' Set APIN to P2
dira[2]~~ ' Set direction of PIN

frqb := 322_122_547 ' FRQB = 12_000_000 * (2^32 / clkfreq)
ctrb[30..26] := %00010 ' Set ctra for "PLL single-ended"
ctrb[25..23] := 4 ' Set PLLDIV to 4x
ctrb[5..0] := 3 ' Set APIN to P3
dira[3]~~ ' Set direction of PIN

repeat


The problem is when I look at the outputs using my Saleae Logic every so often I see values of
469667 and 467836 hz grouped together.

Is it not posible to generate a stable 46875 hz output using an NCO mode counter, am I doing something wrong, could it be my logic Analyzer or are discrepancies like these normal ?

Cheers
Jack

Kye

Hi, you need to use the PLL with the NCO mode. NCO produces jitter. The PLL will clean that up for you.

Basically, in the PLL mode, you generate the same NCO output, but, then that goes into the PLL which locks onto the average target frequency and is quite stable. I'm not sure you can hit below, however, 500,000 Hz with the PLL mode.

Jack Scarlet

Thanks Kye, I'll have to do some more reading

jmg

Jack Scarlet wrote: »

The problem is when I look at the outputs using my Saleae Logic every so often I see values of
469667 and 467836 hz grouped together.

Is it not possible to generate a stable 46875 hz output using an NCO mode counter, am I doing something wrong, could it be my logic Analyzer or are discrepancies like these normal ?

You should expect some deviation, but not quite that much - what is the sample time of the Logic analyser ?
A logic analyser will introduce additional sampling errors, on top of the 12.5ns quanta the NCO works in.

Assuming those quoted values simply missed a decimal point, we have

80e6/46966.7 = 1703.33449018134125
80e6/46783.6 = 1710.00094050051728
So the average is close, but the spread is larger

A good way to check the stability and jitter nature of the NCO, is to get an expanded/egyptian fraction form

The requested 46875 maps to

80e6/46875 = 1706.66666666666667
ie you divide on average, by 1706 2/3

This is a simple example, but we flip to the Time-domain, to get
Target period is
1/46875 = 2.13333333333333333e-5 ( 1706.66666666666667/80e6 )

This will be made up of building blocks of the two nearest values of

1707/80e6 = 2.13375e-5
1706/80e6 = 2.1325e-5

and this gives 1 cycle of /1706 and 2 cycles of /1707, repeating every 3 cycles
(1*(1706/80e6)+2*(1707/80e6))/3 = 2.13333333333333333e-5

Another way to think of this, is that the edges are snapped to the nearest 12.5ns tine slot.

How much jitter you measure, depends on your gate time, but I would not expect to see values outside of these limits :

80e6/1706 = 46893.3177022274326
80e6/1707 = 46865.8465143526655

These are the two component frequencies, which are averaged to 46875.000, note they are 'off' by -393ppm and +195ppm

If you have a gate time of a multiple of 3 cycles, you will measure 46875.0000Hz, but when the gate time does not divide into the fractional expansion, you will see the 12.5ns snap effect.

taking ~ 100ms, and 4700 cycles, we will measure
1/((1567*(1706/80e6)+3133*(1707/80e6))/(1567+3133)) = 46875.0019479305996
1-ans/46875 = -41.55 ppb, error, when taken over 4700 cycles. ( the more cycles the less this error averages to )

Jack Scarlet

Jmg, thanks for your reply. My analyzer is set at 24mhz sample rate. I think I understand what your saying. So the ideal situation would be to use a crystal and clock frequency that gives an integer result of CLKFREQ / desired output frequency.

jmg

Jack Scarlet wrote: »

Jmg, thanks for your reply. My analyzer is set at 24mhz sample rate.

That explains why you see the ~ 6.66 times worse spread numbers that you did. - but it does show the effect of finite samples.
A 1GHz sample analyzer would show closer to the real prop values.

Jack Scarlet wrote: »

I think I understand what your saying. So the ideal situation would be to use a crystal and clock frequency that gives an integer result of CLKFREQ / desired output frequency.

If you want no jitter artifacts, yes. you need a adder value that can repeat with no fractions, or you have to manually reload/fix the Counter, which effectively disables the adder (or removes the fractional part).

Mark_T

I'm using the following code to generate 46875 hz output and a 12mhz output.

My analyzer is set at 24mhz sample rate.

My bugbear again: "hz" and "mhz" are wrong, the unit is the "hertz" or "Hz", note the case. "MHz" is 10^6 Hz, "mHz" is 10^-3 Hz.

Most but not all units named after people are lower case when written in full, uppercase for the abbreviated version (volt/V, amp/A,
hertz/Hz, henry/H, farad/F, kelvin/K). Most units not named after people are fully lower case (candela/cd, barn/b, metre/m, light-year/ly)

Jack Scarlet

Mark_T wrote: »

My bugbear again: "hz" and "mhz" are wrong, the unit is the "hertz" or "Hz", note the case. "MHz" is 10^6 Hz, "mHz" is 10^-3 Hz.

Most but not all units named after people are lower case when written in full, uppercase for the abbreviated version (volt/V, amp/A,
hertz/Hz, henry/H, farad/F, kelvin/K). Most units not named after people are fully lower case (candela/cd, barn/b, metre/m, light-year/ly)

Thanks Mark, good to know!