Re: [time-nuts] Synchronisation of crystal oscillators

Since the answer to my original question of possible synchronisation was a reasonably resounding no, I started doing some design work and then got an off-post message from TVB suggesting the use of his neat PicDiv chips to divide all my crystals down to 1PPS. On ordering a batch he came up with

[time-nuts] GPS module recommendation for Pi timing

I have an application where I need to synchronize the internal TOD RTC in a raspberry pi and need to pick a GPS module. We are building our own hardware but still using the Pi so interconnection will be via GPIO/serial. We won't try to use USB. This is not an NTP application. These units will be i

Re: [time-nuts] GPS module recommendation for Pi timing

Is this application for a product that you will be selling in quantity and producing over time, or a one-off or low volume application? On Fri, Mar 13, 2020 at 10:07 AM Brian Lloyd wrote: > I have an application where I need to synchronize the internal TOD RTC in a > raspberry pi and need to pic

Re: [time-nuts] GPS module recommendation for Pi timing

On Fri, Mar 13, 2020 at 9:20 AM Jim Harman wrote: > Is this application for a product that you will be selling in quantity and > producing over time, or a one-off or low volume application? > It will have a run of at least 100 units, maybe more. I would like it to have a decent lifetime in case

Re: [time-nuts] GPS module recommendation for Pi timing

Hi Pretty much any generic GPS module will get you to 1 ms without a lot of effort. There is certainly no need for the M9F or M9T sort of parts. A typical module will deliver a pps signal that is better than 100 ns as far as timing. How good you can do via serial on a Pi depends a bit on how lo

Re: [time-nuts] GPS module recommendation for Pi timing

What do you mean by "internal TOD RTC"? When I see "RTC", I usually think of one of those battery backed things running at 32 KHz. But the Pi doesn't have one of those. From the context, I think you mean what I call the system clock - what gets printed when you say "date". The trick to getti

Re: [time-nuts] GPS module recommendation for Pi timing

Hi Brian, We published this back in 2016 but it provides an analysis on the stability of the STC on the first three generations of Raspberry Pi as well as the stability profile of the uBlox M8Q: https://crin.eng.uts.edu.au/~darryl/Publications/Pi-hat_current.pdf Hopefully it will give you a st

Re: [time-nuts] GPS module recommendation for Pi timing

On Fri, Mar 13, 2020 at 2:07 PM Brian Lloyd wrote: > > I have an application where I need to synchronize the internal TOD RTC in a > raspberry pi and need to pick a GPS module. We are building our own > hardware but still using the Pi so interconnection will be via GPIO/serial. > We won't try to u

Re: [time-nuts] GPS module recommendation for Pi timing

On Fri, Mar 13, 2020 at 9:59 AM Peter Membrey wrote: > Hi Brian, > > We published this back in 2016 but it provides an analysis on the > stability of the STC on the first three generations of Raspberry Pi as well > as the stability profile of the uBlox M8Q: > > https://crin.eng.uts.edu.au/~darryl

Re: [time-nuts] GPS module recommendation for Pi timing

Hi If you are laying out a board and building quite a few, shop for one of the < $10 modules. What’s out there changes almost month to month so research is needed. As long as you get a PPS out, and a fairly rational serial i/o, mating them up should not be to crazy. You might spend the money y

Re: [time-nuts] GPS module recommendation for Pi timing

If your product depends on monotonic times, there are a lot of good reasons for using NTPD. It will slew the clock rather than jump it which can be hugely important for many applications if there is some need for data to be accumulated with monotonic timestamps. It will also apply good drift correc

Re: [time-nuts] GPS module recommendation for Pi timing

tsho...@gmail.com said: > You prominently mention both milliseconds and TOD RTC. Note that all common > RTC chips (e.g. DS1307) only directly read out time to the previous second. > They do not read out directly for milliseconds although you can try to > interpolate based on seconds edge. Some

Re: [time-nuts] GPS module recommendation for Pi timing

Hi, For your application and 1 ms accuracy ,the problem, this is a long time that i have made that, it is in the output and the information on a serial link or GPIO on a no Real Time OS. Even if you don't want using USB in an internal the PI use an USB serial port. There are some parameter in

Re: [time-nuts] GPS module recommendation for Pi timing

Hi One as yet un-asked question: Is this a dynamic or a static application? If static, is there time to do a proper survey of the location? Normally that all matters for accuracy. In this case it mostly matters in terms of dropouts / code slips. A code slip would indeed nuke your “one ms” budg

Re: [time-nuts] GPS module recommendation for Pi timing

kb...@n1k.org said: > In this case it mostly matters in terms of dropouts / code slips. A code > slip would indeed nuke your “one ms” budget. What is a "code slip"? Why can't I filter it out? -- These are my opinions. I hate spam. ___ ti

Re: [time-nuts] GPS module recommendation for Pi timing

Hi One of the ways a GPS module “freaks out” is to slip by one code cycle (which is just slightly over 1 ms). If you have a surveyed location, some firmware will reject the solution and at least you will be in holdover. In a case where the *only* thing you can trust is the GPS, filtering isn’t

Re: [time-nuts] GPS module recommendation for Pi timing

Thanks. kb...@n1k.org said: > One of the ways a GPS module “freaks out” is to slip by one code cycle > (which is just slightly over 1 ms). If you have a surveyed location, some > firmware will reject the solution and at least you will be in holdover. If it slips, how long does it stay slippe

Re: [time-nuts] GPS module recommendation for Pi timing

A nice post processing application such as RTKLIB will show any cycle slips that your receiver might have encountered. A good write up about cycle slips is available here: https://rtklibexplorer.wordpress.com/2016/05/08/raw-data-collection-cycle-slips/

Re: [time-nuts] GPS module recommendation for Pi timing

On 3/13/20 8:17 AM, Brian Lloyd wrote: On Fri, Mar 13, 2020 at 9:59 AM Peter Membrey wrote: Hi Brian, We published this back in 2016 but it provides an analysis on the stability of the STC on the first three generations of Raspberry Pi as well as the stability profile of the uBlox M8Q: https

Re: [time-nuts] Used HP 5061A cesium tube

Luiz Given that you work in a timelab I think you may know when the tube is dead. So I won't take you through the steps to check. But the discussion of refilling a tube has been discussed here several times in great accurate detail and depth. Search the archives for good reading. From the experts,

Re: [time-nuts] GPS module recommendation for Pi timing

Hi If you always operate in fixed locations, your chances of seeing a slip are not that high. The original post question and reference here were to timing in a *mobile* situation. Bob > On Mar 13, 2020, at 4:14 PM, Hal Murray wrote: > > > Thanks. > > kb...@n1k.org said: >> One of the ways a

[time-nuts] Modern Rb atomic reference vs classic Cs

Hi guys, Potentially a bit of a loaded topic, but I'm really curious as to what the consensus is on this. For the research I've been doing over the past few years, I've been predominantly using an SRS FS-725 (which uses the PRS-10) disciplined by a Microsemi S650 (with the Rb option, though it

Re: [time-nuts] Modern Rb atomic reference vs classic Cs

*Hello,* * * *By definition a Cesium frequency standard is just that, an absolute primary reference !  The only difference between the 5061A and another Cesium reference is a matter of degree of closeness to the absolute value.  For example the 5061A has a spec of +/- 1 in 10 to the -11th for

Re: [time-nuts] Modern Rb atomic reference vs classic Cs

Correction on the last sentence on accuracy of the hp-5061A was meant to say +/- 1 in 10 to the -11th. On 3/13/2020 10:35 PM, WB6BNQ wrote: *Hello,* * * *By definition a Cesium frequency standard is just that, an absolute primary reference !  The only difference between the 5061A and anothe

Re: [time-nuts] Modern Rb atomic reference vs classic Cs

Well, I fixed two typing mistakes.  Blame it on the corona, too many that is. Bill WB6BNQ On 3/13/2020 10:35 PM, WB6BNQ wrote: *Hello,* * * *By definition a Cesium frequency standard is just that, an absolute primary reference !  The only difference between the 5061A and another Cesium

[time-nuts] Is 5061A by itself a primary reference? Was: Modern Rb atomic reference vs classic Cs

On Sat, Mar 14, 2020 at 5:35 AM WB6BNQ wrote: > *By definition a Cesium frequency standard is just that, an absolute > primary reference ! The only difference between the 5061A and another > Cesium reference is a matter of degree of closeness to the absolute > value. For example the 5061A has a