This weekend, for the combined reasons of interference from Low Power Devices and also an opportunity to enable a new DMR repeater for Cambridge, the well-established GB3PY repeater has moved frequency. It was on 433.200MHz (+1.6MHz split) and is now on 430.900MHz (+7.6MHz split).

This brought an interesting question: other than website and email, how could the Cambridgeshire Repeater Group notify users of the repeater about the impending change? My solution was to add a voice announcement after the normal CW ident, initially saying ‘GB3PY will change frequency soon. For more information, see cambridgerepeaters.net’, and then adding in frequency information in the 24 hours before the change. This way the message was kept short and unobtrusive, whilst also giving everyone the notice they needed.

It wasn’t possible to get extra equipment for this special voice logic installed at the transmitter site, however, which meant that the announcement ran from my house, which brings its own set of problems: if the announcement were just on a timer, it would ‘double’ with any ongoing QSOs on the repeater, so the logic at my QTH needed to know the state of the repeater’s logic without having any special access to the repeater circuitry.

The solution that I came up with was rather hacky, but I am also rather proud of it. At the heart was a Raspberry Pi 2, running a fairly simple Python script. Transmit was generated by a USB soundcard attached to the Pi, feeding into my IC-706MkIIG, which was set on Vox, with a long (3s) Vox Delay, thereby avoiding the Tx/Rx switching happening mid-message. The audio file that was played started with a 300ms 1750Hz tone, not to open the repeater but rather to open the Vox circuitry on the 706 before the announcement started.

The setup for the GB3PY voice announcement

Reception of GB3PY was provided by a cheap RTL SDR dongle. Every five seconds, rtl_power running on the Pi, would sample the signal strength on 433.2MHz to determine whether a carrier was present or not. In my case, using a gain value of 20 for rtl_power, a carrier was a signal strength over -25dB. Other setups and locations may require different values.

The number of samples over which the carrier was present was used to determine the state of the repeater:

• 3 or fewer samples – that was a CW ident (or just someone quickly keying the repeater)
• 20 or more samples – this is an ongoing QSO
• 4-19 samples – other state (for example, someone calling for contacts)

The program does different things depending on each of these states:

• If it was a CW ident, which has now finished, and it was the 4th such ident, then call a system command to play the voice ident out of the USB soundcard
• If it is an ongoing QSO, just reset the counter on the number of CW idents that have happened since the ident was last played.
  This is so that if someone briefly keys the repeater immediately after the QSO ends, such as another person wanting to continue the conversation, the voice ident will not play and interrupt them.
• In any other state, just ensure we don’t play the file

Obviously, you may need to tweak the audio level out of the soundcard, for example with alsamixer, to get the levels right.

If other repeater groups are interested, you can get the code I used. It isn’t pretty but it works!