As I am programming my SDS100 for P25 Simulcast cells in my area, I noticed the option to set the site NAC code. Does this do any benefit to the scanner by programming the NAC? Also, would this help ensure the scanner is monitoring the correct cell?
SDS100/SDS200: SDS100 P25 Simulcast Site NAC
- Thread starter inlandpatch
- Start date
-
- Tags
- p25 simulcast proscan sds100
- Status
doctordialtone
Member
Set it to Ignore Site NAC....
JethrowJohnson
I love P25
Why should he do that?
It is what Paul recommended - if I remember correctly.
Again (if I remember correctly), there was a glitch concerning NAC that was fixed in a firmware version.
It (the fix) could have been by adding the ignore feature.
Put it this way.... if the NAC is wrong (in RR or...) you don't hear anything.
Set to ignore, you do.
Someone feel free to jump in if you remember more of the details, please.
You might have been thinking of this:
SDS100/SDS200: - SDS100 Firmware 1.05.00M/1.01.05S Open Beta
http://info.uniden.com/twiki/pub/PartnerWeb/SDS100-Beta/SDS-100_V1_05_00M_V1_01_05S.zip To apply this public beta, unzip the above file and put the two files in the scanner's firmware directory then reboot the scanner. Note that the sub-processor version did not change for this beta...it is...
tvengr
Well Known Member
If you use site NAC, it will prevent the scanner from receiving wrong control channel frequencies in situations such as ducting. Also, control channel frequencies are often reused multiple times on sites out of range from each other in statewide systems. The scanner does not know which site you are actually receiving when travelling if NAC is not enabled unless you are using a GPS and have the latitude, longitude, and range properly programmed for each site. You may see a site name appear on the scanner that is hundreds of miles away. That happened to another member and had him very confused.
It's along the lines of setting the CTCSS on conventional frequencies and is solely user preference.
One school of thought is that it acts as a gate-keeper so that only the desired "stuff" is "admitted" to the receiver.
The other school is that "I want to hear everything I can, so leave the gate open".
One school of thought is that it acts as a gate-keeper so that only the desired "stuff" is "admitted" to the receiver.
The other school is that "I want to hear everything I can, so leave the gate open".
RidingDownUnder
Member
I don’t program NAC codes when programming P25’s. As others have mentioned its like DCS/CTCSS and I like to hear everything on that channel. You never know and it has happened, later down the line they may change the NAC code then you wonder why you don’t hear some systems anymore. It might be a problem in summer when sporadic E’s plays it’s roll, but I find that interesting and it usually doesn’t last very long.
An issue that others have encountered is when they have 2 trunking systems, or a Motorola Statewide and a Harris local system (which all frequencies are rotated as control/voice), and you begin to have issues with decoding, cross over voice etc. This is a reason why it's recommended that NAC Site is used.
The tool is there, and in all my years of monitoring, one time a site changed NAC codes. I have my display set up to see the site that's in use, and on my statewide system, I'm in range to monitor 2 sites. I noticed one site was always active, and the other wasn't. A simple NAC search revealed the change in about 5 seconds and my programming was updated. So it's very rare (but not impossible) for a NAC to change.
No, absolutely not. Individual cells of a simulcast site do not transmit any unique bits in the P25 protocol. They are all on the same CC frequency, same NAC, same site#. There is no way to tell which cell your monitoring within a single simulcast site. However, I suspect you meant to say "site" instead of "cell". A single simulcast site has numerous cells.
The NAC filter is a great feature for statewide systems, which typically share CC's as was mentioned earlier. Unlike commercial radios, you can't program scanners to recognize a site based on Zone/Site Number. However if you are monitoring a regional or local system which doesn't re-use CC's it really doesn't matter.
Last edited:
You've got some of the terminology mixed up.
The "cell" is the collection of physical transmit/receive locations (known as subsites) that make up the complete simulcast site. Put another way, a simulcast site (aka a simulcast cell) is a single virtual "site" comprised of multiple subsites.
You are correct about there being no unique fingerprint for each subsite; they all broadcast exactly identical transmissions. However I believe the OP was asking if programming the site NAC would reduce the chance of the scanner picking up an unwanted co-channel site, to which the answer is yes. Well, as long as the sites use a unique NAC, which is not always the case.
Ohhh sorry thanks for correcting me.
You're welcome.
In my opinion, it is a huge game-changer, particularly in a large city or an area with dense radio traffic from many different radio systems. I tried scanning Houston, Texas without the NAC site checked. The response delay was noticeable. When I made adjustments to the site NAC, it helped a lot. I also changed the hold time on the radio systems to 1 sec and added a 4 sec. delay on talk groups.
This helped me speed my SDS 100 up a lot. Now, I am happy with the performance.
Last edited:
Ubbe
Member
NAC doesn't do anything for the response delay. Scanner always use a hold time of 1,5sec even if you set it to 1 or 0 for trunked systems.
What do matters are the delay time for talk groups. The default 2sec are often too short and the scanner continuous to scan and skips all other conversations in that system and while scanning you don't hear the response until it has gone a full scan cycle. Increasing the delay to 4 or 5 sec helps to keep the scanner in the conversation until it ends. It could be perceived as it's catching more traffic, scanning quicker.
Uniden scanners could need a on/off/pri selection to continue to monitor other TG's at the same site for a set time, perhaps using the hold time value, and not start to scan other systems as soon as the TG delay timer runs out. The pri selection would disable the normal priority function for TG's but only allow priority TG's to be monitored during that extra hold time when the TG delay ends.
/Ubbe
Thank you for sharing. I did not mention that I previously had the hold time set at a higher value. Hence, when I dropped it, it began scanning better, almost as fast as my 436HP. Since my SDS 100 is working great now, I will keep the radio parameters as they are now.
Last edited:
- Status
Similar threads
SDS100/SDS200:
SDS100 P25 Site Scanning Question
