HamGadgets News

I’ve added the Rockmite II kit from QRPme to the catalog.  I have a small stock of kits ready to ship immediately, along with an even smaller number of hard-to-get cabinets.  I have kits in 80, 40, 30 and 20 meter flavors.  Great for saving on shipping if you’re ordering a Rockmite along with some fine HamGadgets kits!

When you’re playing with Morse code and microcontrollers like the PIC (my personal favorite), you need a way to store the Morse characters in a way that makes sense.  Since devices like these have very limited program memory and even less RAM, the efficient use of memory is a big concern.  Your PC may not care if you use an extra few kilobytes here and there, but a PIC or other embedded controller will quickly run out of memory if you’re not very conservative in your use of memory.

I’ve seen quite a number of different ways in which people store Morse code characters in memory.  Some make more sense than others.  One that I saw works well when only a very limited number of symbols need to be stored – just letters and numbers without punctuation.  A single byte was used for each character, laid out like this:

Bits 7, 6, 5:  Number of elements (dots and dashes) in the character
Bits 4, 3, 2, 1, 0:  The elements themselves; 1=dash, 0=dot

Do you see a problem here?  Even though you can define a character with up to seven elements, you’re limited to storing only up to 5-element characters.  So, no comma, period, question mark, SK, and so on.  While it may work for some applications, it won’t work for most.  It’s efficient (using only one byte per symbol) but relatively ineffective since it doesn’t cover all of the symbols — including some that are very commonly used.  (I did see a workaround to allow six-element symbols, but it would require some additional code.)  Another method I have seen overcomes this by using a two-dimensional array to store the length of each symbol and its elements in separate bytes.  It’s effective, but very inefficient in that it uses twice the number of bytes needed.

Part of the difficulty is that Morse code symbols (characters) are variable in length.  Unlike ASCII characters, for example, which are all eight bits long, Morse characters are not all the same length.  They range from one to six elements (dots and dashes) long.   In fact, make that seven if you want to include the obscure “SX” prosign for the dollar sign ($), which I’ve never actually heard of being used, but Wikipedia says it exists.  So we really need to know two things about a Morse symbol: it’s length, and its actual sequence of dots and dashes.  We need to have at least six or possibly seven bits to store all of the letters, numbers, punctuation, prosigns and non-English characters.

The method that I use is very simple and allows for all Morse symbols.  The eight-dit “error” symbol does require slightly special handling, but it’s a special case in itself so that turns out not to be a problem.  In my method, anywhere from one to seven bits are used for the dots and dashes, with one extra bit indicating the end of the character.  Here’s how it works.  As with some other methods, dots are represented with a 0 and dashes with a 1.  Elements within a character are stored “backwards”, with the first dot or dash in the least-significant bit (LSB) and moving to the left from there.  A trailing 1 bit is added to signify the end of the character.  Confused yet?  Let me try to clarify.  Let’s take the example of recording characters sent with a paddle…  for example, to store a message in a keyer’s memory.

Start by initializing a variable to binary 0.  Now, as dots and dashes are received, they are right-shifted in from the most-significant bit (MSB).  Let’s say we are storing a Morse “L” (._..).  Here’s how that progresses:

0000 0000	Nothing received yet
0000 0000	Dit (zero shifted in from left)
1000 0000	Dah (one shifted in from right)
0100 0000	Dit (zero shifted in from right)
0010 0000	Dit (zero shifted in from right)

So now we have hex 20 stored. We also know that we’ve received four bits.  We just need to get that into a usable form.  So, let’s use another variable byte, initialized to 1 (0000 0001),  We’ll then left-shift the four bits back OUT of the first variable and into the second, like this:  Variable 2  <—  Variable 1

Variable 2	Variable 1	Count
0000 0001	0010 0000	0
0000 0010	0100 0000  <-0	1
0000 0100	1000 0000  <-0	2
0000 1001	0000 0000  <-0	3
0001 0010	0000 0000  <-0	4

This shifting of the bits is a crucial step (and of course there are other ways to do it).  Now we have the character stored in Variable 2 in a very easy to use format.  It involves a little extra code to when when the dots and dashes are received, but pays off when they’re stored and sent.  The Morse code “L” is stored as binary 0001 0010, or hex 12.  To send it as Morse code, we simply right-shift the byte, reading 0’s and 1’s out of the LSB and sending either a dot for 0 or a dash for 1.  Before each shift we test to see if the byte is equal to 1 — if it is, we’re done sending.

If you need to store and send the “error” symbol (……..), you’ll need to add code to detect when the byte is equal to 0 and respond appropriately.  In practice, I have yet to discover a case where I need or want to store and play back that particular symbol.  If it’s detected as an input while recording (easy to do — length is 8, byte is zero), it means the user wants to back up to the beginning of the last word and re-send it.  The symbol itself never gets stored, only detected and acted upon.

This method of storing Morse symbols is both efficient and effective.  All Morse code symbols can be stored, and all take up exactly one byte of storage.  There is only one special case (the error symbol) that needs to be addressed and it’s a symbol that you will likely never want to store anyway.

I really wish I could take credit for thinking of this.  it’s simple, elegant, and it’s worked perfectly for every Morse code application I have had for over ten years now.  I am, however, pretty sure I got the idea from reading something back in 2002 or 2003 when I was working on the original PicoKeyer.  It’s been a lot of years, and I cannot recall where I saw it or who did it…  but to whoever it was, thanks.