The Development Journey, Part I

I was born with an inquisitive mind and my parents let me run with it. Later, when I entered the work world, I began a prolific career, by many standards, of creating products. It has taken me to some interesting places and rounded me out with extensive knowledge in evolving products for several markets. My 50-plus years in electronics and software abound in products with and without microprocessors, so, of course, when the Arduino turned up, it drew me in. I just wanted to play with it. Naturally, I had a few ideas.

A bit of background first, though.

Early Thinking about HF on Arduino

To begin with, in 2005 the Arduino project emerged from a bar in Italy as a tool for students in a graduate design program. Their course requirements were, and presumably are, to create “devices that interact with their environment.” (Wikipedia, “Arduino”) Intrigued by the concept of this open-source hardware and software company, I joined their community of several hundred thousand novices and professionals in October 2017. By that time, the platform had undergone several revisions and acquired a great reputation as a popular educational system that teaches programming and basic electronics. In my case, I wanted to figure out how far I could take a project on that platform.

Reader, please realize that my first experience with chips like these was back in the mid-1970s. For $11,000 my company could place an order for 1000 pieces for a computer-on-a-chip. We’d have: 2K of read-only memory, 64 bytes of random access memory, a 4-bit CPU and four 8-bit parallel I/O pins in a 40-pin package. Better get your code right!  You would not believe what we could do and did do with those chips. Our market competitors sure didn’t.  🙂

Early Arduino DevelopmentFifty years of microprocessor development have wrought amazing advances. The Arduino has an astonishing 32K of program memory, 2K of RAM, and a bunch of I/O pins as well, costs only about $1.50 and runs about 200 times faster. Wow, how things changed! Low price, extensive resources and no operating system required or even desired. You program right to the metal, so to speak. Which is what I have always preferred. Yes, I dislike programming on top of operating  systems.  So, no Raspberry Pi for me, thank you.  At least for this project.

My early experiments with Arduino included this weather station of sorts. I had plans to build an indoor/outdoor wireless system, but I ran into a problem that needed to be solved. I call it the “Prepper-HF Problem.”

A transceiver problem without a solution

It came to my attention that hams here in the Northwest needed a small HF transceiver that would also be a Morse code translator, mostly for emergency use. Some of them were also asking whether we could take a bit of the pain out of learning Morse code. They didn’t have the time or the inclination to master CW, but they might need it in a crisis. A few wanted to learn Morse code—but without the intense studying and drilling. Present me with a conundrum like that, and I’m on it.

The weather station project had already familiarized me with Arduino programming, but the display that came with it? I had my doubts. Would it work for a Morse code decoder? Nope. Two lines of 40 characters was not going to cut it for a transceiver that could encode and decode 

By and by our research singled out a 3.5″ full-color touch panel, with built-in memory to store lots of graphic elements and a programming language all its own, apart from the other hardware and software. The Arduino simply had to send text commands to the GUI’s computer, and it would perform the operations, including graphics, buttons, changing pages, displaying text or returning text entered by the user.

Birth of a Morse Code Translator

Originally, I’d planned on a fairly large front panel for my Arduino ham radio, with lots of LEDs and knobs and not so much of a display – maybe a four-line, 80 character display for incoming and outgoing text only, not a lot different than the display in the weather station, only bigger. The operator interface is a plug-in keyboard, since the design goal is to type in your message, not key it in with Morse code. Everyone knows texting; the computer translates it into code.

I like to point out that my team was arguing, “Use keyboard commands. Get rid of most or all of the knobs and switches. Make it small and portable.” Great! The results tell the story. Don’t be fooled by the Arduino name or the tiny size of the DMX-40 when you see it. It’s crammed with features! Critics would say, “Impossible with such a simple chip.”  Not me. “Simple chips” don’t have to be that simple. I’ve always used less to get more. 

The first hurdle we faced was the input-output requirements. We have a digital frequency synthesizer chip, several digital volume control chips, the outgoing CW, the incoming signal which is not yet CW, the CW IN LED, several other LED’s, keyboard input, debug serial ports, serial ports to the display, band selection, timers for CW in and out, lots of stuff. Too much stuff for one minute Arduino, right?

Working with Dual ArduinoChoices, Choices

However, when it came down to the realities, the biggest issue for me, in fact, was serial ports. Because we wanted to keep a serial port free for debugging, we added a software serial port for the display.  What to choose? The Duo, the Raspberry, something else? We chose the dual Arduino and allocated its duties. I/O was tailored to the capabilities of the chip and—bonus!— we got a 2X gain in available memory resources.

As you can see, our two-Arduino experiment was off to a good start, with the 3.5″ LCD and a rotary knob for frequency control.  We would later chuck the knob.

Continued in Part II.