HUMAX iHD-FOX C (KabelBW - Germany)

Post by **The Robman** » Tue Mar 06, 2012 1:07 pm

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

Yeah, but this is a bi-phase quad!

eferz · Post by **eferz** » Tue Mar 06, 2012 1:43 pm

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

I dunno this sounds like its way outside my league, but if you think it can be done with my assistance then I'd be more than willing to learn. Mind you, I have no experience in assembly let alone specific processor addresses.

3FG · Post by **3FG** » Tue Mar 06, 2012 2:16 pm

One other point, which Rob may be able to answer. I guessed at the order of the phases. Probably 0 = <-2,2> is correct, but I didn't decode all the signals to see if the OBCs made sense. Is a different order of the 4 phases more likely to be correct?

Post by **The Robman** » Tue Mar 06, 2012 4:13 pm

3FG wrote:One other point, which Rob may be able to answer. I guessed at the order of the phases. Probably 0 = <-2,2> is correct, but I didn't decode all the signals to see if the OBCs made sense. Is a different order of the 4 phases more likely to be correct?

No, you nailed it. Once I allowed for the check-bit, the 1-9 buttons have 1-9 as their OBCs.

Take a look:
https://www.hifi-remote.com/forums/dload ... e_id=10788

Post by **vickyg2003** » Tue Mar 06, 2012 4:13 pm

The Robman wrote:Yeah, but this is a bi-phase quad!

Yes, a pain to decode, but wouldn't the executor be pretty much the same as a normal quad? You have 4 possible sets of timings, but if a certain bit is turned on you turn the ir on first, and then off for a given amount of time otherwise you turn it off first and then on.

The executor itself shouldn't be a little larger than most quads, its the decoding, (your part) that gets to be such a pain.

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]

I'm very confused about the toggle part though.

Post by **The Robman** » Tue Mar 06, 2012 8:41 pm

Well, with a normal quad, you're alternating between 4 normal pairs (and by normal, I mean they're ON-OFF pairs). I don't recall if it's possible to send a pair reversed (ie, OFF-ON) when you're doing it manually. I think you'd have to send the ON and the OFF (ie, delay) separately.

Post by **The Robman** » Tue Mar 06, 2012 9:00 pm

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]

Btw Dave, how did you figure this one out? I mean, what clued you into the bi-phase quad format?

eferz · Post by **eferz** » Tue Mar 06, 2012 9:24 pm

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

As I understand, you have a total of 200 bytes to work with for each Slingbox upgrade. This threshold includes the device and protocol upgrade together. I don't believe there's are any restrictions on the size of the individual device or protocol upgrades, because its a limitation for the size of the bin files which can be uploaded into the Slingbox.

Post by **vickyg2003** » Tue Mar 06, 2012 10:31 pm

The Robman wrote:Well, with a normal quad, you're alternating between 4 normal pairs (and by normal, I mean they're ON-OFF pairs). I don't recall if it's possible to send a pair reversed (ie, OFF-ON) when you're doing it manually. I think you'd have to send the ON and the OFF (ie, delay) separately.

Yes I think you have to send the on/off separately too. I think it can be done something like this with 137 bytes for the protocol. This is roughed in for the s3c8+. I have to check all the data, and timing and such, but you'll get the drift if you look at this protocol.

http://ww.hifi-remote.com/forums/dload. ... e_id=10789

As I said I won't have a chance to work on this until Thursday, I'll have to look at your decodes and see if and how this works.

Btw Dave, how did you figure this one out? I mean, what clued you into the bi-phase quad format?

Yes, HOW DID YOU figure this out?
I'm totally in awe of anyone that can see these patterns!

Post by **vickyg2003** » Tue Mar 06, 2012 11:40 pm

BTW I updated my rough draft of the Humax because I had the zero, one two and three values mixed up. But someone had already downloaded it.

eferz · Post by **eferz** » Wed Mar 07, 2012 12:57 am

vickyg2003 wrote:BTW I updated my rough draft of the Humax because I had the zero, one two and three values mixed up. But someone had already downloaded it.

That was me. I wanted to see if I could understand it, but its all greek to me.

3FG · Post by **3FG** » Wed Mar 07, 2012 1:34 am

I decoded this by first noticing that the number of burst pairs wasn't constant among the various functions, but the total time was constant. That's a strong indicator that it is some kind phase shift keying. We see it all the time with bi-phase signals like RC5. Also, if it is phase shift keying, the time per digit has to be constant. For example, RC5 uses 2 units of time per digit, and the receiver depends on that fact in order to know when the next relevant transition will occur.

Next, with eferz' learns, which have very little jitter, we can see that the minimum time between transitions is 6 periods of the modulation, and the longest is 37 periods between transitions. So I think of that as the shortest time is 1 unit and the longest is 6 units . There were lots of instances of repeated burst pairs of 2, -2. So I chose to believe that each digit lasts for 4 units. 6 units of off (the longest such time observed) could realistically then be made up of <1,-3> followed by <-3,1>. (In principle it could also result from some combination of -2, -4 or -1, -5, but neither of those will work with a 4 unit digit time.)

So a single digit could take on 6 values-- <-3,1> <-2,2> <-1,3> <1,-3> <2,-2> <3,-1>. However, <-1,3> and <3,-1> aren't seen here, probably because base 6 arithmetic is not so easy to work with. When the designers picked 4 digit values, of course they discarded the two with long on times.

So really, once we've decided to try phase shift keying as a candidate decoding, the rest follows pretty easily. The only other thing to worry about is if the protocol begins with an on burst that is used as a start mark only, then the start of each digit would be shifted, but that wasn't the case here. It is still possible that the protocol begins with a start digit or lead in.

BTW, this is not a "bi-phase" protocol. It is a quad phase protocol, because there are 4 values (phases) within a digit.

Post by **vickyg2003** » Wed Mar 07, 2012 3:38 am

3FG wrote:So really, once we've decided to try phase shift keying as a candidate decoding, the rest follows pretty easily.

Yeah Right

(that's sarcasm incase you couldn't recognize it)

Nice job.

And it looks like Rob has this decoded nicely into 1's and 0's and if your IRP is in the same 0, 1, 2, 3 order than we are quite near a solution.

bnordman · Post by **bnordman** » Thu Mar 08, 2012 12:48 pm

You guys are just scary when it gets to this. Amazing.

I am just the outside who is hoping that we can get a useful remote out of this so I can use the Slingbox that I bought...

Thanks for all the work and input on this. It is greatly appreciated!
Bjoern

Post by **vickyg2003** » Thu Mar 08, 2012 2:21 pm

Here is a KM file that seems to shoot the signal. There still may need to have some minor tweaking of the time-offs, as this signal looks to be a tad bit shorter than the ict-learns I was working from.

https://www.hifi-remote.com/forums/dload ... e_id=10796

I've also updated the protocol builder file above.

Question for Rob, was there a way to use your obc's in KM? I just multiplied them by 2 and added 1 if the real obc was even, but was there a way where I could have kept the OBC and had a checksum bit separately?