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

[Bob kb8tq]

Hi

> On Mar 14, 2020, at 4:10 PM, Brian Lloyd  wrote:
> 
> On Sat, Mar 14, 2020 at 12:52 PM Bob kb8tq  wrote:
> 
>>> I understand completely. Still, I have to come up with a
>> reasonably-priced
>>> source of time and it does seem like GPS is the right answer. I can live
>>> with units going off-line periodically due to insufficient timing
>> accuracy,
>>> but I cannot have them drifting away from correct time.
>> 
>> Only you can evaluate how important this or that aspect of the design is.
>> If *any* timing drift past 1 ms becomes an issue, some sort of TCXO based
>> GPSDO may be the real answer.
>> 
> 
> In reading the data sheet for the LEA-M8T it does have a TCXO for the
> timing outputs.

It does and it doesn’t. You can not “count on” the TCXO to do nice things
in holdover. 


> 
> 
>> With a bare crystal, you could easily have a 10’s of ppm sort of error. If
>> you do, then any outage over about 100 seconds will hit your limit.
>> 
> 
> Yes, and I just need to know that I am out-of-spec so I can turn off
> participation by that device until it has good timing again. And if I have
> to end up disciplining a local TCXO then I can do that too, and then I use
> a cheaper GPS module. Ah, design decisions. Where would we engineers be if
> we weren't making design decisions compromises. ;-)

So you need a second “something” to compare to that will let you make
this call. That or you shut down any time GPS drops out. 

> 
> 
>>> The signal will be squared and used as a clock for something else.
>>> Duty-cycle is flexible. As long as the rising edge is clean and there
>> isn't
>>> too much jitter, I can live with it. I have no erroneous notion that I am
>>> getting a clean sine wave or a symmetrical square wave. Also, this is in
>>> the "nice to have" category and I can do away with it and use a GPS
>> module
>>> that only has 1pps.
>> 
>> The output will have jitter at the same level as the time pulse. If it’s a
>> 20 ns
>> time pulse pre-sawtooth, then the 10 MHz will also hop by 20 ns.
>> 
> 
> Yes, so what happens depends on whether it is phase error or phase jitter,
> and then what the device wanting the 10MHz reference does with it. Since
> that is part of this that I don't have control over, I am going to have to
> get more information. But if that other time-pulse can be used as a 10MHz
> reference that is used to discipline another oscillator rather than being
> used directly, it should be OK. I just need more information on this part
> of it. I just don't know how clean that output from the Ublox is.

The time pulse, pps, whatever you call it is quantized to an internal free 
running
clock in the module. It comes out based on whatever edge happens to be
closest at the moment. Since the clock is free running you can have some
very odd behavior. 

For accurate timing or a GPSDO, there is a “sawtooth” message that tells
you the offset of the edge from reality. That message comes out once a 
second. If the edge you use comes out more often than that, you have 
no feedback about where the edge is relative to what it actually should be. 

> 
> 
>> 
>>> 
>>> So I am still hoping that someone will say, "The U-Blox LEA-M8T is a
>> pretty
>>> good choice but for what you are talking about, you might want to look at
>>> the XYZ module as well."
>> 
>> There are maybe another two dozen modules out there that might work and
>> cost the same or less. Buying a few of this and that / trying them out is
>> about
>> the only way to know if they are “good enough” for all the details of your
>> application.
>> 
>> The bigger issue is - how much can you invest to dig through a pile of
>> modules?
>> The simple answer is indeed to just pick one and accept the cost impact.
>> 
> 
> That is indeed the question. Given the experience level here I was hoping
> that others had run into similar issues and might have more information to
> share with me, or even point me to something that would works as well or
> better than the Ublox.

The gotcha is that every application is different. Without a deep dive into the 
entire design (and that’s not really what this list is for ) there is no way to 
start
sorting things out.  These days pretty much all the modules on the market 
(that put out a pps) will easily do microsecond level timing. 

Lots of fun 

Bob


> 
> Thanks! I appreciate your input.
> 
> -- 
> 
> 
> 
> Brian Lloyd
> 706 Flightline
> Spring Branch, TX 78070
> br...@lloyd.aero
> +1.210.802-8FLY (1.210.802-8359)
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to 
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

[Hal Murray]

br...@lloyd.aero said:
> Some of the units may have access to the Internet and I could run NTP on them
> but the majority will be using GPS as the single stand-alone source of UTC.
> The goal is for all the units to be sync'd to UTC as they need to perform
> repetitive functions concurrently. 

If you run NTP without a network connection but with GPS, it will discipline 
the local clock by tweaking the seconds per tick parameter deep inside the 
kernel.

It's a GPSDO implemented in software.  No DAC.  Actually, GPSDC - Clock rather 
than Oscillator.


kb...@n1k.org said:
> With a bare crystal, you could easily have a 10’s of ppm sort of error. If
> you do, then any outage over about 100 seconds will hit your limit.  

Unless ntpd has tweaked your clock.  It's good enough to make a rough 
thermometer.


br...@lloyd.aero said:
> I just don't know how clean that output from the Ublox is.

If the output frequency is programmable, it will be derived via a DDS, good 
for long term timing but lots of jitter.

I suggest you get a Ublox development board and/or one or more Pi GPS HATs and 
start experimenting.


-- 
These are my opinions.  I hate spam.




___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

[Brian Lloyd]

On Sat, Mar 14, 2020 at 12:52 PM Bob kb8tq  wrote:

> > I understand completely. Still, I have to come up with a
> reasonably-priced
> > source of time and it does seem like GPS is the right answer. I can live
> > with units going off-line periodically due to insufficient timing
> accuracy,
> > but I cannot have them drifting away from correct time.
>
> Only you can evaluate how important this or that aspect of the design is.
> If *any* timing drift past 1 ms becomes an issue, some sort of TCXO based
> GPSDO may be the real answer.
>

In reading the data sheet for the LEA-M8T it does have a TCXO for the
timing outputs.


> With a bare crystal, you could easily have a 10’s of ppm sort of error. If
> you do, then any outage over about 100 seconds will hit your limit.
>

Yes, and I just need to know that I am out-of-spec so I can turn off
participation by that device until it has good timing again. And if I have
to end up disciplining a local TCXO then I can do that too, and then I use
a cheaper GPS module. Ah, design decisions. Where would we engineers be if
we weren't making design decisions compromises. ;-)


> > The signal will be squared and used as a clock for something else.
> > Duty-cycle is flexible. As long as the rising edge is clean and there
> isn't
> > too much jitter, I can live with it. I have no erroneous notion that I am
> > getting a clean sine wave or a symmetrical square wave. Also, this is in
> > the "nice to have" category and I can do away with it and use a GPS
> module
> > that only has 1pps.
>
> The output will have jitter at the same level as the time pulse. If it’s a
> 20 ns
> time pulse pre-sawtooth, then the 10 MHz will also hop by 20 ns.
>

Yes, so what happens depends on whether it is phase error or phase jitter,
and then what the device wanting the 10MHz reference does with it. Since
that is part of this that I don't have control over, I am going to have to
get more information. But if that other time-pulse can be used as a 10MHz
reference that is used to discipline another oscillator rather than being
used directly, it should be OK. I just need more information on this part
of it. I just don't know how clean that output from the Ublox is.


>
> >
> > So I am still hoping that someone will say, "The U-Blox LEA-M8T is a
> pretty
> > good choice but for what you are talking about, you might want to look at
> > the XYZ module as well."
>
> There are maybe another two dozen modules out there that might work and
> cost the same or less. Buying a few of this and that / trying them out is
> about
> the only way to know if they are “good enough” for all the details of your
> application.
>
> The bigger issue is - how much can you invest to dig through a pile of
> modules?
> The simple answer is indeed to just pick one and accept the cost impact.
>

That is indeed the question. Given the experience level here I was hoping
that others had run into similar issues and might have more information to
share with me, or even point me to something that would works as well or
better than the Ublox.

Thanks! I appreciate your input.

-- 



Brian Lloyd
706 Flightline
Spring Branch, TX 78070
br...@lloyd.aero
+1.210.802-8FLY (1.210.802-8359)
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

[Bob kb8tq]

Hi

> On Mar 14, 2020, at 1:36 PM, Brian Lloyd  wrote:
> 
> On Sat, Mar 14, 2020 at 10:57 AM Bob kb8tq  wrote:
> 
>> Hi
>> 
>> 
>>> On Mar 14, 2020, at 10:54 AM, Brian Lloyd  wrote:
>>> 
>>> On Fri, Mar 13, 2020 at 8:49 PM Bob kb8tq  wrote:
>>> 
 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.
 
>>> 
>>> Thank you all for your inputs. Here is a little more data, prompted by
>>> comments and questions. (Some of this I wasn't thinking about at first.)
>>> 
>>> I realized that, while I expect the majority of units to be stationary
>> with
>>> the ability to properly position an antenna, there is a chance that one
>> or
>>> more of the units may be mobile. Regardless of mobility, the purpose will
>>> be time and frequency reference, not position. Does that change my choice
>>> of device?
>> 
>> In order to get time, you first need location. Without location, there is
>> no
>> way to correct for the time of flight of the signals.
>> 
> 
> I understand. The question is, are the timing-oriented GPS modules going to
> work in that application or should I opt for a position-oriented GPS and
> accept lower accuracy of 1pps?
> 
> In a mobile situation, timing can be tough. At some point a ZED-F9P or a
>> member of that family would do better if highly accurate mobile time is
>> the
>> goal. Since your needs are modest, it may not be worth the cost.
>> 
> 
> And that is the question.
> 
> There is still the issue of going under a bridge / into a “canyon” and
>> having the GPS stop due to lack of signal. This sort of dropout can
>> easily run into the “couple of minutes” range.
>> 
> 
> Let me put it this way, if I am going under a bridge or in a tunnel, the
> point will be moot.
> 
> “Good antenna location” in this case is often not an easy thing to do.
>> Ideally you want a full sky view down to 10 or 20 degrees above the
>> horizon. Your typical “fast setup” location usually does not do this. With
>> an “impaired” antenna location, you can get dropouts based on the
>> limited amount of sky you can get at.
>> 
> 
> I understand completely. Still, I have to come up with a reasonably-priced
> source of time and it does seem like GPS is the right answer. I can live
> with units going off-line periodically due to insufficient timing accuracy,
> but I cannot have them drifting away from correct time.

Only you can evaluate how important this or that aspect of the design is.
If *any* timing drift past 1 ms becomes an issue, some sort of TCXO based
GPSDO may be the real answer. 

With a bare crystal, you could easily have a 10’s of ppm sort of error. If 
you do, then any outage over about 100 seconds will hit your limit. 


> 
> 
> 
>>> Some of the units may have access to the Internet and I could run NTP on
>>> them but the majority will be using GPS as the single stand-alone source
>> of
>>> UTC. The goal is for all the units to be sync'd to UTC as they need to
>>> perform repetitive functions concurrently.
>>> 
>>> The starting point for me was going to be the Ublox LEA-M8T because it is
>>> current generation and Ublox offers a common footprint so that, if
>>> production runs into the future, there will be newer modules that can be
>>> dropped onto the same board. I want the second output to use as a 10MHz
>>> reference. I have need for a 3e-7 accuracy 10MHz frequency reference in
>>> some cases and that looked like it would do what is needed without going
>>> full-on GPSDOCXO.
>>> 
>>> So is my first choice of the Ublox LEA-M8T a good one or should I be
>>> looking at other units. While I don't want to spend $50(us) on a
>> receiver,
>>> if it does the best job, it will fit the budget and that extra timing
>>> output I can use to generate 10MHz is quite attractive.
>> 
>> That output is likely to be very “dirty” as far as spurs and noise are
>> concerned.
>> If you have any significant spectral purity needs … yikes.
>> 
> 
> The signal will be squared and used as a clock for something else.
> Duty-cycle is flexible. As long as the rising edge is clean and there isn't
> too much jitter, I can live with it. I have no erroneous notion that I am
> getting a clean sine wave or a symmetrical square wave. Also, this is in
> the "nice to have" category and I can do away with it and use a GPS module
> that only has 1pps.

The output will have jitter at the same level as the time pulse. If it’s a 20 ns
time pulse pre-sawtooth, then the 10 MHz will also hop by 20 ns.


> 
> So I am still hoping that someone will say, "The U-Blox LEA-M8T is a pretty
> good choice but for what you are talking about, you might want to look at
> the XYZ module as well."

There are maybe another two dozen modules out there that might work and
cost the same or less. Buying a few of this and that / trying them out is about 
the only way to know if they are “good enough” for all the details of 

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

[Brian Lloyd]

On Sat, Mar 14, 2020 at 10:57 AM Bob kb8tq  wrote:

> Hi
>
>
> > On Mar 14, 2020, at 10:54 AM, Brian Lloyd  wrote:
> >
> > On Fri, Mar 13, 2020 at 8:49 PM Bob kb8tq  wrote:
> >
> >> 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.
> >>
> >
> > Thank you all for your inputs. Here is a little more data, prompted by
> > comments and questions. (Some of this I wasn't thinking about at first.)
> >
> > I realized that, while I expect the majority of units to be stationary
> with
> > the ability to properly position an antenna, there is a chance that one
> or
> > more of the units may be mobile. Regardless of mobility, the purpose will
> > be time and frequency reference, not position. Does that change my choice
> > of device?
>
> In order to get time, you first need location. Without location, there is
> no
> way to correct for the time of flight of the signals.
>

I understand. The question is, are the timing-oriented GPS modules going to
work in that application or should I opt for a position-oriented GPS and
accept lower accuracy of 1pps?

In a mobile situation, timing can be tough. At some point a ZED-F9P or a
> member of that family would do better if highly accurate mobile time is
> the
> goal. Since your needs are modest, it may not be worth the cost.
>

And that is the question.

There is still the issue of going under a bridge / into a “canyon” and
> having the GPS stop due to lack of signal. This sort of dropout can
> easily run into the “couple of minutes” range.
>

Let me put it this way, if I am going under a bridge or in a tunnel, the
point will be moot.

“Good antenna location” in this case is often not an easy thing to do.
> Ideally you want a full sky view down to 10 or 20 degrees above the
> horizon. Your typical “fast setup” location usually does not do this. With
> an “impaired” antenna location, you can get dropouts based on the
> limited amount of sky you can get at.
>

I understand completely. Still, I have to come up with a reasonably-priced
source of time and it does seem like GPS is the right answer. I can live
with units going off-line periodically due to insufficient timing accuracy,
but I cannot have them drifting away from correct time.



> > Some of the units may have access to the Internet and I could run NTP on
> > them but the majority will be using GPS as the single stand-alone source
> of
> > UTC. The goal is for all the units to be sync'd to UTC as they need to
> > perform repetitive functions concurrently.
> >
> > The starting point for me was going to be the Ublox LEA-M8T because it is
> > current generation and Ublox offers a common footprint so that, if
> > production runs into the future, there will be newer modules that can be
> > dropped onto the same board. I want the second output to use as a 10MHz
> > reference. I have need for a 3e-7 accuracy 10MHz frequency reference in
> > some cases and that looked like it would do what is needed without going
> > full-on GPSDOCXO.
> >
> > So is my first choice of the Ublox LEA-M8T a good one or should I be
> > looking at other units. While I don't want to spend $50(us) on a
> receiver,
> > if it does the best job, it will fit the budget and that extra timing
> > output I can use to generate 10MHz is quite attractive.
>
> That output is likely to be very “dirty” as far as spurs and noise are
> concerned.
> If you have any significant spectral purity needs … yikes.
>

The signal will be squared and used as a clock for something else.
Duty-cycle is flexible. As long as the rising edge is clean and there isn't
too much jitter, I can live with it. I have no erroneous notion that I am
getting a clean sine wave or a symmetrical square wave. Also, this is in
the "nice to have" category and I can do away with it and use a GPS module
that only has 1pps.

So I am still hoping that someone will say, "The U-Blox LEA-M8T is a pretty
good choice but for what you are talking about, you might want to look at
the XYZ module as well."

-- 



Brian Lloyd
706 Flightline
Spring Branch, TX 78070
br...@lloyd.aero
+1.210.802-8FLY (1.210.802-8359)
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

[Bob kb8tq]

Hi


> On Mar 14, 2020, at 10:54 AM, Brian Lloyd  wrote:
> 
> On Fri, Mar 13, 2020 at 8:49 PM Bob kb8tq  wrote:
> 
>> 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.
>> 
> 
> Thank you all for your inputs. Here is a little more data, prompted by
> comments and questions. (Some of this I wasn't thinking about at first.)
> 
> I realized that, while I expect the majority of units to be stationary with
> the ability to properly position an antenna, there is a chance that one or
> more of the units may be mobile. Regardless of mobility, the purpose will
> be time and frequency reference, not position. Does that change my choice
> of device?

In order to get time, you first need location. Without location, there is no
way to correct for the time of flight of the signals. 

In a mobile situation, timing can be tough. At some point a ZED-F9P or a 
member of that family would do better if highly accurate mobile time is the 
goal. Since your needs are modest, it may not be worth the cost. 

There is still the issue of going under a bridge / into a “canyon” and 
having the GPS stop due to lack of signal. This sort of dropout can 
easily run into the “couple of minutes” range. 

“Good antenna location” in this case is often not an easy thing to do.
Ideally you want a full sky view down to 10 or 20 degrees above the 
horizon. Your typical “fast setup” location usually does not do this. With
an “impaired” antenna location, you can get dropouts based on the 
limited amount of sky you can get at. 

> 
> Some of the units may have access to the Internet and I could run NTP on
> them but the majority will be using GPS as the single stand-alone source of
> UTC. The goal is for all the units to be sync'd to UTC as they need to
> perform repetitive functions concurrently.
> 
> The starting point for me was going to be the Ublox LEA-M8T because it is
> current generation and Ublox offers a common footprint so that, if
> production runs into the future, there will be newer modules that can be
> dropped onto the same board. I want the second output to use as a 10MHz
> reference. I have need for a 3e-7 accuracy 10MHz frequency reference in
> some cases and that looked like it would do what is needed without going
> full-on GPSDOCXO.
> 
> So is my first choice of the Ublox LEA-M8T a good one or should I be
> looking at other units. While I don't want to spend $50(us) on a receiver,
> if it does the best job, it will fit the budget and that extra timing
> output I can use to generate 10MHz is quite attractive.

That output is likely to be very “dirty” as far as spurs and noise are 
concerned.
If you have any significant spectral purity needs … yikes.

Bob

> 
> -- 
> 
> 
> 
> Brian Lloyd
> 706 Flightline
> Spring Branch, TX 78070
> br...@lloyd.aero
> +1.210.802-8FLY (1.210.802-8359)
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to 
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

[jimlux]

On 3/14/20 7:54 AM, Brian Lloyd wrote:

On Fri, Mar 13, 2020 at 8:49 PM Bob kb8tq  wrote:


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.



Thank you all for your inputs. Here is a little more data, prompted by
comments and questions. (Some of this I wasn't thinking about at first.)

I realized that, while I expect the majority of units to be stationary with
the ability to properly position an antenna, there is a chance that one or
more of the units may be mobile. Regardless of mobility, the purpose will
be time and frequency reference, not position. Does that change my choice
of device?

Some of the units may have access to the Internet and I could run NTP on
them but the majority will be using GPS as the single stand-alone source of
UTC. The goal is for all the units to be sync'd to UTC as they need to
perform repetitive functions concurrently.


NTP provides advantages, as mentioned by Tim Shoppa, in that it also 
does a "smoothing" of the time from your GPS.






The starting point for me was going to be the Ublox LEA-M8T because it is
current generation and Ublox offers a common footprint so that, if
production runs into the future, there will be newer modules that can be
dropped onto the same board. I want the second output to use as a 10MHz
reference. I have need for a 3e-7 accuracy 10MHz frequency reference in
some cases and that looked like it would do what is needed without going
full-on GPSDOCXO.


Do you actually need 10MHz "control" or do you need "knowledge"?
If you count your clock with the 1pps, you get knowledge to 1E-7 (for 
10MHz), but not necessarily control.
If you don't need good close in phase noise, or smooth ADEV statistics 
you could probably use the count to drive a simple loop to steer a VCXO 
every 1 second or every 10 seconds or something.


Conceiveably, one could also do something like continuously reprogram a 
SiLabs part





So is my first choice of the Ublox LEA-M8T a good one or should I be
looking at other units. While I don't want to spend $50(us) on a receiver,
if it does the best job, it will fit the budget and that extra timing
output I can use to generate 10MHz is quite attractive.


Of course, cheap 10MHz VCXO (not VCOCXO) might get you there also.
Or use the Abracon
https://www.mouser.com/datasheet/2/3/ASG-C-9844.pdf
which has both a voltage and a programming input

$8 in single quantity from Mouser.






___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

[Brian Lloyd]

On Fri, Mar 13, 2020 at 8:49 PM Bob kb8tq  wrote:

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

Thank you all for your inputs. Here is a little more data, prompted by
comments and questions. (Some of this I wasn't thinking about at first.)

I realized that, while I expect the majority of units to be stationary with
the ability to properly position an antenna, there is a chance that one or
more of the units may be mobile. Regardless of mobility, the purpose will
be time and frequency reference, not position. Does that change my choice
of device?

Some of the units may have access to the Internet and I could run NTP on
them but the majority will be using GPS as the single stand-alone source of
UTC. The goal is for all the units to be sync'd to UTC as they need to
perform repetitive functions concurrently.

The starting point for me was going to be the Ublox LEA-M8T because it is
current generation and Ublox offers a common footprint so that, if
production runs into the future, there will be newer modules that can be
dropped onto the same board. I want the second output to use as a 10MHz
reference. I have need for a 3e-7 accuracy 10MHz frequency reference in
some cases and that looked like it would do what is needed without going
full-on GPSDOCXO.

So is my first choice of the Ublox LEA-M8T a good one or should I be
looking at other units. While I don't want to spend $50(us) on a receiver,
if it does the best job, it will fit the budget and that extra timing
output I can use to generate 10MHz is quite attractive.

-- 



Brian Lloyd
706 Flightline
Spring Branch, TX 78070
br...@lloyd.aero
+1.210.802-8FLY (1.210.802-8359)
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

[Bob kb8tq]

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 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 slipped?
> 
> I have plenty of old GPS units.  I'm a bit surprised I haven't noticed 
> something like that.  Maybe I'm not looking hard enough and/or in the right 
> place.
> 
>> In a case where the *only* thing you can trust is the GPS, filtering isn’t
>> going to do much good. 
> 
> You also have the CPU crystal.  It's not good for long term stability, but 
> shouldn't have any troubles holding to a ms over several seconds.
> 
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

[jimlux]

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://crin.eng.uts.edu.au/~darryl/Publications/Pi-hat_current.pdf



Thank you. Perfect. Reading now.

Bob KB8TQ: We are laying out our own board as it will be doing other things
besides GPS time/frequency keeping. Trying to avoid the use of USB. 1pps
will go directly to a GPIO pin, assuming that will provide the best
performance.

Hal Murray: Yes, I am trying to discipline the system clock.

Arne: Yes, I was considering using gpsd.

Right now I am leaning toward the Ublox LEA-M8T. I have a use for the other
programmable output from the Ublox.


I've been working on a similar project - using a battery powered 
beaglebone and a GPS with an RTL-SDR to build an interferometer.


I was able to get a NEO-7 hooked up, chrony installed and running, etc. 
on 4 nodes.
what I have not been able to do is figure out how to sync the RTL-SDR 
(or, at least, get a 1pps hack into the data stream) - I might just go 
to a fancier RF interface like a Lime mini.




___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

[Chris Burford]

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/ 



Regards,

Chris

On 03/13/20 15:14:13, Hal Murray wrote:

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 slipped?

I have plenty of old GPS units.  I'm a bit surprised I haven't noticed
something like that.  Maybe I'm not looking hard enough and/or in the right
place.


In a case where the *only* thing you can trust is the GPS, filtering isn’t
going to do much good.

You also have the CPU crystal.  It's not good for long term stability, but
shouldn't have any troubles holding to a ms over several seconds.




___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

[Hal Murray]

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 slipped?

I have plenty of old GPS units.  I'm a bit surprised I haven't noticed 
something like that.  Maybe I'm not looking hard enough and/or in the right 
place.

> In a case where the *only* thing you can trust is the GPS, filtering isn’t
> going to do much good. 

You also have the CPU crystal.  It's not good for long term stability, but 
shouldn't have any troubles holding to a ms over several seconds.



-- 
These are my opinions.  I hate spam.




___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

[Bob kb8tq]

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 going
to do much good.

Bob

> On Mar 13, 2020, at 2:53 PM, Hal Murray  wrote:
> 
> 
> 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.
> 
> 
> 
> 
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to 
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

[Hal Murray]

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.




___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

[Bob kb8tq]

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” budget.

Bob

> On Mar 13, 2020, at 11: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://crin.eng.uts.edu.au/~darryl/Publications/Pi-hat_current.pdf
> 
> 
> Thank you. Perfect. Reading now.
> 
> Bob KB8TQ: We are laying out our own board as it will be doing other things
> besides GPS time/frequency keeping. Trying to avoid the use of USB. 1pps
> will go directly to a GPIO pin, assuming that will provide the best
> performance.
> 
> Hal Murray: Yes, I am trying to discipline the system clock.
> 
> Arne: Yes, I was considering using gpsd.
> 
> Right now I am leaning toward the Ublox LEA-M8T. I have a use for the other
> programmable output from the Ublox.
> 
> 
> -- 
> 
> 
> 
> Brian Lloyd
> 706 Flightline
> Spring Branch, TX 78070
> br...@lloyd.aero
> +1.210.802-8FLY (1.210.802-8359)
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to 
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

[Thierry MUSEUX]

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 the USB driver to 
manage the answer.
 For the GPIO it is also  a driver to manage.

To have a good  accuracy the best way is to use RTOS or best a metal OS to 
manage the GPIO.
Or allow some slope accepted modular time.

Thierry M

-Message d'origine-
De : time-nuts [mailto:time-nuts-boun...@lists.febo.com] De la part de Brian 
Lloyd
Envoyé : vendredi 13 mars 2020 15:06
À : Discussion of precise time and frequency measurement
Objet : [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 in the field and will
most likely not have Internet access. I need their clocks to be pretty
close. I am shooting for 1ms ... if possible.

The new M9F and M9T modules from Ublox are a bit pricey. The M8T is a bit
more reasonable. OTOH I realize there are limits to how tightly I can
control the Pi's RTC and will run into diminishing returns, so even the M8T
might be overkill.

Has anyone here figured out what the reasonable limit is for timing on a
Pi, and what makes sense for a timing module for an application like this?

Thanks.

-- 



Brian Lloyd
706 Flightline
Spring Branch, TX 78070
br...@lloyd.aero
+1.210.802-8FLY (1.210.802-8359)
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

[Hal Murray]

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 of those chips have a pin that is intended to make an interrupt.




-- 
These are my opinions.  I hate spam.




___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

[Tim Shoppa]

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
correction for times when sky and satellites might not be visible (which in
terms of real world products is very common.

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.

Tim N3QE


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 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 in the field and will
> most likely not have Internet access. I need their clocks to be pretty
> close. I am shooting for 1ms ... if possible.
>
> The new M9F and M9T modules from Ublox are a bit pricey. The M8T is a bit
> more reasonable. OTOH I realize there are limits to how tightly I can
> control the Pi's RTC and will run into diminishing returns, so even the M8T
> might be overkill.
>
> Has anyone here figured out what the reasonable limit is for timing on a
> Pi, and what makes sense for a timing module for an application like this?
>
> Thanks.
>
> --
>
>
>
> Brian Lloyd
> 706 Flightline
> Spring Branch, TX 78070
> br...@lloyd.aero
> +1.210.802-8FLY (1.210.802-8359)
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

[Bob kb8tq]

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 you save on the GPS buying a “real” RTC 
chip ….. They aren’t crazy expensive and mate into the Pi environment 
pretty easily. GPS can come and go unless the antenna is in a really
good location. 

Bob

> On Mar 13, 2020, at 11: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://crin.eng.uts.edu.au/~darryl/Publications/Pi-hat_current.pdf
> 
> 
> Thank you. Perfect. Reading now.
> 
> Bob KB8TQ: We are laying out our own board as it will be doing other things
> besides GPS time/frequency keeping. Trying to avoid the use of USB. 1pps
> will go directly to a GPIO pin, assuming that will provide the best
> performance.
> 
> Hal Murray: Yes, I am trying to discipline the system clock.
> 
> Arne: Yes, I was considering using gpsd.
> 
> Right now I am leaning toward the Ublox LEA-M8T. I have a use for the other
> programmable output from the Ublox.
> 
> 
> -- 
> 
> 
> 
> Brian Lloyd
> 706 Flightline
> Spring Branch, TX 78070
> br...@lloyd.aero
> +1.210.802-8FLY (1.210.802-8359)
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to 
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

[Brian Lloyd]

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/Publications/Pi-hat_current.pdf


Thank you. Perfect. Reading now.

Bob KB8TQ: We are laying out our own board as it will be doing other things
besides GPS time/frequency keeping. Trying to avoid the use of USB. 1pps
will go directly to a GPIO pin, assuming that will provide the best
performance.

Hal Murray: Yes, I am trying to discipline the system clock.

Arne: Yes, I was considering using gpsd.

Right now I am leaning toward the Ublox LEA-M8T. I have a use for the other
programmable output from the Ublox.


-- 



Brian Lloyd
706 Flightline
Spring Branch, TX 78070
br...@lloyd.aero
+1.210.802-8FLY (1.210.802-8359)
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

[shouldbe q931]

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 use USB.
>
> This is not an NTP application. These units will be in the field and will
> most likely not have Internet access. I need their clocks to be pretty
> close. I am shooting for 1ms ... if possible.
>
> The new M9F and M9T modules from Ublox are a bit pricey. The M8T is a bit
> more reasonable. OTOH I realize there are limits to how tightly I can
> control the Pi's RTC and will run into diminishing returns, so even the M8T
> might be overkill.
>
> Has anyone here figured out what the reasonable limit is for timing on a
> Pi, and what makes sense for a timing module for an application like this?
>
> Thanks.
>
> --
>
>
>
> Brian Lloyd
> 706 Flightline
> Spring Branch, TX 78070
> br...@lloyd.aero
> +1.210.802-8FLY (1.210.802-8359)

If you are using a Pi, then you are limited to the Pi onboard crystal,
however as long as the GPS signal is "good", and the temperature is
stable, <1ms should be easily acheivable (my logs show ~20us is) while
GPS is running, however without GPS, the drift can be significant.

Although you might not need external NTP, the "simple" stack would be
ue gpsd to listen to the GPS and PPS, and then ntp/ntpsec/chrony to
set the time.

If you wanted a "plug and play" solution, the uptronics board is the
probably simplest.
https://store.uputronics.com/index.php?route=product/product_id=81,
otherwise for 1ms, there are many suppliers of uBlox modules.

Cheers

Arne

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

[Peter Membrey]

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 starting point if nothing else :)

Kind Regards,

Peter Membrey



- Original Message -
From: "Brian Lloyd" 
To: "Discussion of precise time and frequency measurement" 

Sent: Friday, 13 March, 2020 22:06:07
Subject: [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 in the field and will
most likely not have Internet access. I need their clocks to be pretty
close. I am shooting for 1ms ... if possible.

The new M9F and M9T modules from Ublox are a bit pricey. The M8T is a bit
more reasonable. OTOH I realize there are limits to how tightly I can
control the Pi's RTC and will run into diminishing returns, so even the M8T
might be overkill.

Has anyone here figured out what the reasonable limit is for timing on a
Pi, and what makes sense for a timing module for an application like this?

Thanks.

-- 



Brian Lloyd
706 Flightline
Spring Branch, TX 78070
br...@lloyd.aero
+1.210.802-8FLY (1.210.802-8359)
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

[Hal Murray]

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 getting decent timing from GPS on a Pi is to feed the PPS signal 
to one of the GPIO pins.  With that (and reasonable GPS reception), 1ms should 
be simple.

There are several GPS HATs available if you want to experiment before you 
build your own board.  The one from Adafruit fills the rest of the board with 
a prototyping area full of holes on a 1/10 inch grid.

For 1 ms, USB isn't out of the question.  There is at least one USB-Serial 
chip that uses the faster version of USB.  I forget the words.  Most GPS 
"mice" connect via slow USB with a polling interval of 1 ms.  The faster one 
is 8 times as fast.


-- 
These are my opinions.  I hate spam.




___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

[Bob kb8tq]

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 loaded it 
is. “Microsecond" level performance is possible. 

I’d target low cost over performance in this case …..

Are you laying out a board for your gizmo? If so, there are a number of
drop in solutions for not a whole lot of money. 

Bob

> On Mar 13, 2020, at 10:06 AM, 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 use USB.
> 
> This is not an NTP application. These units will be in the field and will
> most likely not have Internet access. I need their clocks to be pretty
> close. I am shooting for 1ms ... if possible.
> 
> The new M9F and M9T modules from Ublox are a bit pricey. The M8T is a bit
> more reasonable. OTOH I realize there are limits to how tightly I can
> control the Pi's RTC and will run into diminishing returns, so even the M8T
> might be overkill.
> 
> Has anyone here figured out what the reasonable limit is for timing on a
> Pi, and what makes sense for a timing module for an application like this?
> 
> Thanks.
> 
> -- 
> 
> 
> 
> Brian Lloyd
> 706 Flightline
> Spring Branch, TX 78070
> br...@lloyd.aero
> +1.210.802-8FLY (1.210.802-8359)
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to 
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

[Brian Lloyd]

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 we need to make more.


> 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 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 in the field and will
> > most likely not have Internet access. I need their clocks to be pretty
> > close. I am shooting for 1ms ... if possible.
> >
> > The new M9F and M9T modules from Ublox are a bit pricey. The M8T is a bit
> > more reasonable. OTOH I realize there are limits to how tightly I can
> > control the Pi's RTC and will run into diminishing returns, so even the
> M8T
> > might be overkill.
> >
> > Has anyone here figured out what the reasonable limit is for timing on a
> > Pi, and what makes sense for a timing module for an application like
> this?
>
>

-- 



Brian Lloyd
706 Flightline
Spring Branch, TX 78070
br...@lloyd.aero
+1.210.802-8FLY (1.210.802-8359)
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

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

[Jim Harman]

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 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 in the field and will
> most likely not have Internet access. I need their clocks to be pretty
> close. I am shooting for 1ms ... if possible.
>
> The new M9F and M9T modules from Ublox are a bit pricey. The M8T is a bit
> more reasonable. OTOH I realize there are limits to how tightly I can
> control the Pi's RTC and will run into diminishing returns, so even the M8T
> might be overkill.
>
> Has anyone here figured out what the reasonable limit is for timing on a
> Pi, and what makes sense for a timing module for an application like this?
>
> Thanks.
>
> --
>
>
>
> Brian Lloyd
> 706 Flightline
> Spring Branch, TX 78070
> br...@lloyd.aero
> +1.210.802-8FLY (1.210.802-8359)
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>


-- 

--Jim Harman
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.