FPGA analog input rate

[shuishen1983]

The build waveform block works. Thank you!

[shuishen1983]

I can see some extrmely high spike on the front panel of the Vi, except that the signal seems to be similar to the same signal on the oscillscope. At first I think it is noise, and then I found that I can not filter them. Then I export the measurement to excel and plot them in matlab, then I am assured that those spikes are unreal data. Could that be the problem for the DMA FIFO setting. I set the  FPGA period 100 usec and reading 2000 points.

[nathand]

I don't know.  Did you fix the FIFO so the datatype matches what you're reading from the analog inputs?  Also try removing the Wait from your host while loop so that the FIFO Read dictates your host loop timing.  This will allow your host loop to "catch up" because if one loop iteration runs too long (due to Windows running something else, perhaps), the next iteration will happen sooner (as soon as the data is ready).

[shuishen1983]

I think the problem is related to backlog the data which is left in FPGA. I change my settings to FPGA period to 5 usec, and number of points 2500, and waiting time zero. Then, the number of data in backlog decreased. But for some reason, the number of backlog increase to several thousand for some instant. Do you think that could be the problem?

[nathand]

I don't understand exactly what timing you changed.  Did you change the wait time on the FPGA, or on the host?  Do you mean the Wait timer, or the FIFO timeout?

Set the FPGA to run at the speed at which you want to acquire data.  Say that's 1000 S/s and you're acquiring 4 channels.  Your host should read 4000 samples with a timeout slightly larger than 1 second, and the FPGA read should be the only timing function in the host loop.  Of course you can scale that appropriately - you could read 1000 samples every 300 ms or so.  If you're doing this right the FPGA backlog should stay close to 0 and the FPGA read should never time out.  You cannot control the precise timing on a Windows host so your FIFO depth (on the host side) needs to be large enough to handle occasional delays; by using the FIFO read to manage the loop timing it can catch up if one iteration lags.

If you're getting a timeout when you write to the FIFO on the FPGA then you need to increase the FIFO size on the FPGA.

[shuishen1983]

---

@nathand wrote:

I don't understand exactly what timing you changed.  Did you change the wait time on the FPGA, or on the host?  Do you mean the Wait timer, or the FIFO timeout?

Set the FPGA to run at the speed at which you want to acquire data.  Say that's 1000 S/s and you're acquiring 4 channels.  Your host should read 4000 samples with a timeout slightly larger than 1 second, and the FPGA read should be the only timing function in the host loop.  Of course you can scale that appropriately - you could read 1000 samples every 300 ms or so.  If you're doing this right the FPGA backlog should stay close to 0 and the FPGA read should never time out.  You cannot control the precise timing on a Windows host so your FIFO depth (on the host side) needs to be large enough to handle occasional delays; by using the FIFO read to manage the loop timing it can catch up if one iteration lags.

If you're getting a timeout when you write to the FIFO on the FPGA then you need to increase the FIFO size on the FPGA.

---

I change the waiting time on host. And If I don't plate a write to measurement file in it. The backlog is OK, but when I put one write to file in. It becomes terrible.

[nathand]

It would help if you set a non-zero default value on the FPGA Count (usec) control so that when the FPGA starts it will run at a reasonable rate.  Right now, it will momentarily run with a 0 usec wait until the host gets a chance to update it, and that could cause the FIFO to fill in a hurry.  Once the FIFO fills it's possible you'll read data from your channels out of order, since you'll lose data when the FIFO is full.  Could the unusual spikes you saw be explained by out-of-order data?

Why did you pick 16383 as the FIFO depth?  You may want to make that larger, and a multiple of the number of channels.  It does not need to match the FIFO size you configure on the FPGA.

How are you writing to the file?  If you open the file, append data to it, and close the file every time through the loop, it will be slow.  You should open the file reference once and store it in a shift register so that you do not need to reopen the file each loop iteration.  Using a longer timeout and reading more data from the FIFO will also help.  For maximum speed writing to disk you can create a large file in advance, which forces the operating system to allocate space, then set the actual file size when you finish writing to it.

EDIT: one other note.  You can improve your host code by chaining the FPGA write along with the FIFO read instead of forking the wire, and even if you do fork the wire, you do not need to close both copies of the reference.  Another code improvement would be to remove the Express formula node and replace it with an expression node or simple math.  Also, you can use a single index array and expand it downward rather than using 4 index array nodes.

[shuishen1983]

---

@nathand wrote:

It would help if you set a non-zero default value on the FPGA Count (usec) control so that when the FPGA starts it will run at a reasonable rate.  Right now, it will momentarily run with a 0 usec wait until the host gets a chance to update it, and that could cause the FIFO to fill in a hurry.  Once the FIFO fills it's possible you'll read data from your channels out of order, since you'll lose data when the FIFO is full.  Could the unusual spikes you saw be explained by out-of-order data?

Why did you pick 16383 as the FIFO depth?  You may want to make that larger, and a multiple of the number of channels.  It does not need to match the FIFO size you configure on the FPGA.

How are you writing to the file?  If you open the file, append data to it, and close the file every time through the loop, it will be slow.  You should open the file reference once and store it in a shift register so that you do not need to reopen the file each loop iteration.  Using a longer timeout and reading more data from the FIFO will also help.  For maximum speed writing to disk you can create a large file in advance, which forces the operating system to allocate space, then set the actual file size when you finish writing to it.

EDIT: one other note.  You can improve your host code by chaining the FPGA write along with the FIFO read instead of forking the wire, and even if you do fork the wire, you do not need to close both copies of the reference.  Another code improvement would be to remove the Express formula node and replace it with an expression node or simple math.  Also, you can use a single index array and expand it downward rather than using 4 index array nodes.

---

First, I found out that the sample rate of the data is independent with the FPGA period or the waiting time in ms or the number of points to read for one chanel. The interval between the data points are 5*10^-6 sec. Which means the frequency is the AD Converter speed 200kHz. The number of points to read only controls the width of the time window I am looking at. So the scale on the x axis is always 5*10^-6.

Second, I think the unusual spike comes from the out-of-order data, you are right. My depth for the host is 24000 now and the the depth for the FIFO is 1023. In the past I do place the write to file block into the while loop, so I think you prediction is right: I am open the file and write to it and then close it and do it again. How long should the timeout be, I have 2500 points for each of the four chanel, which means 10000 points to read, If the program is able to record all 10000 points in 0.0125 sec. So will 125ms be a proper time for timeout? If the program can't finish the tast in 12.5ms, then the backlog number will become large

Third if I want to wire FPGA write and FIFO read, does the sequency matters. I think read and write should happen at the same time, so I fork the signal before.

[nathand]

---

@shuishen1983 wrote:

First, I found out that the sample rate of the data is independent with the FPGA period or the waiting time in ms or the number of points to read for one chanel. The interval between the data points are 5*10^-6 sec. Which means the frequency is the AD Converter speed 200kHz. The number of points to read only controls the width of the time window I am looking at. So the scale on the x axis is always 5*10^-6.

---

This isn't right; it's your timing function that's wrong.  On the FPGA you have the Loop Timer configured for Ticks, not uSec (and you're using a I16 even though it expects a U32 input).  You're probably running a 40mhz clock so each tick is 25ns, meaning your loop runs 40 times faster than you expect.

---

@shuishen1983 wrote:

Second, I think the unusual spike comes from the out-of-order data, you are right. My depth for the host is 24000 now and the the depth for the FIFO is 1023. In the past I do place the write to file block into the while loop, so I think you prediction is right: I am open the file and write to it and then close it and do it again. How long should the timeout be, I have 2500 points for each of the four chanel, which means 10000 points to read, If the program is able to record all 10000 points in 0.0125 sec. So will 125ms be a proper time for timeout? If the program can't finish the tast in 12.5ms, then the backlog number will become large

---

Once you get the FPGA loop timing right you'll be handling less data, which will help avoid filling the FIFO.  I'd recommend a 200ms timeout, reading whatever amount of data you expect to arrive within that amount of time once you get the loop rates right.  Which function are you using to write to the file?  What file format?  Upload the code that writes to the file.

---

@shuishen1983 wrote:

Third if I want to wire FPGA write and FIFO read, does the sequency matters. I think read and write should happen at the same time, so I fork the signal before.

---

The amount of time it takes to write to the FPGA is minimal, and you already wait at the FIFO read, so putting the FPGA Write before the FIFO Read will function identically to your current code.

[shuishen1983]

You are right about the wrong timing. I fix that and also make some change to other part. I am using TDMS now. But there is still a very small amount of data lost. I think I am close to the finish line. The timeout is 500ms now, So what could happen to make this data lost?