Repeater linking is an idea that has been floated about for years, recently IRLP has been showing just what could be done. However for IRLP to work really well it's clear that a broadband 24/7 internet connection is required, and that's just not available in many areas and even where it is available the costs are often high. A group of repeater keepers may think what a nice thing it would be to link up their repeaters by hardware owned by the group, rather than relying on web connections and other peoples servers. The trouble is that whilst it's easy to say 'yes link GB3XX with GB3YY' when you begin to look at the mechanics of how to put it all together it's not that easy, particularly if you want the sort of flexibility that IRLP offers.

The simplest for of 'link' is the so called 'linkless link', this works only where each of the two repeaters to be linked can hear the other. This means that effectively they must be covering adjoining areas and must well sited, it is also necessary that the frequencies used by each repeater are suitable, for example.....

GB3EE uses base TX of 433.3 and RX of 434.9, the proposed GB3BC (Bolsover) may use base TX of 430.825 and RX of 438.425. Each repeater can be heard at good strength at the others site. We therefore provide EE with a second RX on 430.825, and BC with a second RX on 433.3. This means that EE must recieve 430.825 whilst transmiting on 433.3, a considerably easier task than the one that EE also performs in recieving 434.9 whilst transmitting 433.3. BC would have to recieve 433.3 whilst transmitting 430.825 - a similar problem. The 2.475MHz shift involved would present little problem, especially considering that the 'link' RX could be operated on a yagi pointed at the other repeater, and with a sensativity of only what is required to maintain a noise free link.

This is the most basic of implementations of linking and not suprisingly it has the most serious limitations and deficiencies. Firstly it's really limited to 2 repeaters in most practical situations. There is no control, so the repeaters would be always linked. The system would be open to a user misusing it by transmitting on say 433.3 and bringing up BC that way, rather than using the intended 438.425 input. Then consider the problems if you wanted to link say EE and DY (DY uses 433.250 TX and 434.850 RX), the link RX at EE would need to recieve 433.250 whilst sitting beside a TX on 433.3 - not an easy task! Also if one repeater gets 'jammed' with a carrier or whatever, both would be jammed.

However it does have some advantages. It's simple and easy to implement, and infact with the addition of DTMF decoders on the link recievers some element of control could be added allowing users to switch the link on and off. Now the SLE controller is modified to send CTCSS only when signal is being recieved by the repeater only speech would be passed down the link, the link 'RX busy' line could drive the 'network signal' input on the SLE controller, so signal from the remote site would get an 'N' report, to make clear where it was coming from. Infact the idea is in a lot of ways 'beautifully simple'.

A slightly more sophisticated idea is to connect 2 fixed radios 1 on each repeater to some form of 'switch' or 'hub' that will patch audio between them in both directions. This offers the advantage that it is not restricted to linking just 2 repeaters, consider EE,DY and BC...... It would be necessary to provide a fixed radios on each repeater at some point that was in coverage of all 3. The radios on BC would need to RX 430.825 in the presence (possibly) of transmitters on 434.9 and 434.85 - a separation of over 4MHz - easy stuff. The radios on EE would need to RX 433.3 in the presence of (possibly) transmiters on 434.85 and 438.425 - a separation of 1.55MHz - challenging but not impossible, especially considering that powers are likely to be low and antennas of high gain, with good isolation and directivity. The radios on DY would need to RX 433.25 in the presence of (possibly) transmitters on 433.9 and 438.425 - a separation of 1.65MHz - similar to the normal repeater split, but again with high gain, well separated directional antennas operating at low power.

A DTMF decoder plus embedded micro (say an 8051 as used in the SLE repeater controller) would allow users to link any 2 repeaters, or even all 3 in a 'conferance' configuration. I'm currently working on a design for a switch/hub which would allow up to 7 repeaters to be networked in this way, including a 'conferance bridge' (IRLP users may call this a 'reflector') Quick thinkers will also realise that (if licensable) simplex radios could be added, allowing gateways onto other bands, such as 6,4 and 2 mtrs. It would also of course be possible to site the hub with one of the repeaters, effectively connecting it 'direct' to the network.

This method of course does again have the problem that it would be possible for a user to access via one of the link radios, he would be able to cause minor irritation but little else. Of course we must also remember that if a 'conferance bridge' is provided effectively allowing up to 7 'channels' to be bridged together the potential for a user with a stuck PTT to cause irritaion over a wide area is massively enhanced! Co channel problems during tropo openings would be equally irritating, it may be prudent to provide an un publicised RX input to allow the 'network admistrator' to control the thing, locking out 'offending' ports until the problem is cleared.

IRLP node owners will also be interested to note that there is no reason why one or mode of the repeaters involved should not be linked bia IRLP, if fact it would also be possible to provide an IRLP link on a simplex port. We must just be careful that none of the DTMF strings used have any meaning to IRLP, use of * # and ABCD should help here.

Infact in some cases where frequency assignments would make operation of all the desired frequencies on one site difficult or impossible or where a single site offering coverage on all the repeaters to be linked was unavailable, a group may choos to fit 2 or more hubs, connecting them by 'gateway' links on the microwave bands. The current bandplans provide channels in 13 and 3cms for 'repeater links'.

The next step beyong linking by using radios on the repeater outputs to provide the link is to fit each repeater with a microwave TX/RX linking to a similar TX/TX at the hub. This offers the advantage that the links could be made much more secure. Use of the microwave bands alone would mean that 'casual' abuse of the system would be unlikely. Also we would have more control of what was sent to the link, maybe we would only relay signals recieved on the repeater input with CTCSS, this would make the network much more robust and less likely to suffer from being jammed by other systems during lift conditions.

We would also be free to use signalling methods other than CTCSS for these links, making them more secure and more difficult for abusers to cause mischief on. We could if required fit intermediate repeaters in these links extending the links to repeaters over very wide areas. In short by using true linking in this way we could begin to build a network that would be almost infinately scaleable both in capacity (number of repeaters linked) and geography (area covered).

However everything comes at a price. By using microwave links we need to provide 2 microwave transievers for each link, along with at least 2 microwave antennas,feeders etc. - not cheap. Also many groups may be a little 'nervous' about approaching the site owner for permission to put up more antennas, especially if they are currently on good terms (peppercorn rents or whatever). This would also require 'surgery' on the repeater its self, which is usually to be avoided if possible. In many ways such a complex system is probably overkill, a practical solution is likely to be somewhere between the last 2 options, with most ports on the hub being connected to radios on the repeater frequencies and a few connected to microwave links.

All this raises a few questions that I could do with getting a range of views on, so if you want you voice to be heard take the trouble to email your thoughts on the following (and any other ideas you have.

I'm intereseted to know what proportion of users run with CTCSS decode on EE, whats your preferance do you like to hear the pips or not?? . There are also lots of 'what ifs' for the repeater link project that I could do with answers to.

For example if 2 repeaters are connected together what should happen if a 3rd one tries to connect to one of the 2? Should he get a 'busy' or should all 3 get connected 'reflector' style? It would be just as easy for me to connect all 3 (or 4 or 5 or 8).

When more than 2 are connected what should happen when 1 disconnects? Should it just disconn him or all the others too?

Should I provide a 'selective disconn' command that allows a user to disconn a specific repeater leaving others on, should there also be a 'global disconn' that clears all users on a 'reflector'?

Should there be a facility to allow 2 repeaters that are linked to 'include' a 3rd or 4th or whatever?

Many of these things would be easy to do if I plan for them from an early stage.

These are questions I could do with getting a broad range of views on (not just mine!) so let me know what you think. If you don't then please don't complain when it's not 'as you wanted it'!!

I'm particularly interested in hearing from Repeater Keepers and RMC members

Anyhow thats it for now but please do check back here in the next day or so and I'll continue to update the page as time allows.



BCNU Richard