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
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.
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,
> >
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
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
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
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
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
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
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:
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/
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
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
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.
___
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”
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
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
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
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
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:
>
>
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
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
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
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
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
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
26 matches
Mail list logo
