Rebroadcast Without The RJ45 Crossover Cable

[Rob_Brookes]

A number of teams have recently begun enquiring about forward control vehicles where MRMap is run actually in the vehicle and tracking of team member's locations is handled by the personnel in the vehicle rather than at a fixed base. This isn't at all difficult to achieve but does cause some problems when it comes to deciding just how many separate radios are needed to manage this. In a never-ending search for the smallest installation, some teams have been looking at using just two SRM9005 radios to handle standard vehicle comms, GPS tracking of the vehicle itself, rebroadcast and local tracking of team members on the hill. All of this is possible using just two radios but it does require some innovative programming and not a little training of the vehicle operator. In an attempt to make this simpler, I've built up a rebroadcast device that doesn't make use of the standard, red, crossover cable. Using this cable takes away the two RJ45 connectors that are normally used to connect control heads or computers. This means accessory boards have to be fitted in order to recover these missing ports. There is another way however. The power and facility connector on the back of the radio does carry enough programmable contacts to do what we would want and without any connection to the normal RJ45 sockets. You need to add four wires between the two power contacts and slightly modify the configuration in each radio. This work is on-going and will be detailed in the next issue of the Rebroadcast Manual but I've here posted a cut-down version which should give a working idea of what's involved. This has been built and tested as far as it's shown here. It works as a normal vehicle radio and a rebroadcast unit. Due to the way in which my version is constructed, I can't fit accessory boards. This will be done a little later and I'll then test that side of things. In the meantime, if anyone wants to try this method, I can confirm that it does work. The audio transmitted by the rebroadcast unit is significantly louder than that sent by a device using the normal red, crossover lead so I may not have the levels set exactly right just yet. However, there's no distortion in the audio and MRMap works fine if plugged into the RJ45 socket of the TWC set so I can't be far off.

A spin-off advantage of using this method is that CTCSS now works exactly as you would expect it to, being programmed on Rx and Tx for each channel. It doesn't now need to be programmed in the 'Data CTCSS' option which should be left as 'Undefined'. With this in mind, take care that you use the 'PTT Ext' option and not 'PTT Data'. You might be forgiven for thinking PTT was PTT but in these radios it isn't. 'PTT Mic' duplicates what happens when the microphone PTT bar is pressed, as does 'PTT Ext'. However, 'PTT Data' duplicates what happens when Tx/Rx is handled by the red crossover lead. CTCSS goes all to pot as far as we're concerned and it no longer matters what you program into each channel, it won't work. This is a function of how community repeaters work in Australia but using the facility connector and 'PTT Ext' you can recover the CTCSS functions programmed for each channel. CTCSS now becomes a completely channel-by-channel function.

Please visit the download section for example configs and the Alternative Rebroadcast Method document.

[Rob_Brookes]

I've now tested the 147MHz radio with CTCSS active on both transmit and receive. This works OK and still allows GPS data to be correctly received and processed by MRMap. Although not critical in use, CTCSS does go some way towards reducing the steadily increasing level of interference on the rebroadcast channel. Next test is to reprogram the radios as a wide area repeater and see if that also works.

[Rob_Brookes]

Next batch of tests. This time I programmed the rebroadcast radios as a semi-duplex repeater. That is, one repeater radio transmits on 155.350MHz, it doesn't receive at all. The other receives on 147.475 but doesn't transmit.

Portable radios are programmed to transmit on 147.475 and receive on 155.350 making their operation semi-duplex. Working this way, the portable radios cannot speak directly to each other if out of range of the repeater. This is the wide-area type of operation used by some teams.

To make sure I could actually carry out the tests without the stunning silence when I get it wrong which leaves Sue drumming her fingers on the table usually, I also programmed the F7 (the handset orange button) to function as 'Repeater Defeat'. At the same time I programmed the display to change to 'Reverse Rept' whenever this function was active so there's no mistake as to which way around your own radio is. This adds a level of operational complexity to things but judging by what some of you out there are up to with these radios, reverse repeater would cause you few problems!

In operation, and providing all portables are within range of the repeater, then communications are normal in all respects and the users on the hill would not notice any real difference from simplex operation. They hear both sides of the conversation as they would if they were simplex in operation. Positioning of the remote repeater site becomes ultra-critical. It must cover as much of your team operating area as is reasonably possible. For direct comms between two portables or two vehicles then the 'Reverse Repeater' function is switched in by one of the two radios (not both). How you decide which of the two radios switches to reverse rept, I leave to you.

The base radio is programmed exactly the same as a portable or vehicle set and links to the repeater in the same way. Again, direct comms with any portable is only possible when the base switches to reverse repeater. One possible advantage of doing things this way is that the 'base' only needs to be a portable radio if it's in range of the repeater and the actual location of your 'base' can vary around the location of the repeater. This can sometimes be handy for big jobs like train, plane, or coach crashes were it's usually better to be flexible with your command positioning but you might not always be able to get a vehicle into a suitable location. Providing the user of the 'base' portable identifies him or herself as 'Base', it really makes no difference where they are physically and if they're leading the rest of the emergency services around it makes sense to be as mobile as possible.

This method of operation, again using the facility connections rather than the Simoco crossover cable, works fine and once again the repeater transmitted audio level was higher than it would normally be. Using this method, CTCSS performs significantly better than when using the red X-over lead although I have no idea why this might be.

The whole set of tests were repeated with and without CTCSS and it appeared to make no difference. MRMap decoded the GPS data from the portable radios with or without CTCSS. Using the 'Quiet Tail' function results in a significantly reduced squelch tail as the radio mute gates close. Operation is not the series of 'Shssssss' Shssssss, noises it normally is.

I didn't do much with the lead-in and lead-out times and the repeater tail value was set at 200 milliseconds as I don't like long hang times. Programmed this way, the repeater mute closes 200 ms after the portable drops carrier. It's still long enough to hear two mute gates close however. As only one radio in the repeater transmits and only one receives, users don't actually have to wait for the mute gates to close when whoever they are speaking to drops carrier. There is no switch-over from Rx to Tx by the repeater radios. You can speak immediately the other person ceases to transmit as the repeater is still open and will pass the message as normal. There is no need to wait for things to go quiet before you speak. In this respect I notice a number of teams are using the GPS data as a sort of 'Roger beep' that indicates the other person has stopped transmitting. Nothing wrong with that of course but unexpected non the less.

This type of operation is best suited to those teams who have either relatively flat areas of operation or who are blessed with a big mast in the middle of their area. Infill communications using rebroadcast vehicles is still perfectly possible and I've already tested MRMap through two rebroadcast devices so it will almost certainly go through a repeater and a rebroadcaster. Unfortunately I don't have enough spare radios to set this one up so if anyone wants to test this out, please let me know and I'll post your findings.

Conclusion:-
The use of the facility connector to provide the repeater or rebroadcast audio and PTT crossover connections works very well and has some advantages that outweight the small amount of soldering needed for the modifications. CTCSS now works as it should and the transmitted audio is very good indeed. Operation is reliable and consistant. The main advantage for in-vehicle systems is that the RJ45 ports on each radio remain available for connection to a tracking computer. This removes the need for any additional boards in a forward control vehicle for example.
A variation on this method is used by Langdale Ambleside team where an AW Communications digital switching device controls five otherwise independant radios using this method of audio/PTT operation. The original RJ45 connectors on each radio remain available and are the means by which I tested connecting multiple radios to a single instance of MRMap.
This thread is now closed unless anyone wishes to add their own views or experiences to it.