JP1 Remotes

Good work. So I double checked yesterday's files to see if I missed the hex code changing, but yesterday that was good, it was the device code that was getting dropped. But now that you've upgraded to the current RMIR, the device code is getting passed correctly but the byte2 hex code is not correct.

Yesterday's Learns
Freq___ Raw Timing Data with Coding
37736 +3440 -1720; 010101010101101011110001000011001000001010001111; +430 -20210
36866 +3440 -1720; 010101010101101011110000000011001000001010001111; +430 -43430

Today's Learns
Freq___ Raw Timing Data with Coding
37736 +3440 -1720; 010101010101101011110001000011001000001010001111; +430 -20210
36866 +3440 -1720; 010101010101101011110001000011001000001010001110; +430 -43430
36866 +3440 -1720; 010101010101101011110001000011001000001010001110; +430 -43430
36866 +3440 -1720; 010101010101101011110001000011001000001010001110; +430 -20210
36866 +3440 -1720; 010101010101101011110001000011001000001010001110; +430 -20210

I took a lot of digging but I think I've found the problem. I've tested my fix against the one learn that you supplied and it works, but to be sure I got it right, I'd need to see learns of all the buttons.

So, here's what you should do.
1. Open protocols.ini using a text editor like notepad.
2. Search for the [Sharp DVD] entries (there are 3 of them)
3. Look for the following line in the code:
CmdTranslator=Translator(lsb,comp) XorCheck(4,12,0,2,0;3,4)
4. Change it to this:
CmdTranslator=Translator(lsb,comp) XorCheck(4,12,1,2,0;3,4)

When I do that and enter 65 as the OBC (with dev=8, sub=48), I get hex "7D 70", so it will work for at least the POWER button. I guess you'll need to test whether the other buttons work.

For those curious to know why that change, the nibble (half-byte) that we're having the problem with is the checksum nibble. It is calculated by XOR-ing the device code nibble with both sub-device nibbles, both OBC nibbles and E (ie, the first half of byte2). The way the XorCheck was previously written, it was ignoring the E value (ie, the 2nd "7" in "7D 70"). I was curious to see how this was getting set as there didn't appear to be any code to set it, and I found that it gets set using DefaultCmd=00 70.

So, then I had to figure out how to get that value into the XOR calculation, and I ended up using the "seed" parm. It was previously seeded with 0, so changing it to 1 (which is the value of E in decimal) did the trick.

chuliu,
I updated the bin files that Alan created for you in the other thread, could you test the bins to see if they work?
https://www.hifi-remote.com/forums/viewtopic.php?t=14452

I am sorry but I am remote to the sharp dv-hrd30 and I didn't hook it up to a slingbox. Thus, I cannot test it at the moment. If you can create a bin for sharp an-ip 100 which is sharpdvd 8,26, I can test.

Alan helped create an upgrade here, https://www.hifi-remote.com/forums/dload ... e_id=12306

which at that time didn't work. You can copy the device, subdevice, and obc from there, though.

I am not sure if the issue with these two remotes are related, though.

Done, I updated it, give it a whirl.

The updated file doesn't contain any functions in the functions tab. It seems wrong. I made the correction to sharp dvd in protocol.ini by changing 3 0s to 3 1s. I then open Alan's file, made sure power was 7978, which it should be. I create bin file from that file, no luck.


I am trying to replicate the steps provided in the an-ip100 page 3 where 3fg asked me to download .class and replaced it in remotemaster.jar.


_______________________________________________________
I gave up on replicating the steps by 3fg, as the protocol.ini in rmir 207b2 is different to that in the old protocol.ini when I make the an-ip100 upgrade. I guess Rob is trying to fix as many combination of device code and sub device code working as possible. I keep fingers crossed.

Thanks.

It had a whole page full of functions, but I didn't think to check if any of them were assigned to buttons (and they weren't), so I just assigned them all to buttons. Please try again.

I downloaded the an-ip100 file that Rob updated, and loaded it to slingbox, but still no luck. I had to revert to the remote that is in sling database. Not sure what is wrong, though.

This thread is getting slowly hijacked... :-)))

That's OK. I got it, Rob. Will try protocols.ini fix tonight and report here.
One question though. If it all works, do I then keep the amended protocols.ini or should it be reverted back to the old state CmdTranslator=Translator(lsb,comp) XorCheck(4,12,0,2,0;3,4) after I finish making my upgrade? In other words, is it a permanent change or a temporary patch for my upgrade only?

Thanks for the help. I hope that gave you a bit of fun.

Will report tonight.
Watch this space.

It's all on the subject of the SharpDVD executor, so it's all good.

If you confirm that it works, keep the change in your copy of protocols.ini and I'll make sure that it gets into the official version.

Hi all,

I have manually edited three lines in protocols.ini files (related to SharpDVD) as was instructed above by Rob.

Then I have created the upgrade for my Comcast1067Bx3, based on the Barf's upgrade from the previous page.
It all works. I haven't tested all functions from that upgrade because I ran out of buttons on my Comcast, but I have tested all major functions such as navigation buttons, playback controls, menus access, power, eject, angle, audio, subtitles. All buttons are operating correctly with no exceptions, so there is a good reason to believe that all functions are assigned with correct OBCs.

I suggest that Barf's upgrade should be used as a standard, as it is universal (no buttons assignment), but in case someone wants the upgrade specifically for device as in subj, I have uploaded it to here.

Thanks a lot to all involved in the discussion and of course specifically to Rob for solution finding.

Another box is ticked off.

Regards,
DS

Thanks DS. I checked your file and noticed that the leadout time box was still blank, so I updated it to 20.

The Robman wrote:Thanks DS. I checked your file and noticed that the leadout time box was still blank, so I updated it to 20.

I wrote earlier that I experimented with different LeadOut settings (0/20/44) in the working upgrade, and that made no difference, so I decided to leave it at the default (0) value. But, of course, if we aim to match the Harmony timing as the most trusted reference, yes your correction is right. Thanks. Both variants work fine in this case.

digital_silence wrote:

The Robman wrote:Thanks DS. I checked your file and noticed that the leadout time box was still blank, so I updated it to 20.

I wrote earlier that I experimented with different LeadOut settings (0/20/44) in the working upgrade, and that made no difference, so I decided to leave it at the default (0) value. But, of course, if we aim to match the Harmony timing as the most trusted reference, yes your correction is right. Thanks. Both variants work fine in this case.

Receivers are usually pretty tolerant so in all likelihood it doesn't matter, but sometimes they change suppliers and the new units are more fussy than the old units, so it's always best to match if you have the option to do so.

chuliu wrote:I downloaded the an-ip100 file that Rob updated, and loaded it to slingbox, but still no luck. I had to revert to the remote that is in sling database. Not sure what is wrong, though.

The fix that I did for the 8.48 signals doesn't work for the 8.26 ones. I have just come up with a new fix that appears to work for both.

Change the XOR entries to this:
XorCheck(lsb,comp,4,12,7,2,0;4,0)

The Robman wrote:Receivers are usually pretty tolerant so in all likelihood it doesn't matter, but sometimes they change suppliers and the new units are more fussy than the old units, so it's always best to match if you have the option to do so.

That brings up the related question: do we assume that the IR timing coming out of the Harmony remotes (based on their device database) is always most accurate and can (or rather should) be used as a reference for JP1 upgrades?