If you own a 7330, you know that its flexibility in port programming is unmatched in repeater controllers.
How did it get that way? Let’s go back some years...
The 7K is in its prime and is our flagship model. It’s designed to support one repeater, one link transceiver, and one control receiver. It’s still doing its job well, but we’re getting more frequent requests to have it control two or three repeaters instead.
We’ve been stretching the 7K by timesharing its resources. For example, the DTMF decoder originally worked on a priority basis, but now it also scans the three receivers and the phone line. (The downside is that detecting a character means staying connected to that source temporarily while ignoring the others. It would be nice to have three decoders.) And we created a new message handler that sends tone and voice messages individually to each transmitter and the phone line. (Unfortunately, there’s only one tone generator and speech synthesizer, and when they’re busy, courtesy beeps and IDs for other destinations must wait their turn. Three tone/voice generators would be much better.)
We see that any new “triple repeater controller” needs three of everything so that each repeater thinks it has its own controller. But we don’t want to use three totally separate controllers due to the difficulty in setting up communications between them. A single controller has the advantage of accepting commands through any port to control the other ports.
The new design needs more parts than the 7K, but at least the hardware is straightforward. Since each repeater is to be controlled separately and independently, we don’t want to share resources; we need three receiver interfaces, three transmitter interfaces, three DTMF decoders, nine audio gates, three audio mixers, three tone generators, three voice generators, three audio delays, and so on.
At first, the software seems straightforward as well. We need three access modes, three command buffers, three timeout timers, three identifiers, three message handlers, and three of everything else.
With all that, we can conceivably control a carrier-operated repeater on RX1/TX1, a carrier-and-CTCSS repeater on RX2/TX2, and a carrier-or-CTCSS repeater on RX3/TX3, all simultaneously and independently.
But wait a second. What happens when we interconnect those repeaters?
One issue is choosing the access modes for the remaining combinations: RX1/TX2, RX1/TX3, RX2/TX1, RX2/TX3, RX3/TX1, and RX3/TX2. A related issue is the right way to handle multiple receivers wishing to key a transmitter simultaneously. Which receiver wins? Do we use a priority system, or do we mix the receivers?
The answer is to use a solution from the 7K. It supports three receivers and two transmitters, and it has six paths and six access commands for the modes. Because the new controller has three receivers and three transmitters, we go with nine paths and nine access commands.
We allow both a priority scheme and a mixing scheme. For example, RX1, RX2, and RX3 can feed TX1 based on a user-selected priority or a combination of priority and mixing.
A second issue is the timeout timer (TOT). It’s a simple software routine that we use to monitor a transmitter PTT or receiver COR. Which do we choose?
If it monitors the transmitter’s PTT, and more than one receiver keys the transmitter, the TOT runs until all the receivers go silent. Frequent timeouts will be a nuisance.
If the TOT instead monitors the receiver’s COR, and the receiver times out, the receiver is prevented from keying ANY of the transmitters.
The solution, once again, is to monitor neither the receiver nor the transmitter, but rather the path that connects them. That means nine separately programmable TOTs, one for each path, which means there can be a different timeout for each RX/TX combination. A repeater can have different timeouts for local traffic and link traffic.
A third issue: A courtesy beep is typically sent to let listeners know that the TOT has reset after a transmission. But when you have one transmitter fed by three receivers, and a separate TOT on each path, how do you handle the beep? The answer is to have a separate courtesy message for each path. That way, users can tell which receiver heard the last transmission (and thus which TOT has reset).
The paths are named for the RX number and TX number. So, the main characteristics of the repeater on RX1 and TX1, such as carrier access, a three-minute timeout timer, and a single courtesy beep, are assigned to Path 11.
The repeater on RX2 and TX2 (path 22) might be set for carrier-and-CTCSS with a five-minute timeout timer and a two-beep courtesy message.
The repeater on RX3 and TX3 (path 33) might be set for carrier-or-CTCSS with a 10-minute timeout timer and the CW letter “K” as the courtesy message.
Now, to cross-connect the first two repeaters, we configure the paths 12 and 21 by choosing the desired access modes, priorities, timeout timers, and courtesy messages.
To add the third repeater to the mix, we set up paths 31, 32, 13, and 23.
If RX3/TX3 is a simplex link transceiver instead of a repeater, we turn off path 33 so that RX3 doesn’t key TX3. We delete the path 33 beep and the TX3 tail sequence so that it unkeys quickly.
When the system is complete, we make use of the macro command system to create commands that connect and un-connect the radios quickly for use in emergencies.
To sum up, the three receivers and three transmitters are now seen as totally separate devices. This means the user can control three repeaters (in-band or crossband) and/or links (full- or half-duplex) in any combination by configuring the interconnections between them.