Record IQ data from FMCOMMS5

Do you need the data to be contiguous (no gaps)? At what sample rate do you run the system at?

For perspective, 3.75 billion samples would require 15 GB of space.  You could not capture this into DDR as the ZCU102 only has 4GB. Writing to the SD card is heavily speed limited so its usually not an option to continuously write to it.

-Travis

I do need the data to be contiguous. I am using 12.5 MSPs as sample rate, and i am running from a nfs server so there should not be any issue regarding the size of the file.

You can use the https://github.com/analogdevicesinc/libiio/blob/main/examples/iio_adi_xflow_check.c tool that comes with libiio to check for overflows when pulling buffers. You will need to tune the buffer size to make it large enough so that overflows do not occur.

-Travis

I do know I can run $ iio_adi_xflow_check -u local: cf-ad9361-A. But how do I record the file? Can I just use $ iio_readdev -u local: cf-ad6361-A > data_IQ.bin?

How are you moving data off the board? Are you using libiio to do this with its remote contexts or through NFS?

-Travis

Sorry for not giving all the context. I am running the board in QSPI mode with a remote Root filesystem in nfs server in a host server. I then connect to the board using ssh for all doing everything.  Since I am trying to record from the 1st Rx of the 1st ad9361 of the FMCOMMS5, I think if I run this $ iio_readdev -u local: -s 125 cf-ad9361-A voltage0 voltage1 > data_recTest.dat I will get the data I need. One thing I cannot do is run the $ iio_adi_xflow_check -u local: cf-ad9361-A  in other terminal to check for data losses.

ok.

So iio_adi_xflow_check is used to check for overflows when using remote contexts. libiio supports streaming over Ethernet, which is the most common use case for iio_adi_xflow_check. iio_adi_xflow_check doesn't save data, its only for benchmarking.

I can't really comment on the NFS performance on this setup, but we've gone through the speed requirements.

As for iio_readdev, I would start with iio_adi_xflow_check to verify buffer sizes before writing data to an nfs share that you don't drop things, then move to iio_readdev.

One big limitation is that iio_readdev does not check for sample drops. You may need to modify iio_adi_xflow_check to write data out to stdout (like iio_readdev).

-Travis

Thank you for the support! The nfs server should not be a bottleneck. In any case I would like to be aware if I was missing samples. One thing I am missing out is out can I properly choose the buffer-size. In iio_readdev [Analog Devices Wiki] it is not specified how it should be selected.

I am pretty sure I am missing samples... At the Rx input I have connected a signal generator, so I should get a cos/sine wave alike. I do get it, but as you can see there is a gap temporal between samples (image bellow). This is not an isolated case, it happens from time to time. Is there something I can do to make sure I do not lose any sample? Something related with buffer size maybe (I am using the default value of 256)? 

256 is wayyyyyy too small. Each buffer pull introduces overhead, so the larger the buffer the less overhead.

-Travis

But how large can I go? Can I have a buffer with the same size as the samples I want?

Max buffer size is determined by 2 things (mostly), the kernel CMA and the IIO block size. Usualluy the IIO block size is smaller by default. See here wiki.analog.com/.../libiio_tips_tricks

-Travis

Max buffer size is determined by 2 things (mostly), the kernel CMA and the IIO block size. Usualluy the IIO block size is smaller by default. See here wiki.analog.com/.../libiio_tips_tricks

-Travis