Help me help you

[eaf1956]

NAC decoding on Phase 2 calls is incorrect, Phase 1 seems to be decoded properly. This prohibits you from using the site NAC feature if your system has any Phase 2.

It works fine on the Henderson CO, KY phase 2 system

 

[KevinC]

It works fine on the Henderson CO, KY phase 2 system

Cool! It does not properly decode the NAC on the 8 sites I can monitor from my house or the other dozen or so I've monitored across the state (on a Phase 2 call, Phase 1 seems to decode properly).

 

[MStep]

Poor JoeBearcat.

As soon as he posted his offer of help, I knew that within a month that person would have enough work now to last two more careers.

My sympathy to Joe as well. For anyone taking this on, it has to be more a labor of love than anything else. It might be interesting (and I may have missed one or two of his posts) to know a bit more about Joe, within the limits of respect for his privacy. But folks might be wondering how long he has been involved in scanning and associated with Uniden, and a little more "peripheral" information that may give additional insight about someone willing to take on this task.

 

[JoeBearcat]

NAC decoding on Phase 2 calls is incorrect, Phase 1 seems to be decoded properly. This prohibits you from using the site NAC feature if your system has any Phase 2.

Only the display is erred. The NAC operation works fine.

I will confirm this later, but I'm pretty sure my local Phase II system has NAC programmed in.

 

[JoeBearcat]

I would like to see a favorites list hold feature. The only way to make this happen now is to have one favorites list per system, and use system hold. I have some favorite lists that have multiple systems, and would like to be able to hold on those lists.

Assuming you have too many FLs enabled to make use of FL Quick Keys.

I added your request to the list.

 

[KevinC]

Only the display is erred. The NAC operation works fine.

You are correct, but if you do a NAC search won't it display the incorrect one?

 

[JoeBearcat]

@JoeBearcat - My SDS200 never shows a RSSI value when monitoring a DMR Hytera XPT system (during a transmission). The decode works fine as I can hear the users and see talk groups displayed on the screen. But, the RSSI field shows nothing during the transmissions. Please note my SDS200 works fine and displays the RSSI value for P25, NXDN, and other DMR systems. Is there something odd about XPT transmissions?

I added that to the reported bug list. Thank you.

 

[JoeBearcat]

Poor JoeBearcat.

As soon as he posted his offer of help, I knew that within a month that person would have enough work now to last two more careers.

Job security?

 

[JoeBearcat]

I don't have a picture but screen shot this one. Left side where the box is. If you put Text White and Blue Background the white square pops up instead blue background. Here is the screen shot I took from Uniden SDS100 & SDS200 Color Schemes

View attachment 98522

That looks like blue on white which would be the "normal reversed" colors. If you want a white on blue scheme, program it reversed (blue on white) in your profile.

 

[JoeBearcat]

You are correct, but if you do a NAC search won't it display the incorrect one?

It might. That bug has been on the list for close to a year. There was not any way to really address it until recently.

I do consider it a major bug and hope it is one of the first to be squashed.

 

[KevinC]

It might. That bug has been on the list for close to a year. There was not any way to really address it until recently.

I do consider it a major bug and hope it is one of the first to be squashed.

Thanks.

 

[radiopro52]

Someone suggested a while ago that the scanner show the date and time of a recording when you replay it instead of the current time. I'd like to see this implemented at some point.

 

[JoeBearcat]

Someone suggested a while ago that the scanner show the date and time of a recording when you replay it instead of the current time. I'd like to see this implemented at some point.

Already on the list of feature requests. UPMan actually had this one on the list.

 

[JoeBearcat]

You are correct, but if you do a NAC search won't it display the incorrect one?

I wanted to confirm this before posting, but ONLY the NAC SEARCH feature on voice channels is affected by this bug.

The programmed NAC works correctly. (at least on my local Phase II system)

If you want to program the correct NAC, and it is not in the RR database, hold on the control channel (CH FREQ CH) and it will display the correct one. You can then program it in your scanner and submit it to RR.

 

[GTR8000]

I wanted to confirm this before posting, but ONLY the NAC SEARCH feature on voice channels is affected by this bug.

The programmed NAC works correctly. (at least on my local Phase II system)

If you want to program the correct NAC, and it is not in the RR database, hold on the control channel (CH FREQ CH) and it will display the correct one. You can then program it in your scanner and submit it to RR.

That's all fine and well, however if someone with good intention has their SDS in NAC Search mode and catches the incorrect TDMA traffic channel NAC, and submits that to us...guess what? And no, that it not a hypothetical, I have received submissions based on that exact scenario.

If the scanner is going to display a NAC, then it ought to be the correct one; a workaround such as "hold on the FDMA control channel to find the real NAC" is not a solution, a firmware fix is.

Still haven't heard from you regarding the TDMA traffic channel priority issue. I have confirmed with both a 536 and SDS200 that neither series responds to traffic channel data announcing priority talkgroups; they are either not decoding or ignoring those grant messages, and remain on the current transmission even when all parameters on both the system and scanner side are setup correctly.

 

[kmartin]

Noted.

Well Joe. I guess you will be working some overtime after opening that can of worms ! LOL

 

[bravo14]

I wanted to confirm this before posting, but ONLY the NAC SEARCH feature on voice channels is affected by this bug.

The programmed NAC works correctly. (at least on my local Phase II system)

If you want to program the correct NAC, and it is not in the RR database, hold on the control channel (CH FREQ CH) and it will display the correct one. You can then program it in your scanner and submit it to RR.

There is a new system P25 Pll being put together and so far the NAC is correct and I haven't missed any radio tests. In a few weeks I'll listen more make sure it is not missing any traffic when its more active.

 

[JoeBearcat]

Still haven't heard from you regarding the TDMA traffic channel priority issue. I have confirmed with both a 536 and SDS200 that neither series responds to traffic channel data announcing priority talkgroups; they are either not decoding or ignoring those grant messages, and remain on the current transmission even when all parameters on both the system and scanner side are setup correctly.

That is not a hardware issue, and hardware issues are what is currently being worked on. I have a year+ worth of issues to address. They are not all going to fixed at once. Elsewhere I stated what the priorities are. Hardware issues are first because those are the most difficult to address 'in the field' and I want to make sure as FEW new units ship with that issue as possible. Software and firmware are both a matter of "download the fix".

A display bug that does not affect operation, however inconvenient to you, is not as important as an issue that causes a unit to not function correctly or at all. I still have the display issue to address as well as follow-up on the hum issue and a couple others. While the display issue is relatively rare, it's something that needs to take priority since it is a hardware issue.

The incorrect NAC display is important, and I expect will be addressed - just not today. Priority issue? Same deal. Although I believe preemptive priority on trunked systems was never an advertised spec. I think UPMan commented on this previously. If that is the case it is relegated to the realm of "feature request" which is the lowest priority. So yes, those will not receive replies for some time. And once a feature request is on the list, there is no need to add it again.

 

[GTR8000]

Although I believe preemptive priority on trunked systems was never an advertised spec. I think UPMan commented on this previously. If that is the case it is relegated to the realm of "feature request" which is the lowest priority. So yes, those will not receive replies for some time. And once a feature request is on the list, there is no need to add it again.

Please tell me that you're joking regarding priority being a "feature request". As you well know, the scanners have a Priority ID Scan option for trunked systems, including P25. That feature does not function correctly with P25 TDMA talkgroups. That is a bug, not a "feature request", nor did you mention anything of the sort in your original reply to me.

Help me help you

Last evening I started to look for threads that had pending questions/issues. It became quickly apparent this was a massive task that could take weeks to complete, so I am asking for some help to identify threads that have pending questions/issues. For now, I would like to focus on issues such...

forums.radioreference.com

And since when is this thread about hardware issues only? Your very first post asked for "basic functionality" issues.

For now, I would like to focus on issues such as basic functionality of Uniden scanners (firmware update issues and major bugs), and would like to avoid (for now) service issues.

 

[JoeBearcat]

Please tell me that you're joking regarding priority being a "feature request". As you well know, the scanners have a Priority ID Scan option for trunked systems, including P25. That feature does not function correctly with P25 TDMA talkgroups. That is a bug, not a "feature request", nor did you mention anything of the sort in your original reply to me.

Help me help you

Last evening I started to look for threads that had pending questions/issues. It became quickly apparent this was a massive task that could take weeks to complete, so I am asking for some help to identify threads that have pending questions/issues. For now, I would like to focus on issues such...

forums.radioreference.com

And since when is this thread about hardware issues only? Your very first post asked for "basic functionality" issues.

For now, I would like to focus on issues such as basic functionality of Uniden scanners (firmware update issues and major bugs), and would like to avoid (for now) service issues.

Anything that is not a current feature, or advertised feature, would be a feature request.

Priority ID SCAN might not work as you believe it does. What that means is that when scanning the scanner will favor priority TGs over others. I'm going by memory of what UPMan said on this, but I believe I stated that correctly. This could have been changed at some point, but I will find out for certain.

The manual is vague on this and does not reference any priority for P25 trunk systems. For trunked systems it says it works as I described above. From the manual: "Priority is checked in between transmissions, when the scanner is receiving the control channel, and during the channel delay period."

For Motorola systems (Type I/II) it does mention preemptive priority. But again, makes no reference to P25 let alone Phase II.

As such, not being preemptive priority is not a bug if I am correct in my description.

While I generally agree with you preemptive priority is preferred, I cannot arbitrarily change the specs based on the way we believe it should be vs the way it was designed.

Yes, I asked for all issues. I also stated that there would be a priority as I stated. I can gather all classes at once. I cannot task the engineers with fixing all the issues at once. Documentation is much faster than resolution.

Your quote is accurate. In the class of feature requests, it would be lower. If it is a bug (and I don't believe that to be the case, but I will find out) then it may be lower than other bugs.

Link to earlier in this thread where priorities are addressed (53 posts ago):

Help me help you

No "major" firmware updates in the near future for the SDS series? That depends how you define "near future". I am in the process of documenting things that need addressed currently. Those will need approved, fixed, tested, and then released.

forums.radioreference.com

And yes, that was clarified from your quote. More distinctions/classes were added.

If I find that preemptive priority was the design goal, the issue will move up to major bugs, but will still be lower on that list, but is the third area to be addressed, not the first where we currently are.

I have already reached out to the management team and others on this question. When it is clarified, I will post the info.