NJQRP MicroBeacon

DESIGN

Bob Applegate, K2UT (project mgr)
Last update: 01/24/1998

After today's great meeting, I got inspired again to work on the beacon/keyer (I might use the term "beacon" or "keyer" interchangably; they're the same thing). There were some real big technical issues dragging down my enthusiasm for the project, but Jim, WK8G, came up with the obvious answer that solved a lot of the big headaches. More on this later. BTW, I (K2UT) am doing the web pages directly related to the keyer to take some of the burden off George, so blame me for the different "feel" of the pages.

At this point, we generally know how the front panel and user interface will work. The controls will consist of the following "devices":

• Analog control for sending speed (pot).
• 12 button keypad for entering data, selecting memories, etc (telephone keypad).
• 2x16 LCD display (2 lines of 16 characters each).
• Output to the rig (probably a transistor keying to ground).
• Input from a paddle.
• Three output bits for control of the optional attenuator.

Hey, why isn't there a power switch or a straight key input? Easy: the power switch is really external to the keyer in that it goes between the power connector and the beacon's PC board, and the straight key can short the rig connector to ground external of the beacon. No need to include those as part of the beacon design that I can see (opinions welcome).

One of the big problems was related to timing inside the software due to all the real-time issues involved. The keyer software needs to do these basic jobs:

• Read/debounce the paddles (requires timing to do debouncing).
• Do character element spacing to turn on/off the output at the proper time (an element is the length of one dit, which is used to make up dits, dahs, intra-dit/dah spacing, and spacing between characters).
• Read/record non-volatile memory used for the memories. The memory will probably be done via a serial EEPROM which requires careful timing.
• Send/receive data from the computer port. Have to pick a baud rate and stick to it!
• Scan/decode/debounce the 12 digit keypad. Again, lots of timing for debouncing.
• Send data to the smart LCD display. Non-critical timing, but we can't delay too long or the display will be slow to update. It would look sort of silly to have the display update only when nothing else is happening.

Yes, there are lots of timing issues, and probably a few that my mind held from me just to let me sleep at night The other big concern was getting a processor with enough I/O lines. From what I can gather, we'll need about 20 I/O bits (ouch!).

There is where Jim comes in. After the main meeting, he was eating lunch and we got talking about embedded controllers. I mentioned the timing issue and all the I/O lines and he suggested an easy solution: add another processor! The other processor would do some of the I/O and timing intensive operations and leave the main processor to do the main jobs.

We need input from the group in selecting the hardware. The components up for discussion are:

• Part 1. Display and keypad
• Part 2. Processor(s)
• Part 3: Memory for message memories
• Part 4: Attenuator design (in progress)

Please check into those pages and provide comments.

73,
Bob - K2UT
bob@waterw.com

Go BACK to the MicroBeacon home page