|
Data codes and other facts
- The data codes are sent using pulse coding.
- Each packet has 12 bits and a header.
- The basic time period T = 550 micro secs
- The header length = 4T
- 0 = Pulse with length T followed by space of length T
- 1 = Pulse with length 2T followed by space of length T
- The last 5 bits represent the address.
- The first 7 bits represent the command.
- The packet is transmitted every 25 milliseconds while a button is
pressed.
To view a list of
all the codes, please click here...
Some other interesting facts..
It makes more sense to have the first bits as the address with the
command following it. However, in this case, we found that the address
was coded in the last trailing bits. On a similar tone, when analysing
the encoding of the numerical buttons, the data bits seem to form
mirrored binary numbers.
For example,
Button 0 = 000000010001
Button 1 = 100000010001
Button 2 = 010000010001
Button 3 = 110000010001
Button 4 = 001000010001
If you look at the first 7 bits, when mirrored, they denote
corresponding binary numbers. This leads me to assume that the decoding
logic decodes the bits the other way around. That also seems to explain
the reason for the header being sent in the end.
There seems to be 1 error in my analysis. The plot of the data
signals obtained for the button 6 seem to be wrong. It only has 11 bits
and a faulty address. I haven't had the opportunity to go back to the
lab and confirm this. However, the error seems to be in the remote
control itself since all the data was measured and recorded using
reliable electronic and digital equipment.
Computer Interfacing Solutions
The 3 possible input ports that could be used to connect the receiver
are
- IRDA port
- Serial Port
- Parallel Port
IRDA port
The IRDA port on the computer can be interfaced directly to the
receiver, thus minimizing requirements for intermediate hardware.
However, on further research I found out that the protocols and
standards used by IRDA were totally different from the physical and data
link layers used by the SONY remote control.
In brief, the IRDA standard is based on a 3 layer protocol..
- Physical Layer / Data link : SIR
- Data link / Network Layer : IrLAP
- Transport Layer : IrLMP
The SIR specifications use 2 schemes depending on the transmission
speeds. For lower speeds (between 2.4 kbps and 1.152 Mbps), it uses RZI
(Return to zero-Inverted) and for higher speeds (around 4 Mbps), it uses
PPM (Pulse Positon Modulation).
Since all the readily available IrDA software are only tailored to
these standards, it is not possible to connect the SONY IR receiver to
IrDA port unless we have specific drivers written for reading in the
data signals as per the SONY specifications.
In any case, I tried connecting the receiver to the port to see if
anything could be achieved. As expected, I had no luck.
Serial Port
The Serial Port on the computer receives asynchronous data at
suitable speeds for our data. This, however, requires an extra
hardware/logic interface between the IR receiver and the port. Some of
the main incompatible features between the data links were..
- The serial port expects asynchrounous data, while the remote
control sends self-timed data.
- The serial port can only accept words of length 5 or 7 bits. It
also expects start and stop bits. The remote control has 12 bit
words with a header.
To overcome these incompatibilities, we need hardware such as a
demodulator and logic that encodes the IR signal as 5 bit / 7 bit words
perhaps sending 1 data signal from the remote control at a time. Thus, a
word received on the serial port would represent the data signal
equivalent to a time period of T in the remote control pulse code.
After this, specific software needs to be written in order to decode
/ record the pulse code and interpret it as application commands. This
software can be also part of the application.
Parallel Port
The Parallel Port on the computer is more flexible. Here is a
solution borrowed from the Infra
Red (IR) Interface with Windows CD Software page. The only extra
hardware used is a high speed (109 kHz) timer, which is connected to Pin
11 as a clock to sample Pin 12, which is connected to the IR receiver
output. This ensures that the data is sampled constantly through the
parallel port.
However, we do need to write some low level software, that would
collect these samples from the pararllel port and store them for further
use. After this, the application software has to take the responsibility
of decoding the pulse code and appropriately interfacing the commands.
Conclusion
The greatest learning experience in this project comes from the
remote control signal analysis which answers a lot of questions
regarding the communication technology and standards used by remote
controls. After analysing the signals that are emitted by a remote
control and the options available with regards to interfacing an IR
receiver to one of the computer ports, I have come to the conclusion
that it is possible to implement a communication line between your
remote control and software applications on the computer without much
difficulty. Depending on the convenience, various methods can be
implemented using different layers to convert the pulse coded signals
received from the remote control into a software application command.
Bibliography and Links
Initially, when I started this project, I kept running into several
dead ends. However, as time progressed, my search on the web for
information proved more successful and by the end, I found my project to
be more redundant that a discovery. I am surprised at the amount of
information readily available out there..
Last but not the least, a very special thanks to my roommate Brandon
Itkowitz for getting me started with HP Vee, the sample JAVA script code
(which I modified for the oscilloscope demo on this page), letting me
use his scanner to scan in all the plots, help with photoshop and
finally for just being there..
Related interesting links..
|
