DSD FME

[radioopperator]

Here's a list of the more common types (in the US):

DMR ALGIDs:
01    Anytone RC4
21    Motorola EP/RC4
22    DES
24    AES-128
25    AES-256

P25 ALGIDs:
80    Unencrypted
81    DES
83    Triple DES, 168 bit key
84    AES - 256
85    AES - 128
9F    DES-XL
A0    DVI-XL
A1    DVP-XL
AA    ADP(RC4)

Is there any more info on this? I'm using DSD-Plus and seeing stuff like: ALGID=A2 ALGID=23 ALG=8A Is this really valid?

 

[Ubbe]

Is this really valid?

In the Audio Decode part of the window and for Voice Error you should see [0][0] to be able to trust the result. If you see a 1 or 2 then it will begin to false decode the data information.

/Ubbe

 

[gary123]

Ubbe is correct. If the signal is marginal or noisy then it is common for the ALGID to get messed up. If you monitor for a while you will often get the correct ALGID and matching KIDs.

 

[iscottybotty]

MESSAGE FOR JIM HAMPTON.

Jim, if your on here, could you drop me a quick DM. Thanks.

 

[uv5eld]

Okay, its DMR Simplex. Guess I never tested that type before when making raw wav files. I just went and tested that functionality, and it doesn't work for me either. I think what is happening is that samples are being dropped and not properly writen to the wav file due to the absence of the other slot, as it were. I'll have to take a look at the code at some point, and see if anything can be done to fix it.

In the meantime, if you need a capture to playback later on in DSD-FME, just use the -c capture.bin symbol capture method instead, those work properly when played back using dsd-fme -i capture.bin

Hello. Could you please clarify? I tried to reread the thread, but I might have missed some posts. Was it possible to solve this problem? Maybe it has been discussed somewhere else and there are solutions?

 

[lwvmobile]

Hello. Could you please clarify? I tried to reread the thread, but I might have missed some posts. Was it possible to solve this problem? Maybe it has been discussed somewhere else and there are solutions?

That was in regards to an issue that was fixed two years ago where raw audio wasn't being properly written to a raw audio wav file in dsd-fme.

 

[radioopperator]

Well is Motorola about to stop us cold watching P25 P I heard they are about to release an update that encrypts the data channel! Since they don't do much for free, I hope many users wont PAY for this upgrade? As they encrypt the radio audio and the computers and half the radio traffic is going over IP what would be the need to encrypt the data channels except to end scanner users and SDR users. Many agencies use scanners / unification so they don't have to buy radios that just monitor but those days may be comming to an end fast?

 

[Ubbe]

As they encrypt the radio audio and the computers and half the radio traffic is going over IP what would be the need to encrypt the data channels except to end scanner users and SDR users.

In most cases encryption are to protect the system from unauthorized radios to interfere with communications that could generate false information. It then needs the data signalling to be encrypted as voice encryption only stops any eavesdropping.

The Swedish police used an analog system 25 years ago that used CCIR sequential tone signalling and at a world leader convention in Sweden there where some people that had different opinions and made their voices heard in the streets. They had a radio central coordinating demonstrators and also had radios that had the same type of signalling that the police used and sent out alarm calls that made the system to connect all audio together from 10 channels that created havoc. One police channel could be assigned to handle demonstrators at one location and another channel for a demonstration at another location and a third channel fo security at the building and so on and it became impossible to use the radio system until the alarm call where cleared down. This to try and stop the police to interfere too much with demonstrators.

Shortly after that the decision where made to buy a fully encrypted digital system, Tetra, and since then its been impossible to listen to and more difficult to interfere with police communications.

/Ubbe

 

[saioke]

Well is Motorola about to stop us cold watching P25 P I heard they are about to release an update that encrypts the data channel! Since they don't do much for free, I hope many users wont PAY for this upgrade? As they encrypt the radio audio and the computers and half the radio traffic is going over IP what would be the need to encrypt the data channels except to end scanner users and SDR users. Many agencies use scanners / unification so they don't have to buy radios that just monitor but those days may be comming to an end fast?

Where did you hear that at? I'm calling BS honestly. Just doesn't seem like it would make any sense to encrypt the control channel of a P25 system when every radio supports encryption out of the box. What would be the point in wasting resources to do such a thing when their own radios can prevent anyone from listening in?

 

[gary123]

Many P25P2 systems are no longer transmitting a band plan. This in itself is enough to slow down a vast majority of scanner users. The ability to encrypt the CC has been available for a long time. Saioke has a valid point with lots of systems being 100% ENC there is nothing to be gained by encrypting the CC.

For now I put this in the "the sky is falling category" if it happens then there is nothing that can be done at the present. I am not going to get into a big panic over something that is possible. My suggestion is everyone just wait it out and see. Until then support the hobby where you can.

 

[AK9R]

Saioke has a valid point with lots of systems being 100% ENC there is nothing to be gained by encrypting the CC.

If you believe in "security by obscurity", then encrypting the control channel might make some sense. If unauthorized users cannot track which talkgroups are being used or which units use which talkgroups, then it might be more difficult to build a picture of how the agency responds.

 

[radioopperator]

In most cases encryption are to protect the system from unauthorized radios to interfere with communications that could generate false information. It then needs the data signalling to be encrypted as voice encryption only stops any eavesdropping.

The Swedish police used an analog system 25 years ago that used CCIR sequential tone signalling and at a world leader convention in Sweden there where some people that had different opinions and made their voices heard in the streets. They had a radio central coordinating demonstrators and also had radios that had the same type of signalling that the police used and sent out alarm calls that made the system to connect all audio together from 10 channels that created havoc. One police channel could be assigned to handle demonstrators at one location and another channel for a demonstration at another location and a third channel fo security at the building and so on and it became impossible to use the radio system until the alarm call where cleared down. This to try and stop the police to interfere too much with demonstrators.

Shortly after that the decision where made to buy a fully encrypted digital system, Tetra, and since then its been impossible to listen to and more difficult to interfere with police communications.

/Ubbe

EXCEPT for the fact that MOTOROLA made what is called the electric fence. It would look for to identical radio id's affiliated in the system at the same time! And it was expensive so NO ONE PAID for it. And only a stupid radio manager turns on all the unused radio id's. And yes I know some countys that did that.

 

[MELERIX]

btw, why in DSD-FME 2024 the tail console displays some elements with different texts colors when using -Z but in DSD-FME 2025 the tail console only displays all elements texts in white color.

 

[lwvmobile]

btw, why in DSD-FME 2024 the tail console displays some elements with different text colors when using -Z but in DSD-FME 2025 the tail console only displays all elements on white text color.

When I compiled the 2025 version, I did so with the -DCOLORSLOGS=OFF cmake option. I often get logs and whatnot, its easier to parse them when the log files themselves aren't full of ANSI color characters. In other words, personal preference. If you compile it yourself, however, the default is for color logs, if you prefer those.

 

[MELERIX]

When I compiled the 2025 version, I did so with the -DCOLORSLOGS=OFF cmake option. I often get logs and whatnot, its easier to parse them when the log files themselves aren't full of ANSI color characters. In other words, personal preference. If you compile it yourself, however, the default is for color logs, if you prefer those.

maybe you can add a command line to allow colors? something like --show-colors

btw, with P25 Phase 1 and RTL-SDR V4 testing this commands...

with SDR++ (with PPM -4 to center CC control frequency 868.8375) it works fine and DSD-FME automatically changes to the voices channel/frequency and decoding with the keys file perfectly and with good audio output

.\dsd-fme\dsd-fme.exe -i tcp -U 4532 -T -N -Z -K multi_key_hex.csv  2> log.ans

but, if I try to use this command to use RTL-SDR V4 directly, DSD-FME does not changes to the voices channel/frequency automatically, it only stuck in a single frequency and without audio output neither decoding with keys file

.\dsd-fme\dsd-fme.exe -f1 -i rtl:0:868.8375M:20:-4:12:0:2 -T -mq -N -K multi_key_hex.csv 2> log.ans

what could be wrong?

 

[lwvmobile]

but, if I try to use this command to use RTL-SDR V4 directly, DSD-FME does not changes to the voices channel/frequency automatically, it only stuck in a single frequency and without audio output neither decoding with keys file

Going by the first command and the second one you posted, you have it hard set for phase 1, which don't know if that system you are listening to is phase 1 or phase 2 audio. So, you might try tweaking it to this instead.

.\dsd-fme\dsd-fme.exe -ft -i rtl:0:868.8375M:0:-4:12:0:2 -T -N -K multi_key_hex.csv 2> log.ans

 

[MELERIX]

Going by the first command and the second one you posted, you have it hard set for phase 1, which don't know if that system you are listening to is phase 1 or phase 2 audio.

the system I'm listening is phase 1.

So, you might try tweaking it to this instead.

.\dsd-fme\dsd-fme.exe -ft -i rtl:0:868.8375M:0:-4:12:0:2 -T -N -K multi_key_hex.csv 2> log.ans

I've tested that exact command, but the issue persist, after few seconds the main DSD-FME window stucks in a single frequency and no audio output neither decoding with keys file, but the log console keeps rotating between different frequencies.

 

[lwvmobile]

How's the signal strength when using SDR++, great, good, bad, marginal, or any sort of co-channel interference? If its not great, then the internal RTL input isn't nearly as good as what you can usually accomplish when pairing it with SDR++, since they have a much better DSP.

Only other considerations I can think of is to double check the current control channel frequency, PPM, all that stuff.

 

[MELERIX]

the signal is perfect because the repeater and the voice channel/frequencies are near here jaja, so with SDR++ command in TCP mode it works fine, is only with the direct RTL command that does not work :/

 

[lwvmobile]

the signal is perfect because the repeater and the voice channel/frequencies are near here jaja, so with SDR++ command in TCP mode it works fine, is only with the direct RTL command that does not work :/

Any other obvious error related messages in the console log when starting up? Is the RTL dongle being opened successfully, as in, you're not trying to run the rtl input when SDR++ is actively running, or anything like that?