Re: [time-nuts] GPS message jitter (preliminary results)

Yes, I know about those. I think the ubloc line has a version that does this but it is made for the automotive roadmap type display. I think the way to learn is to jump in and make one. Start by re-implementing an example filter then go the next step and the next. On Thu, Jul 21, 2016 at 7:34 A

[time-nuts] GPS message jitter (preliminary results)

I bit bang serial all the time... it is much easier if to do if you are only banging serial output. Reading serial streams at higher bit rates while doing other useful stuff can be challenging... particularly if you don't have a timer handy. I once coded up a PIC to output a time code / sta

Re: [time-nuts] GPS message jitter (preliminary results)

Here is an interesting discussion of Kalman filtering. http://math.stackexchange.com/questions/173901/why-use-a-kalman-filter-instead-of-keeping-a-running-average Thomas D. Erb t...@electrictime.com / Electric Time Company, Inc. Office: 508-359-4396 x 117 / Fax:

Re: [time-nuts] GPS message jitter (preliminary results)

> On another note, I did some jitter measurements on Jupiter-T and Jupiter-T > Pico receivers. > I can't imagine how they do it, but those things are insanely good. Running > at 9600 baud, > their message jitter into a hardware serial port is less than a millisecond > peak-peak! > Somebody p

Re: [time-nuts] GPS message jitter (preliminary results)

If your not bean counting for a commercial product you can take a look at particle filtering, its like a real-time monte-carlo simulation. The location estimate in NEMA is also heavily filtered and referenced to its utc time estimate (PPS). Conceivably could be filtered to a bandwidth of Fs/2, 500

[time-nuts] GPS message jitter (preliminary results)

A lot of the newer GPS modules can accept "dead reckoning" data from external sensors and integrate that into their location solutions. The receiver does all the Kalman filtering foo for you. Also you can get receivers with up to 50Hz position updates (you have to run the com link at very hig

Re: [time-nuts] GPS message jitter (preliminary results)

I might have been the one who brought up the problem of the NMEA message not being right on the UTC send tick. But now I'm thinking of another problem this might create. It is slightly off topic because it has to do with location. Let's say I have a mobile robot (or a self driving car) that wa

Re: [time-nuts] GPS message jitter (preliminary results)

To answer about how they get good timing. Many times you run a loop that runs off a timer at say exact 1000 times per second. Having something like a 1KHz loop gives very deterministic timing. Lots of ways to do it. One is to run some RTOS. I had to make all the axis of a machine tool move at ex

Re: [time-nuts] GPS message jitter (preliminary results)

HI > On Jul 20, 2016, at 7:51 PM, Mark Sims wrote: > > I added the ability of Lady Heather to calculate the time offset of the > timing message from "wall clock" time. It calculates the difference between > the system clock time to the time that the (end of) the timing message > arrived.

[time-nuts] GPS message jitter (preliminary results)

I added the ability of Lady Heather to calculate the time offset of the timing message from "wall clock" time. It calculates the difference between the system clock time to the time that the (end of) the timing message arrived. The result is only as good as your system clock, so the system c

[time-nuts] GPS message jitter (preliminary results)

I ran some tests on the message timing of some V.KEL gps receivers in both NMEA and binary mode. These receivers are the cheapest ones I have (3 for $15 - $20, shipped). They use a SIRF III chip and have an on-board ceramic patch antenna. They performed amazingly well. No problems tracking

[time-nuts] GPS message jitter (preliminary results)

My LEA-6T board came out of one of those cheap Chinese drone pucks. It has a ceramic patch antenna on board. I have it sitting on the floor of the lower floor of a two-story, stucco over wire mesh house (not close to any windows). Same for some Sirf, Venus, and standard Ublox receivers.

[time-nuts] GPS message jitter (preliminary results)

Yes, turning on the display filter only gives an indication that one could gain some some benefit if they were to use the message arrival timing to implement some sort of NTP-ish algorithm to their 1PPS-less clock. I have added some options to Lady Heather calculate the adevs of the message ar

Re: [time-nuts] GPS message jitter (preliminary results)

is that you are changing the "tau" of the std dev. At this point you're much better off not to use raw or filtered std dev at all -- and just go with ADEV on the raw data, where the tau of the sigma is explicit. /tvb - Original Message - From: "Mark Sims" T

[time-nuts] GPS message jitter (preliminary results)

Most definitely... if I turn on Lady Hather's display filter (which does a sliding average of "n" readings) the standard deviation and jitter values drop dramatically. With a 60 second filter the deviation was down to around .15 msecs and the peak-peak jitter below a millisecond. Average and

[time-nuts] GPS message jitter (preliminary results)

I have seen some reports of some Skylab GPS boards that had some rather sketchy GPS code. A friend had one that was off around 0.5 degrees in longitude... but only if your location was between +/- 90 degrees longitude. He was on the east coast and had the problem. He sent it to me (96 dgrees

Re: [time-nuts] GPS message jitter (preliminary results)

Hi Very nice data !! Hmmm….. software averaging against the MCU (or FPGA) clock source … NTP seems to get some pretty good results down into the single digit ms (or lower) doing that based on some equally jittery inputs. Looking at the data by eyeball (maybe not the best way): A 10 to 30 s

[time-nuts] GPS message jitter (preliminary results)

That plot was from a 12 hour run. I've done 48+ hour runs and did not see anything strange. I'm not currently measuring the offset of the message from the 1PPS, just the stability/jitter in the timings of the last byte of the timing message. If the timing message offset time from 1PPS jum

Re: [time-nuts] GPS message jitter (preliminary results)

> most receivers get the time messages out within a window less than 50 > milliseconds > wide with a standard deviation of less than 10 milliseconds. Hi Mark, For comparison with your data, attached is the ADEV+MDEV plot [1] for the SkyLab / MG1613S GPS board [2], the one with the 350 ms offset

Re: [time-nuts] GPS message jitter (preliminary results)

Yo Mark! On Mon, 18 Jul 2016 18:30:08 + Mark Sims wrote: > A few generalizations: most receivers get the time messages out > within a window less than 50 milliseconds wide with a standard > deviation of less than 10 milliseconds. How long did you run your tests? My experience is that the

[time-nuts] GPS message jitter (preliminary results)

Ooops, that tboltjit.gif plot was actually from a Trimble Resolution-T SMT timing receiver running with an indoor antenna, not a Thunderbolt. The Thunderbolt with an outdoor antenna is about twice as good. I just added the ability to feed the timing jitter value to Lady Heather's real time AD

[time-nuts] GPS message jitter (preliminary results)

I added the ability for Lady Heather to measure a plot the difference of the arrival times of each timing message (actually the time when Lady Heather receives the last byte of the timing message from the operating system). The end-of-message arrival time is time stamped to nominally nanosecon