JP1 Remotes

The Robman wrote:Hi chuliu,
I apologize, I did forget about this one. I started to look at your files when you posted them and could see what you were pointing out but didn't get around to digging into it further. I will try and review them later today.

It is okay. I think you might have forgotten it, too.

I just export to binary file the an-ip100 upgrade and tested it on my slingbox with an-ip100, and it seems to work just fine.

I finally got around to digging into this, and the problem is a bug in protocols.ini

The following line in each of the entries for [Sharp DVD] should be corrected:

from this:
DeviceTranslator=Translator(lsb,comp,0,4,28,4) Translator(lsb,comp,1,8,32)

to this:
DeviceTranslator=Translator(lsb,comp,0,4,28) Translator(lsb,comp,1,8,32)

Also, your learns show that you really need 70mS as your lead out time, so the control byte should be "02" rather than "03". The "03" value is hard coded for Sharp DVD, so to get the correct value you would need to switch to the Kaseikyo protocol (and set OEM1=170 and OEM2=90).

I have updated your RMIR file as described here:
https://www.hifi-remote.com/forums/dload ... e_id=13876

I've checked a new version of protocols.ini into SourceForge which corrects this error, and also has the capability to send lead-out durations of 20, 44, and 70mSec. I probably caused the error. At one time DecodeIR decoded SharpDVD incorrectly by including a nibble with value 15 in the device code. So protocols.ini accepted 8 bits of Device, and then truncated off the incorrect nibble. When we changed the decode of Device to 4 bits, protocols.ini was changed to only accept 4 bits in the Device field, but the DeviceTranslator entry was not changed.

Hi, Rob and 3FG.
Thanks for correcting the error.

I, however, am a little confused as to how to use the corrected rm to build device upgrade.
In my own manual protocol, I have 4 device bytes and 2 command bytes with lo 70mSec.
Now with the corrected protocol.ini I downloaded from c2 and it was decoded as sharp dvd 8, 26, and with only obc values. I would assume I need a second value for command byte 2, or G value as in Kaseikyo. Otherwise, I need to manually calculated the G value for Kaseikyo.

Please correct me if I am mistaking.

Both Sharp and Kaseikyo have 2 bytes of command data. Did you try the RMIR file that I created for you?

No, my an-ip100 is accessed through a sling box.
I need to be able to export the upgrade to a binary file.
I tried to click edit button on the kaseikyo upgrade that you created, but it won't open up upgrade editor. I cannot save it as rmdu and export to binary file. Can you post a rmdu file of a sharp an-ip100 instead?

You mentioned that sharpdvd has 2 command byte, but in my learns I only see sharpdvd 8,26, and a obc number. I don't see a second value for command byte two. If I have to use Kaseikyo, then I don't know what value to use for G from the learns.

SharpDVD is one version of the Kaseikyo IR protocol. Other versions include Panasonic, Denon-K, Fujitsu, JVC-48, Mitsubishi-K, Panasonic2, and Teac-K. They differ in the OEM numbers, and more importantly, in the format of a checksum byte or nibble which is sent just after the OBC.

The Kaseikyo entry in protocols.ini is very flexible and allow the user to specify the checksum explicitly. However, for the more common Kaseikyo variants, RM is able to calculate the checksum. So for example we're accustomed to only specifying an OBC with Panasonic. If instead of using a Panasonic entry in protocols.ini we were to use the Kaseikyo entry, we'd have to specify a value for G. Similarly, RM knows how to construct the checksum for SharpDVD. You can see it in the line and so it is only necessary to specify the OBC. RM will automatically generate the value for G.

Rob asked you to use the Kaseikyo entry instead of SharpDVD, because Kaseikyo can specify different leadout times, while the earlier SharpDVD entry didn't allow it. But both entries use the PID 00F8:3 executor, so I could modify the SharpDVD entry to allow 3 different leadouts--as shown in my previous post.

chuliu wrote:I tried to click edit button on the kaseikyo upgrade that you created, but it won't open up upgrade editor. I cannot save it as rmdu and export to binary file. Can you post a rmdu file of a sharp an-ip100 instead?

Something must be wrong with your RM setup, because I can click edit to get it to open in RM. I did just that and created the following RMDU file:
https://www.hifi-remote.com/forums/viewtopic.php?t=15183

My fear is that whatever is preventing it from opening from RMIR will also prevent it opening from RM.

3FG wrote:I've checked a new version of protocols.ini into SourceForge which corrects this error, and also has the capability to send lead-out durations of 20, 44, and 70mSec.

Code: Select all

PID=00 F8
VariantName=3
DevParms=Main Device:4=8,Sub Device:8=48,Leadout(mS):20| |70|44=3
DeviceTranslator=Translator(2,8,0) Translator(lsb,comp,0,4,28) Translator(lsb,comp,1,8,32)
FixedData=03 AA A5 0F FF                      
DefaultCmd=00 00
CmdParms=OBC=0
CmdTranslator=Translator(lsb,comp) SharpDVDTranslator()

I probably caused the error. At one time DecodeIR decoded SharpDVD incorrectly by including a nibble with value 15 in the device code. So protocols.ini accepted 8 bits of Device, and then truncated off the incorrect nibble. When we changed the decode of Device to 4 bits, protocols.ini was changed to only accept 4 bits in the Device field, but the DeviceTranslator entry was not changed.

Hi I assume that I only need to change the entry with variant 3.
Am I correct?

I am asking friend to test on his an-ip100.
My an-ip100 is not accessible at the moment.
Thanks.

Yes, Slingboxes use Variant 3, so that is all you need to change now. The next Build of RMIR will have the new protocols.ini.

3FG wrote:Yes, Slingboxes use Variant 3, so that is all you need to change now. The next Build of RMIR will have the new protocols.ini.

But my friend is testing with his c2...

I think c2 and slingbox uses the same variant.
I will test now.

Hello,
I compared numeric buttons 1 to 5 on Kaseikyo, changed sharpdvd, and my manual protocol.
Kaseikyo and changed sharpdvd appeared the same.
My manual protocol differes from Kaseikyo and sharpdvd in that :
1. the byte before the lead out (one on,LO) in Kaseikyo is always
(437 -1307) but that byte is always (437,-437) in my manual protocol.

2. the lead out in Kaseikyo and sharpdvd is -75000 and in my manual protocol it is -70000.

I assume something wrong with the check nibble calculation.

Also, I noticed that both Kaseikyo and SharpDVD have pid=00 8F
Is it by design or a conflict?
It seems I cannot have device upgrades in rmir for both Kaseikyo and SharpDVD at the same time. Otherwise, one of the two device upgrade will have several tabs grayed out.

chuliu wrote:Also, I noticed that both Kaseikyo and SharpDVD have pid=00 8F
Is it by design or a conflict?
It seems I cannot have device upgrades in rmir for both Kaseikyo and SharpDVD at the same time. Otherwise, one of the two device upgrade will have several tabs grayed out.

As Dave explained earlier, SharpDVD is a specific version of Kaseikyo, the difference is only in what RM pre-programs for you, otherwise they use exactly the same executor.