Closed Caption decoder

xgamer123 · Post by **xgamer123** » Thu Dec 18, 2003 4:53 pm

Hi guys,

Thanks for all of great guys that help me create Prosat satellite IRD remote control code within two days. I've posted this new RC code in KM format at my another topic for Prosat IRD.

Now, I'm going to find out my color closed caption decoder's remote control code. I got keys data from Girder. Any idea for protocol & device?
Power: A857
Disc: 18E7
Select: 08F7
Up: 30CF
Down: 10EF
English: 807F
Chinese: 00FF

xgamer123 · Post by **xgamer123** » Thu Dec 18, 2003 5:11 pm

This time girder fools me. I create new KM file by:
Device:TV, EFC
Protocol name:NEC1, 0, 0, 20
Protocol ID: 005A, 20 FF FF
Power key:EFC/120, OBC/021, HEX/57

8017 sends codes same as original RC in Girder, but it won't works for my closed caption decoder. I need new idea for this.

BTW, if these few button start to work. How do I add to TV set for some none-use key buttons?

johnsfine · Post by **johnsfine** » Thu Dec 18, 2003 7:35 pm

Earlier Jon asked about any extra data that Girder gives you for a whole set of commands (rather than those values you listed for individual commands).

Those values do look like the second half of NEC signals, the half that varies by command. But we need to know the first half in order to reproduce the signals.

jon_armstrong · Post by **jon_armstrong** » Thu Dec 18, 2003 8:24 pm

Also, help us out with the manufacturer, model number, and any other details about the unit.

xgamer123 · Post by **xgamer123** » Fri Dec 19, 2003 11:42 am

I don't understand that Jon wants what kind of extra data, sorry.
I'm using Igor SFH-56 device plug in Girder. It shows in word(two bytes) format only, no matter what I change other RCs. Some RC rapid show different D.word like Pioneer RCVR. It only stop at second half when I release keys. These button code re-produce from 8017 are same as O.RC. I don't see any first half code in Girder. Point me more detail, I post this one and Prosat one for you at Prosat topic and here.

This Closed Caption decoder made by LIGITEK. It's little close to high end decoder for COLOR CC display in transparent back ground. The RC same as Prosat product line, for all model. Actually, SatCruiser satellite IRD RC code that posted in file section is for all model too.

johnsfine · Post by **johnsfine** » Fri Dec 19, 2003 12:37 pm

I looked up the SFH-56 and found this interesting page

http://www.cesko.host.sk/images/PluginHelpPicture.gif

The description of how to get to that config page is here:

http://www.cesko.host.sk/girderplugin.htm

That suggests a few things worth trying:

1) Try changing the "command order". Right now it is doing what you would want for normal use of Girder. It is showing you just the part that is different between keys in the remote. But we need to also know the part that is the same for every key. I think you may be able to get that part by setting the "command order" to something else. (Set it back to 0 after you record the results of that test).

2) The log file created by that "service" option would probably be understandable to me or to Jon. Try the service option and email a copy of the log file to me. You probably shouldn't send that log to Igor (as that page instructs), since his software is working right for its intended purpose. You are just trying to use it for something other than its intended purpose.

To help me understand the log, include some transmits from a built in setup code of the 8017 and tell me exactly what setup code and what keys.

xgamer123 · Post by **xgamer123** » Fri Dec 19, 2003 2:16 pm

johnsfine,

I've sent log and Girder learned and 8017 KM files to you. Let me know any file you want.

johnsfine · Post by **johnsfine** » Fri Dec 19, 2003 2:33 pm

The log file is very verbose, but very obvious.

I looked at the first two signals in the first log file. In both it was device 72 and subdevice 178. You should be able to adjust your KM file to use those numbers.

I don't see anything in the files you sent which tells for sure whether the protocol is NEC1 or NEC2 or something else. I think it is NEC2. If you use NEC1 when NEC2 is correct, it would mostly work, but long presses would do the wrong thing.

johnsfine · Post by **johnsfine** » Fri Dec 19, 2003 3:18 pm

As far as I can tell from the SFH-56 and from the files I got by email, the software for the SFH-56 does crude decoding of the IR signal, not just raw capture. In decoding the NEC signal it seems to pass only the second half (key specific) part to Girder. It seems to ignore the device specific part.

This makes no sense for two reasons:

1) Girder ought to be able to support and distinguish multiple orriginal remotes, rather than just distinguish keys within one remote. If the SFH-56 software doesn't even give the device specific data to Girder then in many cases Girder couldn't distinguish remotes.

2) Girder has plug-in's, such as SFH-56 for many different methods of raw IR capture. It would make more sense to have the crude decode be built within Girder itself rather than in the plug-in, since the process is the same regardless of the raw capture method.

Maybe I missed something in the Girder files.

xgamer123 · Post by **xgamer123** » Sat Dec 20, 2003 11:48 am

johnsfine wrote:I looked at the first two signals in the first log file. In both it was device 72 and subdevice 178. You should be able to adjust your KM file to use those numbers.

I don't see anything in the files you sent which tells for sure whether the protocol is NEC1 or NEC2 or something else. I think it is NEC2. If you use NEC1 when NEC2 is correct, it would mostly work, but long presses would do the wrong thing.

John,
I've followed your instruction and have done it. Thanks!

0.000 1
9.152 1 9.152 <-- Lead In timing 1
9.152 0
13.453 0 4.302 <-- Lead In timing 2
> In this particular signal, the first two intervals (9.15 and 4.3) are
> called a "lead in" and help to identify this as an NEC protocol.
Q. Does NEC protocol always like this "lead in" timing? How about that we'd been done for Prosat IRD on RECS80 (45)?

It looks Girder using only NEC protocol to decode it? Is this the reason that I got HEX codes are different with RECS80 (45) code? Where I can get all table of lead in code table to guess any remote control's Protocol?

> The log goes on for a total of 32 bits for this signal and then more
> signals at 32 bits each. The first 16 bits are the same for each one. It
> is those first 16 bits I used to tell you the device and subdevice
> number for KM.
Q. Now I understand how to convert IR stream. I followed your
explanation to get bits form. I found that device and subdevice are 0x32
0x4d. There is another question about device using OBC? You said it is 72/178? I entered 72/178 into KM. It doesn't work. Girder got 0x12 0x4d. Then I tried to use IR EFC calculator, I found 0x4d same as your at OBC LSB, 0x32 seems OBC LSB=76, I updated device to 76, and it works now. Great!

Another spot, the protocol needs one more Parm (hex), how/when to get it?

I just found problem which already came to my thought. I want to add/merge only two or three buttons into TV set for some un-used key. If I set same TV code in KM, the original TV code are all gone. Do you know any trick to insert key moves into device with different protocol?

Thanks again.

xgamer123 · Post by **xgamer123** » Sat Dec 20, 2003 11:57 am

johnsfine wrote:1) Girder ought to be able to support and distinguish multiple orriginal remotes, rather than just distinguish keys within one remote. If the SFH-56 software doesn't even give the device specific data to Girder then in many cases Girder couldn't distinguish remotes.

2) Girder has plug-in's, such as SFH-56 for many different methods of raw IR capture. It would make more sense to have the crude decode be built within Girder itself rather than in the plug-in, since the process is the same regardless of the raw capture method.

Maybe I missed something in the Girder files.

Yes, maybe we are new at Girder that we can't let all function active. I know there are lots source code in Girder files site for plug-in upgrade. Since I can't let GetIR.xls works, I can use Girder+SFH-56 to manual get bits form to HEX code now. I know different protocol could lead me into another puzzle. But this is the only way for me to get full stream without learning remote controller.

johnsfine · Post by **johnsfine** » Sat Dec 20, 2003 12:55 pm

xgamer123 wrote: Q. Now I understand how to convert IR stream. I followed your
explanation to get bits form. I found that device and subdevice are 0x32
0x4d. There is another question about device using OBC? You said it is 72/178? I entered 72/178 into KM. It doesn't work. Girder got 0x12 0x4d. Then I tried to use IR EFC calculator, I found 0x4d same as your at OBC LSB, 0x32 seems OBC LSB=76, I updated device to 76, and it works now.

I make mistakes on occasion. You are correct that the device numbers translated to hex the way Girder would are 0x32 and 0x4d and you are correct that the LSB position in the EFC calculator is the right way to get the decimal device and subdevice number. I was careless when I wrote 72.

xgamer123 wrote: Another spot, the protocol needs one more Parm (hex), how/when to get it?

That parm is normally left blank in KM. There are less common versions of the NEC protocol in which a parm value is used. I don't think this device should have that.

If I understood you correctly, the upgrade worked (operates the actual device) after you changed the 72 to 76.

xgamer123 wrote: I just found problem which already came to my thought. I want to add/merge only two or three buttons into TV set for some un-used key. If I set same TV code in KM, the original TV code are all gone. Do you know any trick to insert key moves into device with different protocol?

I have a lot of trouble understanding your English. (I would have much more trouble in any other language). I think you are asking a simple question about key moves and I think what you want to do is simple (no trick required). But you may need someone who understands your question better to give the answer.

jamesgammel · Post by **jamesgammel** » Sat Dec 20, 2003 1:03 pm

I think he just wants to do three keymoves into his TV configuration, which apparantly uses a native setup code. You wouldn't do that in KM, you'd do it in IR. If the device you want to keymove FROM isn't in a standard ueic setup code, you would first have to use KM to make a no-key (or three key) device upgrade, them keymove those to the TV's unused buttons. If you already have a device upgrade made and installed, just use IR to keymove them to your using TV device's unused buttons.

Jim

xgamer123 · Post by **xgamer123** » Sat Dec 20, 2003 1:10 pm

johnsfine,

forgive my English, please.

What I'm asking is only simple thing. Is it possible to insert/replace one new button code into one device in 8017 with different protocol. i.e. replace LEGITEK power button code into TV -0150 Mitsubishi at PIP button?

xgamer123 · Post by **xgamer123** » Sat Dec 20, 2003 1:41 pm

jamesgammel,

Yes! This is I'm going to do. I've found new O.RC code by jon's help. My 8017's TV native 0150 setup code has some unused buttons. That's I want to use it for new code. I've created new setup code for one button only by KM. But IR replace entire original 0150 set to disabled. Maybe I make mistake on Copy/Paste function into IP's devices. I'm new at JP1. I don't know about detail to use KM's device upgrade and IR manual input keymove, and my 8017 only add EEPROM, is it not device upgraded?