CW Beacon Keyer

You might be wondering why activity has been a bit minimal lately. Well, our first child was born almost one month ago now so I’ve been a tad busy. šŸ˜‰ I’ve got a couple of more things coming up soon, but hopefully activity will resume in the next month or two. šŸ™‚

That said, in the meantime I’m reading and where possibly playing with simpler things.

For example, some months ago I decided to start looking into microcontrollers. I pondered between AVR and PIC and in the end with with AVR. So I grabbed myself an AVRISP mkII and a few ATtiny chips and built up a basic development board following instructions on I Make Projects. Within a short time I had a flashing LED but then got busy.

Anyway, I had decided a great first MCU project would be a CW Keyer (mainly for QRSS on LF, but also wherever else). These can be implemented many ways (and indeed, there’s many bits of code one could download) and many simply hardcode the sequence for the callsign. However, I wanted to learn and build from scratch – plus it was a great opportunity to do some C programming.

To that end I decided to write up a library that would provide encoding of a string into a CW element sequence. I could then enumerate over this sequence generating the matching delays for the key-ups and key-downs. Further, I did calculations based on the PARIS methodology for the element durations for various common speeds covering 5WPM to 40WPM and QRSS1 to QRSS60. I initially wrote the library and unit tests on the PC with GCC, and then when it was ready just added it into an AVR Studio 5 solution.

With such a library, the resulting MCU specific code was minimal and I have two ‘configuration’ variables – one for speed and one for the string to send.

Yesterday I got this all working and successfully tested on my dev board with an LED. Doing so I learnt several things such as _delay_ms() requires a constant parameter and more significant how to use the AVR Studio simulator – very handy tool.

Oh, I also came to better appreciate the minimal memory contraints of the ATtiny chips. In the end my program had to be run on an ATtiny85 (although it may fit on a ATtiny45), this is due to the encoding library and it’s look-up tables being on the chip. This results in AVR studio stating SRAM usage of 240 bytes (ATtiny45 has 256 and ATtiny85 has 512). Strictly speaking there is no need for the encoding library on the chip so you could go smaller – you could run it on a PC, grab the encoded array and place it on the EEPROM and have it read from there. But hey, for now this is okay me thinks.

So the video shows the result with an LED flashing out my callsign at 5WPM. From here I just need to whip together a small number of components to have a nice standalone beacon/QRSS keyer – however, not entirely sure when I’ll have the time for this. When that’s done, I’ll be sure to share all. šŸ™‚
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s