Page 1 of 1
Discrete codes -- brute force method?
Posted: Sun Feb 04, 2007 3:00 pm
by ehart
Hi everyone,
I think I've pretty much proved that my device (Optimus TV/VCR 13" combo) doesn't have discrete codes. It uses VCR code 1162.
I did the proving by manually going into IR "key moves" and defining every possible EFC (from 000 to 255) onto keys, and testing each key to see if it turns the TV on or off. Pretty painstaking, actually.
Does that in fact prove there are no remote codes for it? Or might the discrete on/off be part of a separate protocol or something?
Thanks,
Eric
Posted: Sun Feb 04, 2007 3:04 pm
by Capn Trips
It pretty much proves it, unless they happen to have hidden them using, say, another device code, which could have a whole nother 256 OBC's to try. It happens, but only rarely.
You can always use ToadTog.
Re: Discrete codes -- brute force method?
Posted: Sun Feb 04, 2007 8:25 pm
by The Robman
ehart wrote:I think I've pretty much proved that my device (Optimus TV/VCR 13" combo) doesn't have discrete codes. It uses VCR code 1162.
I did the proving by manually going into IR "key moves" and defining every possible EFC (from 000 to 255) onto keys, and testing each key to see if it turns the TV on or off. Pretty painstaking, actually.
First off, that's an incredibly time consuming way to test all 256 EFCs, a much easier way would be to create dummy upgrades that have the EFCs assigned to buttons, then load the codes and test the buttons.
But regardless, VCR/1162 is a combo code which doesn't reliably support EFCs, so testing EFCs with this code doesn't actually prove anything. You would need to test all the EFCs for the 2 or 3 device codes that make up the combo.
Posted: Sun Feb 04, 2007 10:08 pm
by ehart
First off, that's an incredibly time consuming way to test all 256 EFCs, a much easier way would be to create dummy upgrades that have the EFCs assigned to buttons, then load the codes and test the buttons.
So I should do this test using RM (or KM), instead of just in IR?
VCR/1162 is a combo code which doesn't reliably support EFCs, so testing EFCs with this code doesn't actually prove anything. You would need to test all the EFCs for the 2 or 3 device codes that make up the combo.
Is there any way to tell what the 2 or 3 device codes are?
Posted: Sun Feb 04, 2007 10:21 pm
by The Robman
ehart wrote:So I should do this test using RM (or KM), instead of just in IR?
Right. And once you move over to KM or RM, it's usually easier to work with OBCs rather than EFCs, but eithr will work.
ehart wrote:Is there any way to tell what the 2 or 3 device codes are?
VCR/1162 is a well known code, so I don't even need to look that one up. That code is a combination of VCR/0162 (Panasonic device 144.0) and VCR/0454 (Panasonic device 144.1). The TV controls may come from TV/0250 (Panasonic 128.0).
Posted: Mon Feb 05, 2007 9:03 am
by ElizabethD
There might be one more on subdevice 144.5 - obc 43 for Tape Position. It displays relative place where the tape now is. Very convenient on VCR.
Posted: Mon Feb 05, 2007 10:48 am
by ehart
Interesting. I'm doing the same research/testing for a Liteon DVD player/recorder. How likely is it that it also uses multiple "code sets" (for lack of a better word)?
Posted: Mon Feb 05, 2007 11:58 am
by The Robman
If all of the signals that you learned from the Lite-on remote all use the same protocol and device code, I would say that it's unlikely. If you had learned the signals from your Panasonic TV/VCR combo remote you would have noticed that the three, maybe four, different device codes were used and this would have been your clue.
Posted: Mon Feb 05, 2007 2:05 pm
by ElizabethD
Rob, wouldn't it be interesting if it used NEC1 in addition to JVC. Half of these LiteOn boxes, and the DigitalMax I played with, use JVC, the rest use NEC1. Do the manufacturers pull tricks like that on us? Maybe discrete power is there after all somehow? Fat chance

Posted: Mon Feb 05, 2007 2:22 pm
by The Robman
That just means that Lite-On is using two difference sources for the box, where one of the sources is probably JVC.