Scope with zoom?

[jim-martz]

Hello, I am interested in a project using the Red Pitaya with a larger buffer and being able to read the buffer with SCPI using selectable decimation. I am wondering if the DAQServer project may work for some or maybe all of my needs?

Here is a list of what my project needs to do:

1. Triger an analog acquisition either by a voltage level or external trigger.
2. Once triggered write the data at 125Msps to a 2MS buffer in DDR memory, for each channel.
3. After the data is stored be able to read it at a 128 decimation, through TCP.
4. Then be able to read selectable sections of the raw data with no decimation, or even better selectable decimation. (Think of this like a scope with a zoom function.)

Another option that may be easier to implement would be to have 2 buffers for each channel. One that is a 2MS buffer that holds all the samples and can be read at any location. And a second smaller buffer that stores the data with 128 decimation.

The control of this would need to be with SCPI functions over the Ethernet, the end software would be LabView.

I have some experience with Linux and C programing, but little experience with fpga programing. I am trying to figure out what all pieces of my project don’t currently exist and try to determine how difficult this project would be for me and try to determine how long it may take.

I have been unable to find much documentation on the DAQServer project and in particular the daq_server_scpi, can someone point me to any documentation on this?

Thanks, Jim

[jonschumacher]

Dear Jim,

I think for the most part your needed features are there. You can start the acquisition with a trigger, read it via SCPI and also select the decimation. The main problem is the undecimated data. Since we wanted a continuous acquisition, we are only able to go as low as a decimation of eight in order to not overload the LAN connection. I guess there is no way around a modification of the FPGA image. Feel free to ask questions concerning this.

Concerning the documentation: I know we are a bit short on documentation. This is due to the fact that this project was mainly developed for our own purposes and we only wanted others to also be able to use it. I know this is a bad excuse for not commenting code correctly, but we are both a bit short on time for this project. If you really want to use this project and possibly find a generic way to integrate your features into the codebase, I would be pleased if you would add more comments and documentation. I think it would also help others since you would have another perspective on the code.

Maybe a few words on the general structure of the server. 'daq_server_scpi.c' is the starting point. It inits the SCPI server with the commands given in 'scpi_commands.c' and creates the the threads for the data acquisition. All operations that need actual access to the FPGA are in 'rp-daq-lib.c' and are then included into the server.

I think you goal can be reached by adding another acquisition mode which activates a limit for the acquisition counter. If this limit is reached, the acquisition is stopped. The decimation should be set to 1 beforehand. I actually don't see a reason to then only send the data with a decimtion of 128, but this could be done in C, so you could limit your FPGA coding.

Best regards Jonas

[jim-martz]

Jonas,

Thank you for the replay. I think the buffer for DAQServer is 8M and this is a ring buffer. So on a trigger the pointer location is sent? And there is currently not a way to stop data acquisition?

With DAQServer is there a way to do decimation on a read? The reason for doing the decimation on the read is that it takes to long to transfer 2Ms of data. For most of the waveform 128 decimation is fine, but there are parts of the waveform that we need a higher resolution.

Thanks, Jim

[jonschumacher]

Dear Jim,

the trigger is for starting the acquisition, not for sending the pointer. The acquisition can be stopped by putting the trigger pin back in its initial state. Therefore, acquiring exactly 2 MS and stopping afterwards requires modifications to the FPGA image. Since the decimation is currently being done in the FPGA, there is currently no Implementation for this in the server. How are your Timing requirements? I am not sure, if they can be met with the currently server implementation. How many acquisitions of 2 MS do you need per second?

Cheers Jonas

[jim-martz]

Jonas,

Ok, so the trigger pin is more like a start/stop acquisition. If the buffer was 2Ms+ and a one-shoot of 16ms was connected to the trigger pin then I think I would be able to capture all the data and stop it before the buffer loops back around. Does this sound like it would work?

I know the exact end of the data may vary a little but that will not matter, I will just make sure a little more data is read in then I will read out.

The decimation of the acquisition is fix at 8 and I would need to modify the fpga, is this correct?

Thanks, Jim

[tknopp]

The buffer is (about) 256 MB large and the decimation can be adjusted with either the server, or the C library. (the former uses the C library)

[jonschumacher]

Dear Jim,

this sounds feasible. I have to check, but I think the minimum decimation is 4 at the moment. You would have to adjust this setting in the Vivado environment. It can be found in the settings of the CIC compiler. You can then set the decimation to 1 (or any value between 4 and 8192) by using either the server or directly the library. Your decimation of 128 has to be done in C then. The best option might be modifying readADCData in rp-daq-lib.c, but this is something which @tknopp knows better.

Cheers Jonas

[jonschumacher]

Okay, apparently I was wrong about the CIC. The minimum decimation is 4 [1]. If this is fine for you, you don't have to change the image. If you need the full 125 MS/s, you need to either build a custom image for yourself and remove the CIC from the processing chain or bypass it. A switchable bypass would be the most flexible option, but I think the easiest one is the removal.

[1] https://www.xilinx.com/products/intellectual-property/cic_compiler.html

[jim-martz]

Thank use for the replies. I think my next step is to setup a development machine as described in Pavel Demin notes. Then start with a blink LED program to get a better understanding of how things work.

Thanks, Jim

[jonschumacher]

Hi Jim,

did things work out for you?

Cheers Jonas

[jim-martz]

Jonas,

Thank you for asking. This is still an evolving project and the requirements are changing some as it progresses. One of the first things I did was to add the decimation of 128 and 256 to the standard RP project. That would have allowed us to get what we needed at the time, but would still need two RPs. Since then it was decided that it would be better to use only one sampling rate(decimation) for all test. To be able to do this and capture enough data I had to increase buffer size. Last week by setting the DAC buffer to almost nothing, I was able to get the buffer up to 64k per channel, and get it working with the acquire program. Next is to get it working with the SCPI server. Although we would still need to use two RP's.

Original to get the project down to a single RP I was thinking to store everything at the full 125Ms into a large buffer in DDR and then do the decimation on the read from the DDR. And be able to re-read the data stored in the DDR using a selectable decimation rate. I think this would be a nice feature as it allows a sample of unknown data to be taken once and then be able to read different parts of the data at various decimations, like the "zoom" function on a scope, without having to take another sample of the data.

As for the project I am working on, with the 64k buffer I may be able to store enough data for this project. If so, then there may be another way to get this project down to a single RP. Because we are using both channels to take a differential measurement, I may be able to do the differential part (ch1 - ch2) in the fpga and store that to just the ch1 64k buffer at a selectable decimation. Then the ch2 buffer is open to have the data stored at the full 125Ms, although it would only be for the first 520us (with 64k samples). But this may be acceptable for this project. Anyway, things are still changing on this project and things may change again.

Thanks, Jim

[tknopp]

Since this is not a concrete issue, I am closing this for now.

[jim-martz]

I got this project taken care of. I ended up doing the following:

1. The ADC data buffer was increased from 16k samples to 64k samples.
2. Decimation options was increased to include 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096,
   8192, 16384, 32768, 65536
3. The two input channels were changed to take a difference measurement (ch1 –ch2), with the result being stored in the channel 1 buffer.
4. The channel 2 buffer stores the difference data at 125MS/s, regardless of what the decimation is
   set to. Storing data starts on the trigger and ends when the 64k buffer is full.
5. The ability to change the input filter coefficients including gain and offset using SCPI commands. And I also edited the SCPI parser code to to send the data much faster. Most of these changes I have posted here or in the RP forum.

Thanks, Jim