so can i backup to a computer or not

No. Not right now. Unless someone comes up with some sort of interface using IR or the 7 pin connector. I don't believe HTM has any plans for this.

This may sound like a bit of work, but I like the idea that Daniel and others have had of planning out their layout in a Spreadsheet before programming the MX-500. In the rare even that your MX-500 loses its programming, at least you have your master plan to go back to.

Even doing so on an 8 1/2 x 11 sheet of paper and keeping it file away would be worth it. IMO.

MX_500 unfair to UR hackers!!!!!

Come on URC where is the fun in this remote? Two evenings and it is working like a charm. I mean it learnt or had internally every button on every remote I own and 50 FAVs programmed to boot. I only had some trouble with some advanced Sony codes which I cured with an old AV8. I've tried PDAs with extra transmitters that keep falling off. I've tried RS-1995 and JP1 and Pronto and they all took a week or two of frustration and learning and FUN before I returned them. My wife has threatened to divorce me if I take the MX-500 back:) Every remote but the MX-500 is now off the coffee table. Come on URC I was looking forward to at least two weeks of hassling with this thing and you've denied me the pleasure of that. It's just too easy - UNFAIR:) Life wasn't meant to be easy, MX-700 you say, never heard of it.

I guess I am going to have to see if I can hack the MX-500. I tried an IrDa device from BAFO last weekend but that didn't work with the cloning feature. I tried using a program called winlirc with it which could be promising with a serial IR device rather than the USB device I tried. I guess I'm just going to have to try something else to make it work with my PC as that is the only mountain left to climb.

Mike

Go for it, Mike!

I have tried to use winlirc to capture remote codes to my PC and play them back but it one seems pretty unreliable and two it requires you to press the "to be learned" button 10 times which is a bit much. I built the hardware and got the software via the winlirc homepage at

http://winlirc.sourceforge.net/

I don't recommend it as I found out that the sensor has a limited bandwidth around 40KHz which may not be good enough for the cloning process.

I then purchased a device called the "Infrared Drive Module Kit" which can be found at

[Link: jdresearch.com]

If you follow the link for "Where to Buy" you can get this on line (TM Data in Austria Martin H). I purchased mine at Fry's in the Bay Area. I tried this using the IRDA protocol on my PC which my motherboard supports (ASUS CUSL). Although the module received something the MX-500 doesn't seem to be using the IRDA protocol .

I then used this kit as the IR receiver and transmitter that can be found under the schematic section of

[Link: ziplabel.com]
[Link: ziplabel.com] (Schematic)

The kit has four wires (5V, GND, IRRX and IRTX). I used the IRDA connector to supply 5V and GND to the kit and by lifting up the black plastic tang with a pin on the yellow (IRRX) and white (IRTX) wires was able to withdraw them from the supplied connector. Using a 25 pin DB connector, I soldered a 220 ohm resistor between pins 3 and 13 and connected the yellow (IRRX) wire to pin 13. I soldered the white (IRTX) wire to pin 2 of the DB 25 connector. Using the software found at the CIR site, my PC was able to receive and transmit IR codes. The MX-500 even said the codes were good but unfortunately they didn't operate the equipment correctly. I think the CIR software is having a problem figuring out the correct speed of the CPU and is interpreting them incorrectly.

Martin H you said that you might be able to help with the software. Is it possible that you could adapt the CIR software so that it reads codes correctly? There is also some software that works at the following link but it is based on the CIR software above.

[Link: dishhead.home.insightbb.com]

In addition I ohmed the pins of the MX-500 to see what I could see. Looking at the back with the battery cover off and the display at the top I found that the three pins on the right are connected to each other and also to the right hand battery terminal. I figured these are GND for the MX-500. I couldn't figure out where the four pins on the left were connected. I tried opening the case but the gap around the MX-500 is so small that it is not possible to insert a cut up credit card. The MX-500 is pretty tough as I couldn't find anywhere that it yielded. I did not try anything metallic - yet.

I hope this helps somebody. I won't be able to do much next week but if anyone wants to send an email I'll try to answer.

I also hope this post doesn't violate any rules on Daniel Tonks' excellent site.

Mike

With help from Greg I was help to open up the MX-500 without damaging it. Thanks Greg.

I found the 7-pin connector (CN2) has labels on the circuit board as follows:

The right hand three were GND as I thought.
Starting at the top of the four pins on the left, and going down, there are labels that say 37, 39, 40 and VCCVX2. The first three numbered pins go to resistor/diode static protection circuits (R11 thru R13 and D3 thru D8) and then to pins of the same number on what is obviously the controller. This is the largest chip on the board and is labeled

127
OHS1002P
OHSUNG

I cannot find data on this IC although OHSUNG do make remotes - see [Link: 202.31.143.8] . Without this data I cannot determine which of these pins do what.

The fourth signal, VCCVX2, passes through a diode and drives the 3.7V VCC to the remote. It also passes through another diode but I didn't trace where that went. By applying approximately 4.2 to 4.3V between this pin and GND one can power the remote externally after removing the batteries. So access to the connector and powering the remote is possible when the batteries are removed.

The second largest IC is the PROM and it is labeled SST 39VF010. The data sheet can be found at [Link: ssti.com] .

Unfortunately this is a parallel PROM, not serial, and it only interfaces with the controller. The PROM is 128K by 8 bits. According to the data sheet his PROM needs special codes to access it. I haven't read the data sheet in detail to see if they are user selectable or fixed as yet.

Clearly accessing the PROM is done by the controller and communicated to the CN2 connector via pins 37, 39 and 40. And vice-versa of course. There will be a software protocol that needs to be followed to cause the controller to read or write to the PROM. I don't think we'll find out by hacking it unless there is someone with knowledge of this chip who is prepared to share it. Assuming the software for the controller is stored in this PROM it might be possible to take it off and read it on the bench. However there is sometimes another PROM inside controllers which contains the program so it may not be stored in the 39VF010 at all. You could also put a logic analyzer on the PROM and capture its contents as they are executed. That really is hacking it and I don't know if that is legal or not. But even if you can do that you still need to know the instruction set of the controller to understand it.

I might pursue the electrical approach further but the IR approach seems the best bet at present. Sorry I can't give you better news.

Mike

I understood EVERY word until he got to the 7-pin connector part (second line!) LOL

Greg, I think we may have a new champion in the making!

Greg,

I could spell it out in more detail if you'd like! ;)

Mike

Well, I could understand it all(laugh on dotted line.........), but don't you just HATE it when they put in a parallel PROM when you really just want a serial one! ;-)

Guess on the PROM is that it contains both the program memory and the reconfigurable aspects of the MX500. For this size of memory it wouldn't be prudent ( cost effective ) to add additional memory just to store the configurations with that amount of FLASH. I doubt you'd get anywhere with a logic analyzer in that case.
Be interesting to scope out the three lines and look for activity - suspect they are serial data in/out/clock. If no activity then really need the protocol for interfacing.

Subkron,

I agree on scoping out the signals which I'll try when I can. Not sure why you think using a logic analyser wouldn't reveal anything if the code is in the PROM.

Mike

Mike,
Was figuring that the configurable parameters would be buried within the program memory space and would be hard to find. If you set up the analyzer to trigger on writes only, it would filter out the instruction fetch data. At some point you may be able to decode the addresses used for each item stored in FLASH. However, I suspect that it would only be unique to that firmware version, since the code was probably relocatable for compilation. Also, if you could trap the data, it would be hard to get at/change unless you did some "major" instrusion by desoldering the PROM, etc...

Wow - wouldn't it be cool to decode or get the serial protocol ?

I've just been tipped off to this thread, keep up the good work. Greg, how did you get the MX500 open? I was given one for a few days to see what I could find out regarding it's hackability but I couldn't get it open (and I wasn't allowed to scratch it up).

Could someone who has opened it up take some pictures and post them somewhere please. If you have pictures but don't have a web site, I'll post them on mine.

I think it might be time to bring Tommy Tyler in on this!

Rob.
[Link: hifi-remote.com]

This may be the best news I've heard yet! Even eclipsing Mike's hint about lower MX-700 pricing. :)