This document attempts to explain how the Graham Repeater Association machines are linked up. The linked system consist of five UHF repeaters in Raleigh, RTP, Efland, Graham, and Greensboro North Carolina. The five machines behave as one in that anyone getting into one machine is heard on the other 4 machines.
       The approach to linking is different from many other systems. For purposes of illustration, I'll discuss the Efland to Graham link. Lets first look at how a user who is accessing the Efland machine shows up on the Graham machine. When the user gets into the Efland machine (which means that both a carrier and an incoming PL at 107.2 have been detected), the link radio to Graham is also put into transmit. This link radio transmits at the input frequency to the Graham machine. In other words, it looks like any other user of the Graham machine, and the Graham repeater can not distinguish it from any other user. It transmits the audio received at the Efland receiver, and also transmits the correct PL for the Graham machine.
       When the signal into the Efland machine drops (which can be either the carrier or PL, but for most users it's the carrier that drops 1st), the transmitting link radio to the graham machine drops. If someone then accesses the Graham machine (perhaps to reply to the user on the Efland machine), the process reverses. The link radio at Efland receives the Graham repeater output (it sees carrier and PL), and then the Efland machine receives takes this audio and starts to transmit it.
       So you can see how the two repeaters are linked together, behaving as one machine. But there are some subtle differences involving the PL tones. When the Efland machine was transmitting to the Graham machine, it transmitted both a carrier and PL, just like any user with a radio. When the signal into Efland went away, the entire RF deck transmit to Graham went away- both the carrier and the PL. When a user replied via the Graham machine, however, things behaved slightly differently. Since the repeaters have transmit hang (the transmit stays up for 5 seconds after a user drops their signal), there must be some mechanism to signal the Efland machine that the signal at Graham has gone away. That mechanism is as simple as the Graham machine stops transmitting a PL tone.
       So in general, all machines need carrier and PL in to recognize a signal, and all machines only transmit PL when there is a recognized signal at the input. When this is the case, this method of linking machines (which for lack of a better term I'll call "In Band Linking") works quite well. Machines that behave this way are good candidates for cross band repeater applications. When the repeater ID's, there is no transmitted PL tone. Some users leave the tone decode on their radio on, so they only hear audio and no ID tones.
       This should be a fairly clear picture of the simple requirements to two repeaters together. Now lets expand the picture.

       At the Efland site, there are link receivers not only to Graham, but to Greensboro and RTP. They behave the same way as the link to Graham. So when a user is received at Efland, that signal is then transmitted to the Graham, Greensboro, and RTP machines and the user is heard there too. When the Efland user stops transmitting, anyone can access any of the Graham, Greensboro, or RTP sites and the link radio at Efland will broadcast their signal on the Efland machine. It will also broadcast the signals to the other two repeaters via the other two links (the ones not receiving anything). So now we have 4 machines tied together, and to the users they appear to be one big machine. The "hub" of this system is the Efland machine.
       At the RTP site, there is a link radio to Raleigh. The Raleigh and RTP machines are linked, just as Efland and Graham were at the beginning examples. However, the RTP machine is on a link at Efland. So, when a user accesses the Raleigh machine, the link at RTP sees the output of the Raleigh machine, and the RTP machine switches to that received audio and turns on it's transmitter and PL. The link radio in Efland sees the carrier and PL from RTP, and it selects that link radio as the source for the Efland machine and the two links to Graham and Greensboro. The Efland repeater transmits the audio (with PL), and the link radios transmit the audio received from RTP to their respective repeaters.
       So now all five machines act as one. So why doesn't this go on from Manteo to Murphy? Well, each hop sees some degradation of the audio. And as the sites spread out, there is degradation of the enthusiasm of the people who have to drive around and maintain the sites. So on the theory that a small system that works well is better than a large one that sounds bad and is flaky, the system ends.
       Other sites can link into the system as needed. There is a political constraint (as opposed to a technical one) that other systems linking in have an automatic inactivity timeout of 10 minutes. In other works, if the system is idle for 10 minutes, the link must drop. Another political constraint is that the codes to link and unlink the system must be public knowledge. I will again point out that this is a people created non-technical constraint, the intent of which is to encourage experimentation and utilization while keeping the quality and reliability of the system under control. Also, the links between the five backbone machines are on all the time. This encourages use and allows hams over a 100-mile area to get to know each other.

       There are two interesting problems with repeaters that involve time. One is that it takes a PL decoder time to recognize valid incoming PL and time for it to realize it has dropped. The second problem is that it takes time for the carrier sense ("squelch", if you will) to realize that the carrier has dropped and during this time the user is treated to a burst of noise (sometimes called the squelch tail). These times are roughly 150 milliseconds to see PL arrive or drop, and about 80 milliseconds to see carrier drop. Now lets imagine a signal arriving at the Raleigh repeater. The 1st 150 mS are lost as the receive PL is decoded. Then, the transmitter turns on and the transmitted PL turns on at the same time. 150 mS later, the Raleigh receive link at RTP sees that it has a valid signal on the input, and the RTP machine turns on and transmits PL. Then, 150 mS later the RTP receive link at Efland turns on, presenting the RTP signal to the Efland site. The Efland repeater transmits and turns on it's PL. At the same time, the links to Graham and Greensboro turn on, and their PL xmit turns on. 150 mS later, the Graham and Greensboro repeaters turn on and transmit their PL. And then, 150 mS later, the casual listener in Greensboro who has their PL decode turned on hears what the person in Raleigh has to say. Unfortunately, there is a cumulative lost of audio due to the PL decode times of about 5 times 150 mS, or about .75 seconds. That's enough time to loose a "Roger" or a "Please Repeat" message. And then, just as you loose that message, you get a cascade of noise as the PL receivers take their time and drop. The system will also have many squelch tail bursts as carriers drop. Clearly this is not good.
       The solution is simple (but like many simple things, tricky to implement well enough that it is not noticed by the users). Lets focus first on an individual repeater. Each repeater has a 150 mS audio delay circuit. The audio from the repeater's receiver is digitized (12 bits, 28 Khz sample rate). The digital carrier detect (squelch sense to some) is also digitized. So the controller logically sees the signal about the same time the PL receiver kicks in. Now there is no loss of speech due to the PL time decode. The repeater keys up (and transmits PL) without loosing a thing. When the carrier drops, the repeater controller turns off the incoming audio, leaving the noise burst (squelch tail) in the audio delay where it won't bother anyone and certainly won't be heard. So to the controller, the signal "carrier detect" is really the AND of the real and delayed carrier.
       Now if all the repeaters in the system behave this way, there isn't quite the cascade of lost time as a signal goes through the system. And the users never hear the squelch tail burst. Overall, things are sounding pretty good.
       Of course when things look there best is when you need to look out for the runaway wagon. Lets take our signal through from Raleigh to Greensboro again, and count delays. The signal comes in at Raleigh, and Raleigh transmits the signal with PL with no loss of audio. So far so good. But the Raleigh link radio at RTP looses 150 mS of audio while it decodes the PL. It then presents that signal to the RTP repeater, which transmits it (and transmits PL). The RTP link at Efland receives the RTP signal, but looses 150 mS due to it's PL decode. Then, that is broadcast at Efland and it also is sent out on the links to Graham and Greensboro. Fortunately, those links are going into repeaters, which have the delay so the decode time for the PL receive at (say)Graham is compensated for by the audio delay at Graham. The total lost time for audio is now 300 mS. Much better than the 750 mS before. In order to balance this out further, there is an addition 150 mS of delay added to the Raleigh link radio at RTP to further balance the time delay down to 150 mS total between Raleigh and Greensboro.
       Ok, so someone in Raleigh gave a CQ. Now someone in Greensboro is going to answer. They come into the Greensboro machine, and the audio delay there compensates for the PL receive time. The link radio at Efland sees the Greensboro machine, but looses 150 mS due to PL decode time of the receiver in the link radio at Efland. The Efland machine broadcast the signal. Also, the link to RTP broadcast the signal (and has it's xmit PL on). The RTP machine receives the link's signal, but since it has an audio delay no time is lost. Once it sees the signal, it broadcast it out and also send it on to the Raleigh machine via the Raleigh link radio. Since the Raleigh repeater has the audio delay on it, there is no loss there due to PL decode times.
       So, Greensboro to Raleigh is a 150 mS loss, and Raleigh to Greensboro is a 150 mS loss. Not bad given all those PL decode delays. And not an annoying squelch tail in the whole lot.

       The problem with all of the above is that it's not really right. It's not wrong, it's just simplified. In reality, the PL decode time needs to be modeled statistically, just like any PLL acquisition time. The average time turns out to be around 120 mS. In fact, the typical audio time lost end to end should be only 50 mS. Now sometimes, with a bad bounce, it's as high as 200 mS. And sometimes it's as low as zero. But it certainly is well within the users ability to hit the PTT button on their mike and have a small delay to start talking.
       I tend to detest courtesy tones. In fact, the quieter a repeater the better. But, due to all the audio delays, PL decode delays, and other factors to be covered soon, there is a need for about a 350 mS delay between transmissions to positively insure that the system is "idle", and all the sites (relative to any given repeater that you are listening to) have gone idle and the system is waiting for the next user to transmit, wherever that is. Sometimes the users get a little confused and impatient. It's like listening to the space shuttle with it's time delays. You can ask a question in Raleigh, and if the person in Greensboro immediately answers, it will seem like a .75 second delay. So, the machines do have a courtesy tone on them, and if you wait for it you can be assured you'll be on all the machines.
       Like a single repeater, any two people can double- transmit at the same time. This system is no different. You can certainly double, and the slight time delays seem to sometimes make that easier. There is a concept in the system call "Repeater has Priority". If at any time at a linked site (which is only Efland and RTP) the current source of the transmission is a link receiver, and a signal comes in on the repeater, that repeater will take over as the source for that site and the transmitting links. So two people talking rapid fire on a the same machine don't suffer from turn around delays. It's really not as bad as it sounds, and the delays are good operating practice anyway.
       Earlier I mentioned that the repeaters don't transmit PL when they ID. Link radios have to ID too. But when they ID, they must have their PL on. Otherwise, someone would think the system was idle and there would be a double between the ID-ing link radio going into a repeater and someone trying to use that repeater. Because repeaters don't transmit PL when they ID, the system eventually goes fully idle when there is no use.
       There is also an interesting control problem. How do you turn off the Raleigh repeater when you are in Greensboro? The answer is a lesson right out of the Internet. Each repeater has a touch tone receiver and generator in it. There are commands for bringing links and repeaters up and down. Each site has it's own site number. And each site has a unique routing table. When you enter a command to initiate some action at a site (such as when you decide to turn off the Raleigh machine from Greensboro), if the command does not apply to the site where it was received, the routing table is consulted and the command is sent out on the appropriate link radio that gets the command closer to the correct final destination. So a command to shut down Raleigh, issued in Greensboro, makes its way across the state until it arrives at the Raleigh machine and the shutdown occurs.
       One last timing issue to touch on. When the repeaters have their transmit hang time active (they are transmitting, sometimes called the repeater "tail"), the input to the repeater is monitored. If receive PL shows up before the delayed carrier, transmit PL is turned on right away while the controller waits for the delayed carrier sense. This occurs system wide, and has the effect that the audio delays mentioned above actually go to zero. Yep, all it takes is for the PL decode times to be under the 150 mS and you start to build up a time surplus that goes against any long decoding PL time. This "Repeater active advanced PL transmit" feature truly makes the system behave as one machine, with no decode time delays, and no receive squelch tails. As they say in these parts, "It just darn works".
       Unfortunately, for this to really work (you really didn't think it was that simple, did you ?) there is then a requirement for what is called "post transmit blind time". This applies to the link radios. When a link radio is transmitting to a repeater, when it drops it's transmit, it has to be blind to that repeater for 300 mS. The reason for this is twofold. First, most RF decks (since these are converted mobiles) will show a PL receive when the deck is transmitting. When the transmit drops, it will take some time (up to 250 mS worst case) for the rec PL decoder to drop. If the controller did not have the blind time, immediately after it drops it would see the transmit tail of the repeater it was just broadcasting into, and see the lagging PL receiver, and immediately select that repeater as a source. Of course, very shortly (averaging 120 ms), the PL rec. would drop, and so would the repeater. But by then, the damage is done and the entire system is quickly turning on with that repeater as the source. The seconds reason for the blind time is that sometimes the PL receive is very fast. It is fast enough to see the 90 mS of PL from the repeater before the carrier sense at the repeater goes away. It will then select the repeater and there will be another brief burst of noise. In the early days of the system, when the blind time was being adjusted, this was called "pumping the system".
       The combination of PL decode times, blind times, and audio delays, and their associated statistical timing, are why there is a 350 mS system turn around delay and why there is a courtesy beep. However, no audio is lost despite all the delays and hops.

       The RF decks are Motorola Mitreks. There is no particularly good reason for this. The deck is small enough that an entire repeater and controller can fit in a 2 RU chassis. The Mitrek was the last crystal controlled machine, and uses pin and hole components so it is easy to work on. They are terrible for 6M, OK for 2M and absolutely wonderful at 440. There is a PCB added inside the deck that takes the audio and makes it 1V p-p buffered. This board also takes the squelch, Rec. PL, and Xmit PL and makes them open collector pull to ground signals. The xmit PL has a weak pull-up to +5 volts.
       Outside the RF deck is another PCB. This has amplifiers for the xmit audio, a gain control to set the volume on Xmit (if you change the deviation on a channel element, you have to reset the frequency a touch, so external tweaking of +-30% can be done on this PCB). It has a volume control to set the output audio level at 1V p-p. It has the squelch for the deck. It also has the switching power supply (100 Khz) for creating the +5 for the controller. The Efland site is a 28 volt site (a bad decision that seemed good at the time), so it also has a switching regulator that is installed for decks at that site that makes 13.8 V at 4 A. The only good thing about the 28 volt Efland site is that the PA decks are very efficient. The bad thing is I bought TE Systems amps, and ended up totally reworking them and adding VSWR protection. This PCB also makes +8 and -5 from the 12 to 28 volt input, which is used to run the audio op amps in the controller. It also makes the 2.5V false ground that everything is referenced to on the audio board. The board has RCA jacks for audio in and out, and for carrier sense and PTT. This makes it easy to both test the board on the bench and in the field, and allows for a really dumb repeater (also good for field testing). It has a 25 pin connector wired for a SCOM 5K. Each site has a backup SCOM 5K so if the homebrew controller fails, it's easy to remove it and leave the machine on the air. There is also a 16 pin ribbon connector that has all the power and signals for the RF deck. This cable goes to the controller.

       The controller is two double sided plated through boards. One is the audio delay and switching unit. The other is the microprocessor PCB. The audio delay board connects to the RF deck via the 16 wire ribbon connector. It has three 26 pin headers that can go directly to the 25 pin connector on the link decks. A standard ribbon cable 26 pin dual .1 center to 25 pin D connector cable does this. This board has the switching for the audio. An FPGA on the board runs the digital audio and squelch delays, and runs the serial 12 bit A/D and D/A. There are LEDs on the board, showing the status of the power supplies, the RF Deck signals (rec, PTT, rec. PL, xmit PL, and delayed rec squelch). The current "source" is also shown. It also displays the output of the touch tone decoder. Dip switches determine the length of the audio delay (150 ms or 300 ms, currently all are at 150 ms). By changing dip switches, this board can also act as a complete controller, and has an EPROM on it with the ID information. There is a dipswitch for type of call (repeater, link, aux) and a jumper for "pete" or "dave" (wa1yyn or k4gwh). Another setting makes the board just an audio delay device, and a 25 pin connector is then the "new" standard SCOM 5K connection to the deck. This is how the extra delay is added at the Raleigh link. The board also has on it serial shift register/latch chips (74HC595 and 597) so that a single 10 wire cable connects some 48 digital signals and power to the uP board. A second 10 wire cable has the outputs of two timers, which the uP uses to "beep". Finally, there is an audio line from the uP that comes from a 12 bit DAC. This is how the uP does some of the voice feedback (used Only for announcing links and repeaters coming up and down, not for ID). The op amps used for the audio are National LM833 audio op amps. Not the best, not the cheapest, but slap 47 pF between the output and the input and they are stable and good for audio. Distortion is way below the quantization noise floor of the converters.
       The uP board is a 68HC12 microprocessor. There are two serial ports on it. One is used to turn tasks on and off, run the debugger, change parameters (such as blind time, ID default link status, routing tables) in EEPROM, and to update the flash memory that has the software and voice in it. The other is used to display various system functions in an enunciator fashion. The board has 64K of RAM, and 1 Mbyte of flash. All boards run the same program. The site specific parameters are stored in EEPROM on the uP. There is a temperature sensor that shuts the system down if it gets too hot. No point in burning up your PA if the air conditioner fails. There are also VSWR input ports, and many sites have Bird forward and reflected sensors with electronics to turn full slug rating into 2.5 V DC. This is a "to be connected some day" feature, but the software does monitor the lines on the A/D. Leds on the uP unit display which task is running. The repeater controller is broken down into a number of task, such as COR switching, Idling, Command Processing, Serial Link Control (for the 595/597's), Environmental Control, and Enunciator Operations. The boards stack on each other and fit in a 6" x 8" by 3" box. They draw about 1 watt of power.
       All digital IO on the RF decks has transient protection. All power supplies have transient protection. All digital inputs have weak pull-ups and RC networks on them. All IO in and out of the system has EMI filters on it so the uP's won't interfere with anything. In a little more than a year, there have been no field failures, yet lighting strikes at sites have taken out 3 preamps (the power supplies on these had DC transient protection, so the problems were due to input signals not power). Of course now that this has been said, we'll see a rash of failures....

       It was a big win select a single RF deck and make the PCB's for it. The standardization of the RF decks saved a lot of time, and it allows us to have spare link radios and receivers. We documented how to convert and align the decks, so it's easy to get the quality control and consistency between the decks. The only exception is the 220 repeater, which is build out of ICOM band modules and an FPGA that squirts bits into the PLL's to set he operating frequency when the system is powered up. A nasty piece of reverse engineering that went from fun to ugly very fast.
       Every RF deck goes through a band pass filter. Just for fun, most sites ran without for a while. Most sites got cleaner or problems went away when the filters were added. Raleigh, RTP and Efland have bandpass filters after the cavities on receive on 440 to get more margin against interference.
       Dont' mess with 28 volt systems. The "free" charger is the most expensive thing I ever got. I should have wired the 2500 pounds of backup battery for 12V, and then I would have had one simple problem, a 200A 12V charger instead of a whole pile of 28 volt to 12 volt conversion problems and 28V PA problems. The 440 and 220 decks are re-works of new TE systems. The 147 and 53 Mhz decks are build from scratch single transistor amps (which, at 28 volts, means they are 100 and 120W units- a small win in an otherwise bad situation).
       The controller from scratch was for fun, but the timing is very complicated and that worked well. I can't imagine doing that with macros. It was felt that it was critical that the system performed like a single repeater because that is what users expect. A more digital approach would be nice, but the choice was made to get something done that worked instead of something cool that never got done. A voice going from Raleigh to Greensboro goes through some 28 op amps, and is digitized twice. Greensboro to Raleigh is digitized 3 times.

       Well, you're tired of reading and I'm tired of typing, but I hope this give you a feeling for how the system works.


-Pete Hallenbeck, WA1YYN