RTC deviation in comparison whit GPS time ?

Ltech

I try to find how to know when the next second start from a nmea gps sentence
I try to find the deviation of rtc time by using gps time

Using the "GPS_Float" Object
The problem is when do I have lo read the rtc time for making the comparison ? " IfNot rtc.Getseconds == GPS.Long_Second Do update rtc "

The GPS.Long_Second is already in the string for a while when I read the rtc .....
On the LCD my seconds do not always jump at the same moment.

JonnyMac

Even if you achieve perfect sync once, it won't stay. Your RTC is being driven by a clock source that is not nearly as accurate as the source driving the clock in the GPS satellite.

max72

Check you GPS datasheet. Usually there is a 1pps port, with a small delay.
If the datasheet is well done you'll have detailed description of the 1pps signal and a delay range for your pps signal.

Massimo

ersmith

I tried to do something similar (looking at the time of arrival of NMEA sentences to try to get sub one second precision) and had little luck, even with running the receive code in another COG. I found the time between GPGGA sentences varied by +- 100 milliseconds according to the Propeller CNT register, and while I'm sure CNT is unreliable I don't think it's that far off. As Massimo said, you'll probably have to hook up the 1pps line to get an accurate indication of when a second starts, rather than relying on the serial port.

If you want, here's the code I used for testing (it's for PropGCC rather than Spin, that's the environment I'm most comfortable with). There are two .binary files which you can run with the regular Proptool. printall.binary prints all sentences with timestamps (based on the 80 MHz CNT) and delta between arrival in cycles and milliseconds; examinegps.binary prints only the GPGGA sentences, which are the first ones my GPS sends. The binaries are compiled assuming the GPS is talking on pin 4 at 4800 baud.

Output looks like:

   426577801   71770672 ( 897 ms)::$GPGGA,021923.000,44XX.3900,N,063XX.4599,W,1,06,1.7,47.2,M,-23.1,M,,0000*45
   506793065   80215264 (1003 ms)::$GPGGA,021924.000,44XX.3902,N,063XX.4599,W,1,05,1.7,47.5,M,-23.1,M,,0000*45
   586958361   80165296 (1002 ms)::$GPGGA,021925.000,44XX.3903,N,063XX.4600,W,1,05,1.7,47.7,M,-23.1,M,,0000*44

which gives the time of arrival (in cycles measured by CNT) and difference from the last sentence (in cycles and milliseconds, again as measured by CNT). "Time of arrival" is the value of CNT when the first bit of the sentence was received, and is measured in a separate COG for accuracy. As you can see there's considerable variation in when that sentence arrives, much more (I think) than the error in the Prop's RTC.

jmg

ersmith wrote: »

I found the time between GPGGA sentences varied by +- 100 milliseconds according to the Propeller CNT register ... hook up the 1pps line to get an accurate indication of when a second starts, rather than relying on the serial port.

Certainly 1pps will be much more precise than Serial, but what does the long term sync of the Serial look like ?
A simple tracking lock, could remove short term jitter, to get down to something useful without needing another pin for 1pps ?

eg Two of your numbers differ by what looks close to 3 bit times at 4800 (within 1.0006404)

max72

As long as there is gps signal you have time in sync with the atomic clock on the satellites.
So do you need precise (ms) timing or do you want to get rid of long term drift?
If you accept a little jitter getting time from the serial stream on the long term will have less drift than an RTC. As long as you have GPS signal..
Massimo

jones

Ltech wrote: »

On the LCD my seconds do not always jump at the same moment.

The only requirement imposed by the standard is that the NMEA data for a particular second be output in that second, there is no synchronization of any part of the NMEA data with the start of the second. That's the purpose of the PPS signal. On the Garmin OEM devices I've used, there is no delay; the leading edge of the PPS signal marks the beginning of the second to +/- 1 microsecond. As others have stated, you can use the NMEA data for long-term correction, but not to find the start of any given second.

Ltech

Thanks for the tips.
First I just need to sync my rtc, but how can I do it at the best time
I need to get it under the 1/30 of a second
When I get the right timing of second change (trough 1sec puls :-) ) I can anticipate the next second and wait the right amond of time for update the rtc
I use the gps time for normal use, but need a backup with rtc ( startup after power douwn, and "short" inside use )