JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

HUMAX iHD-FOX C (KabelBW - Germany)
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> Slingbox
View previous topic :: View next topic  
Author Message
alanrichey
Expert


Joined: 24 Mar 2008
Posts: 3529
Location: UK/USA

                    
PostPosted: Mon Mar 05, 2012 6:40 pm    Post subject: Re: HUMAX iHD-FOX C (KabelBW - Germany) Reply with quote

eferz wrote:
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.
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3367

                    
PostPosted: Mon Mar 05, 2012 6:43 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
bnordman



Joined: 04 Mar 2012
Posts: 17
Location: OH / USA

                    
PostPosted: Mon Mar 05, 2012 6:59 pm    Post subject: Reply with quote

The Robman wrote:
bnordman wrote:
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.
Back to top
View user's profile Send private message AIM Address
eferz
Expert


Joined: 03 Jun 2010
Posts: 1078
Location: Austin, Texas

                    
PostPosted: Mon Mar 05, 2012 7:48 pm    Post subject: Reply with quote

alanrichey wrote:
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 wrote:
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.

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

3FG wrote:
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.

Ruwido Press Release wrote:
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.”

_________________
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL

                    
PostPosted: Mon Mar 05, 2012 10:04 pm    Post subject: Reply with quote

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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
eferz
Expert


Joined: 03 Jun 2010
Posts: 1078
Location: Austin, Texas

                    
PostPosted: Mon Mar 05, 2012 11:29 pm    Post subject: Reply with quote

The Robman wrote:
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.

The Robman wrote:
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.
_________________
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3367

                    
PostPosted: Tue Mar 06, 2012 4:19 am    Post subject: Reply with quote

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:
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.
Back to top
View user's profile Send private message
eferz
Expert


Joined: 03 Jun 2010
Posts: 1078
Location: Austin, Texas

                    
PostPosted: Tue Mar 06, 2012 11:27 am    Post subject: Reply with quote

3FG wrote:
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?

3FG wrote:
The RDF that Rob was using is newer than, and I believe better than, the RDF with the 1.5q distribution.
Code:
[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.
_________________
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL

                    
PostPosted: Tue Mar 06, 2012 11:55 am    Post subject: Reply with quote

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?
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3367

                    
PostPosted: Tue Mar 06, 2012 11:58 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
eferz
Expert


Joined: 03 Jun 2010
Posts: 1078
Location: Austin, Texas

                    
PostPosted: Tue Mar 06, 2012 12:52 pm    Post subject: Reply with quote

3FG wrote:
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.

The Robman wrote:
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.


3FG wrote:
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.
_________________
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3367

                    
PostPosted: Tue Mar 06, 2012 1:21 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL

                    
PostPosted: Tue Mar 06, 2012 1:23 pm    Post subject: Reply with quote

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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
eferz
Expert


Joined: 03 Jun 2010
Posts: 1078
Location: Austin, Texas

                    
PostPosted: Tue Mar 06, 2012 1:44 pm    Post subject: Reply with quote

The Robman wrote:
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.
_________________
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)
Back to top
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7073
Location: Florida

                    
PostPosted: Tue Mar 06, 2012 1:55 pm    Post subject: Reply with quote

The Robman wrote:
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.
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> Slingbox All times are GMT - 5 Hours
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
Page 3 of 8

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control