DSD FME

[jimlawrence]

Many thanks for your reply!! The positives in dsd fme far outwigh the few "flaws". Your software meets my needs very well!
The way I've gotten around this problem of a TG being blocked is to close dsd fme and then restart it. There's no group.csv file in use, so it's all good and the TG can be heard again on restart.
Keep up the good work! Thank you!

 

[francisuk29]

I dont know if your know SDR++ well enough to use a server mode instead of the GUI interface?

So far i have

network_sink_config

{
"Radio": {
"hostname": "YOUR INTERNAL IP or localhost",
"listening": true,
"port": 7355,
"protocol": 0,
"sampleRate": 48000,
"stereo": false
}
}

rigctl_server_config

{
"Rigctl Server": {
"autoStart": true,
"host": "Internal IP or localhost",
"port": 4532,
"recorder": "",
"recording": true,
"tuning": true,
"vfo": ""
}
}

and then start the SDR++ server

sdrpp -a Internal IP --server

Im stuck here, How about yourself, Is your USB RTL working? or is it becouse im using the RT|L-TCP?

 

[LimaZulu]

It's not very clear what is the exact problem you have? Could you please be more specific?

 

[francisuk29]

It's not very clear what is the exact problem you have? Could you please be more specific?

Sorry.

Normally when you start the SDR++ server, it should load the network_sink and rigctl_server config and rtl_sdr config's but for me, Is not, so not sure if anyone is experience the same issue?

I know the SDR++ GUI interface is working but im talking about the server mode of SDR++ with DSD-FME for trunking via rigctl server

 

[LimaZulu]

I used SDR++ server for remote control but never together with rigctl server.
I had to think a bit to clear things in my head but at first glance it seems you are missing a piece. Basically you are running one server waiting to be controlled (sdrpp) and a second one (rigctl) waiting to be controlled as well but you are missing the link between them. You need a third instance that connects to both servers and controls them. In other words your third instance needs to connect to sdrpp server and tune it to control channel and connect to rigctl as well in order to tune sdrpp server to where control channel sends it

 

[lwvmobile]

When I have a chance, I'll try to get SDR++ to work in server mode using an rtl_tcp instance over my LAN and see how it goes. If memory serves though, once you connect to the SDR++ server with the local SDR++ client, you then get a secondary drop down box with options for devices on the server end. I'm not sure if rtl_tcp is one of those options or not, though. I know you can connect sdr++ directly to rtl_tcp, but I don't know if you can connect an sdr++ server to an rtl_tcp instance, and then connect and use that instance with another sdr++ client.

Is there a benefit or something in particular to gain from using the SDR++ server in this instance and not just using SDR++ Locally to connect to a remote rtl_tcp session? Seems more like the SDR++ server is meant to be a more versitile replacement that can be used to serve multiple devices as opposed to rtl_tcp that can only use a single device.

 

[lwvmobile]

Also, just FWIW, A while back, I did make a feature request to SDR++ to have a 'headless' mode, similar to server mode, instead of it being a server, that it would be a headless instance starting up with the last known good parameters, including audio sinks and active modules like rigctl server. It basically got shot down immediately by the owner.

SDR++ Headless Mode · Issue #1063 · AlexandreRouma/SDRPlusPlus

I looked to see if this was already requested, or mentioned, but couldn't find anything in issues or projects, so I apologize if this has already been asked. How about a feature similar to the SDR+...

github.com

I don't mention this to pester the guy about it, so, best just to leave that alone, he's already shot it down, so I don't want to ruffle his feathers about it. I think the headless mode may have been something similar to what you are interested in trying to do.

 

[francisuk29]

Also, just FWIW, A while back, I did make a feature request to SDR++ to have a 'headless' mode, similar to server mode, instead of it being a server, that it would be a headless instance starting up with the last known good parameters, including audio sinks and active modules like rigctl server. It basically got shot down immediately by the owner.

SDR++ Headless Mode · Issue #1063 · AlexandreRouma/SDRPlusPlus

I looked to see if this was already requested, or mentioned, but couldn't find anything in issues or projects, so I apologize if this has already been asked. How about a feature similar to the SDR+...

github.com

I don't mention this to pester the guy about it, so, best just to leave that alone, he's already shot it down, so I don't want to ruffle his feathers about it. I think the headless mode may have been something similar to what you are interested in trying to do.

You hit the nail on the head! Excaily what i wonted however.... I think the dev isnt bother about it and just wonts a GUI of some sort....Did ask on DIscord but nothing as of yet .... Oh well.

The best i got outta SDR++
D:\Data1\sdrpp>sdrpp --server -a 192.168.1.250

[07/08/2023 21:49:58.000] [INFO] SDR++ v1.1.0
[07/08/2023 21:49:58.000] [INFO] Loading config
[07/08/2023 21:49:58.000] [INFO] =====| SERVER MODE |=====
[07/08/2023 21:49:58.000] [INFO] Loading modules
[07/08/2023 21:49:58.000] [INFO] Loading D:/Data1/sdrpp/modules/rtl_tcp_source.dll
[07/08/2023 21:49:58.000] [INFO] Initializing RTL-TCP Source (rtl_tcp_source)
[07/08/2023 21:49:58.000] [INFO] Running post-init for RTL-TCP Source
[07/08/2023 21:49:58.000] [INFO] RTLTCPSourceModule 'RTL-TCP Source': Menu Select!
[07/08/2023 21:49:58.000] [INFO] Ready, listening on 192.168.1.250:5259

As you can see, no rigctl server or network_sink loading, Even thought is on the config file to "True" and not "false"

Anyway

Using rtl_fm requires you to attach a USB on a computer where in my case, My PC is on the other side of the room, So in this case, Im using my OpenWrt router with rtl_tcp installed and then a silm jim over my window.

rtl_tcp support · Issue #158 · lwvmobile/dsd-fme

Please could you add support for rtl_tcp, Its supported on small OpenWrt router's and since is Linux both ARM64/x86_64 is supported, It also can be run on any cheap devices with a nice 100 meters o...

github.com

 

[lwvmobile]

Okay, so, here is what I was able to do.

1. Start rtl_tcp on my local machine with command:
rtl_tcp -a 192.168.7.8 -d 0 -g 36 -f 851375000 -p 1236

2. Start sdrpp -s on my file server (192.168.7.5) with default settings:
sdrpp -s

3. Start SDR++ on my local machine, connect to the SDR++ Server on the file server, and then connect that back to the rtl_tcp instance on my local machine.



Everything connected and worked just fine with that configuration.

I also performed the same, but ran both rtl_tcp and sdr++ server on the file server, and was able to get it to work as well, when using the default binding address for rtl_tcp (by not specifying it and letting it pick 127.0.0.1 which I also mirrorred by putting into SDR++ on my local computer and not the file server.



Of course, if you have rtl_tcp running, and want to connect SDR++ to it, seems logical to just bypass the SDR++ server entirely and just connect directly to rtl_tcp.



For my final test, I attempted to configure SDR++ with the default TCP Network Audio Sink and RIGCTL setup while in GUI mode, set to startup in listening mode, and to start the rtl dongle, then I closed the GUI and started it with sdrpp -s --autostart to no avail, it did not start the network output sink or the rigctl server, so it would seem those only function when in GUI mode.

 

[francisuk29]

Of course, if you have rtl_tcp running, and want to connect SDR++ to it, seems logical to just bypass the SDR++ server entirely and just connect directly to rtl_tcp.

Thats what i have always done.

Normally i just issue (on the server for rtl-tcp) -a for ip address as im networking from router > PC (Always via LAN to LAN)

rtl_tcp -a 192.168.1.1

and then either SDR++ or Gqrx will just command it from there what settings you make in the app to the rtl_tcp sever.

@lwvmobile Normally for SDR apps, I set mine to 2.4MHz but how are you finding it at 1.04MHz and then i can see one at 2.408mhz?

 

[lwvmobile]

1024 and 2048 seem fine to me, never noticed any issues, I usually just run them a bit under the advertised full rate of 2.4 (or even 3.2 for those who can get it to work that high) I never find myself needing that much sampling all at once anyways, I usually prefer 2.048 locally, and use the lower 1.024 value when using remotes to cut down on bandwidth and using compression when connecting to SDR++ remotes that are truly remote so it isn't affected by wavering Internet speeds and uplink saturation, etc. I've never really been able to get a dongle to do well at very low values though, so anything like 250 kS doesn't seem to go so well, seems like 960 kS is about as low as I can go on rtl dongles.

 

[leoaln]

I am wanting to run DSD-FME to decode my local county's (Harrison County, MS) Public Service network. It is listed as an Edac Provoice network. I've tried using SDR++ with DSD-FME with no success of DSD-FME receiving anything from SDR++. Using rtl mode in DSD-FME has no output. Log file and screenshots attached.

 

[lwvmobile]

Okay, a couple of things to note. First, in the log file, I see a lot of

rtlsdr_demod_read_reg failed with -1
rtlsdr_demod_write_reg failed with -1
So, I assume you must have tried to use the -i rtl method with SDR++ open, and it tried to use the dongle that SDR++ was already using.

Also, in SDR++, you have your BW set to 50000, which is way too high. You'll want to aim for around 12000 or 14000 for EDACS/Provoice. You may also want to consider using IQ correction checkbox and also not tuning directly on center, depending on your dongle. If you have a 'meh' quality dongle, considering the 72 PPM value, I'm guessing you want to hit the bullseye and tune that frequency slightly off center.

Something Similar to this setup in SDR++ will work well.



Thirdly, you will need to set your audio output sink to a Network/TCP output sink, and also enable RIGCTL module, both enabled and listening, and use a command similar to this to connect to it.

This is a command I use to monitor local EDACS SLERS:
dsd-fme -fp -i tcp -U 4532 -T -C channel_map.csv -G slers-talkgroups.csv -N 2> log.ans



Also, if you intend to trunk, you'll want to create a channel_map file, if you look in your examples folder, you'll see a lot of different examples, but certainly one for trunking EDACS and channels. You can also find a lot of useful info on the Example Usage page and the trunking.sh script.

 

[lwvmobile]

Also, I should mention, if you want to skip using SDR++ and just use the rtl (rtl_fm) built in input for EDACS/Provoice, you can use this command (make sure SDR++ isn't running and tying up the dongle first). I took the liberty of setting it up with the PPM value you have found for your dongle and using AGC for the rtl input, that usually works well enough for me in most circumstances with the rtl input anyways.

dsd-fme -fp -i rtl:0:851.15M:0:72:24 -T -C channel_map.csv -G group.csv -N 2> log.ans

substituting the names of the csv files for the ones you have, of course.

 

[leoaln]

On a different computer with a different Nooelec v5 sdr, running rtl mode, I get flashing green text in the Audio Decode area of window.
This is from the log file

07:46:45 Sync: +EDACS BCH FAIL
Sync: no sync
07:46:45 Sync: +EDACS BCH FAIL
07:46:45 Sync: +EDACS BCH FAIL
07:46:46 Sync: +EDACS BCH FAIL
07:46:46 Sync: +EDACS BCH FAIL
07:46:46 Sync: +EDACS BCH FAIL
Sync: no sync
07:46:46 Sync: +EDACS BCH FAIL
Sync: no sync

 

[lwvmobile]

Yeah, it looks like there is an issue with the signal, could be related to start up settings, or other noise/signal/antenna related issues. What command did you run to start up with? Does that other Nooelec device have the same PPM error as the other one?

 

[leoaln]

Startup command

dsd-fme -fp -i rtl:0:851.15M:0:-1:24 -T -C edacs_channel_map.csv -G harrisoncounty.csv -N 2> log.ans

This is a newer sdr with ppm error of -1 works well in op25. The other sdr is a nooelec mini that is about 8 years old.
Right now, I have only and old 8' fiberglass marine band antenna connected, but the nearest site antenna is less than 5 miles from me.
I bought a l-com HGV-906u from ebay but it is lost in the mail between salt lake city , Utah and Mississippi.

 

[lwvmobile]

If the signal is pretty strong and you are nearby it, let's disable the AGC and run it with a low gain value instead, so try running with these parameters instead:

dsd-fme -fp -i rtl:0:851.15M:36:-1:24 -T -C edacs_channel_map.csv -G harrisoncounty.csv -N 2> log.ans

You'll find the digit after the frequency is the gain value. 0 is for AGC, and values from 1-49 are the rounded gain values similar to how they are in other applications like SDR++ or GQRX when using an RTL dongle. I put 36 for the gain, middle of the road, try a little lower or a little higher, and see if it cleans up the signal. If you have a lot of active channels in that frequency range and they are really close by, then AGC may not be a great idea.

 

[leoaln]

Manually changing the gain lowered the rms value a good bit from where it was with agc on. I’m am going to relocate my antenna to try and improve reception while Pom waiting on the other antenna to arrive

 

[lwvmobile]

What kind of RMS values were you getting before with AGC on and now with various gain values? Were you getting any good decodes at all on the CC, or was the entire thing errors?