Bug found in LDKP protocol in all JP1.3 extenders

unclemiltie · Post by **unclemiltie** » Tue Apr 12, 2011 5:40 pm

I've just uploaded new versions of the following:

Atlas 3000/3033 Extender (V2.12)
Comcast 3039 Extender (V1.02)
RS 15-100 Extender (V1.02)
RS 15-13x Extender (V1.12)
RCA RCRP05B Extender (V1.04)

In trying to figure out some issues with LDKP processing on the Insignia remote, I found a bug in the processing of single keypresses in the LDKP procotol. In essence, the computation of the length of the single side of the macro was off by one and it loaded an extra byte (the LDKP control byte) into the macro, which then could execute a key or could do nothing, depending on what it found.

This bug has no impact on those who use the Long/Short feature of the protocol, only those who use the Double/Single feature.

Note: If you use the RCRP05B extender, I released a 1.03 last night but have deleted it since there were no downloads. This fixed a bug in the set_menu processing and in shift cloaking on keys over $40 in value. These fixes are included in the 1.04 release.

The new files include new RDF's to match as we wait for the distribution to catch up. I've also uploaded all of the latest RDFs to the SVN repository so when there is a new distro (or those who use SVN for your RDF files) will see the sync later today.

This bug will also be fixed in the Insignia extender when V1.00 is released (soon)

R2-M0 · Post by **R2-M0** » Wed Apr 13, 2011 9:04 pm

OK, it's entirely possible that I've managed to muck something up here. But since upgrading to v1.04 of the RCRP05B extender, it seems like the short sides of my LKPs have stopped working.

For instance, I have an LKP on the power button. Used to be a short press power toggled the current device, while a long turned off everything. Now the long still works, but the short doesn't seem to do anything.

Similarly, I have an LKP on CBL/Aspect. A short press used to send the signal to adjust my DVR's zoom, while a long would cycle through the TV's zoom modes. Again, only the long seems to be working for me now.

I've uploaded my IR file to the diagnosis area.
dload.php?action=file&file_id=9614

unclemiltie · Post by **unclemiltie** » Wed Apr 13, 2011 10:12 pm

I am traveling for the rest of the week and will look at this when I return

unclemiltie · Post by **unclemiltie** » Mon Apr 18, 2011 9:49 pm

I've had a chance to download your file and check into things. Your IR file does fire a short LKP when the CBL device is selected but not on other devices. I am not sure if it is the extender or something that happened during the upgrade. For example:

Code: Select all

 
in CBL mode, power will fire a short Panasonic_old dev=27, key=7 and in long a series of codes for different devices

Can you do me a favor. The patches below will revert you back to the V1.03 LDKP protocol in your configuration and will change nothing else. If you can go into your IR file and make the following 6 changes (each change is one byte) and then try your IR file again and see if it works. That'll validate if the config changed somehow during upgrade or if I really introduced a bug.

Code: Select all

For each of the addresses, swap the "new" byte with the "old" byte.  

$981  new: 0C, old: 2C
$9AE  new: 08, old: 28
$9B0  new: 0E, old: 2E
$9B7  new: 30, old: 32
$9BD  new: C0, old: C2
$9C2  new: B0, old: B2

To do this go to the raw tab, find the appropriate bytes and change them. When you've changed all 6, hit the apply button and then go back and make sure that they're changed. Then upload the IR file to your remote.

(you could also edit the IR file in notepad and then use IR to upload it)

The specifics:

I found that during the delay on the single/double keypress processing, I was using register W0 twice. Once to find the bytes in the command to process (i.e. the short/single or long/double) and one for the delay. The changes in 1.04 switches to use W2 instead of W0. these changes revert to using W0 on all of the places that I changed the code. (thus all of the changes involve changing a 2 to a 0)

R2-M0 · Post by **R2-M0** » Thu Apr 21, 2011 9:13 pm

OK, it was my turn to be out of town for most of the week. But I'm back and I played around with 1.04 some more tonight.

I made the changes you requested, and didn't see any difference. But after some more experimentation, I concluded that I must have rushed my testing last week and misdiagnosed things. Now, I think I have figured out the real culprit here.

On the short-sides of my Aspect and Power button LKPs, I was taking advantage of XShift cloaking to access the underlying device functions on those buttons. That's what appears to be screwed up. If I change those short macros to use Shift cloaking instead, things appear to work just fine.

XShift cloaking was working fine in v1.01, which I had been using before this upgrade. And the reason that the short function of my Power LKP only worked for the CBL device under 1.04 was because I had explicitly defined XShift-Power for CBL as a ToadTog macro, since my DVR does not have discrete power commands.

unclemiltie · Post by **unclemiltie** » Thu Apr 21, 2011 10:26 pm

hmmmm....

There was another change in 1.03 that changed the cloak mask from $3F to $7F after a bug found in the insignia extender that wouldn't allow a key with value of $40-$7F to get processed since it got masked. I don't quite know how this would impact cloaking though as both Shift and Xshift are above $80 and the cloak mask would get that.

Another experiment:

the cloak mask is stored at $5D8 and in V1.04 is $7F. In 1.01 it was $3F.

if you change that back and try your config again, does it work?

I can't imagine that it would have an impact, but you never know since there is so much in the remote that I rely on for the extender.

let me know

-bill

(but at least I know that the change in the LDKP protocol wasn't the issue!)

R2-M0 · Post by **R2-M0** » Fri Apr 22, 2011 12:17 pm

unclemiltie wrote:the cloak mask is stored at $5D8 and in V1.04 is $7F. In 1.01 it was $3F.

if you change that back and try your config again, does it work?

I think you meant $6D8, not $5D8. But yes, reverting that byte back to $3F does indeed seem to fix my XShift cloaking issue.

Perhaps the problem is that XShift (as defined in the RCA extender RDF) is $C0. $C0 & $7F = $40, while $C0 & $3F = $00. So while a $3F mask would leave $C0 unchanged, a $7F mask would turn the XShift value of $CO into $80 (aka, DiscreteOn).

unclemiltie · Post by **unclemiltie** » Fri Apr 22, 2011 2:50 pm

Crap

UEI does it to me again. Now I'm going to have to add code to deal with the couple of keys above $3F in the unextended remote.

In the mean time, on the RCA at least, the clock mask can be left at $3F since the only key above $3F in the remote is the DVR key and that is most likely to ALWAYS have a macro on it, which gets around this.

On the insignia, I have work to do!

I'll build a 1.05 soon that fixes this. But anyone using 1.04 can patch the cloak mask back to $3F and the extender should work just as 1.01 did, with the benefit that the single/double protocol will actually work right.

-bill

unclemiltie · Post by **unclemiltie** » Thu Apr 28, 2011 9:21 pm

Well, I've confirmed it.

1: I do have to deal with the fact that UEI has some keycodes above $40 and the old tricks of just masking off the high two bits to shift-cloak isn't gonna work.

2: On top of that, adding just one BTJRF instruction makes the extender two bytes too long and it won't fit (at least on the RCA where I'm working now)

Now I have to go back into the extender and see if there are some places where I can re-order and change the code around to save a few bytes.

The Insignia won't be an issue since it doesn't take nearly as much setup space as the RCA does. But hey, if I do it for one, I'm doing it for the other.

In the mean time, on the RCA going back to $3F for the cloakmask (as described above) is a perfectly good solution since the only keys at $40 and above are device keys and those are likely to have keymoves or macros on them anyway so I don't have to worry about chopping those off in most configurations.

The Insignia, on the other hand, has issues with real keys up there.

R2-M0 · Post by **R2-M0** » Fri Apr 29, 2011 3:45 pm

unclemiltie wrote:Now I have to go back into the extender and see if there are some places where I can re-order and change the code around to save a few bytes.

Would it help to externalize some of the special protocols into their own executors, instead of having them just jump into the extender code?

For instance, the classic pause protocol that you can find in RM worked just fine for the unextended RCRP05B, as long as you changed the protocol ID. Could you just ship the extender with that one instead? (That would also allow users to choose for themselves whether they'd prefer to use the standard pause protocol or the interruptible version.)

unclemiltie · Post by **unclemiltie** » Fri Apr 29, 2011 5:10 pm

That's not where I have issues

The protocol code all resides in the "hidden" area of the JP1.3 remotes, where cable companies generally keep backup of their stuff so a reset will restore that part. The extender lives in the old advance code area after the (properly terminated) advance code that activates the extender.

I could probably move some of the "helper" routines in the extender into the hidden area, there is still space there. But It'll be easier if I just find a couple of bytes that I can squeeze by reordering some stuff and turning a couple of JP's into JR's.

it's just time...

unclemiltie · Post by **unclemiltie** » Fri Apr 29, 2011 7:36 pm

Oh, and one of the easiest ways to solve this would be to remove the code that I just put in for the user-defined delay value between each key in a macro.

I've never used it and always wanted my macros to be as fast as possible and can deal with delays by inserting them myself. But others had asked for it.

thoughts?

mdavej · Post by **mdavej** » Fri Apr 29, 2011 8:22 pm

I'm perfectly fine with that.

R2-M0 · Post by **R2-M0** » Sun May 01, 2011 7:24 am

I haven't used the macro delay value either, so I have no problem with it going away

unclemiltie · Post by **unclemiltie** » Wed May 04, 2011 10:37 am

I think I found the space by recoding some stuff and moving things around in the area where I decide if the key being processed is part of the HT control keys (Dev_x, Dev_Cancel, Set_x) which are at a contiguous block starting at PseudoBase and ending at PseudoEnd.

this is what I had:

Code: Select all


CP        RC0,PseudoBase             ;is key less than HT control block?
JRLT      SetHTDev                   ;yes, go process key
CP        RC0,PseudoEnd              ;is key greater than HT control block?
JRGT      SetHTDev                   ;yes, go process key
SUB       RC0,PseudoBase             ;compute offset into HT key block
TM        RC0,#08                    ;is this Dev_Cancel or a Set_X command?
JRNE      SetKey                     ;yes, go process Set_x keys

This is what it can be (I'm pretty sure, I haven't loaded this into a remote yet)

Code: Select all

CP       RC0,PseudoEnd                ;is key greater than HT control block?
JRGT     SetHTDev                     ;yes, go process key
SUB      RC0,PseudoBase               ;compute offset into HT key block
JRLT     SetHTDev                     ;index out of block, go process key
BTJRF    SetKey,W0.3                  ;is this Dev_Cancel or a Set_X command?

This saves 7 bytes from the original code and allows me to fit the fix for keys over $40 into the RCA extender. I'm going out of town today and won't be able to load up a remote and give it a whirl, but I'm pretty sure that this fix will do it.

thanks for all of your patience on this one.