kbalage

Sw compatibility might change with every upgrade so it's a challenge to maintain such list. Not sure what feature list you are looking for, I don't think there's anything more to tell about them than what was summarized previously (and the tech specs can be found in Philo's list): There are 3 types of motors: Simple motors - only power control, no interactive functions - Simple medium linear motor (45303), train motor (88011) Tacho motors - speed / power control and relative position reporting, that means it can tell you where it is compared to the relative zero which is by default the position where it was turned on - Medium Linear Motor (88008), internal motors of the Move hub (88006) Smart motors - speed / power control and absolute position reporting, the motor has a mechanical zero position - Technic Large Motor (88013), Technic XL motor (88014), Large Angular motor (Spike Prime), Medium Angular Motor (Spike Prime / Mindstorms)

From my point of view that's the problem with the Powered Up app - every educational product (even the ones that share the protocol/platform) has some documentation, but the product that was made for the "masses" still has zero documentation and even if it had one it would be too complicated for most casual users. Hope to see it resolved in the future, but I think it was a mistake to launch the system without a proper and detailed instruction set, preferably focusing on the differences and advantages compared to Power Functions and how the basic functions of the previous system could be replicated in the new one.

I don't think it is related to any exclusion in any apps, the hardware is different (even if it's the color and the product family) so it gets a different ID. The Mindstorms rechargeable battery seems to have the exact same internals as the Spike Prime battery, still the Mindstorms one is called "Rechargeable Battery No. 6" and the Spike Prime variant is "Rechargeable Battery No. 2".

Actually the acceleration is different with the two apps, the top speed is similar.

Sure, here's one (totally random ) example:

That's actually incorrect, the gyro sensor is used in the challenges to detect if you turn with the model or not. Swapping the hub to the AAA version only improves slightly the top speed but makes a big difference with the climbing abilities, you can check it out here. But this car is not about climbing so I don't think a lot of people would notice the difference :) Since the Technic hub is a structural part of the build that's the main reason why it was used instead of the AAA hub, you don't have to disassemble anything to get access to the batteries and it simply fits better in the Technic studless system.

You have the AAA Powered Up hub for that purpose exactly :)

Train and Simple Medium Linear are power only, Medium Linear (and Move hub internal) only have relative positioning, and we don't know what is still in the pipeline. @henrysunset asked for a categorization of the PU hardware for this Brick Label collection. Since he did not use the exact default LEGO Shop names on the planned labels, the conversation started about the names and whether people would understand the differences between the hw elements based on their name. Regarding the labels, I'd still stick to my original version - use the LEGO Shop names for easier identification and if it seems to be reasonable add a category to the motors, that's all.

Sure, but if you start to give them completely new names then it only makes the whole situation even more confusing for everyone. We need to either stick to the original (shop) name or append something to it to make it easier to differentiate, and that's where the categories can help. It can be either Simple/Tacho/Smart, or Power only/Relative positioning/Absolute positioning, whatever fits the best. In any situation you'll have a hard time explaining the exact differences with only a few words so some additional information is needed anyway.

I'm sure we won't get everything in a single update but a mid-level interface with less coding and customization is definitely needed. The PU team knows that and they work on it, and will roll out the new features gradually. People don't use the app because for the majority it is too complex and there's no documentation, but these things will change with time. Time is a critical factor here - if they need another 2-3 years to make an easy to use environment complete then customers won't wait and a 3rd party app can easily steal the show.

I know what it's called in the shop, I was referring to that :) The problem with the whole PU naming is the lack of categorization. Every Power Functions component had "Power Functions" in the name. Now we have the AAA Powered Up hub being called "hub". A customer could ask: "hub" for what, which application, which motors, which what? Can I use it with Boost, Powered Up, Control+, Spike Prime? What can I connect to it? The whole ecosystem is super confusing now for an outsider, and TLG does not help either with adding the PU Technic L / XL motors to the Powered Up and the Power Functions categories as well in the shop. If it is called Technic Large Hub then we should use this name, there's no point to remove "Technic". I'm sure the Mindstorms variant will have a different color and potentially a different connected app so it will have a different official name as well. I don't think we should come up with brand new names for the motors, that'd be even more confusing for everyone. The product family shall be either "Powered Up" or "PF2", that can be added to each of them and then just use the name that is used in the LEGO shop.

Adding an option for a light in the Control+ app would be cool, but then people would want to control another motor, or a sensor, etc. Control+ is meant to provide you with a stock experience, and the Powered Up app is there will be there for customization. The main question - how much time does TLG need to catch up with Control+ and give us a flexible, customizable environment in the PU app?

The "official" naming is the most confusing in the first place. We know what a "hub" or a "move hub" is and which set it is related to, but an average LEGO customer won't have any idea. I see two options - try to relate the hub/motor to a platform where it is possible (Technic, Spike Prime, Boost), or stick to the original naming. If we choose the original one then the "Large hub" should be "Technic Large Hub", or even "Technic Large Hub for Spike Prime" as it is called on the Education webpage. About the motor categories, I'm not sure what was the problem with the simple / tacho / smart differentiation, that at least tries to stick to some official naming convention.

I think it is more like an internal terminology used by the Powered Up hardware team. The Powered Up code also refers to the interactive motors as TachoMotor, but there's no specific block yet for the Smart motors so we'll have to wait and see what will be the reference for those. Unfortunately there's no fixed terminology for the Powered Up system in general, every team at TLG has their own internal naming convention. On top of that the "official" naming on lego.com is not very helpful either, e.g. the AAA PU hub is simply the "hub", or the new L motor is the "Technic Large Motor". Sticking to Tacho and Smart as a category can set a good example so I suggest to follow that

There are 3 types of motors: Simple motors - only power control, no interactive functions - "21980 - Motor, Med. " Tacho motors - speed / power control and relative position reporting, that means it can tell you where it is compared to the relative zero which is by default the position where it was turned on - bb0893c01 / "26913 - Motor, Boost Interactive" and the internal motors of the Move hub (Boost) Smart motors - speed / power control and absolute position reporting, the motor has a mechanical zero position that can be used e.g. for return to center steering simulation - "bb0959c01 / 22169 - Motor, L. Control", "bb0960c01 / 22172 - Motor, XL. Control", "54675 - Motor, Large Angular (Spike)" and also the 54696 Spike Prime medium motor. The Spike Prime motors have markings with the zero position, the Technic L & XL motors don't have the zero marked.

TLG has a long-term strategy with parts and colors. If you have a look at the lime parts used in this set, you'll find most of them in black, white and one of the grays, then red and maybe yellow, but I'm almost sure you won't have all of the needed parts currently in production in a specific color other than the original. And this is only a single set, if they make an alternate body for this one then fans would want to see the same for other sets as well. With every color variation they need to have extra stock that requires warehouse space and logistics, it also makes the manufacturing more complicated. This means an alternate body wouldn't be a $50 option, rather a $200 one that obviously won't sell well, so I guess this is the reason why we don't get any official color swap packages.

I don't think that'd work well with the lime. Matching the body color and the interior accents is quite common, here's a lime Lamborghini example:

Amazing job as always, tons of features and some really fresh ideas in this one! Actually at the moment they only have a programming capability for Powered Up (Control+ for me stays only the Technic set-specific app, the product family is PF 2.0 or Powered Up) and barely anything else. The non-Technic sets have the set-specific profiles in the Powered Up app, the Technic sets have the same in the Control+ app, and you have the advanced visual coding environment in the "free play" area of the Powered Up app. What we don't have at the moment that'd make it actually useful: official documentation customizable interface I made a code block guide to help a bit with the first problem, but that's not a full documentation rather a description of each available block. You mentioned in another topic that you don't want to spend time with coding, actually to test the functions you don't need much. There are only a couple of code blocks that you need to use to control the motors (e.g. rotate 90 degrees), it shouldn't be difficult to set up the code for testing. If you need some help with this just PM me, if you tell me which hub and which motor on which port shall do what then it shouldn't be difficult. About the interface - well that's a tough one, there're two interfaces with fixed elements at the moment, and even the better one is far from being good for anything else than a tracked vehicle. The next release should be around the corner with an important update for servo steering control, I'm not sure we'll also get any interface changes this time but I'd wait to see before starting to build the proper control interface.

You can use the code as many times as you feel like.

I was referring to the AA + AAA hub solution. The AAA hub is not very different from a volume perspective if we compare it to multiple IR receivers or the SBricks, especially with all the PF plugs attached. The latter ones surely can be distributed better but in most cases this can be a resolvable challenge. We'll see if TLG will recognize the need for such solution from the AFOL community and if it fits into their production pipeline. I'm afraid their hw development is still mostly based on the demand from the projects' side (the sets being developed), and anything official that has 4+ motors will be probably big enough to house 2 Technic hubs (e.g. Liebherr), or will include a gearbox to switch between the different functions and they make it work with a single hub. Maybe it's time to push the Technic designers to come up with something relatively small and complex enough that requires this solution and try to convince the managers to turn it to an official product :)

Dumb splitters are certainly not possible, you need to put in the required electronics to give you more ports. These are valid examples, for 5 functions I'd use one AA and one AAA battery box. If there's space for a PF AA battery box and 3 IR receivers or 2 SBricks then there'll be space for those 2 PU units as well :) But I'm sure there'd be plenty of examples that were working with PF or a PF+3rd party solution and will not be easy to replicate with PU. My own 42069 mod is like that, it had 8 motors (4 L for driving, 1 servo for steering, 3 M for the functions) and 4 PF lights ,and all these were operated by 2 BuWizz units hidden in the back of the truck. That's why I'm saying that PU might not be a solution for everyone, I firmly believe that PF and the 3rd party options will live on for quite a while. There'll be a possibility to go the interactive way with all the sensors, smart motors and advanced coding functions, or the PF way with many connected devices but less smart functions (or some with a 3rd party controller). TLG simply cannot provide a solution that fits all needs, e.g. they decided to use a universal plug that works in all of their connected products from the dumb M motor to the advanced sensors but that means they lost stackability. That's a trade-off where the majority of their customers will enjoy the benefits, but a minority of the advanced MOCers will not be satisfied. I will also keep using both systems and try to choose a solution that is best for that specific situation.

@thekoRngear sorry, I really misunderstood your reply.

I was actually asking about that specific situation, I'm totally aware of the issues that were raised during the past 2 years (partially by myself included). PU is not perfect, but it's a step forward for a smarter way of controlling LEGO, and that required several changes. I'm not trying to defend anyone, just trying to provide thoughts from another perspective. Let's see: You can't stack sensors and smart motors, simple as that. Since TLG wanted to add more functionality and interactivity to the system they had to go this way. True, but running 4+ motors from a single power source would already affect their performance in the PF world as well. I don't think there are that many applications where you would connect more than 2 IR receivers to a single battery box. Regarding the lights TLG needs to come up with a better solution that they have currently, a "smart" port replicator with control electronics but without battery would be a possible solution. Since the connected motor/light/etc. type can be detected it is simple to restrict the type of devices to ensure the required power level is still provided. Their difference is very similar to the PF L & XL motors when they are geared to the same speed. The PU XL motor is simply geared up internally compared to the PF equivalent (or not geared down, not sure about that). This is only the case if you want to use the official Control+ profile. In their case restrictions are needed because the profile simply wouldn't work if you connect e.g. a simple M motor to the port where the steering L motor is supposed to be. If you want to make a MOC then you shouldn't use the Control+ profiles, but the Powered Up app. Yes I know you still don't have customizable interfaces etc. but it does not mean there won't be any solutions for that. Again PF didn't need profiles because it was a simple IR based system without any advanced controls, anything extra was added by 3rd party solutions. No you can't, but while with PF IR you could physically connect a buggy motor to the IR receiver but it only provided you a fraction of the original performance. With a simple DIY or 3rd party converter cable you can run them at the same level with a PU hub as well. That's an issue we addressed multiple times and I'm sure a solution will be provided. It still might not be perfect for anyone as it will not rely on dumb IR remote controls, but a less complicated software interface is coming. PF does not have this problem because it is a dumb IR-based system, no sensors, interactive motors, nothing. If you want to stick to that then you are welcome to use it, we are still using buggy motors that were discontinued like 10 years ago so I don't see PF going away anytime soon for simple applications. Btw if you like SBrick without coding then make sure to avoid the next generation of their app ;) And PU gives you a simple "dumb" control solution already - if you use the AAA hub and the remote (that technically has the same functionality as the PF IR remote) then you can control the 2 connected motors without any apps. It does not cover yet all aspects as it won't give you servo-style control for the L/XL motors but it again only depends on a fw update. I don't see why you should not do that if that's a good solution for you, but don't forget that hobby grade servo still requires a controller that you also need to buy. SBrick only gives you a control solution without motors, sensors etc. so it will be always more "reasonably priced". If you compare a Technic hub ($90) and try provide the same functionality with SBrick then the math looks like this - SBrick + extension cable + AA battery box + WeDo tilt sensor = $59 + $3 + $7 + $27 = $96 That's an issue TLG will need to resolve for sure. The current controller is not sophisticated enough for advanced controls, they need to come up with a proper one that allows proportional control with joysticks. We can run these circles over and over again, but from my point of view saying "PU sucks, PF was the king" is simply wrong. In the past 2 years I can't tell you how many times I raised concerns on several different platforms, because I did not like either what I saw. But it always helps if you try to understand the reasons behind the decisions made on the other side of the fence, and formulating constructive criticism is quite important too. Whatever we say, TLG will not revert back to PF just because "those were the good old days". AFOLs are important for the company but they are a toy manufacturer for kids in the first place, so if they develop a new remote control ecosystem then it will be kid-focused in the first place, that means providing a possibility for visual coding will get a higher priority on their list than crazy fast buggy motors, high precision servos and all these things. But I'm still sure they'll listen if we tell them what is still missing from their ecosystem for us and how that can be possibly added to make AFOLs happy as well.

Those solutions use only a fraction of the potential in the system, no use of sensors, interactive features of the motors etc. And yes, I totally agree that TLG missed the point with the approach they took, I think the release schedule should have been different. As I see they wanted to provide access to the advanced features as soon as possible, since those are the ones differentiating PU from PF, providing an added value. People usually forget how simple the BuWizz or the SBrick apps were in their early years, lacking some very basic features, they also needed years to become versatile and useful. But the response from TLG was too slow, so now we are in a situation where the PU environment still has major features added with every release, instead of having a mature and fully capable system released on day one.

@thekoRngear what would you like to see exactly to have my "story" proven? :)