DSD FME

[m1064]

git checkout remotes/origin/pulseaudio
git checkout -b pulseaudio
git branch -a #double check to see if you are on pulseaudio branch
I want to try pulseaudio and this branch was dead.

 

[ki4hyf]

git checkout remotes/origin/pulseaudio
git checkout -b pulseaudio
git branch -a #double check to see if you are on pulseaudio branch
I want to try pulseaudio and this branch was dead.

Pulseaudio is the default output in the latest branch.

 

[RobDLG]

I am able to report that Digital Speech Decoder: Florida Man Edition works on Fedora 40!

I can now also report that DSD-FME builds and runs on Red Hat Enterprise Linux 9.4, though the base repositories must be supplemented with EPEL, and support for SDR hardware can be an issue.

Initially, I didn't even consider RHEL 9 as a host OS, because the kernel doesn't include the modules corresponding to the RTL-SDR Blog V4 device I was using. Despite this, an older version of the rtl-sdr package is available in the EPEL 9 repository. I found this puzzling, but installed it anyway, and found that rtl_eeprom could read the device, but rtl_test showed nothing but errors.

It turns out that building and installing the newer version of rtl-sdr from Fedora 40 enables the RTL-SDR Blog V4 dongle to work under RHEL 9, despite the missing kernel support.

There are other kernel options for Enterprise Linux, of course, such as ELRepo. Also, Oracle Linux 9 offers two kernels, "UEKR7" and "MODRHCK" that include support for SDR hardware. Anyone wanting to run an Enterprise OS might want to replace the stock kernel.

 

[CLN-RADIOAFICION]

Hello, could you help me with a command? I'm not sure if I'm doing it right since I'm still getting my voice a little bad. I am decoding NXDN48 I have the encryption key, I receive the voice well and clear for a few seconds and then again it is heard a little distorted and it is not possible to hear. The command I use is: dsd-fme -i /dev/dsp -fi-mc -R 16871 -4

I don't know if there is a command that helps me better.

The same in the data that the program throws, I see that many times the RAN is incorrect, I don't know if there is a way to configure those digits myself so that they do not vary?

 

[ki4hyf]

Hello, could you help me with a command? I'm not sure if I'm doing it right since I'm still getting my voice a little bad. I am decoding NXDN48 I have the encryption key, I receive the voice well and clear for a few seconds and then again it is heard a little distorted and it is not possible to hear.

Sounds like you have a marginal signal. NXDN is much more finicky than most of the other common protocols.

The command I use is: dsd-fme -i /dev/dsp -fi-mc -R 16871 -4 I don't know if there is a command that helps me better.

Is there any reason to use "/dev/dsp"? Seems weird to me on a modern distro. Also, -mc is the default. And I don't know what benefit the -4 will have in this case. I would try:

dsd-fme -f1 -R 16871 -4

Another thing, if you are using SDR++, you want to set it up to use tcp audio directly, like:

dsd-fme -f1 -i tcp:127.0.0.1:7355 -R 16871 -4

Be sure to read "Example_Usage.md" in the "examples" directory.

The same in the data that the program throws, I see that many times the RAN is incorrect, I don't know if there is a way to configure those digits myself so that they do not vary?

That definitely sounds like a poor signal.

 

[iscottybotty]

I have some DMR samples taken from SDR# Studio V1.0.01919, using DSDPlus to record.

The samples will NOT play via FME however, they will play through DSDPlus. I’ve tested other samples on FME and they are fine.

What could be the issue here, why are they playing on DSDPlus but not FME?

Seems weird. Anyone?

 

[ki4hyf]

I have some DMR samples taken from SDR# Studio V1.0.01919, using DSDPlus to record.

The samples will NOT play via FME however, they will play through DSDPlus. I’ve tested other samples on FME and they are fine.

What could be the issue here, why are they playing on DSDPlus but not FME?

Seems weird. Anyone?

How are you importing into FME? I've had good luck importing funky DSD+ wav files using VLC. I assume you're using the command line argument:

-i filename.wav -s 96000

Another note, it's my experience that DSD+ wav files play better when FME is in NCurses mode.

 

[CLN-RADIOAFICION]

Hola, encontré unas frecuencias que DSD-FME me muestra como Cap+, me arroja Group Call y sus datos, no siempre logra decodificar correctamente a pesar que no aparezcan como encriptadas, saben qué sistema es? Si con algún comando podría mejorar la decodificacion

 

[ki4hyf]

Hello, I found some frequencies that DSD-FME shows me as Cap+, it shows me Group Call and its data, it does not always decode correctly even though they do not appear as encrypted, do you know what system it is? If with some command I could improve the decoding.

Is there any way you could provide a sample? I think the best way is to add this to your existing command line.

 -6 <filename.wav>

 

[lwvmobile]

Alright guys, sorry I haven't been on lately. I've stayed logged out for a bit and had most all email notifications disabled and I'll get around to addressing that. Also, if anybody needed help and you got missed, sorry about that as well, just wanted some time off mentally from the usual.

Anyways, while I was away, what I've come to realize is that my interests in DSD-FME and radio things has waned quite a bit, and I find my interest levels not really up there like they once were. I think spending a lot of my free time on coding and decoding of radio stuff has kind of led me to being severely burned out to the point I don't really even look at code for DSD-FME anymore, or have any desire to work on it, and have been skirting a bit on replying to messages and help to use requests. Truth is, I'm just a bit burned out and have realized that I'd like to spend my free time doing other things. I've also realized, that I think I've taken the original DSD source code as far as I can take it in its current form, and just jamming more and more things into it isn't going to help much or 'make it better' at this point.

So, just wanted to post this publicly, so others can all know at the same time what I've decided to do and how I'm going to proceed form here. This is the important part:

I will no longer be writing any new code or doing any new features for DSD-FME. That includes taking new feature request. Not going to do any.

I will help on a limited basis with the use of DSD-FME in its current form, the most up-to-date version out there, so nobody ask me about ancient versions of the code. Honestly, on some of the miscellaneous messages I've received lately asking for source code to older versions, I honestly don't have that code nor do I really even remember what feature they may have done that the newer code doesn't. If its not on Github, or something you can roll back to with 'git checkout' command, then I don't have it for you.

If somebody identifies a minor bug in DSD-FME, it will most likely not be fixed by me. I classify a minor bug as anything that is not overly consequential to decoding, trunking, etc.

I may address more major bugs, if it is easily reproducible, it cannot be mitigated by doing something differently, and it has a major consequence, such as a crash. Decoding errors are not major bugs in this regard.

I'm not going to reply to any more questions regarding encryption/decryption etc. Let's face it, that's the majority of my inbox on here, so, if I don't reply, sorry. Nothing personal to anybody, just kind of tired of the same questions over and over.

Again, just want to reiterate before I get asked, everything with me is fine, its been a lot better when I realized I didn't have to be here to reply to everything all the time, and I've come to accept that I can't help everybody with every problem or feature or use case thing they ask me. If I don't reply for long periods of time, its not because anything bad has happened to me, its just because I am either not seeing the message, or because I can't tell you anything new that isn't already posted on here somewhere else, or in the example usage in the docs, or that another user can't help with. Thanks to the few people on here who have been helping while I've been away. Again, I should let you all know, my notifications are off on here, as much as I can turn them off, so I don't feel the urge to just have to immediately jump and answer asap. Its been quite refreshing and de-stressing to not be super engaged on here. Let's be honest, a lot of people on any forum/social media could benefit from just turning it all off for an extended period of time.

So, just wanted to let you all know that's where I am currently at with DSD-FME, radio related things, and the forum here in general. I'll be around from time to time if I see something that I can provide help on for using DSD-FME, but I may not reply to personal messages often or at all, depending on what its about, and I don't get notifications as far as the website here will let me not get them, so just FYI in case anybody wonders why I don't reply or am slow or virtual non-existent to reply.

 

[Unitrunker2]

@lwvmobile This does not in any way diminish your contributions to the hobby. Thanks for all you've done.

 

[iscottybotty]

To DSD-FME,

Thank you. Thank you for everything you’ve done on this program, and to all those that have contributed. What you have created is amazing, and more popular than the paid for version, DSDPlus. That really does say something.

I can appreciate the “burn out”, and as you say, as a sufferer of cPTSD myself, your mental health and well being are far more important than coding. The support you have given on here is more than we could have ever asked for and I for one, would like to personally thank you, for everything. It was a pleasure to assist you in the early days of FME and I’m honoured to have been part of your team.

I, and I know many members feel the same, so we thank you, we wish you well and good health and who knows, perhaps one day our paths may cross once more.

It’s been an absolute pleasure, DSD-FME, and I wish you all the best for your next endeavour, whatever that might be.

Thank you, Scott.

 

[doriboni]

Thank you @lwvmobile for all your work, which is great. Just a question when you come back.

Do you always fix bugs or not at all? I'm talking about the bug of the bad random decoding of the 49th bit of the AMBE frames. Someone told me here that the 49th bit is useless but it's wrong, it impacts the decoding of the MI in late entry. When this bug occurs, there are 2 wrong bits in the MI decoding (This is corrected by the Golay code, but if there are other bits that are wrong by the reception then the decoding no longer works). I won't explain the bug further because it's useless if you decide not to fix it.

If you decide not to fix the bug then too bad and thank you again for all your work.

 

[CanesFan95]

I'm trying out the Windows version and have a quick question, if you guys don't mind. How do we tune the SDR receiver? I don't seem to find that in the program.

 

[ki4hyf]

How do we tune the SDR receiver? I don't seem to find that in the program.

If you are talking about an external program such as SDR++ or SDR#, then that should be asked in a different thread. If you are talking about the way DSD-FME uses RTL-SDR directly, then this is from the help file:

RTL-SDR options:
 Usage: rtl:dev:freq:gain:ppm:bw:sq:vol
  NOTE: all arguments after rtl are optional now for trunking, but user configuration is recommended
  dev  <num>    RTL-SDR Device Index Number or 8 Digit Serial Number, no strings! (default 0)
  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)(4, 6, 8, 12, 16, 24)  
  sq   <num>    RTL-SDR Squelch Level vs RMS Value (Optional)
  vol  <num>    RTL-SDR Sample 'Volume' Multiplier (default = 2)(1,2,3)
 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:2

 

[lwvmobile]

Do you always fix bugs or not at all? I'm talking about the bug of the bad random decoding of the 49th bit of the AMBE frames. Someone told me here that the 49th bit is useless but it's wrong, it impacts the decoding of the MI in late entry. When this bug occurs, there are 2 wrong bits in the MI decoding (This is corrected by the Golay code, but if there are other bits that are wrong by the reception then the decoding no longer works). I won't explain the bug further because it's useless if you decide not to fix it.

It was purely a display bug where the last packed octet was printed but not collected properly, thus the random value in it. I honestly hadn't noticed because I never bother looking at that bit. Regardless, the bug has been fixed, its been pushed to the aw_dev branch for now pending further testing. Further testing by somebody else, won't be me.

The bug only affected the printed AMBE value, it didn't affect the bit array ambe_d, where the 49-bit decoded voice frame is usually held, nor did it in any way impact the late entry MI/IV value held by the ambe frame, that MI extraction process is carried out separately from the mbe voice portion, and has both Golay applied to it and a CRC check.

If you are getting late entry errors often, then it means that for one thing, you aren't getting the initial link control headers nor the PI header, and it probably means that you are also having tons of reception errors if it is often bad or having to assert itself over the current internal LFSR generated MI/IV value. If you are getting tons of decode errors, then you should look at either cleaning up your signal into DSD-FME, or there is some interference on that channel, or the signal is just too weak, or maybe even too strong if its nearby to you.

Another thing to keep in mind is that if that system is also TXI enabled, the late entry key/alg has to compete for time with the TXI information, so its possible that on super short talk spurts with TXI enabled, and encryption enabled, if you miss the PI header, or have bad signal, it may have to wait multiple superframes, and by that time, the call could very well be over. Using the -0 and/or -3 option may be required to both disable the late entry alg/key and also force it to attempt RC4 decryption at all times, but it can only use one key value if you go that route, no key loading.

 

[lwvmobile]

I want to try pulseaudio and this branch was dead.

I would suggest just using the latest build, it can be found here, I would advise reading the front page and following up with the cloning and installing link since those will have the most up to date info.

If you really REALLY want to try the 'pulse_audio' branch from two years ago or however long it was, you can revert the code back to that time by finding the appropriate commit in the commit history and running git checkout a0d9e349c2406d60762c403d689e53b34e2c656a after cloning the current branch. Just letting you know, though, if that's what you want, that's all the help your going to get on going back that far.

 

[lwvmobile]

Hello, could you help me with a command? I'm not sure if I'm doing it right since I'm still getting my voice a little bad. I am decoding NXDN48 I have the encryption key, I receive the voice well and clear for a few seconds and then again it is heard a little distorted and it is not possible to hear. The command I use is: dsd-fme -i /dev/dsp -fi-mc -R 16871 -4

Use squelch in whatever software you are using, SDR#, SDR++, or internal RTL input to prevent the garbage decodes.

 

[CanesFan95]

Is there a way to save that help file as a .txt? This doesn't work:

dsd-fme.exe -h >Help.txt

 

[RMason]

Is there a way to save that help file as a .txt? This doesn't work:
dsd-fme.exe -h >Help.txt

The help information may be being written to stdout.
Try:

dsd-fme.exe -h 1> Help.txt 2>&1​

​

*** Note: I did not try this myself....