Need help with GoVideo DV2140 DVD/VCR Combo

[garypen]

In my case, I do appear to have a device with 2 protocols. It's a GoVideo DV2140 DVD/VCR Combo. I have been attempting to create a device upgrade file, and I learned every button from the original remote.

Most of the functions are NECx1, device 45, subdevice 45. But, and it's a big but, many functions are NEC1, device 110, no sub.

The only protocol listed in KM that appears to allow 2 devices is NEC 2DEV Combo, so that's the one I've been attempting to use. Unfortunately, only the NECx1 functions work after uploading to the remote (2116).

I would imagine I'm misunderstanding the instructions for the byte2 entry, or something in the protocol/device settings. Perhaps one of the experts can take a look at my entries below, and tell me what I am doing wrong. I'd appreciate it. Thanks.

On the Setup page, I entered:
protocol =NEC 2DEV combo
device1 =45
subdev1 =45
device2 =110
subdev2 =no entry
NEC style =no entry

In the byte2 column on the Functions page, I entered:
"1 x1" for the functions that are NECx1 45, 45
"2 1" for the functions that are NEC1 110
(The quotes are for demonstration. There is a space between the 1st and 2nd character.)

Again, I appreciate the help.

[The Robman]

It's not surprising that a VCR/DVD combo would use two different device codes, I'm guessing that the split between the two sets of codes matches the split between DVD and VCR functions.

If this is the case, rather than creating a combo code like you're trying to do, why not create two seperate upgrades, one for the VCR portion and another for the DVD portion. If there are 1 or 2 buttons that are on the wrong side, use keymoves to fix it.

If you make it all one big upgrade, what would you program to the PLAY button, "VCR Play" or "DVD Play".

[johnsfine]

rather than creating a combo code like you're trying to do, why not create two seperate upgrades

There's a good chance that's the best answer for this device. BUT if he has discovered a KM bug, shouldn't we also fix that KM bug.

At first glance it looks like the protocol uses the top bit of the second byte of the hex command to select the second device.subdevice values. But KM seems to use bit 5 of that byte instead (and bit 5 serves another purpose, so things get even more confusing). Anyway, I can't see how KM would ever work for this protocol. But I'm not near a remote I could test with to be certain.

[gfb107]

While checking to see if it is a bug in KM, could you also check RM?

[The Robman]

if he has discovered a KM bug, shouldn't we also fix that KM bug.

I do seem to recall that the NEC 2DEV Combo doesn't work but I've never had the time to look into it, and I'm guessing that no-one else has either.

[garypen]

Actually, the two protocols are not divided between VCR and DVD functions. The splitting of the protocols is random. "Play" is "Play", "Stop" is "Stop", regardless of DVD or VCR. There are DVD and VCR function keys that cause the device itself to change modes. The same play, stop, ffwd, etc key codes control both VCR and DVD functions, depending on which mode the actual device is in.

Plus, I prefer operating the device from a single device setting on the remote.

Debate about using one or two device upgrades aside, isn't the NEC 2DEV Combo protocol supposed to work in this situation? Did I make the correct entries? Am I doing something wrong? Or, is it a KM issue?

Thanks.

[The Robman]

If, as you say, the PLAY button is always PLAY, then you should try and use one upgrade to control the device. If the commands had been split down the DVD/VCR split, then it would have been more appropiate to use two upgrades. After all, just because this is physically one device, doesn't mean you need to treat it as one device, when in fact it's two "logical" devices. This is also true of HT systems which combine a tuner, CD player, DVD player, etc all into one physical device.

In your case you appear to need to use two different protocols (ie, NECx1 and NEC1). IIRC, the NEC 2DEV Combo protocol is designed to combine different device codes for the SAME NEC protocol style, in other words, the output would be all NECx1 or NEC1. That being said, I don't think this protocol actually works. In which case, you would be better off using the Device Combiner, which would certainly let you create one upgrade that sends both the NECx1 and NEC1 signals.

[garypen]

Device combiner, eh? UH oh. Now I have to learn something else. I better get my thinking cap back out.

BTW, if NEC 2DEV combo is designed for multiple device codes for the same NEC protocol, I wonder why the instructions on both the "function" and "protocol help" page seem to indicate it would work with multiple codes AND protocols? Am I misunderstanding what it says?

[Capn Trips]

I presume you've already tried THIS upgrade?

It might not work, as it is NECx2 Dev5.5, but the model numbers are close.

[The Robman]

BTW, if NEC 2DEV combo is designed for multiple device codes for the same NEC protocol, I wonder why the instructions on both the "function" and "protocol help" page seem to indicate it would work with multiple codes AND protocols? Am I misunderstanding what it says?

You notice that I put an "IIRC" in front of that statement. When I originally added this protocol to KM I don't recall adding functionality that would let you combine different styles of NEC, but it does look like that functionality has been added (according to the help sheet).

Also, I don't KNOW that the combo protocol doesn't work, I just seem to recall seeing many posts in the past from people having problems trying to use it, but I've never had the time to investigate it.

[garypen]

Don't sweat it Rob. This whole JP1 deal, using IR and KM, has been a great help. I guess I was just getting spoiled, since all of my other device upgrades have been flawless.

If anybody can figure out why the dual prorocols don't work with NEC 2DEV, even though they should according to the KM "help" and "functions" pages, I'd appreciate it.

[garypen]

I presume you've already tried THIS upgrade?

It might not work, as it is NECx2 Dev5.5, but the model numbers are close.

I actually downloaded that one immediately after ordering the unit, before I even had it my home. But, once I dl'd the function info from the original remote to the 2116 to IR, I saw that absolutely none of the codes were the same. None. Not one.

However, perhaps I'll load it up, and try it anyway. Couldn't hurt! I also checked out the LG files, and will now look at Zenith files, as I believe my GoVideo model was made by LG, as are Zenith and LG (of course).

[johnsfine]

While checking to see if it is a bug in KM, could you also check RM?

Whoever put that in protocols.ini did a very good job of matching KM bug for bug. RM is wrong too.

I'm nearly sure the second translator should be Translator(1,1,8) rather than Translator(comp,1,1,10). That should make it correctly decide between the first and second device numbers.

But I also think both KM and RM have the decision between NEC and NECx wrong. They both add 0x4 to the control byte for NECx. I think you need to add 0x10 to the control byte for NECx. But I really can't be sure short of installing the upgrade in one JP1 remote and learning the result to another. I don't have time anytime soon to do that.

BTW, in testing this I was reminded of another RM glitch I probably never commented on but should have: If you put in an OBC of 0 it displays a blank OBC rather than 0.

BTW2, another RM glitch I notice in testing this is the "Type" column in the functions sheet is too narrow to display NECx1 or NECx2 and using the handles to change column width works only on the Name column. On any other column it either does nothing or does strange things (like changing column sequence). It never changes the width.

[garypen]

If you can make that change to KM, and make the "beta" available to me, I can test it with my JP1 remote and two-NEC-protocol device.

[johnsfine]

If you can

Me or some more generic "you"? KM has evolved a long way since the short period during which I understood enough to make limited changes in it. I could make the protocols.ini changes for RM.

BUT, I don't think your proposal is a decent test. If I understand the protocol and your reported results, you tested a version that always selected NEC, not NECx and device 45.45, never 110, yet some of it worked.

That means your device accepts NEC when it should be getting NECx. That makes it too forgiving to use as a protocol test. We really need to do the learning test, one JP1 remote to another.