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

[Glen Langston]

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_yourself
> 
>