Hod Carrier

My apologies if, in my ignorance, I’m misusing a term that has a specific meaning. The flexibility to which I’m referring is the ability for a model geared for high speed to still be driven controllably at low speed through the provision of reduction gearing. If it helps, I’ve not put any additional gearing into the drivetrain and am simply driving the differential directly from each end without anything in between. It is the differential itself that is doing the job of multiplying the motor revolutions, not a high torque/low speed or low torque/high speed gearbox. As such, your formula for calculating r0 (r0 = 0.5 * (r1 + r2)) holds true. I’m unable to embed images at the moment because I’m using my mobile phone, so I’m unable to post the motor map graph again. However, it is in the hidden contents section of the opening post and can be viewed there. Although the coding for the custom controller uses variable “a” for train speed which has a range of -200 to 200, this is later divided between the two motors as “b” and “c”. The range for r0 remains -100 to 100. If you apply the formula for r0 to any selected speed on the motor map you will see that 0.5 * (r1 + r2) = r0 = a / 2

I'm not trying to bring more torque or v-max. I'm trying to bring more control and greater flexibility. Yes I am aware. And at certain parts of the motor map this is precisely what happens. But is this not also what happens with the differential? By applying a reduction gearing through the differential I am multiplying the number of motor rotations for any given road speed. In essence, that is precisely what I am trying to achieve. Not only that, but it's hard to build fast train models because the higher gearing required for higher speed running means that the motor speed necessary to overcome inertia is also that much higher, which means that the train leaps forward suddenly at an even higher speed. The differential allows for the gearing ratio to be varied which reduces the speed at which this sudden leaping forward happens. I am aware that this is not necessary with certain motors in the PUp range and that by using the new L-motor I could have dispensed with it altogether. However, not everyone is happy to use PUp and many remain heavily invested in PF, which is something that 3rd party manufacturers are catering to with PF clone motors and their own Bluetooth controllers. This technique will not suit everyone nor will it be applicable to every situation, and I am certainly not suggesting that it is a new standard, but it does have some attributes that others may find useful. I have chosen to use PUp components and the PUp app to demonstrate it because that it what is now available, but it is not necessarily a PUp specific system and may be applied using other equipment as the builder sees fit. Yes, and that's certainly one option. However, as @Toastie mentions, I have discovered that there is a problem using this feature with the City Hub. The Technic Hub would be more reliable for this, but sadly it is too large to include in many train models.

I'm not actually trying to replicate the transmission of the Fell Loco. I may not have been adequately clear on this point. It is simply that the Fell Loco's gearbox arrangement has been the catalyst and inspiration for this project. The only aspect of the Fell Loco that I have taken and applied is the use of a differential as a reduction gearbox. The idea behind this project was simply to find a way to make the Technic motors that many of us use to power our builds more usable. The experience that I have had of using Technic motors so far is that they have a very limited speed range which means that, as a builder, you have to decide on how fast you want the model to run and then design and build the geartrain accordingly. They also need quite a bit of power to make the model move and, because the motor speed is proportional to the power being applied, the model tends to move off at a higher than desirable speed. But what if there was a way to improve the range of speeds that could be achieved and make them controllable at low speeds? Using a higher final gear ratio gives you the higher speed while the differential acts as a variable reduction gearbox to make low speeds possible while giving much greater control over the speed of the model right the way through it's speed range, all while the motors are drawing sufficient power that they do not stall. I would encourage you to watch the video of the GT3 chassis test (posted below again for convenience) and see the range of speeds that this model is capable of. I do not believe that this degree of performance would be possible any other way except by using a differential.

Happy to help. Have a great day too.

I would suggest that you contact him directly and see what he can arrange rather than asking for others to provide copies of instructions that, if my understanding of Patreon is correct, they will have paid for. I’m unsure what his level of involvement is with this forum, but you can probably reach him through his Flickr page.

Essentially yes. That’s the basic principle of the Fell gearbox which works as a way of replicating the different ratios in a traditional gearbox. My idea takes the principle of using a differential as a means of providing reduction gearing and runs in a slightly different direction. By driving each motor independently through a custom controller on the PUp app I can vary the gear ratio to provide a wider range of speed than would be the case with a traditional fixed gearing. The rotation speed of the differential is what sets the speed of the train, but by varying the speed and direction of rotation of each motor relative to each other I can control the speed of the differential.

Thank you. Credit for the H10-44 has to go to the original designer, as there's still rather a lot of his design still in my model. I have made some changes to facilitate the different drivetrain and a few other cosmetic tweaks, but the cab, bogies, platforms and the overall size and shape are still faithful to the original design. GT3 looks like it's approaching train motor speeds but luckily it stuck to the R40s even flat out. I'm feeling very pleased with the results so far, even if the performance from the M-motors has been a little disappointing. It lasted a remarkably long time in frontline service in spite of being wildly non-standard, although I've no doubt that it did so largely thanks to good manufacturer support due to it's highly complex nature. There were reports that an improved version was on the drawing board, but it was not pursued. More about the Fell Locomotive can be found in the usual places. Thank you, Thorsten. I wanted to try and keep it all LEGO as much as I could and the combination of hardware and software is what made the results possible. LEGO isn't a brilliant medium for railway modelling due to the limited capabilities of the motors that we're given to play with, and I think that train builders push them further than almost any other segment of the LEGO modelling community, so it's nice to be able to showcase just what they can be capable of with a bit of thought. I've not tried pulling any load behind either loco yet, so I just hope that the smooth motion can continue even with a tail load. [I'll take a mosey over there shortly and have a look and see the progress. I did e-mail LEGO customer service as you suggested but have only had the usual "thanks for your enquiry" response so far. I'll update the community of any news I receive.] You're really most welcome. I wanted to share all the information to make it easier for others to replicate what I have done if they wish to. Thank you, Thomas. I did think that I would not be the first to have this idea. I have seen comments about using a differential, but only as a means of equalising the power from two motors driving the same geartrain and not with independent motor control in the way that I have done. Likewise I am not familiar with these other sets and don't know how they used the motors and differential. Is it similar to this design with independent motor control? Isn't the flashing orange light a low battery warning? For sure!! If I'm getting the low battery warning already after just a small amount of testing so far then it's clearly draining them fast. I should just mention that I used the same hub and batteries for all tests with both locos so far, which includes static and dynamic testing. At the moment I'm using normal Duracell AAA disposable batteries but I am planning on modifying the hubs to accept a Znter rechargeable PP3 9V battery instead which should provide the full 9V until discharged. It may not improve battery life but it might help ensure consistent performance. **EDIT** I need to draw your attention to the fact that I've had to change a couple of the images of the code used for the PUp custom controller due to posting incorrect details. Unfortunately the images did not match the descriptions given, but I have now changed the images in the original post to make sure that they are correct. Anyone looking to replicate the code will need to check again to make sure they have the right information.

Thanks very much. The final gear ratio for GT3 is actually 1:2 thanks to that little 12T bevel gear at the bottom. The problem is that I chose to modify an existing model rather than design and build one from scratch, so it's a bit of a compromise. It needed an additional gear to reach down into the chassis and the spacing meant that only the 12T would work. But I'm not disappointed because it has XL drivers so is already geared up a fair bit, so 1:2 works quite well. Not at the moment, no. I only run trains occasionally for my own pleasure so wear isn't a major concern for me. I would expect that those folk who run their models for extended periods (e.g. at exhibitions) are used to the need to carry out loco maintenance including the servicing and renewal of the geartrains, and this will be no exception. In principle I do agree that you want to keep your geartrains as short and as simple as possible, but for a system like this there really isn't any alternative. Even with some of the aftermarket controllers that have different power modes you still have the limitations of the motors themselves and a fixed gear ratio. I have found that you want to try and keep things as robust as you can to prevent slipping, and the L-motor certainly has enough torque to separate bricks. I'm looking forward to seeing it finished.

I’m very cautious of using the word “new” to describe anything I do because I know that in LEGO, as in life, there is very rarely anything completely new under the sun. With that in mind I will just preface this thread by saying that this is not something that I have seen done elsewhere, so I’m going to bring it to the attention of the community. But first, a little diversion by way of explaining where my inspiration came from. I had been doing some reading about British Railways No 10100 which is better known as the Fell Locomotive. This was a prototype 2-D-2 locomotive that was perhaps the oddest (and oddest looking) loco to have graced the UK rail network and was an attempt to build a 2000hp mainline diesel engine using a mechanical transmission. Most mainline diesel locomotives use either electrical or hydraulic transmissions which are better suited to coping with the high power demands of mainline use, with mechanical transmissions usually used on railcars and small shunting locos. However, the Fell Locomotive took a different approach using four 500hp V12 engines mated to a transmission which utilised differential gears. Not being very mechanically minded I had no idea what this meant or how it worked, but then I happened across this old newsreel hosted on another forum which explained things in layman’s terms and the scales fell from my eyes. The transmission was brilliantly conceived and it is clear how it would suit the needs of mainline operation. But then I had a Eureka moment and realised that this might work well in a LEGO loco too. Well, not the whole four engines and three differentials thing, but with two motors and a single differential it might be possible to increase the controllable range of speeds achievable. The original idea was to have a sort of two-speed loco that could run at half it’s normal speed with a single motor and then access the rest of it’s performance with the second motor, but then I realised that by altering the speed and direction of rotation of the motors relative to each other it would be possible to almost infinitely adjust the loco’s gearing. Suddenly I was looking at the possibility of running models that could do low speed as well as high speed without having to make compromises with the gearing. So for the past few months I have been working on a couple of prototypes. The first is a rebuild of my own English Electric GT3 4-6-0 and the second is a modified version of @Commander Wolf’s bijou little Fairbanks Morse H10-44 switcher. Each loco would have a different motor and gearing arrangement to test how they work with different types of loco design. This is the new power arrangement for GT3. There are two L-motors in a stacked arrangement with gearing to take the power to each end of the differential. The gearing gives a final ratio of 1:2 which, when added to the model’s XL drivers, should give a decent increase in speed. The H10-44 has a slightly longer geartrain due to the need to power both bogies. This loco use a pair of M-motors placed at either end of the differential. The model was built with the option to alter the final ratio by sliding the relevant sized gears along the driveshaft to engage with the differential, with either 1:1 gearing for some proper slow speed switching capability or 1:3 for higher speed running. The gearing arrangement that allows for these two different final ratios is quite simple and can be achieved without any major rebuilding, as the shaft arrangements are identical. As well as the physical arrangements of motors and gears that were necessary, to get the best out of the system I decided that I would also need some form of control. I suppose that, if you were dexterous enough and deft at using one, it could be done manually using a remote, but I didn’t think that I could manage that. I opted to use Powered Up as this has been the de facto hardware for a while now, but you could use any system you like. As it doesn’t appear to be possible to share Powered Up profiles I have given a full description of how I built the custom control profile, but I have hidden it as a spoiler so that those who have no interest can easily skip on ahead. With models and a control profile built it was time to go testing. Here are a couple of videos of the two prototypes strutting their stuff. Each one accelerates slowly up to maximum speed before slowing to a stop. (Apologies for the quality of the video. Unlike the SBrick app, the Powered Up app doesn't have a "set and forget" feature, which means that I've had to resurrect an ancient digital camera to record these videos.) The H10-44 is running a 1:1 final ratio as I discovered that even with two M-motors there just wasn’t enough torque to turn the higher 1:3 gearing. Even when it could be persuaded to move the performance was erratic as often one motor would stall even at high power input levels. It’s much happier running with the 1:1 gearing, which is appropriate for a switcher. GT3 benefits from having more power thanks to the L-motors and a degree of intelligence due to the in-built rotation sensors on the motors. This means that the motors can adjust the amount of power they need depending on how their speed compares to the input values from the control profile. As such it shows a good range of speed and is able to maintain that speed even when taking tight bends. The Powered Up app still isn’t especially stable when controlling the L-motors and will sometimes drop the connection to the hub, but it doesn’t happen every time so I can live with it. So what are the negatives? Well, you need to have two motors and enough space inside your model to take advantage of this, but dual motor set-ups are fairly common in train builds these days. Also, the longer and more convoluted drivetrain is bound to generate more internal friction and battery life may be reduced due to the greater demands. I still have more things that I would like to try. In particular, I’d like to uprate the H10-44 with some L-motors and see if it can manage the 1:3 final ratio. I’m sure that there are some tweaks to be made with the control profile too to give better control and flexibility. But as I’ve been talking non-stop for such a long time I think it’s time for me to shut up and hand over to you for questions, comments and feedback good and bad.

It's a shame, but I think you may be right. Until this bug has been sorted out I have written some replacement code in the form of a fairly crude feedback loop to replicate the function of the faulty block. Static testing with the model works well but the real test will be under load to see if it can cope with the mechanical drag of the model and alter the motor settings as necessary. A big thank you to @Toastie, @Andman, @kbalage and everyone else who has contributed to this discussion for your hard work in pursuit of the source of the problem. You guys prove the value of the community.

It's an iPhone 8 Plus. I did wonder whether these problems might be related to the device but it sounds like it's not if you're having the same issues as me.

Thanks Thorsten. It seems that we're all learning plenty today. Ah. Hmm...

Yikes!! Sorry about that, chaps. I have to say that I've not been following the detail of your discussions, but the one take-away I did get was that the Set Motor Speed block doesn't like being looped because of the demands on the software. Based on this I did a bit of thinking today at work about how to make the loop only run when there is a control input, so I did this... ...but it's only a partial success. The motors are now able to respond to more than a single input, but ultimately I still loose control over them from the controller and the bluetooth connection to the hub still drops out.

If I use Set Motor Speed for the tacho motor I get the behaviour outlined above. However, the controller works fine if I substitute it with Set Motor Power. The program shown above is the non-functioning version but is identical to the working version except for this one block. Thanks for checking, though. Your help is appreciated.

Sorry if I've exceeded the image size limits.

The complete program. The front end. The back end.

Yes of course, and I do understand. As I mentioned, screenshots are coming just as soon as I get an opportunity, hopefully by tomorrow. It’s just that I don’t have a lot of spare time at the moment to devote to hobbies at present.

Apologies. I didn't want to waste a lot of people's time doing all that if the answer was as simple as "this is a known issue with the app" or "it won't work with that combination of hardware". I'll have to get some screenshots done when I get a moment. Apologies to you too, as I think my opening post isn't as clear as it should have been. As you probably have guessed, it's a train controller that I'm working on which uses three variables; train speed (set directly using buttons) and motor speed/power inferred from the train speed. I've put three dials on the controller to monitor these variables. When I start the controller it remains stable and the bluetooth connection is maintained. When I start the motors after pressing to increase or decrease the train speed the motors will begin at their first speed position, but after that they will not respond to the app. However, the controller continues to work on my phone because the indicated values for train and motor speeds continue to rise and fall as intended in response to the buttons. Throughout this, the app itself does not crash and the controller does not freeze or stop working, but after a few seconds the motors will stop and the bluetooth connection to the hub is lost. Subject to checking, I don't think that there's any issue with the code. If I substitute the Set Motor Speed block for the Set Motor Power block and leave the rest of the code exactly the same the controller works perfectly; it's just when I use the Set Motor Speed block. There are no loop expressions except for those that control the dials and the motor inputs, as per the examples on @kbalage's YouTube tutorials.

Apologies if this is in the wrong section, but I'm having a spot of bother with a custom controller I've been working on in the PUp app and wondered if anyone could provide some insight. I'm attempting to control two Technic L motors using what I believe is referred to as the City Hub (PN:88009). The custom controller does not control them directly but rather calculates the necessary power level based on a single input. I wanted to use the Set Motor Speed block as this would ensure the accuracy of the function, but this doesn't seem to be working as I expected it should. The motors respond correctly to the first button press but then the program appears to freeze and the motors will not respond to any other input. After a few seconds of this the hub disconnects and the motors stop. I did wonder if there was an issue with the hub reading the inputs from the rotation sensors, but that doesn't seem to be the case because I can get the controller to display motor speed satisfactorily. For the time being I'm using the Set Motor Power block instead which works fine, but it's not the solution I really want. Is this a bug in the app, a limitation of the hardware/software or some other issue? I'm running the app on an iPhone 8 Plus and wondered if it could be the cause of the issue. Please bear in mind that I am neither an electronics nor computer expert, so please don't baffle me with science. I'm just hoping that there is a simple answer that will avoid the need for a long and complicated workaround in the custom controller.

Another steam pioneer!! That's a very nice rendition of an historic train. Congratulations.

Thank you for that very comprehensive rundown, Thorsten. My own computer/electronics knowledge extends just far enough to know how to turn on the laptop and type "How do I...?" into a search engine, therefore I'm afraid that your solutions are very much beyond my abilities at this time. However, they do sound very impressive. It sounds as though you've found a good way to combine two hobbies that you love into one absorbing passtime. I have found @kbalage's excellent website and YouTube channel and am very grateful to him for all the hard work he has done in decoding the PUp app and programming environment and explaining it in very accessible ways. Using his knowledge base as a starting point I have found the programming to actually be quite easy. I'm no coder and have only some experience of coding for Mindstorms, but I found that coding for PUp was a lot more intuitive than was the case with Mindstorms (although to be fair the tasks that I was writing code for are not comparable which may have made the task easier). I think that there may still be some bugs in the system as I did get some inexplicable behaviour, but I have found mostly that, if I can conceive of the code I need, I can write it quickly and easily and have it working correctly first time.

That seems like a pretty good summary of our hobby. Oh yes, definitely!! I was up in the North-East last spring just at the start of the pandemic, but I didn't have a whole day free to devote to Beamish, so I went to Locomotion at Shildon instead on the trail of the last surviving Shenfield EMU. However, it is very much on my list of places to revisit, and it would be my third visit in total when I do get there. My first was as a young teenager in the late 1980s on a family holiday. Back then there wasn't much to see; just the tram line winding it's way down the hill to a fairly short Victorian High Street. It was impressive to see how the site had grown and it will be good to see how much more has been added since. Maybe next time I'll go on my own or with a group of like-minded friends, though. That feeling still persists, even as the modern world gets ever busier. Even though the site sits amongst County Durham's colliery villages on the slopes of the North Pennines there really is a wonderful feeling of isolation, as if the modern world no longer exists. It's a fabulous trick to be able to pull, and the many volunteers and actors really do give it an authentic life (well, all except the young lad inside the motor garage who had his hand inside a drawer so that he could use his mobile phone which is presumably otherwise strictly verboten ). Tram (Trolley). Seconded. In fact if industrial heritage is your bag the whole area is a gold mine of opportunities with museums and preserved industrial sites concentrated within a fairly small area.

Do you mind me asking how you control your Croc? Is it using the PU remote? If so, how do you access the L Motor's speed command rather than power command? I don't wish to say too much at the moment, but I have something on my workbench at the moment that could help builders using all versions of the Technic motors to run their models in a more controlled fashion without the need to modify anything or resort to third party offerings. It won't help users of the train motor, though. Unfortunately those guys are on their own. Watch this space, as they say.

I wasn't aware that the Beamish Museum had such an international profile. It's a fabulous day out and highly recommended. I was last there in 2008 but the Elephant was in the shed while they ran the replica of Puffing Billy. Sadly I didn't get the chance to ride behind it because I was with my ex and she wasn't very interested in the trains, so I couldn't really indulge my interest. I love your recreation of this steam pioneer and the way that the motion moves. You've done a fabulous job with it. Pioneers such as this look so otherworldly now, but back then it would have been startlingly futuristic.

No, I wouldn't have thought so. The problem is the stall speed of the motors themselves. Without any load they will turn at power outputs as low as 20% but loaded you seem to need at least 40% to get the train moving. For train motors with their relatively high gearing this means that the train will suddenly leap forward as if scalded. Smooth getaways just don't seem to be possible. I did have some success with slow getaways and stops with the Mindstorms controlled D800 Warship loco by using the servo motor with it's speed and angle sensor, so I would imagine that the same could be replicated using Powered Up large Technic motors, as you suggest. It would take a bit of coding in the app, but it wouldn't be too hard to achieve. Video of RoboTrain 1.0 under test.