There is other length info in a learned signal that allows for several blocks of data, see the example given in this post . It seems to me that this, together with the overall length of the segment, is sufficient but perhaps there is some new extension that we haven't seen that does need the new length bytes.
I suspect, but haven't yet checked, that JP2 may use the new learned format too. My testing of learned signals with segmented remotes was only on JP1.4. I sort of assumed that JP2 would be the same. But in any case, I think the remote type (JP3, or both JP3 and JP2) is sufficient to distinguish between the old and new learned formats, including the relevant clock frequency.
RM/RMIR v2.02 Beta now available!
Moderator: Moderators
It looks like there are three learned formats. Besides the standard format, we have for the MAXQ612 (URC-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
and for the MAXQ622 (Xsight Lite/ARRX12G):
54 05 30 00 01 38 06 01 51 17 A7 01 50 74 44 15 70 0D 1F 15 70 06 A2 01 50 04 F1 01 50 01 AB 22 25 54 55 55 54 45 44 44 44 55 54 55 55 44 45 44 41 82 30 FF
The MAXQ612 adds a seemingly redundant length word, and the MAXQ622 changes the length specifier from the standard byte to a word.
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
and for the MAXQ622 (Xsight Lite/ARRX12G):
54 05 30 00 01 38 06 01 51 17 A7 01 50 74 44 15 70 0D 1F 15 70 06 A2 01 50 04 F1 01 50 01 AB 22 25 54 55 55 54 45 44 44 44 55 54 55 55 44 45 44 41 82 30 FF
The MAXQ612 adds a seemingly redundant length word, and the MAXQ622 changes the length specifier from the standard byte to a word.
I have found by experiment some more info about the MAXQ612 learning format. Here are two complete learning segments:
00 34 09 FF 39 2D 2C 00 01 36 06 01 21 04 FF 04 A0 01 6E 02 60 02 B9 02 60 01 60 01 20 02 CA 01 20 01 71 0E 14 52 35 54 34 35 40 8E 14 52 53 54 34 53 40 FF
00 34 09 FF 39 2E 2D 00 01 36 06 01 21 04 FF 04 A0 01 6E 02 60 02 B9 02 60 01 60 01 20 02 CA 01 20 01 71 0E 14 52 34 55 55 25 20 8F 14 52 52 55 55 35 45 00
Both segments have the same length, 0x34, but the new length byte marked in red differs. The first one has this byte as 2C and a final FF after the normal signal end, the second has this byte as 2D and no final FF. So the FF, when present, is a padding byte and the true end of the signal is determined by the new length byte. I thought at first that it might be a two-byte little-endian length, 2C 00 and 2D 00 in these examples, but the length makes more sense if it is a single length byte and the following 00 is a new, as yet unknown, part of the signal. The length byte is then exactly the number of signal bytes, including the new 00 and excluding the padding FF if present.
The first of the six burst pair timings, marked in blue, shows another new feature. In the old learning format these burst pairs split as two 2-byte values, so 0x0121 would be the ON time and 0x04FF the OFF time. I assumed this and deduced that the ON time was in units of (carrier period)/16, which seemed rather strange but it gave the right values. This example, from the timings that it actually generates as shown by IRScope, reveals that it now splits as a 3-nibble ON time of 0x012 in units of the carrier period and a 5-nibble OFF time of 0x104FF in units, as in the earlier post, of (system clock period)/16, ie of 4/3 us.
Dave, you took your 7962 data from Mike's post which in turn took it from the signal data area of RMIR's Learned Signal Details. The first three bytes are spurious, they are RMIR constructing a JP1.x-style 3-byte header and prefixing it to what it has parsed as the signal data. The true complete segment, with the standard header up to the segment flags in brackets, is
(00 24 09 FF) 39 29 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
and assuming your MAXQ922 data is the part that follows the segment flags FF, the format seems the same as the MAXQ612. It would mean that for your MAXQ622 signal, 54 is the button number of the device key, 05 is that of the key generating the signal, 30 is the new length byte (which is the correct length) and 00 is the new, unknown, first signal byte.
00 34 09 FF 39 2D 2C 00 01 36 06 01 21 04 FF 04 A0 01 6E 02 60 02 B9 02 60 01 60 01 20 02 CA 01 20 01 71 0E 14 52 35 54 34 35 40 8E 14 52 53 54 34 53 40 FF
00 34 09 FF 39 2E 2D 00 01 36 06 01 21 04 FF 04 A0 01 6E 02 60 02 B9 02 60 01 60 01 20 02 CA 01 20 01 71 0E 14 52 34 55 55 25 20 8F 14 52 52 55 55 35 45 00
Both segments have the same length, 0x34, but the new length byte marked in red differs. The first one has this byte as 2C and a final FF after the normal signal end, the second has this byte as 2D and no final FF. So the FF, when present, is a padding byte and the true end of the signal is determined by the new length byte. I thought at first that it might be a two-byte little-endian length, 2C 00 and 2D 00 in these examples, but the length makes more sense if it is a single length byte and the following 00 is a new, as yet unknown, part of the signal. The length byte is then exactly the number of signal bytes, including the new 00 and excluding the padding FF if present.
The first of the six burst pair timings, marked in blue, shows another new feature. In the old learning format these burst pairs split as two 2-byte values, so 0x0121 would be the ON time and 0x04FF the OFF time. I assumed this and deduced that the ON time was in units of (carrier period)/16, which seemed rather strange but it gave the right values. This example, from the timings that it actually generates as shown by IRScope, reveals that it now splits as a 3-nibble ON time of 0x012 in units of the carrier period and a 5-nibble OFF time of 0x104FF in units, as in the earlier post, of (system clock period)/16, ie of 4/3 us.
Dave, you took your 7962 data from Mike's post which in turn took it from the signal data area of RMIR's Learned Signal Details. The first three bytes are spurious, they are RMIR constructing a JP1.x-style 3-byte header and prefixing it to what it has parsed as the signal data. The true complete segment, with the standard header up to the segment flags in brackets, is
(00 24 09 FF) 39 29 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
and assuming your MAXQ922 data is the part that follows the segment flags FF, the format seems the same as the MAXQ612. It would mean that for your MAXQ622 signal, 54 is the button number of the device key, 05 is that of the key generating the signal, 30 is the new length byte (which is the correct length) and 00 is the new, unknown, first signal byte.
Graham
By loading your files my_URC_7960.rmir and my_URC_7962.rmir into these remotes and looking at the signals with IRScope, it seems that the Denon AVR3300 does not work with your Tuner/1177 setup code as the Device code is 0 instead of 2. You can use the Functions tab of the Device Upgrade Editor to change this value. I can't see why the Sky S HD 3 does not work because the 7960 and 7962 send the same signals in the MCE protocol. Are you quite sure that it doesn't work? This protocol has a toggle bit, so the first press may not work if the toggle is out of sync with the device. The Nokia32 protocol, PID=0173, is more of a problem. We don't have a MAXQ code for this protocol. Since your remote is new, why not contact UEI to get an official upgrade for your Fujitsu Activity Media Center, from which we can get the protocol.MikeT wrote: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
Graham
Yes, 54 is the virtual device number, and 05 is the bound button number. I've only tried one group of learned signals (NEC1, device 4), and all of these learns were the same length, and of course all have a pad byte.It would mean that for your MAXQ622 signal, 54 is the button number of the device key, 05 is that of the key generating the signal, 30 is the new length byte (which is the correct length) and 00 is the new, unknown, first signal byte.
I have checked to see if adding a soft key name to the learned signal might trigger a new block of information in the learned signal format, and it does not. Soft key names are instead stored in a 0A segment.
After I almost finished my mail to OFA, I noticed, that the code cable/0858 is supported which also uses the Nokia32 protocol. In the protocol list of the RDF, there is a 0173:1 entry, but this variant is not known in protocols.ini, so it is not listed and can not be selected in RemoteMaster. Therefore I thought is not supported.mathdon wrote:The Nokia32 protocol, PID=0173, is more of a problem. We don't have a MAXQ code for this protocol. Since your remote is new, why not contact UEI to get an official upgrade for your Fujitsu Activity Media Center, from which we can get the protocol.
I added the following entry to protocols.ini:
Code: Select all
[Nokia32]
PID=01 73
VariantName=1
DevParms=Device,Sub Device,X,High X-bit:Constant|Toggle|Release
DeviceTranslator=Translator(3,8,0) Translator(0,8,8) Translator(1,8,16) Translator(2,8,24)
FixedData=00 00 00 00
CmdParms=OBC=0
CmdTranslator=Translator()
Code.MAXQ610=35 6f 41 96 00 05 06 00 0a 00 06 00 10 00 06 00 16 00 06 00 1c 00 b5 0c 0f 00 0a 00 00 84 00 00 00 01 0c 56 0c d0 01 56 08 e0 01 17 d3 d3 80 c3 54 c4 80 71 72 73 74 1c 56 1c ba 01 16 95 95 cf 16 96 96 1f 55 0c d0 02 15 bb bb 01 57 08 00 00 15 12 12 80I don't understand most of the RDF parameters, so I just copied the original Nokia32 entry and adapted VariantName and Code.MaxQ610. What is the difference between 0173 and 0173:1?
Michael
I think nearly all UEI executors are 0173:1. A couple of Kameleon HCS08 remotes (URC-8204 and 8206, I think) are 0173:2.
I don't really understand how RMIR reads in entries in protocols.ini, but judging from rmaster.err (which has a lot of startup logging), if RMIR doesn't recognize the variant of an executor, it tries to use one which is listed. So I experimented using my 1056B03 (a MAXQ processor) and RMIR didn't display Nokia32 in the protocols list. I added the Code.MAXQ610=35 6f.... line you've supplied to the existing Nokia32 0173 entry, and RMIR now displays Nokia32. So I think we only need to add the one line rather than adding an entire entry for variant 1.
I don't really understand how RMIR reads in entries in protocols.ini, but judging from rmaster.err (which has a lot of startup logging), if RMIR doesn't recognize the variant of an executor, it tries to use one which is listed. So I experimented using my 1056B03 (a MAXQ processor) and RMIR didn't display Nokia32 in the protocols list. I added the Code.MAXQ610=35 6f.... line you've supplied to the existing Nokia32 0173 entry, and RMIR now displays Nokia32. So I think we only need to add the one line rather than adding an entire entry for variant 1.
RMIR v2.02 Beta does not work with URC-8820BC1-SA-R
RMIR v2.02 Beta does not work with URC-8820BC1-SA-R.
I have used RMIR with Cox 7820 remotes without any problems. Upgraded to Cox Whole Home DVRs and received replacement remotes with Sticker in battery compartment: C113901 URC-8820BC1-SA-R. The Cox tech who installed my Whole Home DVRs told me that Cox is now only giving out this remore with all their DVRs.
Bought and received Tommy's new JP1.2-4 Flash Interface Cable and 5-Pin Adapter.
A few days ago I downloaded the latest Beta and RDFs that I could find for my remote. Remote master info:
RemoteMaster v2.02 Beta DecodeIR version 2.43
Interfaces:
• JP1.X Serial version 0.20 Beta
• JP1 USB version 0.031
• JP1 Parallel version 0.02
System Properties:
• java.version = "1.6.0_10"
• java.vendor = "Excelsior, LLC"
• os.name = "Windows XP"
• os.arch = "x86"
Problem: The only thing that works is raw data download.
Raw Data:
F800: 30 CF 00 10 00 FF 02 00 00 03 2A FF 01 01 01 01
So there is no valid Signature.
Ran JP2Sniffer.exe and did Begin Comm; GetInfo; GetSigBlk [62CC] and the Signal Block displayed was:
00 2E 00 32 35 33 36 30 32 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 08 00 62 CB 62 F8 F7 FF F8 00 FF FF 02 00 FF FF FF FF E7
The data 32 35 33 36 30 32 is 253602 as it should be.
Steps that I used:
1) Plug remote cable into USB port and wait until your Flash Interface’s LED stops blinking.
2) Start JP2Sniffer.exe
3) Select USB port from “Select COM port” window
4) Click on “Low Level” tab
5) Click Begin Comm button
6) Click GetInfo button then 62CC will appear in box to right of GetSigBlk button
7) Click GetSigBlk button and Signal Block info shown above was displayed.
Do you need more information? What do you suggest I do?
I have used RMIR with Cox 7820 remotes without any problems. Upgraded to Cox Whole Home DVRs and received replacement remotes with Sticker in battery compartment: C113901 URC-8820BC1-SA-R. The Cox tech who installed my Whole Home DVRs told me that Cox is now only giving out this remore with all their DVRs.
Bought and received Tommy's new JP1.2-4 Flash Interface Cable and 5-Pin Adapter.
A few days ago I downloaded the latest Beta and RDFs that I could find for my remote. Remote master info:
RemoteMaster v2.02 Beta DecodeIR version 2.43
Interfaces:
• JP1.X Serial version 0.20 Beta
• JP1 USB version 0.031
• JP1 Parallel version 0.02
System Properties:
• java.version = "1.6.0_10"
• java.vendor = "Excelsior, LLC"
• os.name = "Windows XP"
• os.arch = "x86"
Problem: The only thing that works is raw data download.
Raw Data:
F800: 30 CF 00 10 00 FF 02 00 00 03 2A FF 01 01 01 01
So there is no valid Signature.
Ran JP2Sniffer.exe and did Begin Comm; GetInfo; GetSigBlk [62CC] and the Signal Block displayed was:
00 2E 00 32 35 33 36 30 32 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 08 00 62 CB 62 F8 F7 FF F8 00 FF FF 02 00 FF FF FF FF E7
The data 32 35 33 36 30 32 is 253602 as it should be.
Steps that I used:
1) Plug remote cable into USB port and wait until your Flash Interface’s LED stops blinking.
2) Start JP2Sniffer.exe
3) Select USB port from “Select COM port” window
4) Click on “Low Level” tab
5) Click Begin Comm button
6) Click GetInfo button then 62CC will appear in box to right of GetSigBlk button
7) Click GetSigBlk button and Signal Block info shown above was displayed.
Do you need more information? What do you suggest I do?
Last edited by Jim W on Thu Oct 18, 2012 10:08 am, edited 1 time in total.
I'd like to know what RMIR responds when asked for an ordinary download. Also, using JP2Sniffer, and the High level tab, what is the response to Download from remote?
Are you using this RDF? It is the same as the RDF included in the "base package".
Here's the first sentence of the readme.txt file for JP2Sniffer: How do you think it should be phrased?
Concerning the signature, JP2 remotes don't store the signature at the beginning of E2 memory.
Are you using this RDF? It is the same as the RDF included in the "base package".
Here's the first sentence of the readme.txt file for JP2Sniffer:
Code: Select all
JP2Sniffer must be started after interface cable is plugged into the Computer USB port.Concerning the signature, JP2 remotes don't store the signature at the beginning of E2 memory.
1) I tried 3 different .RDF files and got message: “No RDF matches signature starting [blanks then y with two dots above it]". Will go back and find link to each .RDF file that I tried and the exact results if you want me to. Which .RDF file should I be using? I will try that one.3FG wrote:I'd like to know what RMIR responds when asked for an ordinary download. Also, using JP2Sniffer, and the High level tab, what is the response to Download from remote?
. . .
Are you using this RDF? It is the same as the RDF included in the "base package".
. . .
Here's the first sentence of the readme.txt file for JP2Sniffer:How do you think it should be phrased?Code: Select all
JP2Sniffer must be started after interface cable is plugged into the Computer USB port.
2) JP2Sniffer Download from E2 shows 11 lines of data:
Code: Select all
FF 02 00 00 03 2A FF 01 00 01 01 2C FF
FF 01 00 01 07 55 7F 01 00 01 01 2C FF
FF 03 00 02 02 15 FF 01 00 01 01 2C FF
FF 04 00 03 03 FF FF 01 00 01 01 2C FF
FF 00 04 0E 3A 10 10 10 10 12 13 12 10 13 0F 13 0E 01 00
FF 00 05 01 01
FF 01 00 04 17 18 19 1A 01 07 55 01 05 60 01 0F FF 01 0F FF FF
FF 02 00 04 17 18 19 1A 01 07 55 01 05 60 01 0F FF 01 0F FF FF
FF 03 00 04 17 18 19 1A 01 07 55 01 05 60 01 0F FF 01 0F FF FF
FF 04 00 04 17 18 19 1A 01 07 55 01 05 60 01 0F FF 01 0F FF FF
FF 00 00 0A 1E 0A 08 03 FF FF FF
It appears that while JP2Sniffer is reading the signature correctly, RMIR is not. One possibility is that JP12Serial.dll V.20 Beta is not working correctly with the 8820BC1. Would you mind trying an older version of the DLL, which I believe has been shown to work with the 8820BC1?
Re: RMIR v2.02 Beta does not work with URC-8820BC1-SA-R
You certainly have the latest JP1.X version but not the latest RMIR. You need the latest development version, v2.02 Beta 1.5v to work with this remote.Jim W wrote:RMIR v2.02 Beta does not work with URC-8820BC1-SA-R.
Bought and received Tommy's new JP1.2-4 Flash Interface Cable and 5-Pin Adapter.
A few days ago I downloaded the latest Beta and RDFs that I could find for my remote. Remote master info:
RemoteMaster v2.02 Beta DecodeIR version 2.43
Interfaces:
• JP1.X Serial version 0.20 Beta
• JP1 USB version 0.031
• JP1 Parallel version 0.02
System Properties:
• java.version = "1.6.0_10"
• java.vendor = "Excelsior, LLC"
• os.name = "Windows XP"
• os.arch = "x86"
Graham
Thanks 3FG and mathdon. I've got it working with your posts. Tried 3FG's suggestion and got same result. Saw mathdon's post and when I looked at the files in the .zip I realized that I had 1.5V installed but it didn't show in About.
Renamed dll from 3FG's post and went back to the version that I had been using. Clicked on RemoteMaster.jar. Everything worked and About showed RemoteMaster v2.02 Beta 1.5v.
My error was: I had been using a icon that pointed to "C:\Program Files\www.hifiremote.com\RemoteMaster\RemoteMaster.exe" instead of RemoteMaster.jar.
Update: The Cox DVR firmware has a known bug that causes it to lose the Variable Audio function at power off. Created a macro on Cox 8720 for AUX key that works to circumvent this bug by toggling the Variable Audio setting.
Can set the same key macro in Cox 8820 Remote with RMIR RemoteMaster v2.02 Beta 1.5v but Cox 8820 does not execute AUX key macro. No problems found with RMIR with Cox 8820.
Thanks for the help.
Renamed dll from 3FG's post and went back to the version that I had been using. Clicked on RemoteMaster.jar. Everything worked and About showed RemoteMaster v2.02 Beta 1.5v.
My error was: I had been using a icon that pointed to "C:\Program Files\www.hifiremote.com\RemoteMaster\RemoteMaster.exe" instead of RemoteMaster.jar.
Update: The Cox DVR firmware has a known bug that causes it to lose the Variable Audio function at power off. Created a macro on Cox 8720 for AUX key that works to circumvent this bug by toggling the Variable Audio setting.
Code: Select all
Settings;Down;Down;Down;Down;Right;Right;Right;Down;Select;Up;Select;Exit;CBLThanks for the help.
Last edited by Jim W on Sat Oct 20, 2012 11:15 pm, edited 1 time in total.
-
mr_d_p_gumby
- Expert
- Posts: 1370
- Joined: Sun Aug 03, 2003 12:13 am
- Location: Newbury Park, CA
Variant 1 has an option to send a final frame with bit 7 of the 4th fixed byte toggled (or set in some versions). Variant 2 does not have this function.MikeT wrote:I don't understand most of the RDF parameters, so I just copied the original Nokia32 entry and adapted VariantName and Code.MaxQ610. What is the difference between 0173 and 0173:1?
Mike England
Can program URC-8820BC1 macros with RMIR v2.02 Beta 1.5v
I have found a way to program my URC-8820BC1 with working macros using RMIR v2.02 Beta 1.5v. When the assigned key is pressed, the Cox 8820 sends the IR command sequence to the cable box. I am working on the detailed instructions that I will post and an example file that I will upload to the File Section.