About IR remote control ======================= Since seeing Lorell Joiner's article on Model Railroader Jan 1990 I've desired to build a wireless throttle/controller. Tapiola club already had at that time a operating C/MRI lookalike computerized cab control system, so all that still was not quite the way I desired was the wire between walkaround controller and layout. Preamble (basics about IR transmission) ======================================= There are some basic things that needs to be taken into consideration while trying to make a IR remote control: Almost everything warm radiates infrared light. We must be capable of figuring out if our transmitter is sending IR light irrespective of the background IR radiation. One way to select is the light wavelength. Most IR LED's radiate at 940nm (nanometre), but that is not good enough. Let's make a test: If you consider yourself looking through a matt glass you can see all colours of spectrum either directly lighting the matt glass or reflecting from surfaces. Your eye now represents the IR receivers photosensitive part. As our eyes are not sensitive to IR light well choose to be selective to white light, similar to camera flash light. We now open our eyes, looking through the matt glass. We have no way of saying if pure white light is being radiated from our IR- ... oops... pure-white-sender, as you have nothing to compaire the intensity of white light to. Now supposing a camera flash operates nearby. You'll sure register this flash, as the intensity of white light went up and down, so, is is this a bit of information? No, it wasn't! Someone just opened a door, and sun was reflected to your matt glass through the glass pane of the door. You'd have quite a miserable day trying to figure out which flash is the camera flash you were to respond and what was just odd reflections from whatnot. Now someone tells you, that if you see ten repeated flashes within two seconds, that is your signal. That is equivalent to modern cameras flash bulb flashing to get the iris of your eyes shut before the big flash hits your face -- so that your eyes would't look red. Now you have less difficulty in recognizing the signal, as it has distiguishabe pattern, the flashing frequency. This is called the carrier frequency. It is easy to make the IR LED flash at certain rate, and it is possible to create a electronic filter that passes signal only in case it flashes at a certain rate. This is the fundamental thing in making IR gates and IR transmitters, you need to be able to distinguish the light that comes from the real sender irrespective of general light intensity variations. With IR remote control there is of course a possibility that something else is flashing at the same rate nearby, so our selective part should be very clever and notice that as that flashing is so dim (too far away) and is constant, you should adjust the filter so that that amount of IR-light flickering at correct frequency should be ignored. This is called automatic gain control. The gain control system is so designed that in case the flickering is constant it will reduce the internal amplifiers gain to a level where no signal gets through. It also means taht our signal must be intermitted. We must provide short bursts of IR light flashing at carrier frequency so that there will be moments of nothing sent to assist the automatic gain control. All this and much more should be taken into consideration while building a IR receiver. Luckily there are commercial IR receiver modules that have the colour filter, utomatic gain control etc all built in. Those are of course sensitive to only certain carrier frequency, and have maximum burst length (and minimum, to again distinguish false flickering). Backwards engineering Lorell Joiners system =========================================== Lorell Joiner's article was written by the Joiner's team, but certain things were (deliberately?) left out, and Model Railroader editors propably patched those without knowing how. One of those things was a description of packet format. I could not figure out at the time how Joiner's IR-transmitters message collision detection system could work. The bits were described as being either 10us 250MHz carrier (1) or 10us silence (0). The packet had 8 bit payload and two extra bits were shown in an illustration drawn by MR staff as added to the end of payload. I could not understand how the receiver could figure out the outer limits (beginning and end) of the message as the first bit or bits were part of the "payload" and could easily have been all zeros, hence apparently shortening the message. I did send a $15 to Mr joiner to receive full description, as it was offerd at a fee of $11. Nothing ever came back. These things do to happen, I've learned now... Tapiola club has for some time now used Lars Lundgren's TMWDCC system, which is based on Michael Brandts DCC-MB. The key thing is that a PC is used for creating the DCC messages. PC Joysticks are "cut in half" so that throttles/controllers consists of one pot for speed and a button for direction control. DCC functions are controlled by pressing the direction button once or more times while the train is in motion. If the train is halted, the button acts as direction button. Mr Lundgren is developing a new version of TMWDCC, and that has a RS485 network between throttles/controller and computer. There are also radio linked throttles, but as the approved radio link modules (with document of conformity) are either hard to come by or too expensive so, IR link is – at the moment -- the only way to go). While going to an excurion to Turku club in 2001 I travelled with an old friend of mine, Mr Koskela, the fellow who designed our C/MRI-lookalike that we used in our previous layout. We started to discuss about this matter and realized that there are now excellent IR receiver modules on the market that require no analogue circuits. We decided to start for a search of suitable components and try the Lorell Joiner's idea from a fresh start. I found a component outlet that sells Vishay Telefunken's TSOP17xx modules and Siemens LD271 IR-leds: Vishay Telefunken TSOP17.. IR-module: http://www.vishay.com/search?query=TSOP1738 LD271 IR-LED: http://batronix.com/pdf/ld_271.pdf Mr Koskela found web pages describing possible solutons for the transmission protocol to look into - the Holger Klabundes RC5 devices using PIC processors and description of Philips RC5 code: Holger Klabunde's PIC RC5 projects: http://www.holger-klabunde.de/rc5send.htm RC5 protocol: http://www.wolfgangrobel.de/electronics/rc5.htm We decided that we'll start from barebones control and after we get a working protype that we can test in real life situation we'll try something more fancy. My first trials weren't so successful: I used only 130 mA to drive the IR-led and needed to aim the transmitter to the receiver to get proper transmission. Mr Koskela then pointed out that I should read the Siemens data sheet more carefully, as even 3A current could be used intermittedly. I replaced the current limiting resistor to smaller one (1.8 ohms at 5 volts supply voltage) and got 1A going through the LED! Great! At home in my workshop I could get transmissions working in a 12 m2 (120sq.ft) room even without pointing the transmitter to anything in particular. Then I started to figure out how the transmision protocol should work. I first tried the RC5 coding for bits but with shorter words (only one start bit, 8 bit payload and a parity bit). I noticed that some of our home remote controllers could mess up the system, as the original RC5 messaging could contain sections similar to codes accepted by mine. I then choose to shorten the bit duration close to the limit of TSOP17XX series. It fixed the problem. The need for shorter messages is also clear as we need to have as many non- colliding packets per second as possible. This is limited by the carrier frequency and the TSOP17XX series module's need of at least 10 cycles of carrier. Joiner had 250 kHz carrier and hence had much shorter packets and could increase packet number per second far beyond what we can! I then needed to figure out the message format. I first tried the method used by Lorell Joiner, where one message ment increase speed another for decreasing speed. In case accelerator button is held down constantly the speed will be stepped up at constant rate. Likewise I also wanted a possibility to pump the switch so that I could increase the speed by one step with each press. The problem is that what if a packet or two gets missed. Will the speed be increased by constant rate or will the packets be "pumped". First I resolved this by sending null packets to this address if the button was released, so that the receiver could notice that I've released the button, and that it could separate between no pressing of button and disturbed transmission. I then thought that I'd also like to have a potentiometer controller/throttle. I searched the internet for a solution of getting PIC16F84 to do analog/digital conversion. The only one I found was so clumsy: reading pot: http://www.piclist.com/techref/microchip/seepicsrc/psbpix/pot.htm I thought that there must be a more easier way. I choose to investigate the PC joystick method again: PC-joystick: http://www.epanorama.net/documents/joystick/pc_joystick.html I choose to use 1M potentiometer but as Microchip data sheet says that 50pF is the maximum capacitance one can connect to input I got completely mixed up. The PIC POT example I found in the internet showed a huge capacitor. I the resolved to use 1M pot and 33+47 = 80pF capacitors, plus a 10K resistor at the top of the pot. I'm not entirely happy with this, I get no change at both ends of the pot travel. Must investigate further. How to get the receiver understand the pot transmitter? If I was to send a increase speed command when the speed control knob was turned cklockwise I could end up in having the pot turned to end position but due to missed packets the receiver could be half way. In decreasing the speed this could be even more disasterous. Hence I choose to send the actual speed setting. The speed counter for button version is within the transmitter and the analog/digital conversion result is sent with the pot version transmitter. Yes, I've heard of encoder wheels, but... The next problem was packet interval. If the packet interval is the same with all transmitters and in case two transmitters start at exactly the same time they will ruin each others packets, and no packets will ever reach destination. Joiner used very high modulation frequency, thus his packets were quite short and he had different packet interval for each handheld. As we use 38kHz (38,5kHz to be exact) we can only manage to theoretically squeeze 100 packets of 10 ms duration into one second, and I desired to have at least four handhelds operating at one time, so I choosed to use 40ms interval and increase that up to 70 according to address, hence the propability of two transmitters constantly ruining each others messages is propably low. I had two transmitters built, one is a pot version (on breadboard) and the other with buttons. For test purpose I built the pot version so that it will send continuously so that I coud test for collisons. I found that I can still well fit the button transmitter command within the pot transmitters messages, so at least with two transmitters I'm having no problem from collision. My ex. boss Mr Niinikoski suggested that I'd try CAN BUS collision detection method as it has the advantage of the other packet getting through althoug the packets would collide: CAN protocol: http://www.kvaser.se/can/protocol/index.htm As this needs two way transmission for collision detection I opted not to try that for now. In future I do wish to try two way transmission. There is another thing that also prevents using CAN bus presently and that is that I'm forced to use multiple IR receiver modules (something like three modules at the club and propably a lot more in exhibitions as big halls provide less reflections) and then the transmitters will not be able to see the collisons to end transmission if stronger packet gets sent simultaneously. The RC5-type system, where both the ones and zeros have certain formation that includes active transmission and silence also prove to assist in error checking. How to interface TMW-DCC, the first version =========================================== The next thing to worry about was: how to get this newly designed system interact with the TMW-DCC? To make it quick and dirty I opted to replace the analogue throttles (joystick stuff) with resistor network that I could control with the remote system. To start with I choose to use 15 different speed steps (4 bits) and that meant using four resistors and shorting those with C-MOS 4066 switches. http://www.onsemi.com/pub/Collateral/MC14066B-D.PDF To get four throttles working I needed 16 output wires for them, and four additional C-MOS switches for controlling the direction buttons (speed or functions). The resistors and direction switch outputs were connected to quad RJ45 type connectors and RJ-patch cables were connected between the receivers RJ-45 panel and the original systems throttle panels. In addition to this we needed some kind of display to show and prove ourselves that the IR link was working and speed was actually being changed. I choose to give each throttle a dedicated 7-segment dispay unit, use the hex numbers to display the speed setting (0..F) and the desimal point for the direction switch. The number of lines to control grows beyond the number of pins available in the PIC16F84 processor, so I choose to put both the joystick stuff and the display stuff in two separate latching shift register chains: the chains consisted of C-MOS 4094 shift registers that had serial in and output pins and 8 parallel latched outputs. http://www.onsemi.com/pub/Collateral/MC14094B-D.PDF The data was "morsed" in through data, timed with clock and latced with strobe line. So, for displays only three wires (plus feeders) were needed. The joystick resistor network shorting C-MOS switches were also operated with another similar chain of 4094 shift registers. I could combine the data and clock lines so that I could handle the speed, diection and diplay with four pins of PIC. Not bad. The IR transmitter packet then consisted start bit (0) two bits to recognise the IR throttle in question a spare bit, direction bit and four bits for speed, and the final parity error check bit. To aid transmission reliability all data is sent three times (later 10 times) after last change of controls, so that in case a packet or two gets missed the system still works. To test the collision detection system I modified the other of the two transmitters so that it sent continuously. It proved that I had no problems in getting through with the other transmitter. Before the Model Expo exhibition I choose to make use of the extra bit by introducing another feature: It would be fun be able to let the IR receiver do the TMW-DCC function control morse keying. If the spare bit was 1, the "speed bits" showed the function buttons number that was pressed. The receiver was then modified so, that in case the speed was zero, it first adjusted the speed to step one and the morsed the functon key sequence and returned the speed back to zero. If the speed was off-zero in the beginning the speed control gimmick was skipped and only the speed button morse keying was done. One could watch the function key sequence by looking at the desimal dot flicker slowly. Fun! The three-day Model-Expo 2002 show is now behind, and the system worked well! The fisrt two days we only had one transmitter, but the last day we operated with two, the other one having the function buttons also! We did once get a situation were the receiver ended responding, and the lights on the 7-segment display started to fade, but I trust this to be related to the fact that the 3.5mm jack I used for the TSOP modules connector is so louzy that it does not hold the plug. If it gets loose the power and ground gets shorted. We had three TSOP1738 IR-modules, and there were little or no dead spots within the layout perimeter. I did have a lot of problems trying to set up the IR- module party line, but that was only due to my own stupidity: Before the exhibition I assembled the receiver modules at home. I purchased 5 metre headphone extension cables and cut the cables near female connector and inserted the TSOP-module with small cap and resistor as described in the data sheet. I inserted diodes between the TSOP output and control line and added a LED with current limiting resistors to the TSOP output so that I could see that this TSOP does receive signal. I got a bit worried about the strength of the grounding properties (the TSOP grounded the output at a few milliamps if it received IR transmission). I throught that I'll just insert a transistor between the TSOP output and signal party line so that the base of the transistor gets connected to TSOP's output, emitter to ground and collector would pull the party line down. A single pull-up somewhere would be needed and as the transistor reverses the signal. I'll just invert the way the receiver PIC interpreted the input signal. I hooked two TSOP's with the above mentioned stuff together and plugged in to the receiver unit. All was well. I then pulled the party line through our apartment hall and tried the stuff. Nothing worked! Only if the both TSOP's got the IR signal it worked. It took some time to realize what was wrong – did you realize what? How to interface TMW-DCC, the second version ============================================ Tapiola club is now preparing for the Lahti exhibition. We'll have all our modules in a row there plus return loops now under construction. The setup will be about 30 metres long. This means that the operators will not walk to the receiver box to swap the patch cables from the far end of the layout just to get another train under control. I'm a not confident about the joystick cables extending over 30 metres also, so something else needs to be figured out. I then thought that it would be fun if the IR throttles would have a method of sort of reconnecting the patch wires: by having 8 resistor chains inside the receiver unit and somehow choosing with the IR throttle that which of the resistor networks the IR throttle should control. I added another switch to one of the trottles and reworked the transmission packet so that in case functions were to be transmitted but the direction bit was set it meant that this was in fact address changing data. The address or patch cable socket was selected with speed control (speed step represented the address or throttle connector number). While the address selection was on the display of this cab flashed on and off. When the address was chosen, the adress switch was turned off, and the address was flashing until the speed was set back to zero and the newly shosen address was activated. I got the software up and running pretty quickly, but soon learned that the hardware part of the receiver becomes a dreadful monster. During our holiday tour in Gothenburg, Copenhagen, Oslo and Stockholm I started to design yet another version: the PC-eliminator! How to interface TMW-DCC, the third version =========================================== After reading the source code of Mike Bolton's DCC system I was convinced that I should give it a try. It would have to be modified somewhat as the distances will become excessive, and I wasn't intersted in building the booster myself. I then choose to do something completely different: use the TMW-DCC hardware and just replace the PC. I studied the Michael Brandt's DCC-MD DOS TSR driver code that was used (modified) with the TMW-DCC setup: https://web.archive.org/web/20000919070921/http://web.syr.edu/~mobrandt/dcc-mb/software/dcc-mb.asm and dis-assembeled the TMW-DCC processor card PIC hex code to make sure I understood the Brandt's drivers timing sequences correctly and commenced working. The main idea is that the receiver interpretes the IR transmitters messages much the way it initially did, but the packet is extended to be 11 bits long: 2 bits for IR cab ID, 8 for payload and one parity bit. The transmission between IR transmitter and receiver needs to handle DCC addressses, speed control and some functions. The TMW-DCC hardware in turn requests the DCC packets to be delivered in 8 bit parallel form so that the whole packet including preamble, address, data and error check bytes and separation bits is glued together and split in 8 bit sectiuons and those are sent to the hardware as requested: byte0: PPPPPPPP Preamble 8 first bits byte1: PPPPPPPP Preamble 8 next bits byte2: PPPPP0AA Preamble 5 bits, sep, 2 addr.bits byte3: AAAAAA0D 7 addr. bits, sep 1 data bit byte4: DDDDDDD0 7 data bits, sep byte5: EEEEEEEE Error byte To transmit 8 bits of DCC signal takes at least 900 us so by polling the request signal from the TMW-DCC at less than 450us interval I could serve the harware during the timing loops of IR side. For the IR protocol I opted for transmitting the DCC packet bytes as closely as possible. Address packet has the MSB set zero, so all the seven bits can be used for address (1..127 possible). If the MSB is 1 the either speed or function group 1 type data byte is sent. These bytes are too much alike, so I choose to copnvert the bytes slightly to make them different and also to make room for transmitting the 14/28 bit info. This is not actually needed, but the display unit can now display the speed in correct format: ------------------------------------------------------------- ADDRESS: CC0AAAAAAAP CC =transmitter ID A..A =address P =packet parity (Strip transmitter number and parity bits to get the proper NMRA-DCC 1..127 address byte "0AAAAAAA") ------------------------------------------------------------- 14/28SPEED: CC11DsSSSSP CC =transmitter ID D =directon bit s =F0 / LSB speed S =speed bits P =packet parity (Strip transmitter number and parity bits and replace first 1 w. 0 to get the proper NMRA-DCC 14/28 speed step speed byte "01DsSSSS") ------------------------------------------------------------- GROUP 1 FUNC: CC10MFFFFFP CC =transmitter ID M =14/28 step Mode F =function status bits P =packet parity (Strip transmitter number and parity bits and clear M to get the proper NMRA-DCC Multi-Function Group 1 byte "100FFFFF". 14/28 mode is sent separately here to make sure speed=0 is interpreted correctly: address change should only allowed if speed is zero!] ------------------------------------------------------------- 11th October 2002 the system started working the way it was intended: I have one throttle finished, the display works (except that the speed steps are not taking in consideration the emergency halt steps and thus run to 15/31 instead of 14/28. There is still some adjustments needed (the display and forcefeeding of functions in case the speed is constantly adjusted). I hope to finish the second controller this week to get some serous testing started. Pekka Siiskonen