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 <robin.g...@analog.com> 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 > >
