Posted: Fri Nov 12, 2010 2:08 pm Post subject: How to get accurate GPS timestamp for OnDataAvailable
I’m wondering what the best way is to get an accurate GPS time stamp to correlate with the data stream. I receive an OnDataAvailable event and I’m wondering if there is a corresponding alert that would send me timestamp information. Alternately, I’m wondering if there is an alert I can get when the data collection starts for a given frame. I’m also wondering how to correlate the 32 bit counter in an alert header with the GPS seconds of the week value. Here are the details on our collection scenario:
We have an EPC with two X3_25M cards and a Trimble GPS. An Azimuth pulse comes in to one of our X3-25M cards every 4 milliseconds or so. This pulse is sent to the second X3_25M card through the DIO. That card uses the pulse to generate a series of very fast elevation pulses(every 70 microseconds). When all of those pulses are complete will have a frame of data and the software receives the OnDataAvailable event.
At this point the software could go read the GPS and get a value but it seems to me that value would be subject to the latency of the Windows OS. I was wondering if there is a better more deterministic way. Specifically, Is there is some way to get an Alert packet from the system when the Az pulse comes in to the first X3 card? The snap example shows there is an OnInputTrigger but we aren’t triggering the A/Ds on this card. When we do trigger the A/Ds on the other card it happens at every elevation angle and that is too rapid for alerts.
Joined: 07 Mar 2006 Posts: 2267 Location: So. Cal. USA
Posted: Fri Nov 12, 2010 3:08 pm Post subject:
There is no simple way to reliably time-stamp the data packets on the current X3 and X5 modules without a firmware modification.
If using continuous triggering, one could route the GPS epoch signal into an available DIO pin on the module, custom firmware could latch the current sample count value and this value could be embedded into the unused header word of each subsequent packet, until the next epoch event. This would provide a means of correlating absolute time to each sample within the data set.
If triggering is non-continuous, a more sophisticated solution must be devised.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum