JP1 Remotes

masteraprentice · Joined: 29 Mar 2010 Posts: 8

I'm trying to decode the protocol used on a remote so I can create and build my own remote with custom functions. For that, I need to decode what protocol is used on this specific remote and then I will be able to make a program for a PIC micro controller with my custom controls.
The attached file contains the graphic of the IR signal decoded by a compatible IR receiver chip. I captured the signal on the output of the IR receiver chip directly to my sound card linein jack on the PC.

I'm used to protocols like manchester code, etc. But I'm having some difficulty to figure out this protocol. The base time seems to be 1000 u seconds, which leads me to a bit rate of 1kbit/sec. But the larger times are confusing me and don't seem to be able to identify each bit and also what are the control bits, etc.

By the way, the code you see on the spreadsheet is the result of the number 3 pressed on the remote.

http://www.easy-share.com/1909684091/GI%20Remote%20Protocol%20Capture%20and%20analysis.xls

Hope somebody can help.
Thanks in advance.

The Master Aprentice.

johnsfine · Posted: Mon Mar 29, 2010 1:07 pm Post subject:

I tried and failed to download that file. The 60 second delay and advertisement were annoying enough I don't want to guess what I might have done wrong and try again.

This forum has a diagnosis area for posting such things
http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=35

We will have an easier time looking at your file is you upload to our diagnosis area and then post the URL of your file reached from the diagnosis directory back to your thread.

vickyg2003 · Posted: Mon Mar 29, 2010 1:09 pm Post subject:

I'm not going to allow that server to take control of my computer, but I would guess by the name of the file "GI Remote Protocol " along with the
"base time seems to be 1000 u " that you may be looking at the GI4DTV protocol.

G.I.4DTV
UEI protocol: 00A4
IRP notation: {37.3k,992}<1,-1|1,-3>(5,-2,F:6,D:2,C:4,1,-60)+
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.

masteraprentice · Joined: 29 Mar 2010 Posts: 8

well, it seems I found the solution myself...

From http://users.rcn.com/ted.johnson/ir_remote.htm

masteraprentice · Joined: 29 Mar 2010 Posts: 8

The updated file is uploaded like you said.
Please review and let me know if it is correct.

http://www.hifi-remote.com/forums/dload.php?action=file&file_id=8230

Thanks!

masteraprentice · Joined: 29 Mar 2010 Posts: 8

Well, sorry for lots of posts, but I'm excited to learn this and to try later at home.
I'm reading many documents, but some things are still not clear. Please help, as this is the only forum where people seems to really master IR remotes.
I think I forgot to mention, the remote in question is an old remote for old GI cable boxes.

Doubts:
1-Is there any documentation, or table with all the key codes so I can compare to what I've captured so I can certify I'm decoding the data correctly? I mean, I still don't know if the key 3 on the remote is either a C0 0B or a 03 D0. If I had a table, I could have concluded this already.
2-Do you have any clue of what exact carrier frequency I will need to modulate the data when sending to the IR led? I suppose you can now tell me details about this protocol, right?

I plan to write a program for a PIC ucontroller which will mimic key presses on the actual remote controller. I intend to create a custom remote, which is able to run some macros that I will define. For that, I need to understand the transmitting part of the protocol.

vickyg2003 · Posted: Mon Mar 29, 2010 4:21 pm Post subject:

I'm a picture person, and I can see right away that your pictures don't match up with your column data, you have some error in your spreadsheet columns (probably down rounding). You have 2 distict quite times in your signal, -4000us and - 2000us I may have the units wrong I can't see when things are that small.

EDIT, there were a lot of rounding errors on that spreadsheet. The on times were half the size

You have a lead in pair
+9000 on, -4000 off
followed by a data portion
1 = 500 on , -4000 off
0 = 500 on, -2000 off
message would be
11000000 0000 1011 1

Edit: I corrected my decode.

This is a GI Cable Signal the first group of numbers is the function. Read from right to left, this is the number 3.

This should be sent at 38.7k

Our write up in DecodeIR doesn't show the correct number of bits, but my GI cable code has the same number of "seperators" as yours does. Part of the code will reman static and part of the signal will be a complex checksum
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.

masteraprentice · Joined: 29 Mar 2010 Posts: 8

Vicky, thanks for the response, I'd ask if you could explain in more detail what you said since I did not get it.

On my spreadsheet, there are no roundings at all. Also I've just confirmed that the data on the spreadsheet is an exact representation of what is displayed on the graphic (and the values are those that I got from the timeline on Sound Forge.
I can't cofirm right now that the software I used to analyze the wav file (Sound Forge) can go as deep as needed regarding the decimal places. You know, for measuring micro seconds, the software should read 6 decimal places and it shows only 3 places on the timeline. Then, if the software is no capable to show smaller times, it could be a problem measuring the time.

The timing, I got on Sound Forge by placing the cursor on the place where the waveform starts to change its status. I've done this before to decode machester protocol and it works.

Also, the graphic don't lie, and visually, I see only four different bit lenghts, which according to the timing that I got from the timeline in Sound Forge, are: 9000us, 4000us, 2000us, 1000us.

Sorry, I don't mean to be a smartass at all, just trying to provide arguments as to why I believe what I've done is correct. And if I'm not correct, I'd like to understand what you said.

Thank you so much and please, don't let this thread die
Laughing

vickyg2003 · Posted: Mon Mar 29, 2010 7:22 pm Post subject:

vickyg2003 · Posted: Mon Mar 29, 2010 7:39 pm Post subject:

This is IRScopes view of the signal. At the top you can see the thumnail, and then the expanded detail. Note my picture is upsidedown from yours. The seperator is going up instead of down. The elaspsed times under the line. The raised numbers are just the number of times the IR LED actually flashed during the "on time".

GI Cable looks like this
{38.7k,490}<1,-4.5|1,-9>(18,-9,F:8,D:4,C:4,1,-84,(18,-4.5,1,-178)*) {C = -(D + F:4 + F:4:4)}
leadin = +18*490, -9*490
zero = +1*490, - 4.5*490
one = +1*490, -9*490

The first 8 bits, are the function, the next 4 are the device, and the next 4 are the checksum.

11000000 0000 1011 1

The checksum is computed {C = -(D + F:4 + F:4:4)}
So you take the first device + the first bits of the function the next 4 digits of the digits and then make that negative.

- (0+3+0)
-3 the lsb the checksum, would be 10111111 so we take the 4 bits and make that 1011.

Then we might as well talk about the repeating. In the thumbnail you can see 2 repeat frames, after the initial frame. Those repeats will be sent as long as the key is held. The repeat portion (18,-4.5,1,-178) indicates that the repeat frame will be :

+18*490, -4.5*490, +1*490, - 178*490
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.

masteraprentice · Joined: 29 Mar 2010 Posts: 8

Vicky, I don't disagree with what you said, I just feel you did not get what I was trying to say (or more probably I was not clear enough). Looks like we were saying the same stuff but in different languages hehehe...

Let me go by steps...

Facts:
-I got the data using an home made osciloscope connected to the sound card.
-The data is a waveform which shows the binary data coming from the output pin of the phisycal IR module device (tsop like IC) with a real GI remote control pointed to it and pressing the button 3. So this is the real bits that are decoded from the carrier frequency to binary data by the receiver module (tsop chip) and then sent to the cable box processor.
-The values were really rounded because I forgot to choose the correct time display units on Sound Forge. Now I am posting a more precise spreadsheet with the more correct timing values, bu the software allows me to even more precise.
-The numbers in the spreadsheet are more accurate numbers that were copied and pasted from Sound Forge while moving the cursor to each position in the timeline were the waveform changes its status.
-The spreadsheet should be read in the vertical order from top to bottom, according to time values, which shows the changes of status as time goes by.
-If you look on the values of the last column in the right, you will see the same bit values that you have decoded. So I decoded the values of the bits correctly, but I was wrong on the timings which were really rounded a lot.

The updated file:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=8230

Going forward:

Since my purpose is to build my own remote control unit from scratch, I need to understand how the binary data is composed first, and then how to modulate this binary data on the carrier frequency.
If I am correct, the actual function is a 1 byte value, so the actual number of possible functions are limited to 256, right?
Since this remote control unit serves only one type of cable box, the device code will be always 0000?

Regarding the modulation of the data to the carrier frequency, is there any documentation about this specific remote? How are the zero'es and one's represented on the carrier frequency for these GI remotes? I've read some details about Philips RC-5 and Sony modulations, but did not find anything regarding GI modulation. Since I'll be using a PIC uc to build the remote unit, I guess I can generate the packets already modulated on the carrier frequency instead of sending binary to another chip that would modulate. I can even use the PWM module which is available on some PIC models, but it depends on how this data must be modulated so the cable box understands my remote unit.

Thanks again!

vickyg2003 · Posted: Tue Mar 30, 2010 5:20 am Post subject:

masteraprentice · Joined: 29 Mar 2010 Posts: 8

leadin = +18*490, -9*490
zero = +1*490, - 4.5*490
one = +1*490, -9*490

This is ok, I've got it. BUT, isn't this the data already decoded from the carrier frequency? The IR receiver modules (TSOP like ICs) are designed to recognize and decode carrier frequencies between 36khz and 40khz and output binary data (which could be in another bit rate/frequency), right?
Are you telling me that the carrier modulated data and the binary data are the same in this case? If they were the same, then the LED would stay on for +18*490us, then off for -9*490us, and then follow the rule as you explained:
zero = +1*490, - 4.5*490
one = +1*490, -9*490

I thought the IR LED would keep flashing even when we are transmitting for example the leadin data, and it should be flashing in some pattern which denotes the carrier frequency specification. This is how I believe it works, the carrier frequency would be different from the resulting binary data. This is the purpose of those IR receiver modules, right?

Sorry for so many doubts, but as I will be sending IR light from my custom remote to the cable box, I need to know what are the details about how the IR LED should flash to be in the correct 38.7khz carrier frequency and then be understood by the cable box.

Edit: Now, reading some more about RC-5, I suppose the GI protocol can use the same technique regarding the flashing of the IR LED. On RC-5, the IR LED flash on a 1/3 or 1/4 ratio. This means that when I want a leadin time to be transmitted, I'd need to flash the LED for 8820us (+18*490us) and the flashing frequency calculation would be this:

vickyg2003 · Posted: Tue Mar 30, 2010 9:20 am Post subject: I

masteraprentice · Joined: 29 Mar 2010 Posts: 8

Vicky, great! Now I've got it all.
I will work on the program for the micro controller which will emulate the protocol. Then, if I have any doubts I'll ask again, ok?

Thank you so much!