[time-nuts] Ublox neo-7M GPS

EWKehren at aol.com EWKehren at aol.com
Thu Aug 21 20:04:36 EDT 2014

We may be talking past each other I had problems with the statement that  
the basic M6 and M7 are not suitable for GPSDO's. They are not GPSDO's in 
them  self but great GPS engines even without saw tooth correction which is an  
impossibility since the data is not available. But as you observed as 
frequency  goes up saw tooth comes down. But with frequency power goes up reduced 
by  smaller chip geometry. For the majority of applications power is # 1 
concern. We  are a minority. Pure material cost of our universal controller is 
below $ 15 but  once you add paying some one for kitting, shipping and 
handling it is a  challenge to keep it below $ 50.
Having in the past spend excessively for toys I get more pleasure by  
looking for very low cost solutions at top performance. That is what we do as a  
Bert Kehren
In a message dated 8/21/2014 11:34:53 A.M. Eastern Daylight Time,  
ed_palmer at sasktel.net writes:

Hi  Bert,

I don't think we have any fundamental disagreement here.   Maybe just a 
difference in emphasis.

On 8/21/2014 4:34 AM,  EWKehren at aol.com wrote:
> Sorry but I disagree. Having done extensive  work with the M7 and M6 in
> connection with the with GPSDO work we are  doing we have characterized 
> units  extensively.  First  from what we can see the difference between a 
SSR-6T and a $ 16 M6 is that one  has a TCXO and outputs sawtooth 
correction data but uncorrected both are the  same.

I agree that uncorrected results will be basically the  same.  Note the 
specs I stated for the navigation receiver (30ns rms,  60ns max) vs. the 
timing receiver (15ns rms, <60ns max).  Not a  huge difference.  But, 
timing receivers do have features that can  improve performance over 
navigation receivers. Some that come to mind are  position hold mode, 
TRAIM, maintaining performance with only one satellite  locked, sawtooth 
correction, and precision survey.  I haven't dug  through the Ublox data 
sheets to see which ones they support.  Some  are only useful during 
degraded conditions so it might be difficult to  test their 
effectiveness.  Some are automatic while some, like  sawtooth correction, 
require extra work to take advantage of.

You  mentioned the TCXO in the timing receiver.  Ublox says that it helps  
with acquisition and maintenance of satellite lock, but I don't think it  
has any significant effect on the quality of the 1 PPS or the variable  
frequency which will still be limited by the timing resolution (i.e.  
period) of the TCXO.  Is that right?

> Last year we did  extensive work on Brooks GPSDO and it works well with
> uncorrected  M12's and ublox $ 16 M6's.  With a Morion we got 1  E-12.
>  With a geometry shrink in the M7 silicon higher frequency is possible  
> also lower power. Ublox most likely wants lower power and  higher
> performance but not necessarily lower sawtooth because those  OEM's that  
need it will get a version with sawtooth data. Basic engine  is still the 
same.  Time nuts are not a big enough market.  Sawtooth  is smaller compared 
to the  M6 doe to the higher clock frequency and it  is safe to assume that 
when they  come out with a M8 it will even be  less.

I won't be surprised to find that sawtooth correction becomes  irrelevent 
due to higher clock speeds which results in small sawtooth  size.  The 
Navsync CW-12 has been around for some years now.  It  runs at 'up to 120 
MHz', whatever that means.  I've measured its' 1  PPS jitter as 4 or 5 ns 
(1 sigma) and about 20 to 25 ns max.  It  doesn't support sawtooth 
correction, but it hardly needs to.  I tied  it to an HP Z3817A GPSDO.  
That's not a typo.  It's a strange  beast that requires an external 1 PPS 
input.  It includes an E1938  oscillator.  The result was a 1 PPS jitter 
of < 100 ps (1 sigma)  and < 1 ns max.  That's better than my Z3801A or 
Tbolt. It might  be capable of even better performance.  There's a 
possibility that  the E1938 oscillator is noisier than it should be. I 
should repeat that  test with other GPS receivers to see if the output 
degrades due to the  higher jitter on the older receivers. Another 
project to add to the  list!

Higher clock speeds will also allow more processing.  I  don't know if 
that will allow improved performance or if the receivers  have already 
done everything that they can.

> On the universal  controller we have a GPS filter not correction on the
> input that does  improve performance.
> I took a page out of Ulrich's work when I saw a  picture of his GPSDO 
> he thermally isolated his M12. With the FE  5680 work I made the M12 part 
> the  Rb by mounting it with  metal stand offs to the backplate of the 
> in turn is   temperature controlled.
> In the case of my FE 405B work I actually  placed the M6 inside the OCXO
> took the battery off. I think I have a  picture if interested.

Yes, if you look in the manual for Jackson Lab's  GPSTCXO it says that 
shielding the board from drafts improves  performance.  You've taken that 
to the next level.

> Not  knowing that it can not be done I did what I call a GPS-PLL using a  
>   Attached  is the board layout on the right side  is what we are 
> using with the Morion, on the left is a  version for 5 V OCXO's so Hams 
> use  12 Volt. The one on the  right is driven by readily available parts 
> any Ham  and no  adjustments. Total cost not counting GPS and OCXO below 
$ 10.
> We  are  still fine tuning the filter but right out of the box we got  1
> E-10. This is for  Ham's not time nut standard. Data exceeds  attachment
> limitations but any one can  contact me off list and I  will send it. We 
destroyed the M7 have not figured out how but a new one is on  order and 
once testing is completed schematics will also  be  available.

Every project requires a sacrifice to ensure success.   In my case, it's 
usually a blood sacrifice caused by stabbing or goring  myself with some 
tool. :(


> I have the bad habit  layouts
> first documentation maybe  second. Frustrating for the  team, but I am
> getting better. As I said before  mainly for Ham's  and one of our 
Australian team
> member will roll it out to the   Ham community. But any body is free to 
> it I just think time nuts  can do  better.
> Bert Kehren
> In a message dated 8/21/2014 1:30:50 A.M.  Eastern Daylight Time,
> ed_palmer at sasktel.net writes:
>  Thanks,  Tony.  That's good info.
> So now we've  confirmed that the neo-7M  has an NCO and it appears that
> it's  resolution is 20 ns.  The data  sheet shows the 'Accuracy of  time
> pulse signal' is 30 ns RMS and 60 ns for  99%, but it isn't  clear whether
> they're referring to jitter or error with  respect  to GPS seconds.
> The original question was whether the  neo-7M  would make a good GPSDO.
> As we've seen, the answer is  no.   Cheap, yes.  Good, no. Setting aside
> the NCO  issue, the neo-7M isn't  a timing receiver, it's a navigation
>  receiver.  That limits it's  performance in many  ways.
> Ublox sells timing receivers, but they're  still  NCO-based.  They're also
> significantly more expensive than  the  navigation receivers. One example
> is Synergy Systems'  SSR-6Tr if it's  still available.  It was announced,
> and  discussed on this list, in  2012 but it still isn't listed on  their
> web site so I don't know what it's  status is. It's based  on the LEA-6T
> timing receiver which has a spec for  the 1 PPS is  'within 15 ns to
> GPS/UTC (1 sigma)'.  That can be  further  reduced with some extra work.
> If the performance of an   NCO-based unit isn't enough, you might want to
> consider Jackson  Labs  GPSTCXO which is a real GPSDO.  More expensive
> than  the NCO-based  units, but you get what you pay for.
> No,  I'm not associated with  Synergy or Jackson labs.
> So  Graham, if you survived the firestorm  started by your simple
>  question, are you any wiser?
> Ed
> On   8/20/2014 7:56 PM, Tony wrote:
>> On 19/08/2014 16:11, Ed  Palmer  wrote:
>>> Does anyone have a neo-7M and an HP 5371A  or a 5372A  Analyzer?  Use
>>> the Histogram Time  Interval function to  measure a block of samples.
>>> That  will show the length of the  samples with a resolution of  200
>>> ps.  That's what I did a  couple of years ago  when I analyzed the
>>> Navsync CW-12 with the  old and new  firmware.
>> FWIW, I just had a look at the timepulse  on a  NEO-7M. I configured it
>> to 10MHz, 50:50 duty cycle when  locked,  disabled when out of lock. I
>> don't have any of those  Analyzers so I  used an HP 54615B digital
>> scope. The period  of the majority of cycles  was 104ns with 'random'
>> cycles  being 84ns. I did not observe any  other cycle periods. I  don't
>> know how accurate the time measurements  are on the  scope, but it looks
>> like the timing is derived from an   approx 48MHz clock, and the timing
>> phase/frequency adjusted  by  periodically deleting 48MHz clock cycles.
>>  Although I said  random, I couldn't make any observations as to  the
>> statistics of the  short and long cycles or their  distribution - I
>> guess I'll have to  write some software for  my STM32F4 discovery board
>> for  that.
>>  If I get time, I'll do the same with a Reyax RYN25AI  receiver  which
>> has a UBLOX MAX-7C  module.
>>    Tony

time-nuts  mailing list -- time-nuts at febo.com
To unsubscribe, go to  
and follow the  instructions there.

More information about the time-nuts mailing list