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.