Toastie

Dear All, since long I am toying around with ideas about IR range extension using radio frequency (RF) transmission. It is not necessary the line of sight range that bothers me – the LEGO IR remotes (both PF and the RCX/Scout/Spybot Mindstorms varieties) do bridge fairly long distances – the dead spots were making me nervous. My “robots” are often controlled to some extent by a host computer communicating with the remote PBricks in charge via the Mindstorms IR Towers. I was never that much interested in creating autonomous robots – which appears to be the main impetus of the hardcore robotics folks. In this RailBricks article (Page 44, link opens full PDF document) is a short reference to my first reasonably well working IR/RF range extension solution; the devices are set-up for half duplex IR/RF communication so that the PBricks can report back (acknowledge) commands to host control. A number of my present LEGO trains are also equipped with RCX PBricks and IR/RF transceivers. This way the trains are capable of receiving and acknowledging commands in tunnels, behind large buildings and the like. In case there is no reply the command is simply resent by the host computer a couple of times before a warning is issued. More recent train additions such as a motorized version of Ben Beneke’s BR23 use PF equipment (receiver + LiPo + old school 9V mini motors) to roam around – so these need to be integrated as well. Just recently I put one of my IR/RF transceivers in front of a LEGO PF receiver and it worked quite well. There is of course no reply from the PF receiver, so all that is really needed for PF is the RF to IR conversion part of the transceiver. I tried out a couple of integrated electronic RF circuits (no way that I could work with discrete RF stuff, TTL/CMOS logic is all I am capable to manage electronically) and came up with a fairly stable solution that I like to share here. Although this is not a train specific contribution, I post it here because the original idea was remotely controlling trains. Furthermore, there were also some hints from other forum members (e.g., JopieK) that RF communication is on their roster. I am very much interested in these solutions as well! Before going into details, here is a short list of properties I judged to be essential for my project; bear in mind that this project is sort of across multiple themes, so the transceiver should be operating with virtually “all” IR controlled LEGO devices (as long as they run on the LEGO typical 38kHz IR carrier): Two-way half-duplex communication (-> not necessary for PF) About 20 m range in congested surroundings Up-to 5kBits/s communication rate Minimal foot print, preferably 4 studs wide No modification of existing LEGO hardware, i.e. the transceivers need to tie into the IR communication path Make it as cheap as possible, but within my limited e-skill range Wide input voltage range: 4.5 V DC to 20 V AC Operation voltage below 5V. 3.3V seems to be favorable Max. input current 10 mA The last two properties result from the idea to run the transceivers off from “active” RCX sensor inputs. These are capable of a sustained delivery of about 5V/10mA to external sensors after rectification and voltage stabilization. In other words, I would not need any additional power source for the operation of the transceivers, such as RCX outputs; there are only three and they are used for motor and light operation. The wide input voltage range ensures that all other LEGO power supplies are compatible as well. To begin with, here is the idea of the non-invasive realization of a half duplex IR/RF transceiver. The set-up would be: Local LEGO IR Mindstorms tower <–> local IR/RF transceiver <–> remote IR/RF transceiver <–> remote PBrick. The problem that readily arises when using two individual circuits for RF transmission (IR in + RF out) and RF reception (RF in + IR out) is a nasty loop that is created when not taking further care, as shown in Figure 1. IR from the tower causes RF to be sent (1), the RF in channel is picking up the signal (2), mirrors that to IR out - and we create a loop (3); the on-board RF in sees its own signal and goes nuts. So there needs to be some sort of control logic, telling the IR out channel of the transceiver to simply shut-up when RF is being sent. That logic can either be hardware (e.g., in terms of a TTL solution, as shown before, see above referenced RailBricks article) or can be “programmed into” a little micro controller. I am using PICs from microchip (just ran into them, no preference at all here). The cheapest and smallest PIC I could find with 6 I/O ports is the 12F509 ($1.5/pc). The diagram in Figure 2 shows the simple electronic circuit I came up with. Programming the PICs is rather straight forward, after some readjustments to assembler code (loved to program Zilog’s Z80 on the machine level in the olden days) it worked fine for me. The nice thing about virtually all small baseline micro controllers is their reduced instruction set. The cheapest programmer for PICs is the PicKit1, which sells for about $35. The PicKit1 is compatible with microchip’s mighty MPLab IDE, which ships for free. I did all the programming with this suite and I am impressed with debugging, simulation capabilities and what not. What does the PIC do? When idling, it simply loops between the IR in and RF in channel of the transceiver and listens for signals. The moment a signal is received it jumps to the respective code (either IR or RF is handled, but not both) and deals with the signal: Is it just noise or a qualified signal (see code)? In case of a “real” signal it generates the corresponding RF out or IR out signal by mirroring what is coming in to the output: RF out is simply the on/off keyed (OOK) bit stream from the IR detector. IR out is somewhat more sophisticated; here we need to convert the incoming OOK RF signal into corresponding 38 kHz IR light bursts (I could not get hold of an IR LED with built-in 38kHz generator, they must exist). This is what the PIC does as well. For the time of transmission and some additional delay time after transmission it does simply not look at the other channel, this way we for sure don’t create a locked loop. Mindstorms PBricks need about 5 - 10 ms for sending out their reply, so this is ample of delay time. If you are interested in the PIC code, PM me and I’m happy to send you the assembler listing or the entire MPLab project file. But beware – the code is sub-amateur level! As IR parts I used the pieces shown on the left in Figure 3. The more commonly used pieces on the right were a little bulky – also I wanted to go with 3.3V so that took me to the TSOP 34838 IR receiver and a miniature side emitting SHARP GL 480 IR LED. The RF parts are shown in Figure 4. I used 433 MHz LINX modules just because they were relatively cheap (and ready to go and can manage up-to 5 kBits/s). These receivers are very stable, reliable, and virtually don’t pick up RF noise, even in completely messy circuits, see Figure 5. (On a side note, LINX phased out the LC series receivers in 2007. The follow-up LR series receivers are much more sensitive, have a higher transmission rate (10 kBit/s) but also do see a lot more noise. In fact, with no “real” RF signal present, the internal amplification goes way up and picks up noise like crazy. There are ways to pull the receiver out of noise, including software solutions (see code), but I found a much more convenient way: East Dragon Electronics (no joke, and the guy's name handling the order was Oscar ...) in China has still tons of LINX LC receivers in stock and they sell them for $5 + sh&h each!) Figure 5 shows the prototype on a solderless breadboard; if RF works in such a messy environment, then it for sure works on a rookie-made printed circuit board as well. All I can say is that the LINX people do a good job on their RF stuff ... RFM has also a nice suite of integrated RF stuff. Their integrated transceivers (RF in and out all under one tiny hood!) are also working fine, even in my messy environment. It is just that the LINX LC receivers appear to be less prone to noise pickup ... and they are a little cheaper. Now on to the foot print. To really go small we need a) a printed circuit board (PCB) and b) some SMD parts. The PCB board was made by a German company called “PCBPool”. They give you quite powerful software (called “Target V14” and up) to draw the circuit and automatically route the board – but you have to use their service. Which is $60 for a 160x100 mm2 double sided board. That fits at least 15 individual transceiver boards as shown in Figure 6 – I have already used 7 from this board shown. Everything works on-line; you just have to wait for the board to show up in your real mailbox. Figure 7 shows all the parts going onto the board – I certainly overdid it with the resistors ... The assembled transceiver is shown in Figure 8; In Figure 9 it is comfortably sitting in a case made by 3 hollowed out 4x2 bricks and a 2x4 plate. The cost (very rough estimate) for such a transceiver is still considerable, I guess: PCB $60/15 = $4 RF receiver = $10 (LR type from digikey) or $5 (LC type from East Dragon) RF transmitter = $5 IR receiver = $1 SMD capacitors = $5 all remaining parts about $5 That totals to roughly $30 which is considerable. Prices go down when you order ship loads but that was not what I was looking for. I just want my trains and stuff run around happily. Figure 10 shows how to “connect” to LEGO devices without breaking into them. So far this IR/RF transceiver worked with PF receivers, RCX, Scout, and Spybot PBricks. PF is only one way, so the back channel is not needed. In this clip three trains are remotely controlled via RF (with back channel). The IR tower or control unit (remote) is hooked up in exactly the same way with another transceiver. As already said, if you go one-way only (PF) then a 433 MHz remote control extender works very well as transmitter. Here are some more or less useful pictures once moderated. There is more to come; RF base stations with distributed IR in/out satellites (reducing the cost significantly for multiple stationary LEGO devices such as switch point controllers, lighting, etc.) is one option that works also quite well, just installed some stuff. Furthermore, when not using the back channel, the host transmitter can be a plain vanilla 433 MHz remote control extender blowing out considerably more RF signal than my tiny transceivers. That will ensure some real remote distance control. Will hopefully be back soon with some more applications. Best regards, Thorsten

Tony, this is absolutely entirely true - this is what LEGO is about. Nothing more, nothing less. Thank you very much for so nicely phrasing it - I will surely quote your post partly or entirely when it comes to "what is LEGO about" related stuff. Wonderful. Best regards, Thorsten

Hi Mostlytechnic, since you are into micro controllers - ever thought about replacing the PF receiver with a custom design (instead of customizing the remote)? Or maybe create an add-on to the PF receiver? I guess that the difference between brake and float will not really show with most trains. They would have to be really heavy - however in that case friction would really go up and they would stop faster. I have equipped my trains with RCX PBricks - well that makes them rather bulky but worked reasonably well with the Santa Fe and the GPXX diesel series. The RCX bricks receive (and optionally acknowledge) messages in the RCX format (which is compatible with RCX2, Scout, and Spybotics firmware and you may also tie in NXT PBricks if you have the NXT HiTechic IR "sensor") - and then do what you have programmed with that message. For example, the first message is an address byte, the second a data byte - lets say train #3 go to speed 5. A little piece of software in the RCX looks at the current speed, and then cranks up to target speed rather slowly. The same is true for breaking. When you go from full speed to 0, my trains need a good amount of time to actually stop. Guess this is what they do in the nifty DCC controllers as well; as far as I understand, you can program you response characteristics into the controllers - but I don't have any, just guessing. Regards, Thorsten

Hi JopieK, that sounds interesting! I am done with my approach using LINX modules, both for PF (uni-directional) and RCX (bi-directional) communication. Works quite well in my office. Will be back in two weeks and hopefully show some pictures. What is you approach? Regards, Thorsten

Hi LT, wow, although I had a detailed sneak preview of this beautiful engine: Simply breathtaking. A truly masterfully built steam engine! But even more so: Your soldering is excellent as well, very clean and very well suited for LEGO models. Brilliant work and fully in line with the other BR series models!!! All the best, Thorsten

Dear Man with a Hat, do you have a photograph or could you take one that shows the hang over on switches? I am currently motorizing my switch points in different ways (PF, mini motor, old style 9V motor MicroScouts and what not), and hangover is a serious problem (e.g. the Mask container things do interfere considerably with my first generation switch drives ... ... but your cars are beautiful. They very well match the original coach sizes. All the best, Thorsten

Hi Brickviller, there are some options; one that is at least tempting is to run a PF->9V "conversion" cable to some spot in the train with space. I have done it this way. If you are concerned about the piled up PF terminals: Go with one PF->9V cable to the back of the engine. There you have space to attach further PF cables (top of connector) or 9V cables (bottom of connector). When wiring between cars/engines, I prefer 9V cables; they are much more flexible than the PF cables and thus don't exert that much "derailing force". has front and back lights - and you may add as many cars "in between"; connected with 9V cables that is. It's the best of both worlds after all ... Regards, Thorsten

Hi Aanchir, your comments are very well received! I agree: Future releases of LDD will make train construction easier, for sure. What I like about the LDraw approach though is: Open Source. The various programs come with: Install what you want, skip what you want. In contrast - LDD: "An update is available. Download size: 135 MByte". And clicking on the LDD program icon fires up stuff that I simply don't want to see; all I want is building. I know, I am living in the past ... LDD has all the options to become the #1 digital LEGO designer program: A >team<, TLC's backup (PaB is tied in, right?), and what not. LDraw folks are focusing on making parts available; PovRay lives on it's own, and the other gadgets are more or less final releases, just working blistering fast and fine. I am an LDraw fan, others are not. It is nice to see all that activity though. All the best, Thorsten

Hi AndyC, you are absolutely right - in terms of connectivity. However, having played around with MLCad for a couple of years, that really is not an issue. For newcomers it may very well be though, and LDD is much better. With respect to the "level of productivity" - as of now(!) - we should probably be more careful with the judgment. I have inspected the "Make building instruction" feature of LDD, and yes, you do get a decent HTML output. But running the latest PovRay fed with an LDraw input file, with all the nifty add ons available on LDraw.org, I am pretty sure: The output from these programs is truly amazing. You do have to do a lot of hands on work to get high quality instructions, but at least I can do that with plain vanilla PC programs and >I< have control. I guess this may change in the future. But as of now: LDraw + all the gadgets is what I do. I am pretty sure it also depends on what material you build with: I am piling up a rather outdated stock of bricks ... being more than 45 years in building business ... Best regards, Thorsten

I totally completely agree. Downloaded the "latest" (I was living a little in the past) parts library today ... Oh my goodness. Since LDraw folks don't care about what's available through LEGO's PaB, there seems to be much more freedom. It seems that Bricklink is the limiting brick source for LDraw (which simply means that virtually unlimited brick "ages" and quantities are readily available, if you can afford them). That is exactly the reason I stick to MLCAD + LDraw resources. Best regards, Thorsten

Just click on the pic I just browsed through the LDD file - brilliant. I am pretty much impressed how far you got with the electronic version. Fantastic! Regards, Thorsten

Hi John, that was a very nice post ... it reminds me a little (no, a little more) on how I - as chemist, and not IT-guru - look at these things: We have to get things going. As chemist, I know s**t about C-finesse. And I find C really, really hard to learn, and more importantly, to memorize - knowing that I need this particular piece of code now and probably never again. It has been and it will always be an "I/We believe in" question: Programming languages. The Gurus are probably right: C is the way to go. You know what? As purist, I'd say Assembler is the way to go. Once you have all time of the world, you probably can beat the output of a C-compiler with respect to code optimization and performance, at least that was the case in the olden days. Most important to me is: A couple of basic, powerful commands to get simple things going, accompanied by matching documentation. And then, further on: Unlimited command sets for the tough stuff. "RobotBASIC is written in C++" ... I LOVE that one. Best regards, Thorsten

Hi Perterab, oh come on. 3MP is more than adequate to capture the beauty of LEGO MOCs. You know, with 15MP all what happens is that Brickster is going nuts and tells us to reduce to 800x600 max. Which is absolutely reasonable ... See, it's not the resolution of cameras, it's the MOC. Regardless of camera resolution, a brilliant MOC remains a brilliant MOC. The BR103 sure is one of the most beautiful German E-engines. Along with matching coaches it becomes a dream. You have captured it very, very nicely. 3 axle bogies, the coloring scheme, the exhaust "grids" (very important feature!), SNOTing all over the place, the wonderful electrical stuff on top, and: Nice curves. A BR103 is curvy and your model is showing just that. Congratulations, and don't worry at all: 3MP is perfect. Regards, Thorsten

Tim, thank you very much for this contest call. And thanks to the folks who have put a high quality PDF of 7777 online! I am even more deeply impressed with what TLC has done in the past. I have never had a chance to play with 12V at that time. The booklet is truly amazing. Ideas everywhere - the steam locomotive is breath taking, considering we are talking 1981 here. Wow. The layouts, track side structures, little things - wow. I have to admit, these were the really good'ol days ... Best regards, Thorsten

I could not agree more. RCX, yes, they rock. The NIX PBrick is OK though ... However, what worries me very much is that "Mindstorms" items have entirely disappeared from the LEGO "catalogs", at least from the stuff they send me. What's going on here? Anyone experienced the same? Regards, Thorsten

Folks, this topic has discussed "7745 advices", "how well does 8878 perform", and also "cost" issues. Here are my 2 cents on 8878 ... maybe off topic; 7745 was the original post (8886 is the PF extension cable ... I guess this reference may be in error?) 8878 is indeed rather powerful and - if you'd ask me - quite sophisticated with respect to performance. As already pointed out in this thread, TLC is asking for a serious amount of money. Let me re-iterate a couple of thoughts, you may want to check out this thread and RailBricks Issue 7 as well. 8878 incorporates a Lithium Polymer (LiPo) based rechargeable battery pack. LiPo's don't show any noticeable fatigue over time; once charged, they keep that charge for the longest time, as compared to most other types (NiCd, NiMH, ...) In addition LiPo's have a fortunate mass to charge ratio. 8878 incorporates a powerful charging circuit as well. You simply don't need the LEGO power supply - just use plain vanilla 9 ... 18 V DC power supplies to charge 8878, it works. That said, 8878 makes entirely sense, even at that cost, when you consider charging "on the fly" [e.g., using modified train motors, picking up (largely changing) voltage from the powered track]. It does not make sense when you prefer charging off-line - in that case, battery boxes loaded with NiMH rechargeables are the way to go. Best regards, Thorsten

Hi Fireburner5000, as JopieK said, you need an USB cable, the A/B type variety - they're dead cheap and you may very well have them in the house already. Google has tons of pictures. @Paul: The USB tower you are referring to is perfect for the RCX/Scout/Spybotics PBricks (via the IR link) and for the VLL bricks like Code Pilot and MicroScout bricks via the visible light link built into that tower. Unfortunately the NXT (1.0 or 2.0 does not matter) does not speak IR anymore ... which certainly is not nice . Regards, Thorsten

Hi Hrw-Amen, well that depends. On the complexity of your layout, and on the total number of trains you are planning to run simultaneously. Lots of track, less chances for crashes. Many trains on the track, many potential crashes, particularly if there is confined space. I'd go with dedicated remotes, even if that seems to be expensive. The moment a fully steaming EN is approaching a waiting crags train on the same stretch of track, you may get confused ... well, my experience. All the best, Thorsten

Hi Tony and L@GO, that is right and real quick: The 2 "outer" cables are +9V and 0V or ground. The inner two are called C1 and C2. All "dumb" devices like motors and lights get power from C1/C2. All devices requiring permanent power (e.g., receivers) do get that via 9V/0V and "forward" power via C1/C2 to motors/lights, mostly PWM modulated. You may want to look up Philo's PF reference page. So when you want to reverse the motor direction you need to "cross" the inner two (C1/C2) wires. Best regards, Thorsten

Hi Jonathan, thanks for the fast response! The NXT brick control taking care of the aforementioned problem makes perfect sense! I'll post some pictures of my approach in a couple of weeks (it's vacation time and I can't wait to get up to Northern Germany, where I was born ...) I did some technic beam securing with rather limited footprint; you can bang the drive to both ends and it virtually cannot fall apart. But that should be done with care, since the motors may suffer from being stalled too long. I am also using multiplexed PBricks for motor control, so that makes things a lot easier. Thanks again + best regards, Thorsten

Hi Snapshot and Brickaroo, I am using this design as well, however I had some issues with having it ripped apart after 20+ repeated turns, particularly when not using the panels (as in the original design) serving as stop and also removing forces pointing up considerably. Did/do you experience the same? Regards, Thorsten

Hi Scotty, yeap, works well, but may fail in the long run. WD40 is one option; with ABS you may consider silicone based lubricants though. If you need to go with lubricants at all (was the train that much faster?) make sure this stuff - after a couple of rounds - does not make it to the rails - slippery when wet ... Regards, Thorsten

Hi Macoco, hehe, this IS some sort of business school type calculation, beating TLC's reasoning ... but you are using US prices, right? I could not follow through entirely considering I am living in Germany ... off topic again ... Í know ... Best regards, Thorsten

Hi Elroy, this is fantastic news, I have placed my orders - to really enjoy the magazine I need paper in my hands. Railbricks is the #1 railroader magazine for LEGO fans. Thanks a lot for all that work. Best regards, Thorsten

Hi Bellicose, hmm. To be quite honest: I think that with an organized Danish Company as TLC is, along with the fact that these folks are global players (toys-wise) that they simply watch out for profit maximization. They have to do that, it is a rough environment out there. We (as AFOLs that is) wish for this and that, and they (as power players) have to take care of business (OK, with some sort of care for customers ...). So I guess, the whole issue of who is paying what in which country is - well - a school of business decision. I am spending some time per year in the US and I can assure you that with every visit I am smuggling ... no I don't want to go into details. I am living in Germany and looking at prices in the US ... Sorry, I guess this is how it is. Taxation is one thing, business decisions are another. Regards, Thorsten