Brickster12

I've installed the new firmware as well but there are still issues: Fixed: Multiple hubs in BLE network with ONE handset works now in all desired combinations (one common channel or multiple channels). No motor stuttering/going mad. New issue: 1 hub + 2 handsets (on same channel): Handset that was added to BLE network first is fully functional. Any additional handset added to network is without any function. 2 or more hubs + 2 or more handsets on same channel: Same as item 1. 2 or more hubs + 2 or more handsets on multiple channels: Same as item 1 - except channel select button on handset changes between available channels. It actually does not matter which handset is on which channel - the one added to the network first always works, any additional one does not work. I tested that systematically with all handsets I have and can exclude that the handsets have the issues. It only depends on the order of addition to the the network. All these cases did work with the previous firmware version but had the issues of motor stuttering/going mad - hence this looks like a regression issue or the result of a quick fix (solving motor stuttering over preserving multi-handset functionality). So actually you currently cannot run two trains with two individual handsets simultaniously. If you buy two PU Train sets you quickly run into this situation. Does anyone confirm this?

The Lego support team replied that TLG will come up with an firmware update soon. However, they could not provide a date yet. Last week or so there was an update of the Powered Up app in Google Playstore but it did not contain a newer firmware as I already have on my hubs. So keep fingers crossed for the next update. ?

Recently I discovered in the PU app as well as in the Boost app that you can not query multiple color distance sensors individually. While the programming blocks for motors allow port addressing, the blocks for sensors do not. Having two sensors plugged e.g. in the MoveHub their readings are just combined (the smallest value dominates). It looks like TLG has not implemented the port addressing consistently for all components one can connect to a hub.

Oh, I expressed myself wrongly in my original post. During update and first usage after the update the hubs were running on Alkaline batteries. Later on I replaced them by the Eneloop rechargebles. There ist no difference in behavior between Alkaline and rechargebles. I also did a quick-check: when using rechargebles the Powered Up app reports full batteries. Hence it appears that at least Eneloops are feasible for use. (I corrected the original post)

Hi, as the new Powered Up elements are software driven and receive firmware updates from time to time I think it might be useful to have a place to discussuss issues related to the software and updates. To give it a start I would like to discribe my observations after the last firmware update I performed on my hubs: I performed a firmware update on three of my 2-port-hubs ("Hub No. 4") on 10. Aug. 2019 through the Powered Up - App for Android. The update was performed successfully on all three hubs according to the app. There was no interuption of the update and my smartphone was fully charged, the hubs were running on almost new Alkaline batteries. Shortly after that I discovered a quite strange bahaviour that can be reproduced and is obviously not an intended behaviour: When using two or more hubs in range of BLE together with one or more handsets plugged in motors or lights show an abnormal behaviour when [+] or [-] buttons are pressed a couble of times. Expected "normal" bahaviour should be (was before the update): M-motors: while [+] or [-] button on handset is pressed, motor on particular port goes +/- 100% depding on button. Releasing button, lets motor run out. M-smart-motors ("Boost motor"): same as M-motor. Train motors: [+] button on handset increments speed forward, [-] button increments speed backwards, [ ] button stops (breaks) motor on particular port. Lights: [+] or [-] buttons increments brightness, [ ] turns off light on particular port. Observed bahavior after firmware update: A single 2-port-hub in BLE vicinity: Everything works as expected. Two or more 2-port-hubs in BLE vicinity: Hubs on the same channel (same LED color): M-motors, M-smart-motors: pressing [+] or [-] a couple of times lets the motors on the particular port go mad: they run continuously or stuttering at random speeds. Pressing [ ] does not stop them. Occasionally they stop when pressing [+] or [-] on a random sequence. Train motors: in addition to the stuttering they also show extremely rapid changes between +100% and -100% which looks like causing very hard loads on the structure (motor starts to jump when not built into something). Lights: very similar like the motors but with brightness, resulting in wildly flashing lights. Hubs on different channels (different LED colors): Motors/lights on hub turned on first: normal bahaviour (!!) Motors/lights on any other hub added to the network in BLE vicinity after the first one: same abnormal behaviour but separated by channel. Using just one or multiple handsets does not make a difference. This actually means for me I: with this current firmware I cannot run two or more trains at the same time - regardless how many handsets I use. This is because all hubs in BLE vicinity form a communication network (which is desirable) and are affected of the issue. Does any one else observe this strange behaviour? I've raised a LEGO service ticket with a description of the issues yesterday. I have only reveived the automated feedback so far.

Right, that is a point. On the other hand having the software running on a mobile device is easy to use. And if you are not running a huge static MOC display for hours or even days but just want to play around with automation a mobile device is a really good platform. However I personally preferr platform independent software as that provides most flexibility. Open source, open standards and Node/JS, Python & Co. are the right choice to go with... even from a modern commercial point of view. What I'm missing is a more holistic approach from TLG. It is quite ridiculous that WeDo and Boost are incompatible software-wise while the hardware is compatible. TLG has obviously missed to understand that if WeDo is used in school kids may want to do more at home and may want to use Boost and/or PU. But then it would be VERY useful to have the same programming environmet available for all three product lines. (I'm saying that as an AFOL and parent of two kids in the right age) So the software is a complete conceptual and product design fail in my eyes. And separating the markets here does not make any sense. I really hope TLG gets the turn in future.

The more I read about boost/pu the more it becomes intersting to me. Last few days I played around with the Boost app (w/o having any hub) just to see what programming features it offers out of the box. And I think it provides most programming structures one needs for automating trains. So possibly many people could be happy with that. (Although I personally appreciate the effort shown here in the forum to open the new hardware up for more advanced programming languages and generic environments.) However, one thing I could not find out (have already searched here and the internet) is: does the current Boost app already allows to connect to and work with the PU smart hub? Can I run e.g. one of the 2018 trains with Boost? Could someone here who has Boost app and the PU hub give it a try? Same question for the WeDo hub. Does it require an own app or can one use the Boost app? The info I found regarding this was not really claer about that... Also I have noticed that the Boost app had some updates since release and many of the early reviews appear outdated in the meanwhile (e.g. regarding availability of certain programming functions and control structures). The latest version appears to me at least in some points better than the initial release.

Has someone identified the connecor type used for Boost/PU? Would be nice to know a source where to I could order some.

I think it wasn't really mentioned yet... the current Lego Powered Up app provides already two control profiles for the Bat mobile, one with fw-stop-bw for left/right and one with contiuous fw-bw sliders. The set uses the WeDo motors.... Hence the different control behaviour in this case does not depend on the (motor)hardware used in the model but just the software. I can imagine (and hope) that TLG gives us in future a kind of customizable controls in the app where one can just select between differet controller concepts for the hardware. The existing app already demonstrates what IS possible. Unfortunately all the functions are currently burried in pre-defined control profiles...

PU is really promising, however related to trains I'm still struggeling with the lights topic. In my trains I usually have front and back lights. The PU hub allows me two power consumers. 88005 provides me two LED. So actually it is impossible to equip a train with a motor, front AND back lights using stock PU components (and only one hub). Hence I think TLG's FAQ answer on equipping trains with lights falls a bit short. Wich is a bit surprizing as 60198 has the option for lights at both ends. -- Back to topic. My wishes: - A programming environment that seamlessly allows using all WeDo 2.0, Boost and PU components. This programming environment should use the known block language to make it easy to use for kids and AFOLs. - The programming environment should be availabe for mobile and stationary devices including Windows, IOS and Linux. A platform independent approach would be highly appreciated and contemporary! - Custom code should be easy to share within the Lego community. - A useful selection of analog PWM motors in the sizes like PF. - Adapter connector for the PF motors. - The selection of digital motors (WeDo/Boost) could be extended by at least one high torque motor for load intense applications. - A splitter connector allowing multiple motors/lights on a port. - A hub with AA batteries and 4-6 ports that can be connected to multiple controllers. - Remote controllers: in addition to the new train controller I would like to see a controller that has analog sticks (with axel holes) providing a smooth range from -100% to +100% with spring loaded center position. Stick orientation schould be rotatable like train controller. This controller would cover all use cases with "linear-centeted" (100% 0 -100%) and "digital-centeted" (1 0 -1) motor speed control while the train controller covers all use cases with "static" motor speed control (+ stop -) - The next evolution of Mindstorm components and main units should integrate with all this seamlessly. Proprietary product lines are in times of connectivity and smart devices completely old-school. We want to see something modern that integrates seamlessly with the now latest hardware generation (WeDo, Boost, PU) just as we used to have with the bricks! - A dead line for community wishes of just 3 days is way too short. We should have time to make ourselfs familiar with the new system first.