DSD FME

[leoaln]

This is what I have, currently. The frequency in SDR++ doesn't change from the control channel frequency. No T designation on the active channel in dsd-fme

 

[leoaln]

screenshot

 

[lwvmobile]

Your channel map isn't loaded, note all the zeroes for the LCNs. Not sure if you specified the correct file location, or if the csv file is properly formatted or not.

Also, if you need more room in the ncurses terminal, you can hit the 'c' key and the 'h' key to disable the banner and the history, and just show the LCN tree.

 

[613scanner]

Also, figured I'd ask, are you trying to use DSD-FME with a Raspberry Pi for the EDACS decode?

semi related question. My friend will be gifting me a raspberry pi zero W ( not a 2 model ) soon. Have you tested DSD-FME on something that low spec? all I want to do is monitor one DMR frequency and save the per call files and I am wondering if I can run DSD-FME on it well enough.

Ideally I want to just run it with a rtl-sdr dongle , but if the pi zero can not handle dongle + dsd-fme I could probably just dedicate a scanner with a discriminator tap to this.

 

[lwvmobile]

semi related question. My friend will be gifting me a raspberry pi zero W ( not a 2 model ) soon. Have you tested DSD-FME on something that low spec? all I want to do is monitor one DMR frequency and save the per call files and I am wondering if I can run DSD-FME on it well enough.

Ideally I want to just run it with a rtl-sdr dongle , but if the pi zero can not handle dongle + dsd-fme I could probably just dedicate a scanner with a discriminator tap to this.

I'm honestly not sure if the W is powerful enough or not. I have one, and I just had to hunt for it, but I found it. If I get a chance, I'll test it and see how the performance is. I think it would be okay if you were only using disc tap input, or connecting to a remote TCP audio sink from SDR++ or something. Using the built-in rtl support will push it to its limit, but it might still be okay. A couple of things to keep in mind though with a Pi, and that is to just use the ncurses terminal and not save the console to a log file (route 2> /dev/null) to minimize thrashing or filling up the sd card, and also, that the W has no built in Ethernet, only Wi-Fi, and no 3.5mm jack, and also only one data micro-b usb port, so you'd need an on-the-go adapter, a powered USB hub (probalby), one dongle, and one USB sound card (if you go the disc tap route).

 

[613scanner]

noted , I do have a usb audio card + otg adapter but I think I will have to hunt down a powered usb hub.

 

[lwvmobile]

noted , I do have a usb audio card + otg adapter but I think I will have to hunt down a powered usb hub.

You may only need the powered USB hub if you plan to use both the rtl dongle and the usb sound device. If you just use one or the other, you may not need it, just depends more on if you want to listen in real time or not, or connect to an HDMI monitor/tv or not. BTW, it also uses a mini hdmi connector, so that's another adapter/cable if you don't already have one.

 

[lwvmobile]

Well, I gave the Zero W a go this morning with the RTL dongle, and I think it'll work. While trunking an EDACS site, it was able to keep up, albeit with the single CPU pegged at 100%, but in a trunking sense, it could still lag, since if it can't keep up, it'll start buffering audio and decode it as it gets to it, but by the time it processes a call grant, the call could already be completed or tuned to late.

For just a single conventional frequency, it should be fine. It'll probably still peg out when it starts decoding, but it should be able to handle it, it may just incur a second or two delay in audio.

While Decoding:


While Waiting for Signal:

 

[613scanner]

Well, I gave the Zero W a go this morning with the RTL dongle, and I think it'll work. While trunking an EDACS site, it was able to keep up, albeit with the single CPU pegged at 100%, but in a trunking sense, it could still lag, since if it can't keep up, it'll start buffering audio and decode it as it gets to it, but by the time it processes a call grant, the call could already be completed or tuned to late.

For just a single conventional frequency, it should be fine. It'll probably still peg out when it starts decoding, but it should be able to handle it, it may just incur a second or two delay in audio.

While Decoding:
View attachment 147122

While Waiting for Signal:
View attachment 147123

Out of curiocity did you just use raspberry OS with the GUI? I was thinking I could lower the overhead by forgoing the GUI . I am thinking that I could just set this up as a audio stream on my LAN and listen via VLC.

 

[lwvmobile]

Out of curiocity did you just use raspberry OS with the GUI? I was thinking I could lower the overhead by forgoing the GUI . I am thinking that I could just set this up as a audio stream on my LAN and listen via VLC.

I was using the latest Rasberry Pi OS Lite, so no GUI, just over SSH, completely headless.

Speaking of UDP, I've mean meaning to add a method to blast audio via UDP, I had just completely forgotten about it until you mentioned it.

 

[LimaZulu]

I am monitoring small NXDN 48 system with 4 talk groups but when there is a lot of traffic I used to miss some calls. So I decided to do 4 separate group files where only one group is allowed and all others are blocked then I ran 4 instances of DSD-FME each pointed to a different group file. To do so I use SDR++ with 4 rigctls servers and 4 radios each on a same CC frequency. Now I can listen to each group individually and mute the others that I don't want to hear at the moment. While that works ok, from time to time there is a sync loss causing DSD-FME to scan all site frequencies to find CC again and that is the moment when I see two instances listening to a same talk group where clearly one of them is pointed to a file where this group is blocked. Here is a quick screenshot I managed to get this morning



Anyone tried setup like this and saw some wiredness like this one?

 

[lwvmobile]

If frame sync is lost for long enough on the control channel, and during its rotation to find the control channel again it lands of a voice channel that's active, its going to decode it, whether or not there is a block on the group. The block is only to prevent tuning from the CC to that group's channel, but if it happens to land on that channel while hunting for the control channel, it'll stop there and decode. Best case scenario, it'll mute it for you, but I can't remember if I wrote the mute logic into all decoding types, I can't remember if the block group mute works on NXDN, regardless, it'll still stop there until the channel tears down and the CC hunt resumes.

You might consider using a -t 2 option to extend the hangtime by a second or so, default is one second, that way it doesn't hunt as often, unless the CC itself rotates frequently.

 

[LimaZulu]

Well, maybe some logic to only tune to CC channel when hunting. I bet there is something that can differentiate CC than VC channel and not only looking if there is sync or not.

 

[613scanner]

I have a 15 bit voice scambled nxdn file .wav and the code that allegedly goes to it . what would be the syntax to feed the .wav into dsd-fme with the key and get the resulting .wav with the key applied out? the recording I have is like 15 min of traffic , I just did a narrow fm recording of traffic , would that in theory work?

 

[LimaZulu]

The syntax should be:
dsd-fme -i <name_of_the_file.wav> -N -P -fi -R <key>
If your sample is NXDN96 replace -fi with -fn

 

[613scanner]

The syntax should be:
dsd-fme -i <name_of_the_file.wav> -N -P -fi -R <key>
If your sample is NXDN96 replace -fi with -fn

Thanks this worked great.

 

[hst111]

Hello,
When I using dsd-fme -fi -4 (force Privacy Key over Encryption)
It doesn't work. Can it works with NXDN96?
Or something I should do?
Thanks.

 

[hst111]

It's same as this.
When I press ptt after 3 minutes and it doesn't work.

 

[lwvmobile]

You have to tell it what the key is...

 

[hst111]

You have to tell it what the key is...

I am interested at -4.
How can I use it? With key data?