LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Data acquisition of 16 analog channels using NI 7951R FPGA

Hello everybody,

 

I'm trying to acquire 16 channels continuously at 1.25 MHz (sampling rate not that important as long as it's more than 0.5 MHz) in LV FPGA 2020 SP1 and then read them in LabView (actually I also write them to a binary file and check the data in python, but the error occurs way before). I'm using an NI 1071 chassis, NI 5751 ADC, NI 7951R FPGA, NI 8375 Fiber Optics cable.

 

The way I had implemented the code was to "join numbers" of 4 analog channels (16-bit digit precision per channel) into one 64 bit integer that I could send through a DMA FIFO to the PC. Then, in the PC code, I "split channels" and create an array out of it. Doing so allows me to read continuously and with pretty good results 4 channels per DMA FIFO. The problem arises because my FPGA Target is limited to 3 DMA FIFO channels, so I tried to implement a switching logic in the FPGA, where, in even iterations of the SCTL, I would read the first 8 channels with 2 DMA FIFOs, and in the odd iterations, I would read the other 8 channels using the same 2 DMA FIFOs. 

 

 This in particular means that channels 0 and 8 will be stored in the same column in the file, just as channels 1 and 9 and so on. This is controlled by a case structure and a True/False variable that negates itself after each iteration.

 

 Then, I connect a sine generator in channel 0, run the codes, and plot channels 0 and 8. Channel 0 should have a sine wave, while channel 8 pure noise. What happens is that at random points of the run the data that should be in channel 0 ends up in channel 8, and the data from channel 8  in channel 0, as the images show. One of them is Channel 0, while the other one is channel 8. Here I see that there are no missing points, but something sketchy happens at some point.

 

maldon45_0-1627392606932.pngmaldon45_1-1627392625652.png

 

I've also put a waveform chart in the LV PC code right after pulling out the elements from the DMA FIFO and saw the same behavior, so I know this is not caused by the way I'm writing the files to binary or reading them in Python.

 

I read in this NI thread that "To ensure data integrity, avoid reading or writing to the same FIFO by multiple objects, even if the access requests are not simultaneous." So now I'm thinking that maybe even if the logic is correct, the DMA FIFO won't work as nicely as I thought it would be under these conditions. Is there any alternative way to accomplish my purpose? I feel I ran out of ideas.

 

In the attached code, the boolean that controls the acquisition of the even/odd channel was changed to an integer between 0 and 3. I sample in iterations 0 and 2 and idle in between (as an innocent attempt of giving the DMA FIFO some time to store correctly the data). I also noticed that, when sending this integer through the DMA FIFO to the PC, not always did the even channels end up with the corresponding value of that integer. 

 

PS: I also tried to read the 16 channels with 4 target-scoped FIFO's and them writing all the elements into one single DMA FIFO. I saw that the code slowed considerably, which made me think it was losing some data, as I would expect to acquire an X number samples per channel at S sampling rate in an X/S amount of time, which didn't happen anymore by doing this... also, the data looked pretty weird, so I didn't continue this way.

 

0 Kudos
Message 1 of 1
(614 Views)