Most of the hardware for each beacon is standard commercial equipment, but the beacon controller is specially designed. The beacon controller includes an Intel 8748 microprocessor, so to understand how the beacon controller works, you may need to look at both the hardware and the software for the microprocessor. Both were designed by Bob Fabry, N6EK.
It is improbable that anyone else would want to duplicate the beacon controller exactly. Substantial parts of the design deal with the precise timing of the transmissions needed for rapid frequency sharing and with the power stepping. If you don't want to do both, a simpler controller will suffice. In fact, most simple beacons use a programmable keyer as a controller.
Nevertheless, there has been a fair amount of interest in how the NCDXF beacon controller actually works, so we are including here the schematic and the source code. You have our permission to use whatever part of this would be useful to you. It would be fun for us if you let us know what you are doing.
If you want to calculate the exact timing of each beacon transmission, here is the information you need. Each code element or dot time is 54 milliseconds long. This corresponds to 22.22 words per minute using the normal computation. Dashes are three elements, spaces between dots and dashes are one element, letter spaces are three elements and word spaces are seven elements. The rig is nominally keyed at the start of the appropriate ten second period. The callsign is sent, followed by a word space, followed by four one-second dashes separated by letter spaces.
What are the uncertainties in this timing? The uncertainty in the start of the transmission is the sum of several delays: At the beginning of every second, the GPS receiver signals the controller using the interrupt line. The accuracy of this pulse is plus or minus one microsecond, according the specification of the GPS receiver. The pulse triggers an interrupt and the interrupt routine takes between thirteen and twenty-four 2.5 microsecond cycles to operate. This introduces a 42.5 to 60 microsecond delay. The main program is looping near the program label "xmi4" and will take twelve to sixteen cycles or 30 to 40 microseconds before keying the transmitter. Thus the total delay before the TS-50 is keyed will be between 72.5 and 100 microseconds. Once the TS-50 is keyed, there is a delay of about 20 milliseconds before the RF actually appears at the feedline. This delay may vary a few milliseconds from one TS-50 to another, but should be repeatable for a single TS-50.
Once the transmission begins, the timing is controlled by the clock rate of the 8748 microprocessor. This clock rate is determined by a cheap crystal which should be within about one part in a thousand of the nominal frequency and should be stable to at least one part in one hundred thousand from day to day.
Most of the TS-50s include Temperature Controlled Crystal Oscillators (TCXO) which stabilize the transmission frequencies. However, some of the beacons are installed in locations with significant temperature variations from day to night, often exacerbated by an installation in a shipping container. The W6WX radio temperature can vary from over 40°C to below -10°C or worse in one day. The effect of this is that the transmitter frequency can vary by a few Hertz to tens of Hertz over the course of a day, or from day to day.
After 15 years of operation, the Kenwood TS-50s radios were reaching the end of their useful life. Repairing the old radios became more and more difficult as parts were not easy to obtain and the failure modes became more comples. The 8748 microcontrollers used in the Beacon Controller was also becoming difficult (almost impossible) to obtain in order to repair the controllers when they were damaged by lightning or to build new controllers when necessary.
A meeting was held in August 2010 at the home of Dave Leeson (W6NL/W6QHS), who designed the original controller around 1980 and was involved in the redesign prior to deploying the eighteen beacons in 1995. Attending the meeting were Steve Lund (K6UM), Charlie Mason (W4NJK), Peter Jennings (VE3SUN/AB6WM/C31LJ), Steve Peterson (AC6P), Alex Shovkoplyas (VE3NEA), and Steve Merchant (K6AW). The outcome of the meeting was a three year plan to develop a new controller (version 2.0) incorporating new features while replicating the old signals in order to be compatible with the monitoring software, listener applications, and various applicable laws and waivers that had been obtained to legally operate an unattended radio beacon in all of the 18 locations.
The new beacon controller is based on the well known Arduino platform, which makes it easier to support and open for future enhancements. The hardware design and firmware are all open source and downloadable from the project Beacon Controller 2.0 Github Repository.
Much of the work involved in developing the new system was performed by Kevin Rowett, K6TD. He was assisted in the development and testing by WA5ZNU, Leigh Klotz, Jr; W6NL, Dave Leeson; K6UM, Steve Lund; K6AW, Steve Merchant; N1DG, Don Greenbaum; VE3SUN/AB6WM, Peter Jennings; K6GSF, Lance Ginner; VE3NEA, Alex Shovkoplyas; K6TU, Stu Phillips; N6TV, Bob Wilson, and Tom Berson, ND2T.
Funding for the engineering effort was provided by the NCDXF, YASME and the IARU and by individuals who earmarked their donations to the NCDXF for the beacon project. In addition, materials and labour were donated by N6LXA, Geoff Bahr, who donated three of the GPS timing antennas; N6PSE, Paul Ewing, who donated two ICOM IC-7200 radios; N6BT, Tom Schiller who donated a new antenna to replace the MA5Vs that are failing; and K6TD who donated materials and labor to build the first two prototypes.
The first beta test unit was installed at W6WX on Mt Umunhum in Northern Califoria in the summer of 2015 and was soon generating reception reports from around the world. Some minor adjustments to the timing was necessary to ensure Faros and RBN compatibility, which was considered essential.
In January, 2016, the second unit was installed at KH6RS on Maui and appears to be operating flawlessly. There is a current bug involving the last dash, the 100 mW signal, which is currently putting out more power than expected, but that will be remedied soon.
The Beacon Controller 2.0 is a work in progress. The current hardware and firmware designs are visible on the Beacon Controller 2.0 Github Repository.