I see that many GPS modules have a PPS (pulse per second) pin on them. As is often the case, the datasheet doesn’t provide a whole lot of color as to the meaning/use of this pin.
Does this normally provide a pulse just before it starts sending NMEA data? If so, I’d like to tie that pin to an interrupt on change pin and go from there.
If not, what is the pin normally used for?
It’s usually connected to an LED - when it flashes one knows that the unit is working. The signal can also be used to lock an oscillator.
Thanks.
Now that I think about it I can just use the “UART Rec Done” type interrupt on the PIC anyway. Is there any rhyme or reason to how the NMEA sentences are normally sent out in terms of time or order.
Just parse the headers to get the ones you want, on the fly. It’s quite easy.
The 1PPS signal can be very valuable. The pulse will normaly occur at the “top” of the second with a certain amount of jitter. Often the jitter is measured in the nanoseconds but for some units this might be a handful of microseconds. If you are trying to get multiple computers at remote locations to do something at the exact same time, then you can use the PPS signal to synchronise them. You can also use the PPS to get a highly accurace RTC since the GPS PPS will not drift over time. Each pulse may have some jitter, but over years, the PPS will be dead on.
PS: Do not confuse PPS (Precision Positioning System) with pulse per second.
The PPS signal is extremely useful in accurate timekeeping because the keeping of accurate time using a GPS requires two parts.
is the data stream - however its delivered (via ascii, or a binary format) which will typically keep repeating the current time …(for example, the various NMEA sentence formats) BUT THE TIMING THOSE SENTENCES ARE DELIVERED IN IS UNRELIABLE. (So, you usually dont know when the second changes with any precision.)
is the PPS signal which is typically delivered ONLY when the GPS has a high quality fix. But it does not tell you the time AT ALL ; however it does tell you the instant the time changes, which it is next to impossible to get with regularity from the other stream. (or over USB, because USB’s timing changes)
If you have a USB-connected GPS, for that reason, its difficult to impossible, to get a stratum 1 quality time signal from one (which is the whole point, otherwise, just use the net servers) unless you can access the 1PPS pulse.
(Or set up a system based on receiving WWV - which is also pretty easy, just connect the receiver to your sound card to receive the time signals and get the mixer level adjusted correctly. That can be done to test the accuracy of any GPS-based clock you build.)
Any USB-based solution is going to have more jitter than is ideal at best, (45 msec) or be almost as bad as the on board local clock, far worse than a net supplied stratum 2 or 3 server…
The jitter using a stratum 1 time server over the net varies, but it can often be better than that, depending on latency in the intervening hardware “bufferbloat”
So, having a super accurate clock can be super useful in seeing the effects different hardware have on net traffic.
USB can work, it may be more stable than a net connected stratum 1 server under some conditions… but all bets are off if the USB is connected through a hub or the machine is loaded.
So for most people its not so great - its discouraged, even though its possible.
You can supply the 1PPS to a computer via the DCD pin in RS-232 or the parallel port or probably other methods. The 1PPS doesn’t need to accompany the NMEA datastream on the same port. (there is no way to do that accurately with USB)
Almost anything is better than USB.
This is turning out to be a lot more interesting than I had thought it would be.
Here are some resources on time server issues:
http://groups.google.com/group/comp.protocols.time.ntp/
http://support.ntp.org/bin/view/Support/ConfiguringNTP
http://support.ntp.org/bin/view/Support … gRefclocks
http://lists.berlios.de/pipermail/gpsd-dev/
http://www.satsignal.eu/ntp/NTP-on-Wind … -port.html
http://linlog.blogspot.com/2009/07/sync … pspps.html
http://research.microsoft.com/en-us/um/ … ime-clocks
The reason I have all these links handy is because I came here looking for help with a related project. I am going to try bypass the USB by connecting directly to the PPS on a cheap USB doggle I just bought for $18 that turns out to have a quite sensitive receiver… a skytraq venus 524c.
But I need to find the PPS pin first. If the pins are the same on the 524c as they are on the 521, I’m okay, but thats a big risk… I’d rather know for sure. The board is very small and the connections are tiny. It combines the GPS chip and an active antenna. It’s the same size of - it looks like a USB flash drive.
If anybody knows the answer, let me know in the follow up to the post I’m about to make (I’ll post about it separately.)
If you plan to use a GPS for timekeeping, you are best off if you configure it to only output one of the available NMEA sentences per second. Just one. The one that I most often see used in that context are GPRMC or GPGGA, (not both, which will confuse the refclock driver!)
Then you have to use the “mode” switch in NTP to tell the driver which one you are using.
The baud rate does not matter except that older versions of NTP only work with 4800 baud reliably. And then only with this shortened, single sentence NMEA, delivered exactly once a second.
If you have access to the 1PPS, the need remains if you want the reliability. It seems wise to follow their instructions (or get ready to spend hours or even days monkeying with the configuration before you get an acceptable outcome.)
While doing research, the SkyTraq chips have a “sync to UTC second mode”, which in practice means the startbit of the “$” in the first sentence will occur 1 millisecond after the rising edge on the PPS signal, but only if you set 1Hz rate. However if you set it, at 115200 baud the NMEA will be a burst, so you just need to find the $ character that is at least 1/2 second away from any previous ones. Those will be 1 second apart, and on linux there will be about a 1-3 mS delay if you are using standard system calls.