The NJ-QRP "MicroBeacon"

by: George Heron N2APB, Bob Applegate K2UT, and Joe Everhart N2CX


At one of our regular show 'n tell meetings not so long ago, some of us NJ-QRPers were brainstorming on what we might do as a follow-on project to our successful Rainbow Tuner kit. Besides looking for a project that would be useful in the shack, this project would need to be instructional for all members wishing to participate in the design, protytping and testing of the project. In fact, we were commenting on how our project might follow "standard phases" that real companies use to develop products.

Well, someone commented on how he'd love to be able to actually work on some of the code that goes into a PIC microcontroller. Another mentioned how he had the start of a keyer code for a PIC. And yet another mentioned that it would be real cool to get a beacon on the air whenever we had a club meeting. VOILA, a club project was born … the NJ-QRP MicroBeacon!

This "Concept and Requirements" article is the first in a series describing the birth and evolution of the MicroBeacon. Over the coming months we'll be chronicling how the project progresses -- from our lively discussion of the requirements up front, to the (hopefully) successful build of multiple units for our members wishing to use the project at the end.

We're not sure if we'll be kitting the project for the general QRP community. Right now it's envisioned as being more of a hands-on club project, but we'll see how we progress and what the general interest level is for others watching us on the sidelines. Who knows, maybe a bag 'o parts and these articles might do for a simple kit.


The MicroBeacon is a project collaboratively designed by our NJ-QRP club members. As a group and over time, we are taking this project through some of the standard "phases" of an industry design: requirements, design, construction, test and operation. We'll have a "project manager" who will be the champion of the overall effort through the phases, coordinating, communicating and arranging the necessary steps along the way.

Any member may be involved in any stage of the project, and he'll be making an important contribution to the hardware, software, construction or testing of the MicroBeacon, typically under the guidance of one of the club Elmers. In fact, any member contributing to the development of the project will be allowed to keep the components for himself at the end, yielding an operational MicroBeacon for his own use! The goal is to have has as many members as possible involved in the project, organized into teams within the different phases. The NJ-QRP members gave a resounding endorsement to this whole approach.


Okay, here's where we get into some of the nuts and bolts of the product development … the Concept Phase. A beacon is a device which automatically transmits a repeating signal, often with predictably varying power levels. The beacon transmission usually contains the callsign, power level being used, and a code word which can be later used to verify successful reception of the signal.

This concept is nice and relatively usable as-is, but not too many hams would be rushing out to build, buy or otherwise operate a beacon … there's just not that many instances for when you would use one. Perhaps for field measurements for antenna patterns, for propagation studies, or for club meeting events. (This last use is actually a pretty cool idea … envision a beacon operating during the advertised time of a club meeting, with the club issuing certificates for those who successfully copy the club call on its beacon!)

So what else can you do with a beacon project? Well, let's take a look at the basic blocks of a beacon to better understand what it is -- then we can determine other interesting dimensions of the project.

The primary fixed function of a beacon is to transmit a signal with a repeating cycle. The signal consists of an International Morse code character stream with which the processor (using hardware, software, monkeys, whatever) keys the transmitter. In addition, the processor sets an output RF power level by switching in and out sections of the attenuator bank.

We could easily think of designing the project in separate stages or as three distinct modules. We could later design higher quality/resolution components to replace the "basic" ones provided in the original design. We could even provide different types of controllers -- fixed hardware, pre-programmed microcontroller, or a flexible and downloadable "firmware" controller. There's LOTS of flexibility in this design!

Now here's a key concept. Understanding that the processor is merely an "pre-programmed keyer", why not extend the functionality of the project to be a memory KEYER as well as a beacon?! "Oh no, YAK" (Yet Another Keyer) … <yaaaawwn>. Ahhh, but suppose we open up the software for this PIC keyer! And the design algorithm, flow charts, variable map, timing loops, and everything else that goes into the making of a PIC keyer! Not many vendors (if any at all) do this level of open design. Boy, now THAT would be an interesting twist, and what an instructional value that would be for those of us looking to understand software programming of these cute little microcontrollers, eh?! Plus, if all you're interested in is a keyer for your nifty new NorCal/K8FF Paddles, you're all set with this project. Sure, you could use a simple TiCK chip about the size of your daughter's tooth filling, but this would be your software, running on a controller you made. Pretty cool.

And the last concept of note would be again based on MicroBeacon's modular approach to the design. You could actually construct the Beacon in modular components: plug the controller into your Sierra, OHR or Green Mountain rig; use the controller to key the cute little Micronaught transmitter that fits inside a fountain pen; or use the switched RF attenuator for known micropower level operation of your regular station. Flexibility deluxe!


A requirements specification is one of the key steps in the evolution of a successful product. It serves as a constant reminder to the designers when they get embroiled in all sorts of perhaps unneeded bells and whistles. And the Requirements also serve as a guide for testing the product at the end of the cycle.

We have a full-blown 15-page set of descriptive requirements for the MicroBeacon, but shown below is a shortened listing of the important ones.

To set the stage … "The NJ QRP MicroBeacon is a low parts count, low cost keyer beacon with attenuator control of the transmitter's RF output levels. It can be used as a normal iambic keyer with memories during normal operation, or as a short-term beacon which can transmit a message repeatedly at varying power levels."

1. Full iambic keyer support with self completing dits/dahs and both dit and dah memories. The speed range will be approximately 5 to 40 WPM.

2. Multiple user-programmable memories. Eight memories will be included.

3. An optional computer control port. The beacon can operate without this interface installed.

4. Memories and other beacon functions can be programmed from the computer port or from the paddle.

5. Three programmable output bits shall be provided for control of the RF attenuator. These bits can be controlled from the paddle, from the computer port or from the memories.

7. Ability to auto-replay any of the memories. This is how beacon functionality is achieved.

8. Ability to turn the output ON or OFF directly from a memory. This is used to turn on a solid carrier when operating a beacon.

9. Low parts count = easy construction.

10. Low cost … < $20 with all new parts, or less than $10 with a reasonably stocked junk box.

11. Printed circuit board construction, as small as reasonably possible using standard (non-SMC) components. The PCB will include appropriate test points to aid in the construction and test.

12. Current draw < 20ma at 12 VDC for normal operation. The attenuator may require some additional power. QRP/field operation is a goal.

13. The beacon will drive the target rig via an open collector transistor. When "key down," the output will be grounded.

14. Open design. Analysis, design and source code details shall be made available to readily facilitate duplication. Anyone with access to appropriate development tools should be able to improve and/or experiment with our software.

15. A simple user interface, offering as much "soft flexibility" (e.g., LCD display unit) and multi-pushbutton control of beacon functions (keyer speed, memories and attenuator) as appropriate.

16. Adjustable QRP HF transmitter power output controlled by the microcontroller.

17. TBD power levels or attenuation levels. To minimize control leads required from the microcontroller, a maximum of 8 levels is recommended, which could be accomplished with three control leads. Alternatively, two leads could control a maximum of four output levels.

18. Output levels should be stable and repeatable within approximately 1 dB.

19. DC operating power = 12V

20. If a programmable attenuator method is used, SWR reflected back to the beacon transmitter should not exceed 1.5:1 for protection of the transmitter and to ensure predictable output RF power.

21. Small size (no more than a few cubic inches) and light weight (under 1 pound) are desired to facilitate portable operation.

22. A weather cover is desired to allow operation out-of-doors.


The NJ-QRP MicroBeacon has now just completed the Requirements Phase, with the members "approving" the specs at a recent club meeting after iterating the pro's & con's on our listserver for a number of weeks. You can keep abreast of current developments by checking the MicroBeacon section of the NJ-QRP "Online Journal" at

We'd like to recognize and thank Bob Applegate, K2UT, our project manager for the MicroBeacon. Bob has been driving the concept and requirements discussion and will be in charge of subsequent phase activities. We'd also like to acknowledge Joe Everhart, N2CX, our club Elmer, mentor and overall analog and RF design guru. You'll be seeing some superb QRP attenuator analysis coming from Joe in our next installment (options, trade-offs, benefits and drawbacks of different approaches). We'll also see the initial software design construction for the PIC microcontroller. Good stuff!

See you in the Analysis and Design phases next time!

--George Heron, N2APB


(Back to MicroBeacon home page)

Last Modified: Oct 2, 1997