I always have a couple of radio or microcontroller projects underway at the same time. When I have something completed I usually will write it up for self-publication or if it’s something that may have broad interest I offer it to QST for their consideration.
Here are some things I’m currently work on:
AX.25 Packet Radio Full Duplex KISS TNC with Digipeater operating on Arduino UNO Hardware
I’ve been working on this project in an effort to learn how to use Microchip Studio 7 to debug code for the ATmega line of microcomputers. As of May 2019 I have the RX clock recovery, HDLC decode and RX CRC checking all working. With all that working I’ve ported the software back into the Arduino IDE so that others who are not interested in using Studio 7 don’t have to use Studio 7.
With that much operational I’ve taken a bit of a detour and have just about completed making a system consisting of five Arduino UNOs (four Unos each implementing an independent packet decoder and one UNO operating as a four channel peg counter) to compare simultaneously the empirical performance of up to four packet radio modems monitoring the same radio, as sort of a “fly-off”, to see which Bell 202 demodulator works best. I don’t have final data yet, but the preliminary testing is given me some surprising results.
Next step will be to add in HDLC TX functionality, then Digipeater (conventional and possibly APRS) and finally the KISS interface. My goal is to provide full duplex capability so that I can include loopback tests within the device. For the modem I using the discontinued (but still available on eBay) TI TCM3105 Bell 202 modem chip. RAM is tight in the ATMEGA328P, the processor in the UNO. I’m currently using two 512 byte RX buffers and two 128 byte TX buffers. If it turns out that that isn’t really viable, I may move the project from the ATmega328P (2K RAM) to the ATmega1284P (16K RAM).
The holy grail for the project would be to have the RX/TX HDLC packet processing AND the Bell 202 modem all implemented in software and running concurrently on one processor, such as the SAMD21 or SAMD51.
Cross Band Repeater Controller
This isn’t as fancy as it sounds. There are two problems (legal problems) that often arise when using a dual-band mobile transceiver to function as a cross-band repeater. This device (controller) attempts to correct those legal problems. First problem is how to achieve legal transmitter ID of the cross-band repeaters downlink transmitter. Most cross-band repeaters do not provide for legal ID in either the uplink or downlink direction. My solution is to have an Arduino UNO that generates CW ID every 8 minutes and transmits it via an extra HT that transmits on whatever freqeuency that the cross-band repeater is listening to for the downlink path. That will cause the cross-band repeater to rebroadcast that CW ID on the downlink transmitter, which solves the legal ID problem. The second problem is to provide a control mechanism at UHF so that the control operator can disable the cross band repeater if something goes wrong. I use the same extra HT and a DTMF decoder connected to the same Arduino UNO for that control function. When the UNO hears the correct DTMF sequence from that extra HT, the UNO will remove power from the cross band repeater, thus providing the required remote control of the cross band repeater by the control operator. Issues resolved.
Sound Card Interfaces
I’ve been working on some low cost sound card interfaces intended primarily for FLDIGI and FT-8. One interface, based on a low cost USB sound dongle, was published in the October 2018 issue of QST magazine. I’m currently working on a version intended for FLDIGI on VHF/UHF (no dongle this time) that allows for rapid switching between voice and data modes.
315 MHz and 433 MHz Short Range Data RX and TX Modules
These are modules that are often seen on Ebay that consist of a OOK (On-Off-Keyed) transmitter built around a SAW filter and a super-regenerative receiver with an on-board LM358 op-amp data slicer. I’m also starting to work with transmitters that are crystal based with a simple synthesizer to get the signal up to UHF, and superhetrodyne receivers that use the same principle for their local oscillator. I haven’t gone far enough yet with the superhetrodyne receivers to see if they are consistently more sensitive (and frequency selective) compared to the super-regenerative receivers.
Most of my effort with these consist of using Arduino processors sending UART formatted data via OOK modulation (that’s basically the same thing as CW — for those familiar with RTTY it’s transmitter ON for SPACE and transmitter OFF for MARK). At UHF it works pretty well. The first thing I’ve learned is that the data slicers in the super-regen receivers are AC coupled. The data do not need to be Manchester encoded, but you can’t send 80 UART frames of 0X00 (or 0xFF) in a row and expect good results. I’ve tried things like breaking each source byte into two nibbles, and then sending each nibble as a byte, where the nibble is in B0, B2, B4 and B6 with the compliment of the same nibble in B1, B3, B5 and B7, in an effort to ensure that each transmitted UART frame had an average bit duty cycle of 50%. It does meet the 50% duty cycle within the UART frame, but I’ve found it to be no more effective than simply sending two UART frames for each source byte, where the second UART frame is the compliment of the first (prior) UART frame. On the decoding end, when using that method of achieving 50% bit duty cycle, the program can ignore the duplicate inverted byte, or can check it against the prior byte for extra error checking. The second thing I learned (well, it was more like being “reminded”, because I did know this in the past from real-world experience, but evidently when I started working with these modules I “forgot it”), is that, over a radio link, an 8 bit checksum is no substitute for a 16 bit cyclic redundancy check (CRC) for error detection. The third thing I learned is that the ATmega processors do a very good job of rejecting UART frames produced by noise, because I get far fewer “random characters” from the receive UART when it is listening to radio noise than I would expect.
ATC – Automatic TelePrinter Controller
This is an Arduino Mega based project that accepts data from one of several sources in several different formats (USB Serial ASCII, RS-223 Serial ASCII, TTL Serial ASCII, TTY AFSK, TTY TTL) and will then output the data to one of several different types of hard copy printers. Specifically, a serial thermal printer (ASCII), dot matrix parallel printer (ASCII), or a heavy-iron TTY (Baudot Code) such as the Teletype Model 15 or Model 28 printers. The ATC provides power control for each printing device. It’s intended to run only one printer at a time, not several concurrently. I plan to have a self-published paper available in early 2020 that describes the system, firmware and hardware.
Low Voltage TTY Magnet Driver
The selector magnets in an old Model 28 Teletype have about 1.7 H of inductance. The classic way to get the selector magnets to quickly move the selector armature is to run them at high voltage with a high value current limiting resistor (150VDC, 2500 ohms). It’s getting harder and harder to find 120VAC isolation transformers to create the high voltage isolated supply. To work around this I’ve developed a electronic controlled magnet driver that runs from 32 to 36VDC. I plan to have a self-published paper available in early 2020 that describes the circuitry.