JP1 Remotes

[jyll]

Makes sense, now I am certain how to get Device:OBC, so if something doesn't fit is because the table doesn't agree with my universal remote codes.

Did you see my edit about the Phillips BP6 remote? Its config file uses only 3 hex digits. Another uses 2 hex digits.

How could LIRC work with 2, 3, or 4 hex digits for different Phillips remotes? I expected something more standard.

With only 2 hex digits, you only have 8 bits to encode a RC5 bitstream???

Unless they are not all RC5, but only 2 hex digits!!

http://lirc.sourceforge.net/remotes/philips/26PFL5604H

[3FG]

The upgrade section here has a file for the Philips 32PFL5604H/12. It uses the RC6 IR protocol, device 0.

The IRP notation for this is {36k,444,msb}<-1,1|1,-1>(6,-2,1:1,0:3,<-2,2|2,-2>(T:1),D:8,F:8,^107m)+
So there are 8 bits of device data and 8 bits of function data.

The OBCs in the above upgrade file are the complement of the data you have given. So I surmise that the device=0 information is stored somewhere in the header of the LIRC file.

[johnsfine]

[jyll]

All the info makes sense, thanks!

LIRC output is not very logical ...

0000000000001169 00 VCR_Pause
0000000000001169 01 VCR_Pause

instead of ...

0000000000001169 00 VCR_Pause
0000000000001969 01 VCR_Pause

Are the 00 and 01 next to the hex codes referring to the toggle bits?

Is not clear when LIRC outputs 1169h twice, but with a 00 and a 01 next to them, and doesn't show 1969h.

[The Robman]

[jyll]

If I follow the method posted before, I would expect a 1969h.

Also, how do you interpret the following in light of what we know:

pre_data_bits 2
pre_data 0x02

This is the header ...

[The Robman]

OK, this is for the VCR Pause button, so the binary that we're looking to generate is as follows:

111-00101-101001 or
110-00101-101001

The code you just posted indentifies the signal as 13 bits, where there are 2 "pre data" bits (set to 0x02 or 10b) and 11 "data" bits. It looks like the first bit of our data is taken care of with the "plead" entry.

The code defines the 2nd bit as a toggle_bit. So, it starts out as zero and gets set to one every other button press.

The 11 "data" bits are defined for each button, so 0x1169 becomes 00010-00101-101001, where I'm guessing that the first 5 bits are ignored (ie, 00010-).

I don't know why you're seeing the buttons twice with the extra byte in front of the button name, in fact I haven't seen LIRC buttons with the button names following the hex string before, we usually see the button name first and then the hex string, as it is in the full LIRC files that you posted.

I would still like to see the full file, posted all at once, not just posted in snippets, as I'm having to do a lot of guesswork when trying to decipher it.

The technical details of the LIRC format are listed here:
http://winlirc.sourceforge.net/technicaldetails.html
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[jyll]

There's nothing else, just the header and the codes as posted before:

[The Robman]

I want to see the file that this snippet was taken from because we're trying to determine what the "00" and "01" in front of the button name means ...

[jyll]

That's what the image you can't see what's supposed to show. It shows LIRC's TCP output after I pressed the Pause button once.

I reuploaded the image to another server, can you see it?

[The Robman]

I can see it now, what does that screen shot have to do with the LIRC file? I thought we were trying to decipher a LIRC file this whole time.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[jyll]

According to the method previously posted, we should see 1169h and 1969h, but that's not what LIRC outputs.

EDIT: LIRC only outputs one hex code per button pressed, but uses a repeat count.

[jyll]

I can also get RC5/RC5 extended commands using the IR Toy in RC5 mode (default). Taking the output for the VCR Pause button as an example:

{05}{69}{00}{00}{00}{00} {05}{69}{00}{00}{00}{00}

00000101 01101001 00000000 00000000 00000000 00000000

00000101 = 05h = VCR address (device)
01101001 = 69h = 0+1+101001 = 0 + RC5 2nd start bit + VCR Pause 41 command (OBC)

The leading 01b in the second byte (69h) is a padding "0" and a "1" for RC5's 2nd start bit 2 (always "1") or RC5x's field bit (for extended commands). A value of "1" specifies the lower field commands (0-63), and "0" is for RC5x's upper field commands (64-127).

[Barf]

I would like to add my $0.02 here.

LIRC was never a project for analysis of IR signals, but a project for recording, recognizing, and re-sending of IR signals. The "notation" in the Lirc configuration files is therefore more to be considered as an internal, "private" notation, to be read by machines, but not by humans (with the exception of debugging and LIRC developers...) The winlirc documentation is almost certainly not reliable (several years old, much development have taken place since then), not written by the core developers, not maintained...

The complaint of not being logical and understandable is therefore, IMHO, not justified.

jyll, if you are really that interested, you should study the LIRC source code (freely available), in particular in the directory daemons. (Funny that no-one yet suggested it... )

Even worse,

[jyll]

The output I was seeing had to do with the repeat count (00, 01, 02, 03, ...), it wasn't related to the toggle bit.

LIRC only sends one hex code for each button pressed, but my remote sends the first repeat too fast so that's why I was getting the hex code twice.

I got this ...

000000000000001169 00
000000000000001169 01

but could have seen this, too ...

000000000000001169 00
000000000000001169 01
000000000000001169 02
000000000000001169 03