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