NEO-7M - output frequency issue

[iMo]

As there are people using the cheapo ebay NEO-7M modules for generating 0.25Hz-10MHz frequencies (off the 1pps pin) here are some measurements how the Period of the output signal looks like.
Measurements done with a diy system, still some measurement jitter inside (<100ps rms), subject to an improvement..
The measurement confirms some concerns on a "large jitter" with 10MHz freq people try to use as a cheapo standard.
Based on my current understanding the frequencies which are not 48MHz/integer are a "nogo".

PS: The vertical scale is the sample's "period in picoseconds", the horizontal is the sample number.
Around 1000 samples/sec.

[borghese]

Which is the vertical scale?

[iMo]

The vertical scale is the sample's "period in picoseconds", the horizontal is the sample number. Sampling period about 1ms.

[edpalmer42]

What don't you like about those results?  I'm not seeing anything that looks out of line.

A bare GPS receiver will always have jitter on the timing output.  The magnitude of the jitter is related to the clock speed of the internal processor and the state of the ionosphere at the current moment.  The spec for the NEO-7N timing receiver is 30 ns RMS.  The NEO-7M doesn't even have a jitter spec.  Old GPS receivers had jitter specs as high as 1 us on the 1 PPS output, yes, microsecond!

If you have the numerical data that you used to create the graphs, calculate the average value of the period.  You should find that the result is really, really close to the correct value.  The longer you collect data, the closer the average will get.

The jitter coming out of the GPS receiver is the reason that GPSDOs exist.  The disciplined oscillator filters out the jitter and gives you a clean(er) signal.

[iMo]

What don't you like about those results?  I'm not seeing anything that looks out of line.

The peak-peak jitter with 2 and 12MHz outputs is ~2ns, while with 7 and 10MHz it is ~40ns. That is something interesting, isn't it?

[edpalmer42]

What don't you like about those results?  I'm not seeing anything that looks out of line.

The peak-peak jitter with 2 and 12MHz outputs is ~2ns, while with 7 and 10MHz it is ~40ns. That is something interesting, isn't it?

Okay, I'll agree that it's interesting.  Since it's a navigation receiver rather than a timing receiver, the timing output is more of an afterthought than a feature.  With no jitter spec for the timing output it is what it is.  It could even change from one firmware version to another.    It's unfortunate that the 10 MHz output just happens to be one of the higher values.  But if your measurement needs are limited, it still might give you good results.  For example, if you measure frequency with a one second gate time, 40 ns peak to peak will be nicely averaged out.

What would be really interesting is whether the NEO-7N timing receiver exhibits similar behaviour.  You would hope that it would react better.  A graph for the two receivers showing RMS or standard deviation of the jitter vs. output frequency would be very enlightening.  I don't know if this info already exists or not.

[tomato]

What don't you like about those results?  I'm not seeing anything that looks out of line.

The peak-peak jitter with 2 and 12MHz outputs is ~2ns, while with 7 and 10MHz it is ~40ns. That is something interesting, isn't it?

Okay, I'll agree that it's interesting.  Since it's a navigation receiver rather than a timing receiver, the timing output is more of an afterthought than a feature.  With no jitter spec for the timing output it is what it is.  It could even change from one firmware version to another.    It's unfortunate that the 10 MHz output just happens to be one of the higher values.  But if your measurement needs are limited, it still might give you good results.  For example, if you measure frequency with a one second gate time, 40 ns peak to peak will be nicely averaged out.

What would be really interesting is whether the NEO-7N timing receiver exhibits similar behaviour.  You would hope that it would react better.  A graph for the two receivers showing RMS or standard deviation of the jitter vs. output frequency would be very enlightening.  I don't know if this info already exists or not.

That's not jitter -- that's an oscillator that is purposely generating 8 MHz part of the time and 12 MHz the rest of the time, to produce an average frequency of 10 MHz. The output must be limited to simple (binary) division of a 24 MHz (or 48 MHz?) clock.

[edpalmer42]

What don't you like about those results?  I'm not seeing anything that looks out of line.

The peak-peak jitter with 2 and 12MHz outputs is ~2ns, while with 7 and 10MHz it is ~40ns. That is something interesting, isn't it?

Okay, I'll agree that it's interesting.  Since it's a navigation receiver rather than a timing receiver, the timing output is more of an afterthought than a feature.  With no jitter spec for the timing output it is what it is.  It could even change from one firmware version to another.    It's unfortunate that the 10 MHz output just happens to be one of the higher values.  But if your measurement needs are limited, it still might give you good results.  For example, if you measure frequency with a one second gate time, 40 ns peak to peak will be nicely averaged out.

What would be really interesting is whether the NEO-7N timing receiver exhibits similar behaviour.  You would hope that it would react better.  A graph for the two receivers showing RMS or standard deviation of the jitter vs. output frequency would be very enlightening.  I don't know if this info already exists or not.

That's not jitter -- that's an oscillator that is purposely generating 8 MHz part of the time and 12 MHz the rest of the time, to produce an average frequency of 10 MHz. The output must be limited to simple (binary) division of a 24 MHz (or 48 MHz?) clock.

Wouldn't that be 8.333 and 12.5 MHz i.e. 100 ns +- 20 ns?  Anyway, I'd be surprised if it was that simple.  How would that scenario explain the much better results seen at 2 and 12 MHz?  A digital scope with lots of memory might be able to see if there were any intermediate steps.  An HP 5372A Time Interval Analyzer would definitely show what was going on.

I'm almost, but not quite, curious enough to buy one of each and test them.  Six to eight week delivery time is a real buzz kill.   

[tomato]

That's not jitter -- that's an oscillator that is purposely generating 8 MHz part of the time and 12 MHz the rest of the time, to produce an average frequency of 10 MHz. The output must be limited to simple (binary) division of a 24 MHz (or 48 MHz?) clock.

Wouldn't that be 8.333 and 12.5 MHz i.e. 100 ns +- 20 ns?

Approximately 20 ns.

Anyway, I'd be surprised if it was that simple.

These things are dirt cheap, right?

How would that scenario explain the much better results seen at 2 and 12 MHz?

Simple binary division from a 24 MHz clock.

A digital scope with lots of memory might be able to see if there were any intermediate steps.

It seems pretty obvious from the 7 MHz and 10 MHz graphs that the data takes on only discrete values. 

An HP 5372A Time Interval Analyzer would definitely show what was going on.

Easier yet, a modulation domain analyzer would confirm it in a few minutes.

On edit: Oops, I guess Agilent sometimes refers to the 5372a as a modulation domain analyzer.

[iMo]

I've been running my DIY reciprocal counter (with a time iterator), also using the counter for disciplining a Trimble 10MHz double oven OCXO (cheapo from ebay).
The counter is using 12MHz (or 8MHz) out of NEO-7M for timestamping (inside an fpga).

With the NEO's 10MHz I was getting pretty noisy results, and had problems to get OCXO's pid working. Therefore I started to play with other output frequencies, where 48MHz/N seem to be the "good" ones, at least here.

BTW, the BG7TBL's gpsdo has got a NEO-7M inside (based on the shots I've seen here) and hopefully he is not using the 10MHz output for a timestamping..

Would be great somebody confirms with a different measurement. My guess is all the NEO-7x/8x are affected (as they probably use a suboptimal sw NCO inside).

[tomato]

I've been running my DIY reciprocal counter (with a time iterator), also using the counter for disciplining a Trimble 10MHz double oven OCXO (cheapo from eBay).

What's a time iterator?
 

The counter is using 12MHz (or 8MHz) out of NEO-7M for timestamping (inside an fpga).

With the NEO's 10MHz I was getting pretty noisy results, and had problems to get OCXO's pid working. Therefore I started to play with other output frequencies, where 48MHz/N seem to be the "good" ones, at least here.

BTW, the BG7TBL's gpsdo has got a NEO-7M inside (based on the shots I've seen here) and hopefully he is not using the 10MHz output for a timestamping..

Would be great somebody confirms with a different measurement. My guess is all the NEO-7x/8x are affected (as they probably use a suboptimal sw NCO inside).

Confirm what?

[Berni]

The timepulse on most of uBlox GPS modules is syncronised to the internal clock. Even the timing ones are, but the difference is that the timing modules will also output a data packet that tells you the exact GPS time when the timepulse pin moved. That and the timing ones have a special mode that assumes the antenna is stationary and this gives a improved time only gps solution.

The timing modules also have a mode where they can drive a external DAC to tune a external oscillator while sampling its output to compare it to the GPS time.

I have never used them for this, just used the timing modules in the past for the reason that they can output raw satellite data.