Over the past few months, I have been running my Uniden BCD325P2 in AutoStore mode, allowing it to search through sections of the radio spectrum and automatically save the active frequencies it finds.
Reviewing the results has revealed some interesting patterns. In particular, I started noticing that sometimes the scanner would identify CTCSS or DCS tones, while at other times those details were missing. At the same time, I have noticed an increase in the use of DMR and NXDN locally.
The problem was that the local digital activity has generally been too intermittent to spend the time needed to properly test exactly how the scanner's different search settings affect what is decoded and logged.
Recently, however, our local 70 cm DMR amateur radio repeater (VK7RJG) has been active during the evenings. The longer QSO sessions provided a perfect opportunity to sit down and systematically test the different search options.
My initial test was fairly simple. I manually entered the repeater frequency using the familiar:
HOLD → FREQUENCY → HOLD method, however, the DMR signal wasn't being decoded as I expected.
That led me back to the excellent Easier to Read Uniden BCD325P2 Scanner Manual, specifically the section covering Tone/Code Search.
The manual explains that Tone/Code Search determines whether the scanner searches for codes in Search and Close Call modes. It provides three options:
- Off – the scanner does not search for or display tones.
- CTCSS/DCS – the scanner searches for and displays CTCSS/DCS tones.
- NAC/CC/RAN/Area – the scanner searches for and displays NAC, Colour Code, RAN and Area information.
The manual also notes that this setting is ignored in AM, WFM and FMB modes. What I hadn't appreciated was just how much this setting could affect digital signal decoding.
Using the active DMR repeater as my test signal, I tried each of the three settings.
Tone/Code Search: Off
With Tone/Code Search set to off, the scanner decoded the DMR signal. However, no additional digital information was displayed. In other words, I could hear the decoded DMR traffic, but I wasn't getting the useful identifying information that I was looking for.
Tone/Code Search: CTCSS/DCS
This produced a very different result. Instead of clean DMR audio, I was greeted with what can best be described as "machine gun" audio. The scanner was effectively looking for analogue CTCSS/DCS information rather than the digital information associated with the DMR signal. For someone trying to identify digital activity, this is obviously not particularly useful.
Tone/Code Search: NAC/CC/RAN/Area
This was the interesting one. With NAC/CC/RAN/Area selected, the scanner successfully decoded the DMR signal and displayed the Colour Code. This is exactly the sort of information I want when investigating an unknown digital signal. It gives me both the decoded audio and an additional piece of information that can be used to identify and document the transmission.
The unexpected part: this also affects manual frequency entry. The biggest surprise from this testing was that these settings aren't just relevant when performing a traditional Search or Close Call operation. They also appear to affect what happens when using the: HOLD → FREQUENCY → HOLD method, to quickly enter and monitor a frequency.
That means the scanner's Tone/Code Search setting needs to be correct before entering the frequency, if I want the best chance of getting useful information from a digital signal.
This is an important distinction, as it would be easy to assume that manually entering a frequency bypasses the search configuration. My testing shows that it doesn't.
If I am investigating DMR or NXDN and have the scanner configured for CTCSS/DCS searching, I can end up with an entirely different result from what I would get with NAC/CC/RAN/Area selected.
Another limitation is changing the mode from the keypad
Another interesting observation was that, from the keypad, I can change the mode between options such as:
- AM
- FM
- WFM
- FMB
However, I don't appear to have the same direct control over the more specific digital/analogue decoding behaviour from the keypad.
This makes the global search configuration more important than I had previously realised.
It is very easy to change a frequency and start listening without necessarily realising that another setting is influencing what the scanner is actually looking for.
This has changed how I approach spectrum searches. Previously, I had assumed that running a search across a band segment would give me a reasonably complete picture of what was there. My recent testing suggests that this isn't necessarily the case.
If the scanner is configured to look specifically for CTCSS/DCS, I may miss useful digital information.
Likewise, if I configure it specifically for digital code information, I may not get the analogue tone information I was originally looking for.
That creates an interesting problem for anyone trying to document an unknown section of spectrum. Based on this testing, I think I will need to run two separate searches of each band segment.
The first search will use:
CTCSS/DCS: This should allow me to identify analogue FM activity and capture CTCSS/DCS information.
The second search will use:
NAC/CC/RAN/Area: This should give me a better chance of identifying digital activity and capturing information such as:
- DMR Colour Code
- NXDN RAN
- P25 NAC
The exact information available will, of course, depend on the signal type and what the BCD325P2 is capable of decoding.
One of the reasons I enjoy running the scanner in AutoStore is that it produces a large amount of data that can be reviewed later.
In this case, the AutoStore results were what initially made me question why some signals were being logged with useful tone information while others weren't. What I had originally considered to be inconsistent results now appear to have a much more logical explanation.
The scanner wasn't necessarily failing to detect the information, I was simply asking it to search for the wrong type of information. That's an important distinction. This little experiment has changed the way I think about searching for digital signals with the BCD325P2.
The Tone/Code Search setting isn't something I would normally think about when manually entering a frequency, but my testing indicates that it can have a significant impact on what the scanner actually decodes and displays.
For analogue monitoring, CTCSS/DCS is useful.
For digital signal hunting, NAC/CC/RAN/Area is the better choice.
And if I'm trying to comprehensively survey a section of spectrum, I don't think one search configuration is enough.
For my own monitoring, that means running the band segment twice, once looking for CTCSS/DCS, and again looking for NAC/CC/RAN/Area.
It's another reminder that modern digital scanners are considerably more complicated than the old analogue scanners I started with.










.jpg)

.jpg)
.jpg)

.jpg)
.jpg)

.jpg)
.jpg)
.jpg)
.jpg)


.jpg)
.jpg)
.jpg)
.jpg)
.jpg)





.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)









.jpg)
-edited.jpg)
.jpg)






.jpg)
.jpg)
.jpg)

.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
%201.jpg)
%201.jpg)
.jpg)


.jpg)



.jpg)
.jpg)
.jpg)
.jpg)

.jpg)
.jpg)

.jpg)
.jpg)

.jpg)


