HUMAX iHD-FOX C (KabelBW - Germany)

[alanrichey]

Yes, I am willing to do so. However, I believe that Alan Richey already has submitted a full set already using a widget, "HUMAX iHD-FOX C ict" if you believe a duplicate will help then let me know. For now, I'll see about sampling some keys onto the OARI06G.

I did take another look, in case the Harmony database had been updated, but got the same "unknown", but it is a good idea to get a second data set just in case it is different.

[3FG]

Yes, I believe a second set of learns from a Harmony will be valuable, for two reasons. One is simple minded--perhaps Logitech has a newer set of signals since Alan learned them. Alan did repeated learns of the same function. It's reasonable to expect the Harmony to send the same signal repeatedly, but the learns actually vary significantly.

We really don't expect the number of burst pairs to change for a given function, but they do. That possibly could be an artifact of the Widget, so getting both UEI and Widget learns from the same Harmony remote may provide pretty useful data, since the method of detecting burst pairs is different.

Regarding r-map, there is one post at RC which includes Pronto Hex for one function, and a link to a CCF file which should have lots of functions. I've downloaded that file, but haven't looked at it yet. However, the Pronto Hex for r-map doesn't seem to be similar to the learns we have.

[bnordman]

I have the original remote and can provide any help that I can as a newbie to all of this. Just let me know.

I'm guessing that you don't have any tools that you could use to capture the signals, right? Are you really located in the US, and if so, would you be willing to loan the remote to one of us so we could capture the signals?

Correct, I don't have the right tools and while I am in the US (most of the time), unfortunately the remote control spends it days with the receiver in Germany. I could bring it back on my next trip, but it'll be at least a few weeks until then.

[eferz]

I did take another look, in case the Harmony database had been updated, but got the same "unknown", but it is a good idea to get a second data set just in case it is different.

Yes, I believe a second set of learns from a Harmony will be valuable, for two reasons. One is simple minded--perhaps Logitech has a newer set of signals since Alan learned them. Alan did repeated learns of the same function. It's reasonable to expect the Harmony to send the same signal repeatedly, but the learns actually vary significantly.

We really don't expect the number of burst pairs to change for a given function, but they do. That possibly could be an artifact of the Widget, so getting both UEI and Widget learns from the same Harmony remote may provide pretty useful data, since the method of detecting burst pairs is different.

Fair enough.

• ICT & RMIR files: https://www.hifi-remote.com/forums/dload ... e_id=10787

EDIT v1.1 has been updated to include learns from another IR database.

Regarding r-map, there is one post at RC which includes Pronto Hex for one function, and a link to a CCF file which should have lots of functions. I've downloaded that file, but haven't looked at it yet. However, the Pronto Hex for r-map doesn't seem to be similar to the learns we have.

I believe this is a time where Ruwido has intended to make it harder for Universal Remotes not manufactured by them.

In the r-map ruwido has developed an independent patented infrared protocol permitting several devices to be controlled simultaneously by remote control. r-base comprises a database, compiled over decades, that contains infrared codes of very different manufacturers of entertainment equipment on the market which in some models can be called up by the remote control by USB interface. r-mode contains the collective know-how of the company in the interaction of technology and design, i.e. the shaping and design of user interfaces under consideration of ergonomics, touch, colour perception etc. Finally, all services and solutions for OEM customers are united in r-way. Companies are given access to very different application examples for the implementation of remote controls in their own device environment.

“We will experience a situation in which the traditional cheap remote control will gradually become extinct in the face of the large number of applications and possibilities presented by the digital entertainment world”, of this Ferdinand Maier is certain. “At ruwido we therefore endeavour to track down the latest design and technology trends and in some areas we are even one step ahead. The new generation of remote controls therefore has the potential to advance into the living room as a central CE interface and design element, thereby becoming the best representative of the entertainment electronic brands."

[The Robman]

Which RDF are you using with your OARI06G? When I tried to open the file using RMIR, it couldn't find the RDF, so I downloaded this one but then when I tried to open your file I got lots of errors and no learning section.

Better yet, could you save the files as *.ir files rather than *.rmir as I would need to load them into IR.exe in order to examine them anyway.

[eferz]

Which RDF are you using with your OARI06G? When I tried to open the file using RMIR, it couldn't find the RDF, so I downloaded this one but then when I tried to open your file I got lots of errors and no learning section.

Make sure you're using 1.5q and the included RDFs. As the earlier versions are liable to make Remote Master puke with the RDFs for the JP1.4 & 2.x remotes.

Better yet, could you save the files as *.ir files rather than *.rmir as I would need to load them into IR.exe in order to examine them anyway.

Done but I'm not sure whether or not IR.exe will handle the new remotes properly even with the updated RDFs.

[3FG]

Thanks for the learns. These are considerably easier to work with. I ended up using the UEI learns, because those showed a frequency of 56KHz, which seems more plausible than the 50KHz reported by the Widget.
This is a phase shifting IR protocol, with 4 phases rather than the familiar two phases of bi-phase IR protocols like RC5. Using an arbitrary assignment, we have
IRP is {56k,105, msb}<-2,2|-3,1|1,-3|2,-2>(T=0,(D:14,T:2,F:8,^95m,T=1)+) [D:0..16383, F:0..255]

This means that each signal is sent twice with the toggle set to zero for the first and to 1 for the second.

For these learns, D=12768. (There's not enough information to know if any of this is a start burst, or how the signal should be partitioned in to device, subdevice, OBC, etc.) The following line executed from a command prompt (or through a batch file) will generate the Pronto Hex for volume (F = 38):
java -jar IrpMaster.jar -p -d 1 -o foo.bar -i "{56k,105, msb}<-2,2|-3,1|1,-3|2,-2>(T=0,(D:14,T:2,F:8,^95m,T=1)+) [D:0..16383, F:0..255]" D=12768, F=38

Maybe no one will understand the following, but it's how I split up the bursts.

Code: Select all

VolumeUp : 0000 0049 0012 0000 
      -2    2        2    -2        -2    2                             1   -3    1   -3      
  2   -2        -3   1          1   -3        -2    2   -2    2   -2    2   -3    1         
  2   -4    2   -3   3    -2    1   -5    2   -2    2   -2    2   -2    3   -6    2       
000C 0019 000B 0013 0010 000D 0006 001F 000B 000D 000B 000D 000B 000D 0011 0025 000B 14A3 
000C 0019 000B 0013 0010 000D 0006 001F 000B 000D 000B 0013 0006 000C 0011 0025 000C 6EE8
                                                        -3    1
3013200 0 0212   A=12768  T=0 F=38
2,-2  -2,2  -3,1  2,-2  1,-3  -2,2  -2,2  -2,2  -2,2  1,-3  -3,1  1,-3

BTW, the r-map signals at RC decoded as CanalSat, so this is evidently something else. The RDF that Rob was using is newer than, and I believe better than, the RDF with the 1.5q distribution.

[eferz]

Thanks for the learns. These are considerably easier to work with. I ended up using the UEI learns, because those showed a frequency of 56KHz, which seems more plausible than the 50KHz reported by the Widget.
This is a phase shifting IR protocol, with 4 phases rather than the familiar two phases of bi-phase IR protocols like RC5. Using an arbitrary assignment, we have
IRP is {56k,105, msb}<-2,2|-3,1|1,-3|2,-2>(T=0,(D:14,T:2,F:8,^95m,T=1)+) [D:0..16383, F:0..255]

Awesome! So, can this be turned into a protocol or at least an upgrade?

The RDF that Rob was using is newer than, and I believe better than, the RDF with the 1.5q distribution.

Code: Select all

[root]# grep :2 "329801 (OARI06G One For All 6+3).rdf"
0057, 0058:2, 005A, 005C, 005D, 005E:2, 0065:2, 006A:4, 0073, 007E:5, 0092:3,
0098:2, 009C, 009E, 00A4, 00AF, 00B6, 00C4, 00C9, 00CA, 00CD:2, 00DE,
00E8, 00F0, 00F2, 00F8:3, 0109, 010C, 010F, 0111, 0114:2, 011A:2, 011E,
012A:2, 0161:5, 0162, 016C:2, 0173:1, 0174, 017E, 0184:2, 019C, 01A4:2, 01A5,
[root]# diff "329801 (OARI06G One For All 6+3).rdf" "15q/RDFs/329801 (OARI06G One For All 6+3).rdf"
[root]#

No, not according to diff. They're the same version. If you don't recognize the commands above, I filtered lines with the variants you added in the latest version to prove its authenticity. Then I checked the difference between the one you uploaded and the one included in 1.5q distro. Since there is no response, it indicates the two files are exactly the same. Therefore, axiomatically, neither one is either newer nor better than the other.

[The Robman]

3FG totally nailed the format, furthermore I can add that the 8-bit function code is really a 7-bit function code and the additional bit is a 1-bit checksum (where it is always the complement of the preceding bit).

So, who wants to volunteer to write an executor for this puppy?

[3FG]

Yes, we will be able to write a protocol executor for this. I think it will be small enough for a Slingbox, but I haven't given it much thought yet. There is a small chance that UEI has already written an executor for this IR protocol, but it isn't easy to find them.

Regarding the RDF, I didn't realize that you had incorporated the latest RDF files into the distribution. Just my opinion, but I think we should change the version name/number on a distribution whenever it is changed. At present we are using 1.5q to describe it, but that is actually the version of RMIR, which hasn't changed. It's the other components that have changed. Maybe we should name the distribution package something like RMIR_JP2_ver_a, and bump it whenever some component is changed.

Otherwise, to be sure that her/his software is current, a user would need to check each file date on all of the local files against the last updated date in the file section.

[eferz]

Yes, we will be able to write a protocol executor for this. I think it will be small enough for a Slingbox, but I haven't given it much thought yet. There is a small chance that UEI has already written an executor for this IR protocol, but it isn't easy to find them.

3FG totally nailed the format, furthermore I can add that the 8-bit function code is really a 7-bit function code and the additional bit is a 1-bit checksum (where it is always the complement of the preceding bit).

So, who wants to volunteer to write an executor for this puppy?

Don't look at me. I haven't the foggiest clue in how to even begin.

Regarding the RDF, I didn't realize that you had incorporated the latest RDF files into the distribution. Just my opinion, but I think we should change the version name/number on a distribution whenever it is changed. At present we are using 1.5q to describe it, but that is actually the version of RMIR, which hasn't changed. It's the other components that have changed. Maybe we should name the distribution package something like RMIR_JP2_ver_a, and bump it whenever some component is changed.

Otherwise, to be sure that her/his software is current, a user would need to check each file date on all of the local files against the last updated date in the file section.

Well, it is listed in the description and I believe you were participating in the thread where Mathdon requested them to be added. So, that's what I did. The name or the version was not changed because the actual program didn't change. I only added the files from version 1.2 of the JP1.4 & J2.x support archive as indicated in the description. Again, I only added it as a courtesy to mathdon and gfb107 because they are developing the beta version. It just makes it easier for those involved with beta if there's a common baseline for the support files included with the package. So, really it is up to them in regards to how the distributions of their prototype is presented.

The only reason, I recommend Rob to download the 1.5q package and not just your RDF or the JP1.4 & JP2.x RDF/IMG/MAP compilation is because I've seen the symptoms before. It is indicative of opening an RM or RMIR file for the new remotes with unsupported RDFs with a Remote Master version that does not actually support the new JP1.4 and JP2.x remotes. That's why these RDFs should not be included in an official distribution until the entire project is out of beta.

[3FG]

Rob, I can take a shot at writing an executor. Won't be until tonight, however.

Are all Slingboxes the same in terms of space for executors? Is there a hard limit on the executor size? It does look like the upgrade probably will need just 2 bytes of fixed data and 1 byte of command data, so that will probably be about 36 bytes or so, assuming that there are 34 functions in the upgrade.

[The Robman]

I hadn't realized that you learned the signals using a JP2 remote, so I switched over to using the ICT file as I have a spreadsheet that will convert the UEI export into an IR file format.

The tools that I use to analyse signals only exist in IR.exe.

[eferz]

I hadn't realized that you learned the signals using a JP2 remote, so I switched over to using the ICT file as I have a spreadsheet that will convert the UEI export into an IR file format.

The tools that I use to analyse signals only exist in IR.exe.

I think my OARI06G is actually a JP1.4 remote, whereas the URC-7960 is JP2. Anyways, that's a pretty cool spreadsheet. Who maintains IR Scope? Perhaps we can convince them to include its function as a valid export option.

[vickyg2003]

3FG totally nailed the format, furthermore I can add that the 8-bit function code is really a 7-bit function code and the additional bit is a 1-bit checksum (where it is always the complement of the preceding bit).

So, who wants to volunteer to write an executor for this puppy?

One of the first protocols you had me work on was a quad. I can't find the thread though.

If it can wait until thursday I can do it, or if anyone else wants to cut their teeth on protocol building I can give a hand.