Seeking advice … running LimeSDR USB in 61.44 MHz sampling rate for 1 channel through a GnuRADIO flowgraph.
Basis of signal processing is a 30720 point FFT followed by decimation on frequency channels by 48 producing 2000 fps output of 640 frequency channels and dumped to file.
My machine is an i7 4770 3.2 GHz.
In the attached file, we can very clearly see pulsar detection at various phases of pulse … it runs for up to 10 minutes coherently then we get some random phase excursions which will be due to dropped packets. The horizontal lines at approx 8 mins and 14 mins and then beyond 20 mins are undoubtedly phone calls.
First question is the one I keep beating a drum about on every thread involving noise: do you have a band pass filter on the front end tuned to the 61.44MHz bandwidth?
If not give that a try.
Excellent, you are a rare bird in that respect which is why it is lways my first question.
Next: are you running the LimeSDR off a disciplined time source like a 10MHz GPSDO into the clock input?
No, the LimeSDR is running on it’s own internal oscillator. I do have a GPSDO, but I’ve found the stability to be good enough so haven’t yet connected it to the Lime. (I also have an Airspy and could easily see drift in the oscillator when observing a pulsar).
I gave it another try today with 51.2 MHz clock and still saw the jumps. This could also be a GNURadio issue too so I tried to make the FFT a power of 2 (16384 pt) and a different decimation but no luck.
I do believe that 10MHz is the clock input on the LimeSDR, if you are doing astronomy you should be phase locking your SDR to a 10MHz reference as the clock on the LimeSDR is good enough for LTE but no where near good enough for measuerment, microwave or astronomy purposes.
Get that in place first as it is basically as much a requirement as external filtering is those applications then you can actually start looking for other reasons if it is still happening.
Missing frontend filtering or drifting clock cannot produce jumps like those described. I am interested in using Lime in a coherent radio astronomy application and jumps like this would be a definite show stopper. Have you tried a lower sampling rate if this is due to USB3 throughput limit or similar?
I also have a LimeSDR-mini running on an I5 machine and had that system sorted with 30.72 MHz BW. Still trying to find the point for reliable operation with the LimeSDR-USB think 50 MHz was rather more stable but definite jumps with 61.44 MHz and 51.2 MHz BW. Have upgraded to an I7-4770 for LimeSDR-USB. Only running in SISO mode so keen to assess performance in MIMO to allow correlation.
The problem is that for some reason, SoapySDR doesn’t report overruns, so you only notice them when your data looks wonky.
Doing anything “significant” at 50Msps is still quite a challenge, even for “beefy” CPUs. I’d drop the
sample rate. You lose sensitivity, but that’s probably better than having discontinuities in the data stream–which is utterly fatal for pulsar observations.
I use a LimeSDR for interferometry at 14Msps into an Odroid XU4, and it’s fairly stable.
Hi Marcus, thanks for the input. I have probably had similar results using both SoapySDR and LimeSuite. 30 MHz with LimeSDR mini def possible for a single input and dumping FFT to HDD, I think 45 MHz maybe possible with the I7. Interferometry the next challenge! Looking forward to learning more
When using SoapySDR you can detect the jumps by simply looking at the received timestamps. Then maybe you can do something to take that into account.
Apart from the necessary processing power, I also noticed that I get better performances on a USB 3.1 port (LimeSDR receiving in dual channel at 55MS/s in sc12 format) and that USB cables can get damaged and start not working well at high sampling rates.
I have found that I get constant phase pulsar data when I record with osmosdr GRC source instead of the LimeSuite source block. Up to 54MHz without issue
