DSD FME

[lwvmobile]

Okay, I'll try to simplify things here. The -4 option is to enforce the use of a basic privacy key or an NXDN scrambler key when there may be bad signal or any other reason why decoding could fail on the Link Control / VCALL parameters and DSD-FME doesn't know the call is encrypted. It is used as a way to tell DSD-FME to always use a key, whether or not it currently knows if the call is encrypted or not. It always has to be used with a single known key value that you tell it.

For example, if that system you are listening to has a scrambler key of 12345, then you use the command:

dsd-fme -fn -R 12345 -4

and that will force DSD-FME to always apply that key value, and resulting keystream, to every call that comes in, even before it can successfully decode a VCALL from SACCH. Most times, using -4 isn't required, but can be handy in cases of bad/marginal signal, scanning/tuning, or playing back other people's poorly recorded audio samples.

Do not confuse the phrase 'enforce privacy key' for 'brute force privacy key' because it will not, nor will it ever, do that.

 

[lwvmobile]

P.S., Use Squelch on NXDN, it'll keep that random garbage framesync away.

 

[613scanner]

I am trying to setup pluse audio so I can feed dsd-fme from recordings I made in sdrpp via vlc. however I am a bit stuck after googling . Right now I can make a temporary virtual sink but I can not figure out what to do next. Right now I have not made the virtual sink start when the system does so I can revert untill I figure it out. I am pretty much just asking how to properly setup the virtual sink on ubuntu 22.04

I am going this route because when I try to play the recordings from sdrpp in dsd-fme directly they just do not work for nxdn48 well and will just stop producing anything after 10 sec. It is odd behavior that it just ends after a few seconds , says reached end of file , but the .wav is a 8 min recording of only signals that broke the squelch.

 

[lwvmobile]

Play the wav file from VLC (or whatever your media player of choice is) into the virtual sink, and set DSD-FME to listen to the 'monitor of Virtual Sink' in the recording tab in the pulse audio volume mixer.

Should look like this:

 

[lwvmobile]

I am going this route because when I try to play the recordings from sdrpp in dsd-fme directly they just do not work for nxdn48 well and will just stop producing anything after 10 sec. It is odd behavior that it just ends after a few seconds , says reached end of file , but the .wav is a 8 min recording of only signals that broke the squelch.

Also, was your wav file recorded as stereo, or mono, You'll want to uncheck the stereo checkbox in recorder and also use sample type as Int16, and also make sure your radio sink is set up for 48000, that way it'll capture the wav file at that rate.

 

[613scanner]

Play the wav file from VLC (or whatever your media player of choice is) into the virtual sink, and set DSD-FME to listen to the 'monitor of Virtual Sink' in the recording tab in the pulse audio volume mixer.

Should look like this:
View attachment 147414
View attachment 147415

I was forgetting to set it for the virtual sink monitor! , also I did have stereo selected for sdrpp recordings so thanks for the heads up.

 

[LimaZulu]

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

Okay, I'll try to simplify things here. The -4 option is to enforce the use of a basic privacy key or an NXDN scrambler key when there may be bad signal or any other reason why decoding could fail on the Link Control / VCALL parameters and DSD-FME doesn't know the call is encrypted. It is used as a way to tell DSD-FME to always use a key, whether or not it currently knows if the call is encrypted or not. It always has to be used with a single known key value that you tell it.

For example, if that system you are listening to has a scrambler key of 12345, then you use the command:

dsd-fme -fn -R 12345 -4

and that will force DSD-FME to always apply that key value, and resulting keystream, to every call that comes in, even before it can successfully decode a VCALL from SACCH. Most times, using -4 isn't required, but can be handy in cases of bad/marginal signal, scanning/tuning, or playing back other people's poorly recorded audio samples.

Do not confuse the phrase 'enforce privacy key' for 'brute force privacy key' because it will not, nor will it ever, do that.

To back up this I will bring to your attention some visual and audio clarification. I do have an audio sample where it's clearly visible that -4 option DO help when decoding do fail for whatever reason. Here is a waveform of that sample where it's clearly visible where things are going bad when -4 option is not used.



Upper waveform is with -4 and as you can see audio is produced correctly where at the bottom audio seems to disappear.
You can download those two samples from here and observe the above mentioned for yourself. Even if you don't speak the language you can spot where things are messed up: Ufile.io - 1693294582

I personally always use -4 if I know the conversations are always scrambled, just to keep my ass backed up

 

[613scanner]

Note: I am Canadian and can simply buy the aor-dv1 or whatever the model is that can decode the nxdn 15-bit scramble. I am simply providing this as some info to maybe help someone save some time.

I spent about 2 hours making a shell script file that would increment a nxdn scramble key for a instance of dsd-fme. The instance of dsd-fme would output the use of that key on a sample to a file , the source of the nxdn was a looping .wav file that was been played on a virtual sink. I think tried to take output files and feed them on whisperAI using google colab ( because I do not have a GPU nice enough ) on the "large" model. I made output files of scramble codes 1- 5000 for my proof of concept.

My thought was that I could get simply look and see which of the files gave any transcription output and then brute force a few of the possible results. However this did not work as intended and WhisperAI was giving "something" on nearly every file. so while this idea failed one thing to note was that sometimes it would interpret that classic digital noise as repeated words "Bye.Bye.Bye.Bye.Bye" for example. In online examples of brute forcing the scramble it seems to be under 1-2 minutes so I should probably just read more about NXDN scramble and try to think more about how to do it "the proper way". I should probably confirm that nxdn scramble does not use the network time as part of the IV, otherwise I should have never used a recording and just let it sit and wait for live transmissions. I am thinking that maybe the silence frames if they all zeros are just being xor'd with the direct scramble key?
I know very little about lsfr.

If someone is going to use WhisperAI for a similar idea , I noticed that the medium and large models gave "something" for about the same amount of the files tested.

 

[lwvmobile]

If you want to know how the voice descrambler really works, its literally a LFSR (Linear Feedback Shift Register). Here is the code for it. At the start of a SF structure, the LFSR is set to the key value, and tracked through each AMBE frame. Alternatively, you can create an entire key sequence in one go by running this LFSR 18 times and storing the entire key sequence. It'll never change, just needs the SF/PF field from the NXDN frame to know when to reset its period.

//voice descrambler
void LFSRN(char * BufferIn, char * BufferOut, dsd_state * state)
{
  int i;
  int lfsr;
  int pN[49] = {0};
  int bit = 0;

  lfsr = state->payload_miN & 0x7FFF; //The NXDN/dPMR Scrambler Key on SF1 AMBE frame 1

  for (i = 0; i < 49; i++)
  {
    pN[i] = lfsr & 0x1;
    bit = ( (lfsr >> 1) ^ (lfsr >> 0) ) & 1;
    lfsr =  ( (lfsr >> 1 ) | (bit << 14) );
    BufferOut[i] = BufferIn[i] ^ pN[i];
  }

  state->payload_miN = lfsr & 0x7FFF; //store it back for next AMBE frame
}

Visually, this is the Voice Scrambler, directly from the JVC NXDN manuals, which anybody is free to download from their website.


if this seems familiar, its because a lot of things use LFSR functions. Project M17 uses its own version of the Voice Scrambler, just with different taps.



P25 Phase 2 Frames use an LFSR sequence to 'scramble' its frames.



and literally any sort of Initialization Vector are all generated/propogated by an LFSR function. This is from NXDN, but same applies to pretty much any IV I've ever seen.




The only real difference is the location of the taps, the direction of 'circulation', and when to grab the bit (MSB, LSB, before, or after operation).

 

[adsbgreenock]

@lwvmobile Hi there, I was playing about with Dsd-fme with the simple Dsd-fme folder and opening a CMD on windows 10 taking advantage of sdr++ and rig control with the airpsy. Decent results..

I took the plunge and installed the WSL version on Windows 10 Pro and used the automatic install script.
I tried to run the live monitoring bat (and also the other one to be sure)

I get a swift CMD box opening and then closing again just as fast.
I read the readme and tried installing the x64 bit WSL update., rebooted and still the batch file won't run.


I don't know if I'm missing something.

I am really happy with the results on using the former dsd-fme-aero.exe. I'd really like to get this more advanced version with the Virtual Cable running.

Any ideas

Thanks for your work - really appreciated

 

[lwvmobile]

If you ever have a problem with a .bat file and it closing the terminal way to fast, all you have to do is at the very bottom of your bat file, just put the command

PAUSE

and it'll do exactly that, and you should be able to read any output to see what went wrong.

As far as running the WSL version you compiled, I suspect its because you may be trying to use that bat file to execute it, which isn't going to work I don't believe. You'll probably just want to open your WSL Terminal and type the command directly into it. Again, this is territory I am not directly familiar with as I don't use Windows or WSL. You might can find a little extra help here about it, but I didn't write this stuff, another user wrote it back last year, so take it for what its worth.

Depending on which version of 'dsd-fme-aero.exe' you are using, you may be a bit out of date, or quite a bit out of date. I stopped using that naming scheme a while back, so the latest version is as of 20230901 precompiled, which is on par with the v2.1b branch, and there is also a dsd-fme-aw.exe which is a precompile of the more experimental 'audio_work' branch available in the 20230901 release.

Release DSD-FME (20230901) · lwvmobile/dsd-fme

Updates Include: General Tweaks/Improvements/Cleanup/Fixes to Code; AMBE Tones, New Raw Signal Audio Monitor; EDACS Analog Call support; The main precompiled binaries are from the v2.1b branch. Als...

github.com

 

[613scanner]

If you want to know how the voice descrambler really works, its literally a LFSR (Linear Feedback Shift Register). Here is the code for it. At the start of a SF structure, the LFSR is set to the key value, and tracked through each AMBE frame. Alternatively, you can create an entire key sequence in one go by running this LFSR 18 times and storing the entire key sequence. It'll never change, just needs the SF/PF field from the NXDN frame to know when to reset its period.

//voice descrambler
void LFSRN(char * BufferIn, char * BufferOut, dsd_state * state)
{
  int i;
  int lfsr;
  int pN[49] = {0};
  int bit = 0;

  lfsr = state->payload_miN & 0x7FFF; //The NXDN/dPMR Scrambler Key on SF1 AMBE frame 1

  for (i = 0; i < 49; i++)
  {
    pN[i] = lfsr & 0x1;
    bit = ( (lfsr >> 1) ^ (lfsr >> 0) ) & 1;
    lfsr =  ( (lfsr >> 1 ) | (bit << 14) );
    BufferOut[i] = BufferIn[i] ^ pN[i];
  }

  state->payload_miN = lfsr & 0x7FFF; //store it back for next AMBE frame
}

Visually, this is the Voice Scrambler, directly from the JVC NXDN manuals, which anybody is free to download from their website.
View attachment 147678

if this seems familiar, its because a lot of things use LFSR functions. Project M17 uses its own version of the Voice Scrambler, just with different taps.

View attachment 147679

P25 Phase 2 Frames use an LFSR sequence to 'scramble' its frames.

View attachment 147680

and literally any sort of Initialization Vector are all generated/propogated by an LFSR function. This is from NXDN, but same applies to pretty much any IV I've ever seen.


View attachment 147682

The only real difference is the location of the taps, the direction of 'circulation', and when to grab the bit (MSB, LSB, before, or after operation).

Thanks for all the info , I will countine to work passively on this as school is starting up again this upcoming week.

 

[adsbgreenock]

Hi @lwvmobile

Yes I just read your post while the penny dropped this was a virtual machine of sorts. I got it working. Well im at the stage of entering the commands in the terminal.

Certainly a learning curve for me. And I thought I was OK with basic Linux etc etc 😂.

Nethertheless, thanks again for your help. I'll keep chipping away at it, like I did with the dsd-fme-aero ( I have your latest build, was just using that as an example so as to not confuse with Linux version)

Many thanks

Regards

 

[n5pwp]

I'm using an RSPDuo with SDRpp in server mode. Has anyone tried trunking from a remote SDRpp? I understand that SDRpp --server sends data out on port 7355. I think I understand that you control the SDR device using RigCtl. Will SDRpp --server allow you to control it remotely? I do see messages in the SDRpp --server window on the other machine indicating that it does recognize frequency changes. Or, do i need to have the SDR device actually connected to the SDRpp instance that I have DSD-FME working with? I tried setting up the trunking script and using the two csv files on the remote system and it never changed frequencies. It occurred to me that I might have to open a port 4532 on the SDRpp --server machine's firewall. Does the SDRpp --server know about accepting frequency changes from that port? From what I have read in this thread it seems everybody is trunking with the device (a dongle or an SDR) on the same machine that SDRpp and DSD-FME are running on. Does it sound like I've gone down a rabbit-hole?
Mike

 

[lwvmobile]

Running SDR++ in server mode isn't the same as running it 'headless', which is a feature that doesn't exist. When running SDR++ in server mode, it allows you to connect another instance of SDR++ to the server instance, and connect to and control the devices on the server instance of SDR++.

To do a Network Audio Sink and RIGCTL, you'll want to start the server end (if that's what your interested in) on the remote machine, and connect a local instance of SDR++ to that server under the Source tab, and then configure which device from the server you want to use and get it started. You'll then configure (if you haven't already) the network audio sink and rigctl, if desired, and let dsd-fme connect to that on the local end.

If the SDR++ server instance is on your LAN, then you shouldn't need to open any ports, unless its a seperate segment of your subnet (192.168.7.x vs 192.168.6.x and you have a router gating those two segments). Ethernet preferably over WIFI for stability, if possible. I have done some work remotely with SDR++ where I remote into a computer, and that computer connects to a SDR++ server in another location. In those instances across the internet, SDR++ will need the port you specify for the server instance to be port forwarded appropriately. Beware though, if the remote connection drops for a moment, it often will hang up your local instance of SDR++, and by extension, dsd-fme, and you'll have to force close both ends, and maybe even have to restart the remote SDR++ session as well. Just depends on your network and both ends internet connection and any other weird factors (Windows being Windows and interrupting TCP on its 13th pointless scan of the day, etc)

 

[n5pwp]

Running SDR++ in server mode isn't the same as running it 'headless', which is a feature that doesn't exist. When running SDR++ in server mode, it allows you to connect another instance of SDR++ to the server instance, and connect to and control the devices on the server instance of SDR++.

OK, thanks for the in-depth reply. I appreciate that. But, perhaps I wasn't clear. Let me see if I can be more clear what my situation is. I have a Linux Desktop in my office where the RSPDuo is and I'm in-deed running the Linux machine headless. I don't have space on my desktop for all the monitors so I'm using XRDP on the host machine (the SDRpp --server) and I run Remmina on the client machine. The client is a laptop, running Ubuntu I run SDRpp in client mode connected to the SDRpp --server over a network sink. that works fine for listening to individual frequencies or using SDRpp's scanner. I now want to be able to monitor trunked radio systems which I assume is how the client SDRpp tells the host to change frequencies according to the CC on the system I'm monitoring. I have used the default settings in SDRpp client for the RigCtl sink. In the address field of RigCtl I entered the IP of the host machine. When I 'try' start it I get a 'Idle' status. Both machines are on my LAN and are wired (no wifi involved). Since I'm sending control messages from the client to the server I thought I needed to open the 4532 port on the host machine to allow those messages through. I have opened the port on the server machine and it still gives a 'Idle' status. If I leave the address localhost I get a 'Listening' status. I can see the messages in the SDRpp server terminal indicating when I change frequencies. So why can't TRS systems be done the same way? I guess, since I don't know the internals of DSD-FME I don't know how DSD-FME would change frequencies based on what it decodes from the CC input. I've tried to conceptualize that how it works is DSD-FME gets the CC input and then tells SDRpp client to change the frequency based on that input. SDRpp tells the SDRpp server to change to that frequency on the stream it is sending to the client. Since it isn't working my realization is I don't have it worked out.

Just depends on your network and both ends internet connection and any other weird factors (Windows being Windows and interrupting TCP on its 13th pointless scan of the day, etc)

Yeah, my Windows machine is too old and can't upgrade the Graphics support to GLX3 so I can't run SDRpp on it. Luckily my Linux boxes run it fine.

Thanks again for your patience explaining all this. I have read this thread several times and can see how DSD-FME has developed since the beginning. It is a very nice piece of software. Kudos to you for providing it and the patience to support it.

Mike

 

[leoaln]

DSD-FME and SDR++ have been running for the past few days and decoding a good bit of traffic, but it seems to be not processing all of the traffic.
I have these entries throughout my log file.

13:35:16 Sync: +EDACS BCH FAIL
13:35:16 Sync: +EDACS FR_1 [FC2040054A] FR_4 [EF6029147E] Unknown Command
13:35:16 Sync: +EDACS BCH FAIL
13:35:16 Sync: +PV VOICE[32m Site: 2 AFS: 0-0 LCN: 12 [0m
13:35:16 Sync: +PV VOICE[32m Site: 2 AFS: 0-0 LCN: 12 [0m
13:35:16 Sync: +PV VOICE[32m Site: 2 AFS: 0-0 LCN: 12 [0m
Sync: no sync
13:35:17 Sync: +PV VOICE[32m Site: 2 AFS: 0-0 LCN: 12 [0m
13:35:17 Sync: +PV VOICE[32m Site: 2 AFS: 0-0 LCN: 12 [0m
13:35:17 Sync: +PV VOICE[32m Site: 2 AFS: 0-0 LCN: 12 [0m
13:35:17 Sync: +PV VOICE[32m Site: 2 AFS: 0-0 LCN: 12 [0m
13:35:17 Sync: +PV VOICE[32m Site: 2 AFS: 0-0 LCN: 12 [0m
13:35:17 Sync: +PV VOICE[32m Site: 2 AFS: 0-0 LCN: 12 [0m
13:35:17 Sync: +PV VOICE[32m Site: 2 AFS: 0-0 LCN: 12 [0m
13:35:17 Sync: +PV VOICE[32m Site: 2 AFS: 0-0 LCN: 12 [0m
13:35:18 Sync: +PV VOICE[32m Site: 2 AFS: 0-0 LCN: 12 [0m
13:35:18 Sync: +PV VOICE[32m Site: 2 AFS: 0-0 LCN: 12 [0m
13:35:18 Sync: +PV VOICE[32m Site: 2 AFS: 0-0 LCN: 12 [0m
and

13:35:20 Sync: +EDACS FR_1 [FC8FFFFC7B] FR_4 [FC8FFFFC7B] Unknown Command
13:35:20 Sync: +EDACS [33m Site ID [02][002] on CC LCN [03] Standard/Networked[0m
13:35:20 Sync: +EDACS FR_1 [FC9FFFFEBA] FR_4 [FC9FFFFEBA] Unknown Command
13:35:20 Sync: +EDACS [33m Site ID [02][002] on CC LCN [03] Standard/Networked[0m
13:35:20 Sync: +EDACS FR_1 [FC2040054A] FR_4 [FC400006E6] Unknown Command
13:35:20 Sync: +EDACS [33m Site ID [02][002] on CC LCN [03] Standard/Networked[0m
13:35:20 Sync: +EDACS FR_1 [FC21020D6B] FR_4 [FC400006E6] Unknown Command
13:35:20 Sync: +EDACS [33m Site ID [02][002] on CC LCN [03] Standard/Networked[0m
13:35:20 Sync: +EDACS FR_1 [FC21210262] FR_4 [FC400006E6] Unknown Command
13:35:20 Sync: +EDACS [33m Site ID [02][002] on CC LCN [03] Standard/Networked[0m
13:35:20 Sync: +EDACS FR_1 [FCE0E90718] FR_4 [FCE0E90718] Unknown Command
13:35:20 Sync: +EDACS FR_1 [FC8FFFFC7B] FR_4 [FC8FFFFC7B] Unknown Command
13:35:20 Sync: +EDACS [33m Site ID [02][002] on CC LCN [03] Standard/Networked[0m
13:35:20 Sync: +EDACS FR_1 [FC9FFFFEBA] FR_4 [FC9FFFFEBA] Unknown Command
13:35:20 Sync: +EDACS [33m Site ID [02][002] on CC LCN [03] Standard/Networked[0m
13:35:20 Sync: +EDACS FR_1 [FC2040054A] FR_4 [FC400006E6] Unknown Command
13:35:20 Sync: +EDACS [33m Site ID [02][002] on CC LCN [03] Standard/Networked[0m
13:35:20 Sync: +EDACS FR_1 [FC21020D6B] FR_4 [FC400006E6] Unknown Command
13:35:20 Sync: +EDACS [33m Site ID [02][002] on CC LCN [03] Standard/Networked[0m
13:35:20 Sync: +EDACS FR_1 [FC21210262] FR_4 [FC400006E6] Unknown Command
13:35:20 Sync: +EDACS [33m Site ID [02][002] on CC LCN [03] Standard/Networked[0m
13:35:20 Sync: +EDACS FR_1 [FC8FFFFC7B] FR_4 [FC8FFFFC7B] Unknown Command
13:35:20 Sync: +EDACS [33m Site ID [02][002] on CC LCN [03] Standard/Networked[0m

any significance in these messages?

 

[lwvmobile]

OK, thanks for the in-depth reply. I appreciate that. But, perhaps I wasn't clear. Let me see if I can be more clear what my situation is. I have a Linux Desktop in my office where the RSPDuo is and I'm in-deed running the Linux machine headless. I don't have space on my desktop for all the monitors so I'm using XRDP on the host machine (the SDRpp --server) and I run Remmina on the client machine. The client is a laptop, running Ubuntu I run SDRpp in client mode connected to the SDRpp --server over a network sink. that works fine for listening to individual frequencies or using SDRpp's scanner. I now want to be able to monitor trunked radio systems which I assume is how the client SDRpp tells the host to change frequencies according to the CC on the system I'm monitoring. I have used the default settings in SDRpp client for the RigCtl sink. In the address field of RigCtl I entered the IP of the host machine. When I 'try' start it I get a 'Idle' status. Both machines are on my LAN and are wired (no wifi involved). Since I'm sending control messages from the client to the server I thought I needed to open the 4532 port on the host machine to allow those messages through. I have opened the port on the server machine and it still gives a 'Idle' status. If I leave the address localhost I get a 'Listening' status. I can see the messages in the SDRpp server terminal indicating when I change frequencies. So why can't TRS systems be done the same way? I guess, since I don't know the internals of DSD-FME I don't know how DSD-FME would change frequencies based on what it decodes from the CC input. I've tried to conceptualize that how it works is DSD-FME gets the CC input and then tells SDRpp client to change the frequency based on that input. SDRpp tells the SDRpp server to change to that frequency on the stream it is sending to the client. Since it isn't working my realization is I don't have it worked out.

Sounds like you have SDR++ on the client side connected up to the SDR++ server side just fine if its running. Again, you'll need to run the network sink in TCP mode, 480000, no stereo, and either just use the default localhost address and port provided, or give it an IP address to bind to (usually the computers own IP address) and basically just do the same for rigctl, have it configured with localhost or a binding IP address and port. You'll want to start up both so that they are both listening, and then attempt to connect dsd-fme to it. You can either use the default parameters

dsd-fme -i tcp:localhost:7355 -U 4532 -T

or replace localhost with the IP address inside of SDR++ (again, that will want to be the IP address of the machine running SDR++) sometimes, using localhost may not resolve the 'correct' address, and supply an IP6 address, so you may need to put an IP4 address inside of SDR++ and in dsd-fme.

If nothing else, perhaps just watching the correct sequence of events will be good enough to point you in the correct direction. Here is a demonstration I made earlier after my first attempt to reply to this message failed due to power flickering (still suffering the backlash of Hurricane Idalia in Florida Man Land)

Just keep in mind, if you connected to the SDR++ Server on Machine A with the SDR++ Client on Machine B, then this procedure will be the exact same otherwise, the only difference is the source. Just pretend that I connected to a SDR++ server and that this video is the client side.

 

[lwvmobile]

DSD-FME and SDR++ have been running for the past few days and decoding a good bit of traffic, but it seems to be not processing all of the traffic.
I have these entries throughout my log file.

I don't have the most knowledge or information on EDACS systems, the decodes are pretty bare bones, with Extended Addressing variants like SLERS getting a few more elements decoded than the standard/network variant of EDACS. If those commands say network command or unknown command, then that's all I know about them. The calls grants should all work fine though. EDACS decoding on DSD-FME is just barely enough to get calls tuned and a site id, and it also looks like there is a bug in the AFS reporting on the voice channel, so I'm honestly not surprised by that either.

any significance in these messages?

The significance of those messages are, other than Site ID and Call Grants, I don't know how to decode those properly and it isn't worth sending hundreds of dollars to TIA to buy the manuals that may or may not tell me how to decode them lol.

 

[MTL_Emergencies]

Would DSD-FME be able to monitor an EDACS Networked standard system like this one: STM - Montreal transit ?
All voice calls are analog