Why isn't
there a Keyboard Interface for the D710 like there is for the D700?
Lots of people have inquired
as to why there is no keyboard interface for the Kenwood D710 as there is for
the Kenwood D700. This page will explain why this is so and will update
progress on the development of a D710 keyboard interface.
The D700 keyboard interface
is designed to replicate the functions of the microphone when it is sending
text to the radio. The D700 does this by using a DTMF tone generator. The D700
keyboard interface used a Holtek HT9200A tone
generator chip to simulate this process. The D710 uses an entirely different
process for sending text from the microphone to the radio. There is a data line
with TTL level data on it. This should, in fact, make it a lot easier to
implement a keyboard interface using a microcontroller because the
microcontroller could easily simulate any data stream using a single pin.
However, Kenwood has not documented the communications protocol used in the
D710 and my efforts to reverse engineer it have so far been unsuccessful. I
have, however, learned quite a bit about this protocol in the process of trying
to reverse engineer it, and this web page documents what I've learned so far.
Any suggestions you might have for what I may have overlooked in this process
would be appreciated.
When the microphone is NOT
connected to the radio, the body of the radio holds the data line high most of
the time and then transmits data every half second. On an oscilloscope it looks like this:
Zooming in on one of these
pulses shows:
The individual pulses are
not very square… here’s what they look like individually:
I suspect what is happening
is that a microcontroller pin in the microphone is switching from output to
input occasionally to look for data from the microphone.
When the microphone is
plugged in there is a different series of pulses:
Note that these pulses are
every 50 ms (10 times the rate of the pulses from the body). The line is held mostly low. I have found that if the line is held low
during one of the pulses from the body of the radio, the radio treats this like
a “down” key press and moves the frequency every half second. Thus, at least some of these pulses from the
microphone are needed to keep the radio from changing frequency.
Zooming in on one of these
pulses shows that they are also composed of shorter pulses:
Note also the irregular
shape of these pulses. Again I suspect
this has to do with a pin switching from output to input rather than switching
from low to high. When a keypress occurs on the
microphone, the series of pulses every 50 ms is interrupted:
The line is held low longer
than it might otherwise be and then is held high for a period of time. The period of time during which it is low
varies, but not systematically. Zooming
in on this image:
There is a long high pulse
here (abt 15 ms).
The second pulse you see is the resumption of the 50 ms pulses and third
pulse is the next one in that series.
The data on which key on the mic was pressed
is encoded in the falling edge of that first long high pulse. Zooming in on it looks like this:
The falling edge of the long
high pulse is actually a series of pulses.
The number of these pulses depends on which key was pressed. In the image shown above there are 11 pulses…
this indicates that the “9” key was pressed on the keypad.
I can cause a
microcontroller replicate this pattern exactly but it doesn’t cause the
expected result in the radio because either:
- It’s not being sent at the right time.
or
- There some handshaking between the radio and the
microphone that I’ve not implemented.
If any of this looks
familiar to you or if you have seen this type of protocol implemented somewhere
else, please contact me at john@coastalchip.com