Hilltopper-20

    Hilltopper-20 QRP Transceiver Kit: Of the several QRP transceiver kits I have put together, I like this one best, not because it has lots of fancy features—it does not. However, the Hilltopper-20 does have everything needed in a fully functional 20 meter QRP rig. It is tunable across the band, has a built-in keyer, and its RF power output is approximately 5 watts, as claimed.

    At first glance one may wonder how to know what frequency is tuned—there’s no display. The answer is that after tuning around you press the function button to hear the current frequency value in an abbreviated Morse code format.  For 14,060.0 KHz the unit sounds “o6oro” substituting the shorter ‘o’ for zero, and ‘r’ for the decimal point—‘r’ is the first half of  ‘.’ in Morse. One can also count clicks of the rotary encoder mentally, and in that way (knowing the step size) be aware of the approximate tuned frequency.

    Now to the thing that I like most about this kit... Its microcontroller is an ATmega328P, same as in Arduino Uno, and the controller chip is socketed. Moreover, source code for the control program is open-source and available for download from https://4sqrp.groups.io/g/HilltopperKit. Thus the kit builder can modify or add to the Hilltopper’s default feature set. How cool is that?

    The first thing I thought to try was to add a tuning step, and at the same time have the unit announce the selected step.  The two ‘built-in’ tuning steps are 20 Hz and 100 Hz.  You would have to twirl the tuning knob a good bit to cross the band, although there is also a way to jump immediately to 14,030 KHz. In any case, I decided to add a 500 Hz step and to have the unit beep once for 20 Hz, two beeps for 100 Hz and three beeps for 500 Hz. This was a trivial modification of the supplied program code.

    Word to the wise: Be sure to back up the original code before modifying it. Alternatively use a different microcontroller chip for experimentation. I used two ATmega328PU chips labeled ‘A’ and ‘B’, alternating between them, for subsequent modifications of the control program (described below). Note that each different microcontroller requires its own separate frequency calibration, as the correction is stored in the chip's EEPROM.
    Microcontroller placement>

    The microcontroller is jam up against the headphone jack so it is not possible to work a chip puller under that end. Instead I used a small screwdriver to wiggle it out, a little from one end, then the other, etc. In the course of swapping chips I noticed four empty jack holes labeled J6 (photo above) and wondered what that was about. (Assemble instructions clarify that [J5 and] J6 headers are not provided with the kit.)
i2c breakout

No-harm test    A quick glance at the schematic detail above reveals that J6 breaks out the i2c bus. The main use of i2c is for communicating with the VFO (Si5351 DDS), but of course a different (though related) application springs to mind. To that end I soldered a four-pin header into J6 and made a connecting cable to use with a 2-line LCD. The first test was to ascertain whether writing to the LCD would interfere with anything else. It did not!

    Following this ‘no harm’ test all that remained was to substitute meaningful data in the display. Line 1 would have the frequency and currently selected tuning step, and line 2 would display the Morse keyer speed setting—I couldn’t immediately think of other data to display. When adding to or changing computer code, it is best to proceed in small steps, in my opinion... So at first I hooked into the annunciator, displaying frequency and other information alongside the kit’s ‘built-in’ Morse frequency announcement. At this stage the visual display refreshed only in response to short-pressing the function button.

    Of course this is not how frequency displays normally work and so the next step was to refresh the LCD when any of its information (frequency, step, or code speed) changed.  This modification went more smoothly than I had expected.  Somehow I had imagined the LCD flashing or jittering back and forth between say 15 and 16 words per minute, but that did not happen. The display is easy on the eyes, except when the tuning control is turned quickly through multiple steps.
Frequency, step, and speed display

    Another concern was that the LCD might cause RFI (interference to the receiver). This was also not observed. Spurious oscillations were heard, but no more or less with the LCD attached.

    There is no room for an LCD to be mounted in the supplied kit enclosure, and anyway I don’t need it. This account is not about improving the kit, but rather about having fun through experimenting with the Hilltopper’s Arduino-based control code.

    Demo: Hilltopper-20.mp4

    Second thought: The dangling LCD bothered me a little. My usual solution would be to stow the thing in a closet out-of-sight. However, one day as N4EFS and I were walking along the hardware aisle, she espied a small packet of plastic corner braces meant to be used in constructing or repairing desk drawers. She pulled the item off its hanging rod and held it before my eyes. Yes, that will do ...I thought. A scrap piece of inside corner molding completed the bracket, while also serving to orient the display at a comfortable viewing angle.
Operating setup with LCD mount

    A nice sloping panel with sufficient space for an on-off switch and possibly other decorations would have been more satisfying, but I have no talent for physical construction. If nothing else, my minimalist bracket relieves strain on the display’s serial tether. The entire setup is now free to slide off the TV table as a unit.

    I am beginning to appreciate the appeal of the low-power challenge (QRP). My first couple of  Hilltopper 20 contacts were with Europe and South America. There is something almost magical about spanning long distances with less than 5 watts power to a dipole antenna—even if most of the ‘magic’ is on the receiving end!

OLED frequency display    Third thought: Sooner or later I will let this thing go. The display device pictured on the left is a 0.96 inch OLED. It is tiny and possibly thin enough to fit in the Hilltopper enclosure. However, I will not be cutting holes in my Hilltopper panel—holes cannot be uncut and such ambitious undertakings always go wrong for me!

    Adafruit OLED libraries consume significant storage, maybe because the OLED is pixel-addressable? Thus, the compiler issues a warning for the modified sketch:
Low memory warning
I made no effort to optimize the display modifications. It is possible that the compiler warning might be avoided by removing redundancies, replacing strings with small character arrays, and making other efficiencies. On the other hand no actual stability problems were observed in the course of exercising the display.

   Demo: OLED-demo.mp4

Hilltopper 20 connected to Ham Radio Deluxe

    Receiver Incremental Tuning: The LCD and OLED displays described in preceding paragraphs show frequency and tuning step, but not Receiver Incremental Tuning (RIT). Shortly after the Hilltopper LCD modification was posted, another ham (NK8O) created an enhancement to include RIT status along with frequency and keyer speed information in the display (posted to HilltopperKit@4sqrp.groups.io). This improvement sparked my awareness of RIT, and prompted me to read the relevant paragraph in the instruction manual. A crazy thought sprang to mind: Would it be possible to display both main frequency and RIT information from the Hilltopper using Ham Radio Deluxe (HRD)?

    I imagined inserting a small number of CAT commands into the Hilltopper’s microcontroller code, just enough to communicate minimally with HRD. I did not know which or how many commands would be needed for a working interface. To probe the possibilities I set up a test situation using the com0com utility to establish two virtual COM ports, and to configure them as a null-modem pair.  Next I attached the terminal emulator program Termite to one of the ports. Finally, I created a ‘connect’ target entry in HRD, associating the other COM port of the pair with the Kenwood TS-440S rig type.

    Using this test setup, I attempted to connect HRD in effect to Termite. In this way it became possible to observe CAT commands from HRD in Termite’s ‘receive’ area. While attempting to establish a connection, HRD requested VFO-A and VFO-B frequencies (FA and FB commands), general information (IF command) and the status of frequency and tuning locks (LK command). To be sure those commands were all that HRD would require to connect and remain connected, I typed artificial replies to each command into a text document, then copied and pasted them as fast as I could into the terminal emulator’s ‘send’ box. Fortunately HRD is patient—it does not report failure to connect until multiple command repetitions have gone unanswered.

    Through trial and error I found that it was acceptable to join replies end-to-end. In other words, sending superfluous information or data that HRD had not specifically requested did not break the connection. Repeating Paste and Enter every few seconds kept HRD connected indefinitely. In place of probing HRD in this way (like a black box), it might have been more efficient to study the manual. In any event I concluded that programming the Hilltopper to supply answers to these commands would suffice to keep the connection alive.

    This conclusion led to a 2-phase coding plan. In the first phase, frequency information would be transmitted from the Hilltopper to HRD for display as VFO-A. Then the reverse: changes to HRD’s VFO-A should produce corresponding frequency changes in the Hilltopper (bounded by the band edges, of course). Once primary frequency information was flowing in both directions, the second phase of coding would address RIT. Although I had no clear idea how to do this, it seemed that the Hilltopper’s RIT function should somehow link with HRD’s VFO-B component.

    The process of coding and testing was not without glitches. For example, sometimes the frequency display would flutter once between the last value and the currently tuned value. This was corrected by updating the Hilltopper frequency and LCD synchronously whenever frequency was adjusted in HRD. Another example is VFO-B change direction in relation to RIT delta—the direction was inverted on the first try. (That fix was trivial.) I feel sure that communication could be streamlined, and possibly HRD’s display responsiveness could be improved. However, once the interface was working I felt little urge to improve it.
Two ways to connect Hilltopper

   Electrical interface: The above photos illustrate two options for connecting the Hilltopper with a computer running Ham Radio Deluxe. They are conceptually the same, each implementing a USB (computer port) to serial (Hilltopper) connection. In the left photo the USB-to-serial cable has an FTDI chip embedded in its USB-A connector (the computer end). I also tried a cable that had an embedded PL2303 chipset. That one did not work for either the present project or another project that also needed a bidirectional computer-to-microcontroller connection.

    Note that although very old PCs may have one or more hardware serial ports (RS-232), these typically use higher voltages and are not suitable for microcontroller interfacing, or would require converting levels.
     
    Demo: Hilltopper-HRD-CAT.mp4
Projects Home

Project descriptions on this page are intended for entertainment only. The author makes no claim as to the accuracy or completeness of the information presented. In no event will the author be liable for any damages, lost effort, inability to carry out a similar project, or to reproduce a claimed result, or anything else relating to a decision to use the information on this page.