I made a pretty nifty discovery the other night. While I had zero luck trying to talk to my TM-241a with only my Bus Pirate... It can talk to it when I am piggybacking on the RC-10 I bought. There's one other variable here that I don't know if it changed anything or not... I updated the flash on the Bus Pirate since I was working on scanning for codes earlier in the year. I'm not entirely sure if the original firmware was running a serial clock on data out or not. That is absolutely essential for the radio to pay any attention to what you are saying.
Bus Pirate runs at 3.3v but can tolerate 5v logic, measurements seem to suggest to me that the radio uses 5v logic but then again, the measurements I've made were with the Bus Pirate and not a DMM.
Looks like the RC-10 brings RD (pin 6) to logic 1 (low) for about 250ms when the radio first turns on. I'm thinking that must be how it is telling the radio it is there. What I don't know is how the clock works. It doesn't run all the time, only when data is being sent or received. Also, when you adjust a control on the radio itself, it sends the data out on it's own. I'm thinking that the clock is run by whichever device has data to send. It also looks like the RC-10 sends 0xFF for each byte that the radio sends out. Maybe an acknowledgement signal of some sort?
Still working on the list of commands. Found a fair few sniffing the TX from the RC-10, but found even more after I separated those into groups and then sent the missing values from the groups. Seems like only 6 bits matter out of the bytes. There are two commands, VOL UP and VOL DWN, which use 2 bytes. 0x3C B0/0xBC 0xB0. I still haven't mastered these because they seem to continue to affect the volume after I send them. It either maxes out, or drops to 0. Only if the radio is told to use the remote unit's volume control instead of it's own. If it is, it's own volume control no longer does anything until a command is sent to re-enable it.
My progress is a bit hindered by the fact that my unit has the infamous LCD problem. It's full of garbled junk, and most of the time the elements are all faded out. Completely useless, but sometimes it works. Sometimes I can apply pressure and it works. I need to open it up and reseat the cable but I just haven't done it yet.
Ordered some parts on Ebay to make a sort of breakout box. Got some header pins, a jack that can accept a mic plug, and some other things like jumpers. I already have some perfboard with traces on it. I'll make it so I can plug my Bus Pirate into that and quickly disconnect the RC-10 to test things without it helping me. One of my major goals with this project is to make something standalone that can be used without a RC-10/RC-20 unit helping. It'll probably be a month before all of the stuff arrives though.
There are a couple of things I'd like to discover. I've found some things out already, and have a lot of buttons mapped but I can't completely replace direct control with an RC unit just yet. Some functions haven't been discovered yet. One other thing bugs me... When I first started working on this and didn't know what the protocol was I tried several other things with my Bus Pirate, one of which was I2C. Using the scan mode, I was hoping to discover if it was I2C and if so, what address. Somehow I accidentally overwrote the first couple memories in the radio with completely junk data. I may have blogged about that once actually, it's stuff that is impossible to enter in even with a keypad. I'm thinking there must be some mode to directly communicate and control the memory contents. I'd love to figure out how.
Showing posts with label TM-241a. Show all posts
Showing posts with label TM-241a. Show all posts
Sunday, September 2, 2012
Monday, April 9, 2012
TM-241a analyzing
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.
Fascinating!
Saturday, April 7, 2012
TM-241a Project update 4-7-12
Doh, I feel like such an idiot. Looking over the schematics for the TM241a and RC-20 manuals I see something I dismissed a long time ago. There's Serial In and Serial Out pins, but there's also a Serial CLK pin. Well, I was receiving data just fine without the clock, but apparently I've been spinning my wheels this whole time sending data to the transceiver. You have to clock the clock pin when sending data TO it. Unfortunately the Bus Pirate is apparently completely unable to clock it's clock pin in UART mode. Only in other modes like SPI and I2C. That sucks since I already have these nice probe cables for it and everything. I don't know if any generic FTDI type usb-serial chip does it. I think that's a pretty much dead part of the standard these days. I'd love to be proven wrong though.
Not even the latest v6.1 Bus Pirate firmware has support for this. You can see some commands in the help menu to twiddle the clock pin manually, but you get an error message in UART mode. :/
Not even the latest v6.1 Bus Pirate firmware has support for this. You can see some commands in the help menu to twiddle the clock pin manually, but you get an error message in UART mode. :/
Tuesday, April 3, 2012
TM241 analysis
As I write this, I'm almost done rescanning the 2 byte block. 0000-FFFF unless something happens between 00FB and 00FF then I don't think there's going to be anything here. :(
I think my next target will be trying to ape the kind of stream the radio sends out. (Maybe I'll even rig up something to spit it back to it, see what it thinks of that)
Of course, one possible application when I figure this out maybe making my own remote head. Others might use it to make a D-Star homebrew head that can control the radio as well as do the digital voice. Or maybe I'll eventually figure out multiple radios and make a protocol droid to translate from one control head to a different radio. RC-D710 maybe? As I posted before, It's possible to use that head with other radios, as an APRS tnc. But without control.
One thing I'd love to inspire is some sort of USB for radios. Or some sort of multivendor connection standard. It'd be great to connect multiple radios into a bus along with a control head that can operate all of them. I'm not talking just Ham Radios either.
Update: Scan finished. No hits in 0000-FFFF. :(
Sunday, April 1, 2012
TM241a Fuzzing
Okay, here are all of the possible combinations of data that I've tried:
(where I have "x" that's where I've stepped through 0-F in hex)
x0x2x1FF
x0x1FF
xxxx (Yes, every combination from 0000-FFFF)
That last one includes xxFF in the possibilities.
Nada. Nothing. Zilch. Zippo.
Like I've said before, the radio seems to follow a pattern for the second nibbles. Without the bitorder switched, the patterns are like this:
00 - Start
22622a1 Frequency
0222221 LCD elements
021 Mem Channel
01 Unknown (always 10 01)
FF - End
Sometimes S-Meter data shows up. It's the one element that breaks the pattern of the second nibble. But, the last 3 bits of it seems to always be 101. First 5 bits seems to be the S-meter bargraph length, or similar.
My thoughts have been on mimicing the patterns when trying to fuzz the data out.
I would also like to try to figure out what the I2C address search mode on the Bus Pirate looks like to a 1200 baud UART port. That may be my biggest clue because that's the one time I've really had an effect on the radio and it was completely junk data.
It could also be that the actual legit communications is so complex that it's not really possible to suss it out by searching a sequential pattern. I wouldn't think so, but there's got to be some sort of a memory access mode or I couldn't have entered corrupt data into Ch1 and 2 with the I2C search mode. The values were impossible to set by key entry alone. Heh, maybe the RC units communicate by writing to live memory. I wouldn't think so. I'd think a simple pattern of keycodes would be more than enough, but who knows what Kenwood was thinking when they designed these units.
I'd sure love to get my hands on one.
EDIT: Sigh, just noticed a rather glaring bug in my serial port TX in my program which probably resulted in me not sending out the values that I thought I was. In short, I have to run all of the above tests again. This time, sending the byte values out instead of the decimal representation of them. Snort. At least I didn't test 17 million values before discovering this tomfoolery.
(where I have "x" that's where I've stepped through 0-F in hex)
x0x2x1FF
x0x1FF
xxxx (Yes, every combination from 0000-FFFF)
That last one includes xxFF in the possibilities.
Nada. Nothing. Zilch. Zippo.
Like I've said before, the radio seems to follow a pattern for the second nibbles. Without the bitorder switched, the patterns are like this:
00 - Start
22622a1 Frequency
0222221 LCD elements
021 Mem Channel
01 Unknown (always 10 01)
FF - End
Sometimes S-Meter data shows up. It's the one element that breaks the pattern of the second nibble. But, the last 3 bits of it seems to always be 101. First 5 bits seems to be the S-meter bargraph length, or similar.
My thoughts have been on mimicing the patterns when trying to fuzz the data out.
I would also like to try to figure out what the I2C address search mode on the Bus Pirate looks like to a 1200 baud UART port. That may be my biggest clue because that's the one time I've really had an effect on the radio and it was completely junk data.
It could also be that the actual legit communications is so complex that it's not really possible to suss it out by searching a sequential pattern. I wouldn't think so, but there's got to be some sort of a memory access mode or I couldn't have entered corrupt data into Ch1 and 2 with the I2C search mode. The values were impossible to set by key entry alone. Heh, maybe the RC units communicate by writing to live memory. I wouldn't think so. I'd think a simple pattern of keycodes would be more than enough, but who knows what Kenwood was thinking when they designed these units.
I'd sure love to get my hands on one.
EDIT: Sigh, just noticed a rather glaring bug in my serial port TX in my program which probably resulted in me not sending out the values that I thought I was. In short, I have to run all of the above tests again. This time, sending the byte values out instead of the decimal representation of them. Snort. At least I didn't test 17 million values before discovering this tomfoolery.
TM241a Reverse Engineering Project Update
After a fairly long hiatus and a hard drive crash, I'm back at it working on this project. I am attempting to reverse engineer the remote control protocol in older Kenwood mobile radios. I'm using my TM241a but I understand that the RC-10 and RC-20 addons Kenwood used to make worked with a whole series of model numbers from TM-x21 through TM-x41 at least.
This was a secret from me until I found documentation and links talking about the RC10 and RC20 addons a year or two ago. I got my hands on operating manuals and service manuals for my radio, the RC-20 and the IF-20 addon. The IF-20 allowed you to connect up to 4 radios to a single RC-20. You could have 2,220,440 and 1.2 at your command if you were one of the lucky ones.
I've spent the last couple days poking around in the free Microsoft Visual Basic 2010 Express Edition writing a program to help me. My hardware interface consists of a Bus Pirate connected to the Mic plug on the radio using a spare plug I bought when working on a TNC project. I am running the Bus Pirate in transparent UART passthrough mode. Why not just use a usb-serial adapter? The Bus Pirate is already at the correct levels (TTL, not RS232) and I can program it to hold a pin HIGH, which is what the radio expects to enable it's remote control mode on the mic port.
Now, I can enter all of the Bus Pirate settings with a single button press on my program. I can read the display output continuously (though I still can't make sense of all of it yet). I can have a window with an active comparison going, output that is different is logged automatically. Right now, I'm running one of many routines to generate data and push it out the port. I'm trying to elicit a response from the radio by pretending to be an RC-20, or at least trying to guess what kinda of data one might send to it.
This would be unnecessary if I had access to either an RC-10 or RC-20, but alas they elude me. My fuzzing efforts are time consuming though. I've already ruled out 1 byte commands, sadly. That only took 255 guesses. I tried a 4 byte command guess with most of it filled in except for 3 nibbles. That took 4095 guesses. Nada. Now I'm sending 2 byte command strings, all guesses. That's 65535 guesses. Sadly, if I go up to 3 bytes then that's 16,777,215 combinations. Yes, almost 17 million!
BTW, I'm guessing about 40 times a second, so that's almost 30 minutes to run through 65535 guesses. 17 million isn't going to happen. There's a command for power on/off and transmit at least. Not to mention that while I was trying to figure out what protocol it used in the first place I accidentally entered junk data into it. Using the I2C address scan mode on my Bus Pirate somehow did it. That means there's a chance of a raw memory access mode. That could result in dangerous effects on my beloved radio, such as entering something that would cause the PLL to unlock permanently or TX at some weird frequency causing my finals to blow. I can't just let a fuzzing routine run all night while I'm asleep. A meltdown from excessive keydown is the least problem that could happen.
This is an example of the binary data the radio send out. It runs at 1200 baud 8,n,1 (ahh, bbs days)
00 82 22 A6 02 92 AA F1 40 42 02 12 02 22 01 E0 82 41 10 01 FF
The oddball part of this is that the bit order is reversed. ie 1100 would be 0011 actually.
If you reversed the bitorder and re-wrote the line:
00 14 44 56 04 94 55 F8 20 24 04 84 04 44 08 70 14 28 80 08 FF
The radio seems to use the first nibble for data, with the second nibble acting as some sort of checksum, or maybe even frame marker/address.
00 14 44 56 04 94 55 F8
0 1 4 5 0 9 5 F <- First nibbles only -- I'm on 145.095
0 4 4 6 4 4 5 8 <- Second nibbles only
Second nibbles of 0 and 8 seem to mark the beginning and end of subframes within the frame.
Second part of the frame from 20 through 08 seem to be fixed LCD elements (T +- BUSY etc)
70 - x8 are memory channels if you are in the MEM. This happens to be Memory Ch 12 for me.
70 14 28
7 1 2 <- ch 12.. Channels under 10 are 7 F x (where x is the channel #) so 7 F 9 is Ch. 09
0 4 8
...If I remember right, if you are in VFO or Call the Mem info is different, or missing entirely. That was in my notes that were lost forever in my hard drive crash a little while back.
80 08 are currently unknown for me.
00 and FF always mark the beginning and end of one whole frame.
Once you get the radio started, and all you need to do is send 1 byte of any sort at the right speed to it, then it continually sends display frames out at 1200 baud.
If you receive a signal, the S-meter data is sent out as well, in the form of setting one of the bits in the LCD element section and 2 additional bytes before the 80 08 pattern. It seems to have a hold pattern, if it's not changing then the radio stops sending the extra 2 bytes until it does change and then the radio will send out the changes again. I believe they resolve into the number of S-meter bargraph elements that should be lit up.
I'll keep plucking away at it. I do love a puzzle.
This was a secret from me until I found documentation and links talking about the RC10 and RC20 addons a year or two ago. I got my hands on operating manuals and service manuals for my radio, the RC-20 and the IF-20 addon. The IF-20 allowed you to connect up to 4 radios to a single RC-20. You could have 2,220,440 and 1.2 at your command if you were one of the lucky ones.
I've spent the last couple days poking around in the free Microsoft Visual Basic 2010 Express Edition writing a program to help me. My hardware interface consists of a Bus Pirate connected to the Mic plug on the radio using a spare plug I bought when working on a TNC project. I am running the Bus Pirate in transparent UART passthrough mode. Why not just use a usb-serial adapter? The Bus Pirate is already at the correct levels (TTL, not RS232) and I can program it to hold a pin HIGH, which is what the radio expects to enable it's remote control mode on the mic port.
Now, I can enter all of the Bus Pirate settings with a single button press on my program. I can read the display output continuously (though I still can't make sense of all of it yet). I can have a window with an active comparison going, output that is different is logged automatically. Right now, I'm running one of many routines to generate data and push it out the port. I'm trying to elicit a response from the radio by pretending to be an RC-20, or at least trying to guess what kinda of data one might send to it.
This would be unnecessary if I had access to either an RC-10 or RC-20, but alas they elude me. My fuzzing efforts are time consuming though. I've already ruled out 1 byte commands, sadly. That only took 255 guesses. I tried a 4 byte command guess with most of it filled in except for 3 nibbles. That took 4095 guesses. Nada. Now I'm sending 2 byte command strings, all guesses. That's 65535 guesses. Sadly, if I go up to 3 bytes then that's 16,777,215 combinations. Yes, almost 17 million!
BTW, I'm guessing about 40 times a second, so that's almost 30 minutes to run through 65535 guesses. 17 million isn't going to happen. There's a command for power on/off and transmit at least. Not to mention that while I was trying to figure out what protocol it used in the first place I accidentally entered junk data into it. Using the I2C address scan mode on my Bus Pirate somehow did it. That means there's a chance of a raw memory access mode. That could result in dangerous effects on my beloved radio, such as entering something that would cause the PLL to unlock permanently or TX at some weird frequency causing my finals to blow. I can't just let a fuzzing routine run all night while I'm asleep. A meltdown from excessive keydown is the least problem that could happen.
This is an example of the binary data the radio send out. It runs at 1200 baud 8,n,1 (ahh, bbs days)
00 82 22 A6 02 92 AA F1 40 42 02 12 02 22 01 E0 82 41 10 01 FF
The oddball part of this is that the bit order is reversed. ie 1100 would be 0011 actually.
If you reversed the bitorder and re-wrote the line:
00 14 44 56 04 94 55 F8 20 24 04 84 04 44 08 70 14 28 80 08 FF
The radio seems to use the first nibble for data, with the second nibble acting as some sort of checksum, or maybe even frame marker/address.
00 14 44 56 04 94 55 F8
0 1 4 5 0 9 5 F <- First nibbles only -- I'm on 145.095
0 4 4 6 4 4 5 8 <- Second nibbles only
Second nibbles of 0 and 8 seem to mark the beginning and end of subframes within the frame.
Second part of the frame from 20 through 08 seem to be fixed LCD elements (T +- BUSY etc)
70 - x8 are memory channels if you are in the MEM. This happens to be Memory Ch 12 for me.
70 14 28
7 1 2 <- ch 12.. Channels under 10 are 7 F x (where x is the channel #) so 7 F 9 is Ch. 09
0 4 8
...If I remember right, if you are in VFO or Call the Mem info is different, or missing entirely. That was in my notes that were lost forever in my hard drive crash a little while back.
80 08 are currently unknown for me.
00 and FF always mark the beginning and end of one whole frame.
Once you get the radio started, and all you need to do is send 1 byte of any sort at the right speed to it, then it continually sends display frames out at 1200 baud.
If you receive a signal, the S-meter data is sent out as well, in the form of setting one of the bits in the LCD element section and 2 additional bytes before the 80 08 pattern. It seems to have a hold pattern, if it's not changing then the radio stops sending the extra 2 bytes until it does change and then the radio will send out the changes again. I believe they resolve into the number of S-meter bargraph elements that should be lit up.
I'll keep plucking away at it. I do love a puzzle.
Thursday, February 16, 2012
TM-241a Sniffing
May have found a RC-10 for sale. These were compatible with the remote control interface on this radio (and a few other Kenwoods) It looks like a car phone handset. Remember when cellphones came in a bag variety? Kinda like that. I'm hoping that I can use my Bus Pirate with it to sniff out the correct commands to control my radio. May be just what I need to get my TM-241a computer control project back up and running.
Saturday, November 12, 2011
New theme, TM-241, etc
I'm trying out a new theme to go with the changes behind the scenes at Blogger. It's a little less plain than my old one but I'm not sure if the navigation is going to be a pain, especially for people with older computers. If anyone experiences that, leave me a message on this post?
I haven't forgotten about my work on reverse engineering the remote control protocol for the Kenwood TM-241a radio. I've been very busy with school work lately. I'm in my final month of my Associates degree at IvyTech for Computer Information Technology. I am on track to keep my 4.0 GPA too, which is great. It's caused me no end of stress right now though. I'm on a program that let people who had their jobs displaced to other countries go back to school for a 2-year degree. Many of us did so with the idea that the economy was going to be in much better shape by now. At least, I did. I've been applying for positions since June and haven't had much luck even getting interviews. Once my education program ends, so does my unemployment. Shortly after that... we're going to be in trouble. Of course, one of the places I have applications at right now may come through and save us at the last second. Not that I can count on that though.
I'm thinking about trying some ads on here to see if I can get a little ad money.
If anyone knows anyone hiring within 30-60 minutes of Richmond, IN.. please, let me know. I'll have an Associates degree and I also already have my A+ certification. I'll be taking the Network+ soon and should get that easily.
Speaking of the Kenwood TM-241a work.. I haven't managed the basic application to fuzz out the numbers. It seems doing serial comms under .NET is a little hairy. Also, the Bus Pirate's binary mode is easy to get into but a little hard to use so far. I'm a little inexperienced in it, so it might just be I'm not understanding it right. From what little by-hand fuzzing I've done using a terminal mode on the Bus Pirate.. I feel like my original theory is wrong. I was hoping it would be a simple 3 byte command.. an address and two bytes for the command. The protocol to send the display information out seems to have 1 nibble of data along with 1 nibble of check information. So for example, 0x00 0x04 0x04 0x04 0x08 might be a valid packet with the first nibble having data and the second nibble being a check digit of some kind. The nibbles might have BCD numbers or be bit-level information for single LCD elements. My theory with the control scheme was with 1 byte for address, and 2 bytes for data.. that's 2 nibbles or one whole byte for data giving 256 possible combinations of buttons or commands.
Now, in previous experiments I have managed to affect something while sending data. Once I managed to have the radio skip around in the memory channels by significant steps. Another time, before I figured out the exact communication settings, I managed to overwrite the memory channels with bogus data. That's probably the greatest clue that what I may be dealing with is direct control over the internal memory of the radio. If so, my job is significantly harder. I need to figure out how to address specific areas of memory and what the contents mean, all while not being able to read it directly.
...
Or can I? Looking at the service manual, there's no information on what the main cpu is, and it looks like no external memory. If I could figure out what the cpu is, I can at least figure out my constraints. Working further on fuzzing the interface, I may be able to figure out the correct way to issue address commands and data. The main questions are: How many bytes do I need for an address? Do they require the checkdigits like what is used to talk to the LCD? How many bytes do I send after the address? Checkdigits? What is the constraints on memory area I can address? With that, I can start poking values into memory to see what happens. I know there's a soft power off feature, so you can turn the radio off from the remote control interface. There's also got to be a method to key the transmit, because the PTT line is one used for the communications.
There's apparently an internal basic scripting language on the newer Bus Pirate firmwares. I may need to look into upgrading mine. If it doesn't work, I have a cheap ICSP capable programmer here that I can maybe revert it with.
I haven't forgotten about my work on reverse engineering the remote control protocol for the Kenwood TM-241a radio. I've been very busy with school work lately. I'm in my final month of my Associates degree at IvyTech for Computer Information Technology. I am on track to keep my 4.0 GPA too, which is great. It's caused me no end of stress right now though. I'm on a program that let people who had their jobs displaced to other countries go back to school for a 2-year degree. Many of us did so with the idea that the economy was going to be in much better shape by now. At least, I did. I've been applying for positions since June and haven't had much luck even getting interviews. Once my education program ends, so does my unemployment. Shortly after that... we're going to be in trouble. Of course, one of the places I have applications at right now may come through and save us at the last second. Not that I can count on that though.
I'm thinking about trying some ads on here to see if I can get a little ad money.
If anyone knows anyone hiring within 30-60 minutes of Richmond, IN.. please, let me know. I'll have an Associates degree and I also already have my A+ certification. I'll be taking the Network+ soon and should get that easily.
Speaking of the Kenwood TM-241a work.. I haven't managed the basic application to fuzz out the numbers. It seems doing serial comms under .NET is a little hairy. Also, the Bus Pirate's binary mode is easy to get into but a little hard to use so far. I'm a little inexperienced in it, so it might just be I'm not understanding it right. From what little by-hand fuzzing I've done using a terminal mode on the Bus Pirate.. I feel like my original theory is wrong. I was hoping it would be a simple 3 byte command.. an address and two bytes for the command. The protocol to send the display information out seems to have 1 nibble of data along with 1 nibble of check information. So for example, 0x00 0x04 0x04 0x04 0x08 might be a valid packet with the first nibble having data and the second nibble being a check digit of some kind. The nibbles might have BCD numbers or be bit-level information for single LCD elements. My theory with the control scheme was with 1 byte for address, and 2 bytes for data.. that's 2 nibbles or one whole byte for data giving 256 possible combinations of buttons or commands.
Now, in previous experiments I have managed to affect something while sending data. Once I managed to have the radio skip around in the memory channels by significant steps. Another time, before I figured out the exact communication settings, I managed to overwrite the memory channels with bogus data. That's probably the greatest clue that what I may be dealing with is direct control over the internal memory of the radio. If so, my job is significantly harder. I need to figure out how to address specific areas of memory and what the contents mean, all while not being able to read it directly.
...
Or can I? Looking at the service manual, there's no information on what the main cpu is, and it looks like no external memory. If I could figure out what the cpu is, I can at least figure out my constraints. Working further on fuzzing the interface, I may be able to figure out the correct way to issue address commands and data. The main questions are: How many bytes do I need for an address? Do they require the checkdigits like what is used to talk to the LCD? How many bytes do I send after the address? Checkdigits? What is the constraints on memory area I can address? With that, I can start poking values into memory to see what happens. I know there's a soft power off feature, so you can turn the radio off from the remote control interface. There's also got to be a method to key the transmit, because the PTT line is one used for the communications.
There's apparently an internal basic scripting language on the newer Bus Pirate firmwares. I may need to look into upgrading mine. If it doesn't work, I have a cheap ICSP capable programmer here that I can maybe revert it with.
Saturday, October 29, 2011
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.
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.
Thursday, October 27, 2011
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.
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.
Wednesday, October 26, 2011
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)
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)
Subscribe to:
Posts (Atom)