JP1 Remotes

~Vicky,
I saw the repeating pattern by going back to the original pronto hex, but you can also see it in the IRP above...

Form=*,D:8,S:8,F:8,F:4:4,~F:4,_;*,1:1,_

This form statement means the signal includes....

leadin (*)
an 8 bit device code
an 8 bit sub-device code
an 8 bit function code
a repeat of the function code starting with bit 4 for a length of 4
a complement of the first 4 bits of the function code

repeating portion:
leadin (*)
a 1 bit code, value 1

Regarding using 2 variable bytes instead of using assembler, absolutely, you can do that, and sometimes it's the right thing to do. When deciding, you need to look at how many bytes of assembler will be needed vs. how many buttons are likely to be in the upgrade, because each button will now use up 2 bytes of the upgrade instead of 1. In this case, it took 10 bytes of assembler to generate the checksum and there are 17 buttons likely to be in the upgrade. However, if you don't know how to write assembler, you might want to chose to generate the checksum outside of the upgrade.

In this case, I also needed assembler to generate the repeating portion, but it may have been possible to do it using the IR engine. The repeating portion is very similar to the repeating portion of the NEC1 signal, which is done entirely using the IR engine. However, there is no data in the NEC1 repeating portion. What threw me here is the 1 bit data code in the repeating portion, which is why I did it by hand.

kupakai wrote:...I'm not quite clear on which DCBUF holds what yet.

The first bytes in DCBUF will be the fixed data from the setup code. In this case there would be 2 bytes of fixed data, so DCBUF+0 (R03) would contain the first byte of fixed data and DCBUF+1 (R04) would contain the second.

Right after the fixed data will be one or more command bytes (the ones assigned to a button in the setup code). So DCBUF+2 (R05) would have the single command byte in Rob's PB scenario. He then generates the checkbyte in assembly and stores it in DCBUF+3 (R06) as a second command byte.

For the S3C8 processors, DCBUF starts at R03, and is a maximum of ten bytes in length.

I updated the PB file here to include a HCS08 version and tested both and it seems to be sending the correct signal.
The test device upgrade uses two signals from kupakai's post. Fixed data is AB 54. C0 is Power On. 20 is Power Off.

Did you need to make any corrections to my code? I'd be surprised to hear that it worked perfectly first time.

No changes needed. I used symbol names instead of registers to make it easier to compare the two versions.

my IR dongle arrived in the mail today, so I have test results!

Every command works. At first, I thought "more info" was not functioning, but it is only used so far in entering passcode combinations. It works.

Rob, you are amazing. Thank you everyone who contributed to the effort. I'm going to write up the details as soon as I get a chance this weekend. Right now, my wife wants to rent The Other Bolyn Girl and I don't want to keep Natalie and Scarlett waiting...

summary for KM:

Protocol: Manual Settings (paste in Rob's code)

DVD 2047

Device 1: 213
Device 2: 42

Functions:
channel up: ha0
channel down: h60
power: h40
menu: h04
program guide: h04
display/info: h94
exit: hd0
up: h48
down: hc8
left: h28
right: ha8
select: hd4
sleep: h20
play: h98
pause: hb8
rew: h58
ff: hd8

discrete on: hc0
discrete off: h20

I got it working on my 2117 as well as my HTpro, 1994, old6131 and showstopper remotes.

FYI the 'more info' command was the only one that when learned from the 2117 to the HTPro gave results that looked odd:

To wrap this thread up, here's a link to Revwillie's upgrade:
https://www.hifi-remote.com/forums/dload ... le_id=5676