DSD P25 signal dropping out

[bob-the-scanner-man]

I've been tinkering with a Radioshack Pro-2050 and the new DSD Windows port. I can decode just fine but throughout a transmission my audio will drop out at times which makes it hard to understand what is being said. When this happens I can see on the command prompt screen either "Ignoring LDU2 not preceded by LDU1" or "Unknown DUID". I don't know what this means, but it's causing me to be unable to decode certain parts of voice traffic and it's very annoying.

What's causing this? Is it a problem with my discriminator tap? Antenna? Sound card settings? I'm at a loss here.

 

[kma371]

DUID
Digital unit ID? Like the number assigned to the radio.

 

[bob-the-scanner-man]

I guess. It seems as if the "Unknown DUID" message isn't affecting my decoding, but the "Ignoring LDU2 not preceded by LDU1" definitely is. If I could figure out what that is or what causes it and how to stop it from happening I'd have perfect audio.

I've included some screenshots to show what I mean. I'll be decoding fine and then the audio will drop for a few seconds and DSD will display "Ignoring LDU2 not preceeded by LDU1" and then the audio will pick back up. It's very annoying. It makes it difficult to understand what is being said.

 

[MattSR]

The two are linked to each other.

DUID = Data Unit ID, which is the P25 frame type. DUID 5 = LDU1 DUID 10 = LDU2. These are the two voice frames. there are other DUIDs such as Trunking Signalling block, Packet Data Unit, Header data unit etc etc.

LDU2 always comes after LDU1. If you get a bad decode on an LDU1 frame, it is discarded. The proceeding LDU2 frame is then ignored because LDU2 sometimes depends on the metadata carried over in LDU1.

Basically, your problem is poor quality decode. Noise on the channel or a marginal signal. Its not a software issue in DSD, but rather something wrong with your decoding setup.

Matt.

 

[bob-the-scanner-man]

Ok, thanks.

Going on that info does it seem more likely that I'm just not getting good reception from the system I'm monitoring, or is it coming from my discriminator tap itself? I did the tap by the book so I personally am thinking it's just poor reception.

I have noticed that my reception on my Pro-96 can be pretty bad in my home which leads to digital noise sometimes breaking in during a transmission. The same thing must be happening with the Pro-2050 and DSD. I'm guessing it may be time for me to look at setting up some kind of 800mhz base antenna instead of using my rubber duckie.

 

[KJ4ODU]

what means did you Install the Dis Tap on the Pro-2025?

also did you ever Continue with the DSD4win and the 2025.\

Is I have one trying to hear Carrollton GA, P25. its really Choppy and I might get 3 works. at max.

Tried Line in, Mic, USB Sound, tried all the Freq even the Control Channel.

I will start a new Thread I can't find out what I need to do....


Thanks.

 

[slicerwizard]

Basically, your problem is poor quality decode. Noise on the channel or a marginal signal. Its not a software issue in DSD, but rather something wrong with your decoding setup.

Yeah, I'm responding to an old thread that someone else revived, but what the hell.


The P25 DUID / frame type is a 4 bit value, that along with the 12 bit NAC, is protected by 47 bits of BCH FEC data. The BCH code can correct up to 11 bit errors (e.g. any 11 bits out of the total 63 bits). This means that the entire 4 bit DUID value can be trashed, yet still be recoverable. The NAC and DUID values are not interleaved in any way, but are instead sent over the RF channel as a contiguous block of 8 symbols, so it's very easy for a noise burst to take out a sizeable chunk of the NAC and/or DUID. However, DSD does not use the 47 FEC bits (they are just discarded) to recover the NAC and DUID values, so it is a software issue in DSD.

The P25 protocol designers did not assume that P25 4 level data would be received error-free 100% of the time, nor should they - in the real world, bits get flipped. DSD attempts to error-correct the Golay-protected IMBE voice data (although the process is flawed), but fails to correct the much better protected and far more critical DUID value. This leads to entire 180ms or 360ms audio chunks being lost. That's a lot of audio. The lack of error correction is also why DSD will sometimes display incorrect NAC, talkgroup and radio ID values.


Having said all that, this is by no means a dig against the DSD authors, who describe themselves as "non-programmers". DSD is wonderful proof of concept, not a finished product. Many major components are missing:

- proper noise filtering

- proper symbol shaping

- proper symbol centering

- proper FEC on all critical data


That's off the top of my head. Other issues include:

- the incomplete Golay FEC table

- unnecessary sensitivity to input audio levels

- no ability to select/force decoding of specified DMR/TRBO timeslots

- no detection of the various NXDN trunking sync patterns

- much higher than required CPU usage


Again, not a dig, just stating the facts/issues.