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)
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
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.