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.
I have two Teletype teleprinters that I like to operate occasionally, mostly for nostalgic reasons. One is a Model 28 RO and the other is a Model 15. I prefer the Model 15 as the rhythmic sounds it makes and aroma of warm oil coming from the running machine remind me of my early years of ham radio.
Loop Driver and ASCII to Baudot Converter
This is a simple Arduino based system that looks for ASCII serial data at 1200 bps on the Arduino’s USB serial input and bit-bangs BAUDOT serial data (timed via interrupts) out on a port pin at 45.45 bps. It also includes a 170VDC 60MA loop circuit based on two back-to-back HVAC 24VAC transformers from Home Depot (for voltage isolation) and a loop driver circuit based on the circuit used by HAL in the ST-6000. The HVAC transformers provide an isolated 120VAC at 40VA (the loop only needs about 10VA). The 120VAC when rectified and filter produces about 170 VDC. This Arduino/HVLoopDriver system allows any modern computer with a USB based serial device driver to run my ancient teleprinters.
RTTY Whiz Bang Project
The RTTY Wiz Bang project is like above, but the Ardunio code is tricked out to provide several concurrent processes. It’s an Arduino based system, using an Arduino Nano (although it could run on other Arduino devices) that provides for several concurrently running RTTY functions. One process generates a string of ASCII RTTY data from a canned message source (currently a news report from NASA about Apollo 11) and outputs that data stream on a data pin at 110bps but with padding between characters to acheive a rate of about 6 characters per second (the same character rate as 60WPM Baudo RTTY). Another process will take an ASCII UART stream as input on a data pin at 110 bps and output it on another pin as 5-level BAUDOT RTTY code at 60 WPM. Another process will take a binary data input on a data pin and command a Direct Digital Synthesis (DDS) oscillator to send one of two preprogrammed AF or RF frequencies (it makes FSK at either audio frequencies or radio frequencies up to about 8 MHz). Another process will accept line oriented commands on the Nano’s USB serial port and take the requested action. The command processor is primarily used to set configuration data for the Arduino, such as setting the DDS FSK frequencies (resolution to 1 Hz), setting the ASCII strings for an eventual selective calling mechanize and WRU/answerback system (not yet implemented). All configuration data are backed up in the Arduino’s EEPROM. I’ve been working on this project, on and off, for about 3 years. It has served as a good learning experience for me, as I move from my archaic assembly language mentality to C programming on small machines. I learned C 40 years ago, shortly after I joined Bell Labs, but until I started playing with Arduino a few years ago, I had never applied C to small processors. I had always used assembly language programming for that (mostly on Z80s and 8051 processors).