Toastie

Amen. 100% agreed. Best Thorsten

That's what I do. The gray "very" bottom part comes in handy here. And then I use 8878 (purchased a couple back then, when the world was spinning the other way around) fed by power pickups (= modified 9V train motors) from permanently 15 VDC powered "9V tracks" to power the PUp hubs. Works since PUp exists and much longer for PF controlled trains. 8878 has all the bells and whistles on board. With regard to explosions: It is not as common as suggested. LiPo's usually simply die, when treated badly. The explosions do happen, but whenever that is the case, it is reported on world-wide channels, and amplified upon re-whatever-ing. Nevertheless, be careful with unprotected LiPos. Best, Thorsten

You >nailed< it. A picture is worth a thousand thesaurus entries Thomas (as in: Representative for the color gurus) is more concerned about "knowing that is in there". (This is why I like the "vomit" wording so much :D). Or that you can see the vomit - hmm - wait. Vomit becomes vomit, when it sees the light, right? So that does not make sense here ... Rephrasing: When you can see, what potentially becomes vomit (at a certain angle) - from the outside. I believe the almost life-sized star destroyer (among others) apparently had that issue ... but who knows. Since I was born, I have come to rest with colors Best Thorsten

It really is - and without something decent from TLG, or better: Phased out by TLG, I believe this is really >on< topic. Sure, we are talking about a competitor here, but is that really true? There are other products discussed in TrainTech (and elsewhere) as well - and I surely never want to miss them - all the superb work of @michaelgale as one example (or the Buwizzies). You could argue that this is no competition, as TLG does not make 9V track anymore. Well, TLG also doesn't make any decent carriages anymore. Gone ... My Own Train, 10022, 10025 ... so BB >carriages< are no competition anymore , which then renders this thread as being >on< topic. My experience with BB is really not BB, but rather MouldKing sold by BB. And I must say, that experience was wonderful. The Flying Dutchman. Clutch power better as compared to TLG's bricks (it is a display model, so that is perfect), which would be perfect for carriages as well. No issues with anything - even colors were >perfect<. Well, to me; I am color-blind to a certain extended extent so I am very happy with what I got. Brick-wise - they all matched perfectly. >No< brick was geometrically off. I don't know what I will get this time - but just to reiterate: 24 € for a 6-wide, 40 cm long, dark green carriage ... you know, TLGs new 4-wide ... display train thing ... is 36 cm long ... for 20 €. I am very happy to change this and that on the crap-carriage, should that turn out to be necessary. At €24 I cannot care less about accepting that challenge. We'll see. All the best, Thorsten

Color epidemic plague (matches well with current times) - color pestilence - or simply color vomit (I like that the most , it has a certain touch to it) ... Well I have registered - just in case, let me know All the best Thorsten

Totally agree here! Two options: We just do it here and wait and see when it will be moved to the Community Forum (hopefully, not along with a bunch of other competitor discussion containing threads ) or we directly open a thread in the Community forum. Well after all, a lot of non-LEGO stuff is discussed here - it appears as if the rules - maybe due to the rather low number of decent train sets that came out over the past decade. Don't even talk about track ... Best Thorsten

So we are "no one" minus two. Will be interesting to read about experience. So far, I mixed-up bricks for my Black Pearl only. The Flying Dutchman from Mould King did not need any replacement, in contrast. We'll see. However, with regard to mixing bricks: I have had it with TLGs train theme. I'll definitely go that route. Best + good luck with your order! Thorsten Well, they give away the instructions for free, as TLG does ... Best Thorsten As a German, I am in no way qualified to make any suggestions in this regard - but I read "color vomit" somewhere, which gives it a certain interesting spin :D As does when the sh*t hits the fan :D Best Thorsten

Yeah, seems so. There is some discussion on that though - it must be that a mega-ton of DBG/LBG is more expensive than 1000 kilo-tons of thousand colors + the cost of having either a machine (or a person - I have no clue what the current pay-level in Poland is, given that the company my wife is working at is shifting entire administration departments from their German, French, and Brexity branches to Poland) sorting all the colors and put them into the bags ... in contrast to using just a shovel OK, just kidding!!! Hmm. I guess the 1000 kilo-tons can be used in many more sets ... they certainly have calculated that to the last cent. Business ... Best Thorsten

I'll find out soon - Santa will bring me 4 BB coaches for Christmas. I am pretty sure he will, as I spotted the box in the garage (this is where they put all the boxes when we are gone - so I did not spy!!! I was just getting my bike ... I swear I will then report back. Got some crap parts in a Black Pearl clone set two years ago - but: Crap out, LEGO bricks in - the latter don't scream nor do they melt or ex/implode when you do that. Have even a few original LEGO wheel sets at hand - in BB sets they are the WORST ever, so I have read. But: Design is nice (for me), and I like to try out things. Also, the financial burden is - well - not THAT dramatic, even when this turns out to be a total fail (as the new LEGO high-speed 4-wide train is - OK it is not that bad, I am kidding) All the best, Thorsten I'll find out soon ... upps OK, already wrote that . So this accounts to: no-one minus one = minus one. Phew. That makes me negative ... provided no-one equals to zero.

Heehee ... citing Thomas Panke (in his recent YouTube review of the HMS Hood from Cobi, where he goes nuts on the color vomit having arrived there as well and the instruction booklets, which are a bit off the rails): "... that (person) is the counterpart to the trainee at LEGO, who designs the Friends sets and runs the website." Best Thorsten {translation from German by me; source (@ about 16:50)} - have fun!

Yes. And Yes. Best Thorsten

I don't know what @zephyr1934 was implying - but of course the market leader may not be interested in doing it. Both, the market leader and the small competitors get their >raw material< at the same price. Well, the market leader gets it definitely cheaper, or they should simply go out of business. It is the year 2021 - and making plastic bricks with some finesse has matured into a broadly available technology. To all. And then ... OVERHEAD strikes - heavily. As well as ... the (very) well-being of the employees ... and the employers ... and so on and so forth. It would be interesting to learn what fraction of the retail value of a newly released set goes into OVERHEAD (that number will be - crazy, I guess). As an example: My university charges currently about 70% of the volume of a research contract as OVERHEAD. That dissolves into - well - THE ADMINISTRATION . No idea what they do with that money other than hiring more people to secure that all is handled correctly. It appears as if this system is a perfect perpetuum mobile, violating all laws of thermodynamics. And it appears as if nobody can do anything about it - other than increasing the percentage of the OVERHEAD. Which in turn suggests that thermodynamics is still doing fine and the system is just stupid enough to along with it. Which may be >one< reason why TLGs products become insanely expensive, when you ask me. Whereas the small competitors sell their products insanely cheap. Well, I guess it depends on your perspective. All the best, Thorsten

@Carsten Svendsen and @1963maniac Hmmm. Stud.io with all the bells and whistles - I have no idea. I use it solely for rendering of final models, which is simply amazing. "Sometimes" it is a pain in the butt to get an MLCAD model in there - just because a few nano-meters were misaligned in MLCAD/LDRAW - but it would also not "click" into the right position, when moving that piece a bit around. I am sure this was judged as "illegal" by Stud.io. And maybe it was "illegal". Not in the real build, as it was/is real. And works. So I don't care. I am also very old school. MLCAD is my world - with LSynth installed (http://www.holly-wood.it/index-en.html) - browse to LSynth. Installing LSynth is also old-school. The way it works also. Old school in the sense of: You have to do it all. No automatics here. You tell your LDRAW file how the chain/hose/tube etc etc should look like - and LSynth will do it. Exactly as you - manually - modeled it. It is quite elaborate - but you can bend hoses to a degree, that even does not work in reality. LView (another CLASSIC) as well as PovRay render these synthesized parts perfectly. Summary: MLCAD lets you build your model without any restrictions. And no collision checking. And no click snap plop whooosh - nothing. It is up to you. For hinges: Go to 300% magnification, make the rotation point visible, move it to the location you want it, rotated the corresponding part around this very point. Every angle is possible. Realistic or not. Cheating is entirely possible (assuming a part is a bit out of "legality"). Perfect for me. And my models. I love it. It is much more manual work, but in the end it works. And LView will render it. So will PovRay. Best, Thorsten

Dear All, the purpose of this thread is to assemble as much information as possible on old and current LEGO remote communication protocols, composed from scratch, i.e., data (= channel + action, e.g.: set channel 1 to motor power +3) encoded to the bit/byte data stream emitted by various LEGO remotes using simple algorithms. Such approaches have been repeatedly reported in individual threads here on EB as well as on many places out there in the depths of the WWW, sometimes even whole collections of protocol data exist. Maybe some old farts like me are interested in a more or less comprehensive collection, maybe not. I take the Nike route and – just do it. The hardest part (for me) when encoding LEGO remote control data is the calculation of the checksum, which is always used in TLG’s protocols. It looks like this, when I am trying to find the way the damned checksum is calculated: I will try summarizing all the information and links to encode respective data for a particular LEGO IR protocol, including the commands available and their corresponding value. Again: This is all out there, but as far as I am aware not documented in one place – at least I did not find that particular place. I will simply append any missing information that becomes available to this thread and update the files on the UoWuppertal cloud server, as referenced below (PDF and PPT format): LEGO Protocols: Data format, bit/byte streams and data encoding (very far from beng complete): https://uni-wuppertal.sciebo.de/s/BbYzAnDGLwmWnv7 For the remainder of this post: You may just ignore it. It is very, very long. At the very end there is a link to my “C++” program running on an ESP32 Dev board, which is doing all the protocol translation and signal generation work for my DELL laptop (2019, i7 CPU@2.60GHz, 16Gbyte RAM) as well as for my ZX Spectrum (1985, Zilog Z80 CPU@8MHz, 48kByte RAM). Both are running a control program (of rather different nature) for operation of my trains: 2 RCX, 1 RC, 7 PF (12V, 9V, 4.5V), 4 Pup. When you read on ... OK then, here is MuLPI – a Multiple LEGO protocol Interface It may appear as if this thread is a copy of this device in the Mindful Pub thread, but it is not; basically everything inside the LEGO box has changed: Thus far MuPLI can directly control these LEGO devices/speaks these protocols: (@1963maniac: Thank you for help in fixing the following list!!!) White bullets = devices/protocols: (1) VLL (Code Pilot, MicroScout, Scout, RCX, Spybotics); (2) RC Car (NitroFlash, Bonicle Manas, Spybotics); (3) RC Train (RC Trains only), (4) + (5) RCX (RCX, Scout, Spybotics, NXT/EV3 w/ IR Link sensor); (6) PF; (7) BLE (PoweredUp) Yellow bullets = computer input/output: (A) Serial input w/ HW RTS/CTS handshake (e.g., for ZX Spectrum + Interface 1); (B) Serial input via UBS to serial adapter, for “modern” computer control via e.g. USB port (XON/XOFF). RTS and CTS lines connected for operation with LEGO software (ScriptEd, Scout Tool, vpbcom.ocx etc., see below) Green bullets = MuPLI output/input: (V) Built-in VLL (TX only), visible light best transported via optical fiber; (W) Built-in BLE (RX/TX); (X) Built-in IR (RX/TX); (Y) External IR via RS232 (RX/TX), e.g. for LEGO serial tower boosting the IR signal; (Z) Built-in RF (433 MHz RX/TX) The individual bit/byte streams are encoded using only two input values: “channel” and “action”. Exception is VLL, as there is only one channel; all VLL devices will respond to the “action” data sent. VLL requires thus one dedicated output (LED) per “channel”. I am using optical fibers on my train layout to operate multiple MicroScouts from one “controller” as shown in this EB thread: The following is mostly babbling and bragging. Also the thread title is utter hubris – MuLPI sounded funny to me, that’s all: There is no direct Bluetooth (NXT/EV3) protocol implemented yet, but that is rather current and merely a serial over BT connection, I may by wrong though. And no Cybermaster protocol yet, because I don’t have Cybermaster hardware … and many other things are surely missing as well. MuLPI is built around an ESP32 Dev board (30 pin layout) with the help of a PANT. As I don’t know what a thing attached to an ESP32 Dev board is called, I freely chose PANT: Arduinos have SHIELDs. RaspberryPi’s have HATs. For both, the GPIO (etc.) board connections are facing upward, using sockets (as far as I know). The ESP Dev board has pins facing down. It thus appears as if an ESP32 Dev board needs to get its pants on, whereas a Pi needs a hat, and an Arduino a StarWars type SHIELD. The PANT looks like this (left ESP32 Dev board with a 2x2 tile and plate glued to the "processor and other stuff" cover, right PANT) What may be of interest is the encoding of the bit/byte sequences of all the addressed protocols (VLL, RCCar, RCTrain, RCX, see below) from basic input data (channel + action). Some people have sniffed the various IR protocols and then used the bit streams recorded. This is not the approach here; I am trying to use super simple encoding routines. As said, there are many references out there. In the coming weeks/months/years (yes, years, time goes by, so slowly …) I will just append individual encoding routines here – or maybe other folks as well. So far I have done this for the VLL, RC Car, RC Train, and RCX protocol. PF is available as part of the Arduino Legoino (https://www.eurobricks.com/forum/index.php?/forums/topic/180905-new-version-100-of-legoino-arduino-library/) library package, which runs on ESP32 boards. There are many other well documented PF encoding routines out there; even TLG has provided superb RCX, VLL, and PF documentation – the olden days were better. See draft(!) tables at the end of this way too long message. This is from the PANT marketing department: "The PANT features a most powerful 74HC00 DIP-14 chip from the late 1980’s, three (equally powerful) very low wattage resistors, and a bunch of connectors. All this soldered to a 1985 state of the art bread board. Furthermore, most powerful RF technology from around the Y2k is used: LINX RXM/TXM 433 MHz OOK RF receivers and transmitters (note: The old “LC” version that is, as the newer “LR” versions from 2007 or so cause noise trouble, at least the receivers). And finally a gigantic almost 1” 128x64 high resolution monochrome super-bright OLED display showing the status of the MuLPI. And there are four (super) push buttons, one of which is a 1998 LEGO touch sensor – the ultimate push button solution." MuLPI Hardware Figuring out what to use and how to solder always begins with very professiona sketches and notes in my “LEGO ideas scratch pad” – the ones operated with a pen: Here’s the PANTs size: XS – no, sorry, the circuit diagram (not used for any fancy PCB production, simply made for documentation - although I do trust my pen version much more!): The entire electronics looks like this: This is my ZX Spectrum operating 15 trains (2 RCX, 1 RC, 7 PF, 4 PUp): Using the Speccy is absolutely >not< comfortable, as you can only see the data of two trains simultaneously on the screen; one has to “scroll” left and right to see/change other train data. Not the point: I just wanted to see my Speccy getting it done. For more comfortable operation I am using the MuPLI connected to my laptop running this VB6 program: The LEGO protocols “handled” by MuPLI are: VLL (Visible Light Link) protocol; applicable to Code Pilot, MicroScout, Scout, RCX, Spybotics. RC Car infrared protocol; applicable to NitroFlash, Bionicle Manas, Spybotics. RC Train infrared protocol; applicable to RC Train, NXT w/ IR Link sensor, EV3 w/ IR Link Sensor. Mindstorms infrared protocol; applicable to RCX, Scout, Spybotics, NXT w/ IR Link Sensor, EV3 w/ IR Link Sensor. PowerFunction infrared protocol; applicable to PF, NXT w/ IR Link Sensor, EV3 w/ IR Link Sensor, uses the Legoino library. PoweredUp BLE protocol; for all hubs covered by the Legoino library. Once again: Many others have already done similar things, and there are many and diverse, sometimes dead, sometimes only reachable via the Wayback Machine links, with some information of the protocols out there. But there appears to be no comprehensive compilation featuring the encoding software routines for the bit/byte stream used to control the various LEGO devices. How does MuPLI work? Well, as simple as this: It routes data from the serial port connected to a “computer”, which may even be a Sinclair ZX Spectrum with Interface 1 (or any other old/new computer with serial port or USB to serial adapter) – to the serial port of the “LEGO terminal”. Both terminals are plain vanilla RS232 ports. Depending on the MuPLI mode selected (out of four), it also translates the incoming data from a computer/user to communicate with the “LEGO terminal”. Mode selection is done by repeatedly pressing the Mindstorms touch sensor on the back of MuLPI located next to the VLL output diode. The button is de-bounced with a bold 500ms delay, so no super quick rush through the modes. Patience. There (partly) is almost 40 years old hardware at work here! Operational Modes of MuLPI The four operational modes of MuLPI are: (Manual Mode) Uses the Serial Monitor window of the Arduino IDE to submit data to the MuLPI; format is one ID byte (range 170 to 201) and one data byte = action (power setting and stop), see below. Depending on the device class “identified” by the ID submitted, corresponding output signals are generated using MuLPI hardware (VIS LED/IR LED/RS232). The second serial port is always sending out encoded LEGO IR protocol signals (RC Car, RC Train, RCX, PF) and thus the LEGO Serial Tower can be used to significantly amplify the rather weak signals strength of the built-in IR diode in MuLPI. This works for all IR protocols as the LEGO serial tower is “dumb” and just turns its IR LEDs on and off, according to whatever data are coming in on its RX line (modulated at 38kHz when “on”). Also, any IR signals modulated at 38kHz are detected by the tower and put onto the TX line. See below for further details on the tower. (ZX Interface 1 Mode) Serial data (ID/data byte) from the computer terminal at 9600 baud/8 data/no parity/1 stop bit is inspected and then handled as in Manual Mode. However, both ID and data byte are wrapped into the Mindstorms IR Message Protocol (3-byte preamble, message command, 1 byte message content, checksum. The three latter bytes are each followed by their two’s complement, which results in a 9 byte data packet. Any replies to the control program are also full 9 byte Mindstorms IR Messages. HW handshake is turned on; the computer should send out data to MuLPI only when the RTS indicates MuLPI is ready to accept data; the MuLPI replies only when the CTS line indicates computer is ready to accept data. The former is always the case, as the UART/Serial port software of an ESP32 is mostly bored when data arrive; it could digest many more bytes in one go, as the (max.) 2x9 byte packets arriving from the computer. The latter though is critical, as the ZX Spectrum is thinking about every byte arriving for quite some time, before it accpets another. (LEGO Message Mode) Similar to ZXIF1 Mode, but RTS/CTS HW handshake turned off; rather default XON/XOFF synchronizes the data transfer between computer and MuLPI. I am using this mode for my VisualBasic6 train layout control program. Again, data transport is via 9 byte Mindstorms IR Messages. All modern computers should work using this mode; USB to serial adapters work fine as well. (Direct Serial Mode) For programs such as NotQuiteC (NQC/BRIXCC), ScripEd (Mindstorms SDK2.5) or SCOUT tool (SCOUT SDK), and the like. What comes in on one serial port is routed to the other and RTS and CTS on the computer side are “connected”, i.e., what comes in on the CTS input GPIO is echoed to the RTS output GPIO. Some of these programs, particularly the SDK versions and the vpbcom activeX control for VisualBasic6, verify the presence of a LEGO tower by pulling CTS low for about 30 ms, then putting it back to high and test all of the following three things: 1) Was RTS low, 2) did it get back to high, and 3) within a defined time, which appears to be around 50 ms. Both serial ports of MuLPI are set to 2400 baud, 8 bit, odd parity, 1 stop bit as this is what TLG chose as protocol. Output generated by MuLPI The output generated by MuLPI depends on the data coming in. In principle, these input data simply consist of two bytes: One ID byte followed by one data byte. As simple as that. ID determines the protocol to be used = one of the above; and data byte = action, e.g. power. Current (power) data range is -7 … 0 … +7 as this is the power resolution for RCX outputs, VLL, PF, RC Car, and RC Train. For PoweredUp, the scale is +/-0 … 100% but not used here, as +/- 0 … 7 always works for my trains. The PoweredUp scale is thus simply converted to the +/- 7 scale. Since LEGO IR messages can't be negative (data type is uint8_t) and should not be zero, -7 is mapped to 1 and thus +7 = 15. With regard to IDs: In my layout ID 170 - 174 = VLL; 175 - 179 = RC Car; 180 - 187 = LWP3.0 (PoweredUp – I believe Legoino handles max. PoweredUp devices), 192, 193 = RCX (my two RCX propelled trains), 194 = RC Train (my ICE), 195 – 201 = all PF trains, which are 4.5V/9V/12V trains. Communication data transport As mentioned above, both VLL terminal and RS232 port on the LEGO side are always active. The same holds true for PoweredUp devices, however only when they were discovered and are connected. The 1) built-in IR, 2) built-in 433MHz RF board, and 3) the BLE device discovery function can be turned on and off using three push-buttons on MuLPI; the buttons feature LEDs to indicate the transport status. This is totally overdone, but I like blinking lights and things visually changing their status when tinkered with. Built-in bidirectional IR: Mainly for testing and/or firmware upload to RCX bricks. The built in IR LED (front, covered by trans blue 1x4 tile) is powered by two parallel 74HC00 outputs at 3.3V and does thus not provide any considerable range. When the RCX (or any other IR devices) are located directly in front of MuLPI, all works fine. Built-in bidirectional RF: There is a simple 433MHz RF transmitter and receiver present in MuLPI, which can be turned on and off. When on, all signals on the serial LEGO port are also sent via RF/listened to via RF. This latter is only relevant for my two RCX trains, as they reply to an incoming message with a receipt message. All my trains have either a set of 433 MHz transmitter/receiver on board (RCX) or 433MHz receivers only (PF, RC Train). This way I can reach all of them without line of sight on my layout. This layout is built into my under-the-roof office; there is way more no-line of sight than line-of-sight. BLE discovery: As I don’t really know how this is done correctly using Legoino, the BLE device discovery can be turned on and off. I believe, the idea in Legoino is to discover BLE devices one after the other and in a certain order. When you initiate discovery for all known devices simultaneously, the ESP crashes (naturally) producing a very nice error message: One core of the two apparently “panicked” – I like that error message). I am initiating the discovery for each device every 2 seconds consecutively – that works and you can switch on the devices as you see fit. May be principally totally wrong what I am doing though … When done with the discovery, I turn that off and all discovered and connected PoweredUp trains are happily doing what told. Miscellaneous There is a JoyIt (Adafruit compatible) 1” monochrome OLED display showing the status of MuLPI. I really like lights and stuff, as this is also the way they do it on the USS Enterprise (NCC 1701) or on vintage computer main frames. I believe no one really knew what all the blinking lights meant other than: Power is connected and some program is running. However, on the ESP Dev board there are only so many GPIOs – and currently I have only 2 left over as outputs. Many lights = indicators would have meant to use a multiplexed LED matrix or the like. And behold: Yes, I did cut into this slope brick (4515), and I used glue to affix the OLED display. It is now a “modified slope brick”. As TLG doesn’t make these, I took the freedom of motivating them to do so . The display also updates the hub (PUp) connection status, the circles are filled when a (known) hub is connected and open when not. Protocol bit/byte streams encoding As of now I have compiled the encoding information simply into one PDF. Forgive me my stupid comments or inefficient programming – as said, I learned programming using (punched) tape cards (FORTRAN and BASIC) and then on my ZX Spectrum (BASIC). Moved on to MS QuickBasic (BASIC), MS VisualBasic6 (BASIC; my current programming environment) and also a bit into NQC and C++. Guess my “programming structure” when using the latter. Also, in the current C++ code for the MuPLI, THERE ARE EVEN GOTO instructions, which is the WORST THING EVER a C++ program should feature. As a BASIC programmer, I simply cannot care less … Rest assured though, that the ESP32 still runs fine. Also, the Arduino IDE did not crash without saving any data, when I typed “Goto”. Nor did the BIOS of my laptop melt down; it is still doing fine (I am c/p'ing text into this post right now from this vey laptop ). According to C/C++ gurus, all these things may happen at once and in parallel, when using Goto. For now these are screenshots of a PowerPoint/PDF. This link https://uni-wuppertal.sciebo.de/s/BbYzAnDGLwmWnv7 gets you to my university's cloud server for the original documents (hopefully with working embedded reference links). Here are just screen dumps: Here’s the “C++” code (Arduino IDE) running on the ESP32 – it is ugly but works. C/C++ professionals will certainly enjoy this section: Link to ESP Program MuLPI__ESP_V19: https://uni-wuppertal.sciebo.de/s/BbYzAnDGLwmWnv7 The LDraw file for the box around the electronics is stored in this folder as well. And as said, I’ll use this thread for changes/updates. And for numerous corrections – no way that I got everything documented correctly. Maybe I can hack the Cybermaster stuff hopefully soon … All the best, and have a wonderful Christmas season! Thorsten

Wow. Just wow. Now that you mentioned ... Man. BRIO never ever made such a crappy box art. Nor do the majority of the Never Mention Them Companies. What is going on here? Best Thorsten

Oh my ... TLG appears to completely lose it. They do the "you-need-two-of-these-sets-to-make-it-look-like-a-train" thing again? As in reasonable? As with the HE, one set looks like butchered? Wow. So 4-wide. Good idea. Compatible with wooden track. Well, after all, TLG started out with making wooden toys. Push along, folks! You know what? I just ordered four nice dark green carriages, 6-wide, each 40 cm = 16" long for a total of 100€. I found them in the Very Dark Net. This will be my XMas present. I simply had it with TLG, train-wise. Pirate ship-wise, I had it two years ago. My goodness. BlueBrixx is just one click away. All the best, Thorsten Yeah - on BRIO track. I fear though, it will not do the BRIO bridge so well. Better use straights only. Or did I miss the release of the "TLG 4-wide track system"? In that case, my apologies. Best, Thorsten

Quick question: What is the difference between the class PrimeHub and the class InventorHub? Thanks and best Thorsten

Google "resistor" + "LED" and "voltage". Then some entry may show this link: https://kitronik.co.uk/blogs/resources/which-resistor-should-i-use-with-my-led They have a web based calculator where type in voltage and other info, and then you have the resistor value. It is really worth the "effort", as it is fun to learn new stuff, and it actually works! Best Thorsten

Thank you very much! These were my key questions. So: Out with it. I want to program in either (VB)BASIC or "C++". Although my entire research group is programming in Python, I can't get myself to learning another language/IDE etc. Saves me a lot of money - I guess I'll browse some train-related catalogs (of companies located on the dark side of the moon;)). My BR23 still needs some decent carriages. Thanks again and all the best! Thorsten

It depends. For buildings, I mostly don't want to disassemble them. Also, I usually use "manipulated" bricks holding the LEDs = nothing for the purists. The wiring is generally in a way allowing assembly/disassembly. Best, Thorsten

I absolutely agree on this. Get some LEDs. They are dead cheap. 2mm, 3mm, 5mm. Use defined (red, yellow, green, blue, "white") colors first. Experiment with resistors (brightness). Move on to RGB LEDs. Explore LED stripes; they come with a remote, again, dead cheap. China is your friend. 5mm LEDs fit perfectly into technic holes (of technic bricks). Wires: As "tiny" as possible; today's LEDs need very low current. Experiment. Flexible wires for testing, rigid wires for final design, as you can massage them, and they stay there. Well, as far as I came, that is. Others may suggest alternatives! Best Thorsten

Hi Werner, just an inquiry to get your assessment (that I value very much!): XMas is coming up (by surprise, as every year), and the family is asking for my wish "list". I am sort of trying to follow TLGs micro-controller path, as you know. So far (for me), it was RCX, Scout, MicroScout, NXT, Spybots. All here. I skipped EV3, but got into BLE hubs. Have a bunch of City hubs and Technic hubs. Do you think 51515 will add something to this line-up? If so, I guess it will show up on my list. Nothing else then, because it is still a little pricey ;). If not, I guess I'll browse the ELV, Reichelt or Eckstein websites ... Thanks and all the best, Thorsten

Sick or slick? I guess the latter ... I find it incredibly smart - and again a proof for why am just one of the guys in the back row Best, Thorsten

Tipping hat, a slight nod, and a very, very deep bow. Congratulations and all the very best! Thorsten

Hehee yes, it is confusing. I am working on it - here is a crystal clear explanation of the gibberish on the cells form this website: https://www.fedcobatteries.com/design/cell-configurations For example, if a higher voltage is desired, cells are assembled in series and if a higher current capacity is desired, cells are assembled in parallel. Series batteries have the negative (-) terminal of the 1st cell connected to the positive (+) terminal of the next cell in the string. The battery voltage is the cell voltage multiplied by the number of cells in the string, while the capacity remains the same. Parallel batteries have both (+) terminals and both (-) terminals of each cell connected together. The battery voltage equals the cell voltage, but the capacity is the cell capacity multiplied by the number of cells in parallel. Cells in parallel should be matched for best performance, while lithium primary cells in parallel must have blocking diodes for safety reasons and lithium-ion cells must be matched for safety reasons. Series-Parallel batteries have identical string sets of series cells assembled in parallel at the (+) and (-) terminal ends, but the interior cell connections are normally not connected to each other. The battery voltage equals the voltage of the strings and the capacity equals the cell capacity multiplied by the number of strings. There are accepted industry abbreviations for these configurations. Examples: 1S1P = A single cell battery. V = Vc and Ah = Ahc 1S2P = A battery with 1 cell in series and 2 cells in parallel. V = Vc x 1 and Ah = Ahc x 2 2S1P = A battery with 2 cells in series and 1 cell in parallel. V = Vc x 2 and Ah = Ahc x 1. 2S2P = A battery with 2 cells in series and 2 cells in parallel. V = Vc x 2 and Ah = Ahc x 2. So the BuWizz 2.0 has cells in a 1S2P configuration?! Oh my. Wait, wait - the S means "Sets of cells" in series and not simply "cell". So 1S2P = 1set of cells in parallel configuration = 3.7 V with 2x 900 mAh = 1800 mAh. At least then the nomenclature would make sense. For the BuWizz 3 we have 3S1P = 3x3.7 V = 11.1V @ 880 mAh. Oh my. At least Thermodynamics is still good here ;) Best, Thorsten