UltraViolet

If anyone buys the 88011 from lego.com (North American order fulfilment) using the "new" listing, check the packaging to see if it has a new item number and or UPC code. The one I have from a couple years ago has item #6261456 and UPC 6 73419 30911 0. There could be no change of any real substance, like they could have merely updated some of the printing on the polybag. Maybe they've switched to the non-plastic type packaging? Or it could actually be an internal production revision of one or more parts in the package or motor assembly. Whatever the answer, it's probably the same reason for the disappearance/reappearance of other PU items (aside from the screwed cover change to the 88012).

If just keeping main power input overdraw or loss from resetting the PFX Brick is the primary problem, don't forget that the USB input on the side can be connected at the same time to a separate 5V 'keep-alive' power source. (The brick can use the USB input alone for lower operating voltage setups, although in my experience the chances of overdraw by a motor causing resets is much higher if only this input is connected.) Part of the design of the Brick was parallel power source ability, where the greater of the two sources will determine the maximum motor output voltage, but with the combined overall power (wattage) of both inputs. Connecting both sources at the same time may not entirely eliminate the possibility of resets, but it would be worth testing. You may find just enough room in your compact shunter for a tiny lithium flatpack cell and an equally tiny 3.7V-to-5V boost board to feed the USB connector the supplemental power. You can buy bare micro-USB male connectors from eBay or other suppliers, and these take almost no space if you use one to make your own compact two-wire cable from the boost board source. When I have time, I will experiment with this theory myself, as I have numerous small lithium batteries and DC-DC converter boost boards at my disposal. I got most of these parts with the intention of building much smaller than available custom battery packs for directly driving 9V devices, but the option is there to also try this parallel power source method with some of the same hardware. I have both fixed voltage output and variable voltage output boost boards, so any target voltage can be achieved with what I have. (There could even be a 5V boost for the USB connector and a 9V boost for the main PF input coming from the same battery via the use of two boost boards at once, should the scheme be only battery power for everything.)

I was chatting with Michael at the Bricks In The Six show last weekend about the switches (and about many of the other coming items he had prototypes for along with him). It was nice to finally be able to hold one of the switches in my hands and take a real live close up look at them. I can assure you that branch/route isolation would not be a problem, as even if you didn't take advantage of the incorporated jumper solution, there are numerous screws holding the wiring PCB under the frog and also the cover under the mechanical switch blades, allowing easy access to make your own modifications should you feel the need. End user maintenance was a key factor in Michael's decision to include the screw-on assemblies in the design, but some users may wish to take advantage of the access for other purposes. The same approach is being taken with the new motor bogies, when they're eventually available. Below is a photo of one of the prototype P40 switches next to a stock LEGO one as installed on Michael's display layout at the Bricks In The Six show. This one has the earlier revision of the throw rod which will not be the type on the production run. Note the copious use of his new short straights!

Thank-you very much for finding this information. Changing the PWM frequency that much dramatically higher could certainly explain the difference in motor response. They actually directly stated this change would affect the torque curve. If I read right, this change was committed in the version 3 Pybricks firmware. I'd really like to know if anyone testing multiple versions can replicate my observations. If the change in frequency was the culprit, it certainly should have been implemented in a way that allowed you to keep the old frequency if you wanted, rather than just forcing it to the new way and assuming everything would be fine. I don't care whether or not I hear the PWM frequency - I just want the same motor performance. I actually appreciate hearing the PWM because it allows me to tell whether the hub port is on at low speed steps and whether the motor is stalled. Do you guys feel this should be reported as an issue in the Pybricks GitHub? The thing I don't understand is why an even higher frequency would work on the EV3 and not on PUP with a similar one. There must be some other factor(s) at play in the operating parameters for the PUP devices which would result in weak motor response.

The PWM sound is loud and clear when using Powered Up app with stock firmware, and completely absent as far as I can hear when using Lok24's code with Pybricks. I wish I had an oscilloscope so I could tell what was different about the waveform, other than perhaps amplitude. This is using two otherwise identical City Hubs, with a Keybrick One as the power source swapped back and forth between them. Maximum output voltage on both hubs, measured with a digital multimeter, is 6.04V. I devised a method to test for the presence of PWM. I used PV Productions adapter cables to patch an old 9V studded light bulb in parallel in the middle of the line. This type of bulb blinks when fed reverse polarity. The blinking interacts with the PWM signal, creating a variable flickering effect dependent on pulse width (this can also be used to create the lighting effect for a campfire, candle, or even a welder - You're welcome!). The two hub configurations both exhibit the flickering light effect running in reverse direction, therefore PWM is the basis of the motor control either way, although I figured that must be the case. Something is still clearly different between the two, though. Perhaps the stock firmware/code alters the PWM effect at slower speeds to prevent stalling and improve starting torque, much like the software option available on the PFX Brick. Something similar was available on straight-DC model railroad transformers, usually called "pulse power". It was only active at low speeds for exactly the same reasons. Someone much more familiar with device handling and code functions within Pybricks is going to have to comment on this. It's entirely possible the same behavior as stock can be activated with a single flag in code. I should add, if it helps explain any of this technically, that with Powered Up/stock firmware, if you start the output low enough that the motor is stalled, you will hear a pure 1200Hz tone. Once the motor starts spinning, the tone gets interfered with and kinda warbles. The loudness of the tone seems to decrease with speed increase. This may be the frequency of the low-speed assist control, or it could be the main PWM signal. That's as much as I have the tools to observe. This tone is entirely absent on the Pybricks setup I'm comparing it to.

Now that I've been able to have the connection working, I've started testing some build scenarios to see how everything behaves. I've immediately run into a challenge which raises interesting questions about the possible different approaches to driving and managing the motors with Pybricks versus standard firmware functions. I have a train motor bogie built from a WeDo motor. When using basic variable speed coding in the Powered Up app through a City hub with stock firmware, the motor starts and runs fine. On the other hand, If I use the Pybricks firmware and the code we are discussing here, the motor cannot overcome the gearing resistance to start spinning without me forcing it by hand, and it will stall fairly easily. That got me thinking about how many modes or 'strategies' there are available in Pybricks (and in the hubs in general) to generate the variable voltage output to the motors. The stock config audibly emits the pulse-width modulation sound we are familiar with from the Powered Up and Power Functions hub outputs. The Pybricks code in our discussion, however, does not make this sound, or if it does, not at a level I can hear. Taking a loosely educated guess, it seems like the Pybricks code is not using full voltage as the basis for the PWM output. Can anyone with enough knowledge of the code comment on this? Is there any way to have the code modified to produce the PWM output in the way the stock firmware is generating it? I read through the code again, and I gather this is buried in one of the Pybricks pre-defined functions which is being called. So is it a matter of calling an alternate function, or does the content of the function itself need to be altered? I vaguely recall something from another coding situation about 'speed' control versus 'power' control. Would this have anything to do with it? I'd greatly appreciate if someone were able to figure this out.

I was greatly interested in this project, but as I'm not much of a programmer, and also don't know German, I didn't have much luck with it early on and hoped others would 'pick up the torch' and grow it. Obviously I have even more interest now that I've had it working for the first time. I hope you don't feel that your work was not appreciated. I have written a single Arduino program ever, relying heavily on example code and existing libraries. Python, in this context, is very similar, but as with any other programmable controller platform and language, syntax and lack of key technical knowledge are the killer when starting out. I will do my best to experiment and learn now that I have a concrete example that is working for me on my hardware. I really hope others with in-depth knowledge of the LEGO-specifics and more fluency in Python can help drive this project forward and give it a permanent home. The problems you ran into which you described above are exactly the kind of thing I'm talking about. Even someone with experience such as yourself ran into trouble debugging code after the firmware side of it changed (essentially why the Linux Kernel drives me insane), enough so to quit in frustration. As a rudimentary-level coder, I'm not equipped to help with that, but I can understand enough to test others' end product. LEGO themselves should have offered an official solution to do exactly what this project accomplished. The only thing even close is how the default program on the six-port hubs allows you to run motors up and down in speed using just the arrow buttons on the hub itself. This is a joy on the design workbench, as I can just manipulate physical parts when building and testing MOCs without the need for programming in the PoweredUp app or a mobile device. It is also the only realistic scenario for many children to use the PuP platform outside the bounds of the pre-defined models, but perhaps also for many adults as well!

I am ecstatic to be able to report that this is working for me! For whatever reason, I could never get the remote to connect to it prior to this version. I swapped out the .py file from the 3.1.0 zip file with this patched code, and then it just immediately worked as it was originally supposed to. I used the 3.3.0b8 version of Pybricks UI for the firmware write. Now it would be great if there was a little more documentation on how to customize the operating modes/parameters. I can see some of the things that are easy to edit in the code, but I'm only now at the point where I can actually test any changes due to the connection finally working. Many of the parameters were hinted at in the original documentation but were never spelled out in detail (doc links broken now anyway). Nearly everything I want to control will involve technic motors rather than train motors, so the performance characteristics and operating scenarios will be quite variable. Perhaps those of you that are more versed in the use of the code can post some parameter instructions in this forum. Thanks again to the OP for his work on developing the project. This finally brings the PUP experience much closer to that of the PF system. I can hand the basic remote to my young nephews and expect them to be able to understand it immediately, as well as not risk them trashing a phone. It's also super easy for the workbench when just designing new builds.

Any word on when the S32 track will be back in stock? I would have placed a larger preorder than I did on the new track items, but I'm waiting on the S32's to reappear. It seems there is an insatiable appetite for these. I really would have loved to see an S48 to fit the 48-stud baseplates using just a single section, as I'm making a large number of modular street-track sections using these baseplates. What I really need, though, is fully hidden electrical feeders that are flush with the railhead and don't have more than 2x2 tile surface visible with the wires attached. Soldered wires are my only choice at the moment. The prototype feeders you have shown are the wrong colour for the Light Bluish Gray tiles I'm using to emulate poured concrete around the track, so I'm hoping you can also offer LBG colour, in which case I may be able to make them work by permanently attaching the wire to them. (That is, once they are eventually available, of course). I'm also dying waiting for the release of the new motor bogie! That's going to be the real game-changer.

I just got a couple of Keybrick One battery packs for my City Hubs so I can experiment without chewing through regular batteries. Now I'm looking to clarify something about setting the remote configuration. If I gather right from what you've explained in the documentation, the configuration for using a City Hub is actually stored in the name field of the remote control. Am I able to rename the remote simply by using the Powered Up app to store an RBB configuration string, then disconnect the remote from the app and connect the remote to the RBB firmware'd hub? I have loaded the RBB firmware on a City Hub and it seems to communicate with the remote, but errors out and drops the connection, suggesting a bad string. Have I put an invalid configuration string in the remote (tried using the only two examples in the documentation), or am I doing everything wrong? I'd really appreciate seeing some additional configuration string examples which would work correctly with the City Hub so I can get this functioning at all. I would much rather have this working with the City Hub than any other hub model. (I have flashed the latest firmware file directly, as I am aware of the PyBricks 3.2 compatibility issue.)

Based on your diagram, I think I figured out another reason for the geometry, and it's kinda cool. I don't know why I didn't notice this before - the 'new' style Duplo curved track fits exactly inside the radius of the standard LEGO train track! Also, because the 'new' Duplo straight track is the same length as a standard LEGO train straight track, you can put a Duplo oval precisely parallel inside a LEGO train oval! I will note that the fit is just a tad snug, causing a slight lifting of the Duplo track, but if it were attached to a baseplate then it would stay flat. I think it illustrates how LEGO likely made their decision though. I figured out why the fit is so snug, however, and I don't know why LEGO did it this way, but the ties of the curves are about 1mm wider that those of the straight track sections. You can actually see it easily when comparing the bottoms of the track pieces - the wall thickness on the outer faces of the ties on the curved sections is 0.5mm thicker. If one loop were boosted enough to have the tie ends not touch, the interference should be eliminated. Your custom wide-radius Duplo curves would fit on the outside of the LEGO track in nearly the same way, but they're wider by about one LEGO stud. That might not exactly fit baseplate geometry, but it probably works fine sitting loose on the floor.

I took a look at that design, and it does raise some challenges with current standard geometry. But it also got me thinking about the older geometry of the original black colored track. The irony of LEGO's design change to the shorter track segments on the 'new' track, is that the old geometry with the longer curves and straights would have accommodated left-hand/right-hand switches without any compromise or partial length track segments for correction. (It's further ironic that they then chose to only made a parallel switch!) The straight track 4563 is 176mm in length vs the 127mm of the 6377, and the 4562 curves are 45 degree and at a tighter radius than the 6378 at 33.3 degrees. The newer geometry must have been used to allow the straight track to fit on baseplates, but since the curves never would, the benefit is not as great as it would seem. (The old track is a rare example of LEGO creating something 'out of system' and then 'backtracking,' so to speak.) While designing around the 'old' geometry is certainly something I'd be willing to accept, I figure the best scheme would be to use the newer geometry at 1.5 length for straight and curve on the switch and then make compensating 1/2 straights and 1/2 curves. The 'old' system had shorter straights (4665) in addition to the long ones, so there is some precedent. Half track sections open up many other possibilities for layouts on their own, regardless of whether new switches exist. This approach would likely benefit the maximum number of users. I don't know if it would work out for a parallel passing siding without and odd-length compensating straight, but I'm sure you could determine that easily in the CAD environment. I will note about the example you gave on Thingverse that the mechanical design of the moving parts seemed well thought out and could prove practical in a revised geometry. BTW, I'm enjoying this discussion for that fact it's made me think about these parts in ways that I'd never quite before. It really helps get you inside the head of the original parts designers. If something new and useful comes out of it as a workable printable model, even better!

Great to see someone finally taking a stab at creating some alternative track designs for the Duplo trains. I will very likely try to get some of the wide curves made up. The one thing I've really been missing is switches with one straight and one curved route, rather than the official wye type. I understand why LEGO made the decision to only make a wye type, as it was simpler, and adequate for children's play, to only produce one mold, rather than having to make separate left-hand and right-hand switches. It would be fantastic if you were to create a design for those, though. The upside of 3D printing is that you only have to draft one 'handed' computer model which can then be flipped to make the other.

I'm aware PUp is bluetooth. I'm only distinguishing between the two 'vintage' IR protocols. My subsequent mention of PUp only pertains to the ability to send commands from a PUp sensor element to allow controlling PU from PUp.

Having only used PF myself, I'm wondering if anyone knows if the "new" PF protocol was designed in such a way that it would not cause interference in the same play space with the "old" IR protocol, whether or not this had anything to do with subsequent feature additions? Can they coexist if transmitting simultaneously? Also, I know the ability to send PF commands was made available in PUp, but would the equivalent code theoretically be possible to support the earlier IR protocol?

Take note that both types of Circuit Cubes motors are not rated to handle full voltage from a standard PF source. Operating them at 9V would likely burn out the coils very quickly, and even the lower voltage PF rechargeable battery box would be unsafe. Here are the specifications I received from John Schuster at Circuit Cubes in response to my questions about the smaller motor: "The motors in the Cubit (2x4 stud pattern, 2 bricks tall) operate at 3-6 VDC. RPM about 160 at 4.2 VDC no load. Approximately 5.5 N.cm torque." Now that said, I found that the PF IR receiver operates perfectly fine from a lower than normal supply voltage. These motors worked great at all speed steps from the PF IR receiver when hooked up to a custom power supply with a suitably lower maximum voltage. In my case, I used a cheap and readily available adjustable voltage step-up board sourced through eBay to operate at 5 to 6V from an 18650 lithium cell (any format of standard 3.6-4.2 volt lithium cell will do, so choose what physically fits best in you build). This step-up board maintains precisely the voltage you set no matter the remaining capacity of the lithium cell. The bonus of this board is that by adjusting the maximum voltage output, you can tune the performance of the motor to your needs if the maximum voltage is too fast for your application. If you want to use a PF battery box, you'd have to install dummy cells as spacers in place of two of the AA or AAA batteries so your total max voltage would be 6V. (Be careful if you're in the habit of using non-rechargeable type lithium AA or AAA cells because they often put out higher than 1.5V at full capacity.) So long as you respect the 6V maximum supply voltage, you should do no harm.

Consider also whether you need high speed ability or low speed torque. I will cite a build of my own only as an example of the concept, since in my case I was using the original 9V train motors. I am constructing a 3-bogie, modern multi-segment tram model. For the sake of cost I tried to get away with using two motors and one un-powered brick-built bogie. While two of these motors certainly can deliver a fair amount of torque, the internal gearing is optimized for high speed. The two motors had much difficulty smoothly starting at low speed and maintaining consistent slow speed, particularly through curves. In the end I rebuilt the un-powered section to take a third motor, and the resulting behavior is much better, considering my need for this model to always operate at relatively low speeds. (As a side note, some of the 9V train motors are inconsistent in speed and in the required voltage to get the rotor spinning in the motor, so I've tested a number of them to find the better ones for this application.) Had I been building my own drives using separate motors and gears, low speed optimization would most certainly not have been a problem, but complexity and fragility potentially would have been. I've experimented with quite a few different drive designs and found that each motor type has an optimal gearing where there is a balance of speed and starting torque. Each combination will suit different build situations depending on what you want to accomplish in terms of weight/speed/starting torque/size/battery load/run time/hub max capacity/build strength, etc.

Thank-you very much for that link to the motor teardown. The information presented there leads me to believe two things. The first phase of the motor update where the motor actually is fighting the shaft lock more than likely checks for valid calibration of the reference point for the hall effect sensor versus the completely random field alignment of the ring magnet from where it was placed during production. The magnet has four teeth on it to keep it in a fixed alignment with the output shaft, but the receiving teeth on the shaft allow somewhere around 22 possible relative angular positions versus the shaft zero-angle mark, and there is no starting point of reference physically - the relationship between the magnet and the sensor must be uniquely calibrated. The second, longer, phase of the motor update, if and when it occurs, very likely writes this calibration data to the microcontroller chip if it had differed from saved data but may also send a revised version of the microcontroller firmware. It would be very interesting to know if and how this affects other motors or even sensors in the whole Powered Up family, and how it is handled in the various software packages. What would be the implications after the Mindstorms software is dropped from support/availability? It would also be nice to know why the motor update has to be performed after a hub firmware update, where I can only guess that if the new hub firmware contains an updated motor microcontroller firmware, the software insists on checking the motors to see if they need this update applied also - the zero-point calibration seems to be done no matter what as insurance that it is correct. I would have to think that the calibration data would need to be retrieved from the motor first before being injected into the microcontroller firmware file before it is written back to the microcontroller. Every new motor I've seen came with the zero-angle mark sitting at zero already, implying that all motors go through an initial calibration at the factory when they are first programmed and tested on the production line so that they at least have a good chance of functioning right when fresh out of the box/bag. I do try to keep all my batteries maintenance charged on a regular basis, no matter the chemistry. The same thing applies back to lead-acid batteries (non-LEGO devices) - They will often become unsalvageable if not periodically topped up. I have a large number of AA/AAA/9V lithium batteries with built-in USB charging and constant voltage circuit. The internal circuit bleeds the lithium cell over time, so I have to keep them regularly refreshed. Interestingly, the much newer production ones that have USB-C connector are worse for bleed than the older ones I have with micro-USB. I would recommend the Beston brand ones to anyone interested, although you'll likely have to order them through Aliexpress or similar. Just bear in mind that I found the physical length of this brand for AA/AAA out of tolerance - They are ever so slightly too long physically, which makes them very tight when inserted in battery housings. Other than that issue, they've been great.

When the process was running on my four motors, all of them spent the same brief amount of time trying to fight against the required shaft locking device, but it was the time period following this when the motor was not trying to turn any more that was significantly longer for two of them to reach the end of the progress bar. I would really like to know exactly what it was doing during this phase and what communication is actually taking place with the hub. Is this process unique to this hub and these gray motors, considering the above mention that the Spike app never does it at all? The motor update screen won't acknowledge the presence of anything but the regular gray motors. I wish more of the tech info was properly documented. By the way, I just received a spare yellow battery, and yes, it is identical to the original Mindstorms hub battery in every way, right down to all of the text printed on it. It is relieving to know I have options now. This also means I wouldn't be quite so concerned about opening one battery to rebuild it should it fail.

Thank-you for the suggestion about the education market dealers. This was very helpful to point me in the right direction. I have found a couple online stores based within about an hours' driving distance from where I live who carry the Spike battery. They also carry a lot of the other Spike Prime series parts individually. Additionally, there are many other item categories unrelated to LEGO they carry which also may be of use to me in my other hobbies, so big plus there. In case anyone in Canada is interested, they are http://spectrumed.ca and http://studica.ca - Studica even sells a large selection of CNC machines!

Within the past month I bought separately the Mindstorms hub and four gray motors, just to make sure I had them in my collection before they became unobtanium or prohibitively expensive. Like every other hub I have, I immediately connected the hub to the software to make sure its firmware was up to date, both to ensure it worked with the current software version and also to make sure it was updated in the case that it becomes impossible after the software is discontinued. Then it asked to update the motors. I can understand calibrating the zero point on the shaft rotation, but what does "Updating the motors" actually imply? Two of the motors completed the process within a few seconds, but the other two took significantly longer. What was the difference? They were all bought brand new at the same time directly from the LEGO Store. Do these motors actually have an updateable firmware inside them? Does this process have any effect on compatibility with other hubs and software, updated or not? This also only affected the gray motors, as the one motor I have which is color-matched to the hub was ignored by the update process. I don't like when software performs operations that don't fully explain themselves. Is the update check and download performed entirely locally to your computer, or does it have to check a remote server over the internet every time? Will this process continue to work in the future after the software is discontinued if I buy additional hubs/motors on the secondhand market? LEGO seems to be implying that this hub and motor will be completely abandoned in software/firmware support, even though they have indicated that everything else in the Powered Up ecosystem will eventually be migrated to the Powered Up app. I guess we will only learn the hard way if this becomes true by their actions rather than any formal public statements, but it would be nice to have an open line of communication about this. This is an awfully expensive piece of hardware to end up possibly being 'bricked'. There's nothing stopping them from dropping support for any other hardware either, before Powered Up reaches its final state. (I know about PyBricks, but unless it will allow duplicating the original programs and functions without going to coding school, I'm not very interested. The "Remote BlaBla" project however is quite intriguing to me, and hopefully full/near-full function can be extended to the Mindstorms hub.) I tried to ask LEGO Support the simple question if replacement batteries were available and orderable for this hub, and if not if the battery for the Spike Large Hub would be a drop-in replacement (I assume "Yes"), and if it was available to order as a fallback. Eventually these batteries will fail, possibly ballooning too and ruining even the battery casing in the process, so it would have been nice to know what their commitment was to replacements. LEGO refused to directly answer my questions, instead dancing around them and suggesting if I had a defective battery then I could ship it back to them and they would inspect and test it before considering supplying another one as a sort of warrantee replacement. The new Spike Small Hub has separate additional batteries available openly for purchase on the LEGO Store, but for the two large hubs nothing and no honest answer. Apparently if I want an extra battery even just for additional run time, my only option is to buy a complete new hub for a small fortune. (The resale market is of little help, as postal regulations prevent most methods of shipping lithium batteries from most other countries to Canada unless perhaps you have some kind of business import registration. Oddly, I can get almost anything shipped from China without issue, but nearly anywhere else gets stonewall blocked by Customs.) If anyone has any concrete answers to anything I've been rambling on about here, it would be greatly appreciated.

As this topic relates to a project that will be on rails, I figured I would ask the question here. I am attempting to script a seemingly basic function on the PFx Brick, but can't for the life of me understand why it doesn't work. The scenario involves two LEDs - one is green and gets turned on immediately at power up (via a separate startup action), and the other is red. The action I'm trying to script is when a remote control button (or joystick) is pressed and held, that action runs a script that turns off the green LED and turns on the red LED. When the button is released, another script reverses the LEDs so green is again on and red is again off. The script code for when the button is pressed is as follows: light 1 off light 2 on The script code for when the button is released is as follows: light 1 on light 2 off The first line of each script file will work properly, so one light turns on and off as expected. The second lines, however, never do anything, and the order of the two lines makes no difference. I noted in the documentation that in the case of "event" commands, multiple actions may be triggered, but each type of action can only be called once inside the statement. While I'm not using "event" commands, is this still why multiple "light" commands get ignored? This shouldn't be the case according to the limited script code examples I've seen. I've also noted that the script files are only recognized as scripts by the PFx application if they have a ".txt" file extension, which is at odds with the documentation that says the extension should be ".pfx". If I have to make this work in a one line command, the only thing I can think of is to cheat with the RGB color LED command, as that would affect multiple output pins simultaneously.

It took a little while before I could ask my dad about IBM, but the answer I can give you is that he was primarily working with financial data processing services. In the early days of his career this goes all the way back to the era of punched cards in the 60's, as well as sending/receiving reel-to-reel tape data across the country over phone lines long before most people even knew the concept of a modem. (Likely wasn't even 300 baud.) I will move any further discussion to the other thread after this.

As far as I know, the Wuppertal system is the only one of its kind in operation. The Memphis Suspension Railway is similar but cable-driven and not a full-fledged transit service. I think there's also a mountain incline railway like this using cable-haul. Most suspended monorails use a hollow box-beam with rubber-tired bogies travelling inside, with the train connected to the bogies through a slot in the bottom of the box structure. www.monorails.org is THE site to visit if you want to read up on everything monorail. Now what I'd really like to see is someone attempt to model the Lockheed Monorail as found on the defunct Himeji Monorail line. It's essentially a Lartigue configuration attached to an elevated concrete beam, but marketed as a brand-new space-age invention.

I don't think there is a complete detail image of the "Space2310 Bogie" remaining anywhere online now. Perhaps someone using this design could show it with the wheels and side-frame removed from one side. (I understand how to build it now, but it took some time to figure it out. I don't have one assembled at the moment though.) It would be nice to see a dedicated bogie thread, whether for 4-wide or everything else combined. The examples are so scattered all over the place, and many images are no longer available. I'd love to have such a thread even just as a place to throw around ideas for inspiration and discussion. Some people are better at bogies/mechanisms, while some are better at the rest of the model building. Put the two together and it will likely help many people out. I myself have created some compact bogie test designs with no specific model in mind to put them in, done simply as a technical challenge and a foundation to expand on. I'd happily share them to see what others might do with them, and how they might be improved upon.