DSD FME

[Cretu]

What command did you use? When you use the ncurses terminal, you have to route the console output to a log file or /dev/null , otherwise what happens in that screenshot happens. Usual syntax is to use the command like dsd-fme -N 2> log.ans or dsd-fme -N 2> /dev/null - You always want to make sure to have a 2> log.ans or 2> /dev/null at the very end of the command when using -N.

Indeed, that seemed to help. My bad because it's even on the -h command. Sorry.

That happens when you run it as root and the root account doesn't have access to the pulse audio server. I would recommend not running DSD-FME as the root user (or sudo) or even using the root account in general. This might not be doable though in a live environment, depending on how it was set up though.

How weird is that? Pulse Audio not running in root lol

Lubuntu 20.04 is perfectly fine for DSD-FME. This time, its actually not in my hands, since I don't put together or distribute DragonOS. You need to talk to the person who created that respin and tell him you want FME in it.

Sorry again, it seems like I didn't express myself well. What I wanted to say is that this is good distro, and testing is a worthwhile thing to do. And that is something we all can do, starting by me.


I right now, I think everything is working fine. If you want, I could contact the author of DragonOS to ask him to include your great DSD-FME, but only if you approve. Because that is not my decision

 

[kb9mwr]

Hello lwvmobile,
Have you given any thought to adding support to decode the ham mode, M17?

GitHub - AlexandreRouma/SDRPlusPlus: Cross-Platform SDR Software

Cross-Platform SDR Software. Contribute to AlexandreRouma/SDRPlusPlus development by creating an account on GitHub.

github.com

GitHub - nostar/DroidStar

Contribute to nostar/DroidStar development by creating an account on GitHub.

github.com

 

[lwvmobile]

but only if you approve. Because that is not my decision

That's fine with me. Its all open source, anybody is free to copy it, modify it, distribute it (free of charge hopefully) and so on, as long as they contain the original sources or 'copyrights' or whatever. I just added onto DSD, I didn't write the whole thing from scratch.

Have you given any thought to adding support to decode the ham mode, M17?

Yeah, I'll give it a shot in the future. Not too high on the agenda though, since its baked into SDR++ and others already.

 

[kb9mwr]

Yeah, I'll give it a shot in the future. Not too high on the agenda though, since its baked into SDR++ and others already.

Good to hear, DSD has always been my swiss army knife for the digital modes. I am glad you're continuing the project.

 

[dmedia]

Should we expect DMR RC4?

 

[lwvmobile]

Should we expect DMR RC4?

You should expect EDACS!

Good to hear, DSD has always been my swiss army knife for the digital modes. I am glad you're continuing the project.

 

[dmedia]

You should expect EDACS!

I am very grateful for your work guys!

If there is interest in implementing RC4 in DMR, please send me a private message, I can give a hint about this.

 

[lwvmobile]

So...

Would anybody miss the RTL (rtl_fm) dongle input support if I removed it entirely and replaced it with RIGCTL and TCP Link Audio from SDR++?

Here are the pro's and con's that I can think of:

Pros:
Can remote control the SDR++ and GQRX radio VFO
Users can Fine Tune VFO inside of SDR++ or GQRX for optimal signal
Works with many hardware devices (whatever SDR++ or GQRX support)
Works in Windows Cygwin with SDR++
--(haven't tested the precompiled for compatibility yet)
No need for Virtual Cables / Virtual Sink in SDR++ TCP Link


Cons:
Requires a desktop environment.

 

[kb9mwr]

Cons:
Requires a desktop environment.

Boo.. 90% of my Linux things are command line as thats the true power of the OS in my opinion.

 

[lwvmobile]

Boo.. 90% of my Linux things are command line as thats the true power of the OS in my opinion.

But do you use the rtl input on DSD-FME? To be honest, you could still use rtl_fm seperately and pipe it into DSD-FME if I removed the direct support for it.

 

[Cretu]

I was planning to use the DSD-FME with a RTL on a Raspberry on the oncoming days, but to be honest, I think that this new feature sounds better than manually inputting the frequency on the DSD-FME and adjusting the PPM and all the stuff. However, the Virtual Sink thing is pretty easy to setup with Pulse Audio (much more than Windows Virtual Cables). It's so easy that setting the TCP may even be more dificult buy hey, this thing doesn't sound bad at all!, specially if you want to have the RX machine in a different location than the DSD-FME player. So, I would go for it!

Two questions, If I may: (1) Can't the old RTL control really coexist with the new RIGCTL/TCPAudioLink? (2) Is there any chance we could extend the usage of this to SDR#? Whatever we like it or not, it's a very extended piece of software and, even after all the artificial limitations it has, it's a good software.

 

[lwvmobile]

Can't the old RTL control really coexist with the new RIGCTL/TCPAudioLink?

It could, I've just not been overly happy with the rtl_fm implementation after using it for quite a while. The only perk to using it is the built in UDP tuner I copied into it so you can retune it. Its also finicky with squelch and kind of cumbersome to code. Also, as I mentioned before, it would be just as usable, albeit without the UDP remote, to use rtl_fm and pipe its output into dsd-fme with the stdin and have more options for rtl_fm to fine tune signal and so on.

(2) Is there any chance we could extend the usage of this to SDR#?

If there is some plugin I don't know about, or a community version of SDR# I should look at that has either RIGCTL TCP Link for remote controlling the VFO of SDR#, or more importantly, the ability to TCP Link to an audio sink and receive audio that way, then please let me know what plugin I should use and all that. I tried the DSD+ tcp plugin, and it seems hard wired to work to DSD+.



In other words, how do you do this with SDR#?

 

[Cretu]

I understand the SDR# issue, and that is what I was talking about when I said "artificial limitations"... I had negative experiences in the past with the DSD+ TCP Plugin using anything that is not bundle with it. Even a FastLane version. So yes, perhaps we should forget about SDR#?

About the integrated RTL support of the DSD-FME, well, I don't know the exact implications and only you do, because you are the master here. I simply said that if I could only have one, would lovely change the built-in RTL control for the SDR++ thing, but if, and only if, both things will not collide, why remove the already integrated RTL support? Yea, I know it's far from perfect, but sometimes you don't need a big hammer for small things. As I said earlier, imagine putting a Raspberry Pi 2 (yes! they have enought power, and we have to bring them back to life since new ones are extremely expensive and/or hard to find) with the DSD-FME managing a RTL to monitor a frequency with the help of no other program. That's a marvel!

But in the end, the decision is yours. You asked and this is my humble opinion: having both things would be great, but if not, I would remove the old RTL-FM implementation go for the SDR++ support.

 

[kb9mwr]

But do you use the rtl input on DSD-FME? To be honest, you could still use rtl_fm seperately and pipe it into DSD-FME if I removed the direct support for it.

That would be fine.

 

[Bote]

I understand the SDR# issue, and that is what I was talking about when I said "artificial limitations"... I had negative experiences in the past with the DSD+ TCP Plugin using anything that is not bundle with it. Even a FastLane version. So yes, perhaps we should forget about SDR#?

Ignorant bystander butting in here: SDRsharp is just a better receiver, at least with the AirSpy R2 dongle.

My experience switching from SDRconsole to SDR# a few years ago, keeping everything else the same, was that SDR# could suddenly hear signals that SDRconsole didn't even know were there. Of course, SDR# is optimized for the AirSpy dongles so I don't know if this benefits the cheapie RTR-SDR dongles. But I do know that prog and his bunch are about a bazillion times smarter with this stuff than I am and the results speak for themselves, so I trust them.

This experience was listening to narrowband analog FM 160MHz railroad traffic, but there is a good bit of NXDN on high band in addition to other bands so I would expect similar results in digital modes. You can't decode it if you can't hear it.

So I would find a way to work with SDR# if at all possible. My 2 cents worth.

 

[ki4hyf]

So...

Would anybody miss the RTL (rtl_fm) dongle input support if I removed it entirely and replaced it with RIGCTL and TCP Link Audio from SDR++?

Yes, and no. Right now, I'm very happy with it as is. However, I can keep the old version and have two versions. My RTL devices won't produce enough "inlvl" to reliably decode it's raw output when piping stdin. I may be missing something, but I have to use sox/(a)play/ffmpeg to increase the input level. Not a big deal, but the command line is pretty long and clunky. Also, I haven't gotten NCurses to work with the RTL pipe. I feel sure I'm missing something. Here is my pipe command:
rtl_fm -f144.125M -s48k - | ffmpeg -hide_banner -loglevel warning -f s16le -ar 48k -ac 1 -i pipe: -af volume=5 -f s16le pipe: | dsd-fme -i- -fr -mg

 

[lwvmobile]

As I said earlier, imagine putting a Raspberry Pi 2 (yes! they have enought power, and we have to bring them back to life since new ones are extremely expensive and/or hard to find) with the DSD-FME managing a RTL to monitor a frequency with the help of no other program. That's a marvel!

You know, this is something that just occurred to me, but I am thinking that whichever implementation of rtl_fm that is apart of the RPi repos, or debian repo, or whatever, not sure which, has the UDP remote functionality built into it. The more I consider it, the more I am convinced to leave the rtl_fm support baked in, but some of the CLI options may end up changing in the future, that remains to be seen. I'd like to repurpose -L, -G, -T, and -P for other features and probably will need to re-arrange them.

Yes, and no. Right now, I'm very happy with it as is. However, I can keep the old version and have two versions. My RTL devices won't produce enough "inlvl" to reliably decode it's raw output when piping stdin. I may be missing something, but I have to use sox/(a)play/ffmpeg to increase the input level. Not a big deal, but the command line is pretty long and clunky. Also, I haven't gotten NCurses to work with the RTL pipe. I feel sure I'm missing something. Here is my pipe command:
rtl_fm -f144.125M -s48k - | ffmpeg -hide_banner -loglevel warning -f s16le -ar 48k -ac 1 -i pipe: -af volume=5 -f s16le pipe: | dsd-fme -i- -fr -mg

Yeah, that's something I hadn't considered, I don't know how reliable rtl_fm is by itself of using a sample rate low enough for things like NXDN and so on, I seem to recall that was always kind of finicky, and to do similar in the baked in rtl_fm, I had to do some tom foolery with decimation and interpolation of the sample to get it to push samples based on a desired bandwidth.

Again though, this just reminds me how difficult it can be to set rtl_fm parameters for reliable decoding. A lot of times, if you don't get it right, you really have no idea exactly what is wrong, other than you either get absolutely no decoding, or bad decoding. The visualizations and tweaks afforded by something like SDR++ definitely helps out things, but comes at the cost of needing a desktop environment and more resources to drive it.

Also, one reason I want to move away from using the STDIN, wgetch inside of ncurses will intercept the stdin input as keyboard commands and prevent decoding, so it has to be disabled with using the input pipe. So, when you use ncurses terminal with stdin, you have absolutely no menu capabilities.

 

[ki4hyf]

Yeah, that's something I hadn't considered, I don't know how reliable rtl_fm is by itself of using a sample rate low enough for things like NXDN and so on, I seem to recall that was always kind of finicky, and to do similar in the baked in rtl_fm, I had to do some tom foolery with decimation and interpolation of the sample to get it to push samples based on a desired bandwidth.

I use the -V argument to help boost low levels, and it works as expected, my only wish is a little more fine tuning, but it's no big deal at all to me.

Again though, this just reminds me how difficult it can be to set rtl_fm parameters for reliable decoding. A lot of times, if you don't get it right, you really have no idea exactly what is wrong, other than you either get absolutely no decoding, or bad decoding. The visualizations and tweaks afforded by something like SDR++ definitely helps out things, but comes at the cost of needing a desktop environment and more resources to drive it.

Unfortunately, it's the "'ol catch-22"... Damned if you do, and damned if you don't.

Also, one reason I want to move away from using the STDIN, wgetch inside of ncurses will intercept the stdin input as keyboard commands and prevent decoding, so it has to be disabled with using the input pipe. So, when you use ncurses terminal with stdin, you have absolutely no menu capabilities.

I've come to love the ncurses menu. With very few exceptions, DSD-FME is my go-to program to decode digital radio.

 

[bobruzzo]

I sure could use some help getting this to work but I am utterly confused. I have a DSD folder containing installations of "ITPP 4.3.1" and "mbelib" and I think those are working ok. I tried to install DSD but get this error, in the pic below. So I was probably mixed up doing different installations and failing. I kept getting "cant open /dev/audio" error and I read on Github that /dev/audio wouldnt work with certain kernels or something beyond my understanding. But its at the point where I would need step by step instructions because there are some things I dont understand

 

[lwvmobile]

I sure could use some help getting this to work but I am utterly confused. I have a DSD folder containing installations of "ITPP 4.3.1" and "mbelib" and I think those are working ok. I tried to install DSD but get this error, in the pic below. So I was probably mixed up doing different installations and failing.

Looks like you missed a few dependencies to install, namely ncurses, you may have also missed the nifty automatic install script. I'd delete the current dsd-fme folder you have, and run the installer script by copying, pasting, and running these commands into the terminal, one at a time.

wget https://raw.githubusercontent.com/lwvmobile/dsd-fme/pulseaudio/download-and-install.sh
chmod +x download-and-install.sh
./download-and-install.sh

I kept getting "cant open /dev/audio" error and I read on Github that /dev/audio wouldnt work with certain kernels or something beyond my understanding.

The version in the repository doesn't work because OSS audio hasn't been supported in Linux in like 10 years or something like that, and the port audio code is kind of broken as well. That's why I made the pulse audio branch, to fix the audio.

When you get it installed, you will want to run the virtualsink.sh script and launch dsd-fme it with the command

`dsd-fme -N 2> log.ans`

and open your pulse audio volume control and route audio in and out. Here is a video where I kind of show how to route the audio when you have it up and running. Just pretend the media player is the same as GQRX, you'll be routing the audio the same way, just put the audio into the virtual sink and have dsd-fme listen to the virtual sink.