Why does Whistler allow you to program DMR/NXDN trunking systems?

[trunker]

Why does Whistler allow you to program MotoTRBO and NexEdge trunking systems?
So then wouldn't be the same as programing the freqs as conventional with digital squelch?
Does this just try to make us more comfortable about the fact Whisler can't trunktrack these systems?

TRX-1 - The RadioReference Wiki​

On the above Wiki page it states the following:
"NOTE: GRE / RS / Whistler scanners will not trunk track this mode; they will decode the mode, show TG and slot information"
"Note that Whistler scanners cannot trunktrack MOTOTRBO systems. Whistler never bought the licenses, which is why the upgrades are free. The best these scanners can do is to decode the audio. This may be sufficient on systems that aren't too busy, but for busier systems, this is a serious limitation."

 

[rescuecomm]

Perhaps this scanner is aimed at railroad Nexedge users.

 

[lamarrsy]

I listen to a handful of specific TGs on a DMR tier3 trunking system (2 sites, 5 freqs), and although the Whistlers are not supposed to be good performers on tier3 dmr, I must admit that my WS1080 performs as good as my Uniden BCD436hp and BCD325P2.

 

[lamarrsy]

…And although they cannot “trunk track” per se, if the tier3 dmr system you intend to use is not very trafic intensive, the scanner will have no difficulty tracking specific Talkgroups.

This is my situation and can confirm that it is 99% efficient in tracking the dozen TG I have.

 

[buddrousa]

What @lamarrsy said is correct but you look at a system with 20 usable slots 100 user talkgroups in a town like Memphis or Nashville and the Whistlers not following Control Channel Data only Scanning the Voice Channels they will not work well at all.

 

[lamarrsy]

Yep, very good point @buddrousa

 

[Ubbe]

So then wouldn't be the same as programing the freqs as conventional with digital squelch?

Yes, if it actually where working as the wiki suggests. But it is not. It scans the voice channels of trunked systems and when it finds a TG that you have programmed to be monitored it decodes its audio. When, and if, the call switch to another voice frequency it scans the channels until it has a squelch detect and then if it has a data signal to see if it is a voice call and then if it is the same TG that you where monitoring. As soon as one of the signals do not match it immediately starts to scan to other voice frequencies in a hunt for that TG until the delay timer runs out. Then it starts to hunt for any TG that you have programmed until the dwell timer runs out and it goes to next site or system.

It's a system that works well for sites with fewer channels or a site with many voice channels but are loaded very lightly with calls. I would say that the max are when a site have 4-5 simultaneous calls at the same time. Some systems use a trunk type that makes users go to the control channel as soon as they release their PTT and those are the worst for Whistler scanners. But many systems keep the whole call on one frequency and then it's not much different than using a Uniden trunktrack scanner, if Uniden can make their digital decode more reliable.

/Ubbe

 

[trunker]

Yes, if it actually where working as the wiki suggests. But it is not. It scans the voice channels of trunked systems and when it finds a TG that you have programmed to be monitored it decodes its audio. When, and if, the call switch to another voice frequency it scans the channels until it has a squelch detect and then if it has a data signal to see if it is a voice call and then if it is the same TG that you where monitoring. As soon as one of the signals do not match it immediately starts to scan to other voice frequencies in a hunt for that TG until the delay timer runs out. Then it starts to hunt for any TG that you have programmed until the dwell timer runs out and it goes to next site or system.

It's a system that works well for sites with fewer channels or a site with many voice channels but are loaded very lightly with calls. I would say that the max are when a site have 4-5 simultaneous calls at the same time. Some systems use a trunk type that makes users go to the control channel as soon as they release their PTT and those are the worst for Whistler scanners. But many systems keep the whole call on one frequency and then it's not much different than using a Uniden trunktrack scanner, if Uniden can make their digital decode more reliable.

/Ubbe

That helps to understand better. So they can trunktrack as long as the system isn't too busy.
But I guess they can't put that in a sales brochure.
And yes, I too like the way WS1098 grabs digital.

 

[IrvingtonVFD43]

Trial and error.

I have a couple Mototrbo Capacity Plus and a NXDN trunked system in my area. They are not terribly busy. It has taken some time to tweek the delay setting on my TRX-2 to get the desired results. It's not perfect, but it is suitable for my needs.

Anybody remember back in the 90's when GE/Ericsson released EDACS and how much of a pain the the butt it was to try to monitor one of those systems with a conventional scanner???

 

[eaf1956]

Trial and error.

I have a couple Mototrbo Capacity Plus and a NXDN trunked system in my area. They are not terribly busy. It has taken some time to tweek the delay setting on my TRX-2 to get the desired results. It's not perfect, but it is suitable for my needs.

Anybody remember back in the 90's when GE/Ericsson released EDACS and how much of a pain the the butt it was to try to monitor one of those systems with a conventional scanner???

Heck I remember before Uniden released the 1st Truck Tracker listening to a Trunk system by locking out control channels every night as they changed all the time.

 

[IC-R20]

That helps to understand better. So they can trunktrack as long as the system isn't too busy.
But I guess they can't put that in a sales brochure.
And yes, I too like the way WS1098 grabs digital.

It scans like it would for an LTR system basics. Listening in on all channels for the talkgroup data then will either play it if you’re scanning for everything or only pipe through the audio when it detects the talkgroup your held on or is programmed into the database if you don’t have a wildcard enabled.

You can manually program it without the control channel if you want, but the reason it does it on its own is that’s just how it’s written in the database. I personally leave it on in the rare occasion that voice traffic gets piped thru the CC frequency which happens sometimes, especially on smaller systems with only a few channels.

The local NXDN multisite node by me has only 2 channels so when the 1 voice channel is active it’s not uncommon to hear another talk group at the same time thru the frequency being used for CC.