JP1 Remotes

which seems to send keyboard presses.

What do you mean by that?

The only thing I have been able to find are some raw hex codes from the Pronto boards.

Post a URL for what you found. I think you might have misunderstood something on the Pronto boards and the Pronto Hex you copied might not be ...

As I examined some other standart protocols I saw that no other protocol has so much bytes. What may be the reason for such a long code?

That seems to be the way protocols for Air Conditioners are designed (much longer signals than those in ordinary IR protocols).

If I can find the exact ...

I don't have time to go through that CCF to confirm or contradict any of the following, but the one signal you posted looks generally like other AC signals that tend to have the following big problem and further complication:

1) The actual signal is usually too long for a learning remote to learn ...

Does anyone remember the threads about a different old model that had problems with the floating reset line?

I forget the model number and what keywords were in the thread, but I do remember the underlying technical issue:

The reset line of the main chip in older JP1 remotes is normally connected ...

I'm very happy with the choice I made to include nested bit specs in the definition of the concise irp notation, so that

{msb}<-1|1>(<8:4|4:4|2:4|1:4>( ... ) )
means the same as
{msb}<1,-3|-1,1,-2|-2,1,-1|-3,1>( ... )

I'm not quite as happy with using the nested bit spec in this specific protocol ...

bits 16
...
pre_data_bits 16
bits 16
Notice that bits is how many bits are allowed to vary between commands and pre_data_bits is how many bits before the varying bits are the same for every command.

What I had done was put the device & subdevice plus the command & it's complement as the data ...

As I just noted in the other thread, the E value in these signals seems to be computed from the low byte of the OBC. So the optimal solution would be a new executor that does that. But I don't have time to write that executor (I don't really even remember how). I don't know whether any existing ...

Notice the E value in these signals is acting as an extra check nibble. It is not independent information. If I'm reading it right, E and the low nibble of the OBC xor to 1.

I don't recall seeing that check nibble pattern in Kaseikyo before. But the check nibble rules usually vary between ...

~F:1:6

I always have a lot of trouble interpretting the multiple colons ::: in IRP

I think you already understand. But just in case it is still confusing, I'l give you my point of view:

~F (as you already knew) is F with every 0 bit changed to 1 and every 1 bit changed to 0.

The value after ...

Can I just use the information from line 1, and will it work?

Correct.

There are lots of reasons for duplication and extra crap in a decode. It is generally correct to take the good part of a decode and ignore the rest.

I looked at your file and except for the Denon-K signal, all the others are ...

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

In that file, notice these lines
pre_data_bits 13
pre_data 0xEFF

That means the first 13 bits of each signal ...

Hey I am trying to make a TV remote from scratch, So far I have managed to build a receiver using a solar panel hooked up to my computer microphone jack, and audacity to record the infrared light that it emits.

Which it do you mean? Some first version of the remote you're trying to build? Or the ...

it seems to sample at 10KHz in raw mode which is the reason for too many bits when converting the ON/OFF-signal from the IR receiver to a byte array. It also explains why I see the correct wave form in the analyzer, what i thought was one long ON-period is actually multiple samplings that were all ...

If I look at the raw data supplied from the IR Toy in a logic analyzer I notice the pattern described by the specification (i.e the IR-receiver gets 10 1000 10 1000... etc

That is surprising. It would mean something (the IR Toy or the logic analyzer) is processing the input either with the ...

Unless you know of another existing tool that would show me the remotes codes as they're "supposed" to be read?

The device number and OBC for this protocol (and almost all others) are the codes as they're supposed to be read.

The Hex cmd and EFC are tied to internal details of the UEI universal ...