Clarification for NXDN decoding

Status
Not open for further replies.

ka3jjz

Wiki Admin Emeritus
Joined
Jul 22, 2002
Messages
25,361
Location
Bowie, Md.
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
 

mtindor

OH/WV DB Admin
Database Admin
Joined
Dec 5, 2006
Messages
10,368
Location
Carroll Co OH / EN90LN
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
 

troymail

Silent Key
Joined
Dec 19, 2002
Messages
9,981
Location
Supply (Lockwood Inlet area), NC
It has been stated - based on user observation - that the Whistlers do not use the control channel on NXDN trunked systems. There are some pros and cons of that which I won't go into here.

Having said that - this does not mean that the Whistlers won't "trunk" (bad wording on the wiki) NXDN systems and you should/must program them as conventional.

For some NXDN trunk systems, programming them in a TRX as a trunk system works just fine - for others, not so much. It will depend on various factors - number of sites, number of frequencies, etc.

For larger systems (more frequencies and/or multiple sites), not using the control channel does appear to affect the performance. But this would then mean that the radio is simply scanning the frequencies in your programming - which, to some degree is the same as it would do if those same frequencies are programmed as conventional objects.

There is a bit more processing that occurs with trunked systems - and maybe a bit more with NXDN - talkgroups, potentially RAN values, and for NXDN 4800 vs. 9600 vs. Auto. However, if you were to apply all of these settings in conventional objects to include talkgroups, you'd have to create a conventional object for talkgroup that you program for every frequency which ultimately would perform even worse. Simple example: 10 talkgroups and 3 site frequencies = 30 conventional objects; if 3 sites (or 30 talkgroups) then 90 conventional objects.

As with many things we deal with using scanners, each user's situation is going to be different. There is rarely a "one size fits all" solution for every user in every location on every system.

The best you can do is present/offer the options with some pros and cons and allow the user to decide which works best in their situation. The threads referenced on the wiki were one person's opinion (at the time) and probably not taking into account all of the potential attributes that get applied to trunk systems.
 
Last edited:
D

DaveNF2G

Guest
Given the above discussion, the wording "the TRX-1 and 2 don't trunktrack NXDN systems very well" should be edited to read "the TRX-1 and 2 don't trunktrack NXDN systems."
 

ka3jjz

Wiki Admin Emeritus
Joined
Jul 22, 2002
Messages
25,361
Location
Bowie, Md.
To refine this a bit;

the TRX-1 and 2 don't trunktrack NXDN systems using the control channel in all cases.

If there are threads that better describe the issues, then let's have their links. They can be added to the wiki to let folks decide their own course of action. This is a tricky business; we should try to be as clear as possible, given that NXDN trunking is still iffy at best, at least from the prior comments

Mike
 

slicerwizard

Member
Joined
Sep 19, 2002
Messages
7,643
Location
Toronto, Ontario
To refine this a bit;

the TRX-1 and 2 don't trunktrack NXDN systems using the control channel in all cases.

If there are threads that better describe the issues, then let's have their links. They can be added to the wiki to let folks decide their own course of action. This is a tricky business; we should try to be as clear as possible, given that NXDN trunking is still iffy at best, at least from the prior comments

Mike
I don't follow. Where's the confusion? They always scan just the voice channels, just like some old RS scanner(s) did with Moto 3600 bps trunking systems.
 
D

DaveNF2G

Guest
"No scanner receives" is poor wording anyway.

All scanners receive transmissions on the frequencies they were designed to cover, regardless of modulation type or protocol.

Scanners demodulate AM, FM, NFM and SNFM depending on their capabilities.

Some scanners decode digital protocols.

Some scanners interpret certain kinds of trunking control data to follow talkgroup traffic. We call this capability "trunktracking".

No scanners decrypt encrypted or scrambled transmissions. This would be illegal anywhere on Earth (regardless of any opinions to the contrary.)

If we were to use the terminology correctly, then we would say that the Whistler TRX-1 and 2 can decode NXDN within the frequency range that they can receive, but they do not interpret the control data so they cannot trunktrack NXDN based trunked systems.
 

troymail

Silent Key
Joined
Dec 19, 2002
Messages
9,981
Location
Supply (Lockwood Inlet area), NC
If we were to use the terminology correctly, then we would say that the Whistler TRX-1 and 2 can decode NXDN within the frequency range that they can receive, but they do not interpret the control data so they cannot trunktrack NXDN based trunked systems.

Pretty good Dave -- I think you're getting close....but this last line still needs work.... it could lead people to believe that you cannot program a NXDN trunk system "as a trunk system" on the TRX - which is incorrect.

Therefore:

The Whistler TRX-1 and 2 can be programmed to monitor both conventional and trunked NXDN systems. However, they do not use the NXDN control channel to monitor NXDN trunked systems.
 

Project25_MASTR

Millennial Graying OBT Guy
Joined
Jun 16, 2013
Messages
4,164
Location
Texas
It has been stated - based on user observation - that the Whistlers do not use the control channel on NXDN trunked systems.

Not necessarily user observations. Whistler states that information in the TRX user manuals. They even state because of that, it is best to only monitor the site of interest and not multiple sites as the added scan times may result in missed traffic.

However regardless of whether or not the control channel is being , monitored or not, the scanner will unmute when the first talk group is discovered that meets the scan parameters and unless a priority is set any other activity at the same time will not be heard. This is the same across subscribers and scanners.

Sent from my SM-T713 using Tapatalk
 

troymail

Silent Key
Joined
Dec 19, 2002
Messages
9,981
Location
Supply (Lockwood Inlet area), NC
Not necessarily user observations. Whistler states that information in the TRX user manuals. They even state because of that, it is best to only monitor the site of interest and not multiple sites as the added scan times may result in missed traffic.
Thanks - I was not aware of that statement in the Whistler docs (can't find it). However, I do agree and always tell folks NOT to try and import/program/monitor more than the closest site under routine conditions. Of course, this guidance is different from monitoring a P25 or Motorola system.
However regardless of whether or not the control channel is being , monitored or not, the scanner will unmute when the first talk group is discovered that meets the scan parameters and unless a priority is set any other activity at the same time will not be heard. This is the same across subscribers and scanners.
If I understand the comment, I'd say this is common across the board (scanners, systems, talkgroups, etc.) - which is what I think you are saying.
 
Last edited:

ka3jjz

Wiki Admin Emeritus
Joined
Jul 22, 2002
Messages
25,361
Location
Bowie, Md.
Perhaps something like this will do (taking Troymail's suggestion, and the underlined text is mine);

The Whistler TRX-1 and 2 can be programmed to monitor both conventional and trunked NXDN systems. However, because these scanners do not monitor the NXDN control channel, trunking may not function correctly on all systems
 

ka3jjz

Wiki Admin Emeritus
Joined
Jul 22, 2002
Messages
25,361
Location
Bowie, Md.
What 'last part'? We know from the reports on the forum that programming a NXDN trunk doesn't always work, for the reasons that have already been discussed. For someone that is new, talking about channel grants, RANs and so on is just going to confuse them more

Mike
 
D

DaveNF2G

Guest
"Trunking does not function correctly..."

The situation with the Whistler scanners seems very similar to the original PRO-92 (Radio Shack) scanners and how they tracked Motorola systems. They used the subaudible data on the voice channels, which led to somewhat acceptable "tracking" that could be interrupted by traffic on other channels. Locking onto a talkgroup was problematic and only worked sometimes.

It wasn't until the A/B models (the letter indicated place of manufacture IIRC) that the PRO-92 became a true "trunktracker" for Motorola systems.

I believe the PRO-92 was RS/GRE's first LTR tracking scanner, hence the attempt to use subaudible data for more than one system type. (Hammer, Nail)
 

garys

Member
Premium Subscriber
Joined
Jun 13, 2002
Messages
6,069
Someone should also note the the RRDB is not well structured to contain the Channel Number data for NXDN systems. For DSD+ and any future scanners that will trunk track NXDN properly, that's vital. This might not be the right place for that conversation, but I want to mention it nonetheless.
 

mtindor

OH/WV DB Admin
Database Admin
Joined
Dec 5, 2006
Messages
10,368
Location
Carroll Co OH / EN90LN
Someone should also note the the RRDB is not well structured to contain the Channel Number data for NXDN systems. For DSD+ and any future scanners that will trunk track NXDN properly, that's vital. This might not be the right place for that conversation, but I want to mention it nonetheless.

Yes, it actually is -- but you have to know to click on the site to see the channel numbers.

You can't see NXDN channel numbers from the System level:

https://www.radioreference.com/apps/db/?sid=8212

But you can see the channel numbers from the site level:

https://www.radioreference.com/apps/db/?siteId=24771

So, in my example above, if you click on the first one, and then select a site (such as Canton), you'll then see the channel numbers.

Mike
 

buddrousa

Member
Premium Subscriber
Joined
Jan 5, 2003
Messages
11,224
Location
Retired 40 Year Firefighter NW Tenn
Perhaps something like this will do (taking Troymail's suggestion, and the underlined text is mine);

The Whistler TRX-1 and 2 can be programmed to monitor both conventional and trunked NXDN systems. However, because these scanners do not monitor the NXDN control channel, trunking may not function correctly on all systems

This is the most true statement about the TRX's. This has even been stated by the Whistler Reps in the forum this is why you have to enter all voice channels on a NXDN trunked system so you do not miss any voice traffic.
 
Status
Not open for further replies.
Top