Time Stamps


gerwiz

Recommended Posts

I am using a Labjack UE9 Pro to log 7 channels of data plus a GPS data input from the computer's COM port. I need to know when the data has been scanned so that it can be matched with GPS time, so one of my 7 channels is taking in the 1PPS signal from the GPS. I am using DAQFActory Express to receive and log the data. In order to know when the 1PPS pulse starts, I am sampling, using the Timing value of 0.01, and sampling the rest of my data at 0.1.

My question is this - if I am polling with the DAQFactory timing, what is driving this timer, and what determines the timestamps in the log file? I read in the helpfile that one DAQFActory starts, it uses the high precision counter to determine the current time, using the system clock only to retrieve the initial time. Is this high precision counter the 750KHz clock in the Labjack?

Best Regards,

Gerry

Link to comment
Share on other sites

The Windows high precision clock drives the timer. This is not the same as the clock on the LabJack. It can't be as the communication between the LabJack and Windows has around a 4ms latency. The windows high precision clock I believe is the clock used for pacing things like audio and video. Its precise to 100ns, though DF rounds this to 1 microsecond so the full absolute time stamp fits inside a 64 bit floating point value. The timestamp in the file is the time when DF receives the point back from the LabJack. With PCI devices this is probably within 100 microseconds of the actual reading. With a USB device, however, such as the LabJack with its 4ms latency, the timestamp DF gives the data point is likely between 3 and 5 milliseconds behind the actual time of the data reading. This is a hardware limitation, not a software one. The only real way around it is to use streaming mode in the LabJack so that the LabJack paces the clock, but even then, although the precision of the timestamps will be much better (because the latency with each reading is removed), the accuracy is still likely to be 3-5 milliseconds behind.

As I said, these are hardware limitations of using a USB based device. If you need high precision in syncronization, you either need to sync in hardware, or use a PCI based device.

Link to comment
Share on other sites

Thanks, so what would be the best approach with my setup?

If I use streaming, and read the channels and capture the Labjack system timer as well, will this record the difference in time between the 1PPS going high and when the other data channels are scanned, assuming I can use different scan rates for different channels in stream mode?

Can you advise please?

Regards,

Gerry

Link to comment
Share on other sites

You can't use different scan rates, but you can scan everything at 0.01, and then have DAQFactory average down all the slower signals by 10 samples to get 0.1 second data.

But why are you syncing to GPS time? What is your goal here?

Link to comment
Share on other sites

The independent system integrates GPS data with other data and logs this in a separate application. I am using a different GPS antenna into the Labjack, and simply need to time match the data. I guess it should be possible to have DF configured to log all the data, but it seemed simpler for now to just take the log files from both applications and select the matched up data.

Link to comment
Share on other sites

OK, but even if I log the GPS data in DAQFactory, I still need to know the difference between GPS time and the time of the channel scan, hence my question about capturing the system timer on the Labjack as a means of referencing this. Is this a good appraoch? If so, what's the best way to configure DAQFactory to do it?

Link to comment
Share on other sites

The 1PPS occurs every second for a period of 100ms. At the moment, I am using DAQFactory to sample this at 0.01s, so I am picking up the leading edge within 0.1s. This is probably within our current acceptable tollerances. If we are sampling the data at 0.1s, I believe we should be able to reference the data samples to the time the pulse occurred at the same accuracy? However, if we were able to trigger a scan from this pulse, will this not increase the accuracy, as we should then know precisely when the pulse occured?

Also, for clarification, I'm not specifically concerned about sampling the data at the same time as the pulse occurs, as long as I know when the data was sampled with reference to the pulse, so I can apply the correct time offset.

Hope this makes some sense.

Link to comment
Share on other sites

I'm asking because probably the easiest way to do this is to get it so your Windows system clock stays perfectly in sync, and then have DAQFactory use the system clock instead of high precision clock. You'll lose precision (down to about 15ms), but accuracy will be higher. I'm not sure how to make windows update its clock from an NTP server. I think you can force it using "net time" from the command prompt, which means you could have DAQFactory trigger it using system.shellExecute(). Your GPS may also support NTP, in which case you could have Windows sync directly to the GPS time.

Link to comment
Share on other sites

Thanks, I know there are ways of keeping the Windows clock in sync with GPS, but I'm guessing that there will be varying delays between sampling the data and it being received by DAQFactory, including potential delays caused by PC applications, and other systems using the same network (I'm using an Ethernet connection to the Labjack). My assumption was that these delays would not apply if I sampled the Labjack timer at the same time as the data, hence the question about using streaming and triggering this from a known time, ie. the 1PPS pulse?

Link to comment
Share on other sites

You could trigger a scan from a pulse I believe (you'll have to ask LabJack how) and that will align the data but the time stamps on triggered streaming will be wrong. DAQFactory has no way of knowing the time with triggered because the data comes back from the LabJack in chunks. So, high precision, abysmal accuracy in time.

Link to comment
Share on other sites

Yes, Labjack have given me sequences to set up a triggered scan (attached). I tried this as is, using the 5kHz timer to trigger, but looking at the resultant log file, it didn't record the timer? Not sure why?

My hope is, that if this code can be made to work using my 1PPS as the trigger pulse, then if the Labjack internal timer is used to timestamp the scans, I should be able to reference these to the trigger pulse, which is tied in to GPS time. Then I don't need to rely on the timestamps from DAQFactory.

Does this make sense?

UE9_Ext_Triggered_stream.ctl

test_01.txt

Link to comment
Share on other sites

You aren't getting values for the timer because the channel is setup incorrectly. On the LabJack, when you stream, everything is an A to D on the software side. That's why you use the virtual A to D channels 200 and 224, even though its timer 0. This is just how the LabJack folks implemented it. DAQFactory doesn't know anything about the virtual channels, so to it, its still an A to D. So, just change the I/O type for all your stream channels to A to D.

Link to comment
Share on other sites

Thanks, got this working. After futher communication with Labjack, they suggested using the Triggered Stream example (attached). However, when I set up a log file, the time recorded against the stream samples are all the same (see attached example) but the COM1 channel is being timestamped correctly? It seems to record the start time for the first sample (on first trigger pulse) and then stamp every subsequent sample with that same time. Can you confirm if this is as expected, and explain why?

In the example, there is a V channel set up called TheTime, which I think only records the timer values from the Labjack (channels 200,201,224 and 225) but I don't appear to be able to log this in a log file?

Your advice would be appreciated.

TriggeredStream.ctl

testlog4.txt

Link to comment
Share on other sites

I have been working on this today, and managed to get a config that seems to work. However, I have 2 problems which need resolving. Firstly, the timestamp on the streaming data (as mentioned before) - why are all the captures timestamped with the start time of the stream?? Secondly, whenever I start the sequence it runs for a time (this varies each time I restart) and then the captures stop in DAQFactory, but the Labjack appears to keep sending data (COMM light comes on at periodic intervals). I'm a bit confused about what is happening?? Have attached my config file if you can check please?

TriggeredStream_mags.ctl

Link to comment
Share on other sites

As I mentioned, with triggered stream, DAQFactory has no way of knowing what the correct time stamp should be for the data since the data is sent to it in blocks. So, it just gives all the data points the time of the streaming was started. With regular stream mode, DAQFactory is able to query the LabJack for the interval between data points, and thus can calculate the time stamp based on the start time and the interval.

As for the second part, I can't say. Do you see any alerts? Is there perhaps no trigger?

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.