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.

Fascinating!

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. :/

SDR with $20 TV Tuner card.

http://hackaday.com/2012/03/30/working-software-defined-radio-with-a-tv-tuner-card/
I was going to hold off posting about this until I got mine and could try it out, but I ordered 2 weeks ago and it hasn't shipped yet so I'll drop a line now. There's been some developments on this story since then anyways. Here's a video where someone is showing this running in real time in GNU Radio.



There's also suppose to be support in Windows now too.

Basically, these are $20 laptop TV Tuner dongles from China. USB connections and they are for DVB-T which is the European digital broadcast TV standard. The US uses ATSC for broadcast and QAM64, QAM128, QAM256 for cable typically. There's a fair bit of satellite stuff that uses DVB-S/S2 though. Someone did some sniffing of the card and discovered that the FM radio portion of it was actually a SDR. It's only 8-bit but the possible frequency range is 64-1700mhz.

I'm giddy over this for a couple of reasons. If it can be made to work cheaply, hello cheap receivers to stick in other places. Yeah, the downer is the processing power required for it to actually work. Processing power is cheap these days. Also, what a neat platform for a potentially automated receiver. No interface cables needed either, plug into USB and play.

Neat!

TM241 analysis

Thought it'd be fun to post a picture of my radio with the probes on the mic jack. I'm using a plug I bought in a pack to make interface cables. The antenna behind the radio is actually the rubberducky for a handheld scanner. My TM-241a is sitting on a wood block to separate it from the Alinco DR-600 below it. (My next target? Heh) These probes connect to a Bus Pirate out of the picture. The one alligator clip stands in for a particularly weak probe clip that kept falling off.

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. :(

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.

April 1st

I'd like to officially register my annoyance of all of the fake news stories that every tech site, and some stores, seem to love to post on April 1st every year. It was tired in the 90s. It's over 10 years later. I need some sort of filter for this stuff.

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.