Did some testing by adding an actual sampling rate block.
Yeah the sampling rate is really not okay.
>From adv64.cfile:
SampRate: 9,141,703 B/s, Elapsed: 5 sec
SampRate: 9,142,254 B/s, Elapsed: 10 sec
SampRate: 9,142,458 B/s, Elapsed: 15 sec
SampRate: 9,142,559 B/s, Elapsed: 20 sec
SampRate: 9,142,607 B/s, Elapsed: 25 sec
From Pluto, default buffer size 0x8000 (32,768k)
SampRate: 613,716 B/s, Elapsed: 6 sec
SampRate: 463,144 B/s, Elapsed: 11 sec
SampRate: 401,725 B/s, Elapsed: 16 sec
SampRate: 373,066 B/s, Elapsed: 22 sec
From Pluto, buffer size 0x400.000 (4.1943M)
SampRate: 2,371,763 B/s, Elapsed: 5 sec
SampRate: 3,012,145 B/s, Elapsed: 11 sec
SampRate: 3,209,727 B/s, Elapsed: 17 sec
SampRate: 3,311,143 B/s, Elapsed: 23 sec
This is the best I can get and the second Contellation now works.
USB2 indicate a peak throughput as 60MB/s
For 2x16 that would give 60/4 = 15 MS/s
So yes as you say maybe 10 would be possible...
Strange that there are no kind of flow control.
In this case, Pluto should notice internally that samples are not retrieved fast enough.
I believe the sample rate of 8 MHz DVB-T is beyond the capability of the Pluto. The required sample rate is 9.14 Msps, which exceeds the throughput of USB 2.0.
Ron
Actually USB2.0 should be just fine up to about 10Msps with 16-bit I 16-bit Q. But the PlutoSDR, as shipped, cannot keep up with that.
There are some "tricks" including turning on the 2nd CPU core, and also running a completely-different system image that bypasses all
the IIO stuff, but gives you better RX-only performance.
epy_block_0_PrBf6R.py
test_dvbt_rx_8k_copy.samprate.png