The 2 switches will let you
choose the mode of operation:
The PIC will recieve the data
from the calc in TI's low level protocol. The data is then encoded and
sent by flashing the IRLED at 30khz (the oscillation is made only by software).
On the other end the IR reciever senses the signal and the PIC decode it
and send it to the calc.
The PIC will send the byte
but it will not wait to see if the it has arrived. This mode is useful
when Chating. When a byte is sent by a calc, it can be received by all
other calcs that are ready for receiving.
This mode should be used
with InfraRed Chat. This is the beta version of
IR Chat, a multiple users chat and whiteboard program. I have written it
for the TI85(Usgard) and TI82(ASH), and should also run under the TI86.
For simple chatting TALK, RTerm8x or FTerm can be used.
with Acknowledgment: *
The difference between this
mode and the previous one is that the PIC will wait until it has received
an acknoledgment from the other calc, which indicates that the byte was
recieved from the other calc. There is a time-out set tp aprox. 1s if the
Acknoledgment was not received.
With this mode variable
transfer between 2 calcs is possible; This mode let the calc synchronise
with each other. Note however that only small files(500b) can be sent,
because when a large variable is sent there is more chances that an errors
This mode should not be
used with multiple calcs, because each calcs will then send its ack bit
at a different time.
State mode: *
In this mode the PIC senses
everytime the state of the calc pins changes, and it will send the information
to other PIC, which sets the lines according to what he recieved.
This mode is somewhat slow,
but it enables the use of every protocol, eg. I2C.
To work correctly the calc
has to change the lines not too fast.
Control sending mode:
In this mode the calc can send
signals in whatever protocol to every device that receives IR.
When used in Remote Control
mode, the PIC will recieve data from the calc in the following format(using
TI's low-level protocol):
1 Byte : Number of bytes n to send
1 Byte : The duration of each bit
1 Byte : The first cycle length
1 Byte : The second cycle length
n Bytes: Data
The first byte is the number
n of bytes that will be sent later.This Byte also determines if
the PIC should enter the I/O Expand mode, the Remote recieve mode, or Remote
If Bit 7 of this byte is
1, then the PIC goes to the I/O Expand mode.
If Bit 6 of this byte is
1, then the PIC goes to the Remote receive mode.
The second byte is the duration
of each bit of the data bytes. The unit of this is the inverse of the frequency(eg,
27.7us, if the frequency is 36KHz).
The third and forth bytes
determines the frequency and the duty cycle of the signal. Here is table
that shows the needed values:(This will be soon updated)
And at last comes the n bytes
This will be written soon.
For example(see ir_phlps.asm)
, let'a assume we want to control a Philips TV. Philips uses a protocol
named RC5, in which a logic '1' consist of a 0-1 signal, and a logic '0'
of a 1-0 signal. A 1 and a 0 signal have each one a duration of 889us.
The signal is sent at 36KHz.
The data consist of 14Bits:
2 sync bits, 1 control bit and 11 data bits. The Sync bits are always 1,
and the control bit change every time you press a key, we will suppose
that it is 1.
We know that the 11 bits
code for Volume + are:
So the 14 bits are:
11 1 00000010000
After RC5 encoding we have:
0101 01 1010101010100110101010
If we group them in bytes we have 4 bytes:
We know that each bit of
this has a duration of 889us=32 * 27.7us.
So what we need to send
to the calc to make a Volume + is:
#4d ; 4 Bytes
#32d ; The duration = 889us
#0Eh ; First cycle
#12h ; First cycle
Take a look at ir_phlps.asm.
This simple Usgard program will let you control the Volume and the Channel
on a Philips television.
For a complete list of all
different codes used by differents manufactures, see the rem34bg.zip
and see also the IR
If you don't know what for
a code your remote control use, try to connect a SFH506 to your Sound Card
to visualize the output of it. Or you can use the Remote recieving mode:
Control receiving mode: *
This mode works the same way
as the previous one, execpt that bit 6 of the first byte(data len size)
is set. The format is:
1 Byte : Number of bytes n to read.
1 Byte : The duration of each bit.
1 Byte : The first cycle length.
1 Byte : The second cycle length.
After recieving this header
from the calc, the PIC will wait for data from the remote, and then it
reads n bytes and send them to the calc.
Here is a programm that
demonstrate this: IR Remote. It will learn the
code from every remote control and store it, so that the same code can
When you start the programm
you have the choice between replaying an existing code or recording a code.
To record press 2nd, the choose the key to which you want to assign the
function, then choose the frequency and the time base of the signal. If
you are dealing with an unknown remote, you should try some differents
values. After selecting this the RED LED in the link will switch on and
the calc will be waiting to the code from the remote. When it recieves
the code, the calc will return to the main screen and you will be able
to replay the code by pressing the assigned button.
If dealing with an unknown
remote, some values that often are used by manufactures can be tried, for
example the Time Base/Frequency combinations like 15/38Khz and 12/32Khz.
Expander mode: *
The unused I/O lines RB2..RB5,
are each one an open drain line(like the one of the calc). You might find
it necessary to place pull-up resistors, since the internal ones of the
PIC are not set.
The PIC enters this mode
if Bit 7 of the byte sent is 1 (see above under Remote Control mode). If
Bit 6 of the same byte is 1, then an output will be made. If it is 0, and
input will be made.
In input, the PIC sends back
the byte read from RB.
In output, the PIC sets the
lines according to the byte first sent(that is only 1 byte have to be sent
to make an output).
Author : Sami