JP1 Remotes

Perfect. I've added all 5 of the DVD commands to the soft buttons for testing. Download from the same link again. Likeliest candidates are DVD6, E or A if you want to try those first.

Thanks

mdavej wrote:I've added all 5 of the DVD commands to the soft buttons for testing.

Thank you! I have downloaded the updated file and will start testing shortly.

-- from CyberSimian in the UK

For those interested in the protocol details, here's what I've identified so far. All the numbers below are hex for simplicity.

I've been able to mostly relate the original protocol commands (1 byte) to the official protocol commands (2 bytes) except for the last nybble.

Here's an example of the relationship using the Direction Left command which is device number 15 and function hex 14 in the original protocol and AC 5A in the offical protocol.
If we separate into bits, you can see the relationships, original on top, new on bottom:
0 0 0 _1 0 1 0 1 ____0 0 0 1 _0 1_ 0 0
______1 0 1 0 1_ 1 _0 0 0 1 _0 1 _____1 0 1 0

Green is the device number. New adds an extra bit to this which is 1. New also doesn't care about the first 3 bits (0 0 0 in the original).

Red and brown are the MSB and MSN (most significant nybble?) of the second byte of the function code in hex.

The last nybble in purple I can't correlate with the original. It takes only 5 of the 16 possible hex values: 1, 2, 6, A or E, but I don't know what these represent. I thought maybe some sort of complement or checksum of the other bits, but nothing fits.

mdavej wrote:I've added all 5 of the DVD commands to the soft buttons for testing.

Last button done! The DVD function is provided by button DVDE.

-- from CyberSimian in the UK

Woo-hoo! I updated the full upgrade with all the commands you found (all on the soft buttons except Enter which I put on the Enter button). Double check those when you get a chance, just in case I made a mistake.

http://www.hifi-remote.com/forums/dload ... e_id=25283

mdavej wrote:I updated the full upgrade with all the commands you found

Very many thanks Dave, for all your hard work on this. Without your efforts, my XSight Lite and XSight Plus would have been consigned to the "dead remotes" drawer. Now they live again!

And of course I must express my thanks to the creators and maintainers of RMIR, without which none of this would be possible!

I will post back if I notice any problems with the new definition.

-- from CyberSimian in the UK

You're quite welcome. Thanks for all the testing.

Here's the S3C8 executor for this protocol:

Upgrade protocol 0 = 02 1B (S3F80) Manual Settings: 02 1B (RM v2.06 build 5)
41 89 12 8B 13 8D 84 10 01 08 00 F4 00 E0 00 F4
00 E0 5E 5B 03 DE 00 E0 E4 04 06 B6 06 08 E4 06
08 B6 08 0C 0C 04 B0 C4 58 05 77 47 37 57 07 CF
C0 C4 90 C5 0A F4 B4 05 C4 49 07 F6 01 46 E4 06
04 E4 07 05 F6 01 46 F6 01 0A 7B F8 E4 08 04 8D
01 46
End

Thanks Rob!

CyberSimian, to make this show up in RM, close all instances of RM and RMIR and paste the following into protocols.ini in your Remote Master install folder in place of the section that starts, [pid: 02 1B]
To use it in your other Xsight, open the RMDU you used for the Lite and change the remote model. Pick "Ortek (Official)" from the Protocol list (was Manual ...). Save, then add into your Devices on the other Xsight. We personally haven't done any testing on this version, but it should work.

Can we add the TI2541 code that's already in protocols.ini too?

[pid: 02 1B]
PID=02 1B
Code.TI2541=01 02 01 21 12 92 00 04 13 00 13 00 00 00 13 00 13 00 00 00 52 07 4D 00 13 00 00 80 38 17 05 03 08 17 07 05 0C 56 2C 04 0E 56 20 04 0C 56 14 04 08 55 08 04 08 57 20 00 00 17 06 04 08 57 18 00 00 17 06 04 0C 57 10 00 00 17 06 04 0E 57 08 00 00 17 06 04 0F 42 40 23 00 71 72 42 50 23 00 73 74 42 40 03 00 75 74

Not sure what to do about that because the existing 02 1B is an entirely different protocol. I have no idea what it is, but it's not Ortek. We should probably give the existing one a name and a different ID, if possible. I've let Graham know about the conflict.

And do we know of any relationship between the OBC and Byte2? I just took a quick look and didn't spot one. I would recommend OBC1 and OBC2 as names though.

I really couldn't come up with a relationship either. See my color coded analysis a few posts back. I don't fully understand what the last nybble of OBC2 represents. I do know that it only takes 5 values - 1, 2, 6, A or E. The OBC1 looks like a Device number to me. And the function code kind of spans part of both OBCs.

I don't quite follow all of it, but here's what 3FG came up with:

... the new executor parses the device and command parameters differently than we do:
Our IRP is:
{38.6k,480}<1,-1|-1,1>([P=0][P=1][P=2],4,-1,D:5,P:2,F:6,C:4,-48m)+{C=3+#D+#P+#F}

The 021B executor uses one device byte with just one bit of D. The first command byte is the remaining 4 bits of D, the 2 P bits, and 2 bits of F. The second command byte is the remaining 4 bits of F and the 4 C bits. The C bits are for the first frame when P = 0. Of course the IRP is in lsb, and UEI executors are all msb, so getting the bit order right is likely to be a challenge (at least it usually is for me). The subsequent frames C and P values are computed in the executor.

The need to compute the C values will require a custom translator, I think.

If you can make more sense of it, I'm all for giving the OBCs names, but I'm at a loss right now.

I did put together a spreadsheet which I can post tomorrow that you may be able to see a relationship in.

Here's my spreadsheet:
http://www.hifi-remote.com/forums/dload ... e_id=25288

mdavej wrote:to make this show up in RM, close all instances of RM and RMIR and paste the following into protocols.ini in your Remote Master install folder in place of the section that starts, [pid: 02 1B]

Did that!

To use it in your other Xsight, open the RMDU you used for the Lite and change the remote model. Pick "Ortek (Official)" from the Protocol list (was Manual ...). Save, then add into your Devices on the other Xsight.

I have also done this. However, the first two times that I tried this, RMIR locked up on returning from the device editor to RMIR (clicking the tabs had no effect). The third time worked OK. I don't know what was different about the third attempt.

I loaded this definition into the XSight Plus, and am happy to report that it works fine with this update.

However, I have noticed one quirk in the Ortek definition. In earlier posts we discussed the question of whether the Ortek definition should contain duplicated buttons. I would vote against duplicates, but I accept your point about the buttons being known by different names. I would address this by using compound names (if RMIR accepts blanks in names), like so:

"MyTV (Yellow)"
"MyMusic (Blue)"
"MyPictures (Green)"
"MyVideo (Red)"

None of the "MyXXX" are currently present, but there IS an interloper. The Lite and the Plus both have a button called "List", but the Ortek doesn't. Nevertheless there is a definition for an Ortek "List" button that duplicates the definition of the "Yellow" button.

So I would suggest deleting the entry for the fictitious Ortek "List" button, and (optionally) adding the "MyXXX" to the existing colour names as outlined above (if RMIR would accept this).

-- from CyberSimian in the UK