Toastie

Hi DaddyDeuce, very well; I am as excited as you are. But you know what I find even more exciting? The ingenuity of the TLC folks in charge synchronizing the worlds of bricks. Over at the Technic Forum "they" are as excited about PF as "we" are. In fact maybe even more so; they go nuts on the PF stuff. In other words: PF seems to be a universal approach usable across virtually all LEGO themes. Now that is was I find truly amazing. And I agree, all the recent train specific sets are simply great. But again: All the new bits an pieces - with a few exceptions of course - may be rather appealing to other communities as well. That is what makes TLC simply play in another league, in my opinion. Regards, Thorsten

Hi Dan-147, wow! Your FP7 engine is stunning! The cars as well. If you ask me there is absolutely no need to build closely as possible to the original, in contrast. Your version has already convinced me to change my own FP7 along your line. Thanks a lot for sharing! Best regards, Thorsten

Hi craigstrains, now that's an idea! (the most spectacular derailment) PLUS: You simply reassemble the crashed train and go on for the next try ... How about another competition: Take your engine of choice and convert that into a - uhmm - a lawn mover, within 2 minutes. I bet you'll win your first award ... Rock on, Thorsten

KEvron, F0NIX suggestion may only work for low currents though; the Touch Sensor has a resistance of about 500 Ohm when closed (pressed) and when you run some current through it "generates some heat", at least this is what I found out when using such a switch for powering purposes. Regards, Thorsten

Thank you Paul for that interesting question and thank you TB for front paging that!!! Very cool idea ... "looked down upon by people" ... Hmmm. Anyone who is giving that impression is - well - lacking imaginativeness, if you'd ask me. There are of course several ways of looking at your question. However, if that imaginativeness is not there we probably will never gain support from them. When it is there, we probably already have their support. Personally, I'd say: We are talking about LEGO here! That's it: LEGO is inspiration, creativeness, skill, fun, fun, fun, building, imagination, endless possibilities, ... The very moment we narrow down this wonderful world to "making models as accurate or realistic as possible", we pretty much narrow down the idea of LEGO to something (I feel) is less than LEGO really is, to something much more restricted. When you go into "serious scales", you can always get very close to the real thing - look at all these gigantic breathtaking models out there; they are indeed "realistic". But then you have simply overcome the quantum noise of the LEGO world: If the smallest brick you consider is a 1x1 plate then you can virtually model every structure with amazing details and realism once the model is 10 feet long and 5 across. It is getting much more challenging when building 7-wide trains with a minimum piece dimension of 1-wide. Here we need all the skills form the geniuses out there and all the fantastic ideas to get close to the real thing. And there were (poor) attempts to get closer to realism: Remember that ugly white nose from the ICE train? It is good for just that: An ICE train. Nothing more, nothing less. Take any average sized LEGO train model, take it apart and you could probably do a fairly nice aircraft, at least one we all would recognize. Or a car, or a house, or a tree, ... I like to "feel the idea", to "see functionality", playability, and have fun fun fun. I like to dream along when a LEGO train thunders through it's own world. I like to put Mr. Crabs joint next to Café Corner - just because I can. Is this a realistic model? Oh yes! In the world I have created, it is as realistic as it gets! It simply defines itself. You know, I am very happy with the way LEGO modeling works. All models are "realistic" to me. I do enjoy very much Anthony's, Teddy's, Ben's, LT12V's, (and many other genius builders not listed) creations. I also enjoy cool ideas, alternative approaches, funny layouts, colorful solutions, ... I believe that people giving the impression of "looking down upon" LEGO models may probably (not yet) have had the chance of feeling a universe of unlimited possibilities ... Best regards, Thorsten

Hi LT12Vs, I am just back from a Christmas Holiday trip to find a) one of the most beautiful LEGO steam engines I've ever seen b) wonderful details of the driving mechanism and c) very impressive comparisons of the real thing and your MOC. You are one of the most gifted German steam train builders out there. Front-paging this MOC was a wise decision of The Brickster - he knows! Congratulations on this truly amazing creation and all the "prizes" you have earned! Best regards and a wonderful 2012 for you and your family! Thorsten

Hi Bricks n Bolts, this is amazing! Exactly what I was looking for. See, you can run the power from your pickup into a PF LiPo. That one works like a charm with 12DC charging voltage. The LiPo is feeding a PF receiver and that one controls a PF train motor ... and you have converted the entire 12V gray era to fully compatible PF operation. Beautiful work!!! Regards, Thorsten

I would not go that far. It is 10 years old, true; depending on the condition of the set however $80 is cheap. Assuming that everything is OK than I's say it really is a good price. There is a very good amount of more "classical" Technic and system bricks and plates in the set. In addition, NQC is out there and along with BricxCC all for no charge you can program the RCX on a rather decent level. The NQC is compatible with Scout and Spybot PBricks - true, old stuff again, but it's fun to see them interact all running programs in the same language. I happen to have about 13 "classical" RCX, Scout and Spybots - they still all work perfectly well. Well just my thoughts, Regards, Thorsten

Hi kyphur, next to nothing - 10 mA peak when sending RF, about 3 mA max. when listening for RF (most of the time). I wanted the transceivers to run from "active" RCX sensor ports - they can only deliver that much. Regards, Thorsten

Hi SuperCow, now this is very nice, just what I was looking for. Sweet!!! Just in case: Further up people were also discussing RF as range extension or "line of sight problem" buster. In this thread in the Train forum I have posted one idea of how to get RF and PF get along quite well. The RF thingies tie into the IR bit stream so you don't have to get nasty on the LEGO stuff. The thread discussion is also very interesting. JopieK has a project going on where he uses 2.4 GHz stuff at breathtakingly low prices(!), see links in posts. That seems to be the way to go with respect to RF, if you'd ask me. Regards, Thorsten

Very quickly: The Technic forum is discussing method of expanding the PF receiver range to 8 channels (16 individual motors that is) in this thread, starting around post#41 it is getting really neat. TLC has announced the bit-protocol already some time ago ("enabling the extra address bit"). Just in case somebody is interested. @The Brickster: This post should be deleted if this is common knowledge - I certainly have missed the discussion. Regards, Thorsten

Hi JopieK, this is breathtakingly beautiful RF stuff. I just checked the Nordic website and then some follow-up links to e.g. RF Semiconductor (link opens PDF). Are your students using the 8051 (oh my, very good memories come to mind - an 8051 was doing my gas phase concentration measurements in the lab by taking pressure drops from known volumes ... I still have that module in my office ...) equipped version? Or do you plug the RF modules into your Arduinos? Fantastic! Any idea when the hardware rolls? Or does it already? This is going to be very, very exciting. Best regards, Thorsten P.S. The back channel is naturally also very handy for protocol safety; instead of issuing 4 repetitive bit streams as the PF remotes do, usually 1 transmission is sufficient. Only if that did not get acknowledged, further transmissions are going out.

Hi kyphur, I believe this is entirely possible - it depends a little on details though. First, you'd need to decide whether or not you want to replace the entire PF stuff by new stuff - I guess not, at least not on the receiver side with all the nifty connectors and so on, right? If that is so then a little thingy needs to go in front of the PF receivers. On the transmitter side you could go all custom but then the PF remote dials and switches are also gone. So lets presume you want to tie into the IR bit stream. In this case, I'd wrap simply an "address frame" around the PF "message content". On the receiver side, some intelligence (PIC, Arduino, etc.) decodes first the address (e.g., 0 ... 255) and then decides if the message content goes through or not. For this to work, the respective receiver should only see IR light from the little thingy positioned in front. On the transmitter side - (using the LEGO PF remotes), each remote needs a dedicated IR pickup (at virtually no cost, will post some stuff in this regard soon) which goes to the transmitter intelligence (again PIC, Arduino, etc.). That one temporarily stores the remote bit stream, puts an address in front and sends the whole package out via RF, 4 times, as the original remotes do as well. I believe that there is ample of ucontroller code out there dealing with bit stream handling and things like address decoding. This would be again entirely non-fancy OOK protocol basically replicating what comes from the PF remotes ... This way you would not need several RF frequencies. Also, the address range could be much larger. The entire transmission will be somewhat longer, but that may be tolerable. Again, just ideas, I am no e-expert at all. ucontroller gurus might have a much more elegant way of realizing what you are looking for. Best regards, Thorsten

Hi LT, yeah - discrete WAS better, but then: No RF for me I guess ... With respect to your question: The circuit diagram indeed needs an update. I used Tatalum SMD capacitors - some T491 series, whatever that means, 35 V DC on the source side (47 uF) and 6.3 V on the 3.3 V side (220 uF). These were apparently "new" in 2009 ... Best regards, Thorsten

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