[time-nuts] Ublox neo-7M GPS

[Ed Palmer]

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 the
> 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 and
> 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 where
> he thermally isolated his M12. With the FE 5680 work I made the M12 part of
> the  Rb by mounting it with metal stand offs to the backplate of the Rb.It
> 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 M7.
>   Attached  is the board layout on the right side is what we are presently
> using with the Morion, on the left is a version for 5 V OCXO's so Hams can
> use  12 Volt. The one on the right is driven by readily available parts for
> 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. :(

Ed

> 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 use
> 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
>