RM/RMIR v2.02 Beta now available!

[mathdon]

I'd like to reiterate that there's probably a bug in RM/RMIR associating the correct Pioneer Mix variant when opening or importing an RMDU file which utilizes variant 3. The current work around is to place the variant 3 section of the Pioneer Mix before variant 2 in the protocol.ini file. However, I'm not sure how that will affect RMDUs with variant 2.

Details are described in the following threads:

• EFC codes don't work across remotes?
• RM 2.0x & strange Function tab display problem

I believe this to be fixed in RM/RMIR v2.02 Beta 1.5r

[mathdon]

Deleting the old one fixed it. This issue isn't mentioned anywhere in the documentation, is this an extender issue or? Where does the mane in the rdf come from? Should the extender merge operation edit the name in the rmir file to match the merged extender? Sorry, lots of questions and few answers.

Mike

The name in the .rmir file is taken from the RDF. In this case it will have been the RDF used for the extender in the merge process. If more than one RDF matched the signature of the extender, you should have been offered a choice during the merge. It looks to me as if you chose the old one by mistake. The .hex extender file is just hex data, there is no name in it for the merge process to pick up, so the merge process can do nothing other than use the signature to select the RDF and then to take the name from that RDF.

The merge process doesn't edit the name in the rmir file, as you suggest, as it doesn't create the rmir file. In contrast to IR.exe, the result of the merge is simply to affect what is loaded in RMIR, which will be displayed with the chosen extender RDF. The .rmir file is only created when you save this result and it then picks up the new name for the remote from this RDF. So as I see it, there is no bug and no issue. It seems to have been just an unfortunate slip when you were performing the merge.

Edit: Please also see this post, and earlier ones in the same thread, about installing extenders when there are multiple RDFs.

[eferz]

I'd like to reiterate that there's probably a bug in RM/RMIR associating the correct Pioneer Mix variant when opening or importing an RMDU file which utilizes variant 3. The current work around is to place the variant 3 section of the Pioneer Mix before variant 2 in the protocol.ini file. However, I'm not sure how that will affect RMDUs with variant 2.

Details are described in the following threads:

• EFC codes don't work across remotes?
• RM 2.0x & strange Function tab display problem

I believe this to be fixed in RM/RMIR v2.02 Beta 1.5r

Yep, it looks good to me.

[mathdon]

Prototype RMIR support for JP1.4/JP2 now updated to RM/RMIR v2.02 Beta 1.5s. The enhancements to Beta 1.5r are for a forthcoming extender for the Atlas 1056 B03, a JP2 remote, and for later JP2 extenders. There is no change to other functionality.

[mathdon]

Prototype RMIR support for JP1.4/JP2 now updated to RM/RMIR v2.02 Beta 1.5t. The additions to Beta 1.5s enable device specific macros (DSMs) to be used with those JP1.4/JP2 remotes or their extenders that include this capability. There are a few very minor bug fixes but no change to other functionality.

[mathdon]

I have now updated Prototype RMIR support for JP1.4/JP2 to RM/RMIR v2.02 Beta 1.5v. This is intended to be a release candidate for an official v2.02, so testing and reporting on any issues would be particularly welcome.

Beta 1.5u was a simple bugfix to Beta 1.5t, see this post, but Beta 1.5v contains substantial further developments. There have in fact been 13 versions between Beta 1.5u and Beta 1.5v privately exchanged between me and Vicky (vickyg2003) to resolve the protocol crosstalk issues she raised in this post, together with a number of related issues that appeared during our exchanges. Support for JP1.4/JP2 remotes is now stable. The protocols.ini file has been updated to include MAXQ610 (JP2) code for those protocols where it is available. The digitmaps.bin file has been updated to include Number Tables through 565 (these are the tables referenced by the values in the [DigitMaps] section of the RDF).

There is also prototype support for remotes that use the MAXQ612 chip, provisionally being referred to as JP3. though the only such remote yet encountered is the URC-7962 SmartControl Motion. To provide this, the jp12serial interface has needed to be updated to support 32-bit flash addresses. Version 0.20 Beta of jp12serial.dll is included in the Beta 1.5v package for use with 32-bit Window systems, which it should support from Windows 2000 onward. Binaries for 64-bit Windows and for Linux and Mac OS X will follow shortly. Version 0.19 of the jp12serial interface supports all JP1.x and JP2 remotes but not JP3 and is available for all these operating systems.

To install Beta 1.5v, if you have not already done so then first install the official release of RM/RMIR v2.02 Beta. Then replace the files RemoteMaster.jar, protocols.ini and digitmaps.bin in your installation folder with those in the Beta 1.5v package. Also replace the version of jp12serial appropriate to your OS with either jp12serial.dll v0.20 Beta from the Beta 1.5v package for 32-bit Windows or one of the v0.19 binaries referenced above for other OS. These jp12serial files are in a subfolder of the RemoteMaster installation folder, named according to your OS.

A prototype RDF for the URC-7962 SmartControl Motion is also included in the Beta 1.5v package. It, as well as RDFs for the known JP1.4/JP2 remotes and other newer remotes, is also in the RDF Development folder of the File Section.

If you get an unexpected "RDFs not found!" message when you first run Beta 1.5v, read this post. Please report any other feedback in this thread.

[vickyg2003]

This is a significant improvment over the previous public Beta, and I would stongly suggest that people move up to this version even if you are not using the new remotes.

The BIG thing is that it handles 2byte KM sheets without all the corruption that wss going on before. I know that when I'd do a custom protocol for people in KM, most of the time I had to create an RDMU file too, because the files wouldn't transfer all the data into RM. Now it does. It also does a much better job of opening KM sheets with 2 byte "known protocols". Many of them used to corrupt too.

This fixes all of my cross talk issues where things would corrupt if you happened to LOOK at a protocol with a different version of the PID.

It handles the bug where RM used to hang after you tried to open an upgrade with a "unknown" protocol.

It handles the bug where if you were working with an IR file in RMIR, and you'd go to close the file, it would corrupt your file when you went to X out of the program and accidentally clicked on Yes to save the file.

It also has an enhancement to RMIR, where if you create a duplicate Setup ID, that it prompts you to change the setup code to be a unique ID before you add the upgrade.

It has improved PID handling for using alternate PIDs.

Nice job Graham.

[MikeT]

A prototype RDF for the URC-7962 SmartControl Motion is also included in the Beta 1.5v package.

I transferred my URC-7960 configuration to the URC-7962 remote.

The following 3 devices are working:
Sony TV and Sony Blu-Ray Player: PID 0027:new (Sony Combo12/15/20)
AppleTV remote: PID 01E0 Apple (Official)

The other 3 devices are not working using the downloaded configuration:
Sky S HD 3 (Humax PR-HD 3000C): PID 01A2:2 (URC-7960 was using 01A2)
Denon AVR3300: PID 009C Denon Combo (Official)
Fujitsu Activy Media Center: PID 0173 Nokia32 (Custom) => no such protocol for the URC-7962

Learned Keys show an error because the format is not recognized.

I didn't dig any deeper right now.

EDIT:
Denon AVR3300: Works with setup code AMP 2857, but I don't know which protocol or parameters this uses

Michael

[mathdon]

Learned Keys show an error because the format is not recognized.

Could you elaborate on this? Not recognised by RMIR (what message does it show) or by the remote (how do you know)? If you post a .rmir download from the 7960 or 7962, or both, perhaps I can figure this out.

[MikeT]

Not recognised by RMIR (what message does it show) or by the remote (how do you know)? If you post a .rmir download from the 7960 or 7962, or both, perhaps I can figure this out.

I uploaded four files in the diagnostic area:
my_URC_7962_Learned.rmir and my_URC_7960_Learned.rmir contain the learned signals.
The other two files contain the configuration without learned signals. When the config my_URC_7962.rmir is loaded, I can learn the keys, but when downloading the config from the remote, the list of learned keys is empty in RMIR.

Michael

[mathdon]

Thanks, Mike. There are two extra bytes at the start of the learned signal, compared to the normal format, that are disrupting the parsing by RMIR. I will investigate, but probably won't have time for a day or two.

[MikeT]

There are two extra bytes at the start of the learned signal, compared to the normal format

I started the comparison of some signals from the hex bytes which are displayed in the "Learned Signal Detail Editor":

Code: Select all

7962:
29 92 1E 1C 00       01 2A       04 01 80 4F 71 06 00 01 CC 03 00 01 C7 01 80 01 C4 8D 13 33 33 33 23 33 00 FF
2A 92 1E 1C 00       01 2B       04 01 80 4D AF 06 00 01 C6 03 00 01 C4 01 80 01 C3 8D 12 33 33 33 23 33 00 FF
2B 92 1E 1C 00       01 2B       04 01 80 4D AF 06 00 01 C6 03 00 01 C4 01 80 01 C3 8D 13 23 33 33 23 33 00 FF
2C 92 1E 1C 00       01 2B       04 01 80 4B EE 06 00 01 C6 03 00 01 C4 01 80 01 C3 8D 12 23 33 33 23 33 00 FF
15 92 44 42 00       01 2C       08 01 61 4D 34 01 70 48 76 00 C0 27 95 05 F0 01 D2 02 F0 01 D3 00 40 04 E7 01 60 01 E7 00 90 02 DB 39 25 76 60 36 64 64 44 46 66 13 66 46 44 44 66 61 36 64 64 44 46 66 13 66 46 44 44 66 60 FF

7960:
29 92 1B    00 C7 04 01 2A 35 2C 04 AA 01 36 02 55 01 31 01 2A                01 2F 8D 13 33 33 33 23 33 00
2A 92 1B    00 C8 04 01 2C 33 FD 04 B0 01 30 02 58 01 2E 01 2C                01 2D 8D 12 33 33 33 23 33 00
2B 92 1B    00 C8 04 01 2C 33 FD 04 B0 01 30 02 58 01 2E 01 2C                01 2D 8D 13 23 33 33 23 33 00
2C 92 1B    00 C8 04 01 2C 32 D0 04 B0 01 30 02 58 01 2E 01 2C                01 2D 8D 12 23 33 33 23 33 00
15 92 1B    00 C8 04 01 2C 30 77 04 B0 01 30 02 58 01 2E 01 2C                01 2D 8D 13 32 32 22 23 33 00

At Offset 3 there is an additional length field and a 0xFF terminator at the end. The other parts look also different.

I will investigate, but probably won't have time for a day or two.

Learning the keys is really not that urgent. I think it is more important to get all protocols working.

Michael

[mathdon]

Apart from the additional length field and terminating 0xFF, the other changes are to the units in which various items are measured. For the first signal:

Code: Select all

For 7962, 01 2A is carrier period as a multiple of the 12MHz system clock period, ie 298/12 = 24.83us
For 7960, 00 C7 is carrier period as a multiple of the 8MHz system clock period, ie 199/8 = 24.87us

For 7962, 01 80 is a burst pair ON time in units of (carrier period)/16, ie 0x18 carrier periods or 24*24.83=596us
For 7960, 01 2A is the same burst pair ON time in units of 2us, ie 298*2=596us

For 7962, 4F 71 is a burst pair OFF time in units of (12MHz system clock period)*16 = 4/3 us, ie 20337*4/3=27116us
For 7960, 35 2C is the same burst pair OFF time in units of (8MHz system clock period)*16 = 2us, ie 13612*2=27224us

I'm not sure if the final 0xFF is a padding byte to pad to an even number of bytes, or is needed to mark the end of the signal. Padding bytes have usually been 00 so it may be a terminator mark, but like the additional length field, it is a bit of a puzzle as these both seem redundant. A change of timing units makes some sense, but adding these new bits when the old format worked perfectly well seems strange.

[3FG]

I've been looking at the segments in the ARXX12G (very similar to the XSight Lite) and most of the pad bytes are 0xFF. IRScope doesn't recognize learned signals from it, so it probably also has a different learned format. This is a MAXQ622 (USB) processor.

[MikeT]

I'm not sure if the final 0xFF is a padding byte to pad to an even number of bytes, or is needed to mark the end of the signal

The 0xFF together with the second length makes sense where there could be more than one block for a single key, then instead of the 0xFF there would be the next length and 0xFF marks the end.

The remaining question is how to know the clock frequency of the remote:
a) the two unknown bytes of the GetInfo response (03 15 instead of 02 14 or other values)
b) the remote type (JP3 instead of JP2 or JP1.x)
c) the signature of the remote or some of it's digits
d) the length of the learned block
e) offset 3 is != 0

Michael