TM-241 again

Figured out how to read the S-meter data when it is active. Not too shabby. Still trying to figure out what kind of format the button data is in when transmitted. I have been doing a little hand fuzzing, aka sending random data bytes. I had a theory that they used the exact same control scheme not only on the remote control interface, but also on the internal configuration. That might be true for the LCD commands, but upon closer examination of the schematic, the buttons are in a matrix on CPU pins, SQL and VOL are variable resistors and the VFO knob is a quadratic encoder. Still, it might be valuable to open it up, and patch into the internal LCD signals if it helps me figure out which bits control what LCD elements.

I might also need to write a basic program to start fuzzing. If I could figure out some representative commands, maybe I could go from there and send test commands that are more likely to have a response. At the very least, I need to figure out: VFO knob, VFO button, MEM button, VOL, SQL, and PTT. The last one is important because the MIC connection on the radio is part of the communication scheme for the remote control interface.

TM-241 Progress

After a misstep where I had faulty data, I am getting valid data out of it now. I can tell because I have figured out how the frequency is encoded and I can predict the results of changing to a different one. There's a lot of work still to be done because so far all I can do is read. I also don't know how everything is encoded.

So far I can read the frequency, if there's an offset and which direction, if I'm in VFO mode, CALL mode or Memory channel mode and which channel. I can also see if there's a signal but I haven't figured out how the S-meter is transmitted yet.

There are several bytes where I'm sure data is encoded at the bit level, I've already seen it with offset, CALL and there's a bit that is set if I'm receiving a signal.

There are quite a few LCD elements that I don't know where they map yet. Much of my experimentation so far has been to set something on the radio, turn it off, configure the Bus Pirate, turn the radio on and read it. If I had a RC-10 or especially RC-20 I could probably rig it up to drive it from the Bus Pirate. Then I could configure the packet of bytes to feed it and see what it does. I could also use it to send control packets to the radio to see what they are. I'm guessing the remote control interface is like a "dumb terminal".. if you push a key, it send that key to the radio instead of doing processing itself. That explains why the radio isn't sending a lot of information out such as what the offset is, or if there's a CTCSS tone and what it is. All the radio is sending is what should be displayed on the LCD. I can probably expect a different packet if I'm in a screen to change the tone, for example. Already I have noticed that when I'm on the CALL channel, it omits data for the VFO and MEM channel.

I'm also a little curious as to how the IF-20 sends information to the RC-20 when there's a second (at least) radio connected. The TM-241a only sends out information for itself. The IF-20 would connect to multiple radios and format the information from all of them into a form that can drive the main and sub display on the RC-20. I'm guessing it's an addressing change.

I know Kenwood killed off the remote control displays sometime after the x41 series. I wonder if the protocol survived in the x51 and future radios? Probably not, but you never know. There's a lot of potential power here, this could have been a major selling feature even now.

Kenwood TM-241a

I'm working on reverse engineering the remote control interface on my TM-241a. When it was a new radio you could buy options to use it: RC-10, RC-20, IF-20. The RC-20 looks like any other remote head but with the IF-20 you could hook it up to 4 radios. You could end up with one control and microphone to drive a 2m radio, 440, 220 or 1.2ghz. It also worked across different revisions of the radios although I think the x41 were the last ones.

I emailed Kenwood looking for any information on this interface awhile back, they couldn't help me with the protocol but they were kind enough to send me PDF documents with schematics on the RC-20 and IF-20. Between those, and a PDF service manual for the TM-241a I found.. I have figured out how to do an electrical interface. I'm using a Bus Pirate v3 from Sparkfun to do it. Not entirely sure if I'm interfaced correctly, but I am getting repeatable data. It's quite noisy because I am just using the unshielded probe cables I got with my Bus Pirate.

I did accidentally overwrite a couple of the memories already with junk information. Somehow one wound up with 444.900 and the other had 109.490 in it. Obviously didn't try transmitting there. The radio probably wouldn't have let me, it gave me the error beep when I pushed the REV button to see where the offset ended up. I'm mostly concentrating on receiving the display data that the radio constantly sends out right now. I'm making a bit of progress on the puzzle but it would probably go a lot quicker if I had a RC-10 or RC-20 to experiment with.

All well, I love a puzzle.

My next step may be to collect a lot of information and make Visual Basic programs to help me analyse it. Both for errors, and also for changes between samples (ie, data for one frequency in a memory channel, and then data for another frequency in the same channel)