Interpretation of user notes within specific rdmu file

[bpsherwo]

I'm trying to understand the "notes" within a specific user's file posted at:
https://www.hifi-remote.com/forums/dload ... le_id=1624

It's a device upgrade for:
Audio Pioneer VSX-D511 Remote XXD3038

I'm not sure how to reference to my specific question, but I'll try this technique... with the rdmu file open in a text editor you can see the following line:

Function.0.notes=165 28 C7 244 ok

I've decoed this user comment to mean:

Function.0.notes=DEV 165, OBC 28, UNK C7 244

The Device is 165, the Original Button Code is 28, and I'm assuming "ok" means the person successfully tested it.

But I don't understand C7 244. I bet it's meaningful, and I would like to learn a bit about it. (I used UNK to indicate UNKnown)

Also the line:

Function.7.notes=165 159 06 002 - 165 203 2C 051 \= F9 9A --

I've decoded this to mean:

Function.7.notes=DEV 165, OBC 159, UNK 06 002 - OBC2 203, UNK 2C 051, Hex F9 9A

This introduces the Hex value for the 2nd button code, but again I'm faced with 06 002 and 2C 051.

Can anyone explain what the user was likely trying to point out with the codes I labeled as UNK. I have listed 2 examples, but each function has type of user note.

Thanks,
Brad Sherwood

[gfb107]

I suggest actually using RM to look at that file, rather than a looking at the raw text.

In particular, the overall upgrade notes are of interest:

Code: Select all

BE SURE YOU SELECT RCVR WHEN YOU INSERT THE DEVICE UPGRADE IN IR TO PREVENT PROBLEM.

Don't change values for double sequence codes. there is a bug in protocol 3DEV of RM which prevent you to enter the second byte of the 2nd code.

Use KEYMAP-MASTER to know the hex value for NEW function codes. Below is an example of the problem of RM:

EXEMPLE:

fonction	OBC	DEVICE	EFC	HEX	ORIGINAL SCAN CODE
---------------------------------------------------------------------------------------
Adv Surround	197	1 211	159	f9 99	165 159 06 002 - 165 211 34 115
			------

With RemoteMaster 1.08, The result can't be good:

fonction	OBC	DEVICE	EFC	HEX	CODE SCANNÉ ORIGINAL
---------------------------------------------------------------------------------------
Adv Surround	197	165	159	f9 80	165 159 06 002 - 165 211 34 115
			-----		   --

As you can see, the errors are underline. This is why you must use Keymap-Master to know the 2nd byte and enter it in the hex value.

The above text may provide the information you need to understand the author's notation.

This upgrade was created with a version of RM (v1.08) that didn't correctly support the Pioneer 3DEV protocol. I'm certain that the newest version (v1.49) of RM doesn't have that bug.

[whompus]

I can not explain it because a lot of the pioneer protocols have me bamboozled as well.

I think for instance where you have unk C7 244 the c7 is hex for byte 2 of the second device and 244 is the efc used in km to get the hex for it.

What I don't understand is why this was 3dev instead of 4dev protocol. Maybe Greg or Rob or someone can explain to us both.