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

Bug found in LDKP protocol in all JP1.3 extenders
Goto page 1, 2  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Extenders
View previous topic :: View next topic  
Author Message
unclemiltie
Expert


Joined: 21 Jan 2004
Posts: 1795
Location: Pittsburgh, PA

                    
PostPosted: Tue Apr 12, 2011 6:40 pm    Post subject: Bug found in LDKP protocol in all JP1.3 extenders Reply with quote

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)
_________________
this JP1 stuff is a sickness!
Back to top
View user's profile Send private message
R2-M0



Joined: 14 Aug 2009
Posts: 92

                    
PostPosted: Wed Apr 13, 2011 10:04 pm    Post subject: Reply with quote

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.
http://hifi-remote.com/forums/dload.php?action=file&file_id=9614
Back to top
View user's profile Send private message
unclemiltie
Expert


Joined: 21 Jan 2004
Posts: 1795
Location: Pittsburgh, PA

                    
PostPosted: Wed Apr 13, 2011 11:12 pm    Post subject: Reply with quote

I am traveling for the rest of the week and will look at this when I return
_________________
this JP1 stuff is a sickness!
Back to top
View user's profile Send private message
unclemiltie
Expert


Joined: 21 Jan 2004
Posts: 1795
Location: Pittsburgh, PA

                    
PostPosted: Mon Apr 18, 2011 10:49 pm    Post subject: Reply with quote

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:
 
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:

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)
_________________
this JP1 stuff is a sickness!
Back to top
View user's profile Send private message
R2-M0



Joined: 14 Aug 2009
Posts: 92

                    
PostPosted: Thu Apr 21, 2011 10:13 pm    Post subject: Reply with quote

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


Joined: 21 Jan 2004
Posts: 1795
Location: Pittsburgh, PA

                    
PostPosted: Thu Apr 21, 2011 11:26 pm    Post subject: Reply with quote

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!)
_________________
this JP1 stuff is a sickness!
Back to top
View user's profile Send private message
R2-M0



Joined: 14 Aug 2009
Posts: 92

                    
PostPosted: Fri Apr 22, 2011 1:17 pm    Post subject: Reply with quote

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


Joined: 21 Jan 2004
Posts: 1795
Location: Pittsburgh, PA

                    
PostPosted: Fri Apr 22, 2011 3:50 pm    Post subject: Reply with quote

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
_________________
this JP1 stuff is a sickness!
Back to top
View user's profile Send private message
unclemiltie
Expert


Joined: 21 Jan 2004
Posts: 1795
Location: Pittsburgh, PA

                    
PostPosted: Thu Apr 28, 2011 10:21 pm    Post subject: Reply with quote

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.
_________________
this JP1 stuff is a sickness!
Back to top
View user's profile Send private message
R2-M0



Joined: 14 Aug 2009
Posts: 92

                    
PostPosted: Fri Apr 29, 2011 4:45 pm    Post subject: Reply with quote

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


Joined: 21 Jan 2004
Posts: 1795
Location: Pittsburgh, PA

                    
PostPosted: Fri Apr 29, 2011 6:10 pm    Post subject: Reply with quote

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...
_________________
this JP1 stuff is a sickness!
Back to top
View user's profile Send private message
unclemiltie
Expert


Joined: 21 Jan 2004
Posts: 1795
Location: Pittsburgh, PA

                    
PostPosted: Fri Apr 29, 2011 8:36 pm    Post subject: Reply with quote

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?
_________________
this JP1 stuff is a sickness!
Back to top
View user's profile Send private message
mdavej
Expert


Joined: 08 Oct 2003
Posts: 4500

                    
PostPosted: Fri Apr 29, 2011 9:22 pm    Post subject: Reply with quote

I'm perfectly fine with that.
Back to top
View user's profile Send private message
R2-M0



Joined: 14 Aug 2009
Posts: 92

                    
PostPosted: Sun May 01, 2011 8:24 am    Post subject: Reply with quote

I haven't used the macro delay value either, so I have no problem with it going away
Back to top
View user's profile Send private message
unclemiltie
Expert


Joined: 21 Jan 2004
Posts: 1795
Location: Pittsburgh, PA

                    
PostPosted: Wed May 04, 2011 11:37 am    Post subject: Reply with quote

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:


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:

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.
_________________
this JP1 stuff is a sickness!
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 - Extenders All times are GMT - 5 Hours
Goto page 1, 2  Next
Page 1 of 2

 
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