Rebuilding the Olevia LT19W 19-inch LCD TV Remote Control Unit

I have here in my room an Olevia LT19W 19″ LCD television that has no remote control unit. The buttons for this TV are located on the top panel so it would be a hassle to change volume or channel while watching. I decided to buy the RM-68 universal remote control from eBay hoping that I will be able to configure it to be used for my TV.

Unfortunately, I was wrong. None of the suggested codes I found online could make the remote control work with my TV. I also spent half a day trying most of the codes listed in the instruction manual, but none works. My last try is to use the auto-search mode, which automatically tries all supported codes to see which one works:

Finally after 20 minutes of pressing the VOLUME+ key, I got my TV not to show the volume control as expected, but to display “Normal” at the bottom of the screen. What should be the volume control key turned out to be the key to change the “Picture Mode” of the TV. The TV also recognized some other keys on the RM68 but the mapping was wrong. For example, pressing channel 2 on the RM68 would turn off the television! In other words, although the TV responds to some keys on the RM68, it can’t be used.

I then had an idea. Since I had quite a few keys on the RM68 working, I may be able decode the remote control protocol for this TV. build a PIC-based remote control to simulate other keys and map them to a learning remote controller, which will be used in the long run.

Decoding the protocol

My initial research shows that most TV remote control use consumer IR which transmits using an infrared wavelength of 930 nm, 870 nm or 950 nm at carrier frequency between 33 to 40 kHz or 50 to 60 kHz, with 38kHz being the most common. To decode the protocol, I picked up a TFMS 5400 IR receiver from my junkbox, which is optimal for 950nm infrared @ 40kHz carrier frequency. Although the RM68 transmits at 38kHz, the “Relative Frequency” graph on page 3 of the datasheet shows that the TFMS 5400 would still detect 38kHz signal, just at 95% of the sensitivity. Following the datasheet, I built the receiver and fed the output to channel 1 of my Rigol DS1052E oscilloscope:

By pointing the remote controller at the receiver and pressing a few keys while observing the oscilloscope display, the protocol soon became clear. Each key will transmit a data stream, consisting of an ID byte identifying the TV and a data byte identifying the key, in the following format:

[header] [ID byte] [~ID byte] [data byte] [~data byte]
where ~ represents bit-wise NOT operation

The output of the receiver is active low and will remain high if there’s no signal received. Each data stream starts with a header consisting of a low pulse for 9ms followed by high pulse for around 4.3ms. The ID byte (which is 8 for the Olevia TV) and its complement (e.g. bit-wise not) is sent following the header. After the ID byte is the byte for the key pressed, and also its complement. Binary 0 is represented by a pulse for 0.5ms and binary 1 by a pulse for 1.6ms. There is a delay of 0.6ms between every bit. Bytes are sent in little-endian format, with the least significant bit being sent first. Depending on the key pressed, the data stream may last anywhere between 50 and 90ms.

For example, the following data stream represents the POWER key, whose data byte is 0b00000010 (2 in decimal)

[9ms low] [4.3ms high] 00010000 11101111   01000000 10111111

The following screenshot from the Rigol oscilloscope shows the header and the ID byte:

Building the transmitter

To be able to simulate the rest of the keys, I used a PIC16F628 and a TSAL 7400 IR LED, with the information available here to build the transmitter circuit:

For the receiver to be able to pick up the transmitter signal, the transmitter needs to modulate the signal at around 38-40kHz. Since the receiver receives in active low, this means pulsing the output at 38-40kHz for around 0.5ms for a binary 0, and staying low for 1.6ms for binary 1.

But how do I actually pulse the output at the required frequency? Luckily the receiver is quite tolerant and any transmitted frequency within the the expected range will work. I used the assembly source code from here and modified it to suit my needs. NOP instructions are used to generate the required pulse frequency, as seen in the following code snippet:

IR_pulse                
        MOVWF    count        ;  Pulses the IR led at 38KHz
irloop        BSF    IR_PORT,    IR_Out
        NOP           
        NOP           
        NOP           
        NOP            
        NOP           
        NOP           
        NOP           
        BCF    IR_PORT,    IR_Out
        NOP           
        NOP           
        NOP           
        NOP           
        NOP           
        NOP               
        NOP           
        NOP               
        NOP           
        NOP           
        NOP
        NOP
        NOP           
        NOP           
        DECFSZ    count,F
        GOTO     irloop   
        RETLW    0

If you’re not an assembly guru who knows exactly how many CPU cycles each instruction will take and is able to calculate the output frequency easily, you’ll need an oscilloscope and lots of trial and error to get the desired output. This is when the Rigol DS1052E limited memory becomes a hassle. You will need to set the the TIME/DIV setting to a reasonable value that allows you to view the entire transmitted stream, but not at the expenses of losing too many sample points. Even at 1 mega samples of memory in long memory mode, signal aliasing may occur if the TIME/DIV is set so high that the oscilloscope can’t capture enough samples. For example, the following puzzled me for a few minutes when I attempted to transmit a sample data byte:

The code pulses the output at 38kHz, but from the oscilloscope screen, it seems much less. However there was nothing wrong with the code, all that was needed is to lower the TIME/DIV settings and capture the output again:

This is the transmitted signal:

Applying “invert” on the input channel on the Rigol oscilloscope, I got the transmitted signal to resemble the received signal:

The PIC-based transmitter now works properly and the TV responds to it as how it did for the universal remote controller.

Simulating other keys

By varying the data byte, I am able to simulate many other keys. The full list of keys and their data bytes can be found in the following table:

With this, I am able to get my learning remote controller to learn the above keys and use it as the main remote controller for my TV.

The assembly source code can be downloaded here. It will repeatedly transmit the data stream for the “Channel 1″ button. Unfortunately I could not find the data bytes for many other important keys, such as the volume control and TV/Video switch button. Perhaps these keys have data bytes outside the range I tried, or require a different protocol. I hope somebody with more time and expertise at PIC assembly programming can use my code and find out how to simulate these keys…

Reference:
1. Infrared TV Remote Decoder
2. PIC Tutorial Five – Infrared Communication