As some of you may know, I’ve been involved in Cambridge 105’s ‘Pirate Cambridge 105’ special event – a 12-hour live broadcast from a riverboat moored on the River Cam, intended to celebrate and reminisce about the golden era of Pirate Radio.
In keeping with the theme, we limited ourselves to only using equipment from the 1960s and 1970s. For mixing desks and audio processing, that’s an easy deal as long as you can get hold of the gear. (It’s amazing what people have hidden in the back of their garage.) But this left a crucial question: How do we get text messages and emails using only 1970s gear?
The easy option would have been to say that we don’t take listener input during the day. But we’d already started making arrangements to broadcast on the Channel 292 frequency, 6070kHz shortwave. This meant that we’d potentially have many more listeners across Europe, so hearing from them would be great.
One bit of technology that did exist in that era, of course, is radio teletype (RTTY).
For those who aren’t familiar with RTTY, essentially you have two audio tones which represent 0 and 1 respectively. Encoding characters in the 5-bit Baudot code, you can set up a radio transmitter to rapidly switch which audio tone it is sending, which lets you transmit characters.
By modern standards, RTTY is incredibly slow: about 50 baud (50 bits per second, or 10 characters per second), but it works.
Originally, the receiving end would have been a teleprinter, which was essentially identical to a mechanical typewriter, but connected to a radio driving it.
So how did we do it?
Well, we didn’t have a genuine teleprinter available, and besides it would have been too noisy next to a radio microphone even if we did. Instead, we got a couple Raspberry Pis (running Fldigi, which allows you to transmit and receive RTTY in software).
At the transmit end, a script on the Pi grabbed incoming texts, tweets and text messages to the studio and sent them to a radio every 2 minutes. Messages were truncated at 200 characters (to avoid using all the receipt roll at the other end!) and word wraps had to be inserted every 40 characters, which is the width of the receipt printer font we were using.
At the receive end, the other Pi did the decoding – yes, we broke the 1970’s equipment rule, but the technology was still of the era – and sent the result every minute to a dot matrix receipt printer.
Messages that were OK to read on-air could then be given to the presenter by hand, on tiny pieces of receipt roll.
I don’t know whether we’ll ever have cause to use this system again but, if we do, we need to detect the end of messages rather than just doing the print every minute. We hadn’t expected the volume of messages we received (we used most of roll despite the truncation!) and this meant a significant number of messages got cut as they were printed mid-transmission.