Arris HMC-4000 - weird situation

[chuliu]

Here's the raw code for the regular NEC executor (which generates NEC1, NEC2, etc). To adjust the carrier frequency, you adjust the first 2 bytes of the code.

Upgrade Protocol 0 = 00 5A (S3C8+) NEC1 (KM v9.22)
43 8B 31 8B 12 CF 44 08 08 01 18 01 06 01 18 03
39 D2 DC 11 94 08 B6 20 01 08 03 37 04 15 F6 01
46 FB 10 37 0B 07 E4 05 04 60 05 8B 0E B6 04 80
B6 05 80 37 0B 05 E4 04 05 60 05 E4 06 07 60 07
20 11 37 06 05 F6 01 04 7B 12 37 09 15 37 02 06
F6 01 49 F6 01 46 37 01 03 46 29 0D 46 29 01 8D
01 49 E4 20 1E E4 21 1F 37 01 EB F6 01 49 E6 28
C1 60 04 E6 12 01 8B E4
End

You can use PB to see what it should be. If I enter 38.1 with a 33% duty cycle, I get "43 8B", so this executor is certainly trying to generate 38.1. If I enter 37.9, I get "44 8B". This will take some trial and error to see what the Slingbox actually generates based on the code.

I pasted the above code to a new manual protocol, and in the resulting protocol there are 3 devices and one command.

Moreover, I tried to type in 32,8,and a random number in the 3 devices, and it decodes as nec1 239,175.

I am not sure where the numbers come from?

Thanks.

[The Robman]

You should use the same fixed data that you got before, the first byte should be hex "20".

[chuliu]

Thanks for pointing out that I should use fixed data 20 fb ef. I managed to create bin with frequency 38.1 and 37.9 and tested power button on the customer's box. It was no luck. I then captured frequency from slingbox 500 with the bin loaded. The result was 38.1 and 37.9 respectively.

Should I try more frequencies? Thanks.

[The Robman]

If you're getting 38.1 when you enter 38.1, which is how it should be, that implies that frequency isn't the problem. The ict that you previously posted of Slingbox captures showed a frequency of 38.7.

Could you post an ict of the 38.1 capture from Slingbox please?

[chuliu]

I uploaded ict file with manual protocol and 38.1 frequency captured from slingbox 500.

File 7

[The Robman]

In my opinion, the signals are close enough copies of the originals that they should work. Have you eliminated all other possibilities that might be stopping it from working on the Slingbox, like the placement of the IR blaster, etc?

[chuliu]

I think we have eliminated every possibility that we can think of. Slingbox 500 was tested locally at my friend's end. Ir blaster was in front of ir receiver of the stb.

I wonder if we should send a 350 to the customer for testing.

What is of interest is that I have a customer( well I am also making bin for little cash) who uses the same stb and he confirmed that the bin file I sent him with nec1 32,8 was still working for him. He confirmed it just this morning. However with the current situation we couldn't test any further. I wanted to ask my friend to test slingbox 500 and stb locally, but he said the stb cannot work without signal. i.e. it won't be operable without cable signal.

[The Robman]

Do we have any sort of confirmation that his Slingbox works at all? Has he used it to control anything else? Has he used a digital camera to confirm that the IR Blaster is sending a signal?

Have you considered sending him a learning remote to capture the signals from the IR blaster?

[chuliu]

My friend tested the customer's slingbox with other stb and it was working.


Anyway, I noticed that the on time on the original remote is a bit longer than off time, whereas on time on the slingbox capture is the opposite. Is there anyway to do a manual protocol with modified on time and off time?

Thanks.

[The Robman]

I did notice that too but I don't believe the differences are significant enough to be the cause, but if you want to experiment with it, here's what you do.

If you dump the executor code that I gave you into PB and decode it, you can see that the following hex code results in the following times (this is a COMP'd protocol, so logical 1 and 0 are reversed):

0118h ;pd02/03: 1-burst on=560 uS
0106h ;pd04/05: 1-burst off=564 uS
0118h ;pd06/07: 0-burst on=560 uS
0339h ;pd08/09: 0-burst off=1690 uS
D2DCh ;pd0A/0B: Leadout off=107960 uS
1194h ;pd0C/0D: Leadin on=9000 uS
08B6h ;pd0E/0F: Leadin off=4500 uS

Upgrade Protocol 0 = 00 5A (S3C8+) NEC1 (KM v9.22)
43 8B 31 8B 12 CF 44 08 08 01 18 01 06 01 18 03
39 D2 DC 11 94 08 B6 20 01 08 03 37 04 15 F6 01
46 FB 10 37 0B 07 E4 05 04 60 05 8B 0E B6 04 80
B6 05 80 37 0B 05 E4 04 05 60 05 E4 06 07 60 07
20 11 37 06 05 F6 01 04 7B 12 37 09 15 37 02 06
F6 01 49 F6 01 46 37 01 03 46 29 0D 46 29 01 8D
01 49 E4 20 1E E4 21 1F 37 01 EB F6 01 49 E6 28
C1 60 04 E6 12 01 8B E4
End

[chuliu]

Thanks and by trial and error I modified the code to make a bin with roughly (+580,-540) and (+580,-1650) However, it still doesn't work.

News is that my friend make a bin to control the customer's tv with slingbox 500 ir blaster and no luck. He asked him to reset the box so we will see.

However, I have a basic question, How do one derive from 0118h to 560 and 0106h to 564? It seems that 0118h is dec 280 and times 2 we get 560. But 0106h is 262 and times 2 we get 524 only. So for most numbers I just take hex2dec and times 2 but for few exceptions I need to hex2dec times 2 and add 40 to it.

[The Robman]

However, I have a basic question, How do one derive from 0118h to 560 and 0106h to 564? It seems that 0118h is dec 280 and times 2 we get 560. But 0106h is 262 and times 2 we get 524 only. So for most numbers I just take hex2dec and times 2 but for few exceptions I need to hex2dec times 2 and add 40 to it.

Wow, it's been so long that I don't remember. We decoded that back in 2001 or so, and since it's programmed into our tools now, there's been no need to remember it.

Ok, I just experimented in Excel myself and came up with the following:
1. For ON times (and leadout OFF time), use =dec2hex(a1/2)
2. For OFF times, use =dec2hex((a1-40)/2)

(assuming the decimal time is in cell A1).