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

IRP Specification
Goto page Previous  1, 2, 3, 4  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - General Forum
View previous topic :: View next topic  
Author Message
mathdon
Expert


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

                    
PostPosted: Mon Mar 26, 2012 2:12 pm    Post subject: Reply with quote

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.
_________________
Graham
Back to top
View user's profile Send private message
hengin



Joined: 22 Mar 2012
Posts: 3

                    
PostPosted: Mon Mar 26, 2012 3:51 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Mon Mar 26, 2012 4:47 pm    Post subject: Reply with quote

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/viewtopic.php?t=13396&start=11 and my response 3 postings later Wink ) I have several times expressed interest in somehow "syncing" IrpProtocols.ini, DecodeIR.html and the DecodeIR sources, but this has not received any response Confused .

Quote:
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.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Tue Mar 27, 2012 12:34 pm    Post subject: Reply with quote

hengin wrote:

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.
Back to top
View user's profile Send private message
hengin



Joined: 22 Mar 2012
Posts: 3

                    
PostPosted: Wed Mar 28, 2012 3:12 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Wed Mar 28, 2012 10:14 am    Post subject: Reply with quote

Yes, I agree that it wouldn't be reversible.
Back to top
View user's profile Send private message
quietdragon



Joined: 16 Mar 2013
Posts: 8

                    
PostPosted: Sat Mar 16, 2013 11:39 am    Post subject: Bitfield semantics Reply with quote

I am working through an implementation of an IRP parser and following the details in http://www.hifi-remote.com/wiki/index.php?title=IRP_Notation#Semantics_4

I have a couple of questions. To begin:
Quote:

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 ?
Back to top
View user's profile Send private message
quietdragon



Joined: 16 Mar 2013
Posts: 8

                    
PostPosted: Sat Mar 16, 2013 12:05 pm    Post subject: Reply with quote

The IRP Execution Model says:
Code:

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 ?
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Sat Mar 16, 2013 12:06 pm    Post subject: Reply with quote

Consider the Zenith protocol:
Code:
{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:
{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.
Back to top
View user's profile Send private message
quietdragon



Joined: 16 Mar 2013
Posts: 8

                    
PostPosted: Sat Mar 16, 2013 12:26 pm    Post subject: Reply with quote

3FG wrote:
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 ?
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Sat Mar 16, 2013 2:30 pm    Post subject: Reply with quote

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:
<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.
Back to top
View user's profile Send private message
quietdragon



Joined: 16 Mar 2013
Posts: 8

                    
PostPosted: Sat Mar 16, 2013 4:50 pm    Post subject: Reply with quote

3FG wrote:
0 would mean zero bits.

Oh. Thanks. I had it backwards.

What about in expression contexts ?

For example:
Code:

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

In this case, A=8. What is the expectation for the value of B ?
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Sun Mar 17, 2013 4:46 am    Post subject: Reply with quote

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
Quote:
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:
$ 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:
$ 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.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Sun Mar 17, 2013 5:29 am    Post subject: Reply with quote

3FG wrote:

For example, Sony 12 and Sony 20 could be expressed as a single IR protocol
Code:
{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:
[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]
Back to top
View user's profile Send private message Send e-mail Visit poster's website
quietdragon



Joined: 16 Mar 2013
Posts: 8

                    
PostPosted: Sun Mar 17, 2013 10:37 am    Post subject: Binary forms of bitfields with unspecified lengths Reply with quote

In http://www.hifi-remote.com/wiki/index.php?title=IRP_Notation#Data_Structures
Quote:
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:
<-1,1|1,-1>(-16::0)


I could not figure out from the document what this should mean, and any advice would be appreciated.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - General Forum All times are GMT - 5 Hours
Goto page Previous  1, 2, 3, 4  Next
Page 3 of 4

 
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
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control