JP1 Remotes

Hi,

Need to understanding and decode signals from Jerrold Tocom 5507 remote control, already tried RS232 and a routine I made, similar to 1W protocol, it works not so fine as I expected, sometimes its do something I even send comand too, I think becouse of IR sent by TV set.

I using 16F628A and writes in C. All pins are availeble, just need a tip.

Can anyone give me a link to a description on how this protocol works?

Suggestions, idea or "CODE" are welcome too.

Regards;

Manoel.

We have a JP1 upgrade for the Toscom 5507 here:
https://www.hifi-remote.com/forums/dload ... le_id=5904

This protocol has a carrier frequency of 26.7 kHz.

There is no leadin pair.
The leadout time is 38,360 uSec.

The signal is 8 bit where...
Binary 1 is represented by a 1560 uSec ON time.
Binary 0 is represented by a 1560 uSec OFF time.

Here's the hex and binary for each button:

Hex - Binary -- Button
A8 - 10101000 - Num 0
B6 - 10110110 - Num 1
AE - 10101110 - Num 2
BE - 10111110 - Num 3
B2 - 10110010 - Num 4
AA - 10101010 - Num 5
BA - 10111010 - Num 6
B4 - 10110100 - Num 7
AC - 10101100 - Num 8
BC - 10111100 - Num 9
A3 - 10100011 - vol up
B3 - 10110011 - vol down
B0 - 10110000 - mute
AB - 10101011 - channel up
BB - 10111011 - channel down
B8 - 10111000 - POWER
A9 - 10101001 - TV/VCR
A8 - 10101000 - LAST
B7 - 10110111 - MENU
B9 - 10111001 - enter

Wow,

Don´t know how to tank you.

Best regards.

Manoel.

Will you be able to use that info to do what you want? If so, I'm curious to know what you're doing.

Hum,
Based on your tip I made a routine that’s working great, the only problem is that when I turn on the light, for example, the routine detects and do something that it should not do. How will be the best way to filter this erroneous reading?
void receive_ir()
{
int i=0, byte_ir=0;
lock_ir=1;
for (i=0; i<8; i++)
{
if(!i)delay_us(711);
else delay_us(1580);
shift_right(&byte_ir,1,input(pin_b0));
}
byte_ir=~byte_ir;
transfer_0=byte_ir;
aux_0++;
if(aux_0==0x01)
{
verify_channel();
ds2=transfer_0;
trans_channel=1;
ds1=12;
}
if(aux_0==0x02)
{
verify_channel();
ds1=ds2;
ds2=transfer_0;
trans_channel=0;
aux_0=0;
}
byte_ir=0;
unlock_ir=1;
}

Another thing is that, according my scope, the rising time shall be 1520us and the falling time is 1720us.
I’m trying to make samples inside the bit, just to be sure that there is a rising or falling edge, what do you think?

Regards.

I just captured the signals so you can see exactly what they look like, the learned file is here (view it using the IR.exe program):
https://www.hifi-remote.com/forums/dload ... le_id=6787

In doing so I noticed a couple of things that I forgot to mention the before. The volume and channel buttons repeat when held, the rest of the buttons repeat just twice.

Repeating signals
10100011 -38500 = VOL+
10110011 -38500 = VOL-
10101011 -38500 = CH+
10111011 -38500 = CH-

sent once only
10111000 -38500 10111000 = Power
10110110 -38500 10110110 = 1
10101110 -38500 10101110 = 2
10111110 -38500 10111110 = 3
10110010 -38500 10110010 = 4
10101010 -38500 10101010 = 5
10111010 -38500 10111010 = 6
10110100 -38500 10110100 = 7
10101100 -38500 10101100 = 8
10111100 -38500 10111100 = 9
10101000 -38500 10101000 = 0
10111001 -38500 10111001 = Enter
10101001 -38500 10101001 = TV/Vid
10110111 -38500 10110111 = Menu
10101000 -38500 10101000 = Prev

Does this help?

Oh Yes, this I already noted, In fact, the routine I showed works fine, until you dont have any disturbing signals, like discharge lamps, LCD TV´s and stuff.
The problem is that, somehow, the SETUP BOX do some kind of validation at the signal, may be with wave length or something like this to have sure that the signal was sent by remote, and not from estrange source of signals. The routine works so well in one 16F628 @ 4Mhz that right now I working in some kind of digital filter to eliminate this estrange signals.

Regards.

I'm not real clear, from your posts, on what's working and what isn't, so I don't know what to advise.

In Rob's list, I see all the codes have multiple 0/1 transitions (a 1 bit following a 0 bit).

But not so in your sample code.

I don't know what triggers the start of your receive_ir routine. I don't know what kind of underlying timing system you have. I don't know whether this is a multitasking system in which delay_us() might by less costly than burning the CPU time. Without such info, I can't give useful suggestions.

m-a-c-f wrote:the only problem is that when I turn on the light, for example, the routine detects and do something that it should not do.

I wouldn't expect many transitions from turning on a light.

if(aux_0==0x01)

Where are you getting values like 0x01 from? Maybe that represents too few transitions to be safe from accidental trigger. Maybe it isn't even a possible value (depending on whether you have a robust method to start the receive routine). Anyway, it isn't one of the codes Rob listed.

Another thing is that, according my scope, the rising time shall be 1520us and the falling time is 1720us.

Your IR receiver cannot be expected to delay rising and falling edges the same amount. The difference is probably a function of signal strength, so you decode logic should be immune to that changing. Assuming Rob is correct about the basic structure, worry about the average bit time, not about the difference between high and low.

I’m trying to make samples inside the bit, just to be sure that there is a rising or falling edge, what do you think?

Depending on the available timing and computing resources, finding the edges might significantly improve your ability to distinguish valid vs. random (turn on a light, etc.) signals. But if the receive routine is properly started on an edge and you are accepting only codes such as the ones Rob listed (with enough transitions to not occur in random IR) then you may not need the extra effort.

The problem is solved. Instead of sensing the length of the signal, that varies from each other, I made a simple modification on my routine, that's already works fine despite of the interference from other ir's sources.

In the very good tip received from JP1 forum, despite of there, it seems to be, nobody knows much about electronics, there I could see the entire protocol, and help me a lot, so I discovered that bits 0,1 and 2 always are the same, 0,1,0, so I could simple add on routine a test in the interval of these tree bits.

Basically, below is the code to decode TOCON 5505 in C.

Void ir_incoming()
{
int i=0, j=0, bit_l=0, ir_data=0;
for (i=0; i<8; i++)
{
if(!i) // this is the first pulse, bit 0, always off, the total length is 1420us, 690us stay in the middle
{
delay_us(230); // make the first test at 230us while bit 0
if(ir)
{
fail=1;
break;
}
delay_us(230); // make the second test at 460us while bit 0
if(ir)
{
fail=1;
break;
}
delay_us(230); // make the third test at 690us while bit 0
if(ir)
{
fail=1;
break;
}
}
else delay_us(1580); // for bits 1 and beyond, delay 1580 to stay at the center of the pulse
if(i==0x01) // for bit 1, always hi, the total length is 1580, add 690 remaining from bit 0
{
if(!ir)
{
fail=1;
break;
}
}
if(i==0x02)
{
if(ir)
{
fail=1;
break;
}
}
shift_right(&ir_data,1,input(pin_b0));
}
if(!fail)
{
ir_data=~ir_data;

FOR HERE, YOU CAN DO WEREAVER WITH IR_DATA.

THIS WORKS FINE IN 16F628A @ 4MHz INTERNAL OSCILLATOR.

REGARDS.

hello all, I am doing a remote control for the TOCOM 5507 and want to know where Macf project are working to see if we have the same goals and share some experience ... I also some codes are missing from the protocol if someone has .. hopefully not in vain to revive this post ... thanks!

Hi,

In fact I already did a controler for the tunner os the 5507, so I can get all chennels.
It respond the original remote control with some advantages, works very nice, and I do the PWM tunning voltage generation, GREAT.

regards.