Has anyone seen this problem: I have a Harmon Kardon AVR-330 and a Samsung Hi-Def Satellite receiver. When I press the number "4" while changing a satellite channel it shuts off the HK AVR. Obviously it is using the same IR frequency. I was wondering if anyone knew of a work around. Maybe a way to alter the IR code.
Thanks!

I probably could find signals for both those devices and compare, but that would be fair amount of searching and probably some guessing.

It would be much simpler if you posted the proto hex for that number '4' signal and for some signal (such as power toggle) from the HK.

Frequency is a minor aspect of an IR signal, so same frequency is neither necessary nor suffitient for such a conflict.

There are many possible causes for such a conflict. Some of them can be easily fixed (create a '4' signal for the Samsung that won't affect the HK). Probably I'll know whether/how when I see the two signals.

Thanks for the quick reply. I will get you the codes tommorrow. I have them on my work laptop.

The codes for the Devices I am having a conflict on are as follows:
Samsung “#4”
0000 006A 0000 0022 00AE 00AE 0017 003F 0017 0014 0017 0014 0017 003F 0017 0014 0017 0014 0017 0014 0017 0014 0017 003F 0017 0014 0017 0014 0017 003F 0017 0014 0017 0014 0017 0014 0017 0014 0017 0014 0017 0014 0017 0014 0017 003F 0017 0014 0017 0014 0017 0014 0017 0014 0017 003F 0017 003F 0017 003F 0017 0014 0017 003F 0017 003F 0017 003F 0017 003F 0017 0792

HK AVR “OFF”
0000 005A 0022 0002 019F 00CF 0019 0019 0019 0019 0019 0019 0019 0019 0019 0019 0019 0019 0019 0019 0019 004C 0019 0019 0019 0019 0019 0019 0019 0019 0019 004C 0019 004C 0019 004C 0019 0019 0019 004C 0019 004C 0019 004C 0019 004C 0019 004C 0019 0019 0019 0019 0019 004C 0019 0019 0019 0019 0019 0019 0019 0019 0019 0019 0019 004C 0019 004C 0019 0019 0019 07CC 019F 0068 0019 116B

I dont understand the format of hex codes but they look very different to me.
Thanks!

How different they look in that form has very little to do with how different they look to an IR receiver.

But they are actually very different.

The first is NECx2 protocol, device 9.9, command 8 with 39Khz modulation.

The second is NEC1 protocol, device 128.112, command 159 with 46Khz modulation.

Those two protocols could be confused with each other. But the device number is the key way that signals are distinguished and I can't see how a device expecting 128.112 would do anything with 9.9

The frequencies both look to me like they were learned wrong. But I'll check my files on other 9.9 samples and other 128.112 samples to see whether I have any good data on that question. Devices frequently don't care whether an IR signal is at the wrong frequency, so whether those frequencies are right or wrong, it isn't too surprising that the HK accepts a 39Khz signal.

I found a bunch of HK AVR devices that have that signal NEC1:112.128:159 as their Off command. All but one were in the range 37.6 to 38.4Khz, that one was at 34.8Khz. So I think the frequency was learned wrong in that HK signal, but I also think the HK doesn't care.

Are you sure the HK really responds to the Samsung signal? Isn't there also some wired connection between them? Maybe the HK responds to something the Samsung device does. Can you block the IR window of the Samsung device so it can't see the signal, then use the Samsung '4' signal and see if the HK still responds?

If it is the signal, it might be possible to tweak the Samsung signal a little to make the HK not respond to it. But any such tweak would be pure guesswork, because there is no logical reason the HK should respond to it now, so no specific feature of it that ought to be changed.

I found three CCF files (al Samsung HDTV) in which NECx2:9.9:8 was the digit '4'. All were modulated at 38Khz.

So the first thing to try is that signal cleaned up at 38Khz, instead of learned at 39Khz.

0000 006D 0000 0022 00AC 00AC 0015 0040 0015 0015 0015 0015 0015 0040 0015 0015 0015 0015 0015 0015 0015 0015 0015 0040 0015 0015 0015 0015 0015 0040 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0040 0015 0015 0015 0015 0015 0015 0015 0015 0015 0040 0015 0040 0015 0040 0015 0015 0015 0040 0015 0040 0015 0040 0015 0040 0015 0689

Thanks! I will try this. Just so you know, I am a custom AV installer and this is the second time I used a samsung Sat receiver with the HK AVR with the same results. I just installed a third similar setup and am in the process of programming the pronto so I am not sure if I will have the same result but I am expecting it. In the past I used RCA's DTC 100's but they are not very reliable so I have been using the Samsung then I came across this problem when using the pronto. One other thing. I tried using the original samsung remote to confirm that it was not a pronto issue. The same result. I know next to nothing about IR codes. I would like to know more. Do you know of any good resources where I could bone up on it. Most of my problems as a custom installer revolve around IR issues.
Thanks again!
Nick

I should have remembered to ask that. That takes away the chance that it is anything related to the imperfect learning of that signal, so it makes it very unlikely that the cleaned up version will help.

I also should have asked to confirm my understanding that JUST the '4' key causes a response in the HK. If any other Samsung keys cause any response in the HK, those would help identify the cause. Confirming that none other do would limit which characteristics of the signal might be involved.

Chances are some slightly distorted version of the Samsung signal will still be understandable by the Samsung and cure the problem with the HK. Maybe lower the frequency. The HK obviously can read much higher than 38K. Maybe it is limited lower. Maybe tweaking the pulse to gap ratios. The Samsung probably reads only leading edge to leading edge so big changes may make little difference to it, but might affect the HK. I'll try to throw together some attempts tomorrow.

Barry Gordon's document gives a good introduction to both Pronto Hex and IR codes: [Link: remotecentral.com]

Dave Houston recently posted another tutorial covering similar content to Barry's. I can't find a link to that, but here is a link to one of Dave's web pages: [Link: embed-x.com]

Here's Dave's tutorial page:
[Link: embed-x.com]

Mark

Here a a few things to try. In each case, do they still operate the Samsung and do they still affect the HK.

A non-repeating version: The HK error may depend on the repeat. For a command like '4' you probably don't care about the repeat for correct operation of the Samsung.

0000 006D 0022 0000 00AC 00AC 0015 0040 0015 0015 0015 0015 0015 0040 0015 0015 0015 0015 0015 0015 0015 0015 0015 0040 0015 0015 0015 0015 0015 0040 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0040 0015 0015 0015 0015 0015 0015 0015 0015 0015 0040 0015 0040 0015 0040 0015 0015 0015 0040 0015 0040 0015 0040 0015 0040 0015 0689

Reduced pulse width

0000 006D 0000 0022 00AC 00AC 000B 004B 000B 0020 000B 0020 000B 004B 000B 0020 000B 0020 000B 0020 000B 0020 000B 004B 000B 0020 000B 0020 000B 004B 000B 0020 000B 0020 000B 0020 000B 0020 000B 0020 000B 0020 000B 0020 000B 004B 000B 0020 000B 0020 000B 0020 000B 0020 000B 004B 000B 004B 000B 004B 000B 0020 000B 004B 000B 004B 000B 004B 000B 004B 000B 0689

Distorted lead-in

0000 006D 0000 0022 006B 00D6 0015 0040 0015 0015 0015 0015 0015 0040 0015 0015 0015 0015 0015 0015 0015 0015 0015 0040 0015 0015 0015 0015 0015 0040 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0040 0015 0015 0015 0015 0015 0015 0015 0015 0015 0040 0015 0040 0015 0040 0015 0015 0015 0040 0015 0040 0015 0040 0015 0040 0015 0689

John,
Thanks for the modified codes! The non-repeating version worked with both devices. The other two did not work. Also, I appreciate the links for the hex code info. Also thanks to Marky-Mark896. Looks like I have some reading to do.
Nick

This one is a real oddity.

There is a 20 bit subset of each code that's identical (aside from minor timing differences) but I would not expect that to trigger both devices.

Using the learned codes and transmitted bit order...
The final 20 bits of the first match the first 20 bits of the second.

Dave Houston
CodeGenPro™

Based on email, I see I misinterpreted the above. The word "worked" is too ambiguous for this context. There are at least 4 possibilities for a code:

1) Affected neither device
2) Works on Samsung, ignored by HK (what your email implies you meant by worked).
3) Doesn't work on Samsung, still affects HK
4) Works on Samsung, still affects HK.

I now understand (I think) that the non repeating one had behavior (2) but had another problem. The other two were which behavior?

Also, Dave's observation means that the HK receiver is fully armed by getting the correct first 16 bits. From then on it must be bi-state on bits received, seeing only zero's or one's. A decent receiver would be tri-state, seeing "zero" or "one" or "garbage" and would avoid this problem entirely.

Anyway, I'm not sure what the Samsung would do with garbage after the 32'nd bit. It might ignore that. In which case adding some bits there would not affect the Samsung, but would change which command the HK thought it saw, maybe to some innocuous command.

This message was edited by johnsfine on 10/20/04 17:30 ET.

In the HK code, the first 16 bits really only represent 8 bits. Four bits of the second byte are the same as in the first byte and the other four are complements of the corresponding bits in the first byte.