This is a continuation of a thread that was heading off into left field from the original topic. It's an issue that has plagued PRO-96 users since September of 2003, when the PRO-96 came out. 8)
The issue is the 'trick' of putting more than one trunking system, site, or zone in the same bank in a PRO-96. The original trick was that it would work AS LONG AS you left one conventional channel between the sites/zones/systems. Then, some started posting that they seem to have no problem scanning both systems/sites/zones without the channel between. This should at least solve SOME of that debate.
My test involves a PRO-96 with V1.1 CPU firmware and 1.2 DSP firmware on a P25 CQPSK two-zone system. The CCs for the first zone are in my scanner, followed by a conventional 800 talk frequency, followed by the CCs for the second zone. For the first part of this test, I changed the mode of that conventional channel to MO so I had one continuous block of MO channels not separated by a conventional channel. I have two other conventional channels programmed 'down the list' in that same bank, and another bank (just conventional) activated. Both CCs are about 99 decoding accuracy on the antenna I'm using.
My first test was to see how the scanner reacted to random presses of the MANUAL key. The ONLY channels the scanner stopped on in the trunked bank were the two conventional channels or the FIRST CC. That alone leads me to believe that no other MO channels are being scanned. Surely random chance would have made it stop on the other control channel. I did find something else interesting. If I manually stepped to the second CC, and pressed scan, it would only stop on THAT CC (or the two conventional channels), but when it stopped on any conventional channel, the next CC it stopped on would be the FIRST one again. It seems to remember what CC it last saw as active and will return to that channel in the trunked group FIRST, but only until it was stopped on a conventional channel (which could be in any bank, as I later found out). So, far, not encouraging for leaving out the conventional channel.
Next test: Wait for an active conversation on the system. Up came an active TG. It was received by the FIRST CC (by received, I mean that's what channel was displayed on the top line of the scanner as the active CC and the VC was part of its frequency group). I pressed scan. It sampled the first bank, then came back to the same CC. I did this multiple times, and it never went to the other zone's CC.
OK, so is this all worth it? DOES the trick actually WORK? Well, I changed that one conventional channel back (to CT mode, actually), and although the groupings do seem a little 'lumpped together', stopping scan DOES result in both CCs coming up about equal times on average. It seems it may be 4 times for one, then 5 for the other, etc, but they both DID come up. That is encouraging. I means at least both are now being sampled. I can't say they are both sampled every time, however.
Hmmm... I wonder. I changed the mode to FM (the original trick spec), and NOW I can see a distinct sampling of BOTH CCs every time that bank is scanned. It takes about twice as long now to scan that bank as it did before (remember, the trunk system and only three conventional frequencies are all that's in there), and I can reliably stop on EITHER CC EVERY time - every scan cycle!
So, in CPU 1.1, the conventional channel IS DEFINITELY NEEDED in order to make the scanner evaluate both control channels in the same bank during the same scan cycle - especially when there is no conventional channel activity. It does in fact seem the trick works, but ONLY if there IS a conventional channel between them AND ONLY works RELIABLY if it is a channel programmed as FM (not AM, not CT, not DC, not MO, and not ED). 8)
The tests were repeated with a CPU 1.3 unit with IDENTICAL results. I bet CPU 1.2 will be the same, too.
I suspect those using NO conventional channel between the systems THINK it is working because they hear conversations on both systems from time to time, but I have seen firsthand that it works much more reliably with the conventional FM channel between the systems (or zones or sites). Maybe they are losing one CC and that's the time it switches to another CC. That's not effectively scanning both CCs :!:
Note: This trick has nothing to do with programming two systems that are geographically separated from each other - you can do that in any trunked scanner. This test is dealing ONLY with cases when there are two active CCs within range and how the scanner reacts to them.
Joe M.
The issue is the 'trick' of putting more than one trunking system, site, or zone in the same bank in a PRO-96. The original trick was that it would work AS LONG AS you left one conventional channel between the sites/zones/systems. Then, some started posting that they seem to have no problem scanning both systems/sites/zones without the channel between. This should at least solve SOME of that debate.
My test involves a PRO-96 with V1.1 CPU firmware and 1.2 DSP firmware on a P25 CQPSK two-zone system. The CCs for the first zone are in my scanner, followed by a conventional 800 talk frequency, followed by the CCs for the second zone. For the first part of this test, I changed the mode of that conventional channel to MO so I had one continuous block of MO channels not separated by a conventional channel. I have two other conventional channels programmed 'down the list' in that same bank, and another bank (just conventional) activated. Both CCs are about 99 decoding accuracy on the antenna I'm using.
My first test was to see how the scanner reacted to random presses of the MANUAL key. The ONLY channels the scanner stopped on in the trunked bank were the two conventional channels or the FIRST CC. That alone leads me to believe that no other MO channels are being scanned. Surely random chance would have made it stop on the other control channel. I did find something else interesting. If I manually stepped to the second CC, and pressed scan, it would only stop on THAT CC (or the two conventional channels), but when it stopped on any conventional channel, the next CC it stopped on would be the FIRST one again. It seems to remember what CC it last saw as active and will return to that channel in the trunked group FIRST, but only until it was stopped on a conventional channel (which could be in any bank, as I later found out). So, far, not encouraging for leaving out the conventional channel.
Next test: Wait for an active conversation on the system. Up came an active TG. It was received by the FIRST CC (by received, I mean that's what channel was displayed on the top line of the scanner as the active CC and the VC was part of its frequency group). I pressed scan. It sampled the first bank, then came back to the same CC. I did this multiple times, and it never went to the other zone's CC.
OK, so is this all worth it? DOES the trick actually WORK? Well, I changed that one conventional channel back (to CT mode, actually), and although the groupings do seem a little 'lumpped together', stopping scan DOES result in both CCs coming up about equal times on average. It seems it may be 4 times for one, then 5 for the other, etc, but they both DID come up. That is encouraging. I means at least both are now being sampled. I can't say they are both sampled every time, however.
Hmmm... I wonder. I changed the mode to FM (the original trick spec), and NOW I can see a distinct sampling of BOTH CCs every time that bank is scanned. It takes about twice as long now to scan that bank as it did before (remember, the trunk system and only three conventional frequencies are all that's in there), and I can reliably stop on EITHER CC EVERY time - every scan cycle!
So, in CPU 1.1, the conventional channel IS DEFINITELY NEEDED in order to make the scanner evaluate both control channels in the same bank during the same scan cycle - especially when there is no conventional channel activity. It does in fact seem the trick works, but ONLY if there IS a conventional channel between them AND ONLY works RELIABLY if it is a channel programmed as FM (not AM, not CT, not DC, not MO, and not ED). 8)
The tests were repeated with a CPU 1.3 unit with IDENTICAL results. I bet CPU 1.2 will be the same, too.
I suspect those using NO conventional channel between the systems THINK it is working because they hear conversations on both systems from time to time, but I have seen firsthand that it works much more reliably with the conventional FM channel between the systems (or zones or sites). Maybe they are losing one CC and that's the time it switches to another CC. That's not effectively scanning both CCs :!:
Note: This trick has nothing to do with programming two systems that are geographically separated from each other - you can do that in any trunked scanner. This test is dealing ONLY with cases when there are two active CCs within range and how the scanner reacts to them.
Joe M.
Last edited by a moderator:
