Black Knight

I'd guess that simply some staff of JB is on holiday or something: I ordered another pack of only S32 tracks and they haven't sent it for 6 days now -- while claiming a delivery time of 2-3 working days. Oh my.

@Andalo_an Awesome. Thanks for the heads-up!

So, someone tried to ballast the R72 or R88 curves yet? I am curious how compatible to other track @michaelgale 's are in regard to ballast; do the TrixBrix ballast plates fit? At least the R72 seems to use quite a different approach than TrixBrix or BlueBrixx. Meanwhile -- as a european -- I stoically wait for the sea container to arrive at JB.

@Enrico7676 Do you know whom the dark-red BR 05 in the video belongs to?

Greatly appreciated, thanks!

Bluetooth and WiFi both use the 2.4 GHz band, so they do use the same resource and will interfere. The question is, how severe is it? This depends on the existing traffic in your space: As being said, on public layouts with lots of visitors, everyone bringing his smartphone and Bluetooth headsets and using some public wifi: your packet loss can be spectacular. The good news is, that for commanding the trains, you need very little bandwidth, so you should not see any problems until the 2.4 GHz band is pretty used up already. If it's your kids streaming videos that cause the problems, you can configure your WiFi to use the 5 GHz band (if it's at least 802.11ac from 2013).

Dude! This is sooooo mindbogglingly uber-awesome! There really isn't anything else to say.

That's like comparing apples to oranges. One is a premium-brand, out-of-production, 90+ EUR lithium power-source-only box; the other a NiMH-battery+RC-receiver-box that costs 15 EUR. The BB stuff is just fine if you are e.g. playing with your kids (bonus: No lithium!). If you are dead-serious railroader and don't mind the money, you are going 9V tracks + DCC anyway. Before getting the old PF rechargeable battery, I'd recommend a Buwizz for that kind of money.

If you are open to 3rd parties, the future of PF might not look as dark as painted. There are currently at least 5 other manufacturers producing motors with PF-style connectors: I expect we sooner see the EOL of PU than we run out of 3rd party PF components. TLG's patent on the PF connector ran out several years ago, so you now see motors and also battery+control systems from companies like BlueBrixx (German), Mould King, CADA and Kazi (Chinese). They more or less copy the TLG motors but all have a imho better battery box and controller (than TLG's PF). BlueBrixx has a NiMH-based rechargeable battery box (a little smaller than TLG) with a train-focused remote based on 2.4 GHz RC. Mould King and CADA use rechargeable Lithium battery boxes (also one brick smaller than TLG's box) with RC-based remotes, but at least MK can also connect via Bluetooth to your smartphone. All of those options are legal, no patents or other rights are infringed by these solutions. So if you are invested in PF already, prefer rechargeable systems, need a smaller battery box or are a penny pincher, those might be an option for you. Just like PF and PU, none of those are 100% perfect either, they all have quirks of their own.

I'm not sure how to make this sound less destructive, but I still think the benefit of this setup -- other than using a cool differential -- is... pretty nonexistent: The PU motors can afaik be controlled in 125 steps (only considering one direction). Your setup now doubles this resolution to 250 by providing the in between .5 steps, too. But in terms of power or speed, you gain nothing.

I am honestly confused: So what is greater flexibility if your solution is neither faster nor stronger? Well, in a synchronous solution, the resulting rotation speed (ro) in relation to the two input rotation speeds (r1 and r2) is symmetric: ro = r1 = r2 with a differential [assumption: no gearing] it is r0 = 0.5 * (r1 + r2) In both cases v-max is r0 = r1 = r2 if both inputs are identical. Now lets put some gear boxes between the motors and the differential to make the inputs different. We use a gear box for startup (r1 with low speed, high torque) and one for high speed (r2 with high speed, low torque). For simplicity we assume that r1 is just very slow and we have to rely solely on r2 for high speed. r0 = 0.5 * (EPSILON + r2) = 0.5 * r2 That means that r2 must have at least a gearing of 2:1 if we want the differential solution to have the same v-max as the initial solution. This in turn means, we only have 1/4 of the torque at v-max for the differential solution (one motor with a 2:1 gearing). So the trade-off for the elegant start would be a tremendous loss of torque at v-max. If we were to increase v-max even further, the loss would also increase. I honestly have no clue if that is enough (wild guess: "no"), but I'd be happy to be proven otherwise!

With two batteries in series, you get twice the voltage of a single battery .

I haven't encountered this bug yet; I have an L-motor on a city hub running just fine in speed-regulated mode. Maybe the bug is just in TLGs App as this works like a charm in pybricks. The problem you will always have with the App is, that at least some stuff is running on your phone/tablet. Maybe the city hub simply does not have enough CPU power for both the speed-regulated mode AND the bluetooth connection at a low enough sampling rate?

But your gears do neither bring more torque nor more v-max. If you start with only one motor running, you gain an additional 1:2 transmission, thus giving you twice the torque at half the speed. Instead you could also just run both motors synchronously at 50% giving you twice the torque at half speed. I think the source of the problem you try to fix is the mode in which PF motors, (all) train motors and (all) M-motors are controlled: The controller will simply ramp up the power, but will care nothing about what the motor actually does. This leads to you giving more and more power until the static friction is overcome which will then result in the train suddenly jumping forward at rather high speed. With a higher gear ratio this jump will get smaller and smaller but will always be there. The best solution -- imho -- are the PU L- and XL-motor: They have a rotation sensor and let you control the motor not by power-provided but by actual rotation of the axle. This behavior is really mindbogglingly awesome to watch and a complete game changer! The bad news is, that neither the PU M- nor the PU train-motor feature said sensor and of course you must use some PU hub.

But the differential solution has the same v-max as two synchronous motors. And the same max torque as two synchronous motors. As far as I understand the original design, their problem was, that their Diesel engines only had high torque at high speed: With the differential they would only fire up one engine which then had a high gear ratio from the differential (1:4 in the original) and therefore could run four times as fast, providing higher torque than four engines at low speed. At higher speeds they would then add more and more engines which then would join in at high speed (and high torque) as the train was already in motion. With electric motors, you more or less have 100% torque instantaneously -- thus avoiding the original problem altogether.

Regarding the differential: I fear this is cool, but most often pretty pointless. The main advantage in using two motors in this way is to counteract motors that have different speeds. This might be because you cannot synchronize them or if they have variances due to low manufacturing standards or aging (or simply being completely different motors). I would guess that for two TLG motors (of the same kind), the loss from friction in your construction is probably higher than any friction due to manufacturing variance in the two motors. Some third parties have larger variance in motor speed, so for those, using a differential makes sense. I recall that the (already mentioned) QJ steam locomotive only has a RC remote control that can only toggle motors on and off: Thus their differential makes it possible to run at two different speeds instead of just one. For PU-motors (L- and XL at least), you actually can run them synchronously, so the friction with differential would simply be larger than without. If you would add a "high" gear ratio two the motors before they hit the differential, it would make a difference: You then could use one motor for high torque, low speed; the other would then supply low torque and high speed. tl;dr: Cool but only useful for bad motors or simple remotes. Or if you add differing gear boxes in between the motors and the differential.

Holy cow, this is a pretty sweet train! Also kudos for showing it in action on R40 curves. And with regard to the bump: I missed the first post, so I am glad you hit it again.

@michaelgale Is it an oversight that R88 curves ($75.95) are cheaper than R72 curves ($87.95) in the FX-Shop but do cost the same at JB Spielwaren (EUR 59.99)?

There goes my housekeeping allowance: JB Spielwaren has started the pre-sale.

Looks like dynamite! =)

I had a couple hours and tried to program my croc with PU-Hub, PU-L-Motorand pybricks (MicroPython directly on the hub). As the L-motor has the rotation sensor, I was able to make the train run really smooth: I made a loop ramping up the speed (not the power!) slowly, running for a bit, then ramping down the speed again (a little faster than up). This was absolutely awesome*) to watch and the train behaved exactly the same: if with 6 carriages or without any; accelerating and decelerating just like a real train would. Now I am sad, that there still is no lithium battery for the "CityHub", there is no rotation sensor in the train motor and the CityHub only has two ports and no speaker. Well, some people are hard to please. *) maybe not from an engineer's point of view, but for a toy ;)

I use it with mono(1) directly. I had some issues with the install script, but I don't recall what exactly the problem was (not too mindboggingly obviously).

@Toastie You forgot: We put it in a red 9V train motor chassis (590) with metal wheels for picking up the power from the tracks. =)

According to pybricks, only the PU train motor and the PU M-motor do not have the rotation sensor -- all other PU motors seem to have one.

I was pretty excited to hear that. Unfortunately the train motor and the M-motor do not come with the required sensor. If you need to use one of those, you get no better behavior than from any PF-motor. Oh my... :'(