IR data stream

[evandude]

I'm totally fishing here, but I just thought I'd ask anyway.

I have no idea HOW or WHY, but the IR reciever I was using (which is just a microcontroller that interprets the data from the remote and outputs serial) decided to switch from 2400 baud to 1200 baud. Yeah, I used it for weeks and everything was fine and then it stopped working and I brought it inside and it is now outputting at 1200 baud.

Anyway, I want to just replace the whole thing (it's out of a commercial IR reciever, i just took the whole board out and it's way too big for what simple purpose it serves) with an 8-pin PIC.

So, now I have to interpret the data stream coming from the IR reciever element itself. Attached is the data stream for one button press. I need to sit down and try to sort out any patterns in the packet (ie- assuming 8-bit data bytes, figure out what parts are data, and what parts are start and stop bits for each byte, etc...) so I can figure out the data encoding scheme... but anyway, finally to the point, I just thought I'd post this up here in case anyone recognized the data structuring (perhaps it's used in other remote controls?) and could point me in the right direction before I spend lots of time frustrated.

If all else fails, I can just have the PIC read the entire data packet, with the proper bit timing, and pretend the whole thing is one big long string of data. Obviously that isn't very memory-efficient, so i'd rather try to find a "decoder ring" for it instead, so I can get just the useful data from it.

oh, and if it makes any difference, the display is 10mS/div (5mS *2 because it's zoomed out)... the first big low section is 9mS long, and the bit timing seems to be 1.1 or 1.2 mS.

Thanks

 

[samcheetah]

Nigel's IR tutorial might help you



and by the way, which model of bitscope are you using

 

[Nigel Goodwin]

What make of remote control is it?, they are a great many different schemes used, the most popular one is the Philips RC5.

 

[evandude]

The remote is a Creative Labs, for a PC, one of the little slim credit-card-sized ones.

**broken link removed**

The bitscope is a BS310U. I like it but I'm REAAAAAALLY hoping they hurry up and improve their software.

Oh, and thank you nigel for the tip. I looked into it and I am not sure whether it's actually RC5, but now that I looked at some RC5 info I realized that it's very likely that the data uses manchester (or other similar) encoding (since during the actual data stream, there is never more than 2 bits in a row high or low) which immediately cuts the amount of actual bits in the data stream by half.

 

[Nigel Goodwin]

For a start I would suggest taking readings of ALL the buttons, and compare them - I've always found it helpful to simply draw them out on graphpaper - this way you can get nice accurate comparisons between the different bits.

 

[williB]

could you post another data packet for comparision

 

[evandude]

Sure thing.

 

[williB]

i didnt see your post nigel :lol:
yes and a different button would be nice..

 

[williB]

i see a pattern of 1 5 5 1 2 2 4 1
as the starting sequence..
at least this is the same in both pics..

 

[evandude]

Here's a couple more, if it helps.

 

[evandude]

Oh, and if someone is seeing these data bytes real intuitively, I'd appreciate if you could perhaps photoshop it or something to point out important features (start and end of each packet, start bits, stop bits, whatever)

But I'm very glad that people can at least pick out some useful data from it, sounds promising for me trying to decode it with a PIC

 

[williB]

now it seems to me that the data starts after the second number two..
not the 1 as priviously posted so the data on the first one is
4 1 2 1 1 1 1 3 3 and the second one is
4 1 3 1 1 1 3 1 2
3 2 1 2 1 1 2 3 2
3 3 1 2 1 2 1 3 1

 

[evandude]

1 5 5 1 2 2 4 1 2 1 1 1 1 3 3

So that would be the total sequence (start bits plus data) for the first one?

what format are you assuming for the data packets? encoding? that sequence doesn't seem nearly long enough to contain all that data unless it were 3-bit packets with just plain NRZ encoding...

I'm trying to corellate the data you are giving me with the actual data stream, so that I can figure out HOW you are getting it, so i can actually get a PIC to do it.

 

[williB]

1 5 5 1 2 2 4 1 2 1 1 1 1 3 3

So that would be the total sequence (start bits plus data) for the first one?

what format are you assuming for the data packets? encoding? that sequence doesn't seem nearly long enough to contain all that data unless it were 3-bit packets with just plain NRZ encoding...

I'm trying to corellate the data you are giving me with the actual data stream, so that I can figure out HOW you are getting it, so i can actually get a PIC to do it.

yes
i think that after the 1 5 5 1 2 2 identifies that you are talking THE reciever and no other ..
obviously i was counting the negetive pulses..
what you have to do is make a graph ( like above) of all the buttons ..
then you can program the pic to pick out the data sequence,and apply it to your circuit..

 

[evandude]

You know, I've spent a lot of time trying to make sense of that scheme with some of the more traditional data encoding algorithms, and now that you say that, I think just counting negative pulses with a timeout to detect the larger spaces would probably work just fine... now i have to try to get a PIC to do it. (the fun part)

 

[evandude]

I looked around some more, and it appears they are using RZ (return-to-zero) encoding. Each bit time is about 1.1 mS (the width between two pulse edges in those groups) and a 1 is represented by a pulse for half that period, and a 0 is represented by no pulse...

The nice thing is, the code to read the RZ data is really a subset of the code to count the pulses in each group, so I can do it either way once I get the code written.

 

[evandude]

FINALLY!

note to self: always disable A/D converters and comparators in a PIC first thing... don't assume microchip was smart enough to leave them disabled by default...

note that the green trace is the "decoded" data stream, and it lags behind by a bit because it doesn't display until after the "bit timer" elapses. but obviously it's working!
also, disregard the green trace after the data... it's set at 10v/div and only a 5v input range, so obviously it's not REALLY jumping up to 10 volts at the end... just a weirdness of the scope...

 

[williB]

thats really cool.
is that a pc scope you have there?

 

[evandude]

yep, bitscope 310U.

I'm rather annoyed with it at times. It can't do full-speed capture of both channels at once. if it's a repetitive signal, it can achieve it by just synching the displays after a few captures, but for one-shot captures you only get one channel.

you can switch it to do simultaneous channels, but it slows it down tremendously (they say its only good to 50kHz in that mode)

now the one saving grace for me is that it has 8-channel digital inputs, which are simultaneous. However, I haven't gotten around to making a buffer board for it yet so I am stuck with analog for now.

but for around $500, I was rather disappointed to not truly get 2 simultaneous analog channels out of it. but I'm withholding my real decision until after I get a chance to play with the digital inputs. Because in all reality, that's what I'll use 90% of the time.

 

[williB]

hmm i see it has a spectrum analyzer function..