IRP Specification

[mathdon]

I too do not think I can give an authoritative answer, but for what it is worth, I agree with Barf that a notation does not hold a copyright. However, in so far as there are any Intellectual Property Rights attached to IRP notation, they belong to John Fine who originated the notation and it would be best if he could comment on its use for commercial purposes.

I can, however, answer for the IRP Specification document as I was its author. I am happy for that to be copied, reproduced, quoted from, etc. with the usual proviso that I would expect to be acknowledged as its author.

[hengin]

Hi Barf

1. Sounds good to me. I'll wait for John to comment or later try to contact him.

2. I just happend to pick a bad example. I guess the IRP notation for XMP is erroneous. The correct notation for XMP would be:

{38k,136,msb}<210u,-760u>(<0:1|0:1,-1|0:1,-2|0:1,-3|0...

then it would conform to the specification.

3. I'm not looking for the modulo expression. If A=0xA5 is to be sent over a B&O protocol (MSB) this is not sent binary as 1 0 1 0 0 1 0 1, but rather as TRINARY 1 0 1 0 2 1 0 1. Each bit then needs to be expanded to two bits and set to 2 if it is "the SAME as last bit" in the binary sequence. Therefore I would like to expand A=0xA5 to A1=0x4491 and then use a bitspec something like <210u,-1|210u,-3|210u,-2>. http://www.hifi-remote.com/forums/viewtopic.php?t=12486

4. Nice work you have done. I will look into it.

Actually I've already made a proprietary notation and successfully managed to implement the most common protocols (RC5, RC6, NEC...) but when I hit the XMP protocol. I thought somebody else must have made this before me, and I'm happy I found this IRP notation with so many protocols already defined. Unfortunately there are errors in DecodeIR.html, like the one I found in XMP. Is DecodeIR.html the only source for IRP notated protocols? You got the XMP wrong in IrMaster as well, I guess you used DecodeIR.html as source?

[Barf]

IrpMaster (and thus IrMaster) uses its own "brain file" IrpProtocols.ini, in which a number of errors in DecodeIR.html have been fixed. (For some amusement, see http://www.hifi-remote.com/forums/viewt ... 6&start=11 and my response 3 postings later ) I have several times expressed interest in somehow "syncing" IrpProtocols.ini, DecodeIR.html and the DecodeIR sources, but this has not received any response .

You got the XMP wrong in IrMaster as well

I will be happy to evaluate your proof of that statement. IrpMaster agrees with DecodeIR, at least for "most" parameter values.

[3FG]

3. I'm not looking for the modulo expression. If A=0xA5 is to be sent over a B&O protocol (MSB) this is not sent binary as 1 0 1 0 0 1 0 1, but rather as TRINARY 1 0 1 0 2 1 0 1. Each bit then needs to be expanded to two bits and set to 2 if it is "the SAME as last bit" in the binary sequence. Therefore I would like to expand A=0xA5 to A1=0x4491 and then use a bitspec something like <210u,-1|210u,-3|210u,-2>. http://www.hifi-remote.com/forums/viewtopic.php?t=12486

One way is to define a base 2 system <210u,-1|210u,-3|210u,-2|210u|-2>. Note that in this spec, 3 has the same durations as 2. Use the following operations using 0x5A as an example:

01011010 OBC 0x5A
00101101 rotate right 1 bit
01110111 XOR OBC with rotated value
10001000 complement
x0002000 expand to base 2 and multiply by 2, with most significant digit ignored, if it is the first digit in the IR signal.
01011010 the OBC 0x5A expanded to base 2
01013010 summed, retaining the most significant digit from the expanded OBC, if it is the first digit in the IR signal.

I believe that this is all writable in IRP.

[hengin]

Hi 3FG

I would like to both encode and decode ir raw data with the IRP notation, the expression has to go both ways and since there is a XOR included I believe it's a one way solution?

As I can't find an easy solution for this I've decided to keep this conversion out of the IRP notation and simply pass data with "same as last bit" information already included.

[3FG]

Yes, I agree that it wouldn't be reversible.

[quietdragon]

I am working through an implementation of an IRP parser and following the details in http://www.hifi-remote.com/wiki/index.p ... emantics_4

I have a couple of questions. To begin:

If either b or c is negative then the bitfield is invalid. In the execution process, a bitfield is a translation object that translates the value a to a binary form.

Is it intentional to support b == zero ?

If so, is there a definition of the value of an empty binary form ?

[quietdragon]

The IRP Execution Model says:

Code: Select all

ELSE IF irstream item IS bitfield THEN

    EVALUATE bitfield AS binary form; 
    IF current bitspec IS NULL THEN

        ERROR; 

    ELSE

        PUSH binary form INTO buffer OF current bitspec; 

    END IF; 

What is the correct interpretation for a bitfield with a negative value, for example (-12)::0 ?

How many bits are pushed into the the bitspec buffer for the binary form of this bitfield ?

[3FG]

Consider the Zenith protocol:

Code: Select all

{40k,520,msb}<1,-10|1,-1,1,-8>(S:1,<1:2|2:2>(F:D),-90m)+ 

which specifies an IR signal with a variable number of bits. Setting b = 0 allows one plausible usage of a variable number of bits.

For example, Sony 12 and Sony 20 could be expressed as a single IR protocol

Code: Select all

{40k,600}<1,-1|2,-1>(4,-1,F:7,D:5,S:X,^45m)+  [X=0,8] 

I think this way of defining the Zenith protocol was a mistake, and we should have defined separate protocols, as was done for Sony. But I don't see a good reason to exclude b==0.

[quietdragon]

But I don't see a good reason to exclude b==0.

Thanks for clarifying. Zero means variable number of bits.

I don't think I see that anywhere in the IRP Notation Specification.

This still leaves me with my other question regarding, it appears, either (-12)::0 or even 12::0. Since the width of the bit field is not specified, and the interpretation is "variable number of bits", how many bits get pushed into the buffer ?

[3FG]

No, 0 doesn't mean a variable number of bits. 0 would mean zero bits. Remember that each element of a bitfield can be name, which must evaluate to a non-negative integer. The Zenith IR protocol is an example in which the second element of a bitfield is a name:

Code: Select all

<1:2|2:2>(F:D)

The second element of F:D is "D". For Zenith, D takes on values of either 6 or 7.

I gave a plausible example for Sony 12 and 20, which could be combined into a single IRP where X could take on values of either 0 or 8. That's one rationale for allowing 0 as the second element in a bit field.

[quietdragon]

0 would mean zero bits.

Oh. Thanks. I had it backwards.

What about in expression contexts ?

For example:

Code: Select all

A=(12:3)
B=(12:0)

In this case, A=8. What is the expectation for the value of B ?

[Barf]

Having the width as expression and not constant is definitely a good thing!


The IRP specification is not really explicit, but with some reasonable interpretation says that zero with is valid and will translate to the zero length bit sequence, having the expression value 0. (The value is (for a nonnegative number) a weighted sum of powers of 2, the sum being over 0 terms in our case) So

What is the expectation for the value of B ?

0

Unfortunately, I discovered that IrpMaster does not handle the width zero case correctly -- it is handled as with empty width. Also negative values for width and skip are not rejected as they should. Although hardly of practical importance, this will be fixed in the next release. (Actually, already fixed in my current sources -- if anyone needs it, let me know.)

Finally, there is an undocumented feature in IrpMaster that allows the computation of bitfields from the command line, namely the main routine in /usr/local/irmaster/lib/IrpMaster.jar the BitField class. On Unix-like systems (Linux, Mac, etc) it goes like

Code: Select all

$ java -classpath /usr/local/irmaster/lib/IrpMaster.jar  org.harctoolbox.IrpMaster.BitField    D:-6:2 D=244
244:-6:2 int=47 string=101111

Explanation: /usr/local/irmaster/lib/IrpMaster.jar is the (absolute or relative) path to IrpMaster.jar. The first argument, here D:-6:2, is the bitfield to be evaluated (no spaces should be used), then assignments separated by spaces. The assignments should not contain spaces. The right hand side of an assignment is not evaluated, and may thus only contain a nonnegative integer, unless the assigment is inclosed in braces, in which case the evaluation engine is invoked. This is also necessary for entering negative numbers. Example:

Code: Select all

$ java -classpath /usr/local/irmaster/lib/IrpMaster.jar  org.harctoolbox.IrpMaster.BitField    D:-6:2 {D=-244}  
-244:-6:2 int=48 string=110000

BTW, I do not consider the "IRP Execution model" to be a useful document, and IrpMaster does not use it nor claim to conform with it.

[Barf]

For example, Sony 12 and Sony 20 could be expressed as a single IR protocol

Code: Select all

{40k,600}<1,-1|2,-1>(4,-1,F:7,D:5,S:X,^45m)+  [X=0,8] 

Possibly better, using the inheritance mechanism of IrpMaster:

Code: Select all

[protocol]
name=SonyX
irp={40k,600}<1,-1|2,-1>(4,-1,F:7,D:5,S:(width-12),^45m)+

[protocol]
name=Sony20
irp=SonyX{width=20}[D:0..31,S:0..255,F:0..127]

[protocol]
name=Sony12
irp=SonyX{width=12,S=0}[D:0..31,F:0..127]

[quietdragon]

In http://www.hifi-remote.com/wiki/index.p ... Structures

A bitfield evaluates to a binary form, an integer value expressed in binary notation with a fixed finite or infinite bit length in which negative integers are expressed in 1's complement notation.

The document says that any value conceptually has an infinite number of ones, or an infinite number of zeros, that precede its most significant written digits.

So in the case of a -ve number, I'm wondering what the following should mean:

Code: Select all

<-1,1|1,-1>(-16::0)

I could not figure out from the document what this should mean, and any advice would be appreciated.