JP1 Remotes

Posted: **Mon Mar 29, 2010 11:40 am**

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 ... alysis.xls

Hope somebody can help.
Thanks in advance.

The Master Aprentice.

Posted: **Mon Mar 29, 2010 12:07 pm**

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 ... &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.

Posted: **Mon Mar 29, 2010 12:09 pm**

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)+

Posted: **Mon Mar 29, 2010 12:19 pm**

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

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

The signal from the IR detector is normally high, but is pulled low when it detects a properly modulated IR signal (in the case of the PNA4613, 40Khz). I triggered on the falling edge of the IR detector signal to capture the above display. The IR remote control module signal has a preamble of a long low pulse, a short high pulse, followed by the bits of the message. Wide high pulses correspond to '1' bits, and short high pulses correspond to '0' bits. Each bit is seperated by a short low pulse. The message of the above signal is 0100 1000 1100.

I've never seen separating bits, but anyway, it makes sense if I look to my waveform so I adopted it as being correct. The difference is that my waveform shows a 16 bit code, which translates to C0 0B if it is MSB. If it is LSB, it would be 03 D0.

Please, if anybody sees any mistakes on this information, let me know.

Posted: **Mon Mar 29, 2010 12:33 pm**

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 ... le_id=8230

Thanks!

Posted: **Mon Mar 29, 2010 2:14 pm**

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.

Posted: **Mon Mar 29, 2010 3:21 pm**

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

Posted: **Mon Mar 29, 2010 5:34 pm**

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

Posted: **Mon Mar 29, 2010 6:22 pm**

masteraprentice wrote: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.

Then Sound Forge is doing the rounding. Just LOOK at the picture. There is scale at the top of the graph. According to the numbers you are posting, every tick represents 2000us, after the first skinny "seperator" do you see ANY spaces that are less than even close to being 1/2 tick?, no they are either 1 tick or 2. So when you find the first "seperator" to the right of that is where the data starts.

Oops, I just looked at the graph again, and I started to the left of the seperator, MY BAD. I had an extra 1 at the beginning, this is actually showing three (3),

11000000 0000 1011 1

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.

I am looking and visually I don't see that 1000us space that you see after any seperator.

I captured this signal and can post an ICT file, if you want to download IRScope, or I can post a picture if you don't want to install our software.

Posted: **Mon Mar 29, 2010 6:39 pm**

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

Posted: **Mon Mar 29, 2010 10:27 pm**

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 ... le_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!

Posted: **Tue Mar 30, 2010 4:20 am**

masteraprentice wrote: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...

You can say that again!

Facts:
-I got the data using an home made osciloscope connected to the sound card.

I'm using an IRScope connected to the USB

-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.

I was using the Comcast remote that shoots the GI Cable code by default and pressing the number 3.

-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.

Yes that was my point, the timings were rounded beyond recognition.

-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.

Yes, while you can decode the bytes by hand, your set top box is looking for something that follows the timing rule.

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?

Yes

Since this remote control unit serves only one type of cable box, the device code will be always 0000?

Probably. That would be a good guess. There will be 256 function codes available for unit 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?

That is exactly what I was trying to convey. I don't know of any GI Remote specific documentation other than the little blurb from DecodeIR.HTML that comes with most of the tools on the forum.
Read my post above again.

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.

While I don't understand PIC programming I can tell you that everything you are looking for is conveyed in this IRP notation for the GI Cable Protocol.

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)}

Read my post above where I try to disect this

{38.7k,490} this is the frequency and the modulated time of 490us.

<1,-4.5|1,-9> this is the ratio for on off times for 0, and 1, each number is multipled by 490us.

The next portion describes how the signal is comprised.
(18,-9,F:8,D:4,C:4,1,-84,

18 * 490 is the lead-in-on- time, its neither a one, nor a zero
-9*490 is the lead-in-off-time as seen in your graph.
F:8 indicates the number of function bits of 8 comprised of zeros and ones.
D:4 indicates the 4 bits of device function which will usually remain the same among all the GI Cable signals eminating from a remote.
C:4 is the checksum, see the explanation above.
1 indicates the lead-out-on-time of 1*490us
-84, indicates the lead-out-of-time which is 84*490us

The next portion
(18,-4.5,1,-178)*
Shows the repeat frames, see the explantion in my previous post.

Here is a partial list of typical GI Cable boxes functions You might want to confirm these and then do the math to compute the checksums

Code: Select all

Function	Decimal	Hex
Power	10	50
1	1	80
2	2	40
3	3	C0
4	4	20
5	5	A0
6	6	60
7	7	E0
8	8	10
9	9	90
0	0	00
Enter
 / Music	16	08
Mute	15	F0
Vol +	13	B0
Vol -	14	70
Ch +	11	D0
Ch -	12	30
Last	19	C8
Exit	18	48
Info	51	CC
Up	52	2C
Down	53	AC
Left	54	6C
Right	55	EC
Select	17	88
Guide	48	0C
Menu	25	98

Posted: **Tue Mar 30, 2010 7:33 am**

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:

Code: Select all

timeline in us		behavior
0					transmission of leadin +18*490us started
4					turn on the IR LED
5					turn off the IR LED
8					turn on the IR LED
9					turn off the IR LED
12					turn on the IR LED
13					turn off the IR LED
...
8820				transmission of leadin +18*490us ended
8821				transmission of leadin -9*490us started
8821				LED stays off until the entire -9*490us time has passed
4410				transmission of leadin -9*490us ended
and then comes the data bits...

Posted: **Tue Mar 30, 2010 8:20 am**

masteraprentice wrote: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?

While the frequency is part of the way the signal is recognized, the decoding is done by the length of the timing pairs.

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

No I'm telling you that the LED would FLASH for the duration denoted by the +(plus) times. That flashing occurs at a frequency. During that 9000us lead-in-on time, the LED flashed 343 times. If the LED had not been flashing at a rate that was in the Settopbox's frequency range, the
Set-top-box would have ignored the signal.

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.

Yes, I know that you want to know how this works.

look at my diagram again. This picture should show it all. Above the on-times, you see how many times the LED flashed during that on length of time. Frequency would be how fast these would flash. 343/9000 gives our frequency of 38117, but we know that the recommended frequency would be 38500

Posted: **Tue Mar 30, 2010 8:46 am**

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!

JP1 Remotes

Can anybody help me to decode this one?

Can anybody help me to decode this one?

I