In our wiki, there is a section called 'Can it be decoded?' in our NXDN article;
NXDN - The RadioReference Wiki
I'm not following this well, since I know of very little NXDN in my area. However, I get the impression that the TRX-1 and 2 don't trunktrack NXDN systems very well. If someone would work this section of the wiki, it would be appreciated, as it's pointed to in our wiki based warning template that is used in any NXDN trunk pages
TIA...Mike
That's tricky. If one wants to be technical, in order to properly trunk track an NXDN trunked or DMR trunked system that uses a constant control channel (CON+, NXDN Type-C, etc), the scanner needs to specifically sit on the control channel, pay attention to channel grants, etc so that it can properly switch to the voice channel when there is a voice call. Of course, for those types of system one must already know LCNs and color codes (DMR) or channel numbers and RANs (NXDN).
Along comes Whistler, who just requires you to put ALL active frequencies associated with a given site into the site -- no need for RANs, color codes, LCNs or channel numbers. Sounds great, right? I mean it does seem to work as long as you aren't staring/comparing against something like DSDPlus or a commercial radio. It appears to trunk -- but hey, if it is checking every channel on a site during every scan of a system, certainly it is going to produce some favorable results even if it might not be receiving 100% of the calls.
The Whistlers are great from the standpoint of one only needing to know the frequencies. But if you want to be sure that it's properly trunktracking these types of systems, you really have to be monitoring the CC -- and really have to have color codes, RANs, LCNs and channel number <--> frequency pairings programmed in.
My Uniden always does a better job trunking DMR than my TRX-1. The Uniden actually monitors the control channel. Of course, my TRX-1 does a 100% better job at trunking an NXDN system since there is no NXDN support at all [currently] in Uniden scanners.
Obviously the argument is that Whistler does not do it correctly because they aren't relying upon monitoring of the control channel in order to provide proper trunktracking. I guess there could be various reasons for that. But in the end that is the argument.
To add confusion / difficulty to things, we are required to add ONLY confirmed information about these DMR / NXDN systems in the DB. We aren't supposed to add frequencies that haven't been confirmed active, nor are we supposed to add frequencies for which we do not know color codes, RANs, or LCNs. Given that, the DB often doesn't contain enough information to properly trunk a given DMR / NXDN trunked site. Thus, you'll be missing many / most transmissions in such cases if you are using a Uniden scanner. If, on the other hand, you are using a Whistler TRX and gather all of the frequencies from the trunked license for a given site, you stand a very good chance of reasonably copying that trunked site without having _any_ confirmed information from the DB.
That's why there should really be a strong push (read: encouragement) of savvy RR users to use tools like DSDPlus to properly identify trunked system frequencies, LCNs / Ch# <--> frequency pairings, and RANs and submit that information so that we can make the DB the best that it can be, and the most useful for those people using both Uniden and Whistler TRX scanners.
Mike