Silent GPS Data Over A Simplex Channel

[Rob_Brookes]

After a year of trying and a lot of help from Simoco UK and TMC Australia, I've finally worked out how to silently send GPS data over the normal, simplex voice channel used by most of us. This works with Simoco radios as far as the GPS side of things go but can also be used to mute other makes of radio so that GPS data sent by users of Simoco kit is not heard.
Updated 10/01/09

Silent GPS Data on a Simplex Channel.pdf

Note:- If the CTCSS side of things is omitted from this example then the remaining radio configuration values are also usable with a conventional, open channel, rebroadcast or repeater. Some of these values are quite different to those we've previously advocated using.

The actual muting of data by using CTCSS has been docmented already on this website and is easy to achieve. The problems occur when trying to do the same thing with a rebroadcast or repeater unit between base and the portables. MRMap uses several methods of generating position update requests (Polls). One involves handshaking between the radios and others don't. It was this handshaking function that caused the difficulties as it increases the number of data transmissions made by both the base and the portable but all of them are critical to the operation. If any are missed or corrupted then the whole thing fails. This type of poll is used when you click a specific radio. In the case of the automatically generated polls, a group number, common to all radios in a team is sent and this requires significantly fewer transmissions but is rather more fire-and-forget as far as MRMap is concerned. If the portables answer, so be it. If they don't then hopefully they will the next time a poll is sent. This method is easy to deal with, handshaking isn't. It also wasn't helped by the fact that I was going about it the wrong way so many thanks to the UK and Australian engineers who put me back on the right path.

The attached pdf file hopefully sets out how to do this and will be updated and re-posted under the MRMap Documents section as I work out the bits that are still to be sorted out. The fundamenal principle works but there are additional options that have yet to be tested.

In discussion with Iain at Bowland Pennine MRT, he tells me his team are now used to the FFSK data noise as heard on a Simoco radio. These sets largely mute out the noise and so it's not that obtrusive. It's also being used to tell the user that they are still within range of the base or in Bowland's case, the wide area repeater. In fact this is now becoming a commonly held view so maybe I took too long to sort this one out! However the data noise is not muted on non-Simoco radios and can be heard loud and long where only simple audio processing is used in the radio concerned.

The FFSK data sent by an SRP9100 portable is only at 60% of the level of a voice transmission made by the same radio and so isn't as loud anyway. Unfortunately some makes of radio ram everything they receive up to full volume and these are the ones where the data can be intrusive on a voice channel. Possibly this is a method to voluntarily adopt so as to be kind to the nerves of users of other makes of radio :-)

In theory, and it remains one of the things still to be tested, I can add a single selcall tone to the end of the rebroadcast or repeater TWC radio so that a 'bip' is sent at the end of the transmission, this too can be reduced in volume below that of voice in most makes of radio that have any level of sophistication. Normally you wouldn't do this as you run the risk of the selcall not being decoded correctly but in this case we don't want to decode it, only to hear it. Possibly this can replace the 'comfort tone' effect of the FFSK data noise with something that doesn't jangle the nerves of others quite so much. At the end of this year it will be recommended that all teams add the 218.1Hz CTCSS tone at least to the transmit side of their radios. This will ensure that you can still speak to any team who opt to use full CTCSS on both Rx and Tx. It won't stop you hearing the data noise though. Only full CTCSS will do that and at least you now have the option to use this method through existing repeaters and rebroadcasters should you wish to.

If anyone would like to use this method but runs the risk of buring a hole in the kitchen table, send me a couple of SRM power leads and I'll wire them up for you. I can provide example config files for those who would like to try this out but hopefully there should be enough information in the attached document for you to work it out. If there isn't then please let me know as there's supposed to be!!

[Rob_Brookes]

Some of the items remaining from the previous work:

Having now tested the new method using a low band to high band rebroadcast device, I can confirm that this too works perfectly and produces silent GPS data on the simplex channel normally used for voice transmissions. This is not actually surprising in any way but I do like to actually test anything before I say it works! The low band link system is used by a number of teams in the Lakes and should they or anyone else wish for silent GPS data then this can now be achieved without loss of performance in any other respect.

Also tested at the same time was the fitting of the original, red RJ45 crossover cable in parallel with the crossover connections made to the rear D-15 connector. This lead, in it's as-purchased condition has more connections made than are necessary for this application including crossed over audio and PTT. However as has already been explained, the PTT connections are also the ones that handle the channel change commands sent by the remote channel changing function used in systems such as the one Kendal MRT have in place at their remote site. This is capable of operating on any high band channel but the channel changing is handled by command signals sent over a low band link and not by BT landline.

In theory, only the two connections on pins 1 and 2 are required by the new system but as a lot of teams already have the Simoco crossover cables and before I go anywhere near suggesting that you butcher them down to two connections only, I tried plugging in the unmodified cable. Rather more surprisingly this again worked perfectly and the remote channel changing function was restored. GPS FFSK data continues to be inaudible but the selcall sequence used to initiate the channel change is heard in the speaker of the receiving radio. However this is sent only once for each channel change and was always audible anyway.

As I'm never keen on connecting up things that I don't need, I butchered a spare 18 inch CAT5 patch cable by cutting it in half and cross connecting only pins 1 and 2. This turned out to be the brown pair in my cable. Again this restored the channel changing function but without any possible funnies introduced to having additional audio connections in there using the original crossover cable. I then tidied up the new cable and sealed the joints. This is now permenantly installed in the cross-band demo rebroadcast.

Still To Do:

This method appears to be the optimum for making up a rebroadcast device based upon a pair of SRM9005 radios. It works well and handles most if not all of the extra requirements needed by some teams. If there was to be a 'General Purpose' rebroadcast system then this is possibly it. Whether that be in-band using a diplexer or cross-band using either a low band or UHF channel feeding the high band TWC radio.

Left for me to test is only the effect all of this has when a duplex repeater is used. I can quite easily set one up using a pair of SRMs but it's not quite so easy using a TSF2000-based system. If anyone wants to give this a try for me (Iain....?) then it will make it easier for me as I don't have access to a TSF until one of my Lakes colleagues comes on-shore once again. The engineers at Team Simoco have suggested a method of duplicating all that a straight SRM9005 can be programmed to do and it doesn't look too tricky at all.

It's also quite possible that this method could be used with commercial repeaters made by other companies but I don't have access to any so can't say on that score. Again, if anyone does have one of these devices then the principle of what I've described here can still apply (Mark....?) Exactly how it's done would depend on how flexible the programming software is however.

[Rob_Brookes]

The Repeater Tail value in both rebroadcast radios has now been successfully reduced to 320 milli seconds with no apparent disadvantage. This makes all lead-in and lead-out values the same in the portables, rebro radios and the base radio.