• Effective immediately we will be deleting, without notice, any negative threads or posts that deal with the use of encryption and streaming of scanner audio.

    We've noticed a huge increase in rants and negative posts that revolve around agencies going to encryption due to the broadcasting of scanner audio on the internet. It's now worn out and continues to be the same recycled rants. These rants hijack the threads and derail the conversation. They no longer have a place anywhere on this forum other than in the designated threads in the Rants forum in the Tavern.

    If you violate these guidelines your post will be deleted without notice and an infraction will be issued. We are not against discussion of this issue. You just need to do it in the right place. For example:
    https://forums.radioreference.com/rants/224104-official-thread-live-audio-feeds-scanners-wait-encryption.html

How to improve NXDN scanning

Status
Not open for further replies.

AggieCon

Member
Premium Subscriber
Joined
Nov 25, 2015
Messages
1,444
Location
Texas
#1
Howdy,

When scanning NXDN, I strongly suggest scanning all NXDN systems as conventional frequencies. Yes, even if it is a trunked system, import all of the trunked frequencies to EZ Scan as conventional objects.

Unless there is a compelling reason to add NXDN as a trunked system, I would not use NXDN as a trunked system. Compelling reasons might include the following:

  • You want to listen to only certain talkgroups on a trunked system (e.g. you want to lockout two talkgroups but listen to three).
  • However, if you are interested in just one talkgroup on the system, you should still program as conventional.
I think the active control channel is slowing down the scanner substantially and confusing it when NXDN is programmed as trunked objects. If you must program NXDN as trunked, I think you will have better results if you remove the active control channel from the site frequency list.

The TRX does not trunk track. Programming NXDN as trunked objects is useful only if you are dealing with locking out a bunch of talkgroups or doing other talkgroup specific tasks (where a large number of talkgroups are being dealth with). Otherwise, there is no benefit to programming as trunked; in fact, programming NXDN as trunked is likely hurting your scanner's performance. It is also more complicated and slower to program.

You do not have to program trunked NXDN systems as trunked to receive them. Trunked systems will be received when programmed as conventional objects.

I encourage you to program all NXDN as conventional frequencies with "any" RAN and a wildcard for the talkgroup.

Additionally, I have a website that will allow you to accomplish this quickly: Digital Frequency Quick Import

I write this so that hopefully people can use their scanners more effectively. I don't have any product or marketing interest, which stakeholders in certain entities may have. My goal is to make scanning easier and more accessible. I think the tactic I've explained above will help many of you.
 
Last edited:
Joined
Mar 6, 2015
Messages
122
#2
Howdy,

When scanning NXDN, I strongly suggest scanning all NXDN systems as conventional frequencies. Yes, even if it is a trunked system, import all of the trunked frequencies to EZ Scan as conventional objects.

Unless there is a compelling reason to add NXDN as a trunked system, I would not use NXDN as a trunked system. Compelling reasons might include the following:

  • You want to listen to only certain talkgroups on a trunked system (e.g. you want to lockout two talkgroups but listen to three).
  • However, if you are interested in just one talkgroup on the system, you should still program as conventional.
I think the active control channel is slowing down the scanner substantially and confusing it when NXDN is programmed as trunked objects. If you must program NXDN as trunked, I think you will have better results if you remove the active control channel from the site frequency list.

The TRX does not trunk track. Programming as trunked objects is useful only if you are dealing with locking out a bunch of talkgroups or doing other talkgroup specific tasks (where a large number of talkgroups are being dealth with). Otherwise, there is no benefit to programming as trunked; in fact, programming NXDN as trunked is likely hurting your scanner's performance. It is also more complicated and slower to program.



You do not have to program trunked NXDN systems as trunked to receive them. Trunked systems will be received when programmed as conventional objects.

I encourage you to program all NXDN as conventional frequencies with "any" RAN and a wildcard for the talkgroup.

Additionally, I have a website that will allow you to accomplish this quickly: Digital Frequency Quick Import


I write this so that hopefully people can use their scanners more effectively. I don't have any product or marketing interest, which stakeholders in certain entities may have. My goal is to make scanning easier and more accessible. I think the tactic I've explained above will help many of you.
Thanks!
 

AggieCon

Member
Premium Subscriber
Joined
Nov 25, 2015
Messages
1,444
Location
Texas
#3
You are welcome.

And to further clarify: since the scanner does not trunk track, you do not need a control channel when adding the system as a trunked system in EZ Scan. The control channel, likely, will just cause problems.

Additionally, this might also be the case with Connect + DMR systems. Something else to look into.
 

W4KRR

Member
Premium Subscriber
Joined
Apr 1, 2001
Messages
2,891
Location
Coconut Creek, FL
#4
Keep in mind that if you program multiple trunked NXDN system frequencies as conventional, and you program in a wild card, when any talkgroup becomes active and you want to hold on it, pressing the pause key will hold on the frequency, not the talkgroup. So if the conversation switches frequencies, you're out of luck. IOW, you can't hold on a TG using this method. At least this is what I'm seeing.
 

AggieCon

Member
Premium Subscriber
Joined
Nov 25, 2015
Messages
1,444
Location
Texas
#5
Absolutely, great point. I would add that under the compelling reason list if I could still edit the original post.
 

trido

Member
Premium Subscriber
Joined
Dec 19, 2002
Messages
887
Location
Southern In
#6
I thought at times the CC has voice also? Or am i thinking DMR CC has voice?
Just confirmed with my local kenwood NXDN dealer some systems CC also are voice channels.

so dont think i would leave out the CC.




You are welcome.

And to further clarify: since the scanner does not trunk track, you do not need a control channel when adding the system as a trunked system in EZ Scan. The control channel, likely, will just cause problems.

Additionally, this might also be the case with Connect + DMR systems. Something else to look into.
 
Last edited:

W4KRR

Member
Premium Subscriber
Joined
Apr 1, 2001
Messages
2,891
Location
Coconut Creek, FL
#7
I thought at times the CC has voice also? Or am i thinking DMR CC has voice?
Just confirmed with my local kenwood NXDN dealer some systems CC also are voice channels.

so dont think i would leave out the CC.
The NXDN system here uses dedicated control channels. Some sites they remain constant, on some sites they can change once a day. This system is a NXDN 4800 using Kenwood radios.

One of the sites has only one frequency, and it is the control channel sending out continuous data, but it turns into a voice channel when someone talks, and then reverts to the control channel after the conversation is over. The TRX-1 works well on this site, as there is only one frequency to monitor. But it's limited to only a couple of users.
 
Joined
Mar 17, 2005
Messages
103
Location
Redruth UK
#8
You are welcome.

And to further clarify: since the scanner does not trunk track, you do not need a control channel when adding the system as a trunked system in EZ Scan. The control channel, likely, will just cause problems.

Additionally, this might also be the case with Connect + DMR systems. Something else to look into.
re DMR Yes this is what I did from day one & it works better than setting us as trunked for the reason you said above.
 

AggieCon

Member
Premium Subscriber
Joined
Nov 25, 2015
Messages
1,444
Location
Texas
#9
A lot of the trunked NXDN systems uses a dedicated control channel. These are called NXDN-C. The "C" is for "centralized." These are the ones causing the problems. Some of these systems rotate the control channel daily, which will be a little bit of a pain. So, if you must program your NXDN as trunked, I suggest a scanlist/v-scanner folder for each day of the week.

NXDN-D, for "decentralized," is more like LTR. My guess is that these systems are not bogging down the scanner as much, but I don't have one to check out, either.

If the FCC license was done correctly, NXDN-C should be listed as FB8, and NXDN-D should be listed as FB6 for Class Station Code.
 

AggieCon

Member
Premium Subscriber
Joined
Nov 25, 2015
Messages
1,444
Location
Texas
#10
So to compare, P25 trunked, NXDN-C, and DMR Connect + are all similar, with a dedicated control channel.

LTR, NXDN-D, and DMR Capacity + do not have a dedicated control channel. Instead they have a rest channel that does data and voice. Once the rest channel is allocated for voice, the radios look to the next rest channel for commands.
 
Joined
Mar 17, 2005
Messages
103
Location
Redruth UK
#11
So to compare, P25 trunked, NXDN-C, and DMR Connect + are all similar, with a dedicated control channel.

LTR, NXDN-D, and DMR Capacity + do not have a dedicated control channel. Instead they have a rest channel that does data and voice. Once the rest channel is allocated for voice, the radios look to the next rest channel for commands.
As has been mentioned before the TRX etc certainly for DMR Cap + just go looking for voice frames.Ignoring the CC.
 
Joined
Feb 3, 2012
Messages
71
#12
Some systems in my area have NXDN type-C control channels that rotate every night, presumably to take it easy on the repeaters in terms of duty cycle. This method would require locking out the new CC every day.
 

AggieCon

Member
Premium Subscriber
Joined
Nov 25, 2015
Messages
1,444
Location
Texas
#13
The control channel on Capacity + is more like a periodic data burst, not a continuous stream of data. My radio commonly picks up the data hit from Cap+. But since it isn't continuous, it doesn't seem to mess things up. Also, it's probably where you are going to hear the traffic, anyways. While you are "looking for voice frames" on the control channel, you aren't scanning other channels for voice frames...
 

AggieCon

Member
Premium Subscriber
Joined
Nov 25, 2015
Messages
1,444
Location
Texas
#14
Some systems in my area have NXDN type-C control channels that rotate every night, presumably to take it easy on the repeaters in terms of duty cycle. This method would require locking out the new CC every day.
As I mentioned above, make as many systems as there are rotating control channels. Put each in a different scanlist or v-scanner folder.

Doing a v-scanner folder for each would be fast. Create the system, export it. Import for however many control channels there are rotating. Name the v-scanner folders (or scanlists) appropriately. Delete the control channel from each one as applicable.

Or import them as conventional.

Or let the control channel bog down the scanner.

It's up to each individual, really.

If you program as conventional, which should be best for most uses, you don't have to worry as much about these problems.
 
Joined
Oct 10, 2014
Messages
543
Location
MO
#15
Should AggieCon's NXDN tip be a sticky? I think it should be. :) Title it something like "How to get the most out of NXDN"
 

W4KRR

Member
Premium Subscriber
Joined
Apr 1, 2001
Messages
2,891
Location
Coconut Creek, FL
#17
I have programmed one site (the closest to me) of a networked NXDN system as conventional channels in one scanlist. There are seven channels; the control channel, which doesn't change, was not programmed. I programmed each frequency with the correct RAN code, and to look for one specific talkgroup. I still get conversations dropped in mid sentence and missed replies. I have tried various duck antennas, as well as outside mounted base station antennas. It makes no difference. IMO this method is no better than programming the system as trunked. This seems like some adjustment somewhere should improve the issue, but sadly there are no adjustments to make.
 

ka3jjz

Wiki Admin Emeritus
Joined
Jul 22, 2002
Messages
21,673
Location
Bowie, Md.
#18
Actually, if I was thinking as an engineer, I would want in a bug report the URL of the system from our database you're trying to use, and screenshots (compressed in a zip file) of all your settings. I kinda doubt that WW is reading every thread in the forums; she's no doubt too busy for that, particularly with the holidays just around the corner

Mike
 

AggieCon

Member
Premium Subscriber
Joined
Nov 25, 2015
Messages
1,444
Location
Texas
#19
Ken, what is your squelch to? Also, have you tried to set it to "any" for RAN? Specifying RAN can only slow it down. Unless you need to for interference reasons (I'm wondering if any NXDN systems anywhere in the world actually overlap), I'm not sure the benefit of specifying RAN.
 

W4KRR

Member
Premium Subscriber
Joined
Apr 1, 2001
Messages
2,891
Location
Coconut Creek, FL
#20
Ken, what is your squelch to? Also, have you tried to set it to "any" for RAN? Specifying RAN can only slow it down. Unless you need to for interference reasons (I'm wondering if any NXDN systems anywhere in the world actually overlap), I'm not sure the benefit of specifying RAN.
I thought specifying the correct RAN would speed it up. Anyway, I usually keep the squelch at about 10 o'clock, but I have tried fully clockwise to fully counterclockwise and in between. To me the results are inconclusive. The biggest issues are the signal drop outs, when it then resumes scanning and doesn't stop again.
 
Status
Not open for further replies.
Top