The IC901A Remote Control Head Project Page

Updated 10/13/2020

Back to the HM-133 Adapter Page
This page describes the IC901A Remote Control Head Adapter Project

This project is an add-on to the HM-133 DTMF Adapter. This add-on allows the extended command buttons on an HM-151 microphone to wirelessly "connect to" selected buttons on the IC-901A control head via a bluetooth RF link.

The HM133 Adapter uses a small microcontroller to interpret the serial data from an HM-133/151 microphone to send DTMF tones and the limited button signalization (such as UP/DOWN) present on older DTMF microphones. By using the UART of the MCU to connect to a bluetooth module, the HM-133 can then be used to send mic-button presses via bluetooth to the control head of an IC-901A.

The modification makes use of the traditional key-matrix scanning techniques utilized by the IC-901 to allow keypress data to be sent with a minimum of logic signals. These techniques are likely used with other radios (regardless if they have a detachable control head) allowing this project to act as a roadmap for those who might want to try a similar approach with another radio.

A Brief Synopsis...

I've been working on the remote control aspects of the IC-901 for many years now. I've actually built a couple of control projects to essentially replace the control head of that radio. However, I'm not game to re-invent that wheel yet... there just aren't enough hours in the day, unfortunately. Still, I use the radio mobile, and would like to get the control head "up" where I can see it without having to completely take my eyes off the road. Doing this is pretty easy these days as there are a lot of "suction-cup" cell phone holders out there. Problem is, once it is up on the windshield and easy to see, it is a stretch (literally) to reach the buttons. What to do?

When I created my first HM-133 DTMF adapter, I ended up with an unused UART. Well, it WAS used, for debug, but after that, nuttn'. Still, I provided solder pads on the PCB, "just in case". Subsequent revisions of the design scarfed up those pins, so the UART availability is compromised, but for the original PCB, it is still available. That happened to be the one I've been using, so that meant my UART was still in play.

I've started driving back and forth to work again, a couple of days a week at least, so I started thinking more about this whole control thing again. What if I used some bluetooth modules to send "button press" commands to the control head? I could then use the myriad buttons on my HM-151 that have no purpose when connected to the IC-901A. A couple of weeks ago, I fell down the rabbit hole for bluetooth modules, and ended up buying a couple. Something like $10 for a pair. Lunch is generally more expensive than that.

Thus began the journey in earnest. It was a relatively quick journey (a woeful rareity in my life) with a conclusion that came very close to my expectations (another woeful rarity).

Hardware Design...

The first step was to get the modules turned on and connected. To do this, they needed to be soldered to a board. To do THIS... I needed a board. While there are a number of really cheap PCB options available these days (PCBgogo.com is my current go-to), I decided on the REALLY fast turn option: An Exacto-knife and some blank FR-4 material. The bulk of the material I have features 0.5oz Cu which makes the process go pretty easily (thicker copper is harder to score and peel). The photos below illustrate the result. I have done projects many times with this method with good success. Of course, a microscope and a knife with a proper edge contribute greatly to the success. The main disadvantages to this method of construction is that it is time consuming to do and there are no "spares".


BT Host

BT Remote

The host board was sized to fit precicely between the RJ-45 connector housings on the HM-133 adapter, while the remote board was less precicely sized to fit onto the back of the IC-901 control head. In fact, it started out rather larger and was trimmed to the size shown above. From this point, I could learn how to talk to the modules and see if they could bend to my will. There was a short learning curve to figure out the syntax, and how to identify the modules to each other. I also spent a bit of time grabbing and tinkering with a couple of iphone apps from Microchip. Soon, I had the modules connected and was able to control an LED on the remote board. Sa-WHEAT!

The next step was the control head interface. The module I selected has only 5 GPIOs (General Purpose I/O) available for user control. The Control head has 19 buttons, plus the encoder dial (I did not interface the dial). Since only one button need be pressed at a time, we can reduce that to binary, so we'd need 5 "bits" to cover 19 possibilities. However, the proper way to implement such a scheme is to have a button "address" and a "press" signal. This means we need 6 bits to cover the 19 buttons. This puts us in a bit of a pickle with only 5 bits to work with. Fortunately, the remote module also has a PWM feature, which allows us to "hack" a 6th bit by using the PWM output with an RC filter to remove the PWM carrier. By setting the PWM to 99.5% or 0.5%, we get another logic output.

Originally, I was thinking I'd need to use an N-FET or an analog switch to close the contacts on each switch. This would require a lot of transistors along with a lot of wires running all over the control head PCB. However, I decided to use the matrix nature of the button layout to my advantage. By employing 74HCT138 decoder ICs, I was able to connect the "address" signals (a[3:0]) and a "pulse" output from the the BT module to the decoders to effect the button selection. Additionally, the "row" signal from the 901 control IC was connected to one of the HCT138 enable inputs. There were two rows, thus the two HCT138 devices. The outputs of the two HCT138s were combined with diodes to complete the circuit. This allowed 16 buttons to be accessed using only 10 wires to the 901 control IC.

The remaining 3 buttons were not in the button matrix, but were just open/GND inputs to the controller IC. This meant that they could be handled a bit differently. For these, I used an HCT238 (same logic as the HCT138, but the outputs are active high) connected to 3 N-FETs which in turn drive the three remaining switch inputs. a[1:0] selected the buttons and a separate pulse signal was used to "press". The space was tight, but I managed to squeeze the circuit inside the control head as the photo below illustrates.

IC-901A Control Head modifications (BT remote cable is not yet attached)

The addition of a short cable/connector and a back cover machined out of a flat piece of 1/4" thick PVC gives the final configuration of the control head part of the puzzle.

IC-901A Control Head final configuration (unfolded)

Control Head BT interface schematic

(click on image to see a pdf version)


Software Design...

The software took a pit of prodding to get moving. First, the C8051F530 has only 256 bytes of RAM. Not a lot, but sufficient for simple tasks. The addition of the serial interactions with the bluetooth host caused some overflow due to the linker not knowing where to put RAM items. I spent most of my time here trying to learn things about linkers that most SW people learn in their intro courses (and then never talk about, because I can't seem to find anyone who can speak cogently about segments and linker allocation techniques). I was able to mostly get a handle on the process, and found that the project would push the memory requirements to the limit of the processor's available RAM.

In addition, I created a conflict with Timer1 that had to be resolved. I was using Timer1 to process the DDS tone ISR, but Timer1 also drives the baud clock for the UART. So, I could either run the DDS at 115,200 Hz (or a slower rate), and recalculate all of the DDS frequency dependent items, OR move the DDS to another timer. The latter seemed the easier task, so I moved the DDS to Timer2, and adjusted the application timer code by wrapping it in a prescale loop to return the timers to (nearly) their original 1ms rate.

Once these tasks had been wrestled to the ground, all that remained was to create a state machine to handle the bluetooth connection and command processing tasks and then implement calls to that process to signal when a button press action was called for. I also had to re-arrange some existing functionality to gain access to some of the microphone buttons. This led me to the following "button map" for the HM-151:

HM-151 button map


L: Scan up
T: CALL
X: Main/Sub swap
/: "UP" button
V: V/M
M: H/L power
\: "DN" button
F: SET config
G: SUB band
1
2
3
A (MODE)
4
5
6
B (TSQ)
7
8
9
C (Band switch)
*
0
#
D (SMUTE)


To maximize functionality, the numeric buttons and "*" and "#" were previously "multiplexed" by PTT. In other words, these buttons functioned differently depending on the state of the PTT switch. This M.O. was carried further to allow more buttons to be available to control the IC-901A. I also consolodated the LED brightness control, which now toggles with the "*" button. "#" toggles the CHECK button on the 901 (any button will cancel the CHECK activation). "A" thru "D" are now used to control 901 functions (as shown above). If the PTT is active, the lower 16 buttons generate the corresponding DTMF tone (MW still generates the 1KHz test tone if PTT is active).

The button loop takes a button address, sends it to the remote BT module via serial commands, and then sends serial commands to toggle the "pulse" signal to facilitate the remote "press". This scheme takes an extra serial command, but accomplishes the button selection with no possibility for a logic "race condition" that might result in a phantom button press.

There can be no project without feature creep, at least not in my house. For this project, the creep came in the form of the "Mute on RX" feature (or "Unmute on TX", if you are a glass half full kind of person). This feature meets a need that I've been considering for some time. The problem happens when I'm trying to operate full duplex on a local repeater system. The nature of this full duplex link is such that I will most likely hear a link frequency (on another band) that is very strong when I am transmitting. However, when others are transmitting, the link I hear will either be weak, or have delay in the audio. Sometimes, more often that one might think, I even hear activity from a distant, and unrelated, system.

The talk-back capability allows me to gauge my signal quality into the system and is otherwise of no use when I am in RX. It adds nothing and can be quite distracting. Since the microcontroller is directly in the path of the microphone PTT, it can use that information to do something useful. In this case, at each PTT transition, the processor pulses the SMUTE (sub-mute) button. This action toggles the sub-mute feature. All I have to do is manually establish the SMUTE state while receiving. After that, the sub-band will be un-muted when I transmit, and muted when I receive.

For the moment, this feature is enabled by a micro-DIP swich on the HM-133 adapter. The switch is difficult to operate while driving, but is my best solution at the moment. Reversing the sense of SMUTE to support "Mute on TX" (just a button press by the operator) has some appeal as well for those times when I am not duplex and don't want to get blasted by the sub-band while I'm transmitting. If I decide I want to enable/disable the feature on the fly, I'll have to come up with some manner of unique key sequence (more importantly, some way to signal that the feature has been turned on or off). For now, the DIP switch is the best I can manage.

Other variations are possible as well. One other possibility is to program the talk-back frequency in a call channel (as it currently is) and then toggle the sub-band CALL button at each PTT transition. This requires two extra button presses, however, so I have not raced to this solution just yet. Still, the serial messages are pretty fast, and this would allow me to monitor another repeater while I am not transmitting. Allowing one to take full advantage of a "dual-band" radio.

Terminis...

The HM-151 was used in place of the HM-133 because the audio level of my HM-151 more closely matches that of my IC-901. Efforts at finding a mic element for my HM-133s that is consistent with the HM-151/IC-901 have stalled, so the HM-151 is the MIC of choice around here at the moment. Some of the subtleties of the HM-133 differences might make it a better choice, primary being that the HM-133 has a "Function" button which would add a button press to some commands, but would by default offer up a number of additional functions that could be coded (volume and squelch would be nice and all that is needed is a bit of software and some MIC buttons...).

There was no lack of hair-pulling on this project, but I was able to surmount the impediments and push towards a successful conclusion. A quick project to gain an interesting augment to my trusty FM radio stack. Now, on to the next project...


Photos

Close-up of the modified HM-133 Adapter


The modified control head and HM-133 Adapter