How I controlled the transceiver and went on air via a push-button telephone

Today, reviewing my old documents, I remembered one interesting thing related to amateur radio communications, and decided to quickly write an article about it. We will talk about remote work on the radio, but not via the Internet, as many would immediately think, but via regular mobile communications. It was ten years ago, when no one had smartphones yet, they were just starting to appear. And I had push-button phones until 2017. I have long known that if you press buttons during a conversation with a subscriber, the subscriber will hear a sound from these buttons. This sound is similar to the tone dialing of a regular landline phone. In principle, I had already learned earlier that these sounds are standard DTMF signals. The topic of DTMF signals and my practice of using them in various applications would deserve a separate article. But this article will talk about their use for transceiver control. So, I had the following idea. You can connect the phone to the DTMF decoder, and it in turn to the microcontroller, use it to process the sequence of DTMF signals according to a given algorithm and connect the CAT interface of the transceiver to its UART output. According to this scheme, you can implement transceiver control via DTMF signals. In turn, connect the phone to the transceiver via the audio path, and then you can work on the radio via the phone. I immediately started doing this.

I already had a DTMF decoder board that I made back in my school days. according to this scheme. The board contains the IL9270N decoder chip itself (analogous to EKR1008VZh18), a decoder, and logic inverters. I connected LEDs to it, then thyristor keys and 220V bulbs, but that's another story. Then this board was abandoned because it was not in demand. I took it as the basis for my design. More precisely, for the periphery. And as a basis – a breadboard on the ATmega8 MK, which I made the day before. I was just starting to program the AVR MK in more detail. From the DTMF decoder board, I extracted all the chips, except for the decoder itself. I soldered 7 wires to its outputs: 4 data lines D0 … D3, 1 activity line OE, 5V power supply and GND ground. I also cut off the LM7805. I connected these wires to my breadboard with the MK. I connected the UART interface to the CAT interface of my transceiver. There are two options, depending on the transceiver. If the transceiver has an interface with TTL levels, then the MC can be connected directly. If RS-232, then via a converter on the MAX232 chip. Everything is standard. I have an SDR transceiver, and I connected via MAX232 to the PC COM port. But this does not change the essence. To be honest, I did not yet know how to work with the UART MC for reception. Fortunately, in this case the UART is one-way (TX, GND). And it did not matter to me how the transceiver responded to my commands.

The diagram (Fig. 1) shows how I paired the audio path. This is a simple case of pairing. But my situation was different. I have a mixing console on my desk as an audio signal router. I connected everything through it, using several input channels and AUX sends. This connection allows you to set the volume levels on each line, including for sound recording if necessary.

The algorithm of operation of this complex was supposed to be as follows. On the table lies a mobile phone, connected to the device and set to auto-answer. I, being far from home, call this phone from my phone. Tariffs at that time already allowed to have free or penny communication. The phone accepts the call, and I hear the radio. If the transceiver is turned on for transmission, then everything that I say into the handset will be transmitted to the air. And I will turn on the transceiver for transmission by pressing the buttons on the phone, which, as already said, transmits a DTMF signal to the subscriber when the buttons are pressed. That is, I press the button, thereby forming a DTMF signal corresponding to this button. This signal comes from the audio output of the base phone and is fed to my decoder, then its code is sent to the microcontroller. It in turn forms a CAT command for my transceiver – reception or transmission. The idea immediately arose of not only switching the transceiver to transmit or receive, but also fully controlling it: changing the frequency, switching ranges and modulation types. The disadvantages of such control are obvious – it is “blind”. That is, on my side there is no display with information or audio response about the success of control. You can only navigate indirectly – by changing the sound from the transceiver. But, even with such disadvantages, it is still unique and interesting. By that time, I had already heard radio amateurs on the air who worked remotely via the Internet, but in their case it was a purchased transceiver with an unpronounceable price. And in my case – everything is much simpler and cheaper. And in general, mobile communications, in my opinion, are more reliable and better quality than the Internet in terms of sound transmission.

First, I studied the CAT interface protocol, taking the configuration file from the OmniRig program corresponding to my device as a basis. The protocol turned out to be text, which allowed me to pre-test it manually via HyperTerminal. Then I started writing the firmware. Frankly speaking, I'm afraid to look into the code now. Although, everything is fine there, with minor exceptions. There are a lot of nested switch cases. The main thing, looking ahead, is that the program worked without a failure. The program algorithm includes processing of button pressing sequences (numbers from 0 to 9, *, #) and recognition of the commands I have provided. Entering a command begins with pressing the “*” key, then entering the command number, after which the “*” key is pressed again and the value for the entered command is entered (if provided). Pressing the “#” key executes the entered command (if defined) and the control returns to the default mode. In this mode, the buttons mean the following functions. “1” – rebuild up by 100 Hz; «2» – tune up by 1 kHz; «3» – tune up by 5 kHz; «4» – tune down by 100 Hz; «5» – tune down by 1 kHz; «6» – tune down by 5 kHz; «7» – memory cell back; «8» – switch to reception; «9» – memory cell forward; «0» – switch to transmission; «*» – start entering a command. As you can see, inside the MC I also provided frequency memory cells. Now about the commands. In total, I made four commands. «0» – enter the frequency in Hz. Example: *0*3675000# – tune the transceiver to a frequency of 3675 kHz. «1» – change modulation. Modulation number – according to the protocol description from the configuration file in the «set mode» section. «2» – switch to a memory bank; «3» – create a cell in a memory bank. The command has no arguments.

Now about the practical use of such a device. I never finally implemented the device on a finished board. I used it for 2.5 years at most, then I got tired of it. I used it mainly when I went on long bike rides. As a conscientious radio amateur, upon returning home I entered the radio communications I made into a log, having previously listened to the audio recording, which was constantly being made during remote work. When a smartphone with mobile Internet appeared, I controlled the transceiver (SDR) via TeamViewer. But the sound was still transmitted via a separate independent channel – through the same regular mobile communication. The sound quality when receiving stations, of course, differs from the sound in the headphones near the transceiver. Quiet stations are hard to catch, and the sound can sometimes be briefly interrupted. There are delays, but they are insignificant for normal work on the air. It happened that I pressed the transmission and lost the mobile network, being far from the city. But basically I was very pleased with the work through this complex. When transmitting, my voice was also unique. Considering the voice processing in the mobile communication path, I turned off the compression and equalizer on my transceiver for transmission.

Nowadays, new generation transceivers have replaced old transceivers, and the topic of remote work on the air already sounds like a given. But this idea, which was discussed in this article, does not lose its relevance. After all, not everyone has such expensive modern transceivers. And not everyone has Internet access everywhere. Especially among elderly radio amateurs. I have been repeatedly asked how to make such a design themselves, and asked to help with this. Over time, I plan to make it on a single board and implement CAT protocols for popular transceiver models (Yaesu, ICOM).