Toastie

Well, I have crossed the border, I guess: Yesterday I dumped 184 1x2 LBG tiles into the bin with LEGO tiles - could simply not tell the difference - and then it is "the same" for me. I am leaning towards BlueBrixx located in Germany, shipping is ultra-fast and cheap. They sell sets and bricks/plates/etc. from different sources. My limited experience so far: The Flying Dutchman from Mould King (does beat every single pirate ship from TLG, as far as I am concerned, in many ways), 100 2x2 (5€) and 200 1x2 LGB tiles (6€), see above, and 4 train coaches as "BB special". With regard to the latter: Everything was perfect, but the wheel sets. I knew that beforehand, so no surprise here. The problem is solely the length of the metal rods. And easily resolved. Will post in the BB thread in the Community forum. The thing is: I am really willing to accept less quality - for a fraction of the cost of TLGs products. Plus, BB has more elements in mayny diverse colors in store than PAB has: 1x2 flat tile, LBG. TLG: 0.07 cents/piece = 14€ for 200. BB: 6€. Quality: Same 2x2 flat tile, LBG. TLG: not available. Train coaches: TLG: Not available. BB: Dark green, about 500 pieces, about 40 cm(!) long each. 24€ (as in twenty-four). Quality: Bricks/plates equal or slightly less. Wheel sets: Need to change metal rods. But: For less than 100€, my BR23 is now pulling 4 coaches with a total length of 1.6 m + engine. As said, will post brief update on that later. I believe it is worthwhile testing the waters from time to time - it was very bad in the beginning. I also believe that the brick quality has become "the same" for a number of sources, such as Mould King and Cada. And again: At >max.< half the price for comparable LEGO sets; usually it is even down to 1/4. With regard to set design: That really depends - on an individual per set basis. The coaches mentioned above: 6-wide = my scale = perfect. TLG has nothing that comes even close. What should I say? I am really very happy. Best Thorsten

Absolutely - for one entire country. I believe this has to do with international trade rules, but I can be mistaken. After all, the EU is still that: A union of individual countries. With some common legislation and trade rules, but certainly not with what they call EU wide "catalog prices". The US is big - but one country. I have no clue how international trade rules are operating, but I believe the "catalog price" is the same for each country. At least it is the case in Germany. When I travel to Denmark(!) I hardly buy any LEGOs, as the Danish catalog prices are significantly higher. And then every company selling LEGOs ( many don't like the term LEGOs, but I do ) can come-up with discounts at their discretion. So I believe - and again it may be completely wrong. Amen to that. Best, Thorsten

Oh, absolutely. As you surely know, the EU is categorizing cucumbers with regard to size and curvature (and many other things). But definitely not with regard to pricing. That is simply up to the seller/country. We are living in Capitalism World. Ah, that always sounds so negative: We are living in the Free World. The very moment you declare you are going to make all prices the same across the EU, the world - according to the many text books of capitalism - comes to a grinding halt. Spinning wise. Public transportation is a good example. Should be, could be, is not: It is basically a per city thing to define the price for going from A to B - with the exact same mileage - and we are not talking Switzerland here, where they to have to drill holes into mountains. Oh well. It's called free and fair ... and competition and so on and so forth. LEGO is a toy, but situated in a fish tank full of many (different types of) fishes. Best Thorsten

From the viewpoint of cost of production, quality assurance etc. pp. it does not make any sense. As a globally operating, fine-tuned and in any way (money wise) optimized fully profit oriented enterprise, it absolutely does. Each entry per country, world-wide: Uncountable market analyses (sets sold when, where, how many and so on and so forth), income structure, perception of product "toy", perception of product "LEGO", competitor analyses, SWOT analyses all over the place ... and who knows what else they analyze (as a globally operating enterprise you need to do that, no doubts here) - plus many, many years of testing in what way a price incline affects profit - well - all that results in a "per country stress test" - and with years of experience a in "guess-this-will-work" price tag. As they did in the past, as they are doing today. And today they have the virus on their side. Best, Thorsten

Absolutely. This is the major issue with long and heavy trains - and when wanting to run such a train at low speed while negotiating curves and switch points. They get easily "stuck" due to significantly increased friction as compared to running on straights - and you need to overcome the static friction again and again. This was the main reason for me to program that PID algorithm into the RCX. Back in those days there were no tacho-, PF-L/XL motrors or anything close to that. And I wanted my trains to move slowly - it makes them look even more powerful. Best Thorsten

As said a minute ago - sorry for cross posting - this is a) up-to you or b) in the PUp case they seem to having 1:1 scaled the %speed with the %power rpm, using an internal calibration factor for tacho to rpm conversion. Well, it does make sense to define the speed scale in that manner: It is in many cases no big difference, when you are setting 50% speed or 50% power on a geared motor, as all the PUp tacho motors are. The 100% speed setting simply means no speed control, as that corresponds already to full DC voltage at the output (so I believe). However, everywhere in between and most efficiently when you still have power reserves available. I would build my model (regardless of what type) in a way that is runs at ("your desired") full speed at PUp (or any other PID algorithm) motor speed settings of 70 ... (max.) 80% using appropriate gearing. This way you still have some reserve to control the speed at "your full speed". Does that make sense? Best Thorsten

OK, I am a chemist, so others surely(!) know much better, I am just telling, what I have learned - or at least believe to have learned - over the past decades - I am old Now, the LEGO approach to control the (average) power delivered to any of their motors (for a long time already I believe, for sure with RCX, NXT, EV3, RC train, PF, PUp) is pulse width modulation, pwm, of their outputs. Yes I know, we all know that. In any case: "0% power" = 0% on-time (= 0% duty cycle) of the full DC voltage available = off; 100% power = 100% on-time = full DC voltage available at the output. [Note: The latter is not always entirely true, as my oscilloscope told me; there may be a remaining >very short< off-time barely noticeable - not important]. The term "power" is of course wrong, as the power depends on the current drawn by a device connected to the output. In an ideal, non-inductive world, that current is limited by the internal resistance of the device. Let us assume that the current drawn at any "% power setting" is >not< limited by the electronics nor the battery feeding the electronics (again, in the ideal world ...). In this case, 50% power = 50% average on-time at the output; power is then average on-time x (max.) current flowing. The modulation frequency is well in the audible range - see Philos pages and elsewhere. The voltage supplied to the output is pulses of full DC voltage available. The scale of 0% to 100% duty cycle is different for different devices: for RCX and others: 0 = 0% and 7 = 100% duty cycle. For PUp 0 = 0% and 100 = 100% duty cycle. But that is easily taken care of using a scaling factor for more versatile calculations (as I cannot calculate in the octal system ). Next thing I believe to have noticed: The PUp tacho motors are operated by the hub in a way that when you set "power" = duty cycle to let's say 50%, a certain no-load (i.e. the motor is driving its axle without anything attached to it) rotation speed results (rounds per minute, rpm). This rotation speed appears to be the reference for the "speed" setting in the PUp hubs: When you set "speed" (not power) to 50%, the freely running motor seems to having the same rpm as when you set 50% power. Upon increasing the load at the axle, rpm go down, the controlling device realizes that (feedback) and increases the pwm duty cycle to let's say 60% (= higher average power) to maintain the 50% speed you wanted. And so on. You can tell the PUp hubs the max. duty cycle they are allowed to supply - I always use 100%. Long trains require quite some torque when they are starting to move (smoothly of course, i.e. no "overshooting"). And all that is of course heavily depending on the motor design. Highly down-geared motors, as the PUp L/XL motors need much less power control (as they can produce - at constant voltage or better: duty cycle (!) - quite some torque without any intervention at different loads). However, almost ungeared small DC motors, as e.g. the train motors (PUp, PF/9V) are a nightmare for constant speed train operation: On the 0-7 duty cycle scale (0 = off, 7 = 100%) at level 2 they barely produce any torque, at 3 they awake, at 4 the train jumps forward and then moves with semi "constant" speed and at 5 it derails easily . Well, I guess this is the fun part, but not for me ... Solution 1: Add more train motors. Solution 2: Use one or more L/XL motors. Solution 3: Add PID speed control, when you can reliably read in the rpm on any axle; either with a rotation sensor (RCX) or internal tacho in PUp L/XL motors. OK, I believe setting "speed" in PUp hubs invokes some kind of PI/PID control. On my RCX powered trains, I can monitor the %duty cycle setting on the output, when the PID algorithm tries to keep the train moving at constant speed: It goes all over the place from almost 100% when climbing up, to 10% when going down and then wildly up/down when negotiating curves/switch points, as the load caused by wildly changing friction forces goes also wildly up and down. Well, as said above, either use the rpm of a freely running tacho motor at a given %duty cycle (= "power") setting on the 0-100% scale as reference. You simply read-out the tacho values at 0, 50 and 100% power and then shoot a function through the three (or more of course) calibration points - or use Philo's data. In any case you need the actual tacho values for the control algorithm. I do not know whether the tacho value is the same as rpm. Or you create your own speed scale, provided you want to program your own algorithm or want to use one of the many available out there. I did the latter for my RCX trains, as they don't have tacho motors, but only train motors, and I am calculating the speed using rotation sensor data. The sensor sits on one of the train axles (somewhere, does not matter where when using the same wheel size on the entire train. 1 rpm = 16 ticks on that sensor and the latter is what the RCX gets as input data. This is rather coarse - and no way as good as the tacho readings on the PUp motors, but it works, when you adjust the PID parameters carefully. Hope that helps - but maybe not at all. All the best, Thorsten

Current is constrained by the PUp hardware - if it can't deliver, it simply maxes out. To the point that it shuts down for some time (fractions of seconds, up-to seconds) Best Thorsten

Yes we are - I guess. PID - as you know - reads a signal, which is linearly monitoring the control signal, e.g. rotations/sec of an axle for the variable "speed". The algorithm tries to minimize deviations from the user defined "set point" = desired "speed". It does that by adjusting "power" within the hardware limits. PID is just an algorithm. You can do with PI, even with P. I just believe that when the average parameters are known, PID is the most efficient way to achieve "hold" (speed). And it is software. Of course, to work correctly, you have to define the P/I/D parameters very carefully, depending on the whole "system" (response rate, moment of inertia, available power, and so on). But I found that with some average parameters you get quite far. In summary: I don't know what the feedback algorithm in the LEGO hubs is, but is seems to work quite nicely (at least for my trains, operated with PUp L motors using the SetSpeed command of the LWP3.0 protocol. Best, Thorsten

You described it absolutely to the point. Best Thorsten

Nope, you did not miss anything!!! . As @Zerobricks said: Best, Thorsten

With PID control, you can at least challenge that function. Best Thorsten OK, lame - but here I programmed RCX bricks (10+ years ago) to do exactly that: https://www.eurobricks.com/forum/index.php?/forums/topic/45440-lego-train-control-using-rcx10-pbricks/

Then I understood all that, I believe. Oh yes. I don't know about all the wonderful Technic models; you guys want to challenge and wantc to cope with these challenges. When it comes to trains though, you want speed setting. And also acceleration and deceleration profiles. I have no clue, why TLG put that feature into every hub's firmware - but it is there. TLG's train theme is basically dead - but when you equip your train with tacho PUp motors, it makes all the difference. Not at high speed - but when slowly approaching a station or climbing a slope with some 10++ carriages. Best Thorsten

I don't know about BuWizz (as I have none, but I believe so) - but all the LEGO hubs do exactly that, when you select "speed", but not "power" in the controlling program (I am using Legoino/ESP32, but I tried it with the PoweredUp app and it works). Best Thorsten ... when the supplied (sustained) voltage/the electronics can cope with the load, correct? Best Thorsten

As said above (maybe merged), for me, it is (and it makes >all< the difference) that PUp hubs can control the >speed< (= axle rotations/per time) by monitoring that number (speed) and then swiftly adjusting power to the motor(s) to attain that speed you want. You can set max power to be delivered, and many other things (e.g. how the motor(s) ramp up to controlled speed). Best, Thorsten

Phew - a lot of things are discussed here - but these need to be sorted out, as far as I am concerned. I build/love trains (and switch points ;)) - and electronics to make them go around or simply work - so forgive me if I sound stupid. You guys are making things that I cannot comprehend. OK. Now. PF: No motor "control" at all. You supply voltage (with electronics that can sustain that voltage under load) - and the thing does what you want. Under load: Amperage may (will) get to a point, where a) the controlling device (the PF receiver) cannot cope with the current flowing and thus the voltage goes down, or you have gearing installed that simply saves the receiver to get to that point. In the train world that is 1, 2 or even more PF XL motors. Or any other variety of motors geared down to the point that the trains just crawl. PF train motors can't be geared - so just add them up to your needs. Break on any motor - regardless of make - simply means: Shorten the wires. Induction is at work here. Float on any motor - regardless of make - simply means: Leave the wires at high resistance or better: Open. Not connected at all. And this is it for PF. No "hold". PUp: All of the above + hold: That a) demands you to use a "tacho motor" = >non< PF, but PUp L or XL or some others ... motors. They need to have the rotation feedback supplied to the driving source = PUp hub. b) You need to use the speed and NOT power settings on a PUp hub to get that going. And behold: The latter is - amazing. For trains, at least: Hold (or SetSpeed, same thing) means you set the speed you want, not the power. The power (= motor voltage, if the hub can provide that under the current load) supplied to the motor, is controlled by a pretty nifty algorithm running on the hub. I believe this is all there is. But I may be wrong. Best Thorsten

Very good idea! And it really does not matter where this thread is "located". Quick question: Is this thread intended to report your own experience with BlueBrixx or may other folks post here their experience with BB as well? And then: Although you have linked the product, I believe a parts count as well as rough price info may help some others to gauge the product on their own - or may even lower the bar to cross the border to visit the land where fire and brimstone falls from the sky ... Thanks again! Best Thorsten

No. It will never explode. It cannot. Now, all has been said: Replace the wires (no other chance), use what @allanp has suggested, browse this forum (using Google) for further suggestions on the wire gauge (EB's search function sucks, to be friendly;)) With regard to the motor behavior (which is not related to any wiring, right?) - opening it up is then (IMHO) mandatory. I sure hope you get this going! All the best Thorsten

Let's see the air compressor. That one is the juice. Very nice flooring, I love it. And of course the Singer Best Thorsten

Is this really how this mechanism works? Cool. I just looked under the hood of our magnificent super car Opel (Vauxhall) Zafira Tourer Diesel (4 years old) - but could not figure it out. It is all covered up and slick and clean. I wish, I still had my Renault 5 from 1974 - no diesel and as mileage as good as the Diesel Hmm. Walschaerts ... again: I am not smart enough to "see" that in @ord's approach. In any case - as they say: A couple of months in the lab can easily save you a couple of hours in the library I really like @ord's solution - for whatever it will be good for. As in: I love basic research (this is what I do for a living). All the best, and thanks for sharing! Thorsten

No, I am not on Facebook - I am more or less just here on EB when it comes to LEGO. And I am very thankful that people like you and all the others are here as well and share their honest thoughts . Thank you very much again! 15€ for postage for that thing is really stiff. Oh well, I sure hope that you have fun with the alternative product! And that you get over this real quick. All the best, Thorsten

A couple of issues come to mind: BB not replying: Totally stupid. No way to turn around that one; every customer service knows that when the going gets tough, just be like a strawberry: Sweet, red and innocent. (Just curious, though: Your inquiry was of what kind? "Hey, this piece of crap is defective, I want a refund", or was it more in the direction: "Your product does not work as expected") ? Blocking from Facebook group: Hmm. Bad, stupid ... nothing more to say ... I don't believe that "defective" is the correct term, though. Nothing appears to be "defective" here; it does not work as expected, i.e., as from the "superior" TLG version, right? OK, that one was equally flawed, as it does not allow having both tracks going straight, which is also equally crazy, isn't it? The price of that thing is a whopping 30€(!). They actually charge 15€ for shipping??? I paid next to nothing for four rather large carriages ... but I am living in Germany. May that be the reason for the very high shipping costs? I am really curious(!), as I have a different experience with BB. And I am wondering why that is. Best, Thorsten

Well, here is one from @M2m - a superb rendition, when you ask me: Best, Thorsten

No I can't: Because there is absolutely no reason to forgive, as there is absolutely no reason for what! This: "thanks but this is more of a trying to fix something then a i need a pf receiver now. am a thinkerer" in your Technic Forum thread on your PF receiver fixing work made me think you were older as dirt - as I am :D So nice to know young folks going the long way All the best and good luck on your project! Thorsten

WHAT??? You forgot Sinclair??? These beautiful machines? OK, the keyboard sucked, but when I upgraded from the ZX81 to the ZX Spectrum I thought I was in heaven. Both number crunchers are sitting here on my desk, I got both to work again - and the Speccy is now controlling my 4 PUp, 7 PF and 2 RCX trains. Next thing is to make it also throw switches, but that has to wait a little, as it means a complete program overhaul. BASIC - now that is my world. You may enjoy this little write-up (ZX81/Spectrum this and that and repair): https://uni-wuppertal.sciebo.de/s/IvuL0kCjbl3nLDZ Best, Thorsten