I am using python iio module to Rx samples from Pluto sdr. I have set multiple sample_rate like 2e6, 2.5e6, 3e6, 4e6.
Buffer length is set as n*sample_rate. With n having values of 0.5,1,1.5 and 2. For any combination of sample_rate and n, the commands refill and read take n seconds to complete. Hi thought the time taken to retrieve data is dependent on usb speed and how come it is not changing with sample rate.
lmodur said:Please explain this. I was expecting that USB wil operate at its highest possible speed and time taken will change with amount of data to be transferred.
This will only happen if the USB interface…
You are likely overflowing at the higher rates, meaning that you will just see the limit imposed by USB2.0.
How many buffers are you measuring to arrive at n seconds in each configuration? If you start from lower rates does this trend change?
sample_rate = 5000000
duration = 1
buf_len = sample_rate*duration
ctrl.find_channel('voltage0').attrs["rf_bandwidth"].value = str(int(sample_rate)) ctrl.find_channel('voltage0').attrs["sampling_frequency"].value = str(int(sample_rate))
rxbuf = iio.Buffer(rxadc,int(buf_len), False)
time1 = time.time()print('Rx start time is ',time1) rxbuf.refill() data = rxbuf.read() time2 = time.time()
time2-time1 is equal to 1sec (duration) irrespective of sample_rate value ( I have tried 2.5e6,5e6)
For 2.5e6 sampling rate, we need USB speed to be 10MBps which may be towards the edge of the capability?
If I change sampling rate to less than 2e6, I get this error
ctrl.find_channel('voltage0').attrs["sampling_frequency"].value = str(int(sample_rate)) File "/usr/lib/python2.7/site-packages/iio.py", line 707, in <lambda> lambda self, x: self._write(x),
File "/usr/lib/python2.7/site-packages/iio.py", line 739, in _write _c_write_attr(self._channel, self._name_ascii, value.encode("ascii")) File "/usr/lib/python2.7/site-packages/iio.py", line 70, in _check_negative raise OSError(-result, _strerror(-result))
lmodur said:If I change sampling rate to less than 2e6, I get this error
You cannot set the sample rate below 2.08333 MHz unless you have a filter loaded to get more decimation. This is automatically done with our higher-level module pyadi-iio: https://wiki.analog.com/resources/tools-software/linux-software/pyadi-iio
lmodur said:time1 = time.time()print('Rx start time is ',time1) rxbuf.refill() data = rxbuf.read() time2 = time.time()
The first time this is done there will be a large overhead setting up the DMA. Subsequent buffer pulls will be faster.
Also, only performing this once is also not very statistically significant. We would recommend pulling thousands of buffers and measuring the latency to get a reasonable measurement.
I tried this script:
import numpy as npimport adiimport matplotlib.pyplot as pltimport time
sample_rate = 0.525e6 # Hzcenter_freq = 91.1e6 # Hzduration = 2sdr = adi.Pluto("ip:192.168.2.1")sdr.sample_rate = int(sample_rate)sdr.rx_rf_bandwidth = int(sample_rate) # filter cutoff, just set it to the same as sample ratesdr.rx_lo = int(center_freq)sdr.rx_buffer_size = int(sample_rate*duration) # this is the buffer the Pluto uses to buffer samples
delta = 0sample_len = 0time1 = time.time()for i in range(1000): samples = sdr.rx() # receive samples off Pluto sample_len = sample_len + np.size(samples)time2 = time.time()
delta = time2-time1
print('Rx time is ',delta)
print('speed MBps is ',2*2*1*1e-6*sample_len/delta)
With duration =1 and sample_rate = 0.525e6 ---
lmodur@lmodur-ThinkPad-T440s:~/laksdr$ python3.7 adi_test.py525000000Rx time is 1000.099428653717speed MBps is 2.09979122058585
With duration =2 and sample_rate = 0.525e6 ---
lmodur@lmodur-ThinkPad-T440s:~/laksdr$ python3.7 adi_test.py1050000000Rx time is 2000.3163378238678speed MBps is 2.0996678978131804
With duration =1 and sample_rate = 1e6 ---
lmodur@lmodur-ThinkPad-T440s:~/laksdr$ python3.7 adi_test.py1000000000Rx time is 1000.2784714698792speed MBps is 3.9988864242195676
With duration =0.5 and sample_rate = 1e6 ---
python3.7 adi_test.py500000000Rx time is 500.160227060318speed MBps is 3.998718594149241
It appears the speed is adjusting and the time taken for the data retrieval is fixed.
Please explain this. I was expecting that USB wil operate at its highest possible speed and time taken will change with amount of data to be transferred.
This will only happen if the USB interface is the bottleneck, which does not seem to be the case with the two rates you were using above. If you keep increasing the sample rate, there will be a point where the time it takes to get data back will not get faster. This is where the USB limit is hit.