MRMap - www.mrmap.org.uk

Used by a number of regions, wide area repeaters are a very useful way of giving radio coverage over a large area. In order to work, the aerial for these devices needs to be high up or the area to be covered needs to be fairly flat. They no more go round sharp corners than does any other form of radio coverage. That said, they can be made to work well when either of the above criteria can be met.

One of my colleagues to the south of our region makes heavy and successful use of wide area repeaters and to do this he uses a radio not often mentioned on this website, the Team Simoco TSF2025. This is a dedicated repeater designed for duplex operation and comes in a 1U 19" rack mount case. It's RF engines are a pair of SRM9000s but using bespoke firmware developed by Team Simoco. For use as fixed repeaters on the UKSAR frequencies, they perform well and are reliable in operation.

Taking the programming a little further and looking at mobile repeaters rather than those intended for fixed sites, I used a configuration file sent to me by the Simoco engineers. This is based upon the old police VHF system which had a succession of 'comfort beeps' added to the end of the transmission from the repeater. It will bring tears to the eyes of any police officers in your team!

Using the TSF2025 has an advantage over a lot of other methods as it can handle multiple CTCSS tones. Not simultaineously but providing all radios wanting to use it are on the same channel, R1 to R5, then the TSF will automatically accept any tone and use the correct one in order to pass the transmission out to the receiving radio. This means such a device can be used in any area or region regardless of which tone that team or region uses themselves.

This makes such a device very flexible if it has to be taken out of your own operating area. It's main use would be to provide wide area comms in the event of a major incident for example. Providing all radios use the same mobile repeater channel, it doesn't actually matter which one it is and nothing needs to be done at the TSF2025 end to accomodate this, it's completely automatic.

Conversely, using the same system, two or more teams can access the same repeater with each using different CTCSS tones. This is the so called 'Community Repeater' system and up to eight different tones can be used although there are only five available for UKSAR mobile repeaters so enabling communications for five people or five teams without each team being able to hear another.

Strictly speaking, transmit inhibit should be used with systems like this as otherwise anyone using a different tone to that of another team could transmit over the top of them because they can't hear anyone using a different tone to themselves. Tx Inhibit prevents this happening by refusing to allow the radio to transmit if there's another carrier on the channel.

A huge number of user programmable facilities are available from selcall, timed events, battery backup warnings sent over the air etc etc.

As already mentioned, this is really a 'Major Incident' application but might find use with teams looking for a flexible approach to mobile repeaters on the UKSAR channels.

With thanks to the Team Simoco engineers and our own Mark Lewis for their help in getting this working.

As a footnote to the above, two radios on different mobile repeater channels, R1 to R5 can't talk to each other as they don't use the same CTCSS tone. This is after all the point of using CTCSS in the first place. However, trying it through MRMap I notice that GPS does get received and processed regardless of which CTCSS tone is used even though the base can only ever be on one of the channels at any one time. A radio on R2 can't talk to one on R3 for example but the GPS position report from both is received by the base. I'm still trying to work this one out although I've a fair idea as to why it's happening.

I suppose this means that should a radio appear on MRMap that you can't hear and it's not shown as a remote, it does at least tell you someone on another mobile repeater channel is operating into your repeater. I'll have to think about this to work out whether to see it as a good thing or to work out how to stop it happening. Anyone else's opinion on this would be interesting.

Having now had chance to take it a stage further, by fiddling about with the built-in event timers it's possible to set these repeaters up to switch themselves off (Tx, not Rx or you can't switch them back on again.) The operation is controlled by sending a selcall sequence from your base or portable radios and this switches on a timer in the repeater. Unhindered, this timer will run for one hour and then disable the transmitter in the repeater.

However, if a transmission using any of the R1 to R5 UKSAR CTCSS tones is received by the repeater, the timer is reset for another hour. This length of time is arbitrary of course and can be longer or shorter to suit your needs. There are three available timers which can easily be cascaded to give longer times and a single timer gives a tad over 1.8 hours as the maximum duration. Hence using them all you have 3 x 1.8 hours or any combination in between.

Providing that someone makes a transmission at least once per hour then the repeater will keep running all the time. As soon as it's quiet for longer than an hour it will switch itself off and then needs the selcall sequence to bring it back up again. As MRMap will poll your mobiles every two minutes or so, this will keep the repeater running as long as MRMap is. Once everyone has gone home, MRMap will continue to poll for a default period of 30 minutes. If the repeater timer is also set for this duration then as MRMap shuts down, so does the repeater.

If the necessary selcall sequence is programmed into your radios as a Channel Encode then a button needs to be programmed on the SRP portables in order to send it and switch the repeater on. In the case of the SRM9030 base radios, you again program as Channel Encode but now the sequence is sent each time the green button is pressed when you're on the repeater channel. On any other channel, it does nothing.

Not necessarily a major leap forward in terms of usefulness but it might find a use with someone. I can let you have the config file should anyone need it.

For those who've asked, attached is an example config file for a TSF2000-based UKSAR repeater. This covers all mobile repeater channels R1 to R5. It can also handle three more channels but these are not currently programmed. As it stands, it's rather more of a test-bed config than a working one although it will work as-is if you want all the facilities is has.

It's operating characteristics are :-

1... It will work on any of the five UKSAR mobile repeater channels, R1 to R5, without needing any changes to the repeater itself. It automatically selects the correct tone to send in order to match the one being received. This means it will work in any team area where they are using a mobile repeater and already have their portable radios programmed for one of the R1 to R5 channels. You don't 'switch' the repeater to R1 to R5, it just works out which one you are using and acts accordingly.

2... It has a hang time of 5 seconds during which a pip-tone is transmitted every 900ms. This can be used as-is or disabled from the programming software. It's primary use is to tell you that you have access to the repeater, as a 'comfort' tone for users to tell them they are still within range. I use it to tell me the same thing as I'm driving around and testing coverage. It means I can do it from the car without needing anyone else to man base etc. If you key it up and get the pip tones back for a few seconds then you're within range. The hang time has no effect on any other comms or on your radios as most voice transmissions last longer than 5 seconds and the hang time just extends the length of time you are speaking by 5 seconds. If you switch off the hang time but speak for 5 seconds longer, it has exactly the same effect, none at all. A long or at least noticable hang time on a repeater has no detrimental effect on it's function but isn't something most are familiar with from using straight portable to base type comms. It does take some getting used to.

3... After 30 minutes of inactivity, the repeater will switch itself off and no longer responds to incoming signals in the normal way. Once this has happened then the receiver remains active but the transmitter is now disabled. Should you wish to re-activate it then you need to send a selcall sequence (54321 at the moment). This uninhibits the transmitter and switches it back into talk-through mode where it now works normally. Providing that a transmission with one of the five correct CTCSS tones is received by the repeater inside 30 minutes then it will continue to function for as long as you wish. As soon as no signals have been received for 30 minutes then it will again shut down. Whilst ever the repeater is receiving one of five correct CTCSS tones then it can't switch off mid-sentance. There always has to be 30 minutes of no transmissions before it will shut down.

4... It passes GPS position reporting data without any problems.

If you think about it, MRMap sending out group polls every 2 minutes or so will keep it running as long as this is the case. After a preset period of no activity, MRMap itself will shut down and 30 minutes after that, so will the repeater.


All the first three functions are fully programmable and you can reduce the hang time or remove the pips or a combination of both, as you wish. The 'ON' time can also be set to any value up to 1.8 hours using one of the three available event timers. These can be cascaded if you need longer times. Here only one is used.

Any transmission made during the hang time, when the pips are being transmitted, immediately cancels them and the transmission continues as normal. The pips only re-start once the transmissions have ended. You don't have to wait for the pips to finish before you can speak.

The TSF2000 programming software was available on the Team Simoco website but for some reason all software appears to have been removed from the site. I have no idea why this should be the case as the ability to check whether the programming of the radios is going to be something you can handle yourself is best done by having a play with the software before you shell out for any hardware. As we are still subject to re-programming exercises at fairly regular intervals then it's very handy to be able to do your own programming. In fact in my own opinion, it's essential to do your own programming or you will have to pay someone to do it for you and you could be stung.