I think Uniden got caught off-guard with Whistler's announcement
Actually, I am sure that Whistler got caught off guard by our announcement. I was surprised that they had DMR ready so soon, but in looking at it, it is really more pre than our pre-release.
Those would be Control Channels and may also contain voice traffic on the unused slot. Make a note of the System Type. It should show CON or CAP. Probably Slot 2. Make notes of those freqs and system type. You can eventually use them to fiqure out the trunked systems in your area. Then feel free to Avoid them so you can continue to search for new DMR stuff as they will just lock up your search, but they are of significant value to you.During a scan of "conventionally programmed" DMR freqs, the scanner wants to hang onto freqs that display the Color, Slot and Sys type. I never hear any traffic on these channels.
Should I be locking these channels out, so my scanner just doesn't sit there like a paper weight? How is everybody else handling this? I know these channels provide some juicy info but hinders monitoring radio traffic.
During a scan of "conventionally programmed" DMR freqs, the scanner wants to hang onto freqs that display the Color, Slot and Sys type. I never hear any traffic on these channels.
Should I be locking these channels out, so my scanner just doesn't sit there like a paper weight? How is everybody else handling this? I know these channels provide some juicy info but hinders monitoring radio traffic.
Those would be Control Channels and may also contain voice traffic on the unused slot. Make a note of the System Type. It should show CON or CAP. Probably Slot 2. Make notes of those freqs and system type. You can eventually use them to fiqure out the trunked systems in your area. Then feel free to Avoid them so you can continue to search for new DMR stuff as they will just lock up your search, but they are of significant value to you.
Uniden need to address this as I explained in an earlier post, they need to implement a method of moving the scan or search on if there is no voice traffic for x seconds, until this happens DMR searching and scanning can stall indefinitely on this sort of channel.
Thanks guys! Will do, however, that leads me to another question....
How will I know what system those Control Channels belong to?
Thanks guys! Will do, however, that leads me to another question....
How will I know what system those Control Channels belong to?
we have ARC536 now so this helps a lot especially with Paul's spreadsheet, easy peasy
Uniden need to address this as I explained in an earlier post, they need to implement a method of moving the scan or search on if there is no voice traffic for x seconds, until this happens DMR searching and scanning can stall indefinitely on this sort of channel.
Conventionally programmed DMR is considered "Search" mode, too. If it is programmed as DMR One Frequency Trunked, it will not hang on data channels.
While I agree that the scanner should move on in scan mode, i disagree for search mode... in search mode, the scanner should stop on ANY activity, no matter whether it is data or voice... it is on the user to decide, whether it shall be stored as channel or avoided...
I'd have to disagree, I've been searching and scanning DMR using various methods for years and its a real pain to have things stalling continuously on beaconing systems or data systems, many of these can't be avoided because they share data and voice, AOR implemented thier search mode this way and it works extremely well.
I can't imagine a single reason why I would want custom search mode hanging on a non voice DMR frequency for more than a couple of seconds.