psfales@ihlpe.ATT.COM (Pete Fales) (11/04/87)
A while back, there was a discussion here about programmable remote control devices. I described one that I had build and as a result had several requests for more information, information that I did not then have available. One response suggested writing the "definitive Netnews article" on the subject. I don't know if I would call the following definitive, but I enjoyed writing it. I hope others find it interesting as well. ------------------------------- cut here ------------------------------ A Multi-Device, Multi- November 3, 1987 Media Remote Programmable Remote Control P. S. Fales _C_i_r_c_u_i_t__D_e_s_c_r_i_p_t_i_o_n 1. IIIINNNNTTTTRRRROOOODDDDUUUUCCCCTTTTIIIIOOOONNNN Recently, I described briefly on Usenet a handheld infrared/ultrasonic programmable remote controller that I designed and built. That brief note generated several requests for more information. So, as a result, I decided to put together the somewhat more detailed written description you have before you now. The following description will probably make a little more sense if a copy of the schematic is available for reference. I would be happy to provide a copy of the schematic to anyone who sends me a Stamped, Self-Addressed Envelope. A copy of the software may be had (for what it may be worth) by sending an IBM-PC formatted floppy, mailer, and appropriate postage. My address is Peter Fales AT&T, Room 1Z-243 1100 E. Warrenville Rd. Naperville, IL 60566 One problem with describing my work in detail is that the project was never intended for use by anyone other than myself, so many of the design decisions were made to facilitate my own development and use, but might not be as useful to others. These limitations show up primarily in the software arena - for example, the controller is not "trainable" in the sense that a commercial product might be. The codes for all devices to be controlled are hard-wired into the assembly language program that runs inside the controller and adding a new device consists of adding the appropriate tables into the program, assembling it, and downloading the new program into the controller. For this reason, I will discuss the hardware and software in more of a general overview, hopefully in a form that - 2 - would be useful to someone attempting to construct a similar project. 2. HHHHAAAARRRRDDDDWWWWAAAARRRREEEE DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN Much of the background for the MC came from an article in Byte Magazine by Steve Ciarcia.[1] A block of diagram of the Multi-Controller (hereafter referred to as MC) is given in figure 1. The various components of the controller are each described in more detail in the following sections. -------------- -------------- ------------- | RS-232 | | | | Infra-Red | | Serial |----------| |----------| | | Interface | | | | Receiver | -------------- | | ------------- | | -------------- | Hitachi | --------------- | Keypad | | 63B03X0 | | Infra-Red | | |----------| Micro- |----------| | | Interface | | Controller | | Transmitter | -------------- | | --------------- | | -------------- | | --------------- | LCD | | | | Ultrasonic | | |----------| |----------| | | Interface | | | | Transmitter | -------------- -------------- --------------- | ----------------------------- | | --------------- ---------------- | 32KB NVRAM | | 16KB ROM | --------------- ---------------- FFFFiiiigggguuuurrrreeee 1111.... MC Block Diagram 2.1 MMMMiiiiccccrrrroooonnnnttttrrrroooolllllllleeeerrrr The heart of the MC is a Hitachi 63B03X0 single-chip microcontroller. This is a 64 pin CMOS device with a large assortment of on-chip functions including: +o 192 Bytes of RAM +o 24 Input and Output Pins - 3 - +o 2 Programmable Timers +o Serial Communication Interface (UART) +o 64K Byte External Address Space All of these features came in handy in the MC implementation. 2.2 SSSSeeeerrrriiiiaaaallll IIIInnnntttteeeerrrrffffaaaacccceeee The 6303 microcontroller includes a built in UART which makes the job of communicating with the outside world quite simple. The RS-232 interface circuitry is notable for a couple of "tricks" that are used in its construction. As pointed out in the Byte article, this does not have to be a general-purpose RS-232 interface. Since we know exactly what we are going to be talking to (in my case, an AT&T PC-6300 computer) it is possible to play some tricks to reduce component count as long as it works with this computer. Strictly speaking, an RS-232C receiver is supposed to treat any signal between -5 and -15 volts as a logic "1" and anything between +5 and +15 volts as a logic "0" with the range from +5 to -5 being undefined. In practice, many receivers, including the one in my computer, will treat anything close to +5 volts as a logic "0" and anything close to 0 volts as a logic "1." This means that a TTL or CMOS inverter can be used as an RS-232 driver. Since I didn't have an spare inverter, but did have half of a 74HCT74 flip-flop, I used that as a (somewhat slow) inverter by clocking it at 2 MHz, the highest frequency I had available. The RS-232 receiver is a simple RTL inverter with a diode clamp to keep the input voltage from going too negative. If I was doing another design, component count could probably be reduced even further by using one of the spare op-amps in the LM324 used by the IR receiver. 2.3 KKKKeeeeyyyyppppaaaadddd IIIInnnntttteeeerrrrffffaaaacccceeee The keypad interface is simply six pushbutton switches wire in a 2 by 3 matrix and connected to two output pins and three input pins on the microcontroller. They are scanned using software on the microcontroller. I had some difficulty deciding how many buttons to implement and what functions to assign to them. This is easy to change as everything is handled in software. I - 4 - finally decided on the following assignments: +o Two buttons are used to scroll forward and back through a list of "devices" which is displayed on the top line of the LCD display. A "device" may correspond to an actual physical device such as a television set or compact disk player, or may be assigned in any arbitrary fashion. +o Two more buttons are used to scroll forward and back through a list of "functions" that the device can execute. These are displayed in the second line of the display with two functions displayed at any given time. Typically the functions which are paired together have some intrinsic relationship such as "Channel Up/Channel Down" for a TV or "Skip Forward/Skip Back" for a CD player. +o The last two buttons are used to select and execute one of the two "functions" currently displayed on the screen. 2.4 LLLLCCCCDDDD IIIInnnntttteeeerrrrffffaaaacccceeee The LCD display is an Optrex DCM20215 which is a twenty character by two line display. It is very easy to connect to the microcontroller using six output pins: four for data and two for control. Since the use of this display is described in detail in the manufacturer's data sheet[2] as well as the Byte article, no further details are provided here. 2.5 IIIInnnnffffrrrraaaarrrreeeedddd TTTTrrrraaaannnnssssmmmmiiiitttttttteeeerrrr This portion of the MC is also very similar to that described in Byte, so again there will not be too many details. The key feature is that an 82C54 programmable timer is used to generate a carrier with whatever frequency and duty cycle (within limits) is needed by each device to be controlled. The job of the central microcontroller is therefore reduced to modulating this carrier on and off. This greatly reduces the load on the micro (and the complexity of the software) and also reduces the volume of data associated with each function to a manageable size. The carrier is gated on and off using the "output level" bit of the programmable timer contained within the microcontroller. This bit can be programmed to change state from low to high or vice versa when a specified value is attained by the free running internal counter. This also serves to eliminate the need for complex timing loops and cycle counting in the code - 5 - for the microcontroller. The output of the timer chip is used to control a CMOS power transistor connected to two IR LEDs as well as a visible LED. The visible LED is present only to provide some feedback to the user that the MC is operating correctly. 2.6 UUUUllllttttrrrraaaassssoooonnnniiiicccc TTTTrrrraaaannnnssssmmmmiiiitttttttteeeerrrr The only device with an ultrasonic remote control that I was interested in (in fact, the only one I'm aware of) is the BSR X-10 home control system. This system has been described in a number of places, including an article in Byte Magazine that provides a number of details on the X- 10 system and how control signals are sent to appliances over the AC wiring.[3] The format of the signals transmitted by this remote control is known and has also been published in Byte.[4] These signals are very similar to those transmitted by the Infra-red controllers - so similar that all that was necessary is an ultrasonic transducer in parallel with the IR LEDs used to transmit the IR signal. I am still trying to locate a good source for Ultrasonic transducers. The one I used was obtained by cannibalizing the BSR controller which is a rather expensive way to go. 2.7 IIIInnnnffffrrrraaaarrrreeeedddd RRRReeeecccceeeeiiiivvvveeeerrrr The IR receiver is also similar in principle to the one described in Byte. An LM324 Op-amp configured as a voltage-comparator is used to amplify the signal created by the IR photodiode. One problem I ran into is that most typical photodiodes and phototransistors such as those sold by Radio Shack and mail order houses are simply not fast enough for this application. Most bipolar photodiodes and phototransistors have switching times of around 10 microseconds, and with the transitions of a 40 KHZ carrier occurring about every 12 microseconds, it just doesn't work well. Instead, it is necessary to use a PIN (Positive-Intrinsic-Negative) photodiode which typically switch in well under one microsecond. The TIL413 diode used in the Byte article is a PIN diode. I used an SFH205 photodiode purchased from Active Electronics, Framingham, MA. The amplified signal from the diode is fed into another of the microcontroller's timer input pins, the "input capture" pin. The input capture register can be programmed to latch the state of the internal free running counter whenever a low-to-high or high-to-low transition - 6 - occurs on this pin. Since this counter runs at 2 MHZ, any interval can be measured with 0.5 microsecond resolution. By measuring the time between successive low-to-high transitions, the carrier frequency can be determined, and by measuring the time between the low-to- high transition and the next high-to-low transition, the duty cycle can be found. Determining the modulation pattern for the carrier is more difficult, but not greatly so, and is also similar to that described in Byte: 1. Wait for the first low-to-high transitions. This marks the start of the first carrier ON period. 2. Start capturing high-to-low transitions until no transition occurs for 40 microseconds. At this point, the last captured transition marks both the end of the ON time and the start of the OFF time. 3. Start capturing low-to-high transitions. When one occurs, it marks the end of the OFF time and the start of the next ON time. 4. If no transition occurs for a long period of time (50 milliseconds), the entire bit pattern has been recorded. In my case, the information created by the above procedure is dumped out as a table of numbers that is then incorporated into the program that runs the MC. 2.8 RRRROOOOMMMM The MC includes 16K of Read Only Memory (ROM) containing the program that is run at boot time. Normally, this code does nothing but immediately transfer control the real program which is downloaded into RAM. However, if a button on the keyboard is held down while the MC is turned on, it does not execute the downloaded program, but instead starts executing a simple monitor program contained in the ROM. This monitor program is based on Motorola's Probug monitor and works over the RS-232 serial port. It allows the user to examine and modify memory, display registers, jump to a specific location, etc. Most importantly, it allows the user to download a new program or data from the host computer. This program is stored in RAM and is the program that actually provides the MC functionality. - 7 - 2.9 NNNNVVVVRRRRAAAAMMMM The MC also contains 32K of Non-Volatile Random Access Memory (NVRAM). This is implemented using a 32K byte CMOS RAM, along with a DS-1213C "Smart Socket." The "Smart Socket" is a handy device manufactured by Dallas Semiconductor. It is a 28 pin IC socket containing two lithium batteries, and associated control circuitry such that the internal batteries provide power for the RAM whenever the external supply voltage is removed. This RAM contains all the code which is normally executed by the MC including the user interface, the device description tables, and the code for capturing descriptions of new devices. 2.10 PPPPoooowwwweeeerrrr SSSSuuuuppppppppllllyyyy The power supply is simply a 9 Volt battery connected to an LM2935 Low-dropout voltage regulator. 3. SSSSOOOOFFFFTTTTWWWWAAAARRRREEEE As previously discussed, the software for the MC consists of an assembly language program assembled on a remote computer and downloaded into the MC through the serial port. This code controls all functions handled by the MC including the user interface (i.e. determining the functions of each button on the keypad), the menu of available devices and functions, and the actual tables of information for each device. My current implementation includes about 13.3K bytes of code of which the majority (about 10.6K bytes) consists of the descriptive tables for each device. One additional feature is used in these tables to further the reduce the amount of data needed. A chaining or "goto" capability allows different sequences to to be strung together and share common descriptions. For example, consider channel selection on the cable TV decoder. This requires the selection of one or two digits followed by the "enter" key. Since all sequences end with the "enter" key, it is not necessary to duplicate that table for all channels to be selected, but instead the table for "enter" can be stored in a single location and all the other channel selections can chain to it as necessary. This technique can be extended even further - for example selection of channels 03 and 33 (followed by enter) both share common data for the final two signals. - 8 - Using this technique I currently have tables for 8 different devices with a total of 40 separate functions stored in the controller. As mentioned, this takes less than 14K for all code and data leaving plenty of room in the 32K RAM for future expansion. 4. FFFFUUUURRRRTTTTHHHHEEEERRRR IIIINNNNFFFFOOOORRRRMMMMAAAATTTTIIIIOOOONNNN I enjoy discussing this sort of thing and would be glad to entertain further questions. Just remember that I am not getting paid for this, so I will not be able to provide any responses that take a great deal of time or effort. You may reach me either to the mailing address given in the introduction, or at my uucp address, ...ihnp4!ihlpe!psfales. --PSF P. S. Fales - 9 - _R_E_F_E_R_E_N_C_E_S 1. Ciarcia, S. "Build a Trainable Infrared Master Controller." Byte, March, 1987. 2. Optrex Corporation. "OPTREX Dot Matrix LCD Module - Character Type DMC Series" 3. Ciarcia, S. "Build The Home Run Control System - Part 2: The Hardware." Byte, May, 1985. 4. Ciarcia, S. "Computerize A Home." Byte, January, 1980. - 10 - -- Peter Fales UUCP: ...ihnp4!ihlpe!psfales work: (312) 979-7784 AT&T Information Systems, IW 1Z-243 1100 E. Warrenville Rd., IL 60566