Problems with a device upgrade for Hewlett Packard PL4200N H

[clreichert]

After staring at RM and IR for a while I realized my cut off for a "high-value" OBC was viewed from a decimal perspective. Thinking in hex/binary, I noticed that all of my probelm functions have OBC's that are specifcially >128 (the lowest is 129), which means they are distinguished by being the only OBC's on this upgrade that have a binary high-order bit of "1".

Since this is a biphase protocol, and the device block seems to end on a binary "010", the OBC's >128 end up having a long sequence of doubled up on/off times at the start of the command byte transmission. This is out of my league, but could this be contributing to the problem? i.e., this clumping of transmission bits is a little off in some way that's rendering the signal invalid when the error is compounded over transmission distance?

[Capn Trips]

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.

This seems to me to be the really funky part of all this. I'm pretty sure that I'm not the one to help, but perhpas one of the experts could spot some minor variances if you posted this 9800 IR file with the three different "variations" of the learned signals for comparison?

[clreichert]

Now we're getting some where

I reapplied myself to this test with the URC-9800 with more rigor. Now knowing that I need to vary my distance from the TV I found that my tests with URC-9800 do yield a more revealing view of the problem. I couldn't view the learned signals on the 9800 in IR so I taught them all back to the 8910 for viewing. That IR file is at https://www.hifi-remote.com/forums/dload ... le_id=2580.

My retest with the 9800 basically showed the same pattern. I used three signals

1. The original "source" signal as learned by the 9800
2. The original "source" signal as learned by the 8910 and then taught to the 9800 from the 8910
3. The original "source" signal as encoded in the upgrade on the 8910 and then taught to the 9800

(in the IR file these are on the SAT devide as L1, L2, and L3 respectively)

When broadcast from the 9800, all three work at <5ft, #1&2 work >5ft, but #3 fails at >5ft range.

Since I couldn't view the signals in the 9800's IR file I taught them all back to the 8910. As expected, signals 1&2 still look about the same and decode properly, but now I can see that #3 got lost in translation, it now claims to be from an Emerson device. Forcing the decoder off I can see that the "good" (1&2) and "bad" (3) signals look very different even though they are all supposed to be the same command. In fact, the #3 signal no longer works at all when broadcast from the 8910, whereas the other 2 still work fine).

When I cleared all the learned signals and repeated the test, it got a little funky. The result reported above was the most common, but it did happen twice that the upgrade signal from the 8910 worked flawlessly when learned by the 9800, even when taught back to the 8910, and even though coming direct from the 8910 to the TV it only works at <5ft. I also tried a few other "good" buttons (Power and "1"), and while they always worked no matter how they were learned, I did notice a few times that the signal learned back by the 8910 (which had been originally produced by the 8910 upgrade) was not decodeable by DecodeIR, even though it still worked on the TV.

Incidentally, I pulled the model/serial number off the original remote for reference. On the back of the remote it says in big letters "RC6ir" and a sticker on the inside of the battery cover says "RC16956002/00HP"

[clreichert]

Noticed another interesting thing today. While the original remote for this TV generates toggled commands, the TV itself doesn't seem to care. I tested this by learning the same command (the digit "1") 5 times in a row to different buttons on the 8910. IR shows the toggles clearly.

However, if I use one of the learned commands I can repeatedly enter the learned command without it being ignore every ohter time (or at all for that matter).

[clreichert]

I got a new URC8910 from BestBuy today just to see if it makes any difference. The problem is the same on this remote. This did make it easier to learn the signal from my other 8910 and see what it's producing first hand. I created an ir file that has a set of original signals (on the TV device) and upgrade isgnals (on the VCR device). "Power" and "1" are signals that work correctly, the other three have the failure beyond 5 ft problem. I couldn't really tell by looking if there is a noticeable problem with them.

I'd appreciate any help that can be offered.

https://www.hifi-remote.com/forums/dload ... le_id=2585

Thanks

[johnsfine]

There's a very interesting glitch at the same spot in each of the signals you learned on VCR. If I understand you correctly, those are the ones learned from the upgrade.

I think that may be the sort of effect you get from a phase glitch in the modulation.

I forget who wrote this MCE protocol executor (I wrote some of the executors in the RC6 family and we got some from UEI. I think Rob wrote some) and I don't recall the details of its inner behavior.

Some protocol executor designs tend to have phase glitches. Some devices care (many don't). When the basic design of a protocol executor is subject to phase glitches, I think the programmers at UEI have access to some design info that we don't have that lets you avoid the phase glitch by setting protocol executor details we don't understand. When we've needed to fix phase glitches before, we just experimented with tiny timing changes till the glitch went away.

I don't know that this issue really is a phase glitch. I think we got the protocol from UEI and I don't think they make that mistake. The learned signals just posted look like the result of a phase glitch, but maybe there is some other explanation I haven't thought of.

I know how to modify CaptureIr so it could directly report phase glitches, but I won't have time to work on that until January at the earliest.

Just looking at the assembler code of the MCE protocol might prove that it isn't subject to phase glitches at all. But even that is probably more than I can do before leaving on (rest of the year) vacation Wednesday morning.

[clreichert]

Wow, sounds like I've disovered a rare, odd and difficult problem to solve. I really appreciate you taking the time to look into it in any respect. For now I'm just using two remotes (my 8910 and the TV original remote). It's not ideal but it'll work until further notice and I'm happy to wait until you (or someone) has the opportunity to give it a closer look. I'm just grateful that you have a good idea of what it might be. Let me know if you need any other signal samples.

BTW-thanks to all on the forum, this is the first time in 3 years of using JP1 that I've encountered ANY problems which is a testament to the quality of what you have provided to the community.

[clreichert]

I've also been following this issue ithe OFA support. They've suggested i go through the "send-in your remote" to be upgraded process. I was wondering if others have done this and if there is value in it. I assume when I get the remote back from them it will have the protocol and device upgrade that UEI has derived for this device. I could then post this back to the forum for comparison/references against the MCE protocol that I'm having trouble with.

Any thoughts?

[The Robman]

The upgrade process is an under-used but valuable feature of OFA remotes, at least for non-JP1 users. I have already brought this question directly to the folks at UEI and they say that they haven't captured this device yet, though they have captured an MD5020N which also uses the MCE protocol. They didn't notice anything special about the MD5020N signals, but they haven't had the chance to actually test their upgrade on the actual device yet.

I suspect that if you were to send in your original remote, they would end up creating an upgrade pretty similar to the one you've already created.

If you want a greater degree of assurance that you will get a good upgrade, I would suggest skipping OFA support and instead send your remote directly to the folks at UEI, along with a note referencing this thread, so they know exactly what the problem is. If you want to go this route, PM me and I'll give you the name and address of who to send it to.

[clreichert]

UEI fixed the problem by doing a decode of the original remote and sending me a revised upgrade file. Their version of the MCE protocol for this remote is definitely different from the verions in IR and RM. I've uploaded UEI's file, and modified RM file, to the file area:

UEI Protocol (IR):
https://www.hifi-remote.com/forums/dload ... le_id=2613

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

The UEI file works flawlessly under all conditions. I used keympa master to make a manual upgrade so i could change some of the button assignments, then loaded the result into RM.