DSD-FME dsd-fme/sdr++/rigctl issue?

[bcorbin]

Hi all!

I've been using DSD-fme with sdr++ to monitor a few conventional systems, I've used it directly with an sdr to monitor some trunked systems, and it's worked well. Over the last couple of days, I've tried to get trunking to work with sdr++ and have run into a weird issue.

* I set sdr++ to an active control channel. Signal strength is great (-fme decodes fine if I'm connected directly to the sdr). If I don't have rigctl turned on, -fme decodes the control channel (from sdr++) with no problem.

* If I turn rigctl on, -fme will retune sdr++ (as it should) to track the voice activity. ...and that works for a transmission or maybe two.

* ...but then, when the transmission on the voice channel ends, it looks like the RF gain on the SDR resets to some very low value (nil?). I can't be 100% positive that that's what is happening, as sdr++ doesn't pick up any change in the settings it displays - as far as it knows, gain and AGC settings are unchanged. Now the sdr can't hear anything - -fme and sdr++ revert to scan and can't find any control channel (no significant signal in the sdr).

* At this point, the RF gain/agc controls in sdr++ have no effect on the sdr, and the only way to reset things is to stop and restart the source in sdr++

I'm using the following command to invoke -fme: dsd-fme -N -T -ft -mq -i tcp -U 4532

What am I missing? 8*P

 

[TheButcher]

Use DSD+ for Trunking...

 

[bcorbin]

I do use dsd+FL on the rare occasions where I have to use windows... that solves a problem, not this problem...

 

[TheButcher]

dsd-fme\dsd-fme -i tcp -U 4532 -f1 -T -G group\group.csv -N 2> log\log.ans

 

[bcorbin]

dsd-fme\dsd-fme -i tcp -U 4532 -f1 -T -G group\group.csv -N 2> log\log.ans

Unfortunately, the addition of a group file doesn't change the interaction with rigctl

 

[lwvmobile]

Okay, so, might need a bit more information. When you say dsd-fme drops signal and SDR++ starts to scan around for signal, can you see actual signal in SDR++ during the scan in the "radio" that is set up?

Also, might be worth mentioning which system you are trunking on and which type of system it is.

Another thing, what bandwidth and squelch values are you using in SDR++? any other check boxes checked (low pass, high pass, etc)

Lastly, I noticed you are using -mq which might indicate simulcast. If it is a simulcast system, it may or may not decode properly. Pay attention to the demod and when it goes into the scan mode looking for the control channel, is it set to 6000 or 4800?

Trying to run through things in my head that might cause this issue. Also, on the top left and also on the network audio sink, there are volume sliders for the demodulated signal audio, those need to be set to a reasonable level (just left at full) I have observed some people turn those sliders down assuming it controls the digital voice audio.

 

[bcorbin]

Okay, so, might need a bit more information. When you say dsd-fme drops signal and SDR++ starts to scan around for signal, can you see actual signal in SDR++ during the scan in the "radio" that is set up?

I set SDR++ up on the CC. A voice channel is assigned and the SDR follows. Audio decode is fine. The transmission on the voice channel ends. The SDR now begins to scan through the CC and alternate CC's.

The waterfall and spectrum plots remain active. Sometimes when it returns to the active CC I can see it in the waterfall and spectrum, sometimes there is no evidence of a signal there (though I continue to hear it just fine on a real radio parked nearby).
When I do see a signal on the active CC frequency, it is much lower in signal strength than it should be.

Stopping the SDR, then restarting it, appears to reset the SDR and all is good again until the receiver is steered to another voice frequency...

Does that help??

Also, might be worth mentioning which system you are trunking on and which type of system it is.

I'm actually running at several locations, listening to different repeater sites in a large P25p2 TDMA system (LA-RICS). The fore-mentioned behavior occurs at each location; each location runs its own local computer and dongle and monitors a different site.

Another thing, what bandwidth and squelch values are you using in SDR++? any other check boxes checked (low pass, high pass, etc)

Excellent question (I've been bitten by the HPF/LPF !) 15kc bandwidth, no squelch, no noise-reduction, no HP/LP, no de-emphasis. When I turn off rigctrl and monitor just the CC, I get solid decode and no anomalies over long listening periods.

Lastly, I noticed you are using -mq which might indicate simulcast. If it is a simulcast system, it may or may not decode properly. Pay attention to the demod and when it goes into the scan mode looking for the control channel, is it set to 6000 or 4800?

4800

Trying to run through things in my head that might cause this issue. Also, on the top left and also on the network audio sink, there are volume sliders for the demodulated signal audio, those need to be set to a reasonable level (just left at full) I have observed some people turn those sliders down assuming it controls the digital voice audio.

Ah! And I have always assumed the volume control was inactive for network decode - it never had an effect on my ability to decode conventional digital systems... Alas, it doesn't have any effect on what I'm seeing here.

The weird thing is that the (RF) gain doesn't appear to be consistent from scan to scan -

 

[lwvmobile]

When SDR++ is tuning, do the frequencies in the top that it is tuning to seem valid when it attempts to return to the control channel? Also, what sampling rate (bandwidth) are you running the dongle at? Do you have the zoom enabled and turned up for the waterfall? What is the build date on the top of the title bar? What kind of SDR device are you using?

I'm trying to see if anything else sticks out to me as an issue. Otherwise, you seem to have a god setup, but I do wonder if your dongle might have an issue with tuning around, since you say it gets fixed when you stop the SDR and restart it.

 

[bcorbin]

When SDR++ is tuning, do the frequencies in the top that it is tuning to seem valid when it attempts to return to the control channel? Also, what sampling rate (bandwidth) are you running the dongle at? Do you have the zoom enabled and turned up for the waterfall? What is the build date on the top of the title bar? What kind of SDR device are you using?

Another really good question. The first few times I saw this, I wasn't convinced that the frequencies displayed in SDR++ were what I was looking at in the waterfall, as there was no indication of a CC in the waterfall. But under closer scrutiny, it looks like waterfall and spectrum are matching up with the frequency display, it's just that the gain drops dramatically - signal goes from -30 to -60 to < -80 to -70... (never back to -30). I can sometimes see strong neighboring signals (also greatly reduced) in the waterfall that lead me to believe the frequency is correct.

The sampling rate is 1.024 MHz (no decimation), I use zoom to check my bandwidth, but mostly leave it disabled. SDR++ version is 1.3.0, with a build-date of Apr 2 2026 (I do a git-pull and build locally on each machine). The SDR devices are all RTL2832's.

I'm trying to see if anything else sticks out to me as an issue. Otherwise, you seem to have a god setup, but I do wonder if your dongle might have an issue with tuning around, since you say it gets fixed when you stop the SDR and restart it.

It's repeatable across all the computers and all the devices... so I've tentatively ruled out hardware (though I've certainly seen stranger coincidences).

Tracking works (on all boxen and dongles) if I use -fme directly with the dongle, so it 'feels' like something in the rigctl chain. Could be an OOB in SDR++ over-writing the gain value? It seems strange that I'm the only one seeing this, and it occurs across multiple boxes and dongles for me... speaking of strange coincidences 8*P 8*P

 

[bcorbin]

Ahhhh... the one thing that makes my situation different is that I'm compiling/running everything under FreeBSD.

I had to add <sys/socket.h> to rtl_sdr_fm.cpp, but the rest of the (-fme) code is untouched and compiles fine...

I may need to look a little more closely at that... I may have shot myself in the foot 8*P

 

[lwvmobile]

Sounds like a bit of a mystery then why its behaving the way it is. I don't want to immediately suspect FreeBSD or something in the build process that caused this to possibly happen or some issue with the RTL support and FreeBSD, but its something to keep in mind.

How about the Tuner Gain and RTL Gain boxes, have you tried running with those checked and also unchecked? I can't say its an issue or not, but sometimes when you have really strong signal and you are trying to lock on a weaker signal in the same spectrum, it may cause issues and you may need to tweak the gain values, but I don't know if that is what is happening here or not. Also, are you using the center tuning option, or not (arrows or bullseye icon beside the frequency in SDR++) Might try toggling those and see what happens.

I had to add <sys/socket.h> to rtl_sdr_fm.cpp, but the rest of the (-fme) code is untouched and compiles fine...

I'll try to keep that in mind to add that line to a future commit.


Outside of that, might try manually connecting to the RIGCTL on SDR++ and manually issuing commands to it to see if when it changes frequencies, if the same behavior happens or not.

echo "\set_freq 478050000" | nc -w 1 localhost 4532

 

[bcorbin]

Sounds like a bit of a mystery then why its behaving the way it is. I don't want to immediately suspect FreeBSD or something in the build process that caused this to possibly happen or some issue with the RTL support and FreeBSD, but its something to keep in mind.

At this stage, the problem seems unique to my FreeBSD boxes. SDR++ works well for analog and conventional digital, -fme works well on trunked/conventional systems wired direct to SDR, -fme works well with SDR++ on conventional systems and CC-only monitoring... Taken together, I think we're both pointing at the FreeBSD build.

How about the Tuner Gain and RTL Gain boxes, have you tried running with those checked and also unchecked? I can't say its an issue or not, but sometimes when you have really strong signal and you are trying to lock on a weaker signal in the same spectrum, it may cause issues and you may need to tweak the gain values, but I don't know if that is what is happening here or not. Also, are you using the center tuning option, or not (arrows or bullseye icon beside the frequency in SDR++) Might try toggling those and see what happens.

I've toggled both the Tuner Gain and RTL Gain, but once the problem kicks in, SDR++ ignores them. I have also toggled center/arrows.

I'll try to keep that in mind to add that line to a future commit.

I need to look at <sys/socket.h> and see how it differs from what linux is doing. If linux makes an assumption that doesn't hold up in FreeBSD, that could trigger what I'm seeing - something goes OOB and writes into the 'Gain' space.

Outside of that, might try manually connecting to the RIGCTL on SDR++ and manually issuing commands to it to see if when it changes frequencies, if the same behavior happens or not.

echo "\set_freq 478050000" | nc -w 1 localhost 4532

I just gave it a shot, and the gain remained high (that is, it didn't reproduce the problem).


Anyway - I think this is on my shoulders, now - If I find a solution, I'll let you know. Thanks again for all the work you put into this!

 

[lwvmobile]

Just for fun, one other thing to try might be the opposite, having netcat listen to the RIGCTL port and setting up DSD-FME so that it is connected to the TCP audio of SDR++, and seeing what comes over RIGCTL. What you would do is just stop the RIGCTL server in SDR++, and start up netcat first with nc -lv 4532 and then starting DSD-FME the way you usually do. It'll let you see what is coming over that port. When it attempts to tune, you should get something like F 851800000 and then you'll need to respond in the nc terminal with 1 (or honestly anything that isn't -1) so DSD-FME can get the proper response, or else dsd-fme will hang up until it receives that reply. I'd see if there is extra garbage coming over the UDP port this way, just to rule that out.

I had to simulate the action by running a .bin file, but you can just listen to the C and see what all comes over port 4532



EDIT: I also just realized might be worth a test again to use echo "F 478055500" | nc -w 1 localhost 4532 instead to command SDR++ on that test, to see if using F instead of the \set_freq causes issues with current SDR++ code.

 

[bcorbin]

Looking at the output from -fme, it's doing exactly what it should.

Using 'F' and '\set_freq' both lead to the same problem in SDR++. It's less clear to me now whether an SDR parameter (Gain/AGC) is getting overwritten or the dongle is not being set to the proper frequency. It's beginning to look like a confusing mixture of both.

Looking at SDR++'s github page, the rigctl client is listed as 'unfinished' - so that's probably it - the code that's there may work better in some builds than others.

So, I think the moral of the story, for now, is - I'll continue to use dsd-fme direct with the dongles (which works very well, thank you!) for trunking, and use SDR++ for conventional systems.

Thanks for walking me through some of these tests - I feel a lot smarter than when I started trying to tackle the problem!!

 

[lwvmobile]

I don't see any recent chages in SDR++ code regarding RIGCTL server that would cause this issue. The code found here looks alright to me, but then again, I don't know if any changes found anywhere else may be impacting it, or if building SDR++ with a particular toolchain in FreeBSD is an issue (clang vs gcc or compiler optimization level?). As far as I can tell, the last meaningful code change to RIGCTL server in SDR++ came from when I reported another issue where the token for changing bandwidth changed and had to be fixed.

Just another thing that popped up in my mind, do you have more than one radio or vfo enabled in SDR++? If so, disable all but one and see what happens. I think there is an optional argument for which vfo to control in rigctl, might be a long shot, but just if you do have that set up for more than one, then see what happens if you disable all but one of them. Might require deleting them and not just unchecking them, and also, see if the controlled vfo is the same one you have in the menu box for rigctl server.

Also, if you can, try a different optimization level for compiling SDR++, maybe there is an overflow and its screwing something up. Higher optimization levels tend to reveal bugs like that.

 

[lwvmobile]

Also, try running SDR++ with the console command to get the verbose dump into the terminal, maybe that will reveal some information as well. Might need to use the -c option when launching from terminal.

 

[bcorbin]

Like.. ? 8*)

[18/04/2026 18:34:01.000] [INFO] RTLSDRSourceModule 'RTL-SDR Source': Tune: 769604150.000000!
[18/04/2026 18:34:01.000] [INFO] RTLSDRSourceModule 'RTL-SDR Source': Tune: 770006250.000000!
[18/04/2026 18:34:03.000] [INFO] Rigctl command: 'F 771331250'
rtlsdr_demod_write_reg failed with -4
[18/04/2026 18:34:03.000] [INFO] RTLSDRSourceModule 'RTL-SDR Source': Tune: 771733350.000000!
[18/04/2026 18:34:03.000] [INFO] RTLSDRSourceModule 'RTL-SDR Source': Tune: 771331250.000000!
[18/04/2026 18:34:05.000] [INFO] Rigctl command: 'F 770256250'
r82xx_write: i2c wr failed=-4 reg
r82xx_set_freq: failed=-4=10 len=7

Only one radio attached.

 

[lwvmobile]

Those errors are linked here and tied to the return for the libusb_control_transfer. I found error code -4 is:

LIBUSB_ERROR_NO_DEVICE (-4): The device has been disconnected during the transfer.

So, with this in mind, you say it works fine when DSD-FME is driving the dongle, but when SDR++ is doing so, we get these errors. So, what kind of hardware are you running on? Are you running on a desktop, or laptop, or rinky dink low powered SoC like a Raspberrry Pi? Is CPU utilization high when running SDR++? Any shaky or loose USB connections?

 

[bcorbin]

All the machines are desktops, none of the machines are being taxed in any dramatic way. Solid USB connections, no issues when used on conventional systems (SDR++ and -FME)

 

[lwvmobile]

No idea, could be in how SDR++ builds its rtl dongle module. I have a feeling, seeing those messages, it could be more likely that you get those same errors if you just spammed random frequencies directly into the SDR++ frequency entry at the top, each time changing the 10s value so that it is forced to retune. At this point, I don't think its to do with using rigctl, but just in SDR++ itself.