05-31-2013 03:09 AM
Hi this is Lee.
I'm using NI 9467 with 9024&9111.
I want to log the data with PPS trigger so I'v done it as attached.
I think PPS is must be start of my data, but it has 8ms delay. (5k sampling)
It means that my 9467 and FPGA timekeeper metronome example give me 8ms eariler trigger.
Is this known problem? Did I done something wrong?
Thank you.
Lee.
Solved! Go to Solution.
06-07-2013 03:33 PM
Lee,
The way you have your code right now the sample loop should go at 1Hz, but there is nothing to sync it with the PPS. The metronome's rate is tied to the GPS time, but not its starting point. If you combine the two loops in the right way, that would work.
One way could be to use an occurrence to trigger the acquisition. Or you could simply merge the two loops so that the acquisition begins in the second frame of your sequence structure.
06-09-2013 07:14 PM
I didn't catch that 9239 has a time lag between actual acqusition time and output data. Now I add time correction so it works fine.
01-27-2017 03:47 PM
Hi,
I am also trying to sync the 9239 module by using the PPS signal from 9467. As I saw you already did some working example with 9239 and 9467. Any ideas or examples maybe?
Thank you,
01-27-2017 04:00 PM
TinoMK,
The above example (with some corrections) is one way to do it. The correct answer depends on the kind of acquisition you want to do. If I remember correctly, this example was for a 1 Hz measurement, so it won't work for something running at a higher speed.
For a tool to help with higher speed acquisitions and synchronizing them to GPS time or PPS, take a look at the FPGA Timekeeper.
Thanks,
Andrew
01-27-2017 04:52 PM
Hi Andrew,
Thank for your reply! That is exactly what we are trying to do: I am trying to combine the pipelined data acquisition example for DSA analog acquisition with FPGA time keeper sync with GPS example BUT I am always getting an underflow error when trying to wait for PPS before making the reading from the AI channels of 9239.
Any ideas?
01-27-2017 05:00 PM
Ah. DSA Acquisition. That's why.
DSA modules have their own internal clocks. Once you begin acquisition, they are always oversampling and filtering. Non-DSA modules have their acquisition clocked by the FPGA code that calls it - that's why the FPGA Timekeepr is good for them.
I don't remember off the top of my head if you can sync a DSA module from a GPS module - because of the internal clocks.
01-27-2017 05:13 PM
HI Andrew,
Thanks again. So what do you recomend for syncing multiple cRIO's (9063) with 9239 and 9467 each. Sampling rate is 1KHz. The need to be synced via GPS in order all of them to have same start time of acquisition every second.
Thanks,
01-27-2017 05:17 PM
TinoMK,
I think that is more likely to be successful here is to have the modules time themselves. What the FPGA Timekeeper can then do is provide a timestamp for each sample (record them like X/Y pairs). Then, even though you didn't control when a sample was taken, you know precisely when it occured.
Then the data can be correllated. If the data also needs to be time aligned between targets (certain kinds of analysis require this), you can resample/interpolate the data in post processing to find time-aligned points.
08-22-2019 09:02 PM
Hi All,
I am using NI 9467 to synchronize with NI 9234 + cRIO 9045. I have implemented the FPGA timekeeper code - as attached.
The GPS timestamps and FPGA timekeeper timestamps are saved into separate FIFO for checking only. I use FPGA timekeeper to provide the timestamp correspond to each measurement. Data are saved as wf in the RT part and write to file.
I assume that the wf_start_time should be the start timestamp of each data point. This should be very similar to the first GPS timestamp or FPGA timekeeper in the file. Then, based on the sample frequency and duration, I can do the interpolation of timestamp.
However, my results show that wf_start_time is very different from the first GPS timestamp saved in the file.
Can anyone help me to see which part I am wrong or any mistake in my logic?
Very appreciated!
Ella