In order to comprehensibly describe functions of Egon, first, we have to briefly discuss the principles of infrared remote control.
We will not go unnecessarily deep into details - there is enough information on this topic on the web.
When a button is pressed on the remote controller, its infrared LED emits an (for the bare eye invisible) light signal.
Several informations are encoded in this signal. The method how this information is encoded is given by the protocol used.
There are tens of such protocols in usage. The probably most widespread protocol is RC5 by Philips. Basically, there are two
informations contained in the signal: address and command. Commands are mostly related to the pressed button. Address is
a number, which distinguishes remote controls using the same protocol.
As in the common ambient there are many significant sources of infrared light possibly interfering with the remote control
signal, a method for distinguishing this signal has to be used. The solution is to "chop" the the signal using a suitable carrier frequency. Common carrier frequencies range in 30kHz to 56kHz. As receivers, specialized integrated circuits are used, integrating a photodiode, preamplifier, bandpass filter and an output shaping circuit on a single chip.
Let's call "telegram" a single waveform which is transmitted when a button is pressed. As in the idle state the LED is not transmitting, each telegram starts and ends by a pulse. In fact, this is not a single pulse but a burst of pulses of the carrier frequency. Depending on the used protocol, there are several bursts and spaces in a telegram. In some protocols, sum of them is constant, in others this number changes.
The construction is based on my favorite microcontroller ATmega8. The main reason was implementation of the bootloader and the RAM size.
As USB interface, FT232RL is used. It contains an internal oscillator (making external crystal unnecessary) and also a configuration EEPROM. One of the configurable pins (CBUS4) can be used as 6MHz external clock source for the ATMega8 microcontroller.
As infrared receiver, SFH5110 (alternatively TSOP4838) is used, connected to the INT0 input of microcontroller.
The overall circuit is simple and can be found in egon.pdf file.
Prior soldering to PCB, the firmware (Egon itself plus the bootloader) has to be programmed into the microcontroller, and the Fuses and LockBits have to be set. All the needed files can be found at the bottom of this page, in Download section.
Later, the firmware of Egon will be upgradeable simply using the bootloader.
After connecting the finished Egon to PC, the FT232RL has to be configured. From FTDI's webpages, download the
VCP driver
and configuration utility
Mprog. After installing the driver, start Mprog and perform the configuration according to this picture:
Now, Egon is fully functional (or maybe after giving it a single reset). You can try it according to the
Software description chapter.
In order that Egon could properly receive and understand an IR telegram, it has to "measure" the lengths of all bursts and spaces. For time measurement, Timer 0 is used, with prescaler set to 256. So, as the processor clock is 6MHz, the timer increments in 42,7µs steps (this determines the resolution) and overflows after more than 10ms.
In the current version, Egon can receive 17 different protocols. I have assigned each protocol a number - for example, 0 for RC5, 2 for JVC, 3 for NEC etc. If the received telegram is recognized, Egon sends a unique identifier of this telegram to PC. Each identifier has 3 bytes, which are sent in the following order:
1) Protocol number
2) Command (button) number
3) Address of remote controller
If the ASCII mode is chosen (see details later), each byte is transmitted as two hexadecimal digits; and the identifier is terminated by the CR, LF (line end).
Egon has two basic modes of operation and several optional settings. When switched on for the first time, it is in the normal mode and is set optimally for
EventGhost. It uses the following fixed communication settings: 57600 Bd, 8 bits, 1 stopbit, no parity, no handshake.
Although Egon communicates via USB, thanks to the drivers it behaves exactly if it would be connected to serial port. It means, that for communication with, and setting up Egon, any terminal emulator program (which can be set to the above parameters) can be used.
Each command starts by an asterisk (*) followed by capital letters. Any other character is ignored. The following picture illustrates how Egon responds to the
*HELP command:
There are two types of commands: Temporary commands, and Configuration commands. As their name indicates, the first type of commands act only temporarily, while the second type is permanent (until an opposite command is entered), even after removal of power (configuration is written into EEPROM).
In the following, all the available commands (listed also on the HELP page) are explained:
*HELP
This command displays the helppage as above.
*BUFFER
This command prints out the current content of memory (buffer), which stores data from the received telegram. First byte is the total number of subseqent bursts and spaces. Second byte is the length of first burst, third is the length of first space etc. In the given example, the telegram has 19 (= 13 hexadecimally) bursts and spaces. First burst lasted for about 853µs (20 * 42,7), while the length of the first space was about 896µs (21 * 42,7).
The last identifier Egon transmitted just before the *BUFFER command is "001105". It means, that this was an RC5-protocol command number 11 (hexadecimally), and the address was 5.
*EEPROM
The *EEPROM command is to be used to control the content of internal EEPROM of ATMega8. In the given example, most of the memory is unused. Most of the used space is taken up by definition of commands (data string beginning by 07, 41 and ending by 50, 00).
The byte in red circle (09) contains Egon's configuration. The area in green circle at the end of EEPROM memory is the "Chip Erase Counter", where the Bootloader stores how many times the chip has been erased. In the given example, the counter contains 55 (0037 hexadecimally).
*STATUS
Using this command, the current configuration of Egon can be checked.
*VERSION
Egon responds to command *VERSION by displaying its identification including the version of SW. The homepage of Egon is displayed, too.
*TIMING and *NORMAL
When analyzing an unknown IR protocol, several IR telegrams have to be recorded. This is the purpose of *TIMING command. As shown above, after entering this command the prompt changes to "Timing first buffer ...". After the first IR telegram is received, the prompt changes to "Timing second buffer ...". After the second buffer is filled, both buffers are displayed and the prompt changes to "Command ?". In this moment, Egon ignores all IR data and expects some command. Any command can be entered (e.g. *TIMING again), but returns to normal mode only after entering *NORMAL command.
The format of data displayed after *TIMING command is almost the same than that described by the *BUFFER command. This time, Timer 1 clocked at 6 MHz is used for timing measurement. Length of each burst and space is then displayed in 256 times higher precision, using two bytes.
The explanation, why are there two buffers read and displayed, lies in the fact, that in some of the protocols, when a button is pressed for second time, instead of repeating the telegram a special command is sent. With only a single buffer, it would be difficult to capture this special command.
*UPDATE
Purpose of this command is obvious - use it to upgrade Egon's firmware. Above, Egon's response is displayed. The characters under "Update firmware ..." are displayed by the bootloader running and waiting for AVRProg. After entering this command, close the terminal emulator program (to release the port) and start AVRProg. The bootloader waits for AVRProg for approx. 10 seconds, after which returns to Egon's firmware (performs a standard reset). For more details on the bootloader see my biprog programmer's pages.
*ASCII1 a *ASCII0
This couple of commands belong to the four (pairs of) configuration commands. If the ASCII parameter is OFF (after *ASCII0), Egon sends all identifiers, content of buffers and EEPROM, in binary form. This format is not suitable for displaying, but may be necessary for certain programs (e.g. Girder). However,
EventGhost requires ASCII mode ON.
Note on the subsequent pictures, that after each configuration command Egon displays the current configuration status.
*SPACE1 a *SPACE0
This command is valid only if ASCII parameter is ON. It enables to insert spaces between individual bytes of identifiers etc. For some, this mode is more readable, but when used with
EventGhost, it is better to have SPACE mode OFF.
*RAW1 a *RAW0
When parameter RAW is ON, Egon transmits int PC both recognized and unrecognized telegrams. The format is identical to that described for *BUFFER command. In order that the RAW telegrams could be easily distinguished from recognized commands, one byte of "FF" (255 decimally) is inserted before the byte indicating the telegram's length.
*SUPPRESS1 a *SUPPRESS0
The last parameter is SUPPRESS. It suppresses reporting of spurious short signals. Of course, this option is meaningless in other than RAW mode. When SUPRESS is OFF, even single bursts (with no spaces) are reported.
About EventGhost
In my opinion, EventGhost is an extraordinary software. Primarily it is intended for remote control of PC, but can be used also for other purposes. Its most valuable feature is, that any function can be added, using Python scripts.
Setting EventGhost to cooperate with Egon
After running the program, first, insert Serial port plugin into the configuration tree.
Click on the icon (or choose Edit - Insert Plugin ...), and the following window appears:
To insert the plugin, click on Serial port and confirm using OK. The following dialog appears:
Fill in as displayed here. Instead asterisk "*", as the event prefix, any word can be used. A short word is recommended, for example "Egon".
The Port item has to be filled in according to the settings of the FT232RL VCP driver.
When all the items are properly set, finish the dialog pressing OK. Since this moment, EventGhost should receive the remote control commands. Of course, the whole EventGhost application has to be properly configured, but such a description is beyond the scope of this document.
