All good. I had to force TCP port to 4532 and everything is working great.
Thanks
Thanks
DSD FME
- Thread starter lwvmobile
- Start date
lwvmobile
DSD-FME
That's good to hear. I tried to chime in earlier, but thunderstorm cropped up and this is the fourth attempt I'm making at a reply, my ISP connection has already dropped and reset twice, and then the power flickered once to reboot my server/gateway, all when I either began to read the last messages here or start a reply.
A couple of observations about your bat file, however.
Code:
cd dsd-fme
pulseaudio.exe --start --no-cpu-limit=TRUE --exit-idle-time=3600
ECHO The Pulse Audio Server should now be active!
@REM dsd-fme -fs -i tcp -U 4532 -T -C examples\ctm-site.csv -G examples\ctm-group.csv -N 2> log.ans
dsd-fme -fs -i tcp -U 4532 -T -C examples\ctm-site.csv -K examples\multi_key_hex.csv -N 2> log.ansIf you are going to launch the pulse audio server, you should tell DSD-FME to use the pulse audio output. Its the default in Linux builds, but not in Windows builds. Its also highly recommended for any TDMA systems, since the OSS handling can't play voice in both slots simulataneously, it will preempt the audio in Slot 2 by default if that audio output is used. Also, if you are going to start the pulse audio server in the same bat file as your dsd-fme launch (instead of seperately like how I have them in the example bat files) then its usually a good idea to close the pulse audio server on exit as well, or multiple pa sessions will all run in the background until the idle time out closes them.
Might consider changing to something like this:
Code:
cd dsd-fme
pulseaudio.exe --start --no-cpu-limit=TRUE --exit-idle-time=3600
ECHO The Pulse Audio Server should now be active!
@REM dsd-fme -fs -i tcp -U 4532 -T -C examples\ctm-site.csv -G examples\ctm-group.csv -N 2> log.ans
dsd-fme.exe -o pulse -fs -i tcp -U 4532 -T -C examples\ctm-site.csv -K examples\multi_key_hex.csv -N 2> log.ans
@REM Shutdown pulseaudio
pactl.exe exitOr just keep in mind to run the number 4 bat file and close it manually and also clean out any remnants from other times it didn't get a clean shutdown, it'll usually store old session files in the \dev\shm\ folder (which can keep you from being able to copy and paste the folder from location a to location b later on if desired.
As far as your earlier issues with the RIGCTL, only thing I can think of is to keep in mind, there is actually TWO connections occurring between DSD-FME and SDR++.
First is for the TCP audio sink, that uses 7355, and RIGCTL uses port 4532, you'll want both enabled and started to 'listen' while launching DSD-FME. You can also change the tcp line to tcp:localhost:7355 or tcp:192.168.7.8:7356 for example, if you want to use a remote machine, or not use the stock defaults for TCP sink. The -U 4532 is the port for RIGCTL, but it will always mirror and connect to the same host as the tcp:address
ort line, so it'll connect to the same address as TCP audio sink, but on the port specified by U for rigctl.
Thanks,
I just had to specify the ip adress and port for TCP:
My final bat file looks like this.
I just had to specify the ip adress and port for TCP:
Code:
-i tcp:127.0.0.1:7355
Code:
cd dsd-fme
pulseaudio.exe --start --no-cpu-limit=TRUE --exit-idle-time=3600
ECHO The Pulse Audio Server should now be active!
@REM dsd-fme -fs -i tcp -U 4532 -T -C examples\ctm-site.csv -G examples\ctm-group.csv -N 2> log.ans
dsd-fme -o pulse -fs -i tcp:127.0.0.1:7355 -U 4532 -T -C examples\ctm-site.csv -G examples\ctm-group.csv -N 2> log.ans
pactl.exe exit
Are there any known issues with NXDN4800 decoding currently on the Windows build? I have a few wav files that decode fine and show call activity when piped into DSDPlus, however FME doesn't show any call activity at all. I'm quite puzzled with this. I've been using this command line..
dsd-fme.exe -i audio\nx48.wav -s 96000 -o pulse -Z -fi -N 2> log.ans
Switching to -fn and using an NX9600 wav file play just fine. But I can't get 4800 to work at all for some reason....
dsd-fme.exe -i audio\nx48.wav -s 96000 -o pulse -Z -fi -N 2> log.ans
Switching to -fn and using an NX9600 wav file play just fine. But I can't get 4800 to work at all for some reason....
lwvmobile
DSD-FME
I've always had mixed luck playing back any nxdn based wav files through the input like you are trying to do. Its not very reliable for nxdn.
Ah ok, so it's not just me! Thanks!! I'll trying piping in thru VBCable.
How can I specify the audio output from dsd-fme to vb cable with pulse audio?
I'm piping data from sdr++ via TCP and would like to pipe decoded audio to Zello via vb cable.
I'm piping data from sdr++ via TCP and would like to pipe decoded audio to Zello via vb cable.
lwvmobile
DSD-FME
The only way to route audio in and out of DSD-FME is to use the Windows Volume Mixer in Windows (or similar if there are any third party applications that do the same thing) or Pulse Audio Volume Control, or pulsemixer, or similar, in Linux. If you want to pipe the audio into Zello with vbcables, I'd just open the output from dsd-fme, probably just named pulse or something, and have it play into the VBCables. I don't have any internal handling for which device is selected to be used. In the future, I'll look into seeing how to do that.
This is an older image I found, but basically just change Output device to the VB Cable.
Anyone had luck running DSD-FME with rtl_fm on a raspberry pi?
I got it working with GQRX but I have to manually select the inputs/outputs so I would like to automate everything to start on boot, and rtl_fm takes less computing power.
My issue is that I'm not able to link the rf traffic from rtl_fm to dsd-fme for decoding.
I got it working with GQRX but I have to manually select the inputs/outputs so I would like to automate everything to start on boot, and rtl_fm takes less computing power.
My issue is that I'm not able to link the rf traffic from rtl_fm to dsd-fme for decoding.
lwvmobile
DSD-FME
Going by your other setup you had running, I would try:
Code:
dsd-fme -fs -i rtl:0:450M:0:12:2 -T -C examples/ctm-site.csv -G examples/ctm-group.csv -N 2> log.ansWhere the syntax of the RTL input is:
Code:
RTL-SDR options:
Usage: rtl:dev:freq:gain:ppm:bw:sq:udp
NOTE: all arguments after rtl are optional now for trunking, but user configuration is recommended
dev <num> RTL-SDR Device Index Number
freq <num> RTL-SDR Frequency (851800000 or 851.8M)
gain <num> RTL-SDR Device Gain (0-49)(default = 0; Hardware AGC recommended)
ppm <num> RTL-SDR PPM Error (default = 0)
bw <num> RTL-SDR Bandwidth kHz (default = 12)(8, 12, 16, 24)
sq <num> RTL-SDR Squelch Level vs RMS Value (Optional)
udp <num> RTL-SDR Legacy UDP Remote Port (Optional -- External Use Only)
Example: dsd-fme -fs -i rtl -C cap_plus_channel.csv -T
Example: dsd-fme -fp -i rtl:0:851.375M:22:-2:24:0:6021So, you may need to adjust the PPM in this example (the very last one) from 2 to what your effective PPM is, integer only, so no decimal numbers. Also of note, Linux uses forward slashes, and not back slashes in the command prompt, and you may need to adjust for the location of those csv files vs where you are in the terminal. If you are in the home directory in the terminal, and the csv files are also in the home directory, then you don't need to specify the folder, just the name of the csv files.
One thing of note though, if the system's signal stregnth is marginal or weak, then rtl input won't work nearly as well as something else, like SDR++. Can't say entirely for sure about GQRX, I haven't used it since SDR++ came along, aside from a few tests.
Thanks.
The audio comes in very choppy (and with delay) although I have a good reception. I put the gain to 49dB.
The RMS very is 250 when a transmission comes in and around 10 when no transmissions.
Here is the command I used:
The audio comes in very choppy (and with delay) although I have a good reception. I put the gain to 49dB.
The RMS very is 250 when a transmission comes in and around 10 when no transmissions.
Here is the command I used:
Code:
dsd-fme -fs -i rtl:0:447.625M:49:0:2:40 -o pulse -N 2> log.anslwvmobile
DSD-FME
Yeah, that's not very strong at 250. Try it with Gain 0 for AGC, see if it does any better, if not, then its not going to work well with RTL input.
Try this instead:
or
I think you might have had some out of order parameters on that. I think I might have told you wrong on the order in my earlier example, even I have a hard time keeping it straight sometimes.
The last two for squelch and UDP are irrelevant to DMR, the SQ is only used for NXDN and dPMR currently.
Try this instead:
Code:
dsd-fme -fs -i rtl:0:447.625M:0:0:8 -o pulse -N 2> log.ansor
Code:
dsd-fme -fs -i rtl:0:447.625M:0:0:12 -o pulse -N 2> log.ansI think you might have had some out of order parameters on that. I think I might have told you wrong on the order in my earlier example, even I have a hard time keeping it straight sometimes.
Code:
rtl:dev:freq:gainpm:bwThe last two for squelch and UDP are irrelevant to DMR, the SQ is only used for NXDN and dPMR currently.
lwvmobile
DSD-FME
If you send it, and tell me what it's supposed to say, then I'll look at it, but I won't make any guarantees.
Quick question regarding the In Level percentage... is there an optimal value you should be shooting for there? 100%?
lwvmobile
DSD-FME
You know, I honestly don't truly know if there is an optimal percent in level. Somebody earlier mentioned that they thought they got better decodes at around 50%, but I've had good decodes at low levels and at higher levels. I honestly just think its more of a system to system, or sample to sample. The % meter can also exceed 100 percent, so you know, that's also a thing.
Ha, ok! So find a happy value a carry on. That works!
I personally get good results with either low and high in levels on NXDN48 network. In fact in level was never the reason for my issues which are almost zero to be fair. Despite that I dont think it's a good idea to keep it above 100. I keep mine gain low enough to get good decode and at the same time to not overload my SDR.
Similar threads
