Icom HM-98/HM-133 Internals
The HM-98 is the microphone that ships with the Icom IC-207H amateur radio, while the HM-133 ships with the Icom IC-208H and several other radios. The HM-98 and HM-133 are functionally identical, except for key layout. The HM-151 should also be the same (although I have not yet found a schematic for it). All information developed below was done against the HM-98 mic and IC-207H radio. Based on schematics for the HM-133 and IC-208H, they should perform identically.
These microphones have a NEC uPD7564AG 4-bit microprocessor with 1K of ROM. The processor in conjunction with a 4028 BCD-to-decimal decoder is used to scan the keypad. The keypad in effect becomes a 9 column by 4 row keypad. The microphone has 26 keys (VFO, MR, BAND, F1, F2, UP, DOWN, DTMF-S, FUNC, 0-9, A-D, *, #, and PTT) and two LEDs. The LEDs are controlled locally by the microphone itself, based on certain key actions.
Two of the keys, DTMF-S and FUNC, modify the behavior of other keys. Neither of these two keys send codes to the radio. The DTMF-S key is a toggle, requesting the radio to send DTMF tones when the 0-9,A-D keys are pressed. The FUNC key is a one-shot that only modifies to the next key pressed. Pressing FUNC will cancel DTMF-S (if set), and likewise, pressing DTMF-S will cancel FUNC.
The microphone communicates to the radio over an open-collector bus. The bus idles at a high voltage of approximately 2.45V, and is pulled low to 1.95V by the open-collector driver on the microphone. The radio itself has a comparator with a threshold voltage of about 2.2V. This would seem to result it an exceedingly low noise threshold, but it does work.
At the bottom of this page is a link to a series of captures made with a USBee ZX Logic Analyzer. These can be viewed by installed the software from the USBee download site. Select 'USBee ZX Digital Test Pod Software (32-bit)' package and install it. With no USBee ZX installed, it will start in demo mode.
The Icom schematic has an error it. The values for R8 and R36 are reversed; R8 should be 10K, R36 should be 22K.
The processor scans the keyboard at a rate of 1.3ms per key, using continuous polling.
LED DS11 (upper right on HM-98, above CLR key on HM-133) can indicate red or green, but at no time does it indicate orange. Red is used to indicate PTT is pressed, green indicates the microphone is in PTT-M mode (PTT toggles transmitting on and off). Each color is separately controlled by the uP. According to the schematic, LED DS10 (left of FUNC on HM-98, above MONI key on HM-133) can only indicate green (DTMF-S enabled) and orange (red + green, FUNC enabled). When the red LED is enabled, the green is forced on at the same time. This seems sub-ideal, since the same number of pins are required. This choice was probably driven either by the functionality spec, or a code space requirement (only 1K x 4 ROM).
Some of the indicated voltages are somewhat puzzling. Even though the J1 connector claims to have only 8V on it, the schematic indicates the backlight LEDs have 8.8V in receive mode, and 8.7V in transmit mode.
When PTT is active, the microphone will only send valid DTMF keys, and no others. This means that while PTT is active, key codes for UP, MONI, DUP- will not be sent, but if DTMF-S has been selected (indicated by the DTMF-S LED being lit), DTMF codes for 0..9, A..D, * and # will be sent. This is normally handled in the microphone itself, but the radio will also ignore keys that don't have the DTMF bit set.
Sending the 10 undefined values from the table below had no visible effect on the IC-207H, either in MR or VFO mode. It appears that the radio just ignored those keys, and they don't do anything interesting. These were tested only with sending the data stream with 1st Press bit set. Tests such as press and hold for 1 second were not performed.
Below is what the keypad matrix looks like when the schematic is "unwound". The P00, P01, P02, P03 are inputs into the processor, the Q9..Q0 pins are the outputs of the 4028 BCD-to-decimal decoder.
*1 This is a note, not a key. Q9 is looped straight into P03. This was likely done either for a self-test feature, or so that the software would "know" when it hit the last legal value of the BCD decoder. For a microphone with more keys, this could be replaced with a 4-to-16 decoder to support up to 64 keys. The data formats support this, and this would require no change in the firmware (if they did everything right).
|Pin||Name (Radio)||Name (HM-98)||Function|
|1||8V||M8V||Raw 8V from radio|
|2||MICU/D||MU/D||Up/Down buttons (not used)|
|3||EXTMIC||M8VSW||Grounded by HM-98, indicates digital mic attached|
|4||PTT||PTT||Push-To-Talk (not used)|
|5||MICE||MICE||Microphone audio ground|
|8||MICIN||MDATA||Open-collector data line from HM-98 to radio**|
* Microphone will not enable 8V to the remainder of microphone until this line is high. On the radio side there is a 100 ohm resistor/33uf capacitor that must charge before this line goes high (about 3.3ms). Once it does, Q8 (on the HM-98) will pull Q9 low, enabling 8V into the Q1 shunt regulator. I suspect this is done to make sure the radio is ready before releasing the HM-98's uP from reset.
** This line idles at about 2.45V, and is pulled down to 1.95V when transmitting.
When a key is pressed, the microphone sends a bit stream that is comprised of a preamble and two copies of a 20 bit sequence that contains the key encoding. The preamble is used to get the attention of the radio, and if the software is any good, to determine what the timing of the subsequent data bits are.
A zero bit is encoded by the data line going low for 190us (microseconds), then high for 230us. A one bit is encoded by the data line going low for 190us, then high for 415us. It is unknown what the actual timing tolerances are.
The preamble starts with 7 zero bits, followed by a marker. A marker is encoded by the data line going low for 190us, then high for 795us. After the marker is sent, the actual data begins. The 20 bit encoding of the key is sent twice, back to back, followed by the data line going low for 190us, then back high to the idle condition. For all keys except PTT and FUNC-3, the microphone will then repeat this, sending a new key code every 43ms (milliseconds).
Below is a capture of the '1' key being pressed. This shows the preamble (between red and blue line), the first 20 bit field (blue line to green line) and the second 20 bit copy of the 1st field (green line to far right). Starting at the blue line, we can see a 0 bit, a 1 bit, then two more 0 bits. These are the various flags (PTT=0, 1st Press=1, DTMF=0, FUNC=0).
Below we can see where the 1st Press bit is now cleared. This is the second code sent and repeats every 43ms until the key is released.
Lastly, a capture of the first code sent when DTMF-S is enabled. Here, PTT, 1st Press and DTMF are all set.
The top-most trace (black) in each of the three shots is output of an LM339 comparator run at 5V, with a divider of 120K over 100K, giving a threshold of 2.27V. The second trace (brown) is picked directly off the uPD7564AG I/O pin that drives the open-collector driver. The output of the comparator is delayed by 15us for rising edges, compared to the processor I/O pin. For falling edges, it lags by about 3.5us. Any software that uses such a comparator needs to allow for some error in timing.
The 20 bit field has been arbitrarily broken down into 8 fields, based on what the functionality appears to be. Columns 2, 4, 6 and 8 are delimiter bits, and are always 0. Column 1 are the flags field, detailed below. Column 3 is always '1000', whose function could not be determined. Column 5 is the row address of the key being pressed. Column 5 is the column address of the key being pressed. (Thanks to Simon for coming up with a better analysis of the bits than I originally had.)
|0||0||0||0||Subsequent unmodified keys and PTT release|
|0||0||0||1||Subsequent FUNC modified keys|
|0||1||0||0||First press unmodified keys|
|0||1||0||1||First press FUNC modified keys|
|1||0||0||0||PTT (first key code sent)|
|1||0||1||0||Subsequent DTMF-S modified keys|
|1||1||1||0||First press DTMF-S modified keys|
|Key||1st Press||Subsequent||w/ FUNC||w/ DTMF-S|
Although not shown, for both FUNC and DTMF-S mode, after the key code is sent with the 1st Press bit set, the subsequent codes have 1st Press cleared, just as a key with no modifiers would behave.
PTT is a little different from the rest of the keys, on several accounts. The first is that it doesn't repeat every 43 milliseconds, like other keys. Instead, it sends the PTT code when PTT is first pressed, and when released, sends the PTT code with the PTT bit cleared 5 times. This is because when PTT is pressed, if a DTMF-S is toggled on and a 0-9,A-D key is pressed, the key has to be able to be sent.
A slight oddity of PTT is that if a key is pressed (and DTMF-S is not enabled), on the first code of the release sequence, the 1st Press bit will be sent. This probably isn't used for anything, but is a curiosity.
PTT has another odd behavior that's directly related to the FUNC-3 PTT-M (One-Touch PTT) function. PTT-M makes the PTT a toggle. Pressing it once puts the radio into transmit mode, pressing it again ends transmit. This is handled by the microphone itself, not the radio. When in manual PTT mode, the normal PTT sequence is broken into two stages. To transmit, PTT is pressed, only the first key code of the PTT sequence to be sent (i.e. the 5 key codes on PTT release are not sent). When PTT is pressed again, it then sends the PTT code with the PTT bit clear 5 times.
Unlike other keys that repeat every 43ms, the FUNC-3 key code is only sent once each time it's pressed, and the 1st Press bit is always set. This was probably done so that everything would remain in sync should the microphone be disconnected while PTT was active in normal or One-Touch mode.
- HM-98 Schematic (111 KB)
- HM-133/HM-133S/HM-133V Schematics (970 KB) (HM-133 same as HM-133V(A), HM-133S same as HM-133V)
- NEC uPD7564AG Datasheet (438 KB)
- NEC uPD789071 Datasheet (1.42 MB)
- Hosiden KUB2823 Microphone Datasheet (569 KB)
- DTA114EU Datasheet (69 KB)
- DTC114EU Datasheet (87 KB)
- USBee ZX Logic Analyzer Captures (954 KB)