Monday, April 9, 2012

TM-241a analyzing

Forgot about the simple logic analyzer mode on the Bus Pirate. Channel 1 is serial out. Channel 2 is clock. Channel 3 is serial in. Channel 0 is RD (Pin 6 on mic connector) This graphic looks a little glitchy. Since this is a digital sample, if you sample at too low of a frequency in relation to what you are sampling then you will end up with strange looking data. This may be at 5khz sample rate. You should have seen it at 1khz. I was playing with 10khz and 20khz sample rates which looked much better but had a shorter sample time. The Bus Pirate only has 4096 bytes of ram to save samples in. It wasn't designed as a logic analyzer, it just happens to be a bonus.

This is in a mode that I am calling RC-10 mode. In this mode the radio will allow you to use any and all of the buttons on the radio itself. It only clocks out data when you operate the controls on the radio or on the remote unit, and then the remote unit acts as the bus master. The radio will only send data out when the clock is running and it is receiving 0xFF on serial in. 1 byte out for each byte in. I'm still not sure how the radio indicates that it has data to send out. I think it may twiddle the serial out line a bit. I am currently unable to emulate even this mode so far. I may have to write some sort of bit bang code in order to get the Bus Pirate to handle UART in/out and also the clock line.

The other mode I am calling RC-20 mode and it's a little more mysterious, to me. If I hold RD high, and keep it high, then send something, anything, down serial in then the radio will start continuously sending display frames out the serial out line. It also clocks the clock line itself. I can't seem to make it see any data that I send after that point. Additionally, in contrast to the other mode of operation, once in this mode the radio completely ignores all operation of the controls on the radio itself. There must be some sort of protocol that I'm missing. Maybe something like pull the serial in line high for 50ms, then clock data in or something. Come to think of it, in this mode there is a one shot chance of changing the frequency. Sometimes it works once and then not again until I reset the radio. I wonder if I sent some 0xFF bytes down the line after that if it would work again. But then again, in the other made that only seems to happen so the radio will send out display packets. It does that anyways in this mode. It bears further experimentation.



  1. Very cool stuff!! I just picked up a TM-231a via ebay but I don't have it yet. I was just googling to figure out if there is any sort of a data connection and found your stuff.

    First the basics, I'd like to add programming support for this radio to CHiRP if possible. There is already support in Chirp for the TM-271a. (It's in the kenwood_live driver).

    I too was wondering about the remote control. I also have a Bus Pirate. Hopefully in a week or so I might be able to replicate some of your tests.


  2. Thanks for the comment! This radio also has a cloning function that I've never worked with. It should be a no-brainer to add support to CHiRP for that.

    I was actually working to reverse engineer the protocol for my Puxing PX-2R radio once but didn't make much progress and abandoned what I did once CHiRP added support for it. My interest was really more of making something that could automatically put TX frequencies for out-of-band memories beyond what the radio could handle so that it would beep at me rather than transmitting OOB. That's something that should be easy to do programatically, but a real pain to do by hand either at the radio or in the original software.

    I'd be happy to compare notes when you are able to conduct tests of your own if you'd like to share results. I have a text file with control codes that my RC-10 sends to the radio and a basic description of the display frames. Though, I may have some of that on here already! :)

  3. I see from your posts the Tm-2n1's look like they are 5V, TTL level serial connections. Which pin on the MIC connector are used for async. serial?

    Also what pin are you using for the lock in synchronous serial mode?

  4. From my notes:
    Pin 2 is SI
    Pin 3 is SO
    and Pin 4 is Clock

    Pin 6 seems to enable the mode. In what I term RC-20 mode, if I hold that high then send something to SI on the radio, it begins sending a continuous display stream to SO, and I believe a clock signal out on CLK.

    Pin 8 is GND

    All of these are in relation to the mic connector.

    Hilariously, in the raw serial mode.. Windows 7 thinks my TM241a is a Microsoft Serial Ballpoint mouse. It then installs the driver and proceeds to wiggle the mouse all over the top of the screen until I remove or disable it. Caused me a lot of problems when I started working with the transparent bridge mode on my Bus Pirate.

    Serial settings are 1200 baud 8,N,1
    Receive polarity: Idle 1
    Output type (on BP) H=3.3v, L=GND

    I think the radio is 5v, but it's happy enough with the BP's 3.3v. I guess? I haven't had any luck sending commands to it but I've chalked that up to not being able to control the clock line.

    If you figure out a way to get the bus pirate to use the clock in UART mode let me know. I haven't yet worked on any sort of bitbang UART code. The clock is disabled, but if you know PIC assembly then maybe you can modify the BP firmware.

  5. Hi James,
    I've been looking for informations about the RC-20 protocol for a while. I've missed the last ebay auction on this device a few weeks ago (the seller didn't want to ship it to France unfortunately).
    I own a TM-241E and a TM-441E I'd like to control remotely, so the PDF Kenwood kindly sent you would help me a lot too. Would you e-mail me these files? My e-mail adress is (remove 12345 from the adress, I added it to avoid spam).

  6. Funny you should post a comment about this today. Late last night I was fiddling with this project some and discovered something. I can send commands with my Bus Pirate now, whereas earlier in the year I couldn't. There's a couple of differences since thing though. 1) I updated the firmware on the Bus Pirate. I'm not sure if the original firmware supported running a serial clock line in UART mode. 2) I have an RC-10 that I bought off of someone on that is plugged in. I have it plugged in so I could sniff it's communications with the radio, it may be helping me some. There are some specifics in that protocol that I'm not sure about still. My next step may be to go back to using a blank plug so I can see if I can control the radio without the RC-10 plugged in.

    The PDFs that I received from Kenwood didn't have any specifics on the protocol, and what I've learned is mostly from conjecture and experimentation. I could tell you which pins do what, and you'd know as much as I did after reading the PDF.

  7. There's no helpful information on the RC-10 manual I found on, indeed. I'll have to find an RC-10 or RC-20 to hack, or wait a little bit to get more info from your researches.

  8. I've received my RC-10 earlier this week and started to hack its protocol too. All I've found so far is available here:
    Since my logic analyzer isn't able to send data on the bus, I'm thinking of making a simple interface that would convert RS232 data frames into SPI, to find more commands.
    I'll update the PDF document I've made as soon as I find new commands.

  9. I need to publish my notes likewise. The protocol is UART serial, not SPI. You are right about it being 1200 baud. I have made some progress in documenting the code and running tests. With the RC-10 hooked up, and my Bus Pirate connected to it, I can actually send commands to the radio and have it listen to me. If I measure the Baud rate with my Bus Pirate, it actually tends to measure 1220Baud oddly enough.

    I recently received an Open Bench Logic Sniffer board with probes in the mail. When I get time to work on this project again I'm going to hook it up along with my Bus Pirate for another view. I also have received a number of parts that I intend on using to build a breakout box. I should be able to use it to hook multiple devices up to test with and without the RC-10 connected easily.

    Typical frame of data from the radio:
    00 82 22 66 E2 22 AA F1 40 02 02 12 02 22 01 E0 82 61 10 01 FF

    00 through F1 is the frequency data. Oddly it seems to be sent reverse of what my Bus Pirate is receiving it as.
    826E2A =

  10. I've had no luck decoding the data frames using the UART interpreter with my logic analyzer's software. The only way to read consistent data with it is to decode the frames as "serial synchronous", like SPI but without an Enable signal.
    Do the screen captures on my document look like yours?

  11. Hi James,

    Things went very fast here since last month, I've had the opportunity to buy a brand new RC-20 for a pittance. It allowed me to considerably update the protocol specifications, which might interest you:
    A RC-20 clone is also on the way (!#comments )