I always have a couple of radio or microcomputer 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:
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.
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 August 2018 I have the RX clock recovery, HDLC decode and RX CRC checking all working. I’m current adding in some oscilloscope synch outputs, to help analyze modem RX eye patterns. Next step will be to add in TX functionality, then Digipeater (conventional and possibly APRS) and finally the KISS interface. I hope to have it operate in full duplex so that I can include loopback tests. Note that this project is only using the Arduino UNO hardware platform and not the Arduino IDE. When development is completed I’ll try to see if I can retro-fit the software into a form that works with the Arduino IDE, so that those unfamiliar with Studio 7 can make changes to the code using the Arduino IDE and not have to rely on Studio 7 and an ICE. For the modem I using the discontinued (but still available on eBay) TI TCM3105 Bell 202 modem chip. If it turns out I find that I need more buffer space I may move the project from the ATmega328P (2K RAM) to the ATmega1284P (16K RAM).
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 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 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).