Problems with a device upgrade for Hewlett Packard PL4200N H

[clreichert]

Hi,

I'm trying to create an upgrade for my HP PL4200N TV set. I have a URC8910 remote. I successfully acquired all of the EFC/OBC codes from the TV remote by using the learning feature of my URC-8910 and IR. I used the OBC codes to create an upgrade in RM. The resulting IR and RM files are listed below.

The problem I'm having is that a small number of the functions from the original remote aren't working correctly in the upgrade. I double checked the EFC codes and they are correctly entered in RM and ssigned to appropriate keys. I know the MCE protocol is correct because it works for 90% of the functions. Interestingly, if I learn the problematic functions, the learned versions work fine, they only fail when I try to use them in the upgraded remote. I would leave it at that and be happy except I need to use this upgrade with an extender which doesn't allow learned functions, and several of the problem functions are critical (i.e. video input source).

Is it possible that MCE is working improperly for this small number of commands? I assume that somehow the signal generated by my upgrade is not matching the learned signal (or the original remote signal). I tried substituting alternate EFC codes for the failed functions by using IR's EFC Calculator to find EFC's for the other three OBC formats, no luck.

Any help would be much appreciated.

IR File:
https://www.hifi-remote.com/forums/dload ... le_id=2553

RM File:
https://www.hifi-remote.com/forums/dload ... le_id=2554

1. Device: HP PL4200N
2. Type of device: HDTV
3. Year: 2005
4. JP1 Remote model: URC-8910

[clreichert]

Also meant to note that the IR file I uploaded to the Diagnosis area contains the set of learned signals that I'm having trouble with. The learned versions in the IR file do what they are supposed to do, the corresponding functions in the upgrade do not.

[clreichert]

After thinking about this some more over the weekend and trying everything I could think of to make it work, it occurred to me that maybe this HP remote is using a new variant of the RC6 protocol. Is it possible that a new variant could be similar enough to MCE to allow most of the functions work, but not some others? It seems odd that DecodeIR was able to decompose the signal to begin with if the protocol doesn't work for those signals.

If it is a new protocol, how can I develop a new protocol for this remote? I tried to follow the basic instructions for Protocol Builder but it appears that this remote uses a bi-phase signal with some complex components so after a few hours of trying to decipher it I figured it was beyond my limited abilities.

Any help is greatly appreciated.

[johnsfine]

The resulting IR and RM files are listed below.

I should have looked at this thread when you started it. Sorry about not noticing it.

The problem I'm having is that a small number of the functions from the original remote aren't working correctly in the upgrade.

Exactly which signals were not working?

Exactly which .ir file had you loaded to conduct that test?

I expect we'll find some problem with Keymoves or with some other interaction between remote features within the config you tested. But I don't see that so far.

Is it possible that MCE is working improperly for this small number of commands? I assume that somehow the signal generated by my upgrade is not matching the learned signal (or the original remote signal).

I should test for some bug in the MCE protocol or RM's generation of the upgrade, by loading it into my 8910 and redecoding the output with captureIr, but those parts are scattered around at the moment and I don't know if I'll find the time.

I don't really believe there is some such problem in the protocol or RM, but I'd be happier if I had time to verify that.

IR File:
https://www.hifi-remote.com/forums/dload ... le_id=2553

Usually I'd expect to see two different .ir files, one with the original signals as learned and one with the upgrade as tested.

I assume that one .ir file is supposed to serve both purposes with the learned signals in VCR mode and the upgrade in TV mode. When you tested, are you sure you were careful about which mode the 8910 was in?

maybe this HP remote is using a new variant of the RC6 protocol. Is it possible that a new variant could be similar enough to MCE to allow most of the functions work, but not some others?

The seven learned signals you posted are very clean. It is hard to see how DecodeIr could be confused by any of that. So I'm pretty sure you have the MCE signals as we understand them, not some other form of RC6.

[clreichert]

Your assumptions about the ir file I posted are correct. The TV component contains my upgrade and the VCR component the learned signals. I just tried them again to make sure I hadn't crossed any wires and the behavior is the same.

Here's the really weird part. I had an old URC-9800 sitting in a box so I dug it out for validation on another device. If I load the upgrade into that remote it seems to work fine. I only had a chance to test a few of the signals so I'll have to go back to it later to make certain but I know at least two of the problem functions work in the URC-9800.

Even more bizarre, I used the URC-9800 to learn three signals from supposedly identical buttons:

1. The "Source" signal from the original remote (working signal)
2. The learned "source" signal from my URC-8910 (working signal)
3. The upgrade "source" signal from my URC-8910 (broken signal)

When I look at those three signals in IR, they are all identical, even though the third one fails on the URC-8910. Even worse, the learned versions of all three signals on the URC-9800 work fine.

So something seems to be screwy with my URC-8910, even though it appears to be sending the correct signal pattern. I'm going to blank everything out tonight and start from scratch with both remotes and see if I can figure out why.

[johnsfine]

Does "Source" do a round-robin sequence through a set of possible inputs?

If it does any sort of round-robin it is the kind of signal where you would expect the toggle bit to be required in order for the signal to work more than once in a row (without some other signal intervening).

Does the learned signal (on the 8910 or the 9800, both of which you say work) work twice in a row?

Does the upgrade signal fail twice in a row? Since you're testing signals from multiple sources, I'd expect some failures due to toggle bit state. But the upgrade switches its toggle state on every press, so that if a press fails due to toggle state the next press should work.

Other things I wonder about given your symptom description:

1) Aiming of the LED(s). The IR emitter in the 8910 might be poorly aimed and recessed a little too far within the case. That would cause various problems. I don't think those problems should corelate with which command you're sending, but the fact that you know which command you're sending might create some aiming correlation through your behavior.
Anyway, you might find and read some other threads about opening the case and bending the leads of the IR LED to bring it forward a little so the case blocks less of its output.

2) Batteries. Weak batteries in the 8910 ought to hurt the ability of the 8910 to teach the 9800 more than they hurt the ability of the real device to see the 8910's signal. So weak batteries aren't high on my theory list. But they are on the list. It's always possible for weak batteries to do something unpredictable.

3) Press duration. The signal duration is probably different between a learned signal and an upgrade. I don't know what your device wants (is it picky about duration). You should try some shorter and longer presses than you normally use and see what changes.

4) Lead-out time. If it really is a signal difference between the learned signal and an upgrade signal capable of teaching that learned signal, the plausible difference is lead-out. But you probably need expert hep if you want to try changing the lead-out of that protocol upgrade.

[clreichert]

Thanks for that advice! I'll look into these problems tonight and be sure to get back to the forum with my results.

Thanks again!

[clreichert]

Your suggestions around the LED turned out to be close to the mark. Pulling the LED out further helps a bit but the main problem seems to be interference from the plasma TV. The upgrade works perfectly on my URC-8910 if I put the remote LED directly against the IR receiver on the TV. The farther away from the TV I get the worse the performance becomes until after ~10ft the problem signals pretty much don't work anymore.

I found some spurious references on the web that suggest Plasma TV's can interfere with IR signals. It must just be random luck that the handful of signals I'm having trouble with are getting knocked out by interference combined with what might be a weak IR LED on the URC-8910. It's interesting to note that all the affected signals have OBC values of greater than 100, everything under 100 works like a charm at any distance. So perhaps it is not so random, though I'm still at a loss to explain why those signals are more affected by interference than the others.

At least now I know the codes are working and I'm faced with a problem I can find a way around. I have an IR repeater that I use for my components (in a closet) so I'll probably just end up using that to direct feed the remote signal into the TV (the repeater is VERY forgiving).

Thanks so much for your suggestions, I was really going nuts trying to sort this out.

[underquark]

Pulling the LED out further helps a bit but the main problem seems to be interference from the plasma TV.

Yes, protruding the LED helps though I still think that my Kameleon 4-in-1 (URC8040) is streets ahead of my URC8910 in terms of IR blasting power (but the 8910 is easier to play with).

[clreichert]

This may be more approporiate for the hardware category at this point, but it seems I'm still having trouble. I've noticed some other interesting things worth recording.

My URC-8910 still fades out after 5 ft (measured it last night) but only for some commands (all the commands with an OBC >100). I hooked up my IR repeater to the TV IR receiver (taped the LED right on to the receiver) and it has the same problem, all commands with OBC >100 will not work through the repeater (this TV is the only device with this problem). Once again however, all commands sent from my 9800 work from anywhere in the room and also through the repeater.

One thing that the repeater makes obvious is that the 9800 and the 8910 appear to send signals slightly different. The repeater has a confirmation light that flashes whenever it receives an IR pulse. When I press a button on the 8910 (any mapped button) the light flashes constantly until I remove my finger, indicating that it is receiving repeated IR pulses (though for buttons that work only the first pulse seems to actually register). When I press a button on the 9800 the repeater indicator flashes once to indicate a single IR pulse no matter how long I hold down the button.

Is this typical behavior or have I got IR configured incorrectly? Is it possible that this repeat sending of the IR pulse is causing the signal to get corrupted at a distance? Is there any way to force the 8910 to behave the same way as the 9800 (I would just use the 9800 except for it's limited number of buttons). Any way to boost the strength of the LED in the 8910?

[The Robman]

It might be worth pointing out that the URC-9800 uses a completely different processor (a Mitsubishi 740) to the URC-8910 (Samsung S3C8), so the protocol upgrade would be completely different between the two remotes. Therefore, it's quite possible that there's a bug in one version of the protocol that doesn't exist in the other.

[clreichert]

I hadn't realized that, though I can verify that the upgrade works for all functions--as long as the remote is within 5 feet of the TV. It's only when I'm farther away that it fails, and then only for OBC's >100.

Also, learning the signals back and forth between the 9800 and the 8910 demonstrates that they are each reproducing the signal faithfully.

I took my files out of the diagnosis area but if it's worth checking again for a protocol bug I can put them back up.

Thanks!

[clreichert]

This is a long post, so I'll state right off what I think would be most helpful at this point: Can someone assist in creating an extender for the URC-8910 that gives back ~200b of memory to the learned signals area (from the keymoves/macro area) and enables the learning capability? This would seem to solve my problem.

OK, I've kind of come full circle on this one, hope I'm not beating a dead horse. I sat down last night and made a check list of things that could be causing my problem and then went through it one by one. The results lead me to believe that there is an error in the production of high OBC signals with the MCE protocol (for 8910) that somehow reproduces the high OBC signals "almost" right, at least good enough to be understood at a close range (<5 ft), but not good enough to make it over a longer distance and added interference, especially when coupled with a sensitive IR receiver. This error might be a protocol bug, or it might be a problem with my 8910, or with the way it is configured. In any case, it seems a bit unlikely, but in the immortal words of Sherlock Holmes, "when you have eliminated the impossible, whatever remains, however improbable, must be the truth"

I might also be making some newbie mistake that is glaringly obvious to others (or ignoring some other cause for this issue) so I won't rule out that I'm way off base here. Any way, here's my process:

1. Put fresh batteries in the remote
2. Learned 4 signals from the original remote to my URC-8910, two good and two "bad", learned them to a dummy device
3. Verified the decoded data was correctly entered in the device upgrade
4. Repeated steps 2 & 3
5. Attempted to use the learned signals at close range (<5ft)
6. Attempted to use the upgrade at close range (<5ft)
7. Attempted to use the learned signals at long range (>5ft)
8. Attempted to use the upgrade at long range (>5ft)
9. Repeated steps 5-8 to double check.
(In all cases, tried pressing the button multiple times, with varying hold times, while keeping the remote in the same position)

Result:
Good/Learned: Works at all distances, and all button presses
Bad/Learned: Works at all distances, and all button presses
Good/Upgrade: Works at all distances, and all button presses
Bad/Upgrade: Only works at close range, no function at all beyond 5ft

So this seems to rule out interference as a main cause, since if the learned and upgrade signals were really "exactly" the same they should be similarly affected by any interference. Same applies to battery power and IR LED strength.

The IR file I used to do this is in the diagnosis area: https://www.hifi-remote.com/forums/dload ... le_id=2579
It contains the full upgrade and the 4 learned signals with explanatory notes. I would have stopped long ago but the aspect and source signals are pretty much the most critical ones for me to have access to in the extended remote. As I stated at the top, whatever weird behavior is causing this, the simplest fix might be to have an extender that gives back ~200b of memory to learned signals so i can just learn the working signals into my extended remote.

[The Robman]

I took my files out of the diagnosis area but if it's worth checking again for a protocol bug I can put them back up.

It's not a good idea to delete your files before your issue has been resolved.

[clreichert]

It's not a good idea to delete your files before your issue has been resolved.

I double checked everything so I wanted to make sure I put up an accurate version that I had completely verified. That's available at:

RM File: https://www.hifi-remote.com/forums/dload ... le_id=2563

IR File: https://www.hifi-remote.com/forums/dload ... le_id=2579