LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Best way to do convolution in RT and emit outcome of convolution by speaker

Solved!
Go to solution

i have to do lot of convolution in RT. i think it's to much to do lot of convolution in FPGA.

 

obtain signal from microphone and emit sound using speaker 

 

my method is

1. microphone obtain signal in FPGA with certain data rate and transfer vector to FIFO 

2. in RT, Timed Loop read vector from FIFO and use first sample to downsampling 

3. collect sample to make buffer and do convolution and write outcome sample using FIFO write

4. in FPGA, Speaker read sample from FIFO, emit sound 

 

but there is some problem 

 

there is loud noise in sound

 

What is the best way to do convolution in RT and emit sound sample by sample?

0 Kudos
Message 1 of 10
(1,494 Views)

i collect sound signal and send data to RT and do signal processing 

because i'm doing realtime signal processing in RT, signal processing process have to do sample by sample 

for example in RT, the output sample of convolution is send to FIFO with Looptime 500um (fs = 2000hz)

and in FPGA receive sample data and emit sound with certain data rate 

 

but there is loudnoise 

 

i think when i send value 1 one sample to FPGA with Looptime 500um  (1,1,1,1,1,1,1,1)

in FPGA with Looptime 250um emit sound like (1,0,1,0,1,0,1 .....)

 

i dont know why this process make loud noise....

 

 

 

 

0 Kudos
Message 2 of 10
(1,488 Views)

Noise means that you are most likely not running in a tight and continuous stream for the data. to be output to the speakers.

 

There are various delays in your system on these steps:

 

- AD conversion of the signal and transfer to the FIFO

This depends on the AD converter your IO uses, if you have a SAR (successive approximation registers or a Sigma-Delta) type AD, this can mount up already to considerable delays but is constant for a specific sample rate.

 

- FIFO transfer to your RT app

This takes some time as the DMA channel needs to transfer the data across the hardware bus, but should in itself not be the culprit unless you try to use huge datarates. What is important here is that the consumer on the RT side is fast enough to read the data in useful junks so that the FIFO can't overrun. I usually use the FIFO as accumulation buffer here, by configuring it large enough (> 2 to 4 times the junk size I want to read) and then let it fill up until the chosen junk size is reached and then read that junk in one go. This saves on having to append the data on the RT side to your own buffer until you have enough for your analysis. The FIFO is inherently capable of this, while in RT you need to build complicated circular buffers or even use the "shudder" Build Array primitive to append the new incoming data to your own buffer until you have enough to process.

 

- Your Signal analysis

This is likely your biggest problem. Depending on how you do it, this could introduce a pretty large and variable delay in the whole chain.

 

- FIFO back to the FPGA

This is similar to the other FIFO, however here it is important that you actually do some control on the receiver side that the FIFO never gets empty. Once it does your continuous stream of samples is interrupted and that will create cracking noise on the analog output.

 

 

Of course the loop to read the analog samples from the AD converter and put it in the FIFO needs to be very tightly timed. I ALWAYS use a timed loop for that. And since they can't usually go as low as you want to do your AD sampling, I use clock decimation inside the loop. Set the timed loop rate to a multiple of your desired AD sampling rate and then inside the loop use a counter that you increment each iteration. Once it reaches your desired value, perform the AD write its result in the FIFO and reset the counter to 0. Your AD may have a higher latency than 1 so you need to iterate it for the number of latencies it has before it produces a new valid sample at the output. You need to watch out for that as it will increase the delay from the analog input to when you actually can write the value to the FIFO.

 

The same applies to the analog output side where in a second loop you read a sample from the FIFO and then write it to the DAQ output. Here again you could have more than one cycle latency and need to accomodate for that.

 

If this all sounds complicated, then it is because hardware really can be complicated as it has to work with physical and design constraints. Your FPGA code needs to accomodate for that! 

 

Another point to watch out of course is that a naive Convolution filter approach will have nasty inconsistencies at both ends of your buffer that you choose to process, as it misses samples from the previous and next buffer. So you need to correct for that by saving the end of each incoming buffer and not send an according part of the resulting buffer to the FIFO and then prepend that to the next incoming buffer to put through your Convolution filter and also adjust the front of the convolution result accordingly before sending it back to the FIFO. How many samples you need to correct for at each end of the buffers depends on the size of your filter coefficients. It is typically at least floor((n + 1) / 2) samples with n being the size of your filter coefficients.

 

With all that said, you may overestimate the required resources for implementing your Convolution in FPGA. It depends a bit what type of Convolution you try to do but if it is anything like a FIR filter then there are ready made blocks already that perform the algorithme sample by sample. These type of blocks all tend to have some latency (needing more than one execution before they produce the according result that corresponds to an actual input sample but that is all easily manageable. If you try to do a generic convolution, things might be a little more tricky but it is definitely possible to do that in a sample by sample approach with some more or less involved pipelining and then it is doable in FPGA. FPGA gets very bad when you try to naively implement a block algorithme, which you may be inclined to do when you think in software. But by doing it sample by sample it gets actually manageable in terms of needed resources and FPGA hardware is more than fast enough to do it that way. In software you have lots of memory but the CPU has to work very hard and your process can be interrupted at any time by the OS, so that doing sample by sample processing can lead to inconsistent data rates, which is why block based algorithms are usually the choice there, but they also increase the latency as you need a whole block of data to process before you can send it out to the DAC.

 

The FPGA hardware has dedicated circuitry assigned to your specific part of the algorithme and is not used for anything else in between so if the circuitry can perform your needed processing it ALWAYS can do that without something else being able to grab that resource temporarily. If there is nothing to do for that circuitry it simply sits idle and can't be used for something else, unlike with software on a CPU.

Rolf Kalbermatter
My Blog
0 Kudos
Message 3 of 10
(1,484 Views)

 

i usually collect data to make buffer in RT. is it fine?

 

Isn't it because I didn't interpolate because the sampling rate changed?

0 Kudos
Message 4 of 10
(1,448 Views)

@hsw9797 wrote:

 

i usually collect data to make buffer in RT. is it fine?

 

Isn't it because I didn't interpolate because the sampling rate changed?


I have no idea what you are talking about and hence can not give you any answer. Care to elaborate a lot more what you actually are really doing and maybe, just maybe, you could even attach your code!

Rolf Kalbermatter
My Blog
0 Kudos
Message 5 of 10
(1,440 Views)

hsw9797_0-1650540031890.png

hsw9797_1-1650540074301.png

RT(Speaker_RT) and FPGA(FP1) respectly. goal is emiting sound with RT Sampling rate in this situation 2000hz 

there is two speaker 

problem is as i said there is loud noise

but when i match While Loop Timing to RT Timed Loop, Noise reduced but that is unstable. 

 

How can i emit clean sound

0 Kudos
Message 6 of 10
(1,433 Views)

Crio-9039, Ni-9260

0 Kudos
Message 7 of 10
(1,429 Views)

mismatch sampling rate between RT and FPGA...... i think i have to upsampling in FPGA . right?

0 Kudos
Message 8 of 10
(1,418 Views)
Solution
Accepted by topic author hsw9797

No there is no upsampling if the loop rate doesn't match. You let the two loops simply run freely no matter what. If your RT loop runs faster than your FPGA loop your FIFO will eventually overflow, if your FPGA loop runs faster than your RT loop you will write 0 samples to the DAC since your FIFO read does not use any timeout. This means it will timeout immediately when there is no sample in the FIFO and produce a default value, which is usually 0 and that will of course disrupt the analog signal at the DAC output!

 

But the entire logic you have in that RT loop easily could be put in the FPGA loop too, a sin and cos calculation isn't going to blow up your 2kHz sampling rate at all and will also fit on the FPGA. You then only need your gain and frequency controls that you can easily control through front panel registers on the FPGA VI from your real-time application. That would save you to have to try to synchronize the two loops through FIFO handshaking.

Rolf Kalbermatter
My Blog
0 Kudos
Message 9 of 10
(1,410 Views)

i have to convolution with filter length 51

 

i made input buffer and multiply with filter but there is no add elements..... 

 

is it impossible convolution in FPGA?? 

 

processing in RT is not possible

0 Kudos
Message 10 of 10
(1,375 Views)