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.

evaine23

New Member
I’m looking to make an infrared protocol converter box for my DVR. Any input will do but I need to output XMP-R 62.16 (protocol used for many of the Comcast DTAs and STBs). I’m trying to find some information about the XMP-R (XMP1) protocol but I haven’t seen anything in my searches. Does anyone know if this goes by a different name? I’ve seen the remote codes provided in hex format for use with various IR blasters, but I don’t understand, without seeing the protocol, carrier frequency, and pulse lengths how to translate these values into a signal. If anyone knows where I could find some information on this IR protocol to get me started that would be very helpful. I’ve been searching for a couple of days but haven’t turned up anything conclusive yet.
 
Unfortunately I don’t own a PICkit2, I’ve tried tracing the signal with my analog oscilloscope, but I was not able to detect variations between some of the keys being pressed. I did hear that the XMP protocol does not use a header region so the carrier frequency may be more important, although I cannot confirm this yet. I’ll keep looking into it and maybe later I’ll try and record a few of the signals with my scope. Should at least get me started.
 
Unfortunately I don’t own a PICkit2, I’ve tried tracing the signal with my analog oscilloscope, but I was not able to detect variations between some of the keys being pressed. I did hear that the XMP protocol does not use a header region so the carrier frequency may be more important, although I cannot confirm this yet. I’ll keep looking into it and maybe later I’ll try and record a few of the signals with my scope. Should at least get me started.

You really need a storage scope (or the cheaper PICKit2 option) - where are you connecting the scope? - you need to do it at the output of the IR receiver IC, where you get just the required data.
 
Well this is the initial results I came up with. I used a reversed biased diode as a receiver and filmed the patterns on my scope. I apologize for the abysmal image posted below but it does show that very slight variations in the pattern correspond to different values being sent. It looks like the gap between the pulses may be changing for some of the similar looking patterns. The first half of the pattern was the same for every signal sent. If anyone has any thoughts on this protocol let me know, there must be some documentation out there somewhere. I have heard that the pattern may contain some toggle bits to check for multiple key-presses, but I haven’t seen evidence of this yet either.
**broken link removed**
 
I'll have to see if i can get my hands on a receiver or an IR receiver IC. As this is rental property from Comcast I don't want to void the warenty on the DTA by opening it up. I've already paid them enough money for partially working cable and to render my DVR useless. If the carrier signal is the same, I might be able to pull a receiver module out of an old VCR. While looking around I found these HEX codes for the remote, but I have no idea how to translate these into a signal. I think these are used to program a JP1 remote.
0
Device Code: 62.16 Function: 0
0000 006D 0000 0012 0008 0022 0008 0041 0008 001D 0008 006A 0008 0032 0008 0032 0008 002C 0008 0065 0008 020D 0008 0022 0008 006A 0008 001D 0008 001D 0008 001D 0008 001D 0008 001D 0008 001D 0008 0BF2


1
Device Code: 62.16 Function: 1
0000 006D 0000 0012 0008 0022 0008 0041 0008 001D 0008 006A 0008 0032 0008 0032 0008 002C 0008 0065 0008 020D 0008 0022 0008 0065 0008 001D 0008 001D 0008 001D 0008 0022 0008 001D 0008 001D 0008 0BF2

2
Device Code: 62.16 Function: 2
0000 006D 0000 0012 0008 0022 0008 0041 0008 001D 0008 006A 0008 0032 0008 0032 0008 002C 0008 0065 0008 020D 0008 0022 0008 0060 0008 001D 0008 001D 0008 001D 0008 0027 0008 001D 0008 001D 0008 0BF2

3
Device Code: 62.16 Function: 3
0000 006D 0000 0012 0008 0022 0008 0041 0008 001D 0008 006A 0008 0032 0008 0032 0008 002C 0008 0065 0008 020D 0008 0022 0008 005B 0008 001D 0008 001D 0008 001D 0008 002C 0008 001D 0008 001D 0008 0BF2

4
Device Code: 62.16 Function: 4
0000 006D 0000 0012 0008 0022 0008 0041 0008 001D 0008 006A 0008 0032 0008 0032 0008 002C 0008 0065 0008 020D 0008 0022 0008 0056 0008 001D 0008 001D 0008 001D 0008 0032 0008 001D 0008 001D 0008 0BF2

5
Device Code: 62.16 Function: 5
0000 006D 0000 0012 0008 0022 0008 0041 0008 001D 0008 006A 0008 0032 0008 0032 0008 002C 0008 0065 0008 020D 0008 0022 0008 0051 0008 001D 0008 001D 0008 001D 0008 0037 0008 001D 0008 001D 0008 0BF2

6
Device Code: 62.16 Function: 6
0000 006D 0000 0012 0008 0022 0008 0041 0008 001D 0008 006A 0008 0032 0008 0032 0008 002C 0008 0065 0008 020D 0008 0022 0008 004B 0008 001D 0008 001D 0008 001D 0008 003C 0008 001D 0008 001D 0008 0BF2

7
Device Code: 62.16 Function: 7
0000 006D 0000 0012 0008 0022 0008 0041 0008 001D 0008 006A 0008 0032 0008 0032 0008 002C 0008 0065 0008 020D 0008 0022 0008 0046 0008 001D 0008 001D 0008 001D 0008 0041 0008 001D 0008 001D 0008 0BF2

8
Device Code: 62.16 Function: 8
0000 006D 0000 0012 0008 0022 0008 0041 0008 001D 0008 006A 0008 0032 0008 0032 0008 002C 0008 0065 0008 020D 0008 0022 0008 0041 0008 001D 0008 001D 0008 001D 0008 0046 0008 001D 0008 001D 0008 0BF2

9
Device Code: 62.16 Function: 9
0000 006D 0000 0012 0008 0022 0008 0041 0008 001D 0008 006A 0008 0032 0008 0032 0008 002C 0008 0065 0008 020D 0008 0022 0008 003C 0008 001D 0008 001D 0008 001D 0008 004B 0008 001D 0008 001D 0008 0BF2
 
Hi there,


I've used a cheaper scope to detect several types of IR transmissions and was able to decode every button code.

Using those scope pics, you can see that when the pulse is 'up' you can call that a logical '1' and when down a logical '0'.
As you can also see, the codes change when the different buttons are pressed. All you have to do is mimic the timing and you're all set.
Measure the time between pulses and the pulse duration and use that to generate your own pulses using a microcontroller. To start, you may want to just do the 'on/off' key or whatever, get that code transmitted and working, then simply program in the other codes after coming up with a more general algorithm.

It's definitely doable as i have done it in the past with at least four different remotes of varying carrier frequency. BTW, the carrier frequency does matter sometimes because many of the different detectors are tuned for certain carriers and work best that way, however if you get the pulse time right and the time between pulses right you will get the carrier right too.

There is usually a long pulse before the start of any of the codes, but i cant be sure this is true for every single device.
 
I've done what you are describing with an older remote control for my tv and it worked fine. With the previous remote, the timing for a low or a high were the same, it was just a matter of reading the sequence. With this protocol, it looks like minute changes in the timing between the pulses may be resulting in a different signal being sent. So a 1 or a mark isn't necessarily 60ms and a 0 or a gap isn't necessarily 120ms indicating consistent times for each state. from the picture, several of the signals look the same, but on the scope i can see small differences in the gaps between the pulses.
 
I've done what you are describing with an older remote control for my tv and it worked fine. With the previous remote, the timing for a low or a high were the same, it was just a matter of reading the sequence. With this protocol, it looks like minute changes in the timing between the pulses may be resulting in a different signal being sent. So a 1 or a mark isn't necessarily 60ms and a 0 or a gap isn't necessarily 120ms indicating consistent times for each state. from the picture, several of the signals look the same, but on the scope i can see small differences in the gaps between the pulses.

Hello again,


Yes i see what you mean now. There is a small change in the initial width of whatever that longer 'pulse' is before the second half of the pattern though, so that may have something to do with it, but i dont see why that initial width is lower amplitude. What are you using to detect these pulses?

There may be more to the pattern than shown in the pics you posted too. There might be some other change in the pattern itself as the button is depressed that you didnt notice yet, such as a repeat of part of the data with a small change in pattern or something like that. One pattern i found had both the data and the inverted data being sent (shown in pic).
I also noticed we can not see the bottom of the patterns you posted, is that because the bottom was too bright?
Perhaps you can try posting a pic of more pulses for two of the codes that look the same right now.

I suppose they could be using a more exact technique of measuring the pulse widths too, but that's not like any of the patterns i have encountered so far with my own devices. They seem to not want to be too exact or else the measurements get harder to make. Maybe they are using a phase locked loop technique which means slight changes might be detected.

Here's a pic of some of the codes i found using the scope, but i not sure if it will help you here or not...
 

Attachments

  • RemoteCodes.gif
    RemoteCodes.gif
    18.2 KB · Views: 790
Last edited:
I've done what you are describing with an older remote control for my tv and it worked fine. With the previous remote, the timing for a low or a high were the same, it was just a matter of reading the sequence. With this protocol, it looks like minute changes in the timing between the pulses may be resulting in a different signal being sent. So a 1 or a mark isn't necessarily 60ms and a 0 or a gap isn't necessarily 120ms indicating consistent times for each state. from the picture, several of the signals look the same, but on the scope i can see small differences in the gaps between the pulses.

Pulses are never accurate on IR remotes (or wireless) it's why they use some kind of coding scheme, such as Manchester or SIRC's which ignores small variations.

Like I said, you need to examine the data AFTER demodulation, and compare different key presses.

I first copied a Sharp remote a LONG time ago, using a DOS laptop, which I wrote a simple program for to monitor a pin on the parallel port, and plot the signal as a graph on screen. If I remember correctly?, I used a 16C84, the ony EEPROM based PIC at the time - Windows was either not lanuched yet, or was only Win3.0 or so?.
 
Yes i see what you mean now. There is a small change in the initial width of whatever that longer 'pulse' is before the second half of the pattern though, so that may have something to do with it, but i dont see why that initial width is lower amplitude. What are you using to detect these pulses?
The variation i'm talking about was observed between the last nine pulses, the gap in between the first nine and the last nine is most likely caused by my pasting of images together. I know its probably not overly useful, but i'll try to get a picture of the last nine pulses using a faster sampling rate to see if there is a consistent change in the width. I was using a reversed biased infrared diode to detect the pulses, not the best solution, but its all I had available at the time. We just moved so i haven't found all of my supplies yet.

I was just looking into making a simple logic analyzer to read the de-modulated signal, but I still do not have access to the cable boxes demodulator, so i would have to find an IR receiver module to translate the raw signal into a logical one. I think i have a pic project (16F628a) lying around that I used for some simple RS-232 communication, I might be able to modify that to continuously send the status of a pin to hyperterminal.
 
Last edited:
Hello again,


Nigel, i've never seen a pattern i couldnt detect with the scope. Could this be something special?
From what i can see in his pic's, it looks like those 'pulses' are actually bursts right? That's what i saw with my remotes (see pic attached previously)

I just thought of another possible answer for the codes that look the same...
They may send out a different code temporarily for each key, like (simple examples here) 0000 for the zero key, but then follow it with the 'repeat' data which may be different for several keys but not all.

For simple example key codes for key 0 and key 1:
0000 1010 1010 1010 1010 1010 1010 1010 1010 (note 0000 only once followed by the repeat code for 0000)
0001 1010 1010 1010 1010 1010 1010 1010 1010 (note 0001 only once followed by the same repeat code which is shared between 0000 and 0001).

and for keys 2 and 3:
0010 1011 1011 1011 1011 1011 1011 1011 1011 (note 0010 only once)
0011 1011 1011 1011 1011 1011 1011 1011 1011 (note 0011 only once)


Note the actual key code is sent out only once, followed by a 'repeat' code that is shared between some keys. That would make a scope sweep seem to show only the second part (the repeat code) and it would look like two keys have the same code when really it is just a slightly more complex way of sending the data. The device wants to be able to distinguish between single key presses and repeat presses of the same key.

To catch this on the scope you'd have to watch carefully for the first set of pulses, and it may be difficult to catch but with the intensity up it may work. Of course i cant guarantee this is the way they really do it, but it's a possibility.
If not, you'll have to build something as Nigel suggested.
Using an IR detector module might help too as Nigel said. I didnt have any problem detecting bursts though with my remotes though.
Of course there is still the possibility that they use a phase locked loop method, which can detect small changes. I dont see why they would want to get too accurate though, as modern detector modules probably already do that.
 
Last edited:
Hello again,


Nigel, i've never seen a pattern i couldnt detect with the scope. Could this be something special?
From what i can see in his pic's, it looks like those 'pulses' are actually bursts right? That's what i saw with my remotes (see pic attached previously)

Without a storage scope it's difficult to make much sense of the pulses, because of the low repetition rate, and the fact that the first series is sometimes different to the foillowing ones (RC5 for example).

I just thought of another possible answer for the codes that look the same...
They may send out a different code temporarily for each key, like (simple examples here) 0000 for the zero key, but then follow it with the 'repeat' data which may be different for several keys but not all.

For simple example key codes for key 0 and key 1:
0000 1010 1010 1010 1010 1010 1010 1010 1010 (note 0000 only once followed by the repeat code for 0000)
0001 1010 1010 1010 1010 1010 1010 1010 1010 (note 0001 only once followed by the same repeat code which is shared between 0000 and 0001).

and for keys 2 and 3:
0010 1011 1011 1011 1011 1011 1011 1011 1011 (note 0010 only once)
0011 1011 1011 1011 1011 1011 1011 1011 1011 (note 0011 only once)


Note the actual key code is sent out only once, followed by a 'repeat' code that is shared between some keys. That would make a scope sweep seem to show only the second part (the repeat code) and it would look like two keys have the same code when really it is just a slightly more complex way of sending the data. The device wants to be able to distinguish between single key presses and repeat presses of the same key.

It would be unusual for it to be that bad - first job, get a receiver IC so you're looking at the data you'll be actually dealing with, rather than the crude IR pulses.

To catch this on the scope you'd have to watch carefully for the first set of pulses, and it may be difficult to catch but with the intensity up it may work. Of course i cant guarantee this is the way they really do it, but it's a possibility.
If not, you'll have to build something as Nigel suggested.
Using an IR detector module might help too as Nigel said. I didnt have any problem detecting bursts though with my remotes though.
Of course there is still the possibility that they use a phase locked loop method, which can detect small changes. I dont see why they would want to get too accurate though, as modern detector modules probably already do that.

No, that would be FAR too unreliable - the pulses aren't that accurate to start with, and lose a lot more during transport.
 
Well so far, everything i've read about this protocol implies its pretty picky, most learning remotes have a very hard time with it. It is possible that they use repeats in the sequence, although I've heard that the codes i posted previously are the non-repeat version and it still works. Someone was talking about TOADS which i guess are like toggle bits, but again, based on the sequences i posted this may not be the case, unless one of those hex characters is interpreted as a toggle bit by the remotes software. I was hoping to avoid building any new hardware for this but i suppose thats my next step. I may set up a sound card o-scope and hook an ir-receiver module to it and see what i can pull out. I did take one more picture, this one uses a slightly higher sampling rate and compares the last 9 pulses of buttons three and four. I don't know if this slight shift is significant, but it seems to be consistent.
**broken link removed**
 
Bear in mind that schemes like Manchester use the transistions from low to high, and high to low, nothing to do with any pules widths at all.

There's numerous ways to do IR remotes.
 
Well so far, everything i've read about this protocol implies its pretty picky, most learning remotes have a very hard time with it. It is possible that they use repeats in the sequence, although I've heard that the codes i posted previously are the non-repeat version and it still works. Someone was talking about TOADS which i guess are like toggle bits, but again, based on the sequences i posted this may not be the case, unless one of those hex characters is interpreted as a toggle bit by the remotes software. I was hoping to avoid building any new hardware for this but i suppose thats my next step. I may set up a sound card o-scope and hook an ir-receiver module to it and see what i can pull out. I did take one more picture, this one uses a slightly higher sampling rate and compares the last 9 pulses of buttons three and four. I don't know if this slight shift is significant, but it seems to be consistent.
**broken link removed**


Hi again,


Beer in mind (he he) that as Nigel says there are lots of ways to do a protocol, but if i had this exact remote and saw what you are seeing and asked a lot of people about it and no one had the answer, the next thing i would do is this:

Examine the scope pics once again and try to determine what is actually happening, are they bursts? I would try to get the frequency of the bursts, then as proof that i understood the code i would write a quick uC program with both codes (the ones that seem the same but are slightly different) and see if i could get the device to respond as i change the code pulses slightly as in the scope pics. If those slight changes are truely what is the difference in codes (and a good phase locked loop system could easily detect that kind of change) then i would eventually be able to get the device to respond to both similar but different codes. The proof there is in the doing, or rather in the experimenting a bit and trying different things.
I have done one shots with cheap scopes before though, it works, but you have to be very observant so that when that first pulse train appears, you see it. Keep in mind also that you can push the button, release it, push it again, as many times as you want and try to observe that very first set of pulses and see if they are much different than the ones that repeat later.

Eventually you are either going to have to get better information or better scope views or do some experimenting if you intend to solve this. The IR detector module will probably help clear up the data a bit, but i think you'll still have to get the carrier or else you wont know which detector to purchase.
Worst case if you can part with the remote for a week or two send it to me and i'll look at the pulses and see what it takes to do this. That's the best i can offer right now.
 
I'll see what else I can turn up. I've put a pic of the remote i'm working with (bottom left) and the fancier one they sent out as well (bottom right) but from what i've seen comcast is using the same protocol for the following box's. It looks like the remotes are universal and the receivers are setting the protocol. I know the Pace DC50X, Thomson DCI1011, and DCI105 and the cisco RNG110 & RNG200 are all using this protocol. I have the Pace the DCI105 and the RNG110 all of which can be controlled with the same remote. Well i pulled apart a VCR so i'll try to turn my sound card into a scope to see if that reveals any more info. might get lucky if the carrier frequencies match.

**broken link removed****broken link removed**
 
Alright, so to get a better idea of what was going on, I set up a sound card oscilloscope. From what I can see, the difference between the patterns is a small variation in the spacing between the highs. In addition, there also seems to be a toggle bit, the third bit out of the second set of 9 pulses shifts after an initial period of time. The first image below shows the full pattern being send for the 1 button. The red pattern is the initial pattern sent, the green pattern is the stable pattern after the third bit shifts. The direction of the shift may not be the same for each button from what i've seen.
**broken link removed**
This picture shows just the last nine pulses for buttons 1 through 4. Again the red pattern is the initial pattern, the green is the pattern after the shift. The variation is much more obvious is the pattern of 1 and 4 are compared.
**broken link removed**
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top