JP1 Remotes :: View topic - Need help with GoVideo DV2140 DVD/VCR Combo

JP1 Remotes

FAQ

7 Days

Memberlist

Usergroups

Profile

File Section

File Search

Lookup Tool

Wiki

Need help with GoVideo DV2140 DVD/VCR Combo
Goto page Previous 1, 2, 3, 4 Next

JP1 Remotes Forum Index -> JP1 - Beginners

View previous topic :: View next topic

Author

Message

johnsfine
Site Admin

Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

Posted: Thu Sep 09, 2004 12:34 pm Post subject:

If you want to hand edit the hex upgrade to test, it isn't too hard. Working backwards from the end of the upgrade, every alternate value should be either 24 or 00. Each of those 24's ought to be 10 and each of the 00's ought to be 80. But when you reach a point near enough the begining of the upgrade that an alternate postions is something other than 24 or 00, don't change anything before that point even if there are some earlier 00 or 24 values.

garypen

Joined: 03 Apr 2004
Posts: 145

Posted: Thu Sep 09, 2004 12:46 pm Post subject:

johnsfine wrote:

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.

Maybe I didn't make clear my problem with the NEC 2DEv Combo protocol in KM:

The GoVideo DV2140 uses two NEC protocols and device numbers (NECx1, 45, 45 and NEC1, 110).
In KM, I entered the following:

NEC 2DEV Combo
45 in device 1
45 in sub-device 1
110 in device 2
left sub dev2 blank.

In byte2, I entered:
1 x1 for all device 1, NECx1 functions
2 1 for all device 2, NEC1 functions

The end result is that all device 1 NECx1 functions are working correctly, but all device 2 NEC1 functions do not work at all.

I would imagine I would be able to test whatever changes are made to the KM byte2 calculations in NEC 2DEV Combo, since a working 2DEV protocol is what is needed for this device.

garypen

Joined: 03 Apr 2004
Posts: 145

Posted: Thu Sep 09, 2004 12:49 pm Post subject:

johnsfine wrote:

If you want to hand edit the hex upgrade to test, it isn't too hard.

Working backwards from the end of the upgrade, every alternate value should be either 24 or 00. Each of those 24's ought to be 10 and each of the 00's ought to be 80. But when you reach a point near enough the begining of the upgrade that an alternate postions is something other than 24 or 00, don't change anything before that point even if there are some earlier 00 or 24 values.

I'm not sure I follow in terms of where I would make the changes. Do I unprotect the cells on the functions page, and enter them manually? Or, is it in the .txt file itself?

However, I don't know if the changes would even work, as all of the "xx 24" hex codes are working correctly. It's only the "xx 00" codes that are not.

gfb107
Expert

Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC

Posted: Thu Sep 09, 2004 12:58 pm Post subject:

johnsfine wrote:

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.

There was a version that did this, when I first added support for default values in cmd parms. It shouldn't do that anymore.

johnsfine wrote:

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.

Yeah, I know about that one too. I saw it after reading this thread. The column width is determined by the text of the column header, which in turn is the name of the device parameter in protocols.ini. I usually just add spaces to the front and end of the parameter name in protocols.ini to deal with this. In my personal copy of protocols.ini I have the following:

Code:

CmdParms=OBC:8=0,Device:0|1,Style :NEC1|NEC2|||NECx1|NECx2=0

That minor change seems to be enough to take care of it.

In terms of manipulating column widths, only the Name and Notes columns do not have maximum width limits. When trying to resize columns, you have to make sure the mouse icon changes to the double-arrow, otherwise you are actually dragging the column header itself to reorder.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

johnsfine
Site Admin

Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

Posted: Thu Sep 09, 2004 1:18 pm Post subject:

garypen wrote:

Maybe I didn't make clear my problem with the NEC 2DEv Combo

I understood all that before.

If I'm right about the way it ought to work, then the way it works now causes you to get NEC1:45.45 for both 1 x1 and 2 1.

Obviously NEC1:45.45 won't work for signals where NEC1:110 is correct. But NEC1:45.45 can work (probably less reliably than the correct signal) when NECx1:45.45 would be correct and your results indicate either it does work or my analysis of the protocol is wrong.

So if your device doesn't care whether it gets an NEC signal or an NECx signal then testing it won't tell us whether we got that part right.

Since it does care between 45.45 and 110, testing it would tell whether we got that right.

When manually patching a device upgrade, it's easier to do it in IR.EXE rather than going back to KM and uprotecting anything. You can select an upgrade within IR's devices tab and click the edit button and just select and type over any hex values you want to change. You don't need to change the 24's to 10's since your device accepts them as 24's. If you change those 00's (in only the positions decribed earlier) to 80's that should fix the 110 device.

johnsfine
Site Admin

Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

Posted: Thu Sep 09, 2004 1:26 pm Post subject:

gfb107 wrote:

It shouldn't do that anymore.

I thought I was up to date on RM, but my directory structures for that are confused enough I'll need more carefull checking to see what is really running.

gfb107 wrote:

Code:

CmdParms=OBC:8=0,Device:0|1,Style :NEC1|NEC2|||NECx1|NECx2=0

In my copy, I added a dozen extra | characters (so there are 15 in a row instead of 3) and that seems to make the NEC vs NECx selection correct. It seems a tacky way to accomplish that, but I don't know another. Of course I'm also not sure I'm even right about that "correct".

gfb107 wrote:

When trying to resize columns, you have to make sure the mouse icon changes to the double-arrow, otherwise you are actually dragging the column header itself to reorder.

I was always very careful of that. It always became a double arrow as I hovered over the boundary mark. It always remained a double arrow while I dragged. It still always failed to resize and often rearranged instead.

jon_armstrong
Expert

Joined: 03 Aug 2003
Posts: 1238
Location: R.I.P. 3/25/2005

Posted: Thu Sep 09, 2004 1:35 pm Post subject:

gfb107 wrote:

In my personal copy of protocols.ini I have the following:

Code:

CmdParms=OBC:8=0,Device:0|1,Style :NEC1|NEC2|||NECx1|NECx2=0

That minor change seems to be enough to take care of it.

On a slightly different subject, shouldn't the style be in the DevParms?

I don't think you can set that by command. Both devices can have a different NEC variant.

So I think you want something like this:

DevParms=Device 1,Sub Device 1=[-0],Dev 1 Style :NEC1|NEC2|NECx1|NECx2,Device 2,Sub Device 2=[-2],Dev 2 Style :NEC1|NEC2|NECx1|NECx2

Or maybe I don't understand how the protocol works.

Edit: I just went back and read the entire thread and apparently extra variable byte may have style data embedded in it plus a bit to call dev 1 or 2. Unless Greg or John has already done this by now, I'll fix the protocols ini, if John can clarify this point. There are also some more and far less used variants of NEC that can be called by the first fixed byte in $005A, should we/can we include those?
_________________
-Jon

Last edited by jon_armstrong on Thu Sep 09, 2004 1:51 pm; edited 1 time in total

garypen

Joined: 03 Apr 2004
Posts: 145

Posted: Thu Sep 09, 2004 1:43 pm Post subject:

johnsfine wrote:

So you are saying that the device will accept NEC1 commands in place of NECx1 (as long as the device settings match)?

Quote:

You don't need to change the 24's to 10's since your device accepts them as 24's. If you change those 00's (in only the positions decribed earlier) to 80's that should fix the 110 device.

In your earlier descritpion, you mention "alternating" codes with 00 or 24. But, that is not the case. With my current mapping, I only have 3 buttons using NEC1, 110. So, there are only 2 "00" entries in the device upgrade text in IR, and one in the key moves section.
Should I just change those 3 entries to 80, and see what happens?

johnsfine
Site Admin

Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

Posted: Thu Sep 09, 2004 1:51 pm Post subject:

jon_armstrong wrote:

On a slightly different subject, shouldn't the style be in the DevParms?

I think the NEC style on the setup sheet should act as a default for the style on the functions sheet. There is no style in the fixed data and there is a style in the hex cmd, so logically it goes only on the functions sheet. But typically it should be the same in every command so a default on the setup sheet would save the user a lot of effort on the functions sheet.

I forgot to mention that's broken as well.

jon_armstrong wrote:

I don't think you can set that by command. Both devices can have a different NEC variant.

...

jon_armstrong wrote:

Or maybe I don't understand how the protocol works.

Maybe none of us understand how it works. But I'm pretty sure you can set style by command, so you could have all combinations of the two device numbers with the various styles (and if KM or RM supported them there are more than 4 styles).

That could be useful for those cases where a mixture of NEC1 and NEC2 is used in the same device number, when those are also mixed with two different device.subdevice values.

johnsfine
Site Admin

Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

Posted: Thu Sep 09, 2004 1:58 pm Post subject:

garypen wrote:

So you are saying that the device will accept NEC1 commands in place of NECx1 (as long as the device settings match)?

My best guess (based on maybe understanding the protocol, and understanding your reported results and remembering reports from other owners of devices expecting NECx protocols) is that your device will accept NEC1 in place of NECx1 probably with reduced reliability.

Quote:

In your earlier descritpion, you mention "alternating" codes with 00 or 24.

I couldn't think of a clear way to say that. I meant that is you look at that long hex string in the devices/edit dialog in IR the latter portion of it is alternating command bytes with control bytes and each control byte is either 24 or 00. I didn't mean to imply any pattern to which control bytes were which. I was trying to distinguish control bytes which I suggested changing from both the command bytes and whatever other data comes before the first command byte. Both command bytes and other data MIGHT have 00's and 24's in them, so I couldn't just say change all the 00's and 24's.

jon_armstrong
Expert

Joined: 03 Aug 2003
Posts: 1238
Location: R.I.P. 3/25/2005

Posted: Thu Sep 09, 2004 2:05 pm Post subject:

johnsfine wrote:

I went back and re-read the entire thread and realized that you had concluded that it was in the variable byte.

Quote:

That could be useful for those cases where a mixture of NEC1 and NEC2 is used in the same device number, when those are also mixed with two different device.subdevice values.

I agree and I'll fix the protocols ini (if you or Greg haven't already) and if you can tell me how you think the bits (other that the control bit that picks dev 1 or 2) map to the alternate styles and then test the results. I have a copy of Rob's explanation of how the first fixed byte of data maps to $005A so if it's close to that I can probably figure it out.
_________________
-Jon

johnsfine
Site Admin

Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

Posted: Thu Sep 09, 2004 2:09 pm Post subject:

jon_armstrong wrote:

There are also some more and far less used variants of NEC that can be called by the first fixed byte in $005A, should we/can we include those?

I don't think the style byte here is that good a match for that byte in 5A.

My best guess is:

bit7: Selects the first or second device.subdevice from fixed data.

bit5: Overrides the subdevice from the selected fixed data to be the no_subdevice value. That's barely ever useful, since no_subdevice is typically done by having RM or KM compute the no_subdevice value for fixed data. But I guess there might be a need for mixing two different devices and having one of those mix a subdevice with no_subdevice.

bit4: Selects NEC vs. NECx

bit3 does something. I think it overrides NEC1 to NEC2 for functions assigned to the REW,FWD,CH+,CH-,VOL+ and VOL- keys. In a normal 5A upgrade than can be useful. Here it's pointless. If you want to select NEC2 vs. NEC1 for specific functions, just do it.

Bit0: selects NEC1 vs. NEC2

Protocol 5A has something to select the doubled data frame in NEC1. I don't see anything like that here.

Last edited by johnsfine on Thu Sep 09, 2004 2:10 pm; edited 1 time in total

garypen

Joined: 03 Apr 2004
Posts: 145

Posted: Thu Sep 09, 2004 2:10 pm Post subject:

Quote:

Both command bytes and other data MIGHT have 00's and 24's in them, so I couldn't just say change all the 00's and 24's.

Ok. I think I see. I'll change just the 3 applicable 00 entries to 80, and give it a try. It won't happen until I'm home, of course. But, I will post results, if I find them.

I've also found a few other LG/Zenith DVD upgrade files that use NECx1, 45, 45. I've been able to find 6 function codes from those files that I will try in place of the NEC1, 110 codes. (I have a total of 11 functions, out of 44 total, that are NEC1, 110 , so that still leaves 5).

The Robman
Site Owner

Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL

Posted: Thu Sep 09, 2004 2:51 pm Post subject:

johnsfine wrote:

Just to confirm this, I have a VCR (a Samsung SV5000) that expects NECx2 signals, but responds to both NEC1 and NEC2 signals with the correct device codes (except for the RECORD button that is, which requires a long hold, so this won't respond to NEC1).
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

jon_armstrong
Expert

Joined: 03 Aug 2003
Posts: 1238
Location: R.I.P. 3/25/2005

Posted: Thu Sep 09, 2004 8:23 pm Post subject:

johnsfine wrote:

.
My best guess is:

bit7: Selects the first or second device.subdevice from fixed data.

Yes 0=> Device 1, 1=> Device 2

Quote:

bit5: Overrides the subdevice from the selected fixed data to be the no_subdevice value. That's barely ever useful, since no_subdevice is typically done by having RM or KM compute the no_subdevice value for fixed data. But I guess there might be a need for mixing two different devices and having one of those mix a subdevice with no_subdevice.

Yes but 0=>Overrides sub-device, 1=>allows subdevice

Quote:

bit4: Selects NEC vs. NECx

Yes, but DecodeIR.dll will only decode a NECx1 or 2 IF device=sub-device and I think you recently said that you had found an example where that wasn't always the case.

Quote:

bit3 does something. I think it overrides NEC1 to NEC2 for functions assigned to the REW,FWD,CH+,CH-,VOL+ and VOL- keys. In a normal 5A upgrade than can be useful. Here it's pointless. If you want to select NEC2 vs. NEC1 for specific functions, just do it.

Yes , 1 will use NEC2 on Vol+/-, etc commands UNLESS NECx is selected

Quote:

Bit0: selects NEC1 vs. NEC2

Yes 0=> NEC1, 1=>NEC2

Here is the corrected Protocols ini entry for 01 1A and in my testing seems to work well. Apparently there is only an S3C80 version of 01 1A.

Code:

[NEC 2DEV Combo (*)]
PID=01 1A
DevParms=Device 1,Sub Device 1=[-0],Device 2,Sub Device 2=[-2]
DeviceTranslator=Translator(lsb,comp,0,8,0) Translator(lsb,comp,1,8,8) \
Translator(lsb,comp,2,8,16) Translator(lsb,comp,3,8,24)
FixedData=ff 00 ff 00
CmdTranslator=Translator(lsb,comp,0,8,0) Translator(1,1,8) Translator(2,1,11,1) Translator(2,1,15)
CmdParms=OBC:8=0,Device:0|1,Style :NEC1|NEC2|NECx1|NECx2=0
CmdParmInit=PickInitializer(1,N0,N2)
DefaultCmd=00 20
CmdIndex=0
Notes=38.1 kHz IR.exe and other tools that use DecodeIR.dll will decode a NECx1 or NECx2 protocol only if device=sub-device.
Code.S3C80=43 8B 42 8B 14 CF 44 08 08 01 18 01 06 01 18 03 39 D2 DC 11 94 08 B6 08 CA E6 10 02 08 08 37 0E 06 E4 05 03 E4 06 04 E4 07 05 E4 07 06 60 06 37 0B 05 E4 03 04 60 04 37 06 05 F6 01 04 7B 09 37 09 0C 37 01 03 46 29 0D 46 29 01 8D 01 49 E4 22 1E E4 23 1F 37 01 EB F6 01 49 E6 28 C1 60 03 E6 12 01 8B E4

EDIT: I found the original RM protocols ini entry for this and editied out some confusion on my part.
_________________
-Jon

Last edited by jon_armstrong on Sun Sep 12, 2004 4:40 pm; edited 2 times in total

Display posts from previous:

	JP1 Remotes Forum Index -> JP1 - Beginners	All times are GMT - 5 Hours Goto page Previous 1, 2, 3, 4 Next
Page 2 of 4

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum