Troy,
Very thorough post.
I think you are really onto something by asking everyone to provide more information. It would probably be good if something like that was made a sticky for the entire Whistler Forum: Radio, Firmware Versions, EZ Scan Version, PC OS, Call Sign, Frequency, how it's programmed, relative location to the system, antenna, etc.
I looked up the system you linked to. It has two frequencies listed as type-D and 4 as type-C. Which was doing both control and voice?
Removing the control channel with type-d probably will miss voice; but I am not sure those control channels are the ones slowing down the scanner.
Another thing to consider is constant data channels. I've seen licenses where a couple of the "trunked" frequencies aren't parts of the trunked system. Some even do non-stop data.
What we are somewhat missing is our own investigation. Whether you are copying from RR of DFS, everyone owes it to theirself to investigate each and every frequency they put into their scanner. And that starts with listening to each and analog FM mode to understand what's really going on with the frequency. Then you can start adding digital back in. Basically, if a frequency has constant digital buzz, and if you hear nothing when it is forced to digital, it is likely a data channel that you want to ignore.
On another topic, Whister can't have any issues with trunking DMR or NXDN because it doesn't do trunking.
At the end of the day, I think a lot of the problems are caused by silly scanner software. Last night, I did a test on an analog system.
When I monitored a talkgroup, the black box T was solid 100% of the time with no blinks at all. This was notable, because my scanner never holds the T like that. I tried scanning the system. Nope. Lots of blinking T. I tried scanning just that one frequency. It too, caused the T to blink on and off.
The point: The scanner should be smart enough to stay on to one system if only one system is being scanned, but it is obviously dropping and reacquiring the system non-stop. It makes me wonder what kind of shape all of the firmware is in. Perhaps all patched together with different functions having better performance? Or absolute errors in some areas that prevent the scanner from receiving at all?
Anyhow, what I am suggesting to others with the beginning of the tread is this: Much like you would lockout an annoying talkgroup, you should be removing from your scanner anything that you don't want to hear. Because those things are slowing down the scanner and might be causing problems. If there is a type-C system, you don't need the control channel. It's likely causing the radio to stumble every time it comes around. You'll also want to subtract data-only frequencies.
Very thorough post.
I think you are really onto something by asking everyone to provide more information. It would probably be good if something like that was made a sticky for the entire Whistler Forum: Radio, Firmware Versions, EZ Scan Version, PC OS, Call Sign, Frequency, how it's programmed, relative location to the system, antenna, etc.
I looked up the system you linked to. It has two frequencies listed as type-D and 4 as type-C. Which was doing both control and voice?
Removing the control channel with type-d probably will miss voice; but I am not sure those control channels are the ones slowing down the scanner.
Another thing to consider is constant data channels. I've seen licenses where a couple of the "trunked" frequencies aren't parts of the trunked system. Some even do non-stop data.
What we are somewhat missing is our own investigation. Whether you are copying from RR of DFS, everyone owes it to theirself to investigate each and every frequency they put into their scanner. And that starts with listening to each and analog FM mode to understand what's really going on with the frequency. Then you can start adding digital back in. Basically, if a frequency has constant digital buzz, and if you hear nothing when it is forced to digital, it is likely a data channel that you want to ignore.
On another topic, Whister can't have any issues with trunking DMR or NXDN because it doesn't do trunking.
At the end of the day, I think a lot of the problems are caused by silly scanner software. Last night, I did a test on an analog system.
When I monitored a talkgroup, the black box T was solid 100% of the time with no blinks at all. This was notable, because my scanner never holds the T like that. I tried scanning the system. Nope. Lots of blinking T. I tried scanning just that one frequency. It too, caused the T to blink on and off.
The point: The scanner should be smart enough to stay on to one system if only one system is being scanned, but it is obviously dropping and reacquiring the system non-stop. It makes me wonder what kind of shape all of the firmware is in. Perhaps all patched together with different functions having better performance? Or absolute errors in some areas that prevent the scanner from receiving at all?
Anyhow, what I am suggesting to others with the beginning of the tread is this: Much like you would lockout an annoying talkgroup, you should be removing from your scanner anything that you don't want to hear. Because those things are slowing down the scanner and might be causing problems. If there is a type-C system, you don't need the control channel. It's likely causing the radio to stumble every time it comes around. You'll also want to subtract data-only frequencies.
