search

szechyjs / dsd

Digital Speech Decoder
Other
681 stars 267 forks source link

Question on p25_raw_unencrypted.flac #24

Open EdFuentetaja opened 10 years ago

EdFuentetaja commented 10 years ago

Hi there. This is just a question, not a bug. I'm playing with the p25_raw_unencrypted.flac from the samples repository. Towards the end of the decoding there is an LDU with many errors:

Sync: +P25p1 mod: QPSK inlvl: 20% nac: 1F5 src: 4270002 tg: 7455 LDU1 e:==========R==========R==========R==========RM==========R==========R

I've been debugging this. Seems like in this LDU the IMBE words from 4 to 9 are all exactly the same, with a C0 which looks like:

data: (0, 0, 0, 0, 0, 1, 1, 1, 0, 0, 0, 0) golay23 parity: (0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0)

The parity is not correct for that data, hence the decoding errors. But I don't think it's an error. Since this is repeated exactly on 6 IMBE words I believe it's intentional. The BER for this sample is fairly low.

There are some special values for IMBE words to encode silence or tones, but they should come with a valid golay23 parity. This one doesn't.

If this is a special case, I cannot find it in the P25 documentation or anywhere else. Might this be specific to the radio device used? Some kind of non-standard value that got some meaning for the vendor? It's a the very end of the speech.

mattames commented 10 years ago

Hi Guys,

This behaviour is covered in TIA-102.BAAA-A section 8.2.3, paragraph 2 on page 37. Motorola even went to the trouble of patenting this method (It predates IMBE and was related to the older VSELP format.. However IMBE behaves in exactly a similar manner. - https://www.google.com/patents/US5220565

Cheers, Matt

On Sat, Apr 19, 2014 at 1:18 PM, EdFuentetaja notifications@github.comwrote:

Hi there. This is just a question, not a bug. I'm playing with the p25_raw_unencrypted.flac from the samples repository. Towards the end of the decoding there is an LDU with many errors:

Sync: +P25p1 mod: QPSK inlvl: 20% nac: 1F5 src: 4270002 tg: 7455 LDU1 e:==========R==========R==========R==========RM==========R==========R

I've been debugging this. Seems like in this LDU the IMBE words from 4 to 9 are all exactly the same, with a C0 which looks like:

data: (0, 0, 0, 0, 0, 1, 1, 1, 0, 0, 0, 0) golay23 parity: (0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0)

The parity is not correct for that data, hence the decoding errors. But I don't think it's an error. Since this is repeated exactly on 6 IMBE words I believe it's intentional. The BER for this sample is fairly low.

There are some special values for IMBE words to encode silence or tones, but they should come with a valid golay23 parity. This one doesn't.

If this is a special case, I cannot find it in the P25 documentation or anywhere else. Might this be specific to the radio device used? Some kind of non-standard value that got some meaning for the vendor? It's a the very end of the speech.

— Reply to this email directly or view it on GitHubhttps://github.com/szechyjs/dsd/issues/24 .

EdFuentetaja commented 10 years ago

I would agree with you Matt that those are silences being transmitted. What I don't understand is why they don't follow the P25 standard. According to the same TIA document you mention, on page 7, section "4 Voice Coder", they say that silences are encoded with values from 216-219. So, if they want to indicate a silence, they should send a C0 like:

data: (1, 1, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0) // left 8 bits = 216 in binary golay23 parity: (1, 1, 1, 0, 0, 0, 1, 0, 0, 0, 0) // proper golay23 parity for the data

That would gracefully reach into the mbe_decodeImbe4400Parms method of the libmbe library and be interpreted as a silence.

Instead something else is being transmitted, something that doesn't even got the proper parity and therefore libmbe interpret as an error.

If the Motorola radio is right then we have a bug either in DSD/libmbe.

Kind regards,

Ed