Posts by impulse0879

I was staring at the sdrangel logs today and I noticed that sometimes it wasn't actually taking the sample rate after I set it. I was setting it to the max by scrolling upwards on the first digit in the sample rate until it hit the max value of `61.444Msps`. Doing this produces the following log messages, indicating it's actually running at `32Msps`. Note that when this occurs the GUI will incorrectly show `61.444Msps`. At least this explains the glitches I've seen, where the signal clearly does not match the parameters that I've configured. I find the same issue sometimes occurs with the frequency setting (I can change it and.... nothing happens, still sitting there at the same frequency). I don't see the same issues in gnuradio, so this leads me to believe it's related to how sdrangel handles the configuration.

##### SET MAX SAMPLE RATE HERE #####
2026-02-13 00:08:09.345 (D) USRPInputGUI::updateHardware
2026-02-13 00:08:09.345 (D) USRPInput::handleMessage: MsgConfigureUSRP
2026-02-13 00:08:09.345 (D) USRPInput::applySettings: preGetStream: false  force: false " m_devSampleRate: 61444000"
2026-02-13 00:08:09.563 (D) USRPInput::applySettings: forward change to all buddies
2026-02-13 00:08:09.563 (D) DSPDeviceSourceEngine::handleInputMessages: message: DSPSignalNotification
2026-02-13 00:08:09.563 (D) DSPDeviceSourceEngine::handleInputMessages: DSPSignalNotification:  m_sampleRate:  61444000  m_centerFrequency:  435000000
2026-02-13 00:08:09.563 (D) DSPDeviceSourceEngine::handleInputMessages: forward message to  SpectrumVis
2026-02-13 00:08:09.563 (D) DSPDeviceSourceEngine::handleInputMessages: DSPSignalNotification: guiMessageQueue: 0x55edb686fdf0
2026-02-13 00:08:09.563 (D) USRPInputGUI::updateFrequencyLimits: delta: 0 min: 50000 max: 6000000
2026-02-13 00:08:09.563 (D) USRPInputGUI::handleInputMessages: DSPSignalNotification: SampleRate: 61444000, CenterFrequency: 435000000
2026-02-13 00:08:09.563 (D) GLSpectrumGUI::handleInputMessages: message: GLSpectrumView::MsgReportSampleRate
2026-02-13 00:08:09.564 (D) SpectrumVis::handleMessage: DSPSignalNotification:  centerFrequency:  435000000  sampleRate:  61444000

##### CLICKED PLAY HERE #####
2026-02-13 00:08:10.709 (D) USRPInput::handleMessage: MsgStartStop:  start
2026-02-13 00:08:10.709 (D) DSPDeviceSourceEngine::initAcquisition (dummy)
2026-02-13 00:08:10.709 (D) DSPDeviceSourceEngine::startAcquisition
2026-02-13 00:08:10.709 (D) DSPDeviceSourceEngine::handleInputMessages: message: DSPAcquisitionStart
2026-02-13 00:08:10.709 (D) DSPDeviceSourceEngine::gotoIdle
2026-02-13 00:08:10.709 (D) DSPDeviceSourceEngine::gotoInit:   m_deviceDescription:  USRPInput  sampleRate:  61444000  centerFrequency:  435000000
2026-02-13 00:08:10.709 (D) DSPDeviceSourceEngine::gotoInit: initializing  SpectrumVis
2026-02-13 00:08:10.709 (D) DSPDeviceSourceEngine::gotoRunning
2026-02-13 00:08:10.709 (D) DSPDeviceSourceEngine::gotoRunning:  USRPInput  started
2026-02-13 00:08:10.709 (D) USRPInput::suspendRxBuddies (0)
2026-02-13 00:08:10.709 (D) USRPInput::suspendTxBuddies (0)
2026-02-13 00:08:10.709 (D) USRPInput::applySettings: preGetStream: true  force: true " m_masterClockRate: -1 m_centerFrequency: 435000000 m_devSampleRate: 61444000 m_loOffset: 0 m_dcBlock: 0 m_iqCorrection: 0 m_log2SoftDecim: 0 m_lpfBW: 1e+07 m_gain: 50 m_antennaPath: TX/RX m_gainMode: 0 m_clockSource: internal m_transverterMode: 0 m_transverterDeltaFrequency: 0 m_replayOffset: 0 m_replayLength: 20 m_replayStep: 5 m_replayLoop: 0 m_gpioDir: 0 m_gpioPins: 0 m_useReverseAPI: 0 m_reverseAPIAddress: 127.0.0.1 m_reverseAPIPort: 8888 m_reverseAPIDeviceIndex: 0"
2026-02-13 00:08:10.710 (D) SpectrumVis::handleMessage: DSPSignalNotification:  centerFrequency:  435000000  sampleRate:  61444000
2026-02-13 00:08:10.710 (D) USRPInputGUI::handleInputMessages: DSPSignalNotification: SampleRate: 61444000, CenterFrequency: 435000000
2026-02-13 00:08:10.710 (D) GLSpectrumGUI::handleInputMessages: message: GLSpectrumView::MsgReportSampleRate
2026-02-13 00:08:10.712 (D) USRPInput::applySettings: clock set to  "internal"
2026-02-13 00:08:10.712 (D) USRPInput::applySettings: exception:  ValueError: Requested sampling rate (61.44 Msps) exceeds maximum tick rate.
[INFO] [B200] Asking for clock rate 32.000000 MHz... 
[INFO] [B200] Actually got clock rate 32.000000 MHz.

Additionally, after seeing the same overruns in GNURADIO I'm now less convinced that the following has anything to do with the problem at hand. I think it's either the transport layer or some buffer in libuhd.

Quote from impulse0879

Regarding performance issues

While digging to see if they support `FASTLOCK MODE` I stumbled upon this code here.

https://github.com/f4exb/sdrangel…pinput.cpp#L109

I wonder if this is at all related to the performance issues discussed above? The comment suggests the current FIFO size was based on a max 50Msps, though these devices can actually go higher than that. Perhaps increasing the FIFO size would improve the performance for folks who are running into issues at the full sample rate.

Quote from VMA

2) Depending on the tuned frequency, you will see many "birdies" - these go away if you just tune +/-1MHz - I find that annoying

4) Spectrum sweeps are slow

I have been doing some more research into these two points. The video here briefly touches upon both points.

Regarding number 2

(Skip to timestamp 7:19)

They discuss a filtering mechanism built into the AD9361. This may mitigate said "birdies" but it may not - I don't know.

At first glance it looks like USRP supports this mechanism. They have a function to configure it... but I don't see them using it anywhere.

uhd/host/lib/usrp/common/ad9361_driver/ad9361_device.cpp at ab8ec9973324299828d48d7a27258939dd6ca837 · EttusResearch/uhd

The USRP™ Hardware Driver Repository. Contribute to EttusResearch/uhd development by creating an account on GitHub.

github.com

I guess it is possible they aren't calling it simply because it is meant to be used by the end user (e.g. sdrangel). That would make sense, as there is probably not a sane default.

Regarding number 4

(Skip to timestamp 13:27)

They discuss something called `FASTLOCK MODE`. I do not see support for this in the USRP code. If you are willing to do something more involved then you may find it suitable for your application. See the page here for more details/limitations.

AD9361 high performance, highly integrated RF Agile Transceiver™ Linux device driver [Analog Devices Wiki]

Note: Above that section they also discuss the use of the external clock input. Without a peek through the datasheet it's not clear to me if this would entirely replace the BBPLL (thus eliminating it's calibration/lock delay). But, assuming for a moment that it does replace the BBPLL and that you have an external clock source which can hop/lock faster than the internal BBPLL, this may also be suitable for your application.

Regarding performance issues

While digging to see if they support `FASTLOCK MODE` I stumbled upon this code here.

sdrangel/plugins/samplesource/usrpinput/usrpinput.cpp at c45b8f59fa8c3f8c85c6a350d1563c2bd7b1b83a · f4exb/sdrangel

SDR Rx/Tx software for Airspy, Airspy HF+, BladeRF, HackRF, LimeSDR, PlutoSDR, RTL-SDR, SDRplay and FunCube - f4exb/sdrangel

github.com

I wonder if this is at all related to the performance issues discussed above? The comment suggests the current FIFO size was based on a max 50Msps, though these devices can actually go higher than that. Perhaps increasing the FIFO size would improve the performance for folks who are running into issues at the full sample rate.

Quote from VMA

but this is a problem because I use the PC for work and need it to be on Windows.

I dual boot for the same reason, and I find it quite reliable these days. Back in the day there were many problems. Nowadays, so long as you have a second physical disk for the two images, it's quite stable. If you don't have two disks, Windows periodically erases your Linux EFI entry when it updates. Not that it is hard to fix that when it happens, but it is certainly... annoying :)

Quote from VMA

Can you try SDRangel under Windows? I would be interested if you can demodulate FM radio with 61.444MS/s.

Regards,
Vitor

I gave this a try today. I dual boot, so this is the exact same PC that was working at the full sampling rate in Linux. However, on Windows I cannot sample higher than 20MS/s before I get overruns:

audio gets choppy if I go any higher than this. I would wager the USB (FX3 specifically, perhaps?) drivers are the culprit.

Quote from VMA

Which BFM pass filter did you toggle?

I meant this selector that is built into the BFM plugin, inside the red box in the image here:

BPF may be the wrong term... I have no real signal processing experience so I wasn't sure what else to call it :)

On Linux, I can drag this "filter" back and forth across the entire spectrum (red arrows) and it would successfully demodulate any station I placed it over top of.

Best regards

Hey folks,

VMA, thanks for sharing some info on this radio. There's not much about it online! I wanted to share my experience with this radio as well. This is my first post here so I hope I'm not breaking any rules with links to stuff, etc :)

To be specific, this is the b220 clone that I purchased: https://opensourcesdrlab.com/products/libresdr-b220-mini-ad9361

It comes with the `7A200T` variant of the FPGA. I opted for this version for more room in the FPGA for experiments :).

You noted above:

Quote from VMA

Conclusion: I don't see any different performance! Decoding BOM Cine (Hispasat) is only viable with 6MS/s. If you configure higher values, demodulation breaks. This is the same I got under Windows.

The Linux PC is a Core i5-6300U with 16GB RAM. It is an industrial mini PC, so it is less performant than my main PC (Core i9-13900KF). I don't know how much this matters in terms of MS/s.

With FM Broadcast it is the same: you can listen to radio up to 20MS/s on both (Linux/Windows). You can visualize up to 61.444MS/s, but here things start to break down. This is probably the limit of USB3.0.

OTOH I've found that my radio can demodulate Broadcast FM in SDRAngel while sampling at the full 61.44MSPS. I can just slide the BFM pass filter around the whole range and it works. Note that this was with only one receive channel enabled. My PC specs are Ryzen 9 9900X / 32GB ram. So far I have only tested Linux, but I can test windows too if someone is curious.

I will also note that I built the FPGA image from the source, it's in this repository here. https://github.com/bkerler/LibreSDR_UHD_B220_Mini_FPGA

Personally I'm quite happy with the performance of this radio.