Maximum Receive Buffer Size on Pluto

[tylersweat]

Hi,

When using this timestamping solution, I've noticed that the maximum buffer size I can set without the Pluto failing is 32769. I want to receive 20ms of data at a sample rate of 30.72MSps. The Pluto is bottlenecked by its USB2.0 interface so I can't just stream smaller chunks of data and piece together because it won't be continuous in time.

from adi import Pluto

sdr = Pluto('ip:192.168.2.1')
sdr.sample_rate = int(30.72e6)
sdr.rx_buffer_size = 614400
d = sdr.rx()
print(f'{d.shape[0]} samples')

When running the stock ADI firmware, I get the expected output:

614400 samples

But, when the zynq_timestamping FPGA image is loaded, I get the following error:

Traceback (most recent call last):
  File "/home/tyler/test_buffer_size.py", line 6, in <module>
    d = sdr.rx()
        ^^^^^^^^
  File "/home/tyler/miniconda3/envs/pyadi/lib/python3.12/site-packages/adi/rx_tx.py", line 248, in rx
    data = self.__rx_complex()
           ^^^^^^^^^^^^^^^^^^^
  File "/home/tyler/miniconda3/envs/pyadi/lib/python3.12/site-packages/adi/rx_tx.py", line 213, in __rx_complex
    x = self._rx_buffered_data()
        ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/tyler/miniconda3/envs/pyadi/lib/python3.12/site-packages/adi/compat.py", line 149, in _rx_buffered_data
    self._rxbuf.refill()
  File "/home/tyler/miniconda3/envs/pyadi/lib/python3.12/site-packages/iio.py", line 1003, in refill
    _buffer_refill(self._buffer)
  File "/home/tyler/miniconda3/envs/pyadi/lib/python3.12/site-packages/iio.py", line 62, in _check_negative
    raise OSError(-result, _strerror(-result))
TimeoutError: [Errno 110] Connection timed out

What is limiting the maximum buffer size? Is there a parameter that I can customize before compiling the project that would let me have a larger buffer with timestamps enabled?

[tylersweat]

In the file ip_repo_generated/adc_dma_packet_controller/src/adc_dma_packet_controller.vhd, I noticed the following on line 104:

signal current_num_samples : std_logic_vector(15 downto 0); -- up to 32768 I/Q samples (i.e., enough for 1 ms @30.72 Msps/20 MHz BW)

Is there a way to increase this size?

[ofontbach]

Hi @tylersweat,

The timestamping solution has been implemented to work with 4G/5G signals and to process them in real-time. Hence, 1 [email protected] Msps is equivalent to one frame when using a 20 MHz BW. If I get it correctly, your end goal is not to receive data in real-time (as you say, the Pluto has the USB2 bottleneck) but to capture non-continuous chunks of 20ms of I/Qs.

Of course the width of the signal you mention could be incremented, but it would have quite a few side-effects that you would also need to tackle at both CPU and FPGA ends. Probably, if you are only interested in the Rx path (so the DAC/Tx part is not used at all), then the modification should be more contained.

If I got right your end goal, and the Pluto has enough resources (not sure about that - perhaps if you delete all DAC-related logic you'll have enough), you could implement a RAMB-based buffer large enough to store 20x timestamped packets and control its writing/reading from the ARM (similar to a very simplified ILA if you will). We've done something similar a few times for debugging purposes and it's quite fast and convenient if you simply want to capture data without the real-time operating requirements.

[tylersweat]

Hi @ofontbach,

Yes, we're wanting to post process LTE frames at the 20 MHz BW so we need at least 10ms (but more like 20ms to guarantee the capture of a full LTE frame) of contiguous data which the Pluto cannot stream due to the USB2 bottleneck. We only care about the RX path since we have no plans to transmit anything.

I have little experience with VHDL, but I was able to poke around and increase some of the 16-bit wide signals to 32-bit wide. These changes now let the buffer size be up to 2097152 samples. I believe this is the limit given that PARAM_DMA_LENGTH_WIDTH is set to 24. The signal is treated as signed so the DMA length can be 2^23 bytes. Each sample is 4 bytes so that gives us 2^21 which is the 2097152 as mentioned above.

We're now able to get 2097144 samples once you account for the 8 sample timestamping header which is ~68ms of data at 30.72 Msps. This is good enough for what we're trying to do. Thanks for your help on various questions.

For anyone looking to do something similar, see my fork of this repo: https://github.com/tylersweat/zynq_timestamping/tree/v1.0.2
I can't promise that the TX path still works with the changes I made, but I have verified the RX path with the maxed out buffer size.

[ofontbach]

Cool. Thanks for sharing the fork :)