Multifunction DAQ
NI PCI-7813R GPS 1pps/10Mhz synchronization
Henry,
The 1 pps is a pulse with 50% duty cycle, generated by the GPS device. When it is high, at most 200ms (IIRC) after a time message in the NMEA serial data is send. The serial data will occure just once per second, and IIRC, there is a A or V (indicating if its Absent or Valid, but it could be Available and V...?). If it is available, there will be a 1 PPS pulse, indicating when exactly the following message date/time it.
This is very inconveinient. It would be much more practical to get the time, and activate it on the pulse... If you are sure there is a signal every second, you could cheat, and read the time, add one second, and use this time on the next pulse. But that is dangerous...
The way I handled it was:
1) parse the serial data from the GPS. If there is a time message (, $GP??, not sure) get the date time. I think the GPS date time is a bit weird, I recall something about a 100 day cycle or something. I think you need to add some date information to get the real date.
2) I convert the date time to a U64. I think I use ticks from 1-1-1604. It doesn't really matter. The U64, where 1 is 25 ns from 1-1-1604 gets you some 1400 years.
3) on the FPGA, I have a timer loop (a SCTL). It gets the U64 from a control from the PC. You could als o use a FIFO. So now when I get a pulse (upgoing edge), I start counting ticks. When I get a update from the PC, I know that time plus the counter is the time at that moment. So I set that time to the actual time. If there is no update, the actual time is simply increase by one.
4) The actual time in the loop is put in a local (a buffer VI is less usefull, I use the time in a normal while loop which is not allowed for sub VI's). The local makes available the current time through all the FPGA code.
I used a time out on the serial data update. If the update happended more then 600 ticks after the pulse, I disregard it (not sure if this ever happened). This is easy to implement, since you keep a timer that is reset by the pulse.
This results in about 375 ticks (IIRC) adjustment each cycle with the FPGA clock. About 25 ticks (IIRC) with the PXI backplain clock, and 3 ticks with an external clock wired to the backplain.
So the error you get is basically the maximum nr. of ticks you can get in a cycle.
You can go futher. I did succesfull experiments, but we didn't need it. If you know what the adjustment is (lets say 3 ticks), you can skip the increate of the actual time 3 times in the 40000000 ticks cycle. In my experiments, I send the 1 Hz adjustments to the PC. Do the quotient & remainder logic there, and set a control on the FPGA so it will do the skipping. Using this trick, the accuracy will be the jitter in the error, instead of the error itself.
Most time will be the testing. After years on using it, we got a even more accurate clock reference, and found out there was an error in the code. The clock reference caused the error to be 0, and that was not handled properly. All of a sudden the adjustments where -1,1,-1,1,-1, etc, instead of 0,0,0,0,1,0,0,0,0, etc. I had to set the initial counter of the pulse to 1, instead of 0...
I hope this helps. If you have more questions, please let me know. But I can't provide code on this one (it's not mine to give). There is a presentation that I gave years ago about it here: http://www.carya.nl/index.php?catid=720&lang=nl ( the NI Days NL & BE 2007), and I think it shows a lot of details about this. It's not updated to reflect the latest changes though.
Regards,
Wiebe.
Search LabVIEW like a graph! Henry,
So if you manage to get a loop that set a local to the acurate time, other loops can read that local. The other loops (any number of them) can simply compare a date time (specified as U64, probably set by the PC) with the local.
I did a little bit more. I have a very complex "scheduler". What it does is easy though. It checks what "measurement" (they are transmissions in my case) needs to be done first, and at what time. It then uses this time to compare it with the GPS time. You need to do this in a loop (don't use a wait, because then you are not using time updates).
So the 1 PPS is used to get an acurate time, in the form of a local. Measurements use this local to compare their start time.
Regards,
Wiebe.
Henry,
The time you get from the GPS through the serial port is not deterministic (it might be, and probably is, but it does not have to be). The 1 PPS pulse is the moment the previously send time becomes active. Much like the old phone time sevice, "at the next beep it will be 15:44. ...beep...".
In our application we use a PC to parse the serial data. By the time this data went though the serial buffers, windows, LabVIEW, to the FPGA, the time might be delayed by anything between 1 to 300 ms. Who knows? It probably changes depending on what windows and all other processes are doing. But the 1 pps makes it very accurate.
If you want to do a measurement every second, and you can guarenty there will be GPS reception, you can trigger measurements with the 1 PPS pulse.
In my application, message can be programmed at specific times. Each measurement start time can be scheduled by 25 ns ticks for a time range of 24 hours (although >1000 years is possible).
What triggers a measurement is that the time has arrived to do the measurement. If the start time is 519713280000000004 ticks from 1-1-1600, and the actual GPS time is 519713280000000000 , I have to wait another 4 ticks... If the actual time is 519713280000000006, I'm 2 ticks late. The latter example can actually happen if there was a time update of 2 ticks or more. In my application measurements can also be late if the previous measurement took too long (if they where scheduled too close together).
Regards,
Wiebe.
