Rob,

I'll post some info on how to open the remote shortly!

Randy
www.BlueDo.com

This message was edited by www.BlueDo.com on 05/21/02 11:08.44.

I have a little progress to report on the IR front. I have been able to get my hardware and software combo to successfully record key presses from my MX-500 and when captured on my PC I can play them back to the MX which successfully captures them AND now controls my equipment correctly. Nothing new in that. You could say that I can use it to move move functions from one key to another which is a little victory.

I tried figuring out the IR protocol between a sending MX and receiving MX. I can see that when you put a MX into "SEND" it outputs a short pulse about once a second. It seems logical that this is a signal to a receiving device which says "I'm here tell me when you are". Theoretically if I capture this "SEND" pulse on my PC, which I have done, I should be able to put my MX into receive mode, replay the "SEND" pulse and capture whatever the receiving device sends out. If I can then capture the "RECEIVE" pulse and replay it to a MX, in send mode, the MX should dump its configuration to the PC. So far I haven't been able to capture the receive pulse. The MX doesn't respond to my PC captured "SEND" pulse. I have a sneaky feeling that the SEND and RECEIVE pulses are being sent at a very high frequency. They are extremely short (14 samples versus over 200,000 for a normal key press) and the PC may not be able to capture them properly. I have captured the "SEND" pulse on a learning Sony remote and when I replay it to the MX in receive mode it causes it to abort the "RECEIVE WAITING" cycle and the MX then indicates "FAILD". I hope to be able to capture the SEND pulses on an oscilloscope tomorrow to see what frequency they run at so I can figure out the next step. Wish me luck!

Mike

Good luck, Mike!

Mike C sent me a picture of the PCB of the MX-500, which I have posted on my site so y'all can see it, but those of you will slow connections be warned, it's over 1MB:



Rob.

I had a look at the signals driving the IR transmitters on a scope. I found that when I set the MX to send mode it would send out one of two codes. One for send device and the other for send all. A code is made up of one of two pulse types. The first I call short and is a 1.6 us (microsecond) on pulse followed by an 11.7 us off pulse. The total period was 13.3 us. The second I call long and was the same 1.6 us on pulse followed by an 18 us off pulse for a total time of about 20 us.

The send all code consisted of the following sequence of short and long pulses:

SLSLSLSL followed by a 1.6 us on pulse. (9 on pulses total).

The send device code consisted of the following sequence of short and long pulses:

LSLSSLSL followed by a 1.6 us on pulse. (9 on pulses total).

These on pulses are pretty short for a remote control representing a carrier frequency of about 300 KHz. I'm sure my IR transmitter/receiver combo, which can be seen at

[Link: jdresearch.com]

has the capability to capture short pulses as it supports FIR (Fast Infra-Red) which allows it to operate up to 4 MHz. Unfortunately my motherboard doesn't have a FIR capability, just CIR (Consumer Infra Red). I don't think that the software that I am using to interface my PC to the IR device above, through the parallel port, can run fast enough to capture these short pulses accurately, if at all. I don't know if a serial port will run at a baud rate of 300 KHz.

At this point I am trying to figure out how to proceed so any suggestion would be more than welcome.

Mike

P.S. The software I am using can be found at

[Link: ziplabel.com]

I am using the WIN32DLL version, which is at

[Link: ziplabel.com]

Mike

Most of this is beyond my capability to understand, but you may want to look at this guy's work on furbys and IR.
[Link: veg.nildram.co.uk]

Mike,
Looks like the data sent out is eight bits of real data. If we assume a long 'L' is a one '1' and short 'S" is zero( it's all relative ), the "send all" code is 0x55 hex and "send device" is 0xa5 hex. One way to get around this speed issue ( if the m-board doesn't support that speed ) is to build a circuit to translate the fast IR signals and then downshift the data to something the PC can handle. A small microcontroller could easily measure ( to receive ) or produce ( to transmit ) these pulses and interface to the PC's parallel port. The effective parallel data transfer rate would then be about 8400 khz.
It looks like the ir module you're using would work with this type of interface.
Harware design straightforward - software design simple but just takes time.

bfossett

Thanks, I had already grabbed that software and I'll give it a whirl in the near future.

subkron

That's what I was thinking but the nine pulses are bothering me. Let me ask you to think about something else in terms of protocol. Have a look at the irDA IrPHY 1.4 spec at

[Link: irda.org]

Notice that a zero is sent out as a 1.6 us pulse in all cases up to 115.2 KHz. A one is sent out with no pulse. I keep coming back to irda because of this but I can't make the pattern I measured fit into any of the irda baud rates. Can you give it some thought please and see if you can come up with something. I've also put my irda transmitter into real irda mode with ME drivers and the thing sits there outputting a pulse about every 3 seconds. This is very similar to what the MX is doing in Send mode, at least for 30 seconds or so. Let me know if you come up with anything please. Thanks.

Mike

How about if we all just call and complain to Universal Remotes that they need to give us a way to backup and restore the programming? Maybe if they get enough complaints they will act upon it. Like others I have a huge investment of time into the programming and tweaking. I have macros and am using all 10 devices. I've got everything documented but it would take me many, many hours to recreate if my remote went south. I'm considering purchasing another just so I have a way to backup this one. Unless of course the MX-700 can clone it, in which case that's the preferred solution.

I don't see this feature request feasible without added hardware. Without the production runs in the thousands (or tens of thousands) I suspect the hardware would cost as much as another MX-500!

The MX-700 resolves all of this... :)

Randy
www.BlueDo.com

The MX-700 cannot clone an MX-500.

"The MX-700 cannot clone an MX-500"

Well that's very dissapointing. I have intentionally learned some of my MX-500 buttons as strickly one "pulse" of IR. (I used the Girder logger plug-in to display the IR string(s).) I also learned one of my devices as several other devices from a RS 15-1994 remote because I needed to be sure the IR strings were unique and were not being sent out as two different strings. I suppose it will be relatively easy, just time consuming, to manually port my MX-500 programming to a MX-700. Better than redoing it from scratch that's for sure.

It will be much, much easier than learning from the multitude of remotes you learned to the MX-500.

You will easily create your configuration in MX-Editor, and then the software will step you from button to button in LEARN mode, and all you have to do is push the corresponding button on your MX-500.

The software automatically moves you to the next button ready for you to learn.

... Greg :-)

If you have a handheld I'd suggest avoiding a custom solution. Use one of a few hacks out there for the Palm platform to collect IR. One example is USB-2-IR written by Matthias Ringwald. It passes IR through the cradle and thus through the USB to your PC.

Someone else has a utility to 'capture' all received IR and 'repeat' it back out... I'm having problems finding it at the moment though.

Wouldn't these work? Assuming you have a handheld.

Just a quick note to let you know that I have been designing and building a little gizmo to look like a MX in cloning mode. It's pretty much working and I hope to be able to put together the next piece of the puzzle soon. I hope it's the last.

Mike