I’ve just been playing with and adapting the jocover plug-in for SDRSharp and have got it mostly working with the Lime Mini (a few aesthetic and UI related bugs).
Anyway, I’ve been testing by listening on the commercial FM radio band and have chasing some spurious signals. These appear to be worse around 100 MHz (possibly at other frequecies, I’ve only been focusing on the FM radio band).
The original and my adapted plug-in code is closely based on the code fragments in the “LMS API, – Quick Start Guide --”. As such, I’m slightly at the mercy of “LMS_Init()” call (provided by the Limesuite.dll) as at the moment I’m not up to speed on exactly what low level configuration it puts in place.
Here are two screen shots of the spurious signals, one with an attached antenna and one without.
Any ideas?
I don’t see these signals on any of my other SDRs, so I’m pretty sure that this isn’t a local source of interference.
I’d see four possible sources for that 100MHz signal, well 3 in reality:
USB 3 interference, emanating from a cable with a physical length that is close to a multiple of the wavelength of 100 MHz (2.9979 meters) . So a USB 3 cable that has a physical length that is close to ~12 meters, ~6 meters, ~3 meters, ~1.5 meters or 750 centimetres long. I’d try a different USB 3 cable with better shielding (double or even audiophile triple shielding). And loop the cable a few times through a ferrite ring to attenuate signal levels.
A clock frequency within the PC, so if the clock in the computer was a multiple of 100MHz, there is always the possibility that it could be transmitted through the USB 3 cable. I’d adding clip on ferrites to the USB 3 cable and change the spacing until the signal was attenuated. Metal cases can also help.
A clock frequency from within the LimeSDR, that could probably be changed by changing the sample rate to see if it shifts in up or down in frequency. Increasing the sample rate should probably increase the frequency of the interference if this was the source. It is extremely unlikely this is the source on a 8 layer PCB used in the LimeSDR mini (or a 12 layer PCB used in the LimeSDR-USB/LimeSDR-PCI) because all possible sources are well attenuated.
It could also be related to the raw signalling rate across the USB 3 cable. So for every 8 data bits transferred they are encoded as 10 signalling bits on the cable. So a signal rate of 100MHz would be generated by a data rate of eight tenths of that or 0.8 so 80 megabit/sec and that divided by 12 bits per sample and then by 2 one for I and one for Q. Would be a sample rate of 3.333 MSPS or a multiple of that so 6.666 MSPS, 10 MSPS, 13.333 MSPS, 16.666 MSPS, 20MSPS … Same solution as the first one, better shielding on the USB cable, and clip on ferrites to keep RF inside the PC at the PC and RF inside the LimeSDR inside the LimeSDR.
My gut feeling is that the signal at 100MHz is caused by the very first one, the length of the USB cable being a multiple of 1.5 meters long and due to insufficient shielding it is acting like an antenna transmitting RF directly into the LimeSDR or more likely directly into the antenna. So a better USB cable would be my solution, and a few clip on ferrites.
Most local interference problems can be solved by good RF hygiene, shielding and proper cables.
Most of the time I have the Lime Mini plugged directly into my laptop, so no cable. I have tried using a cable, it didn’t make any discernible difference, but I will try again with a better quality one and I’ll also experiment with some Ferrite rings.
I don’t think the signal is PC related as my other SDRs don’t see it. However, they are all USB2 based, so it might be a USB3 related clock. I will investigate.
It’s also possible that I have a bug. I’m streaming floats and I need to check that the code in the Limesuite DLL matches my SDRSharp driver (SDRSharp consumes IQ values as floats). I’m also not 100% happy with the quality of the demodulated audio (VHF FM radio). It will often have a very slight metallic sound, which is not the case with my other SDRs when plugged into SDRSharp. Again, I’m investigating (I know from previous experience of IQ processing that it easy to make mistakes and introduce artefacts).
I’ll update this this thread with any progress that I make.
I’m now 100% certain my plug-in is working correctly, I’ve pretty much re-written it in order to get it to work reliably. The original version of the plugin didn’t use the LimeSuite API to calibrate or specify any anti-alias filtering. Also, the metallic sound I mentioned (when listening to the commercial FM radio band) seems to occur whenever one of the 100 MHz harmonic artefacts is located within a station.
Today I had a quick look at the FTDI USB3 device and driver. Interestingly the supplied configuration utility show that the device uses a 100 MHz FIFO clock. I wonder if this is the culprit…
There is a 66 MHz option, but so far I’ve not been able to get this to work, as when selected the device drops down to a single USB channel (the driver appears to require two). Shame, as it would confirm whether or not this is the source of the spurious signals.
If I make any progress I’ll post the outcome here. Any thoughts?
Just for interest here’s a screen shot of the FT60X configuration utility.
I dont know what this could be, but it is related to Lime SDR mini. I dont recieve anything like this with RTL-SDR under similar conditions. One more interesting thing is that successful calibration needs significantly less gain on 100MHz than on other frequencies (e.g. 99 MHz).
Confirmed. Not only on 100M, check 150M or 500M … it is basically everywhere.
The comb starts spreading when center frequency is slightly increased:
499.9M:
I don`t see it on 150MHz, but on multiples of 100MHz. I also did one more test - I put RTL antenna across LimeSDR mini and received this as well. It is getting stronger with increasing the sample rate of LimeSDR.
I only see the signals on and at multiples of 100 MHz, as I posted earlier I’m now pretty sure that the source is the 100 MHz USB3 FIFO clock used by the FTDI 601 bridge.
This could be tested as the 601 also supports a 66 MHz FIFO clock, but to use this I imagine you’d have to make changes to the FPGA (not sure, but may take a look when I have time). At some point I’m also planning to experiment with some additional decoupling and/or screening.
I wonder if this is seen on all LimeMinis, or just some. It would be interesting to know.
I can confirm that I see it too. I’m running SDR-Console on Win10, with the radio configured for a 10MHz Bandwidth. I have all gains but the LNA turned all the way down and no antenna attached, connected directly to a USB3 externally powered hub. I’ve also seen it when running GQRX on Ubuntu 18.
I get all kinds of monitor and computer noise on mine, Mine is shielded pretty well and the ground is floating so the cable is shielded but no direct ground connection between the SDR and the computer but the fact of the matter is that computers are seriously RF noisy devices.
It could also be any one of a thousand outside sources in your home or work environment, the only way you can eliminate those is to kill the power to your residence then run this off battery power and see what disappeared.
The absolutely best method to verify however is to use a bandpass filter on the reciever front end that is for a HF band and see if you still get that spike up higher, if you do it is either the SDR or the computer (assuming you are powering from a linear supply like a battery or transformer based power supply).
All in all though SDR’s pick up crazy noise and are in themselves pretty noisy, there will always be spikes and wierd gremlins all over the spectrum, ususally from your own gear and lighting.
Think of it as a fox hunt and you can make a game of locating the source.
Here is your first step to figuring this out, read:
What you want to see is if a -band pass filter- NOT in that frequency range makes the signal disappear or at least attenuate down by quite a bit.
Basically we have been over this and the article I wrote was to address just this, if you are unwilling to do the work to hook up band pass filters for the bands you want to use and are unwilling to properly shield the hell out of this little wonder and make sure even power supply noise can’t get at it then what you will have is a noisy little reciever that show up tons of unwanted signals all over the place and has a noise floor that makes weak signal work impossible.
So if what you are into is watching the noise generated by thousands of cheap LED and flourescent lamps around your house, the RF from your refrigerator supply and all the electrical noise of every car, motorcycle, airplane, power pole, WIFI router, cordless phone and lawn mower in your nieghbourhood please ignore what I am suggesting.
If however you are truly concerned with what that spike is and where it is because you want good performance begin with shielding and filtering, until you do at LEAST those two things your reportrs of noise are just that: noise…
First off having the internal LNA (or any of the internal amps) maxed is not going to give ANY meaningful information, in most actual use cases on my setup I have it turned off because it causes more harm than it does good.
The 50ohm termination is a good move, turn off the LNA or at least get the gain way down where it is more likely to be used in the real world and see what you get.
It’s got to be the 100MHz FIFO clock generated by the USB3 bridge (FT601) that connects through to the FPGA.
I’ve kind of given up on my Mini for the moment, but I may try and screen the 601 and FPGA to see if it helps. Shame really, as I brought my Mini to evaluate the LMS7002M.
I’ve built a few SDRs based on the AD9361 and Xilinx Zynq FPGAs and have had to be very careful to isolate / screen / position the digital components as I’ve had similar issues.
Just out of interest, does the bigger LimeSDR exhibit any of these signals? I notice that it uses a different USB3 controller (a CYUSB3014).
My Mini is also the one on the aluminium case. It also looks like the FM stations in that region are still there under the noise. And the noise pattern seems to be independent of place and PC.
