HUMAX iHD-FOX C (KabelBW - Germany)

[bnordman]

for 3)

I tested:
http://www.hifi-remote.com/forums/dload ... e_id=10802

No button performed any visible action at the Kabel (BW) cable box

Okay, that one matches Rob's RMDU for the offical UEI upgrade which I then turned into a bin file.

• RMDU file: http://www.hifi-remote.com/forums/dload ... e_id=10801
• BIN file: http://www.hifi-remote.com/forums/dload ... e_id=10802

I also tested:
http://www.hifi-remote.com/forums/dload ... e_id=10803

Same results, no reaction of the Slingbox.

Am I missing any files that I need to test?

You could not have tested that file because its an ICT file from IR Scope. It is a recording of the IR Signals emitted by my Slingbox and is not compatible with Sling's tools. There's no way it would have uploaded into the Slingbox as the Setup Assistant does not have the capacity to input a filename.

The other two you would try were created by Vicky. Her original "Humax_with_quad_protocol.txt" KM file was transcribed into BIN files by me. However, her revised update replaced the KM file with a PB file named, "Humax_BiPhase_Quad.txt". I can't seem to get RM to work with it as the following syntax error is displayed, "The upgrade you are trying to import is not valid! It does not contain a value for Remote.name"

• KM/PB file: http://www.hifi-remote.com/forums/dload ... e_id=10796
• BIN File: http://www.hifi-remote.com/forums/dload ... e_id=10798

I just tested this one: http://www.hifi-remote.com/forums/dload ... e_id=10798
No reaction.

So at this point, the only open part is the updated file by Vicky which created an error for you, right?

[eferz]

I just tested this one: http://www.hifi-remote.com/forums/dload ... e_id=10798
No reaction.

So at this point, the only open part is the updated file by Vicky which created an error for you, right?

Yes, I believe that is correct.

[The Robman]

Have we tried building a Slingbox file based on the UEI upgrade yet?

[eferz]

Have we tried building a Slingbox file based on the UEI upgrade yet?

I believe so, as we would be referring to the following quote.

for 3) I tested: http://www.hifi-remote.com/forums/dload ... e_id=10802
No button performed any visible action at the Kabel (BW) cable box

Okay, that one matches Rob's RMDU for the offical UEI upgrade which I then turned into a bin file.

• RMDU file: http://www.hifi-remote.com/forums/dload ... e_id=10801
• BIN file: http://www.hifi-remote.com/forums/dload ... e_id=10802

I even loaded it into my own Slingbox Pro-HD and created the following ICT file to verify the signals it creates.

• ICT File: http://www.hifi-remote.com/forums/dload ... e_id=10803

[3FG]

I've uploaded a zip file which contains a protocols.ini fragment, and a class file called BitExpander. This allows the use of RMIR directly, without the need for a manual protocol, and accepts the natural OBCs. It uses the UEI executor, and seems to send IR signals identical to the learns eferz obtained from his Harmony.

Here's the RMDU file (for a RCA RCRP05B--I don't own a Slingbox). Of course this RMDU file won't load unless the above protocols.ini and class file have been incorporated.

[vickyg2003]

I even loaded it into my own Slingbox Pro-HD and created the following ICT file to verify the signals it creates.

• ICT File: http://www.hifi-remote.com/forums/dload ... e_id=10803

I think this last post might give us something to look at. I was working on this the other day, but it wasn't until I got this latest ICT that things started to make sense.
The first power button was the one that we've been working from that earl captured.
The second is the Official UEI shot from a URC-6131
The third one is my upgrade
The fourth is the first slow set of captures
The fifth is the Official UEI shot from the slingbox.

So the second one and the fifth one should match, because they are the same upgrade shot from the s3c8+ processor.



Uploaded with ImageShack.us

I think that maybe the frequency or timings for the official might need to be tweaked slightly for the slingbox, what do you guys think?

Oh and I also saw that I overwrote my km upgrade with the protocol builder file, will fix, but what about those two new functions, were those real obcs or modified obcs?

[The Robman]

what about those two new functions, were those real obcs or modified obcs?

The small numbers in front are the real OBCs, the larger numbers in brackets are the fake OBCs that follow your "times 2 and add 1 if even" rule. Sorry I didn't spell that out, I thought it was obvious.

29 Delete (58)
45 E-Mail (90)

[3FG]

Vicky,
Unfortunately, we are at the edge of the Widget's capability. This particularly applies to the frequencies it displays. The shortest On duration is 105uSec for the Humax IR protocol. However, I think Kevin's comment that 200uSec of On time as being the absolute minimum duration** is probably conservative for most waveforms, because the Off duration also is important. In the Humax case, the shortest off duration expected is 211uSec. If it were shorter than 200uSec, we'd surely be getting some errors. As it is, the Widget (and accompanying software) is reporting erroneous frequencies.

A typical IR signal on burst is modulated (rapidly turned on and off) at 38KHz. This particular signal is modulated at 56.9KHz***. The Widget counts the number of modulations that occur within 100uS, and reports this for every 100uS period. Since the shortest on burst lasts for 6 modulations (105uS), the Widget will usually see two consecutive 100uS periods with modulations distributed 1/5 or 2/4 or 3/3 or 4/2 or 5/1. Sometimes, either it or the sending remote will mess up a bit, and see a single 100uS period with 5 modulations.

Bottom line: If we want to see these IR signals in detail, learning into a UEI remote will have advantages, at least in determining frequency, and probably in measuring the durations.

I'll take a look at IRScope to see if we can use more of the recorded signal, and get a better estimate of frequency. Edit: IRScope is already doing the best it can with these signals. It finds all the 100uS or longer intervals for which the IR was on during the entire interval, adds up all the transitions and durations of those intervals, and computes the frequency. The issue here is that the longest such interval is 100uS, because the longest On duration is 211 uSec. During one 100uS interval, a 57KHz signal will show 5 transitions, which would compute to 50.000KHz. If the remote wanders 5% in frequency, 6 transitions are possible, corresponding to 60.000KHz. In Earl's first learns for the Harmony, the calculated frequency was always 50KHz. Subsequent learns evidently have some instances of 6 transitions, and the average frequency is calculated to be a little higher than 50KHz. By comparison, a UEI S3F80 remote can in principle measure frequencies to a fraction of 1KHz. One of the counters has a 0.125 uS period.

**I assume that he based that statement on the Nyquist theorem which states that one has to sample at twice the frequency of the highest frequency to be observed in a signal, but the sampling approach in the Widget is more complex than assumed in the theorem, and it should be somewhat better.

***37.9KHz is 455KHz divided by 12, and 56.9KHz is 455KHz divided by 8. A long time ago, somebody started using 455KHz filters in AM radios, and it is just about the cheapest frequency to make, because of economy of scale. Of course it isn't necessary to to make IR operate at these frequencies, but most equipment does.

[binky123]

I'm not sure if it is relevant here but I recall that johnsfine concluded that the original slingbox was running 2.5% slower than in the Dreambox remote(HCS08) when shooting the XMP protocol. This was way back when we first started learning about the XMP protocol and people wanted to control their Dreambox STBs with the slingbox.

[eferz]

Bottom line: If we want to see these IR signals in detail, learning into a UEI remote will have advantages, at least in determining frequency, and probably in measuring the durations.

Here are the learns from an OARI06G of the Slingbox Pro-HD with the HUMAX iHD-FOX C (UEI) from Rob installed.

• RMIR File: http://www.hifi-remote.com/forums/dload ... e_id=10808

I've uploaded a zip file which contains a protocols.ini fragment, and a class file called BitExpander. This allows the use of RMIR directly, without the need for a manual protocol, and accepts the natural OBCs. It uses the UEI executor, and seems to send IR signals identical to the learns eferz obtained from his Harmony.

Here's the RMDU file (for a RCA RCRP05B--I don't own a Slingbox). Of course this RMDU file won't load unless the above protocols.ini and class file have been incorporated.

I installed BitExpander into RemoteMaster.jar (1.5r) and the respective protocol.ini excerpt. Transcribed your RMDU for the RCRP05B to the Slingbox and exported its bin files. Afterwards, I installed the bins into my Slingbox then recorded the signals using my OARI06G and the IR Widget. The following files are referenced below.

• RMIR/ICT file: http://www.hifi-remote.com/forums/dload ... e_id=10809
• RMDU file: http://www.hifi-remote.com/forums/dload ... e_id=10810
• BIN files: http://www.hifi-remote.com/forums/dload ... e_id=10811

BIN file Instructions.

• Mac: http://support.slingbox.com/get/KB-1000223.html
• PC: http://support.slingbox.com/get/KB-1000218.html

Customization instructions:

• http://slingbox.wikia.com/wiki/How_to_c ... te_upgrade

[vickyg2003]

I gather that to open the OARRI06G I need to have the experimental version of RMIR and the new RDF. I think I can find the RMIR, but I looked in the RDF folders and can't find anything for this remote.

Also never heard of BitExpander, but I admit that I haven't been very active in a while.

I learned a great deal from your Sling ICT files though. I was under the impression that there wasn't a hold capability on the slingbox, and that if the protocol like this one was being sent, the hold test would fail, but in this case the hold is being detected and there are three frames from the official upgrade, even though when reading the code I expected that only the first frame would be sent because subsequent frames are subject to the hold test.

The ICTs from the OARI06G are a perfect, but I don't know why we asked for them, as the ICTs from the slingbox clearly showed that the slingbox is shorting us on blinks for the various pulses.

I'm not sure if it is relevant here but I recall that johnsfine concluded that the original slingbox was running 2.5% slower than in the Dreambox remote(HCS08) when shooting the XMP protocol. This was way back when we first started learning about the XMP protocol and people wanted to control their Dreambox STBs with the slingbox.

I think this is relevant. I'm not quite sure if "slower" means I need to speed up the frequency or increase the timings.

Earl, I sped up the frequency on the UEI official protocol. Could you download this file, and record the Power button from your sling into an ICT.
http://www.hifi-remote.com/forums/dload ... e_id=10812

[bnordman]

BIN files: http://www.hifi-remote.com/forums/dload ... e_id=10811

I just uploaded this to my slingbox in Germany and tested it.
The following buttons work:

• Power (on/off)
• Guide
• Exit
• Channel Up/Down
• Info
• Menu
• 0-9
• Last
• Up/down/left/right/enter
• Color buttons

My cable receiver doesn't have a DVR function, so I can't test the associated buttons.

Thank you for this. This is FANTASTIC WORK.

Let me know if there is anything else I should test.

[eferz]

I gather that to open the OARRI06G I need to have the experimental version of RMIR and the new RDF. I think I can find the RMIR, but I looked in the RDF folders and can't find anything for this remote.

Here are the necessary downloads to support the JP1.4 & JP2.x remotes:

• Prototype RM/RMIR support for JP1.4/JP2 (2.02 Beta 1.5r)
• JP1.4 & JP2.x RDFs, Maps, and Images for Prototype RM/RMIR (V 1.3)

Also never heard of BitExpander, but I admit that I haven't been very active in a while.

Until a few posts up, I haven't heard about it either. Don't feel bad. I just walked through the motions as directed and had no idea why.

I learned a great deal from your Sling ICT files though. I was under the impression that there wasn't a hold capability on the slingbox, and that if the protocol like this one was being sent, the hold test would fail, but in this case the hold is being detected and there are three frames from the official upgrade, even though when reading the code I expected that only the first frame would be sent because subsequent frames are subject to the hold test.

I thought this was explained as to why Alan prefers to have a non-repeat protocol for his Slingbox bins. The Slingplayer UI treats a button press on the SlingRemote as if it was held down for a brief period to emit extra frames, regardless of it was actually held down or tapped. This often results in excessive repeats especially with the NEC protocols.

The ICTs from the OARI06G are a perfect, but I don't know why we asked for them, as the ICTs from the slingbox clearly showed that the slingbox is shorting us on blinks for the various pulses.

According to 3FG above, the frequency used by this protocol is near the upper limit of the IR Widget's capabilities. So, I have included both learns from the IR Widget (ICT) as well as the OARI06G (RMIR) just so I can satisfy everyone's theory/needs.

I think this is relevant. I'm not quite sure if "slower" means I need to speed up the frequency or increase the timings.

Earl, I sped up the frequency on the UEI official protocol. Could you download this file, and record the Power button from your sling into an ICT.
http://www.hifi-remote.com/forums/dload ... e_id=10812

Transcribed your RMDU for the Slingbox (RV) to the Slingbox (PL) and exported its bin files. Afterwards, I installed the bins into my Slingbox then recorded the signals using my OARI06G and the IR Widget. The following files are referenced below.

• RMIR/ICT file: http://www.hifi-remote.com/forums/dload ... e_id=10813
• RMDU file: http://www.hifi-remote.com/forums/dload ... e_id=10814
• BIN files: http://www.hifi-remote.com/forums/dload ... e_id=10815

BIN file Instructions.

• Mac: http://support.slingbox.com/get/KB-1000223.html
• PC: http://support.slingbox.com/get/KB-1000218.html

Customization instructions:

• http://slingbox.wikia.com/wiki/How_to_c ... te_upgrade

[vickyg2003]

I gather that to open the OARRI06G I need to have the experimental version of RMIR and the new RDF. I think I can find the RMIR, but I looked in the RDF folders and can't find anything for this remote.

Here are the necessary downloads to support the JP1.4 & JP2.x remotes:

• Prototype RM/RMIR support for JP1.4/JP2 (2.02 Beta 1.5r)
• JP1.4 & JP2.x RDFs, Maps, and Images for Prototype RM/RMIR (V 1.3)

Also never heard of BitExpander, but I admit that I haven't been very active in a while.

Until a few posts up, I haven't heard about it either. Don't feel bad. I just walked through the motions as directed and had no idea what I was doing.

Thanks for the info.

I learned a great deal from your Sling ICT files though. I was under the impression that there wasn't a hold capability on the slingbox, and that if the protocol like this one was being sent, the hold test would fail, but in this case the hold is being detected and there are three frames from the official upgrade, even though when reading the code I expected that only the first frame would be sent because subsequent frames are subject to the hold test.

I thought this was explained as to why Alan prefers to have a non-repeat protocol for his Slingbox bins. The Slingplayer UI treats a button press on the SlingRemote as if it was held down for a brief period to emit extra frames, regardless of it was actually held down or tapped. This often results in excessive repeats especially with the NEC protocols.

Nope that's a single jump to xmiter which does a minimum repeat of 3. That works the same for a remote or a slingbox. In this case there is no minimum repeate. Instead thre is a call to the button hold subroutine. If you did a minimum tap on a remote you wouldn't get any repeats. Since there is no "hold" on a slingbox, I wouldn't have expected the sling to send any repeats, instead it found the hold condition to be true for 2 tests. That is not what I thought a slingbox did, so this was a real valuable eduction for me.

I think this is relevant. I'm not quite sure if "slower" means I need to speed up the frequency or increase the timings.

Earl, I sped up the frequency on the UEI official protocol. Could you download this file, and record the Power button from your sling into an ICT.
http://www.hifi-remote.com/forums/dload ... e_id=10812

Transcribed your RMDU for the Slingbox (RV) to the Slingbox (PL) and exported its bin files. Afterwards, I installed the bins into my Slingbox then recorded the signals using my OARI06G and the IR Widget. The following files are referenced below.

• RMIR/ICT file: http://www.hifi-remote.com/forums/dload ... e_id=10813
• RMDU file: http://www.hifi-remote.com/forums/dload ... e_id=10814
• BIN files: http://www.hifi-remote.com/forums/dload ... e_id=10815

BIN file Instructions.

• Mac: http://support.slingbox.com/get/KB-1000223.html
• PC: http://support.slingbox.com/get/KB-1000218.html

Customization instructions:

• http://slingbox.wikia.com/wiki/How_to_c ... te_upgrade

Thanks, but I don't think we need this anymore. bnordman already found that a previous version worked.

BIN files: http://www.hifi-remote.com/forums/dload ... e_id=10811

I just uploaded this to my slingbox in Germany and tested it.
The following buttons work:

So now I'm really confused as to what is going on here, because I thought the 10811 file (bitex version) was just the rehash of another rdmu with the protocols.ini update. I need to really reread this thread.

Edit: I did go back and check and the bins in 10811 are essential the same as the bins in 10802, the same fixed data, the same protocol, and the function codes seem to be the same although near the end of the device portion of the upgrade it looks like there may be different functions assigned to some buttons but if one worked, they both should have worked.

I wonder if the box was powered on for some of the tests and not other portions of the tests. I know that some of my equipment takes a L-o-n-g press to turn on.

[eferz]

Thanks, but I don't think we need this anymore. bnordman already found that a previous version worked.

Oh my! I must have missed that while composing my response to you. Guess it's time for me to perform some administrative work and sweep all the failed upgrades into Alan's "archive".

I just uploaded this to my slingbox in Germany and tested it.
The following buttons work:

• Power (on/off)
• Guide
• Exit
• Channel Up/Down
• Info
• Menu
• 0-9
• Last
• Up/down/left/right/enter
• Color buttons

My cable receiver doesn't have a DVR function, so I can't test the associated buttons.

Thank you for this. This is FANTASTIC WORK.

Let me know if there is anything else I should test.

Sounds great! I'm glad it worked out for you.