Receiving FM broadcast images on every frequency

I’m trying to use the LimeSDR-USB around 25-30 MHz to reverse engineer a remote control I have, but all I’m getting is the FM broadcast stations from 88-108 MHz. It’s drowning out my signal really badly – I can use those frequencies to listen to FM broadcast radio very clearly. I am getting the same images at different frequencies throughout the entire range from 15 MHz to 82 MHz, and one station around 115 MHz (protected air band). This entire spectrum below 115 MHz is in fact unusable.

I am using a whip antenna connected to RX0 through LNA_L. Using SDR# with 2MSPS. Same results with CubicSDR. Although I notice that below 30 MHz, changing the center frequency has no effect at all and does not change the tuning. For a device that is supposed to tune all the way down to 100 kHz, it’s not really working out.

Digging deeper, it seems even 95.7 MHz is copied onto 96.3 MHz and follows properly if I change the tuning, whereas some images will move in the opposite direction of the tuning. With a cheap RTL-SDR, I do not have those images within the FM broadcast band itself (surprisingly getting better quality with RTL-SDR than LimeSDR), but I do get the images around 30 MHz, so… digital aliasing problems?

Changing the sampling rate does seem to change the location of the individual images, but I really shouldn’t have that many images floating around like that.

Well, it seems unplugging the LimeSDR and plugging it back in fixed the image issues in the FM broadcast band. Strange it even occurred…

Correction: With 2MSPS I have the aliasing, with 2.56MSPS I do not. Still have all the images in the lower part of the band and unable to tune below 30 MHz.

@TehWan,

You need to use a Lowpass Filter that can pass the HF band (2.0 to 30 MHz) to eliminate the images of the FM band - the input to the LimeSDR and the Lime Mini is wide enough that it cannot take those images out and they show up in the HF band. If you use a commercially available or homebrew Lowpass Filter then those images will be gone and you’ll see a clear HF band that you can tune.

Hope this helps - 73 de Marty, KN0CK

1 Like

@martywittrock,

Thanks for the info. For now, I’m using the Ham It Up HF upconverter, which works wonders. Most of the images (especially the ones in band) go away with a larger sampling rate, so it’s definitely aliasing, hence the filter is a great idea but removes some of the agility I need for other projects. I guess that’s why there’s two RX channels :wink: I was quite sure the LimeSDR had an antialiasing filter on the ADCs, but I guess it’s not adjusted according to the sampling rate, at least not within most software.

I still need to solve the problem of getting the tuning to work below 30 MHz, but that’s a different topic.

Thanks.

73 de JD, VE2ZJD

@TehWan,

You turn on NCO to tune below 30 MHz - check that out in LimeSuite.

73 de Marty, KN0CK

Well that makes more sense now. Although I can only tune down to 10 MHz with that option, so I’m guessing the rest is tuned through the sampling itself, where at 10 MHz I can use 20 Msps to capture from near DC to 20 MHz.

That LimeSuite software is overly complicated for an end-user, but it is so complete. I’ve also switched to using SDRangel and it’s day and night.

Thanks for all your help. 73 de VE2ZJD

1 Like

@TehWan,

Using SDRAngel will disclose A LOT of what you’re seeing with how to set sample rate and apply NCO to tune further down. I always found that setting the sample rate to 6,000,000, and then having a ratio of 32 and 16 made it possible to tune down to the AM Broadcast band and demodulate AM there. But you can play with it however it makes sense to you.

Are you developing an app for the Lime? Just curious - that would be a good thing to see as SDRAngel is what I use (but it’s not for everybody) and SDRConsole only works for VHF to SHF (not sure why Simon refuses to work on HF for 'Console since there appears to be a ton of Hams waiting for it). But SDRAngel is elegant in its own way and I use it A LOT to tune HF and generally make my Lime work in the HF band for all modes (AM, FM, SSB, CW).

73 de Marty, KN0CK

@martywittrock,

I do write software that uses the LimeSDR, but it’s usually application-specific. So far, I’ve been using SoapySDR to interact with it due to the simplicity of its API.

I have never used SDR Console. I see it is closed source, so there’s no easy way to modify it.

The world of SDRs reminds me of the early days of computers and operating systems. Everyone has their own way of doing things, and it is up to the person using the product to adapt, rather than manufacturers following a certain standard (though it’s not as bad as it was back then). This is why I like APIs like SoapySDR. It gives me a common framework to work with. Sadly, there’s still a lot of workarounds and extra stuff to do when it comes to each individual SDR apparatus. There’s no global way of saying: tune to frequency X. With the LimeSDR it is: tune to frequency X, but if you can’t, try adjusting this parameter until you can, then change your filter bandwidth, recalibrate your receiver, and when you’re done let’s get this stream up again. All of that should be covered by that one simple command to change the tuned frequency and the rest handled by either the hardware or the driver.

Whether it’s the RTL-SDR (I need to send the tuning command multiple times for it to really change the center frequency), the USRP (this one works wonders… when the Linux part of it doesn’t crash), the LimeSDR or any other, they all have their own specific quirks that make development painful. 99% of the time, all I need is a way to change the frequency, select the sampling rate, and exchange data (I’m not even including gain in here, most radios I’ve used do better on hardware AGC than on fixed gain). The other features and configuration options are all for very specific optimizations that I’ve very rarely used. The main goals of using an SDR are to have frequency agility and to apply DSP on top of a data stream. For application developers, an SDR transceiver is just a tool to get the RF signal into a data stream and vice versa. It doesn’t matter how the tool works underneath, as long as it works.

I’ve built satellite and communications-related software with the RTL-SDR, the USRP, and the LimeSDR (had to switch radios throughout development – USRP had reliability issues, RTL-SDR had quality issues, LimeSDR had configuration issues i.e. overly complicated) and the easiest one to get working was the RTL-SDR, but the frequency stability, the quality of the signal received and the sensitivity made me switch to the LimeSDR. However, with the LimeSDR, I almost always feel like I’m spending more time writing drivers rather than DSP. The research work I did at university required to cover a very wide bandwidth (as close as we could get to 200 MHz), and I have not been able to get the LimeSDR transfer data at or near its maximum sample rate on a single channel without stuttering (USB is horrible for that – it’s a poll system, not a push system like Ethernet). The board is limited in the maximum transfer bandwidth despite the ADCs being able to push even more data through (limitations of the Altera Cyclone IV if I recall correctly). Using both channels to receive was then limited by the USB data transfer speeds, and we didn’t even have transmission in there yet. We tried using multiple transceivers (we had to use 2 anyways, we tried going up to 4), but the synchronization of the whole system was overly complicated, so we went for a different SDR that supports USB3.1 gen 2 speeds (10 Gbps) and also works through PCIe x16 at full speed (around 30 GBps at that time), but that’s a story for another time.

Having access to all of those configuration options for the LimeSDR is both a curse and a boon. It gives more flexibility to developers, but increases the development time and the risk of bugs. I can understand why some developers would rather not add a lot of extra code just to support one radio for a feature that should have already been supported but needs a workaround to work.

In short, yes I do develop software for the LimeSDR (through the SoapySDR API, so really for any SDR supported by them), but no, it is not general purpose RX/TX programs – I work on application-specific software and DSP.

73 de VE2ZJD

1 Like