RE: Gnuradio for Raspberry PI 4 and SDRPLay works well, but need documentation

[Getz, Robin]

Glen:

>The spectra from the PlutoSDR look good, and I can use a wide range of 
>bandwidths,

Great.

>but for bandwidths larger than 3.2 MHz I don’t get all the data captured (I 
>know this by calculating how 
>long I should have to wait for all N samples at a given data rate, and measure 
>the actual time it 
>takes to get N samples.

Just to confirm - to capture 3.2 MHz, the output sample rate is set to 3.2 MSPS 
(Mega Samples per Second?)

I can pretty easily set things to 7 MSPS (7 MHz of total RF bandwidth), and not 
drop samples (over USB).
Buffer size impacts this a lot. See the insightful presentation that Travis did 
as part of GNU Radio Conference 2019:
See: 
https://www.gnuradio.org/grcon/grcon19/presentations/gr-iio_nuances_hidden_features_and_new_stuff/Travis%20Collins%20-%20gr_iio.pdf
 page 38
Set your buffers to 16k - 64k samples for fastest performance.

What is your target sample rate?


Libiio is not threaded, and that is an exercise left for the user, or top level 
application. I think there have been discussions on the mainlining IIO about 
what is the "right" way to do things for GNU Radio. I think this bottomed out, 
and we were doing it the right way - but would need to confirm with Travis....

-Robin


-----Original Message-----
From: Glen Langston <address@hidden> 
Sent: Tuesday, November 19, 2019 4:39 PM
To: Getz, Robin <address@hidden>
Cc: Marcus D. Leech <address@hidden>; address@hidden
Subject: Re: Gnuradio for Raspberry PI 4 and SDRPLay works well, but need 
documentation



Hi Robin,

When using the AIRSPY (and mini) this summer I was finding some flashes in the 
RF band that were on for a few 100 micro-seconds, then off.  (The plots are on 
my home computer so I’ll
have to send these on Friday).   The fraction of time the flashes are on is 
very small, less
than a total of one second in 24 hours.  

The spectra from the AIRSPY look very good and the AIRSPY is very reliable in 
sending all
data at the 10 MHz bandwidth (20 MHz I+Q samples).   I could see these 
transients
even when my horns were pointing at the ground, so were not likely due to 
internal sources.

However since my project is looking for transient events, the flashes are an 
issue for me, but would not be noticed at all by most users.

The PlutoSdr does not seem to be generating many (any?) transients internally, 
which is very good. Ie when I point the horns at the ground I get very few/no 
transients appear above 5 sigma, compared to the noise level.
  
The spectra from the PlutoSDR look good, and I can use a wide range of 
bandwidths, but for bandwidths larger than 3.2 MHz I don’t get all the data 
captured (I know this by calculating how long I should have to wait for all N 
samples at a given data rate, and measure the actual time it takes to get N 
samples.

The PlutoSDR does not seem to be reliable sending data at rates faster than 3.2 
MHz bandwidth
(6.4 MHz I+Q samples).  I think it is sending blocks of data on USB but then 
not sending for a while while the data are buffered in some part of the USB 
processing.  The PlutoSDR code in GNuradio does not generate the Overflow or 
Underflow letters that other software generates for other devices.  So the rate 
issues are probably not noticed by other users of gnuradio-companion.

I’m working on a version of the Gnuradio code that does not generate any plots 
and could run entirely internally on the PlutoSDR.  This might be able to 
capture all events at the full 56 MHz sample rate.

The current code is obtainable by
git clone http://www.github.com/WVURAIL/gr-radio_astro
This requires some building and compiling.   It works for me on the Raspberry 
Pi 4 and Odroid N2 (Both with 4GB).

I’ve downloaded and installed some else’s PlutoSDR .dfu files, that did run 
gnuradio on the Pluto.  That was working well but I could not figure
out how to modify it to build my own c++ libraries.   I might try again.

Regards

Glen


> On Nov 19, 2019, at 2:55 PM, Getz, Robin <address@hidden> wrote:
> 
> On Friday, November 15, 2019 1:22 PM , Glen I Langston wrote:
> [snip]
>> I’ve not yet fully checked the SDRPlay for short term transients.
>> 
>> Note that the Pluto SDR has no (or at least few) short term transients in 
>> the RF.
>> I did find the AIRSPY did have some transients that seem to be due to the 
>> device.
>> These occur a few thousand times a day, but for shorter than 100 micro 
>> seconds.
>> Total time on is less than a second a day.
>> 
> 
> Glen:
> 
> I would be interested in what you mean by this. I assume it's mostly 
> "anomalous data", and while it's "not right", you aren't sure if it is coming 
> from the RF (air interference) or via some transport scheme issue.
> 
> If you have a bursty/intermittent adjacent channel (where adjacent can be 
> within ~200 MHz of your LO, depending on your hardware), it could cause 
> anomalous reception. (This highly depends on your external filters, and 
> shielding)...
> 
> If you have bursty/intermittent data on harmonics of the LO (again, depending 
> on your hardware, external filters, shielding, etc), it could cause anomalous 
> reception.
> 
> If you have a ground loop, and someone next door turns on their electric 
> drill (for example) - this could cause what appear to be receiver problems. 
> (remember - you are pulling out signals at -100dBm, into 50 ohms, that is 
> 6.324 µV(p-p) or 0.12648 µA(p-p)/ That is pretty tiny, and can be effected by 
> lots of issues.
> 
> On AD936x based radios (Pluto, B200, E310, BladeRF 2.0 micro) there is the 
> ability to set the Rx to an LFSR/PRBS (Pseudo-Random Bit Sequence), to verify 
> "data", which I have run for ~ week with no lost/bad data, both at max rate 
> (61.44 MSPS, checking in local in the FPGA), and lower over the various 
> transport layers (~5 MSPS over USB and Ethernet), checking in a C 
> application. I haven't done it in awhile - and have not gone all the way up 
> to GNU Radio, but should be able to pretty easily ... More info at:
> https://ez.analog.com/cfs-file/__key/communityserver-wikis-components-
> files/00-00-00-02-20/AD9361BISTFAQ.pdf
> 
> If you think you are seeing bad digital/transport data on Pluto - let 
> us know so we can track things down. (it's been awhile since we tested 
> this, and changes have been made, I will add this to the release test) 
> Any sort of anomalous device or transport issues - we can try to help 
> look into. If they are anomalous RF issues - that's harder. 😊
> Our goal is zero device issues all the time - the transport to any 
> application should be rock solid.
> 
> Let me know.
> 
> -Robin
> 
> Also - if you are interested in only Rx (like I'm assuming), make sure to 
> turn the Tx off.
> https://wiki.analog.com/university/tools/pluto/hacking/listening_to_yo
> urself
> 
>