search

tknopp / RedPitayaDAQServer

Advanced DAQ Tools for the RedPitaya (STEMlab 125-14)
https://tknopp.github.io/RedPitayaDAQServer/dev/
Other
37 stars 10 forks source link

Ringing on pulse/square wave signals #67

Open Trent-Ralph opened 1 year ago

Trent-Ralph commented 1 year ago

Hi, Thanks again for your work on this project. I'm getting severe ringing on the signals I'm trying to measure using this image. The decimation filter added with V0.6.0 doesn't seem to help. All images shown are a normalised (to the back of the pulse) 30us (0.5v) pulse generated by an AWG captured at dec=8 unless otherwise stated . Comparing the two versions shows no changing in ringing. Zooming in shows slight oscillations at the edges presumably from the decimation filter.
GitHub 6v5 GitHub 6v5_zoom

To confirm it wasn't the RP front end I measured the same signal using the original RP FPGA image. While not perfect when compared to a dec = 1 the original filter function handles the pulse much better. Original Original_zoom For our research we look at changes in pulse shape so this is obviously not ideal. Is there anyway to fix this ? Is it possible to run the RP at the full 125MHz if you aren't interested in data streaming? The length of pulse sequence we are interested in looking at is around 15ms which by my calculations should fit in the buffer 128MB buffer by an ~order of magnitude. I had a quick look into the code around the decimation and it looks like the minimum value of 8 is coded pretty deep which makes me think this is not an option. Look forward to hearing your thoughts.

Cheers, Trent.

jonschumacher commented 1 year ago

I think when taking out the guards in the server, a decimation of 1 should work. You just have to be quick about fetching the data since it would be overwritten in the ring buffer quite quickly.

@jusack Any ideas on why the filter does not work properly?

jonschumacher commented 1 year ago

I have to correct myself: According to my comment in this function https://github.com/tknopp/RedPitayaDAQServer/blob/a49a53f82c0a0e4d8f7c3dcbe77206ca6813b280/src/lib/rp-daq-lib.c#L500 the lowest possible factor without changes to the images seems to be 2.

jusack commented 1 year ago

I think what we are seeing here is the analog front end of the Red Pitaya and not the decimation filter (as we don´t see a strong difference in v0.5.0 and v0.6.0). There is a slight frequency dependent behaviour of the input stage before the ADC, which also differs between the HV and LV path (see also issue #7). grafik The original image corrects this with an additional digital filter stage that we have not yet implemented. This is on my backlog of things that I would like to investigate further and fix, but it does not have the highest priority for me right now.

The minimum decimation, that we can achieve with no changes to the image, would probably be 4, since the FIR compensation filter decimates by a fixed factor of 2 but for it to have something to reasonably compensate we need the CIC filter with a minimum decimation of 2 as well. Otherwise we would need to add a way to just pipe the unfiltered data to a buffer. Which would actually be interesting to investigate the ringing issue, since we could really take the decimation out of the equation.

jonschumacher commented 3 months ago

@jusack This is now implemented and the issue can be closed, right?