RRDB-side fix for certain NXDN systems not importing to Sentinel

[Mikek]

Hello Admins!

About a year ago, I raised an issue regarding multi-site NXDN systems that did not correctly import into my SDS100 via Sentinel.
At that time, a fellow user offered up not only other systems with the same issue, but a very good explanation of why, and how the issue could be remediated. You can see that in the linked thread.

The short version of the issue is that frequencies with LCNs higher than 1023 are rejected by Uniden's import API, and thus, do not show up in Sentinel. This results in incomplete site and frequency data for NXDN systems that use Dynamic Addressing (With LCNs >1023).

To date there has been no movement from the Uniden side. I would like to see if this is something that the RRDB team can address instead. The fix that @mwjones offered in this post might be a great starting point. It's worth noting that these systems do not use LCN, so an LCN of "0" works just fine. Any chance RR can 'feed' Uniden the LCN of "0" in place of anything >1023?

Thank you! It would be great to get this working!

 

[wa8pyr]

Hello Admins!

About a year ago, I raised an issue regarding multi-site NXDN systems that did not correctly import into my SDS100 via Sentinel.
At that time, a fellow user offered up not only other systems with the same issue, but a very good explanation of why, and how the issue could be remediated. You can see that in the linked thread.

The short version of the issue is that frequencies with LCNs higher than 1023 are rejected by Uniden's import API, and thus, do not show up in Sentinel. This results in incomplete site and frequency data for NXDN systems that use Dynamic Addressing (With LCNs >1023).

To date there has been no movement from the Uniden side. I would like to see if this is something that the RRDB team can address instead. The fix that @mwjones offered in this post might be a great starting point. It's worth noting that these systems do not use LCN, so an LCN of "0" works just fine. Any chance RR can 'feed' Uniden the LCN of "0" in place of anything >1023?

Thank you! It would be great to get this working!

I'll bring this to the attention of the back-end maintenance people.

However, don't get your hopes up. Official RR policy is that if there's an issue with someone's software, (be it Uniden, Butel or whoever), it's their problem to fix and that we do not make "custom" fixes to the database. This is because if they do then fix the problem at the software end, we could end up with an even greater problem, this time on the database side, requiring a lot of time to fix.

You might try another software product to see if that takes care of the problem.

Tom WA8PYR

 

[GTR8000]

Yeah, so we have a rather large NXDN DFA system in upstate NY, and because of this issue we (the NYS admins) have purposely omitted the actual CH ID values out of courtesy to those downloading the system to a Uniden scanner. We've set all CH ID values to 0, which allows the scanners to properly track the system.

That said, it's a lousy workaround. While the CH ID values are largely superfluous given the inherent nature of a DFA system, I feel that the actual CH ID values should be cataloged in the RRDB for the sake of keeping accurate records. In the end, in spite of the RR policy we politely ignored for the benefit of our members, this is absolutely a Uniden issue and one that was brought to their attention a very long time ago.

Sadly, Uniden is a rudderless ship since Paul's passing, with nothing but empty promises and half-assed firmware updates that don't address most of the real and lingering issues. "Help me help you" thread was started FOUR YEARS AGO and there has been very little to show for it since. Joe hasn't logged into the forum in nearly two months, and the then-new Uniden America president Kip Sullivan made a single hit-and-run "We still care!" post TWO YEARS AGO and hasn't been seen or heard from around here since. Pathetic.

I suspect my post might vanish for being too blunt and outspoken about this crap as a dbadmin, but I'm just spitting facts.

 

[ka3jjz]

It's not a pretty solution but such TGs can be recorded in the wiki, as we have no such restrictions there

Just my 2 pfennig

Mike