- Status
jasonhouk
Member
Happens all the time with OSP and their mobile repeaters.
Sent from my Moto G (4) using Tapatalk
jasonhouk
Member
UPMan is traveling today and the following is UJE's (Uniden Japan's) findings from the logs submitted:
According to his logs, it seems there is no false TGID.
There are sometimes a short transmission that does not have voice data.
1. The scanner is on the control channel.
2. It receives a voice grant message of TGID_A and Unit ID_A.
3. It moves to the voice channel.
4. It immediately receives a TX release message of TGID_A and Unit ID_A.
LCNs are correct, because verification check of TGID_A and Unit ID_A included in both messages is OK.
As for the issue of scanner's lag and/or unresponsive keypad, it is necessary to reduce the CPU load.
Houk
The debug file doesn't show what we're seeing on this system. I've compared notes with another user who is using a 436 and is seeing the same issues.
2. The scanner is seeing a voice grant message of TGID-A but what is not correct is no UID is showing. The TGID resembles an active UID on the system. Is it possible the system is sending data to the UID and since the last two firmware versions, instead of "skipping" over it, the scanner sees this as a TGID and holds on it?
3. It only moved to a voice channel because I either pressed Avoid or turn the selector knob to continue running the log.
4. Same as above.
As far as reducing the CPU load, the scanner's key pad is laggy and/or unresponsive no matter what the percentage of usage. Using a 32gb high endurance SD card, issues were seen with as little as 3% and up to 20%. Yesterday...had to empty the SD card because the scanner was resetting itself (21% memory used). When a transmission is active is when the keypad problems are at the worst. When nothing is active, scanner operates normally.
I appreciate the response back Houk!
jasonhouk
Member
Just my suggestion: Create another logfile with only #2 issue you're seeing, scanning only one active site and without any manual intervention #3 (avoiding or tuning)
Please rename the log file as:
TYPE_<sys name>_counter
Where:
TYPE= N9600, N4800, IDAS
sys name = a way to identify the system scanned
counter = just a number to differentiate different logs of the same system.
Use Auto Threshold for all.
Houk
Unfortunately the scanner would "hang" on the TGID and would never continue ID Searching. Usually 5 minutes was my limit, but wanted to demonstrate it wasn't limited to one TGID. Manual intervention was necessary for sampling purposes.
Current memory used 1%...had to press keypad 3 times to hold on a specific talk group just now during active transmission. Once no transmission, scanner keypad responded normally.
jasonhouk
Member
I believe we'll want the scanner to hang to drill down that issue. If it happens frequently stop the logging about 1 minute after the hang. Also forgot to advise that I personally, when creating log files, make sure the debug sub-folder is empty.
I'd also format another smaller SD Card and only have that system causing the issues loaded on said card. Just to ensure it's not s failing card.
Houk
Sent from my Moto G (4) using Tapatalk
I'd also format another smaller SD Card and only have that system causing the issues loaded on said card. Just to ensure it's not s failing card.
Houk
Sent from my Moto G (4) using Tapatalk
Will do and have switched cards in the past too...
Re: "Phantom Talkgroup" Issue UPDATE
An update on my "phantom talkgroup" issue. I've now determined that what is showing up in my 436's display and halting trunked NXDN ID Search mode is not talkgroup numbers, but rather RIDs active on talkgroups that I've previously locked out. A quick recap - I am listening to a wide-area trunked NXDN system. In an effort to identify the users of some of the "not so busy" talkgroups, I've locked out the talkgroups that I've already identified. Starting with (I believe) firmware version 1.16.00 (or so), when I have the radio in ID Search mode on this system, the radio hangs up on what displays as a TGID number - no audio, nothing displayed where the RID would normally appear. I had started locking out these "talkgroups", but it was a never-ending battle just to keep the radio operating normally in ID Search mode. My temporary solution was to program all of the TGs I wanted to concentrate on into a department and put the radio in ID Scan mode. This isn't a "fix" IMHO, as I should be able to leave the radio in ID Search mode in order to keep finding new (to me) talkgroups.
This is the same issue that werinshades (above) has been observing.
Hopefully this might help someone come up with a solution to this issue......
Thanks!
An update on my "phantom talkgroup" issue. I've now determined that what is showing up in my 436's display and halting trunked NXDN ID Search mode is not talkgroup numbers, but rather RIDs active on talkgroups that I've previously locked out. A quick recap - I am listening to a wide-area trunked NXDN system. In an effort to identify the users of some of the "not so busy" talkgroups, I've locked out the talkgroups that I've already identified. Starting with (I believe) firmware version 1.16.00 (or so), when I have the radio in ID Search mode on this system, the radio hangs up on what displays as a TGID number - no audio, nothing displayed where the RID would normally appear. I had started locking out these "talkgroups", but it was a never-ending battle just to keep the radio operating normally in ID Search mode. My temporary solution was to program all of the TGs I wanted to concentrate on into a department and put the radio in ID Scan mode. This isn't a "fix" IMHO, as I should be able to leave the radio in ID Search mode in order to keep finding new (to me) talkgroups.
This is the same issue that werinshades (above) has been observing.
Hopefully this might help someone come up with a solution to this issue......
Thanks!
Last edited:
CPU load
IMHO,
CPU load
has to do with internal scanner processes, nothing to do with SD card size or space available.
The scanner is apparently running at it's upper processor limits and that is not something users are at fault for.
Best hope is that the new SDR radio with have more processing power for the future.
It would seem the 436/536 scanners have reached their processing climax with the new feature set.
Only fix for this is yet another firmware edition which cleans up some of the processor hogs.
IMHO,
CPU load
has to do with internal scanner processes, nothing to do with SD card size or space available.
The scanner is apparently running at it's upper processor limits and that is not something users are at fault for.
Best hope is that the new SDR radio with have more processing power for the future.
It would seem the 436/536 scanners have reached their processing climax with the new feature set.
Only fix for this is yet another firmware edition which cleans up some of the processor hogs.
Sluggishness...
This is ONLY effecting SOME of the X36HP scanners, NOT all of them! I am only seeing a couple of complaints of this nature. There is an commonality here somewhere. Possibly a certain run of them? The majority of the scanners updated to this firmware are NOT being effected by this issue of sluggish response due to CPU overload or whatever the heck it is.
False TG/RID...
Yet another issue that seems to only be effecting SOME of the updated scanners. Not a problem for every updated scanner. Again, there has to be a basic commonality here. Its not a complete firmware issue as was the case with a couple of the previous releases.
This is ONLY effecting SOME of the X36HP scanners, NOT all of them! I am only seeing a couple of complaints of this nature. There is an commonality here somewhere. Possibly a certain run of them? The majority of the scanners updated to this firmware are NOT being effected by this issue of sluggish response due to CPU overload or whatever the heck it is.
False TG/RID...
Yet another issue that seems to only be effecting SOME of the updated scanners. Not a problem for every updated scanner. Again, there has to be a basic commonality here. Its not a complete firmware issue as was the case with a couple of the previous releases.
Yes to both...and the reason why Debug logs were submitted. It's like previous firmware versions and complaints of humming and buzzing. Didn't affect my scanner because I didn't use it.
If their is a common denominator with the issues, and I or other uses can correct them without affecting performance or features, we're all ears. Many here don't post for the fear of getting a smack down, but are quietly dealing with it hoping other users post and a solution is suggested.
So...here's what I know. Sluggishness...during transmissions...for the record I have both a newer and older 536 I'm seeing this on.
TGID issue...as Kevin O posted...it appears to be UID's that are falsely identifying themselves as TGID's. It's like the little brother who nags at you to take him with...lol!
As you see, when it boils down to it, you have to have a sense of humor. Reality...this scanner is kicking ***! Can you believe all the sh** we added, all the new sh** I can hear?
So I'm trying to help out..like many of us have in the past. The Uniden engineers will figure it out, as they have in the past with all the other trivial things. I'm sorry it frustrates you as you're trying to make a point with the darkened text. Just ignore my issue as I have ignored many of those that don't bother me. Thanks for chiming in...
The most likely reason most users are not seeing the sluggishness / TGID issues is because it is due to a buggy or badly written bit of firmware code that is only called (or fed a parameter that triggers the bug) under very specific conditions that only a few systems meet for some reason.
k3fs
Member
I am seeing false talk groups and false unit IDs on a DMR OFT system now. I have made several recordings of this system in the past, and have never seen this before. Recent recordings showed about 25-30% of the entries had false TG and false unit ID. No changes made in the system.
I am also seeing issues with NXDN not decoding. I have a decent signal and receive nothing but the digital noise on a couple of frequencies. Unfortunately I may have trouble getting a debug file of this as I have to be at another location to receive them.
Jason, nice to see a beta tester being helpful and not insulting to those reporting issues. The other one that is on here frequently should take note.
I am also seeing issues with NXDN not decoding. I have a decent signal and receive nothing but the digital noise on a couple of frequencies. Unfortunately I may have trouble getting a debug file of this as I have to be at another location to receive them.
Jason, nice to see a beta tester being helpful and not insulting to those reporting issues. The other one that is on here frequently should take note.
- Joined
- Aug 1, 2011
- Messages
- 938
Sluggishness
Since people with this problem report it seems to happen with voice they might consider turning off the “Instant Replay” feature which should reduce the CPU load and see if it helps any with the sluggishness.
I doubt this is the problem but it hopefully will provide more info about what is going on.
Since people with this problem report it seems to happen with voice they might consider turning off the “Instant Replay” feature which should reduce the CPU load and see if it helps any with the sluggishness.
I doubt this is the problem but it hopefully will provide more info about what is going on.
That's what we're trying to figure out by submitting Debug files. I can say this with certainty, this became problematic since Firmware 1.17.00. That was when the NXDN Alias UID feature was added. Prior to that, I still saw these false TGID's which we recently determined were masked UID's who are portraying themselves as TGID's. But...I really like the Alias ID feature and I'm hoping that guiding the engineers in this direction might resolve the issue and improve the Alias ID feature. We shall see, but I'm doing what I can to resolve the issue.
Pretty sure the latest logs identified the problem. Check on the next version.
- Status
