NXDN trunking issues

Status
Not open for further replies.

W4KRR

Member
Premium Subscriber
Joined
Apr 1, 2001
Messages
3,434
Location
Coconut Creek
Anyone else having issues with the TRX-1 tracking NXDN conversations? I find that I'm missing replies when paused on a talkgroup, and sometimes whole conversations, when compared to the same traffic on the DSD+ program.

I started wondering how the TRX scanners work on NXDN trunked systems. The NXDN control channel sends out data that tells subscriber radios to, for example, switch to channel 217. In order for the DSD+ program to work, you need to tell it what frequency channel 217 is. The actual frequency isn't sent out on the control channel. For the TRX scanners, you just enter the frequencies; there's no provision to enter what channel number goes with which frequency. So can I assume that the TRX scanners work on NXDN trunked systems just like they work on DMR systems, that they just scan all frequencies looking for channel activity?

I will say that the NXDN audio quality on the TRX scanner is superior to that of DSD+, but for trunk tracking and following specific talkgroups, the DSD+ software program beats the TRX-1 easily. :(
 
Last edited:

KC1UA

Scan New England Janitor/Maintenance
Database Admin
Joined
Oct 27, 2002
Messages
2,048
Location
Marstons Mills, Cape Cod, Massachusetts
Hi Ken,

Ditto. I'm scanning 1 NXDN system here and comparing it to DSD+. Well, other than the great audio quality, there is no comparison. DSD+ is blowing its doors off.

I have conversations dropping in mid-stream, picking up in mid-stream, being missed altogether, and dropping when the programmed delay should be picking up the next transmission.

This is a 4 frequency system. I even locked out the remaining 28 unprogrammed frequencies for the site. I'm using a talkgroup wildcard.
 

Oakland_Tower

Member
Premium Subscriber
Joined
Nov 28, 2009
Messages
495
Location
S.F. Bay Area
Same thing here in the S.F. Bay Area. I haven't heard both sides of a conversation yet. I hear more when locked on the Wildcard, but still only one side. I"m hoping future updates will correct this.
 

AggieCon

Member
Premium Subscriber
Joined
Nov 25, 2015
Messages
1,448
Location
Texas
If you have only digital objects on the scanlist, try lowering the squelch all the way and see if that helps. The delay might actually be hurting you too. I'd set it to maybe .3 sec.

Try it for awhile with just one (ideally quite active) frequency in the site details window. Leave the squelch all the way down. With it like that, are you hearing the entire broadcasts? Basically, it's a test to see if the scanner is bogging down checking too many frequencies with a long dwell time.

Yea, having the over the air readout on DSD+ is really nice too...

that they just scan all frequencies looking for channel activity

I bet that's how they have it. I'm pretty sure DMR is that way too, still. They are a little vague in admitting it. So basically, it doesn't support trunking, just programming it as trunked, which allows you to at least simply naming and sorting of talkgroups (but works essentially like a bunch of conventional objects with the proper talkgroups).
 

W4KRR

Member
Premium Subscriber
Joined
Apr 1, 2001
Messages
3,434
Location
Coconut Creek
I have 7 sites programmed. So I tried locking out all but the closest site, but that didn't seem to help. The system I'm trying to monitor is very busy, so I would expect the scanner to be almost non stop with activity, but not so, even though I have a wildcard programmed in.
 

AggieCon

Member
Premium Subscriber
Joined
Nov 25, 2015
Messages
1,448
Location
Texas
Even just on one site, it might still be in too long of a cycle. What happens if you add the same frequencies as conventional objects?
 

W4KRR

Member
Premium Subscriber
Joined
Apr 1, 2001
Messages
3,434
Location
Coconut Creek
Even just on one site, it might still be in too long of a cycle. What happens if you add the same frequencies as conventional objects?

Do you mean scanning the site frequencies as conventional objects? Not sure exactly what you mean.

I am trying to adjust the delay times for the talkgroups, as well as the system Dwell time to a higher number to see if I can get better results. For a minute I thought I had an improvement with a Dwell time of 1.5 seconds, but no. I also tried a Dwell time of 0.3 seconds, which was worse.
 

AggieCon

Member
Premium Subscriber
Joined
Nov 25, 2015
Messages
1,448
Location
Texas
I do not think the scanner trunk tracks NXDN. It's just rotating through the frequencies looking for a hit.

Basically, the benefit of programming as trunked is that you can lockout or favorite talkgroups all at once. Otherwise, if it was a conventional object, you would have to make a new entry for each system frequency and each individual talkgroup.

If you are running a wildcard only, there should be little difference between scanning the NXDN system frequencies as conventional vs trunked.

For delay, I like 0.3 sec. For dwell, that's probably too short for the digital decoder to figure out what's up.

To program as conventional, just add each site frequency into the conventional frequency tab. Set the Mode to NXDN, RAN any, and the talkgroup ID to 0.

You can use Digital Frequency Quick Import to quickly add the frequencies as conventional objects.
 

W4KRR

Member
Premium Subscriber
Joined
Apr 1, 2001
Messages
3,434
Location
Coconut Creek
AggieCon, when you say 0.3 sec for delay, you're talking about the talkgroup delay, correct?

I programmed some frequencies as conventional channels with one common talkgroup of interest. It seems to perform a little bit better than programming as a trunked system, but I still see some signal dropouts and missed replies. The signal strength meter would seem to show a signal plenty strong enough for a good decode.

I hope that this is something that can be addressed with a firmware upgrade.
 

AggieCon

Member
Premium Subscriber
Joined
Nov 25, 2015
Messages
1,448
Location
Texas
Correct regarding the delay.

What's the black box S/T doing during this?

Keep in mind, when the scanner has to search for a talkgroup, the steps are somewhere along these lines ->


  • Scanner rapidly sampling the frequencies in the scanlist
  • Frequency breaks squelch. Scanner holds for at least the delay time
  • Analog RF signal demodulated
  • If scanner set manually to digital or if determined to be digital, demodulated signal goes to digital decoder
  • The decoder sends data samples to the processor, which determine among other things, which talkgroup is active
  • Voice data is decoded into analog audio by the vocoder
The deal is that the talkgroup is not constantly broadcast--as say a privacy tone is--so the scanner has to wait for the next talkgroup message to know what the call is. I assume the talkgroup is announced ~5 times a second on these NXDN (but this is just a guess). So if the scanner misses the first announcement of the talkgroup for whatever reason, you'll have to wait for the scanner to hopefully read the next one. By the time the squelch breaks and the decoder catches the talkgroup, the call could be well in progress.


I like the delay time of .3 sec because it keeps the channel live if the scanner has a hiccup, yet it drops it in time to (hopefully) hear the next call of the conversation on a different frequency.
 

W4KRR

Member
Premium Subscriber
Joined
Apr 1, 2001
Messages
3,434
Location
Coconut Creek
Correct regarding the delay.

What's the black box S/T doing during this?

When scanning as trunked, rapidly blinking S; when on a voice call, rapidly blinking T, with some alternating with a blinking S. When scanning as conventional channels, no S, but rapidly blinking T during voice call.
 

AggieCon

Member
Premium Subscriber
Joined
Nov 25, 2015
Messages
1,448
Location
Texas
You want the black box T to be as solid as possible during a call, and, certainly, seeing the S during a call isn't good. What's your squelch set at? What antenna? Also, what's the call sign?
 
Status
Not open for further replies.
Top