RSS icon Home icon
  • Software controlled infrared device

    Posted on February 3rd, 2019 admin No comments

    After a long silence I pushed myself to create a new article. I have many half written materials I can choose from. This time I finished my IR device story.

    In 2008 my then boss came up with an idea: End-to-End testing/monitoring of the TV services by using real set-top-boxes (STB). One of the interesting part of this project was the development of the software controlled infrared remote device. E2E mean we had to control an STB just like clients do, so a computer controlled IR had to be developed. We intended to simulate the original remote, so I had to watch-and-learn the signal it sent.

    I built a very simple infrared receiver and connected it to a logic analyser I bought for myself for hobby projects. The LED gave me feedback whether the remote pointed straight to the IR receiver.

    Infrared Sniffer

    At this point I made a decision which determines and limits how new devices can be added to the controlling software. After all signals captured from the remote I tried to decipher and understand how the data encoded in the signal. When the modulation and coding are revealed I stored only the decoded button codes and the modulation algorithm.  I assumed there are only few modulation/coding variation exist. After examining more than 30 remotes it proved to be true, only 2 modulation techniques were enough for our goals. However, this limits the way how new remotes can be added to the list. If I had decided to simply store the timing of signals, even if I had built a portable signal-receiver then adding a new remote would may have been easier.

    The two modulation techniques I encountered:

    • Manchester or Phase Encoding: Within one period the encoding of a data bit is either low-then-high or high-then-low transition.

    Manchester Encoding

    • Pulse Distance Encoding: The distance between pulses represent one or more bits. Simple versions encode only 1 bit information, but there are remotes exist where distances encode 2 or 4 bits.

    Pulse Distance Encoding of 2 bits

    There are many differences how remotes encode information beside modulation:

    • Using lead in pulses
    • Transmitting Device ID before button code
    • Encoding the button code twice: normal then inverted
    • Many different pulse widths (250-1000 us)
    • Even code length differs: 8, 16, 32 bits

    Fortunately, they all use the same carrier frequency which simplifies the SW/HW design.

    Remote Signal Example

    A remote must repeat the code when the user holds the button a little longer. For example, this helps navigation in long EPG lists. There is a huge gap between two consecutive sending. Usually between 70-100 milliseconds. I saw 3 different methods how remotes handle code repeating:

    • Simply repeating the signal
    • Set a “repeat” bit in the signal
    • Sending only a “repeat the previous code” signal

    I implemented all of these but in practice we never used it.

    The first version of the IR device was quite simple, just a simple infrared diode driven by the serial port’s DTR pin. I put everything else – the whole logic – in the software.

    Simple IR transmitter

    The solution proved to be unreliable. The problem came from the fact a constant 36-38 kHz carrier frequency of the IR signal cannot be reliably produced by software. This would require a precise 25 us timing in a user-space program. At this point I have to remark we were using Windows XP and cheap desktop PCs at that time. Since Windows is a preemptive multitasking operating system it “randomly” (from the perspective of a user-space program) interrupts the currently executing thread which spoils the accuracy of high-resolution timing. On high load the accuracy even worse. There are background tasks that can be unpredictably cause high load for a very short period of time. In other words: I need synchronous operation on an asynchron system. I tried to prevent timing problems with several ideas:

    • The whole signal is precalculated before sending, so transmitting the signal is just a simple loop.
    • Using the QueryPerformanceCounter function to achieve maximum accuracy.
    • Raising the thread priority class to the maximum (realtime) during sending the signal.

    Despite these efforts there were cases where the IR signal was malformed. A small glitch in the signal can change the meaning of the decoded data which in turn cause a different function invoked on the STB. For example, we observed sometimes the software started recording of a TV programme instead of switching to a different channel. This cannot be accepted from a monitoring software. Unfortunately, there is no error detection and error correction implemented in many IR remote devices.

    We had no other choice, the signal must be created in hardware. We were searching the internet for a readily available IR device but found nothing. I offered help to create the hardware. However, there was no official support for the project so I made the prototype at home at my expense. I love creating and see my idea working, so I was not worried about the costs.
    For the constant carrier frequency I used a 555 timer IC. I prefer USB over the old serial port since the latter is fading away, therefore I chose an FTDI chip (FT232RL) to handle the USB communication. I wanted a microcontroller for the signal modulation which can be programmed in assembly to achieve proper timing and has a small memory to store the transmitting code. At last but not least, it can be reprogrammed when needed. I had a Microchip PICkit programmer so the choice was obvious. After a little search on the Microchip website I chose the PIC12F683SN. This is an 8-bit microcontroller operating at 4 MHz clock. The MCU connected via the TxD pin to the FTDI chip to receive the codes from the USB port. There is a newer version of the schematic which contains a transistor to drive the infra LED and therefore can operate from a larger distance. We are still using the transistorless version placed close enough to STB.

    USB Remote Schematic

    In the MCU’s machine code there are two major parts: the signal data receiving part and the IR transmitting part. The signal receiver is simple, it just collects 8 bit frames to read bytes until it reaches zero the end marker. The signal data encodes high and low pulses alternating. There can be values which overflow 8 bit, but to conserve space I had to store variable length values. Bit #7 flags whether its a multibyte value. The MCU can store up to 128 bytes in its internal SRAM. This way the longest signal can be stored in the SRAM. The software still required to calculate the pulses but the precise timing moved into the hardware and a very little modification was required on the software side. The small SRAM may pose issues but in our cases it caused none.Every instruction executed in 1 us at 4 MHz which simplified the timing. I used NOPs to adjust timing. Microchip MPLAB helped to verify and debug the code.

    There are lots of helpful materials on the FTDI and Microchip websites on how to design the hardware and how to interface the chips. I bought a breadboard to test the design. It did its job perfectly, I was able to control my own STB at home.

    USB Remote Prototype

    I had experience with Eagle Schematic and PCB design tool which proved to be very useful to design the hardware. All sch and pcb parts were either included in the standard package or can be downloaded from the internet. The PCB size has been aligned to the dimensions of the plastic case. I found a local PCB manufacturer who helped with the gerber and drill files, gave me useful hints about pad sizes and even found me a soldering company for the SMD parts. The final product looked very good. There was a nice extension to Eagle using POV-Ray to create 3D preview images from the PCB so I can visualize the final product.

    POV-Ray 3D model of IR device PCB

    The device and the software had proven to be robust and stood the test of time. I built approximately 200 pieces. Recent version contains control codes for 30 different STBs, including SAT, Cable and IPTV boxes. After 10 years the solution still working and helps the NOC team to detect failures before our customers may complain. Moreover, STB device testers used it to evaluate STB firmware changes and new STBs, or rather, we sent it (along with our inhouse developed software) to two subsidiary company to help them in monitoring their local TV services.

    The Finished Product

    Two interesting problems arised after mass deployment.

    Sunshine
    There was an STB which cannot be controlled at the morning over an hour. To make thing even worse the problem shifted one minute later every day. After excluding other factors we began to suspect somehow the Sun causes the phenomena. We compared the outages with the sunrise and it did perfeclty match. There is a small window in the room where the sun can shine in right on the STB. The infrared light came from sunlight may interfere with the IR signal or the sunlight may overload the sensor on the STB. Either way, the solution was to shield the STB from direct lighting.

    Wrong functions
    Even using dedicated hardware we had problems with one STB. Sometimes it missed the function. This one is very sensitive to bit changes. I figured out that using an IR receiver to capture signals was not accurate enough to learn pulse widths. IR receivers demodulate the signal and using low sampling rates (ie. 1 MHz) in the logic analyzer (to capture the whole signal) can produce aliasing. I had to disassemble the remote controller and connect the logic analyser directly to the IC generating the IR signal. To measure the pulse width I chose a very high sampling rate (50 MHz). The analyser’s memory cannot capture the entire signal at such a high rate but it was enough to measure the pulse width very accurately. That way I adjusted the pulse timing and the problem vanished.

    Leave a Reply

    Your email address will not be published. Required fields are marked *