How accurate can a data "time stamp" be made for a GPS with the Propeller?

ElectricAye

Hi all,

I've heard that a GPS system can allow you to "time stamp" data down to 100 ns or 100 microsecond resolution. I'm wondering if that's true, if it takes special GPS receivers, etc. and what sort of accuracies are possible with a Prop-based GPS. I'm guessing that the GPS itself does not give 100 ns resolution but instead the microprocessor is interpolating with its internal clock or something.

Anyone know anything about this sort of thing?

thanks,
Mark

Timmoore

GPS receivers output a 1PPS (1 pulse per sec) signal. This can be used as a sync pulse for the NMEA output time. The accuracy of this varies from GPS receiver to reciever. e.g. see http://www.gmat.unsw.edu.au/snap/publications/mumford_2003a.pdf for a comparsion of some receivers. You could input 1PPS into a prop and use it to sync to the NMEA time this would get you a more accurate timestamp.

Cluso99

The GPS receivers actually receive the time signal from the satellites, so the time is accurate. How accurate - I don't know. However, that is how the GPS determines where you are. Obviously, there is an internal delay before the GPS outputs this time stamp to NMEA, so once again I don't know how accurate this will be.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Javalin

The GPS will be nano second accurate internally - cause it has to be. The good ones will allow you to configure the PPS pin to certainly in the Millisecond range.

The "survey" class GPS unit's can output more satelite data for use with RTK calculations.

Look at www.u-blox.com - the TIM or LEA 5 series allow for PPS pin customization and will output time in ms - i.e. 13:01:11.001 for example.

james

ElectricAye

If I tried to use a GPS-based system for time stamping data, all the units downstream of the GPS would be the same, and as long as the data from all the different units is time stamped accurately for one unit relative to another, the absolute delay would not be a big deal for me. However, even though the units might be made identical, I don't know if the processing delays for those various units would be so jittery that it would kill any accuracies between them. I don't know anything about GPS, so please excuse my clumsy explanation of what I'm asking for.

thanks you guys,
Mark

matb

I expect the NMEA output will have heaps of jitter, but will depend on the GPS unit.

We tried it once years ago, from a PC. Using nmea only, the couple of different units we tested, the jitter was over 500ms! We switched to use a specialised GPS receiver with PPS output.

DogP

Yeah, definitely take a look at the PPS output. I'm using a Prop to trigger a camera off a PPS output from a Venus GPS unit (http://www.sparkfun.com/commerce/product_info.php?products_id=9133). I don't need nanosecond accuracy, so I just use spin, but you could dedicate a cog in ASM to trigger on the PPS. IIRC, the error of the PPS output on the Venus is 60ns RMS (which is probably better than you need w/ a prop, since w/ an 80MHz xtal, each clock cycle is 12.5ns, so you're not gonna get a perfect reading).

I assume you're trying to timestamp something when it happens, and not trigger on the second? If so, I'd have a variable that saves the cnt value at the instant the PPS happens, then when the other action happens, save that cnt value and determine the difference in time. Of course this will only be accurate to the accuracy of the crystal, which for the 5MHz xtal is +/-30ppm, which then flows through the PLL, so at 80MHz, you could be +/-2400 cnts from the actual value, or +/-30 microseconds off by the end of the second (and if you're comparing between multiple props, each one can/will be different). You can probably correct a lot of this error though, by logging difference in cnt at the next PPS and determining how many counts were actually in that second (there should be 80 million, but if you see there's 80.000100 million, then when computing absolute time, just use that number to divide by instead).

Crystals are very sensitive to temperature though, so if the temp is changing rapidly throughout the second (like if it's outside with wind blowing on it), then you'll probably want to use a better oscillator, or at least shield the crystal from the elements, since the clock ticks won't be uniform.

DogP

David B

My Garmin GPS25 sensor documentation claims that it delivers +/- 1 microsecond accuracy at the rising edge of the 1 PPS pulse.

I thought I remembered some document saying they also timed the start of the serial data pulse to the start of the second, but as of this morning, I can't find any reference to that, or any claim of its accuracy, in the PDFs I've got now.

DogP

Yeah, typically the serial data starts transmission on the PPS, but at 9600bps, it can be a long time before you actually get your data out of it (and it's not really convenient to watch for an edge on serial data like it is to watch for a PPS line). I typically watch for the PPS, then I know what time that PPS was by reading the GPS data that follows it.

DogP

ElectricAye

Thanks, guys,

This is great stuff. Your inputs have given me plenty to chew on for a while.

bless you all,
Mark