Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

XMP-R Ir protocol?

Status
Not open for further replies.
Hi again,


Nigel:
Now that you mention it i have tried other remotes with detectors that were made for a different carrier and yes i got pulses out too, but i think there may be some optimization for the carrier frequency that they are made for. I cant remember now as it has been quite a while since i looked at detectors.

evaine:
Yes, i see the shift much more clearly now, and it appears that they are enlarging one or more areas of the waves to change the code.
What you need to do is look at the signal again and find out the carrier burst frequency so you can use that to generate the pulses, then TRY generating some pulses with your microcontroller by making a temporary program to try one code out with. That's the only way you are going to get this project to fly, or so it seems.
Try generating one of the buttons like the '1' key and see if you can get the device to respond favorably. Try it as the next thing you do and you may find it works.
We know now the pulses are getting wider, so try that. Without a document on the protocol we're not going to get too far without doing some experimenting.

ADDED:
Ok, i found something on the XMP protocol, and guess what? They do in fact use a repeat code after an initial code that is sent only once. This means you really have to see that first set of pulses to decode this pattern.
Also, it seems that there is a 'checksum' that is also sent that is probably like other checksums...where the device will ignore the code if the checksum does not match the received checksum.
You've got your work cut out for you now, unless you can get some solid documentation on this. You are absolutely going to have to be able to view the entire set of pulses from the very start when the button on the remote is first pushed. You can then just mimic everything and that should get you there.
 
Last edited:
I'll try to calculate the timing of one of the signals and write up a small µC program to send it out. Do you know if the XMP-1 protocol has the checksum you mentioned. There are several version, XMP-1 I believe is uni-directional, either XMP-2 or XMP-4 is bidirectional. Either way, it looks like this is going to be a pain to implement, why did the industry adopt this protocol.
 
Hi,

I dont know that much about the protocol really, just a few things, and from what i know now in order to use this the same way your remote does you have to mimic the signals the remote is sending out as closely as possible. I dont really know much about the different versions either unfortunately. I think one version uses the first window of pulses and another version uses the second window of pulses, and the other window not being used contains a constant set of pulses or all zeros.
Knowing that the sent pulse streams can change after the first set is sent though tells you a lot about this protocol though, in that if you can measure the timing for say the '1' key you should be able to mimic that set of pulses somehow or another. It may take some trial and error though, but it should be possible i would think. This way you dont actually have to calculate any checksum either because it will already be present in the signal you are measuring and if you mimic it then it has to get sent correctly.

I suspect the industry was looking for a more versatile protocol, rather than bang bang your done type signal, so it could be used for more and more devices possibly across many technologies aside from TV and VCR and stuff like that. If you say that some versions are bi directional, that's very interesting too. Unfortunately, just like the hop from RS232 to USB the advance in the technology took such a leap that it makes it much harder to use. It may even be that it is impossible to use without having a good paper that describes the entire transmit technology defining every transition, but i hope not. There must be some where to get it though. Maybe try some other sites too and i'll ask around also.
 
Last edited:
Hi again,


Nigel:
Now that you mention it i have tried other remotes with detectors that were made for a different carrier and yes i got pulses out too, but i think there may be some optimization for the carrier frequency that they are made for. I cant remember now as it has been quite a while since i looked at detectors.

There's seems to be a fairly crude filter centred on the target frequency, which would presumably limit the maximum range, but all I've ever used easily work further than you even need.

I suspect the industry was looking for a more versatile protocol, rather than bang bang your done type signal, so it could be used for more and more devices possibly across many technologies aside from TV and VCR and stuff like that.

Most remote controls are already very versatile, check my Sony PIC tutorial which describes SIRC's, others have similar capabilities.
 
Most remote controls are already very versatile, check my Sony PIC tutorial which describes SIRC's, others have similar capabilities.

Hi again,


I havent been keeping up to date on these devices so all i know about are the ones that i have presently. I think the bi directional transmission is very new at least to me it is.
 
Hi again,


I havent been keeping up to date on these devices so all i know about are the ones that i have presently. I think the bi directional transmission is very new at least to me it is.

Bi-direction control is pretty well non-existent, and it's not required in the VAST majority of cases.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top