DSD FME

[lwvmobile]

Ok. Maybe I did not explain it correctly. DSD-FME does not decode SMS/TMS, but dsd+ fast line does - until the traffic is encrypted. So i was wondering if in the near future, there is any possibility to dsd-fme decode this kind of data or (as you already answered) to push decrypted signal to dsd+ fastline to decode sms/tms.

I think you can 'piggyback' the raw audio from FL into DSD-FME if you use that 'always monitor source audio' option and pipe that into a virtual cable, and then pipe that as input into DSD-FME, and have both decode the same signal, if you wanted FL to decode one particular element, and have FME decode the other.

You could also submit samples of your SMS messages if you wanted FME to decode them, and I'll look into it and see what can be done, would just need to know what to look for as far as what the message is supposed to say, etc. If its an encrypted SMS, then I can't do much about it, don't know enough about how data packets are encrypted, if and when they are encrypted.

 

[doriboni]

I'm trying to figure out how the 32-bit MI that is in the 18 AMBE frames works. I know that all 18 AMBE frames contain the MI for the next superframe.

In the dmr_le.c file we find:

mi_test = (state->late_entry_mi_fragment[slot][1][0] << 32L) | (state->late_entry_mi_fragment[slot][2][0] << 28) | (state->late_entry_mi_fragment[slot][3][0] << 24) |
(state->late_entry_mi_fragment[slot][1][1] << 20) | (state->late_entry_mi_fragment[slot][2][1] << 16) | (state->late_entry_mi_fragment[slot][3][1] << 12) |
(state->late_entry_mi_fragment[slot][1][2] << 8) | (state->late_entry_mi_fragment[slot][2][2] << 4) | (state->late_entry_mi_fragment[slot][3][2] << 0);

go_test = (state->late_entry_mi_fragment[slot][4][0] << 32L) | (state->late_entry_mi_fragment[slot][5][0] << 28) | (state->late_entry_mi_fragment[slot][6][0] << 24) |
(state->late_entry_mi_fragment[slot][4][1] << 20) | (state->late_entry_mi_fragment[slot][5][1] << 16) | (state->late_entry_mi_fragment[slot][6][1] << 12) |
(state->late_entry_mi_fragment[slot][4][2] << 8) | (state->late_entry_mi_fragment[slot][5][2] << 4) | (state->late_entry_mi_fragment[slot][6][2] << 0);


What's in State->late_entry_mi_fragment[slot][ 1] [0] ?
Is it 4 bits extracts from the first encrypted or the first decrypted AMBE frame ?
What does state->late_entry_mi_fragment[slot] [1] [1] contain, is this the second AMBE frame?

Is the bit distribution the same as in this diagram or is it different?

 

[lwvmobile]

I'm trying to figure out how the 32-bit MI that is in the 18 AMBE frames works. I know that all 18 AMBE frames contain the MI for the next superframe.

Usually, the way I handle it, at least in DSD-FME, is to use the MI, or Initialization Vector, that is carried on the PI header and run an LFSR on it at the end of each superframe. For RC4, only a 32-bit MI is required for each perpetual superframe, but if its another algorithm, such as AES-256, then a larger MI (128-bit) is required, but regardless, either or can be generated from the 32-bit MI using the correct LFSR taps and number of cycles to expand from 32 to the next set of 32, or from 32 to 128 bit as an OFB first round input.

In the case of the late entry you pasted in there, that is a method to gather an MI in the event of late entry, when you tune late and miss the initial Privacy Indicator header, and those are indeed, for DMR, carried across 4 bit regions in each of the AMBE frames that comprise a superframe. The late entry Key/ALG is carried in VC-F single burst (VC-B through VC-E carrying the embedded link control). Here is a diagram that roughly corresponds to the one you pulled from the patent that I made back over a year and a half ago, but is generally what the code is gathering when late entry is dumped on each voice frame.




The late entry is primarily used to get an MI in case you miss the PI header, or bad/weak signal and frame sync skip occurs, the ongoing MI can be corrected for the next superframe. Each AMBE frame carries 4-bits that correspond to the MI, the Golay Party Bits, CRC, or padding. This is also why DMR using encryption 'sounds worse', because 4 out of 49-bits of AMBE are manipulated and is degraded. (Just my personal two cents, my opionion, because ETSI didn't plan this out, and nobody thought to use the embedded link control to convey the IV).

 

[lwvmobile]

What's in State->late_entry_mi_fragment[slot][ 1] [0] ?
Is it 4 bits extracts from the first encrypted or the first decrypted AMBE frame ?
What does state->late_entry_mi_fragment[slot] [1] [1] contain, is this the second AMBE frame?

Is the bit distribution the same as in this diagram or is it different?

Short answer is yes, it is the 4-bits that correspond to the MI in each AMBE frame (prior to decryption, otherwise, late entry MI wouldn't work). It corresponds to that diagram.

 

[doriboni]

Thanks, but how do you display the frames AMBE_FR? (which DSD-FME command)
What do AMBE_FR frames contain?

An AMBE frame is 49 bits (6 bytes + 1 byte for the last bit)
A FEC frame is 72 bits (9 bytes)
Your AMBE_FR frames appears to contain 12 bytes.

The patent seems to say that you can extract the MI from the voice bits. where is the MI in my example?

 

[doriboni]

Just my personal two cents, my opionion, because ETSI didn't plan this out, and nobody thought to use the embedded link control to convey the IV).

What is the "embedded link control" ?
Is it the SYNC in my example ?

if so, how would it have been possible to put an MI in this SYNC, since it's normalized.
If the correct SYNC is not received by the sending radio, then the packet is discarded, right?

 

[lwvmobile]

Thanks, but how do you display the frames AMBE_FR? (which DSD-FME command)
What do AMBE_FR frames contain?

That was just some debug output I had from back over a year and a half ago or so. Since then, the code governing late entry has been re-written and reorganized multiple times, and I don't have the code to dump the ambe_fr frames any more.

Your AMBE_FR frames appears to contain 12 bytes.

Again, that was just testing and debug to help me figure out the patent, if you'll notice the zeroes in that output, it was packed favoring MSB going left, so after the correct number of significant bits in each field, it just has 0 bit padding for those extra nibbles displayed. Now we just get the first 4 bits of ambe_fr[3], since those are the manipulated bits.

If you want to, and can compile the code yourself, you can add a couple lines similar to this into the dmr_le.c file into the
dmr_late_entry_mi_fragment function.

for (int i = 0; i < 3; i++)
    fprintf (stderr, " AMBE_FR3: %llX; \n", state->late_entry_mi_fragment[slot][vc][i] );

And It'll dump those similar to this:

10:58:29 Sync: +DMR MS/DM MODE/MONO | VC*
 AMBE 125E4610263800 err = [0] [0]
 AMBE F5AE12E077DF00 err = [0] [0]
 AMBE BC4CC6DF2D8B00 err = [0] [0]
 AMBE_FR3: 0;
 AMBE_FR3: 7;
 AMBE_FR3: 6;
 AMBE AFBBE7B26BBD00 err = [0] [0]
 AMBE FDD7EEDA0D1100 err = [0] [0]
 AMBE 4A74ACB32D0680 err = [0] [0]
 AMBE_FR3: 5;
 AMBE_FR3: 4;
 AMBE_FR3: B;
 AMBE C0A75D782EFB00 err = [0] [0]
 AMBE 784C15EC881D00 err = [0] [0]
 AMBE 004E85FA872B00 err = [0] [0]
 AMBE_FR3: 6;
 AMBE_FR3: 5;
 AMBE_FR3: 6;
 AMBE AAEF8C562FA500 err = [0] [0]
 AMBE 2900507277C480 err = [0] [0]
 AMBE 618F4B0BCAE100 err = [0] [0]
 AMBE_FR3: D;
 AMBE_FR3: 1;
 AMBE_FR3: C;
 AMBE A3D18975705580 err = [0] [0]
 AMBE 9C37835C404080 err = [0] [0]
 AMBE EFF112F9AE1000 err = [0] [0]
 AMBE_FR3: 5;
 AMBE_FR3: 0;
 AMBE_FR3: 8;
 AMBE A57276CEC19F80 err = [0] [0]
 AMBE C838DB72709280 err = [0] [0]
 AMBE 8C56C6D77AC200 err = [0] [0]
 SLOT 1 TGT=11730226 SRC=878103 FLCO=0x00 FID=0x10 SVC=0x40 Group Encrypted Call 
 DMR PDU Payload [00][10][40][B2][FD][32][0D][66][17] SB: 01100111001 - 339;

 Slot 1 DMR LE SB ALG ID: 0x21 KEY ID: 0x67
 Slot 1 DMR PI C- ALG ID: 0x21 KEY ID: 0x67 MI(32): 0x0567456B

 

[doriboni]

for (int i = 0; i < 3; i++) fprintf (stderr, " AMBE_FR3: %llX; \n", state->late_entry_mi_fragment[slot][vc] );

With you example :
I have to take bits 46,47,48 and 49, right?

 AMBE 125E4610263800 err = [0] [0]
 AMBE F5AE12E077DF00 err = [0] [0]
 AMBE BC4CC6DF2D8B00 err = [0] [0]
 AMBE_FR3: 0;
 AMBE_FR3: 7;
 AMBE_FR3: 6;

38 00= 00111(000 0) . The last 4 bits = 0000 -> 0 same
DF 00 = 11011(111 0) The last 4 bits = 1110 -> E not same (not 7)
8B 00 = 10001(011 0) The last 4 bits = 0110 -> 6 same

 

[lwvmobile]

I have to take bits 46,47,48 and 49, right?

No. the 49-bit representation is the processed AMBE frame, we are after the raw 72-bit AMBE frame which has been deinterleaved into its c0, c1, c2, and c3 vectors and still contains its golay parity, etc. We can't copy the bits in the processed frame, we have to get the raw version as it comes over the air. The last 4 of the 49-bit representation is not the same 4 bits we want.

 

[doriboni]

No. the 49-bit representation is the processed AMBE frame, we are after the raw 72-bit AMBE frame which has been deinterleaved into its c0, c1, c2, and c3 vectors and still contains its golay parity, etc. We can't copy the bits in the processed frame, we have to get the raw version as it comes over the air. The last 4 of the 49-bit representation is not the same 4 bits we want.

Uh, that's why that didn't works.
And what code should I put and where, to display not just the 4 bits, but the whole of each 72-bit frame?

 

[lwvmobile]

You might try this:

if (opts->payload == 1)
{
    fprintf (stderr, "AMBE_FR1 - C0:%06X; C1:%06X; C2:%04X; C3:%04X; \n", (uint32_t)ConvertBitIntoBytes(&ambe_fr[0][0], 24), (uint32_t)ConvertBitIntoBytes(&ambe_fr[1][0], 24), (uint32_t)ConvertBitIntoBytes(&ambe_fr[2][0], 12), (uint32_t)ConvertBitIntoBytes(&ambe_fr[3][0], 16) );
    fprintf (stderr, "AMBE_FR2 - C0:%06X; C1:%06X; C2:%04X; C3:%04X; \n", (uint32_t)ConvertBitIntoBytes(&ambe_fr2[0][0], 24), (uint32_t)ConvertBitIntoBytes(&ambe_fr2[1][0], 24), (uint32_t)ConvertBitIntoBytes(&ambe_fr2[2][0], 12), (uint32_t)ConvertBitIntoBytes(&ambe_fr2[3][0], 16) );
    fprintf (stderr, "AMBE_FR3 - C0:%06X; C1:%06X; C2:%04X; C3:%04X; \n", (uint32_t)ConvertBitIntoBytes(&ambe_fr3[0][0], 24), (uint32_t)ConvertBitIntoBytes(&ambe_fr3[1][0], 24), (uint32_t)ConvertBitIntoBytes(&ambe_fr3[2][0], 12), (uint32_t)ConvertBitIntoBytes(&ambe_fr3[3][0], 16) );
}

It produces this result, just keep in mind I've packed the bits into bytes such that the first hex value will align fully left and produce the 4 bit hex representation of the value you are looking for in those, and as such, there will be varying levels of padding bits (C0:24 bits, C1: 23 bits, C2: 11 bits, C3: 14 bits) but they are packed as (24, 24, 16, 16) for convenience.

12:00:25 Sync: +DMR MS/DM MODE/MONO | PI   
 Slot 1 DMR PI H- ALG ID: 0x01 KEY ID: 0x67 MI: 0x12345678 Anytone RC4 (0x01)
 DMR PDU Payload [01][10][67][12][34][56][78][B2][FD][32][62][2A]
12:00:25 Sync: +DMR MS/DM MODE/MONO | VC*
 AMBE 273AB193908E80 err = [0] [0]
 AMBE 3EB4B9FF41C080 err = [0] [0]
 AMBE E234B967D01B00 err = [0] [0]
AMBE_FR1 - C0:716CE4; C1:A5A648; C2:0392; C3:B884;
AMBE_FR2 - C0:823D7C; C1:458F1A; C2:05FE; C3:81C0;
AMBE_FR3 - C0:7C4C47; C1:28226C; C2:07CC; C3:6C04;
 AMBE D9FC881A3B3180 err = [0] [0]
 AMBE A24F668776CB00 err = [0] [0]
 AMBE 68365C9B343F80 err = [0] [0]
AMBE_FR1 - C0:C3DF9B; C1:75E93A; C2:08B0; C3:466C;
AMBE_FR2 - C0:E2F245; C1:213C04; C2:0DC2; C3:E9B4;
AMBE_FR3 - C0:3ADC16; C1:4763EE; C2:09B2; C3:7E14;
 AMBE B0071D5E460380 err = [0] [0]
 AMBE 0B7B204B7BA880 err = [0] [0]
 AMBE 93865D6C6D4E80 err = [0] [0]
AMBE_FR1 - C0:95200D; C1:776800; C2:04F4; C3:6030;
AMBE_FR2 - C0:4CBED0; C1:DB8194; C2:0DA4; C3:0AEC;
AMBE_FR3 - C0:B5C1C9; C1:94247E; C2:0C6C; C3:3958;
 AMBE 814903244AB280 err = [0] [0]
 AMBE 5A2C7E5E52E100 err = [0] [0]
 AMBE 8342CDCF825800 err = [0] [0]
AMBE_FR1 - C0:A1A281; C1:266E08; C2:0448; C3:A6A8;
AMBE_FR2 - C0:65B45A; C1:072E1E; C2:04F4; C3:43A4;
AMBE_FR3 - C0:12C2C1; C1:0D02F2; C2:03E6; C3:0D20;
 AMBE 1D3E9990C1CC80 err = [0] [0]
 AMBE 83662C7C5EE780 err = [0] [0]
 AMBE 6ED6902A717680 err = [0] [0]
AMBE_FR1 - C0:A2DCB8; C1:619044; C2:0612; C3:99C0;
AMBE_FR2 - C0:6E56C1; C1:03F4C2; C2:047C; C3:F3BC;
AMBE_FR3 - C0:E67B76; C1:6D0460; C2:0CA8; C3:B744;
 AMBE 1A4AD5BA038400 err = [0] [0]
 AMBE 5E62E3BF49E600 err = [0] [0]
 AMBE EEA2D23B1F5D80 err = [0] [0]
 SLOT 1 TGT=11730226 SRC=878103 FLCO=0x00 FID=0x10 SVC=0x40 Group Encrypted Call 
 DMR PDU Payload [00][10][40][B2][FD][32][0D][66][17] SB: 01100111001 - 339;
 Slot 1 DMR LE SB ALG ID: 0x21 KEY ID: 0x67
 Slot 1 DMR PI C- ALG ID: 0x21 KEY ID: 0x67 MI(32): 0xB468E067

 

[doriboni]

Thank you very much.
But I'd also like to display the raw 72 bits of the air interface without any changes or shift.

Is this easily possible and how? (even in a location other than dmr_le.c)
My goal is not to see the final data decoded but to understand for myself how to extract data from the MI and to be able to do it manually from the 72-bit raw frame.

(Just my personal two cents, my opionion, because ETSI didn't plan this out, and nobody thought to use the embedded link control to convey the IV).

What is the "embedded link control" ?
Is it the SYNC in my example ?
if so, how would it have been possible to put an MI in this SYNC, since it's normalized.
If the correct SYNC is not received by the radio, then the frame is discarded, right?

 

[lwvmobile]

But I'd also like to display the raw 72 bits of the air interface without any changes or shift.

If you don't want any shifts, then just have it convert to the exact number of bits in those codewords from 24,24,16,16 to 24, 23, 11, 14 in each 'convert' function, or you could dump it out bit by bit if you'd prefer. If you want it before its deinterleaved, literally the way it comes off of the air, then you would have to look at dmr_ms and dmr_bs and grab the dibits as they come in. Since this isn't a coding lesson (not like I'm a person qualified to teach how to code correctly), I'll leave the details to you.

What is the "embedded link control" ?
Is it the SYNC in my example ?

If the correct SYNC is not received by the radio, then the frame is discarded, right?

If it can't SYNC on the pattern, then the next voice superframe isn't handled by the radio since it doesn't know its supposed to be there.

if so, how would it have been possible to put an MI in this SYNC, since it's normalized.

The Embedded Link Control is a 72-bit field that is perpetuated every voice superframe, you can put any number of messages in the embedded link control. DMR often does it for other things than the usual group voice call svc opts, tgt, src parameters, including things like Talker Alias, GPS, and so on. It wouldn't be difficult to put the same information that a PI header carries in that field every other superframe, the tradeoff would be that you may have to wait an extra superframe to start decoding voice if late entry occurs. So, if they used the embedded link control to carry an IV, then they wouldn't need to degrade the ambe voice samples.

 

[doriboni]

Thank you for all your information.
That's interesting for Embedded Link Control. I don't understand why Motorola didn't do that in their patent.

 

[jimmy9999]

Uh, that's why that didn't works.
And what code should I put and where, to display not just the 4 bits, but the whole of each 72-bit frame?

I'm assuming you're looking to display the contents of a full superframe in hexa? if that's the case, you could try LEH's DSD with the -DPMRPrintVoiceFrameHex command, which does just that.
I could be wrong but I don't think DSD-FME does?

 

[Jonboyus]

Signed up to ask about this… I run a local NXDN conventional system with scrambling. I’ve been trying to use DSD-FME and an SDR to listen to the system but for some reason I’m unable to decode the scrambled signal from a wav recording.

I’ve been using the -R command with the 5 digit dec code but I just get garbled audio, and the garbling is the same if I change the code to a knowingly incorrect one. I also get the exact same number of “total audio errors” whether the code is right or wrong.

Any ideas? The recording should have sufficient signal strength so it’s not that. I’ve also tried -s 96000

Can anyone help with this? The only thing I can think of that might be the cause is I see some CRC ERR in the console when playing the recording back but I assumed this is because the signal is scrambled. But they appear even with the correct code and the audio errors number doesn’t change.

 

[lwvmobile]

Can anyone help with this? The only thing I can think of that might be the cause is I see some CRC ERR in the console when playing the recording back but I assumed this is because the signal is scrambled. But they appear even with the correct code and the audio errors number doesn’t change.

Well, what command are you trying to use, and how did you create your wav files? NXDN decoding in DSD-FME is very particular about the need for squelch to be enabled, otherwise it can framesync on about any amount of floor noise.

I may have missed this issue originally because I thought this was the same issue covered here and the same person, perhaps I am mistaken. Regardless, if you scroll down to the sixth reply on that there is a sample wav file I created of NXDN48 that is the correct format. Remember, squelch is required if using NXDN in DSD-FME, even for wav files, and also, some DSDPLus sourced raw audio with NXDN does not always work well in DSD-FME, particularly if the signal is faint or the gain is turned all the way up.

 

[Jonboyus]

Well, what command are you trying to use, and how did you create your wav files? NXDN decoding in DSD-FME is very particular about the need for squelch to be enabled, otherwise it can framesync on about any amount of floor noise.

I may have missed this issue originally because I thought this was the same issue covered here and the same person, perhaps I am mistaken. Regardless, if you scroll down to the sixth reply on that there is a sample wav file I created of NXDN48 that is the correct format. Remember, squelch is required if using NXDN in DSD-FME, even for wav files, and also, some DSDPLus sourced raw audio with NXDN does not always work well in DSD-FME, particularly if the signal is faint or the gain is turned all the way up.

That’s not me who submitted that issue however I’ll try your recommendation of using SDR++ to record the wav file as I was indeed using dsdplus.

Does the signal have to be extra strong for the descramble to work with -R ? And I’m guessing the “total audio errors” number should be lower if it’s descrambled right? At the moment, on the wav recordings I have (regardless of right or wrong key - eg if I increment it by one) I get the same total audio errors whether the key is right or wrong which seems odd to me. I would expect even with a bad decode that the errors wouldn’t be exactly the same?

 

[lwvmobile]

Does the signal have to be extra strong for the descramble to work with -R ?

It just has to be clean signal to get good decodes, including things like the Structure Field and VCALL in order to set the encryption parameters (cipher type) and which part of the superframe we are in for keystream application. I often find that decoding issues arise mostly from weak or fading signal, gain turned way too high, wrong BW, noisy band, interfering signals on the same frequency, or a combination of those things.

I would expect even with a bad decode that the errors wouldn’t be exactly the same?

FEC is applied after the keystream application in pretty much any form of voice encryption, so the errors calculated will be the same regardless of whether or not you have the correct key or not. The only exception to that rule that I am aware of is RAS, which is a manipulation of the CRC itself.

 

[Jonboyus]

It just has to be clean signal to get good decodes, including things like the Structure Field and VCALL in order to set the encryption parameters (cipher type) and which part of the superframe we are in for keystream application. I often find that decoding issues arise mostly from weak or fading signal, gain turned way too high, wrong BW, noisy band, interfering signals on the same frequency, or a combination of those things.


FEC is applied after the keystream application in pretty much any form of voice encryption, so the errors calculated will be the same regardless of whether or not you have the correct key or not. The only exception to that rule that I am aware of is RAS, which is a manipulation of the CRC itself.

View attachment 152800

Thanks! This was super helpful. I was able to decode it with the key now. It was a combination of poor signal and bad recording. The audio errors was the same as you said. Is there a way to only output the descrambled audio? There are other users on the system with a different key and I don’t wanna hear their garbled audio.