To make a long story short : I am looking for the IR remote codes of my Minolta DImage camera. It is a two buttons remote, that I do not posess. I have found the learned codes at remotecentral in a file for MX700 remotes.
According to instructions found on the IRClone site, I have converted the MX700 learned codes to Pronto format.

Unfortunately, these codes do not seem to be well decoded by DecodeIR.dll.

thanks for the hints on Protocol Builder. I successfully built the corresponding protocol. The protocol and the device upgrade have been uploaded in the file area of the JP1 group.

The protocol did not work a the first try. I had to analyse the generated signal by learning it with another remote. It happened that the signal was sent in MSB order, while I had assumed LSB. I did not find how to change it from MSB to LSB, neither in PB nor in KM. So I just redefined the fixed bytes with their values reversed and had to live with the fact that the two codes for the device would have hex values $00 and $80 instead of $00 and $01. Is there something I missed with that MSB <-> LSB issue ?

Except in some secondary aspects of combo protocols, PB doesn't get involved at all in the LSB vs. MSB question.

Hex commands are always MSB.

In most protocols, the OBC is LSB, so the translation from OBC to hex command must reverse the bits. KM or RM handle that in protocols where they know the OBC to hex command rules.

For custom protocols, I've never really understood how to tell KM the right OBC to hex command rules. When I do any more custom protocols, I'll use RM instead. RM's protocols.ini file is a simple text file, so when you want to use RM for a custom protocol, you can just create an entry in its protocols.ini file ans specify any translation you like between OBC and hex command.

I went back to check because John's comments reminded me that, I generally don't use KM's translation when I use PB. Usually, that is because I am creating some signal with a lot of bits and frequently need more than three devices and more than two variable bytes.

To get beyond the three devices you must enter it as hex separatred by spaces. To use more than one variable byte then you can use "byte 2" but the value must be in hex. Reasonably, KM Master doesn't manipulate any bits entered in hex in fixed or variable data regardless of what "signal style" is selected. So far this all seems logical to me. In fact IIRC, I have done 5 variable bytes of data and KM faithfully passed those hex commands through to the device upgrade

The other issue (which has nothing to do with Alain's situation) is fixed or variable data using MSB with less than 8-bit bytes. When you define the width of a fixed or variable command, for example, 7-bits, AFAIK it always uses with the top most 7-bits in hex assuming that hex commands are always MSB. However, I had some dim recollection of MSB not always working correctly using the “signal style” feature.

I just ran a simple test using KM. Using manual settings and "Use OBC", I put 1, 2, and 3 in devices 1, 2, and 3 and OBC’s 1, 2, and 3 for those numerals in the functions tab. In 8-bits going through signal style:

LSB-COMP
LSB
MSB-COMP
MSB

works as expected. But, when I changed the bits/dev and bits/command both to four, then signal style MSB returns (all in hex) fixed data 10, 20, and 30 but 01, 02, 03 for the variable data. I didn't try all the other combinations of bit-widths.

I am not sure that this urgently needs fixing, but it does seem like more people are using PB and I thought I would point it out._________________-Jon

I had noticed the LSB/MSB parameter, but when I changed it, it had no visible effect either on the protocol or the upgrade code. Modifying the "Signal style", "Bits/Dev" or "Bits/Cmd" parameters of "Manual Settings" do not seem to produce any change.

Is this a bug, or are these parameters only applied when a new protocol is pasted ?

I just tried it again in KM Master v7.47 and got the same results as I posted. This time I pasted in a protocol from PB first and then changed the values of signal style and values changed as expected except for the MSB 4-bit case the same as above.

Is it possible when you put the values in from either PB or the functions that you "pasted" values from the other spreadsheets rather than paste special, values? Did you use OBC's?

Could this be the US/European conflicts in Excel for hex2bin, etc.?_________________-Jon

I am using KM version 7.56, the most recent available one.
I have reloaded the upgrade from a text file, so I do not think there is a problem of incorrectly pasted values. Regarding incompatibilities with my non-english version of Excel, this might be the source, but I do not know where to look for.
What should happen when the value of "Signal style" is changed ? Should the protocol, the upgrade, or both change ?

What should happen when the value of "Signal style" is changed ? Should the protocol, the upgrade, or both change ?

I just took a quick look at what KM is doing and it appears that only the Fixed Data calculations are affected by the Signal Style setting. There are also errors encountered when Bits/Dev are set greater than 8 using MSB or MSB-Comp.

When I get some free time, I'll have to dig into this a little further._________________Mark

what I was doing differently was using EFCs rather than OBCs and directly entering "Raw fixed data" in C12 rather than in device numbers C9 to C11.
Doing it as you indicated works well and the "Signal Style" parameter is correctly applied in the upgrade.

I presume, but maybe one of the guru will correct me, that the protocols generated with the Protocol Builder Excel sheet are remote specific. As the protocol in the KM update has been generated for an URC-6131 it might not work on your 15-2116.