JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

Infrared Signals for Beginners
Goto page 1, 2  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Protocol Decodes
View previous topic :: View next topic  
Author Message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 6946
Location: Florida

PostPosted: Fri Jul 31, 2009 3:12 pm    Post subject: Infrared Signals for Beginners Reply with quote

I have just learned how to do protocol decodes. Its been a long struggle for me. I didn't have a technical background and women's intuition didn't work in this process. While its all new, I decided to document some of the basic concepts so that other people who don't have a technical background won't have to struggle like I did to understand the concepts that you need to master before you can actually do a decode.


Infrared Signals for Beginners

I'd like a protocol expert to read this to make sure I'm not passing along bad information.


Last edited by vickyg2003 on Wed Jul 13, 2011 9:16 am; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
johnsfine
Site Admin


Joined: 10 Aug 2003
Posts: 4767
Location: Bedford, MA

PostPosted: Fri Jul 31, 2009 4:10 pm    Post subject: Reply with quote

Looks good. Only very minor comments.

Minor typos or missing words may be extra confusing when the topic is confusing
Code:
Timings need to rounded

Code:
Any Lead-in Pairs, and Lead-out pairs and mid-frame bursts you found

Code:
If protocols use the pulse width method, each bit will start with a pulse, followed by a

Code:
a pulse defined by a silence,

Code:
when working with raw timings you might from IR

Code:
often used in forumas.


Minor technical nit pick:
Code:
Differences that small are insignificant

Actually: Differences that small are insignificant in most IR protocols.
Code:
A determination needs to be made as to whether the bumps on our line can be interpreted with a pulse width method, or if
they are phase encoded.

There are several other less common encoding systems. Not everything is pulse width or phase.
Code:
)*) part in the inner parenthesis keeps repeating

Also the * means it repeats zero or more times, where + would mean one or more times. So for a very short button press the part in inner () might be skipped entirely.

It is a bit of a leap where you just say
Code:
In IRP Notation this could be written as
without adding something like: meaning each 0 bit is represented by durations 550,-550 and each 1 bit by 550,-1650. I know you explain that much later, I'm not good at getting technical info in a good sequence myself (example, this random sequence set of comments) but that one would put readers off.


I also found the side track into duty cycle a bit confusing especially in a section titled "frequency".
Back to top
View user's profile Send private message Send e-mail Visit poster's website
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 6946
Location: Florida

PostPosted: Fri Jul 31, 2009 7:38 pm    Post subject: Reply with quote

John, thank you for the expertise.

I'm making changes but I think I have a major flaw in my thinking.

Which comes first in the < > , the zero or the one.
Back to top
View user's profile Send private message Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 2843
Location: Cambridge, UK

PostPosted: Sat Aug 01, 2009 3:28 am    Post subject: Reply with quote

The zero comes first. Count from the left. If there are four, eg the Sejin, which effectively is <1,-3|-1,1,-2|-2,1,-1|-3,1> then they code 0,1,2,3 in that order, as bit pairs, ie if msb then 00,01,10,11. In the final form of Sejin this has been written as <-1|1><8:4|4:4|2:4|1:4>, where you see both in action. The 2:4, for example, in msb is 0010, which codes as -1,-1,1,-1 in the outer encoding, and adding up adjacent gaps this gives -2,1,-1. This encodes 10 in the data that follows.

I'm pretty sure this is right, but I have a question for John as to what would happen if it were lsb. Suppose the Sejin IRP had begun

{38.8k,310}<-1|1><8:4|4:4|2:4|1:4>

ie implicitly lsb. The 2:4 would be 0100, giving -1,1,-2 in the outer encoding. But in the inner encoding, would this code bit pair 01 or 10, ie 2 in lsb or msb form? I would guess it is the lsb form 01, but I would like to be sure.
_____________
Graham
Back to top
View user's profile Send private message
johnsfine
Site Admin


Joined: 10 Aug 2003
Posts: 4767
Location: Bedford, MA

PostPosted: Sat Aug 01, 2009 7:03 am    Post subject: Reply with quote

Most serial communication between computers is LSB. Most IR protocols are LSB. X86 and some earlier important computer architectures are LSB. So I'm used to thinking about binary data in computers in LSB form.

I know it seems to be backwards to people who aren't used to it.

Also remember that inside the electronics there is no left or right. A sequence of bits has a beginning side and an ending side. It has a high order side and a low order side. It has no left side nor right side.

In English, we are used to reading left to right, so we think there is something fundamental about the left being the beginning and the right being the end in a sequence of bits. But that is arbitrary. We are also used to a numbering system in which high order is on the left. That is also arbitrary.

So I can't write any bit sequences in documentation without triggering all those false associations to left and right.

mathdon wrote:
if msb then 00,01,10,11. In the final form of Sejin this has been written as <-1|1><8:4|4:4|2:4|1:4>, where you see both in action. The 2:4, for example, in msb is 0010, which codes as -1,-1,1,-1 in the outer encoding, and adding up adjacent gaps this gives -2,1,-1. This encodes 10 in the data that follows.


I didn't follow all that and this msb stuff (multiple levels of backwards) tends to confuse me. But I think it works the way you would expect.

Quote:
I have a question for John as to what would happen if it were lsb. Suppose the Sejin IRP had begun

{38.8k,310}<-1|1><8:4|4:4|2:4|1:4>

ie implicitly lsb. The 2:4 would be 0100, giving -1,1,-2 in the outer encoding. But in the inner encoding, would this code bit pair 01 or 10, ie 2 in lsb or msb form? I would guess it is the lsb form 01, but I would like to be sure.


Again, I can't be sure I follow what you said. But LSB is very consistent. Remembering that there is no left nor right and that the computer itself naturally works with least significant bits first, everything stays in least significant first sequence through the whole process.

When you define 2:4 (from the outer definition) to be 2 of the inner definition, the 2:4 is of course least significant first so what you would write as 0010 would be transmitted with the 0 first and 1 second, etc.

Then the pairs of bits would be taken in lsb sequence from the actual value to be encoded, so if the actual value was 14:4, what you would write as 1110 we would take first the 0 and second the 1. Since we are consistently LSB, two bits first 0, second 1 combine to a value of 2. That selects the 2:4 from the inner encoding and sends the -1,1,-2.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 6946
Location: Florida

PostPosted: Sat Aug 01, 2009 9:54 am    Post subject: Reply with quote

Quote:

Vicky wrote:
Which comes first in the < > , the zero or the one.


Quote:

Graham wrote:
The zero comes first.


Quote:

John wrote:
Also remember that inside the electronics there is no left or right.


I'm presuming that John's comment was not a correction of Graham's statement, but rather an expansion of Graham's explanation, so I'm going to un-complement my documentation.

It would seem that these are ordered by value, rather than alphabetical, doh! Rolling Eyes



Quote:

John wrote:
There are several other less common encoding systems. Not everything is pulse width or phase.


OMG! I'll bet the G.I. Cable uses one of those less common encoding systems!!!! The last time my curiosity about protocols flared, I was going to use see if IRScope could help me understand. I fired up IRScope, but thought it was not going to help me because since the you had to look at so many screens to get up enough bumps to describe data. I was actually seeing frames!!!!! DOH!

What would that kind of does the G.I. Protocol use?

What other protocols encoding methods does DecodeIR recognize?

And if possible, could you give me some protocol names that might use different encoding methods so I could examine them to improve my understanding.

I've updated the document with the suggested corrections.
Back to top
View user's profile Send private message Visit poster's website
johnsfine
Site Admin


Joined: 10 Aug 2003
Posts: 4767
Location: Bedford, MA

PostPosted: Sat Aug 01, 2009 4:05 pm    Post subject: Reply with quote

vickyg2003 wrote:
What would that kind of does the G.I. Protocol use?


An ordinary pulse width. Strange repeat frame, but otherwise very ordinary:
{38.7k,490}<1,-4.5|1,-9>(18,-9,F:8,D:4,C:4,1,-84,(18,-4.5,1,-178)*)
C= -(D + F:4 + F:4:4)

Notice the <1,-4.5|1,-9> is very simple and common. The total of pulse and following gap is short for '0' and long for '1'

Quote:
What other protocols encoding methods does DecodeIR recognize?


There is the kind of reverse of typical, such as Sony
{40k,600}<1,-1|3,-1>
The total of pulse and following gap is still short for '0' and long for '1' but the one that varies has changed.

You know about phase encoded such as RC5
<1,-1|-1,1>

There are some raw encodings
<-1|1>
(for the actual bit stream, rather than just for some layered definition as mathdon just demonstrated). I don't have any examples handy. I notice PCTV is listed in my documentation as
<0,-1|1,-0>
That's how raw would be represented in a UEI executor, but I didn't intend to write raw that way in irp notation. I don't recall PCTV protocol and don't know what I was thinking when I documented it that way.

There is <1,-3|3,-1> used in F12, GXB and some other protocols, where the size of a bit is fixed and the ratio of pulse to gap carries the data.

There are a number of layered systems (where some simpler bit encoding is used to encode the actual bit encoding)

There are more complicated ones, such as Grundig16
<-4,2|-3,1,-1,1|-2,1,-2,1|-1,1,-3,1>
That might be considered a layered system that I didn't represent as such. Mainly it is a system in which there is a fixed duration per pair of bits without the inefficiency of simpler fixed duration systems (such as F12, GXB). In a lot of communication systems, fixed duration per small set of bits is an important design goal. In IR it may be tricky or inefficient to accomplish. Note how the simplest pulse plus gap width designs have different bit rates depending on content.

Some systems were clearly designed by people who don't understand the factors that distort or confuse IR receivers, so they looked at the apparent inefficiency of typical systems and changed things they didn't understand, getting complex but unreliable protocols such as Russound
<1,-1|1,-2|2,-1|2,-2>
Back to top
View user's profile Send private message Send e-mail Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18101
Location: Chicago, IL

PostPosted: Sat Aug 01, 2009 11:20 pm    Post subject: Reply with quote

Repeating
Some protocols have a "break" frame, so on occassion it's necessary to use a different technique where you release the button BEFORE the learning process has completed, in order to capture the last frame.

Rounding
I would suggest giving an example. Picking a good rounding number will vary based on the data on hand, but in the case of an NEC signal, 550 would be a good number to round to. Sometimes a smaller number is better (eg, 10 or 100). The idea is to get all timings that basically represent the same time, to get rounded to the same value. In this case, if some times where 538 and others were 578, rounding to 100 would not be ideal because they'd round to 500 and 600 respectively.

Frequency
Pioneer is 40kHz, NEC is 38kHz. So you can improve the "I've been told" statement with the actual data.

Duty Cycle
As your guide is designed to help someone use PB, you should go a step further and recommend a setting for Duty Cycle. Unless you have a good reason to do otherwise, you can always just set it to 33%. Setting it to a higher value (like 50%) may produce a stronger signal but will also run the batteries down quicker. I think I recall reading that values above 50% serve no purpose, but I'm not positive on this. John may know more.

Mid Frame Burst
A mid-frame burst is a burst pair that is not either the ONE pair or the ZERO pair and it appears somewhere in the middle of the data string. There are 2 types of mid-frame burst pairs supported by UEI's IR engine, but IIRC only one of them is supported by PB. The versions supported by the engine can't use just any values, but I don't recall the rules. It's something like, the One-On and the leadin-off, or something like that. If anyone remembers more, maybe they can post it and you can document it.

Pulse Width Timing Pairs
It might be better to use the correct pairings in the NEC example that you use. In other words...

1 = 550,-1650
0 = 550,-550

It's a very good practice to assume that the pair with the longer OFF time is the ONE pair, because most of the time it's true, but there are exceptions of course.

Bi-Phase
I found the bi-phase description a bit confusing, but I don't have a better suggestion right now. However, you should point out how easy IR.exe makes it to check for bi-phase using the Bi-Phase drop down. I can fill you in on that later if you don't know about it yourself.

IRP
Excellent stuff, we've been needing something like this for a LONG time.

--------------------------------
Hope that helps,
Rob
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 2843
Location: Cambridge, UK

PostPosted: Sun Aug 02, 2009 3:25 am    Post subject: Reply with quote

johnsfine wrote:
When you define 2:4 (from the outer definition) to be 2 of the inner definition

Light has finally dawned! I really did ask a meaningless question. I was happy with

{38.8k,310}<-1|1><8:4|4:4|2:4|1:4>

converting to

{38.8k,310}<-3,1|-2,1,-1|-1,1,-2><1,-3>

since the 8:4 etc is sent in lsb form. My question was what comes next, do the four "bursts" encode 00,01,10,11 or 00,10,01,11. The answer is NEITHER! They encode 0,1,2,3, with msb versus lsb being entirely irrelevant, as John's "2 of the inner definition" suddenly made clear.

When we come to send a numeric value, we write it not in base-2 (binary) form but in base-4 (which may have a name, but I don't know it). So in John's example, 14:4 is two base-4 digits, 32 (ie 2 + 3*4). As we are sending lsb we send the right-most digit first, ie the 2, which is the pulse train -1,1,-2.

I don't know if this helps anyone else. It helps me, but I'm a mathematician!

As an aside, lsb really is the logical way to send numbers. Suppose someone is reading out a list of numbers, digit by digit, for you to add up. You want to write them, neatly aligned, underneath one another ready for adding. Here we go. The numbers are twelve and one hundred and forty seven. Twelve is read as "1,2,end", so you write 12. You then hear the initial 1 of one hundred and forty seven. Where do you write it? You don't know, not until the number is finished and you know how many digits there are. But if they were read in lsb order, twelve is read as "2,1,end". You write 12. Then you hear "7,4,1,end", you know the 7 goes under the 2, the 4 under the 1 and finally the 1 to the left of them. Much neater!
______________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 2843
Location: Cambridge, UK

PostPosted: Sun Aug 02, 2009 11:03 am    Post subject: Reply with quote

The Robman wrote:
Mid Frame Burst
A mid-frame burst is a burst pair that is not either the ONE pair or the ZERO pair and it appears somewhere in the middle of the data string. There are 2 types of mid-frame burst pairs supported by UEI's IR engine, but IIRC only one of them is supported by PB. The versions supported by the engine can't use just any values, but I don't recall the rules. It's something like, the One-On and the leadin-off, or something like that. If anyone remembers more, maybe they can post it and you can document it.

My notes from my study of the IR engine in the URC-7781 say that it supports a mid-frame burst with an ON time equal to that of a 1 burst and an OFF time equal to that of a lead-in burst, which agrees with what Rob said. This mid-frame burst is sent after a certain number of data bits, that number being determined by the protocol. I didn't see a second type of mid-frame burst, but that doesn't mean it isn't there. I understood a lot less about protocols when I wrote those.
______________
Graham
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18101
Location: Chicago, IL

PostPosted: Sun Aug 02, 2009 1:32 pm    Post subject: Reply with quote

The 2nd type is invoked by calling a different vector address than the one you normally use. IIRC, it's used in the Proton executor.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 2843
Location: Cambridge, UK

PostPosted: Sun Aug 02, 2009 4:55 pm    Post subject: Reply with quote

The one I described is invoked by calling a different vector address (in the URC-7781, at least), which is why there is no flexibility in the timings. If the other one comes from the normal vector address, that is the one I am missing.
____________
Graham
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18101
Location: Chicago, IL

PostPosted: Sun Aug 02, 2009 8:54 pm    Post subject: Reply with quote

I'll find it and report back.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 6946
Location: Florida

PostPosted: Sun Aug 02, 2009 9:59 pm    Post subject: Reply with quote

John, thanks for giving me a study list.

Rob and Graham, I've updated the midframe burst are with a picture and added this text from what you two discussed.


Quote:
A mid-frame burst is a timing pair that is not either the ONE pair or the ZERO pair and it appears somewhere in the middle of the data string. There are 2 types of mid-frame burst pairs supported by UEI's IR engine, but only a mid-frame burst with a one-on-pulse followed by the silence that is equal to the lead-in silence, like the one above, can be created in protocol builder without assembly language modifications


hmm on second thought that makes it sound like its impossible, I'm going to change that last part to say "without additional assembly code".
Back to top
View user's profile Send private message Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18101
Location: Chicago, IL

PostPosted: Mon Aug 03, 2009 9:53 am    Post subject: Reply with quote

mathdon wrote:
The one I described is invoked by calling a different vector address (in the URC-7781, at least), which is why there is no flexibility in the timings. If the other one comes from the normal vector address, that is the one I am missing.

I had thought I remembered that the mid-frame style used in the Proton protocol was the one that PB didn't support but got confused when I tried setting up a mid-frame in PB and it did indeed generate code that used the $0161 vector address. So, I did some searching to see if I could find some info on this and I found this old post by Mike which seems to imply that PB doesn't use the $0161 vector address. Next, I fired up an old version of PB and sure enough, if you select mid-frame, it uses the $0146 vector address, so PB has changed from supporting one type of mid-frame to supporting the other type, but it still only supports one type.

I'm pretty sure that if you were to change the $0161 vector address in the generated code to $0146 you will get a mid-frame burst that uses different timings.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Protocol Decodes All times are GMT - 5 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Get Smart! the band's official homepage Rockabilly Central