UltraViolet

The specific compound movement and acceleration curve created by the combination of the big gears and levers, while simultaneously being driven from multiple points in the mechanism, is top-level genius! I love GBC, but find this type of thought process completely beyond my ability and imagination. I am merely a humble spectator.

I found this today: Boost programming block decoder | Brickset: LEGO set guide and database It mentions an official so called "crib sheet" for the Boost coding blocks, which for some reason was only given out by request if you contacted LEGO Customer Service: http://uploads.brickset.com/docs/legoboostcoding.pdf This sort of thing would have helped me out loads in starting out with the Powered Up app, as the majority of blocks are the same, and the descriptions are simple. The great irony with Boost, however, is that for the sake of entry level learning, there are a large number of what I would call 'macro' blocks which perform predefined functions that for the most part are fairly clear what they imply. While this would be very useful for novices, or just playing around with a prototype build, none of these are offered in Powered Up, although if you knew the content of these macros you could 're-build' them as custom blocks I suppose. But you can't know the content because they don't tell you, nor offer any examples. The PDF document ends at a page which appears to show the document was unfinished, and that they intended to eventually publish some code examples. Perhaps this was why they would only give it out when a customer called in confused. In any case, how hard would it have been to make a portion of this document viewable in the Powered Up app, or to put a question mark button or hover text help on each block icon? The posting on Brickset about this was from 2017, but we're now in 2021 and apparently nothing has yet changed. I installed the Boost app just to take a quick look at it. You can't do anything at all with it unless it sees a Boost Hub connected, so unfortunately (for now) only the 'crib sheet' will be of much assistance to me. I might consider buying the set for one of my nephews though.

Well, there was this video: Crossover Madness LEGO train - TRIXBRIX - YouTube Things get crazy at around 1:30 mark. Something about this creeps me out!

Okay, that's very cool! I wonder if they could provide a specification sheet for the actual motor from the motor manufacturer. I'd be interested in the true electrical properties and tolerances, if they are available. When I receive my order, I'll dig into these and see if I can learn anything, including if there is a simple fix for the axle depth/protrusion issue.

My father has owned and operated a mainframe software company since the mid 80's. He'd sure know what you're talking about. I occasionally did some hardware maintenance work for the company, but programming, particularly in the mainframe environment, never really grabbed me. It's unfortunate, because no one even teaches that stuff any longer. Anyone with that knowledge and experience is now in demand, as much of the 'old guard' has retired. It's gotten to the point now that mainframe is even running in emulation on production systems, but there are still large corporate mainframes in service running original code my father wrote back in the late 70's/early 80's when he was working for IBM. One of my earliest memories as a child (couldn't have been more than 5 or 6 years old at the time) was visiting my father at the IBM facility and seeing the reel-to-reel data tape machines as large as refrigerators running in service. He still owns in storage a compact desktop reel-to-reel model from much later which attached to a PC with an ISA card.

Okay, I'll bite... Perhaps the 5 year old could figure it out when presented with a ready setup in front of them, and prior guided experience with WeDo. This was not my point, which I thought I illustrated clearly, but thanks for telling me I'm dumber than a 5 year old. LEGO made the software and released it to market, not me. When a global company writes and promotes a flagship software package (Powered Up is supposed to be the central unifying app for the entire platform), and then puts their reputation on the line by saying people of any age and experience level can jump right in and make everything work out of the box and have fun doing it, you generally expect at least some basic guidance. The text of their glossy website singing the praises of the platform clearly implies coding is a promoted option, and that everything is supposed to be easy for "builders of all ages", which also implies all knowledge/skill levels. They didn't say there would be no learning tools, or say you should have had taken coding in early grade school, the closest of which I had access to at the time in the 80's was 10-line elementary BASIC programs on Commodore PETs, which was the best my school could come up with, and they barely explained how the commands actually worked. I learned more on my own at home about BASIC program coding than they were ever going to teach me. Even my technical high school only taught Pascal and Turing on wildly outdated computers. I actually found a compiler bug in Pascal which could not be worked around, but even after eloquently proving it to the teacher, a Computer Science grad, she didn't believe computers were fallible and docked me a lot of marks on my final major project. Who was dumb in this case? I had a choice between that school, and the only other one in the area which 'proudly' had no tech program ("tech schools are for dummies", and most of my community shared that outrageous sentiment at the time), and at which the only computers in the building were the CEMCorp/Unisys ICON. (Look it up.) My school also had a CNC milling machine in the machine shop. This was the first year after a retrofit which finally no longer required 'printing' your CNC code to a punched paper tape, spooling the resulting tape into the machine's mechanical reader, and then praying it behaved itself. Rather now, it was hardwired to the coding entry computer by serial cable. They always used wood stock in the machine, primarily because it had a habit of going haywire, the reasons for which were never properly investigated. The shop teacher was barely qualified to even know what a computer was, and always spoke in terms as if he was using a typewriter, and he could only two-finger type. He also believed computers were infallible, so if your code didn't work as clearly expected, it was always your fault. On the final exam, the machine was acting so badly that half the students never even got to try running their programs. The people who tried and had the machine puke got massively docked marks, the others who never got to try because of all the time wasted were given a failing exam grade. No disputes were entertained. The only thing really worthwhile I had access to in the final year of high school was an ancient Allen-Bradley PLC, the theory of which I had to research almost entirely on my own and without the benefit of any manuals. They basically just told me, "Well, if you're interested in that, be my guest." (This was at least a step beyond the print shop, which had a machine the size of a small car using single-sided 8" floppy disks to drive it, but they didn't even run any classes there any longer.) My family never had the money in childhood for LEGO electronics, and it was only in recent years in my 40's that I finally had enough disposable income to start making up for lost time. It is only in the last couple of years that I've gotten hold of various generations of LEGO programmable gear and started trying to put aside some of what little free time I have to learn how to use it. When I was a child, barely anyone even had a computer at home, the public internet was far in the future, and 'portable' cell phones were a numeric handset with a massively heavy battery/electronics brick 2/3's the size of a brief case. Most people didn't even have a VCR yet. No one was thinking about teaching coding to kids, nor generally did they have the means. Given the opportunity, hands-on technology learning in early grade school would have been glorious to me, and probably taken my life in a completely different direction, but it simply wasn't a thing back then. So, ya, these days the tools are out there to learn, but you have to know you need them, and most of the helpful content comes from the community. Plus these tools are not very helpful to you until you get the hardware in your hands to actually try with, as I just finally did recently. Iconographic software is fine, as long as it is illustrative. The emergency instruction card on airplanes has no written words on it so that anyone speaking any language can understand it, and everyone does understand it at a glance because the explanation is well illustrated. (Why on earth in Powered Up is a variable represented by an image of a cardboard box?) Perhaps a better comparison though would be expecting someone to learn on their own how to bake, but giving them no sample recipes, no explanation of what the key common ingredients are, their amounts and what role they play in the mixture, nor the sequence and timing of the preparation steps. Powered Up is presented like it's going to be a "Learning How to Bake, For Dummies" book, but when the book arrives, you find all the pages are blank. And that's not even getting in to the compatibility matrix headaches everyone is complaining about. Should I have expected to need to purchase and learn other older LEGO Education Division products in the past (often not available to the general public) in order to gain the necessary fundamental understanding of how Powered Up coding works? From what I've seen now with my first time, first hand experience, perhaps the answer is yes. But that is most definitely not what is being advertised to the public. There are plenty enough people out there of 'all ages' who found their introduction to Powered Up rocky and not what they expected given LEGO's sales pitch. There are countless comments to this effect throughout this forum and other avenues of complaint on the internet. I bought the Technic Hub alone, as is available for separate sale on LEGO's store site (where they recommend the Powered Up app for what will obviously be custom builds if you're buying a hub outside of a set). I purposely took the approach of coming at this from the standpoint of a typical member of the public. My experience sucked, even with community resources, and a fairly technical brain. I am not alone in that, and LEGO seems to generally not want it to be that way, but let's allow LEGO to speak for themselves on this subject. In another thread, when I was describing in what I thought was sufficient detail how to make a PF electrical modification, another member admitted they were still confused. My response was to carefully describe it again in even more thorough and careful language and to provide numerous photos for illustration. Should I have just told them, "Ya, you really are thick as a brick"? As someone who has been a teacher, a tutor and a volunteer organization crew leader, many of my pupils have entered their subjects or tasks with little to no background, and it was my job to encourage them and coach them in such a way as to quickly make them productive in their endeavors and come away from the experience feeling it was rewarding. I have also worked extensively in retail customer service, where people present with vastly ranging skill/knowledge levels and in which it is my job to provide the necessary knowledge and supplies for their project without criticizing or judging them, whether or not they 'should know'. Let's stick to helping one another on this forum for the better of everyone, no matter what your personal opinion or perceived understanding of anyone's abilities or life story is.

I've never heard of 'drifting' a locomotive! Seriously though, those 48's would look great on one of those older single main driver locos with the one really large drive wheel per side, especially if you go all-out with 10-wide.

I just ordered a couple of these kits so that I'd have enough motors for all three ports on one battery if I want it. My interest in this is primarily with the small motors, but I like the fact that the app control setup is so simple. This makes it great for young kids, as well as us big kids! I'm very interested in seeing if I can take the guts from the bluetooth cube and put them into a smaller footprint housing, as well as investigating a smaller connector/wiring scheme. They built these things to withstand being handled by a child, so unfortunately that made everything bulkier than it needed to be for the rest of us. I'm also considering the possibility of taking advantage of WeDo's lower voltage (old PF or new PU version) to drive these motors via adapters, opening further channels for experimentation and basic coding. It's really unfortunate they don't offer these motors separately (yet). They probably have no idea who all these kits are selling to all of a sudden and why. I'd buy more of these motors if they were offered separately. Fitting PF into 4-wide trains loses it's charm quickly. The webpage for the product has only a link to the iOS app, but there is an Android version. What I really appreciate about the Android version is that it only requires Android 5.0 as a minimum. This app is so simple, for the most part an older phone would be perfect for it. (Another fine example of this is the JMRI-related apps for DCC model train throttles on a phone - they're fantastic for supporting old phones that everyone has laying around doing nothing.) Plus I'd much rather hand a child a decade-plus old phone than anything current, for obvious reasons. This app makes for a simple to set up, and great basic remote control, without the need for a specific build for it to work. I'm hoping though, as some of you as well, that they eventually expand on the block coding feature. BTW, what do you think are the chances of the CiruitCubes Bluetooth Battery ever making it into BrickController2?

I will get around to it eventually. Once I'm a little more competent programming Arduino, Python shouldn't be too much of a stretch. Time is the problem, although given my above account, perhaps time better spent. I will then fold that back into expanding my understanding of EV3 and ev3dev. I have young nephews who I hope will soon be old enough to take an interest in any of this. Perhaps WeDo would be a better way to get them going, despite the limitations.

I welcome any and all manner of discussion about the PU platform. Recently I just received my first PU hub component, a Technic Hub, and this only because I was buying other stuff from a particular BrickLink seller and they had one for a very fair price. Otherwise I might have put more thought into choosing a hub in these 'early days' of the platform. Yesterday I sat down to the challenge of simply getting a single motor working with variable speed. First thing was figuring out what software it was compatible with if I wanted to code myself and not build an 'official' model. My preferred choice would have been using a Windows 10 computer, but the official software option is Powered Up app which only runs on mobile OS for whatever reason. (Android emulators are not an option because of lack of bluetooth support.) Not interested in fumbling with a tiny phone screen for custom block coding, I had to resort to dusting off the only Android tablet I own, which was shelved because it is an awful slow turd - The RCA Maven Pro. But it met the minimum requirement, Android 5.0 amazingly, and as a bonus has a keyboard and trackpad. Hours later, after having to recharge it from dead, Play Store broke while updating, got that fixed, and finished numerous other pending updates, finally got Powered Up installed. Started the app, but got hung-up enabling bluetooth permissions, had to restart the app. Finally got to the point where the app was running and connected to the hub - now what? With no formal documentation, I had to pour over whatever the community had discovered and elected to post on the internet, including some YouTube videos. Many hours into this process already and finally I figured out how to turn a motor on at full speed by starting a program and turning it off by cancelling the program. No interactive control yet, however I cheer because it feels like a major accomplishment. It took a while and a lot of reading, but I finally learned about the existence of the motor block type which does not have to run inside a play-loop structure. Why this is tucked away at the far right end of the block listing, I have no idea. With this I finally figure out how to use a virtual button in the on-screen control window to turn the motor on/off in bang-bang style. Progress, but not what I wanted. Then I spent another couple hours trying to reverse-engineer an ugly section of code from a YouTube video, which apparently is required to allow sequential speed step control in a sense. The example used a slider, but I wanted to use single discreet button widgets (not the two-way button or directional pad widgets). With much trial and error I eventually reached a basic understanding about what each sub-component block element was actually meant to do, and to some extent how variables work. With that in hand, I was able at long last to make sequential speed control with discreet buttons. There doesn't seem to be an effective way to have the speed decrease to zero without the use of a stop button if you want the speed to start at a minimum step. Also, not wanting the speed to cross zero into reverse when slowing down, as frequently happens with the old PF Train Remote, I eventually managed to code-in a limit which would only decrement the speed to zero and not beyond into the negative. But then how to effect a direction change? I spent a while trying a bunch of other messy logic, at this point having been farting around on this project for the entire day, but arrived at no satisfactory solution. With the hub having been actively connected to the computer with bluetooth all day, even though it spent very little time actually doing anything, the poor batteries finally gave out and the hub shut down. How anyone is supposed to pick up this product line uninitiated and accomplish anything is quite beyond me. No child would have even begun to figure this out. I had to spend forever on a real PC scouring the internet so simultaneously I could keep the PU app on-screen on the tablet the entire time. Why other official apps are available for a Windows computer, but not this one, is also quite beyond me. Why is there no USB port on the Technic Hub, and no rechargeable battery (as of yet) or external power supply? Not to mention that the size of the hub cannot be reduced by detaching the battery, since the outer walls of the compartment are the full dimension of the hub. No matter what, the Technic Hub isn't fitting in a train, so this hub will be most likely relegated to bench-test duty only, and I will order the USB power injector for it from PV Productions so it stops eating batteries. Why is there no coding documentation, not even basic 'hover text' or hints on blocks (even the text entry box on this forum has 'hover text' hints), nor pre-defined sections of assembled code blocks with explanations to start working from for common functions? I feel like I could have made better progress using an open source text-based coding language project, but I'm not a coding expert and can only store so much in my brain while I'm simultaneously trying to also learn the basics of Arduino, EV3, and Control Lab Logo (not to mention my adventures hacking DCC into LEGO trains). Plus, that wasn't the point of this exercise - to learn this the 'official' route. Why is every corporate sub-project of the complete PU family siloed in a way that stifles compatibility and confuses everyone even from a basic naming convention standpoint? Maybe I'm missing something, but that was my first experience with the Powered Up system, in which I dove into the pool head-first but came away feeling like it was the shallow end of the pool I dove into (ouch!). Basically, I feel lucky to have made anything work at all. I also feel lucky that the particular motors I had on hand, none of which are from the Technic sub-line, had no problem with firmware/software compatibility and could be used as "basic motors" on the coding blocks. This is not a "power on and go" environment, even with the benefit of third-party apps. At least third-party development has brought us the prospect of loading an autonomous program to firmware. (How many write cycles before the flash chip is shot though?) It feels like LEGO decided it was better to rip the UI and storage parts of the computer out of the EV3 and leave the hub part helpless/nearly brainless on its own. I am left stunned that in 2021 I accomplished far more in a shorter period of time, and with less effort/research/frustration, starting from scratch learning and installing an RCX and the Dacta Interface B along with their required relatively ancient computers and software environments. So this is supposed to be "Power Functions the Next Generation"? If original Power Functions were like a car - put in gas, insert key and turn, press pedals, go, Powered Up feels like they sent you a kit of parts without a user manual. It's like the steering wheel and other controls are not-preattached, you have to program the linkages from scratch with no information, and they don't even tell you what a steering wheel is to begin with. Powered Up is more like Mindstorms Education, but without any tutorials, and much like how EV3 used the same connectors as NXT but confusingly didn't support all the previous accessories (at least initially for some of them). Will everything in Powered Up ever be fully unified through official channels? No, at least for the WeDo 'prototype', yet another ill-advised silo project. The rest remains to be seen. LEGO, if you're listening - my number-one ask for Powered Up - documentation/examples for block coding (I really don't want to have to learn Python). My number-two ask, but almost as important - Windows 10 app, or integration with the Spike Prime or Robot Inventor apps. If I, as someone who has been using computers since the mid 80's, finds this package/support/hardware environment somewhat baffling and crappy, you're doing it wrong. For the time being, I'll stick to connecting my PU motors to older or third-party control hardware, using the third-party conversion and extension cables you refuse to provide yourselves.

My order of S32 track arrived today. Thanks, Michael!

That's cool! The Taurus kinda plays through every note in an octave due to the need for a more drawn-out acceleration sequence as required by the massively higher weight of a railroad train vs EMU/transit. Same theory though. On topic, track separation/loading guage on European railroads, and especially often on urban commuter/transit lines, is generally narrower than on North American systems, so this station model is an appropriate representation of many prototypes. Whether LEGO insists on being a stickler for "System" geometry in a build that isn't even operational and is not a direct corporate set from the normal LEGO line, remains to be seen. It makes for a great architectural display model or component of a static city scene no matter what. If I want to modify it to "System" functionality, I am perfectly happy to use this set as a starting point for customization. The critical thing is getting the bulk of the parts made available in one box, particularly if it's going to need that many garage door pieces.

If you want to change the 'personality' of the connected PU device without performing your own cable/motor hacks, you can perform a simple trick by combining a couple available cable adapter assemblies from PV Productions. Start with the PU-to-PF adapter cable, which features an integrated device type selector switch to choose between the two "dumb motor" modes, then chain it with the PF-to-PU adapter cable by stacking the PF connectors in the middle. Now you have a long PU-to-PU extension cable with a device type selector built-in! This also effectively can re-define any "smart" PU motor as a "dumb" motor, improving compatibility with some hub/firmware/app combinations if you don't need the position/rotation feedback in your build. Expanding on this trick, you could stack multiple PF-to-PU adapter cables at the mid-point if you want to power multiple target motors in parallel, while allowing a mixture of PU and PF/9V motors together if desired, so long as you respect the maximum amperage for the hub port. In addition, inserting a PF polarity switch in-line at the mid-point, or to any parallel branch individually, would permit physical/manual direction/polarity and on-off control independent of software or bluetooth remote type/configuration. Further, this would also allow the mechanism to directly interact with the motor(s) via the switch(es) if needed, as is a fundamental property of the Akiyuki Train System. + https://pv-productions.com/product/powered-up-to-power-functions-adapter/ (PU-to-switch-to-PF/9V cable) https://pv-productions.com/product/power-functions-to-powered-up-adapter/ (Get the PF/PF-to-PU version as first choice for the above trick - the PF/9V-to-PU version can't stack directly without the addition of old studded 9V plates or cables. You still get access to a 9V studded attachment point on the bottom of the first adapter cable end anyway.) These cables are relatively expensive, but are sturdy, safe, and reusable/reconfigurable at any time. In my case, I saw it as a one-time investment to dramatically improve my build flexibility and reduce frustration with compatibility. I bought most of the adapter cable and power injector variations made by PV Productions in order to maximize my creative freedom and minimize my use of batteries. Beyond my above suggestions, there are numerous other ways you can combine multi-generational devices with these adapter cables when used separately or in different combinations, which I do all the time, so the benefits out-weigh the costs in my situation. For example, I was running PU motors off my Dacta Interface B the other day! I am planning on writing a dedicated article covering multi-generational connections and components some time in the near future.

I am the right person to answer your question properly about this, and to straighten out the technical terminology . While I'm a transit fan in general, as a sound engineer in the past, and as someone who likes to understand how things work, I am always as interested in the sounds a particular transit vehicle produces and why. I've also actually had the opportunity to visit Montreal and ride the entire Metro system. The technology of this system fascinates me from the standpoint that it is mechanically excessively complicated - 16 rubber tires (8 load/8 guidance) and eight flanged metal wheels per individual car for a total of 24! Multiply that by nine cars, and you get 216 wheels per train!!! (And LEGO train builders think they have a friction problem...) It rides on two concrete tread strips, has two guidance rails that double as power rails, and also two backup running rails in case a tire blows out (the metal wheel falls into contact with the metal rail in this event). Even with all that it still relies on the metal wheels and traditional rail track switches to change route. The tires give a noisy and bouncy ride, while generating stifling heat in the trains and stations. The only benefit I can see in this system is better traction, meaning it can accelerate and brake faster and climb steeper hills than a rail-only train. The operational three-tone sound you mentioned is related only to the second generation of trains, the MR-73. This is an audible byproduct of the DC chopper propulsion control on these trains, which in a sense is like the PWM motor drive method which LEGO uses, but only to get the train up to a certain speed before full power is applied to the motors, which then continue to accelerate. In other words, the power through the motors is reduced by the chopper circuit until the effort required to continue acceleration won't overload them. The technology of the time period meant that some of the frequency steps used to perform the initial acceleration sequence were audible. The sequence actually used five frequencies - 90, 120, 180, 240 and 360 Hz. The first two were too low to hear normally, so everyone latched onto the pattern of the remaining three, the musical significance of which appears to be purely coincidental. The earlier MR-63 trains used a mechanical camshaft controller with rheostatic (switched resistance) starting, so all you heard on them was a clicking of the camshaft switch contacts as it progressed through the sequence. There were, however, two sets of MR-63 three-car units which had prototype chopper controllers installed in them, one from each of two manufacturers. The version supplied by Canron-Jeumont featured the same frequency steps as on the later production MR-73, but distinctly louder, meaning the first two frequency steps were clearly audible also. There is a YouTube video which features this distinctive prototype in service, the middle three cars of this nine-car train, and you can clearly hear all five frequency steps blaringly loudly: https://www.youtube.com/watch?v=tEa-zzlhn2Q The 'violent' intensity of the 90 Hz is particularly amusing. I hadn't seen that video before, so many thanks for prompting me to happen across it! It is quite captivating to me, given my specific interest. Sadly, all the MR-63 trains have been retired since my last visit. Thankfully I did have the opportunity to ride them a few times, including the manually-driven ones on the Yellow Line. The MR-73 trains with the chopper control as standard are still in service however. After two prior attempts by the STM at adding a suitable door-closing warning chime, the well known and loved 180/240/360 Hz 'musical' chopper sequence was adopted as the version which survives to this day, affectionately known locally as the "Metro dou-dou-dou". They carefully made the synthesized recorded sound just different enough from the actual train sound to ensure that visually impared people wouldn't confuse the two and try to rush the seemingly closing doors of a train already in motion. (This version also lives on as the door chime on the new MPM-10 "Azure" trains from Bombardier. The MR-63's never had a chime - the doors simply suddenly closed at scheduled departure time without any warning at all!). When riding an MR-73 now, it's kinda weird having the door chime sound, followed immediately by the same tones from the chopper circuit as the train pulls away, but it's such a pleasing sound you can hardly complain. There is plenty worse out there in the world, especially many of the early AC-drives. The craziest I feel has to be the 'demonic growl' of the ART Mark I linear induction motor trains in Toronto, Vancouver, and also Detroit in the USA. Perhaps a much longer-winded answer than you were asking for, but I appreciated the opportunity. I think I loosely tied in some relevance to LEGO there somewhere...

The brick-built track is a curious touch. Not necessarily practical for anything other than static display, but it did get my mind working on where it, or some part of the theory, could be used. Some flavor of a rubber-tired metro train comes to mind. I like the IDEAS set, whether or not there is a track geometry issue. The trains in both the original and the Jie Star rip-off are more interesting to me though. I'd really like to see more models that represent modern day urban EMU or subway vehicles. Many of these systems in Europe have very old stations and infrastructure with modern trains now running on them, plus some of these have narrow loading gauges which often feature narrower track centers. In my home country of Canada, there is a rubber-tired metro system in Montreal with narrow loading gauge and close tracks, primarily because the system was designed to efficiently fit into single-bore tunnel, since much of it would have to be deep-bore though bedrock. This system was inspired by, and very similar to, the rubber-tire conversion metro lines in Paris, although the Montreal system was built much later: Montreal Metro - Two MR-73 trains at Plamondon station. (source - Wikipedia)

Man, all you guys Europe-side are getting your orders right away. I ordered in Canada second day of the release and haven't gotten them yet. I don't blame them though, given they still have all their other duties going on in Ottawa. It's likely going to be an even worse 'frenzy' when the curves are released.

I have a related general question to anyone who can answer - What is roughly the maximum angle of bogie pivot you can see needing in a narrow-gauge MOC? Obviously this depends on the frame length and center-to-center distance on a given build. I like playing around with mechanism designs, and I'm trying to come up with additional practical ways to mount the bogies without necessarily relying on the vertical drive axle, while still giving enough freedom of movement.

I don't want to get too mired in this type of discussion, but I am sympathetic to the OP's feelings. That said, anything which gets LEGO out of their corporate bunker mentality, however small, is most certainly progress. Working for my own employer feels like working for a government agency - it's really hard to change anything that isn't effective policy, and my biggest obstacle every day is them. I succeed in spite of them rather than because of them. Do I still challenge them every time something is illogical or a double standard? Sure. Do I get a win most times? No. TLG is their own biggest enemy when it comes to nimbleness, and that lack of speed and flexibility I'm certain forces so much of the wall of secrecy which stifles community input, since otherwise they would always be beaten to market by the clone brands. My bigger problem with TLG than lack of train sets is in two areas. Price has always been the deal breaker for me. As a child, LEGO trains (among other things) were something for the rich, and mostly for the European market. Even most simpler sets were well beyond the financial means of my family. Now, as an AFOL, I would like better access to smaller incremental add-on sets which aren't all-in-one plug-and-play every time, and at a price which isn't costing you hundreds of dollars for redundant and over-priced PU hubs every time or for a non-motored model which isn't even designed to fit on track or work well even if it is. If anything train-theme gets produced through the IDEAS/BrickLink platforms, and I'm interested enough, I'm more likely to use these as a starting point for a larger model anyway, as I personally can't stand the squashed proportions of 6-wide scale. The other thing that kills me is selection of parts. We hear endlessly about the design and approval hoops any new part or color change have to go through to ever make it to market, and then if widely useful will require you to buy $100-plus dollar sets in a theme you have no interest in just to get one. (Or pay a good portion of that price on BrickLink for just the part and nothing else, with TLG now profiting even from that too.) Then we keep seeing ludicrously complicated one-purpose molds released which get barely used in a few sets and never appear again. But ask for an existing production part in a new common color? "Work within the existing stock". A proposal for a simple and flexible-usage new mold design which may have been widely desired for years, if not decades, and would benefit a wide variety of themes? "We'll decide what's best for the market by random chance, take at least two years to do it, involve half the staff in the company in the discussion, go as far as making production-grade test molds, and then cancel it before it escapes the veil of secrecy." As I just pointed out in the thread about the 3rd-party release of the FX Track system, the basic train motor has not seen any reimagination whatsoever since the 1980 variant of the 12-volt motor. That's 40-plus years of a static design, simply introducing various minor annoyances about the control/wiring with each power system generation. (6-wide trains are also a left-over artifact of the 4.5/12V system's goofy parallel track spacing geometry at switches.) If there was any one thing that's been an obvious crying need in the LEGO Trains community, it's been a more flexible drive system which doesn't require you to hold an 'engineering degree' in Technic construction. Is this design really so 'perfect' that it would get new mold tooling and 'guts' every generation, but remain fundamentally unchanged from the users' perspective and build structure? Nearly every other type of motor produced over the years has featured vastly differing designs - dimensions, attachment points, gear ratios, etc, but the train motor has remained frozen in time. Sometimes I feel lucky LEGO still produces trains at all.

I would very much appreciate the 'resurrection' of the studded electrical contacts in a compatible form. They have proven to be extremely flexible and practical for many things I've needed, including simple polarity reversals and interconnecting between the other later connector formats (PF/PU) using adapters (official and third-party) centred around the studded plates and related components. More new compatible components would be fantastic! One of the best things about the studded connector though was more simply that nothing had a permanent integral cable. This meant you only needed to add as much wire length as necessary to fit the application, and the two-conductor wire was much more flexible. Because of the insulation rot issue which plagued a lot of the 9V wire assemblies, I've taken advantage of the ability to dismantle the connector blocks in order to install new wire of whatever length I want. I am very excited about the prospect of simplified DCC installation. After having modified a couple of old 9V motors for this purpose, I'd really rather not have to repeat the process, and also would prefer not to destroy the originality of many more of them. More important to me than integral DCC though would be smoother low speed gearing ratio. I realize many people just want sheer speed or power, but my personal focus is on streetcars/trams. I was able to get acceptable behaviour with my modified 9V motors on my DigiTrax system, but it wouldn't start smoothly unless it was set to N-scale voltage mode. It is still difficult to maintain consistent speed on a heavy vehicle when transitioning between straight and curved sections. I have a five-section streetcar with three motors, and it is very challenging in that respect because the motors frequently get too close to the stall point. This also raises the point that I most definitely need it to be easy to interconnect multiple motors on one decoder with a common track pickup bus in order to achieve sufficient drive power and to avoid stalls. I'm working in 8-wide scale roughly, and the build weight quickly adds up. So given that, I'd really appreciate either a slightly lower gear ratio as standard (I think most people would agree the stock gearing was always unnecessarily high), or perhaps customizable with interchangeable gear sets. I don't know if you had a preference to go with worm-drive or not, although that would prevent pushing the motor freely when unpowered. I am also working on a model right now that will need a shorter wheelbase. As you've stated prior, I know you are trying to create as close as possible a drop-in replacement for the original 9V motor, but perhaps there is some freedom in there to add closer-set axle ports sorta like how the 9V buggy motor had two axle attachment points. In an ideal world, taking advantage of modern miniaturization, the motor assembly would be a smaller core which could be 'skinned' with a compatibility shell to expand it to the original standard footprint, but still allow a more compact configuration where needed. In other words, somewhat modular. I'm not expecting this to come to fruition, but if it did then I would have much more 'drive' to buy more new motors. I'm just throwing ideas out there while I have the chance. LEGO has essentially been making the same motor footprint since the 1980 12V version, and even that was hardly different from what preceded it. That's 40-plus years with no dimensional alterations, and hardly for much good reason. That's now five system generations with no flexibility (12V, 9V, RC, PF, and now PU). The 9V system also had a design flaw in the switches which created a dead-stall with a single motor at low speed when travelling curved route to curved route through directly abutting switches. So many people have gone through epic pains to build alternative mechanisms with Technic parts just so they can break the mold and do something more creative. I'm really hoping that some how, some way, there is an opportunity to finally have a motor that can fit more build designs. (I've patted myself on the back as much as I also gave myself an actual splitting headache designing compact narrow-guage bogies.) Technic-built motor bogies unfortunately could never be as compact and smooth running as a properly engineered, factory-built drive.

Thanks very much for that! I'm currently waiting on some additional differentials in the mail, as well as some of those frictionless gears, so I can do more experiments. Your design, which is strictly a two-speed transmission, will probably be best for my needs. The CVT-type designs are intriguing more from a general technical interest standpoint than perhaps a practical one, as they seem to be power inefficient, and also likely will have durability issues. That said, I will try out anything compact for the experience at the very least.

What I actually like most is the bottom of the tunnel wall where you have the hollow arches mounted upside-down. The ribbing effect somewhat resembles the iron/steel liners used in many deep-bore tunnels. Was this an intentional detail?

I really appreciate the concept you've developed. There are virtually endless transmission designs out there, but hardly anything that can work exactly like this. The challenge I face personally is that I tend to build small, and most practical transmissions I've seen are quite large. This design is relatively compact. Can any of you other Technic wizzes compact this even smaller? The overall length is less a concern for me than width, but I'd appreciate any further space gains. I imagine there are numerous ways to alter the frames alone in order to compress the assembly a bit more.

If you had the space to hide it behind holes or a trans-colored tile/brick, you could use the old 12V incandescent 2x2 light brick and simply underpower it with 9 volts. Or you could use two of the 4.5V version of the 2x2 light brick wired in series for a true voltage match. Back in the day, they were commonly used to backlight colored trans bricks, often with words printed on the outer surface, so brightness should be reasonable. The large 'window' on these bricks would allow you to place more that one in a row/stack for more coverage on larger models: 08010bc01, e.g. (12v/3-hole version shown, other minor variants available) Or, if you could actually get your hands on two of these antiques, you could go larger: x456c01 - 4.5 volt 2x4 brick, all clear body Both types seem quite affordable on BrickLink, I was surprised. I guess there isn't enough demand for them. The neat thing about the old bi-pin wire plugs is that the wire was attached to them with set-screw terminals, meaning you could modify wires at will or make really long ones without needing a soldering iron or having to mangle crimped ends. You could put a bi-pin end on a cut-off PF wire easily that way. Also, most of the bi-pin connectors had an extra set of holes for another connector to plug into it, making power sharing to multiple lights a breeze. As a child, I had two of the 4.5v 2x2 light bricks from the 816-1 light bricks set, and the C-cell rectangular battery box plus some wires. Brings back fond memories! I still have all the pieces, but I don't know where the light bricks are at the moment. I don't have the package any longer, unfortunately, but here is the image from BrickLink:

***Disclaimer - I should have said this before, though I think everyone should be aware - do this at your own risk! I have thoroughly done my research to the extent possible, and have competently verified everything using a digital multimeter and the various accessories I have on hand. These instructions are about as simple, clear and concise as I can make them. If after reading through this you feel confused or lack the skills/tools to attempt this, either don't try it or find someone else more experienced than you to do it for you. You will always need to make any future connections with the correct polarity, so be sure to label your components properly, and be careful! This cable should only be used for situations I've described - don't use it for anything else because it shouldn't apply to any other configurations. If you view any other photos or mod descriptions elsewhere on the internet, be certain to check that they are correct. I have personally seen at least three examples of incorrect mods out there, and more than one mislabeled PF pinout diagram. Here is an actual illustration of the cable modification I detailed earlier. For my photos I used a generic piece of ribbon cable, as I don't have enough PF extension cables to spare right now that I'd want to cut up fresh. The procedure is exactly the same anyway and can be done at any point along the length of the wire: 1. Split the ribbon in the center and spread the remaining pairs. 2. Strip the wires bare in each pair. Offsetting the strip point will avoid the need to insulate the stripped spots from each other after. If it is easier for you to cut completely through the wire in order to strip it, then you would have the option to use heat-shrink over each pair. In my simple example, you can just wrap the whole area with one piece of electrical tape. (I'm trying to make this method as easy as possible for a wide range of skill levels. If I were actually building it myself, I would probably opt for heat-shrink because it provides a more professional finish. Cutting the wire completely through would also allow you to significantly shorten the length of the modified cable if desired.) 3. Pinch each pair of bared wires together with needle-nose pliers and bond them with solder. (If you chose to cut completely through the wire in Step 2, you would have the option to twist the wires together, but I strongly recommend soldering for proper strength and conductivity.) 4. Wrap the area with an insulating tape. 5. Mark which face/side of the Light Bluish Gray connector end is always battery positive so that you will never forget when connecting - do not get this wrong! If this is not enough to remind you to preferably only ever use the modified cable for this one and only purpose, additionally mark it in some other way that is obvious, like using red electrical tape or heat-shrink for the protective wrap. (Technically you could also safely use this cable to make a PF Servo travel to and lock at 90 degrees clockwise with just the bare cable, or travel between 90 clockwise/center/90 counter-clockwise using all three positions of a PF reversing switch in your connector path/stack.) Remember - once you modify the cable, the onus is on you to connect the studded end to the battery box the correct way every time in order to avoid damaging your accessories. When using the 4760 9V studded battery box as your power source, you must observe the proper polarity of your connections as follows - with the on/off switch facing you, the cable may face straight away, or alternatively towards the right side (left or towards you is reverse polarity - do not do this!). Note again that I have clearly marked the always-positive side of this battery box with a red tile: You can now connect the normal power input connector on your IR receiver either at the dark bluish gray end of the modified extension cable, or stacked on top of the light bluish gray connector at the battery box end. It doesn't matter which end because this modification routes PF battery line power to both ends of the cable. As I mentioned earlier, I cannot speak to the safety of making the cheated connection on the IR receiver by attaching the battery power in through one of the motor driver output connectors, but I certainly would not recommend it. This modified cable is not the same and should not be installed that way - only use the built-in input cable on the IR receiver as LEGO intended. Now I have one bonus tip for everyone. Did you know that LEGO provided us with a very simple polarity and power-on indicator as a standard part? The 4767 light brick turns on solid when standard positive/forward polarity is present, but also helpfully turns on flashing when reverse polarity is applied to it. Once you figure out which orientation of the brick makes the light turn on solid, mark the side matching battery positive (red tile side) with a "+" sign or a red dot, and then you will always be able to check polarity reliably while also indicating presence of power on any studded electrical connection point. I printed a "+" sign on adhesive label tape with a Dymo printer: I'm using a 4770 red cover on the bulb to highlight what it is representing. Be mindful, and you will have happy modding! If you find anything to be in error, an omission, or simply have some additional helpful suggestions to provide, please post.

Thank-you for recounting your experiences. While unfortunate, they at least illustrate precisely the reason why I was trying to have everyone err on the side of caution. I see in the image linked to by 1963maniacs a V2 receiver that appears to have battery source connected in via one of the motor outputs. I can't see properly from the angle in the photo, but let's go with this premise for the moment to explore what would happen. If this were just a pure PF setup, that would work safely, because the PF battery lines are simply connected through internally between the receiver input and both output connectors. In that way, the receiver doesn't know the difference, and you could get away with still using the occupied output port by stacking. If, however, setting up as seemed to be shown in that photo and as per our premise, what then is happening is battery supply voltage is only passing through the C1/C2 lines backwards into the actual motor controller PWM output driver circuit on one port. For some reason this seems to actually work on my V1 receiver (with either polarity) for a motor connected to the remaining port, but I can't imagine it's a safe condition to create, particularly if you accidentally activate the first reverse-fed output from the remote, plus it also wastes a port. If Philo is reading this, I would very much appreciate his assessment of the risk and what is actually going on in the circuitry when you attach this way, and whether or not there was any difference in this regard between V1 and V2 receivers. My recommendation is to not do it like this. I've certainly never heard of it being an officially intended configuration. I will illustrate the cable modification technique some time this weekend. Unfortunately I was occupied with an urgent situation over the last few days, or else I would have done this sooner. Stay tuned... EDIT - I'm adding a thought to this entry that occurred to me today. The photo linked to by 1963maniacs may also have featured shorting by pieces of foil or metal tape on top of the light bluish gray connector, sandwiched between that and the dark bluish gray connector stacked on top of it, then leading into the normal input on the receiver. While this is certainly a solution, although not a durable one, it would not have been implemented correctly in that photo. Since the wire leads are facing out the wrong side of the box, this would be putting backwards polarity into the light bluish gray connector. The foil shorting would therefore have had to be applied incorrectly also in order to flip the polarity back to normal again on the stacked dark bluish gray connector leading to the PF receiver. Such are the pitfalls of incorrect information or trial and error. Following the lead of this example unnecessarily confuses the issue, and so I recommend not doing it that way.