Unfortunately, it appears that the 5644R does not properly timestamp each record of a multi-record acquisition. This is documented here:
"Note The value of the absolute timestamp returned is always 0 for the PXIe-5644/5645/5646, PXIe-5668, and PXIe-5820/5840. The value of the relative timestamp returned is always 0 for the PXIe-5644/5645/5646."
So...no timestamp for 5644R ever. Is there a workaround? I'm using an IQ power edge trigger. I'd like to see in detail the signal that a 3rd party device is generating. I'd like to see as much of the signal as possible, with a bandwidth that captures the whole signal. What I really want to know is how often it is transmitting, and what each small burst looks like.
If I have the number of samples cranked up and the IQ rate cranked up enough to see what I'm looking for, I'm either out of memory on the device, or (before that) my machine is swamped with so much data (and likely copies of that data in LabVIEW) that the machine crawls to a halt. Grabbing one large acquisition is not practical.
I have written a VI that uses IQ power edge triggering to capture several smaller acquisitions, each with a duration of 750 us or so. I was planning to use the timestamps on each record to piece together the story of the transmission, minus the uninteresting long stretches of noise. Well, I can see each burst, but I have no idea of where they occur in time.
I know I can buy LabVIEW FPGA, dig through the fpga code, and create a workaround for this. However...that's a lot of money and time.
Has anyone in the community worked around this already? If so, would you be willing to share the FPGA image with me here? I think NI-RFSA will let me over-ride the FPGA image that the driver normally uses with a custom FPGA image. I'm still not sure whether that's useful without a LabVIEW FPGA license. I would have no way to read back some custom value/property from the custom FPGA without LabVIEW FPGA.
Any other ideas? I know I'm not the only one trying to analyze traffic with lots of dead time in it.
Solved! Go to Solution.
Oh, here's a workaround that will help me:
I can query records done in a tight loop on the CPU. When Records Done changes, record the time (High Resolution Relative Seconds.vi) when it changed. If I record the time on the loop before the change and the loop when it changed, at least I know a window of where the IQ power edge trigger occurred. That is software timed (blech), but better than nothing.
I'll give that a try, and post the result here it if works well.
On my system, polling 'Records Done' in software takes just under 200 us. This is not the timing resolution I would have wanted, but it's giving me enough info to guess where the real edge is. The real edges should be on a 5 ms raster.
Code is attached, for whoever might run into a similar problem later.
Interesting problem, and a quite out of the box workaround.
Another idea that the more I think about it, the more I think it will not work. But the idea goes something like this. See if it is possible to route the IQ Power Edge trigger to an advance record; if so, then then from the host query number of records done and number of samples that got acquired on the previous record(s). But because the size of the records have to be finite for an infinite number of records, I'm pretty sure this will not work. But maybe there is a clever way to use finite records that can give you the timing resolution and then you query for number of records, but then you wouldn't be able to properly advance to the next record only upon getting the event.
Something else along the lines of your original idea, is to only fetch subsets of the data on the host and write that code as efficiently as possible (using a pretty fast CPU).