Priority Scanning Two DMR channels on an NX5000

[dryfb]

More of an observation I made vs seeking a solution, but when priority scanning 2 DMR channels on an NX5k it uses lookback time B even when no carrier is present on priority channels and has the horrendous cutout as if a carrier were present and it was seeing if PL/RAN/NAC matched. Causes slight issues relocking onto Priority 2 when it goes to check Priority 1, about a second of dropped traffic at worst. Sometimes the dropout is almost unnoticeable

Occasionally, the dropout is consistently bad and excessively long, unlike normal (although normal dropout with P1 and P2 being DMR is still long) and a radio restart sometimes fixes it, battery pull seems to always fix it.

Running 5.23 firmware, and KPG is V5.20. Issue is not present with relocking onto P2 if P1 is NXDN/Analog/Mixed and P2 is DMR.

No different combo of settings regarding what gets stacked when a group call comes in, priority scan timing, mixed mode, auto slot select, or SD card recording seem to affect the dropout in a noticeable way.

Always possible my radio is out of RX alignment since the internal mic was way too hot and needed tuned but it seems to perform slightly better RXing NXDN then any other NXDN radio I have. I don't have any test equipment or a close dealer that I can have check it.

Somewhat related, the radio occasionally locks up on a DMR channel and will either lock up, have the screen fade out slowly and restart or lock up, get stuck on the channel, never clear the caller ID and not respond to any commands. That issue requires a battery pull to fix. Also will lock up and lag for a few seconds before accepting inputs and clearing the channel/caller ID. I haven't found a rhyme or reason to those issues since everytime it's happened I needed to clear it quickly and didn't have time to try to diagnose.

 

[kd4efm]

Nice write up, I say to you, log into the support site, sign up, and submit your report.

Sign in to KENWOOD Support Portal

 

[kd4efm]

This may be a bug, or something they currently see. Never know without asking.

 

[dryfb]

Nice write up, I say to you, log into the support site, sign up, and submit your report.

Sign in to KENWOOD Support Portal

Thank you! Ticket's been made.

Also worth noting that thru testing just now, when P1 is An/NXDN/Mixed and P2 is DMR, lookback time A is used and the cutout is unnoticeable aside from signal strength indicator and RX led blanking out.

 

[dryfb]

Some more findings I've made:

My theory is the radio treats any RSSI above -120 as a carrier on DMR, so a slightly elevated noise floor will cause it to go into lookback time B. I took my antenna off and it scanned perfectly fine using lookback time A, and the cutout was unnoticeable.

I tried setting the tuning item for DMR Open Squlech to values above 200 and the issue persisted with no change.

I think the radio just fundamentally handles elevated RF noise on a DMR channel wrong or my radio needs an alignment for RSSI values.

 

[kd4efm]

trying to remember a post I did back two or more years ago about the DMR behavior and I think is was with o2bMark and I discussing it.

The scan on DMR definitely needs a little work, but as fair as i recall, the process is it looks at the tdma signal, validates that, then looks at the CC, validates that, then looks at the slot, validates that, and then looks at the GID for valid data, THIS is where it gets hung up. if the GID does not match, it still validated the Freq, CC, Slot. So it's looking for GID to match before moving on in scan.

Had several "intense" emails back and forth with a few people over this, but in the end, this is how it was "door stopped" and that was that.

The scan has been "cleaned up" per say a little from my testing, though I am P25 and NXDN with 2% dmr use and only if I want to bug a few dmr buddies, but this is my findings and the information I can pass along based on "my experience with it". Everyone will have a different take,
and that's okay.

 

[dryfb]

trying to remember a post I did back two or more years ago about the DMR behavior and I think is was with o2bMark and I discussing it.

The scan on DMR definitely needs a little work, but as fair as i recall, the process is it looks at the tdma signal, validates that, then looks at the CC, validates that, then looks at the slot, validates that, and then looks at the GID for valid data, THIS is where it gets hung up. if the GID does not match, it still validated the Freq, CC, Slot. So it's looking for GID to match before moving on in scan.

Had several "intense" emails back and forth with a few people over this, but in the end, this is how it was "door stopped" and that was that.

The scan has been "cleaned up" per say a little from my testing, though I am P25 and NXDN with 2% dmr use and only if I want to bug a few dmr buddies, but this is my findings and the information I can pass along based on "my experience with it". Everyone will have a different take,
and that's okay.

That's what I had assumed but in my case there isn't even a TDMA signal for it to validate anything on, just a noise floor at about -115 dBm or so. I've started running mixed mode just to see if there was a difference and there wasn't, but I have to set my squelch to 0 to actually have the radio detect a carrier.

Worth noting that when the RSSI on the priority DMR channels displays as ****, the issue isn't present at all. When the RSSI is -120 dBm or higher it will use lookback time B and the number of places where the noise floor isn't at least -120 dBm are quite rare here.