Mr Hobbles

At the time the set was announced, it was stated during the press conference. Page 3 of this thread by a guy who was at the press conference. :)

I don't think so - we've been told the Liebherr has 2x 4-port hubs. The SPIKE Prime set has a 6-port hub. Also I think the SPIKE Prime hub is more advanced - full Bluetooth as well as BLE, USB connection, program storage and recall, etc.

Disregarding your distaste for Lego’s reasons for choosing those colors, you’ve both glossed over the point I was actually trying to make, which is I believe that Lego would try to choose different colors for the Technic audience. So if I’m correct, you need not worry.

Please refer to Lego’s own video, entitled “All-in-one” box, for usage of the term “gender inclusive” when describing the colors in SPIKE Prime. https://education.lego.com/en-us/products/lego-education-spike-prime-set/45678 If you would like a list of colors they consider to be gender specific or exclusive, may I suggest contacting them.

So Brothers Bricks was present at the Lego Education press conference in Russia this past week, and it was stated that a new Mindstorms product will follow in the next year or two, based on SPIKE Prime tech, but with a more advanced programming solution. In the meantime, SPIKE Prime is intended to replace EV3 for the educational market, as they claim it has all the same capabilities. https://www.brothers-brick.com/2019/04/14/hands-on-with-lego-spike-prime-at-moscow-international-education-fair-2019-news/ A couple of other tidbits: I'm glad (and expected) that Boost and WeDo components would work with SPIKE Prime, and I also fully believe that they don't intend to add the capability to control SPIKE Prime components with WeDo/Boost hubs, but I refuse to believe it's not possible. :) I'll certainly be trying it out in our own software - let the reverse engineering commence!

Agreed, it's nice to see Lego adding proper official programming language support. Especially since SPIKE Prime also supports MicroPython, it seems Lego will be supporting it consistently.

I don't get the controversy about the colors. Lego has made parts in different colors for different purposes before, and I 100% believe they'll do it again here. These motors are for education, hence the pleasing and gender-neutral colors. If they're going to use the same motors for Technic, I see no reason why they wouldn't mold the two relevant parts in a different color. After all, Education sets aren't available to the general public, so having the color scheme for Technic motors be dictated by a range that no-one can even access makes no sense. Lego isn't stupid, they know their audiences, and they target the different ranges to each of them appropriately, making changes where required.

That's fair. :) I've chosen not to support the older firmware and am instead putting a warning message in to ask people to upgrade. However for you, to activate your virtual port I think the command you want is [0x06, 0x00, 0x61, 0x01, 0x00, 0x01], right after you get the port notifications for 0x00 and 0x01. This will cause an error you can just ignore on the old firmware. Also note that the combined port id will no longer be 0x39, it'll be 0x10 - but you can read that from the virtual port setup response, as the docs say it may vary (Though I don't see it happening on the PUP hub due to it only having two ports)

A bit strange that it would appear less bright on the PUP hub than on the Boost hub! It could be that I'm putting the sensor in a different mode than what you're using in the Boost app. I will admit I don't really do much in low light scenarios either. Would you mind raising an issue on GitHub so I can help debug it? Makes it easier to keep track of problems, and helps not bung this forum up with support discussions. :) https://github.com/nathankellenicki/node-poweredup/issues

@Cosmik42As promised I posted about it in the Powered Up teardown thread. :) You can either form the AB virtual port back again manually, or migrate your motor commands to the Boost format, since they're now standarised. \o/ To note, I'd expect the Boost move hub to break with its next firmware update too. I imagine they'll also remove the auto combination port forming like they've done with the PUP hub.

So I just published node-poweredup v2.2.0 (https://github.com/nathankellenicki/node-poweredup/), which includes fixes to fully support PUP hub firmware 1.1.00.0004, and hopefully the next revision of the Boost move hub firmware. Changes: Virtual ports (AB, CD) no longer have hardcoded values. On PUP hub and Boost move hub, the library watches for attach events of the physical ports, checks the device types match, then sends a combine command to form the virtual port. This is done to preserve backwards compatibility, and as those hubs have no other possible combinations. The auto-combining isn't done on all hub types. This should set a base for people to be able to combine/disassemble their own virtual ports on hubs with larger number of ports (ie. SPIKE Prime hub with 6x ports - combo AC, DF, EB, etc). Motors are now activated on the PUP hub in exactly the same way as on the Boost move hub. Boost motors are now fully supported on the PUP hub - rotate by angle, rotation notifications, etc. Thanks Lego for standardising the two hubs, the PUP hub no longer feels like a half-baked weird sibling! :)

PUP hub firmware - 1.0.03.0000 lpf2hub Received Message (LPF2_ALL) <Buffer 0f 00 04 00 01 01 00 00 00 00 00 00 00 00 00> +313ms lpf2hub Received Message (LPF2_ALL) <Buffer 0f 00 04 01 01 01 00 00 00 00 00 00 00 00 00> +14ms lpf2hub Received Message (LPF2_ALL) <Buffer 09 00 04 39 02 01 00 00 01> +0ms PUP hub firmware - 1.1.00.0004 lpf2hub Received Message (LPF2_ALL) <Buffer 0f 00 04 00 01 01 00 00 00 00 00 00 00 00 00> +241ms lpf2hub Received Message (LPF2_ALL) <Buffer 0f 00 04 01 01 01 00 00 00 00 00 00 00 00 00> +15ms So some investigation shows this as the cause of the incompatibilities in the latest firmware. But first, a little background. Both the PUP Hub and Boost Move Hub have the concept of virtual ports. When you plug in two devices of the *same type* (ie. two WeDo 2.0 motors) to ports A and B, internally the firmware creates a new virtual port, port AB. This allows you to control both devices with a single command, through a new family of commands - the group commands. In the example above, I have two WeDo 2.0 motors (device type 01) plugged into ports A and B (00 and 01). This triggers virtual port AB (39) to be activated (not in latest firmware. See below). The Boost Move Hub automatically creates one on startup as ports A and B are internal motors and non-removable. The PUP Hub creates one when it detects two devices of the same type. At least, until now. There is this curious remark in the official LWP3 specs: https://lego.github.io/lego-ble-wireless-protocol-docs/index.html#virtual-port-setup. There are actually a few more on the same topic. Essentially, up until now, the hub automatically creates the virtual port and notifies you of it. As of the latest firmware, it no longer does this. Why? Well, I believe for two reasons: 1. This latest app update, and 2. SPIKE Prime and future LPF2 products. Virtual ports can be created for any device types, not just motors. So for sensors that means that it's essentially combining the output values of two sensors and returning a single value. In order for that to make sense logically, the hub needs to know how to interpret the values. Should it take an average? Add them together? Do some math? It will depend on the sensors in use. So the LWP3 spec details how to set up the virtual port by giving it "port information setup" instructions. Something we now need to do. And I think the reason is that with the latest app functionality, along with the new motors and sensors coming out, it no longer makes sense to assume that all device combos will have the same setup information. We'll need to tell it how to behave. This is especially crucial with the SPIKE Prime vision sensor - that 8-pin header is gonna allow anyone to create any sensor they want, and then the hub would be really confused! Also SPIKE Prime has 6 ports. If you plug in 6 types of the same device, there's no way the firmware can know which virtual ports you intend to set up. So, this breaks 0x60, as well as 0x11/0x02, as they rely on the port being setup. I'm still playing with the port setup commands to get them working again. :) I know for a fact they do still work though, as the Batmobile still works. Yeah, 0x60 isn't documented, I came across it while brute-forcing commands. I then later discovered the Batmobile uses it for its zigzag motion by sniffing the BLE connection. I wonder if they'll bother documenting it, given it doesn't exist on the Boost move hub. I recall there was one motor that 0x51 didn't work for me at the time, hence why I resorted to using 0x60, despite not being its intended purpose. It may have been the WeDo 2.0 motor but I can't recall. :)

Kinda...the main problem is they now follow their own spec to the letter! ? Basically virtual port AB is no longer implicitly created when you plug in two devices of the same type. It now expects you to send commands to manually create a grouping. This is something their LWP docs said we should do, but actually wasn’t possible until now. I’ll go into more detail in the other thread. I was using the 0x60 subcommand to control the motors as it was the only one that could control all three, also due to bugs. That’s no longer the case - we can now use DirectModeWrite 0x51 and all motors recognize it. It also looks like they’ve changed 0x60 to properly rely on the existence of AB, which doesn’t unless we create the grouping in firmware. In short, use the same commands to conte motor speed as you would an LED now, as it’ll now correctly work for all motors!

I hope to be proved wrong, but I don't think Lego plans to address that. From their Powered Up FAQ's a few months ago, their opinion was that bang-bang style operation makes more sense for non-train-Motors, as 90% of use cases will be remote control cars. I believe it is a property of the hub. The handheld simply sends button press events to the hub - the hub is responsible for interpreting what to do with them. Re. upgrading handheld - I don't know if this is possible. I've tried connecting a Powered Up remote to the app this evening, to no avail. It is not detected. So, in the meantime, we have to use third party software/libraries to intercept the button presses and send new commands to the hubs. I do recall reading in that same FAQ that they mentioned it might be possible to connect a handheld to the Powered Up app at some point in the future, and use the programming interface to react to button presses. But that doesn't appear to be in this release, if they're still thinking of doing it.

Turns out that day was today. :) New Powered Up app has new firmware update for PUP hub that fixes that bug.

Ok, some initial observations: There is a new firmware update for the PUP hub, that on first glance, appears to do four things: It fixes the bug where plugging in two "non-simple" devices crashes the hub! I am now able to plug in and control two Boost motors on the PUP hub. Yay! It fixes the bug where "rotate by angle" commands didn't work! I can now rotate a Boost motor by X degrees. Yay! It fixes the bug where no rotation events were reported. I can now rotate a Boost motor and it detects and notifies me of the rotation. Yay! It appears to break the 0x60 command I was using to control all motor types by speed. It now doesn't work for controlling any motor. I'll need to do some further investigation. Boo. No firmware update for the Boost move hub yet. I'm still expecting one asap - the Shop@Home description for the move hub states that the PUP remote control works with it - it'll need a firmware update to support that. On the app side, it appears to include some nice sound effects! Trains, cars, trucks, dogs, cats, robots... EDIT: It appears as though the Boost style 0x81/0x11/0x51 DirectWrite commands now work for motors, and they've either removed or changed how 0x60 works. Which means I now need to see if they've accidentally broken the Batmobile, or if it now uses a different command again!

Finally! I was hoping for this! The biggest surprise for me is that they included support for the WeDo 2.0 sensors! I honestly thought they would just forget about them. I’m very glad they didn’t.

I don't actually know, at least consistently. :) I think it's the "LPF2 Smart Hub 2 I/O" and the "LPF2 Smart Move Hub 2 I/O" for the Boost hub. * The LPF2 team themselves call it the "Smart Hub 2 I/O", I expect in reference to it having two input/output ports, but, Shop@Home just calls it a "Hub". * Lego Education also calls the WeDo 2.0 hub the "Smart Hub 2 I/O". Which makes sense as it also has two LPF2.0 input/output ports, but makes no reference to its lesser capabilities or lower power. However I think this platform is now out of date and no longer supported (even though it's still sold), as Lego has stated the firmware or apps will no longer be updated. * The LPF2 team also calls the Boost Move Hub the "Smart Move Hub 2 I/O", I expect the "move" part making reference to it having built in motors. Shop@Home also just calls it a "Move Hub". Regarding the data lines, I wonder if it's simply because 8-pin headers are more commonplace (Is that the case?), so tinkerers are more likely to have them on hand? Two of the data lines may be unused? And I also wonder if we need the full sensor because it handles the initial handshake with the hub. Probably implementing a full identification handshake is beyond the scope of educators making their own sensors. Who knows though. I eagerly await the spec. :)

I'm hoping that this back and forth means they're getting close to app and firmware updates. ie. Was meant to be available last week, but wasn't ready, so they took them off sale, and now they're close again. The descriptions of those components promise certain things that aren't currently possible, so I can't see them putting them up for sale unless that functionality was close.

The brick itself, no, but it is capable of real-time communications with a PC/tablet which could offload the processing, especially as it also states its designed to either work in autonomous or tethered modes. My camera comment was merely an example of one of the types of applications of the high speed ports. Also I still believe SPIKE Prime is the first type of this hub, I'm expecting a Mindstorms replacement within 2 years that ups the capabilities further.

Thanks Jetro. :) I signed up for that community - despite the fact that it saddens me that the discussion has moved towards Facebook with its data-mining and privacy violations. It's great that they've been working on with members of the community on SPIKE, and the inclusion of the 8-pin header on the vision sensor is very exciting. They're already opened the LWP3 specification, now I'm just waiting for the full LPF2 specification so we can put that header to use. There's lots of other interesting information in the tech specs for the hub too. The hub either talks Bluetooth classic or USB to the users smart device. The hub is always cable of talking Bluetooth Low Energy with LWP3 to connect to other LWP3 hubs and remotes (Such as the Powered Up train remote). Two of the ports are special high speed ports - I assume this means for higher demanding peripherals such as cameras and video feeds? Who knows whether Lego will release an official LPF2 camera, but the 8-pin header on the vision sensor opens the possibility for someone to connect one. The ability to use MicroPython on the hub is exciting

Yep, they’re official. It was community driven up until December, when Lego released those docs on LWP3. There’s still stuff that documentation doesn’t cover that we figured out though, so hopefully they keep expanding on it. The only rechargeable batteries so far is for the WeDo 2.0 hub and SPIKE Prime hubs. Nothing yet for Powered Up or Boost hubs.

The released ones already are. :) We have WeDo 2.0 sensors working with the Boost hub, Boost sensors working with the Powered Up hub, Powered Up train motors working with the WeDo 2.0 hub, etc, as they are all LPF2. :) This isn't possible with official Lego apps, but people in the community (myself included) have written other software to enable people to do this, including on laptops. Lego just need to update their apps to do this officially. But the hardware is compatible as is.

It's becoming clearer to me over time that "Lego Power Functions 2.0" (LPF2) is the name for the peripheral standard and Lego Wireless Protocol 3.0 (LWP3) is the wireless standard, whereas WeDo 2.0, Powered Up, Boost, Control+, and SPIKE Prime are names for the brands of Lego products that use the the LPF2 standard. :) The peripheral standard appears to dictate how the peripherals (motors, sensors) connect to their hubs, both in terms of the wire protocol and physical connector. The wireless protocol dictates how the hub communicates back to the users smart device, be it a laptop or phone. For example: For simple automation of system models there is Powered Up, for which the peripherals utilise the LPF2 hardware standard, and the hub utilises LWP3 for communicating back to the users smart device. For simple automation of Technic models there is Control+, for which the peripherals utilise the LPF2 hardware standard, and the hub utilises LWP3 for communicating back to the users smart device. For education and learning: There is WeDo 2.0 for primary education, for which the peripherals utilise the LPF2 hardware standard, but does not use LWP3 as its wireless standard. It uses an older (somewhat similar but more basic) wireless protocol (LWP1? LWP2?). There is SPIKE Prime for secondary education, for which the peripherals utilise the LPF2 hardware standard, LWP3 for communication with other LWP3 devices (ie. Powered Up remotes), and new, as yet undocumented, Bluetooth classic and USB protocols for communicating back to the users smart device. For robotics in the home: There is Boost for younger users, which utilises the LPF2 hardware standard, and LWP3 for communicating with the hub. There is Mindstorms for older users, which currently uses its own hardware standard and wireless protocol. I fully believe there will be a new Mindstorms product within the next year or two which utilises LPF2, and likely, LWP3 somewhere. So far, Lego has released documentation for LWP3, so that we can write code that allows our devices (laptops, phones, etc) to talk to LWP3 hubs - https://lego.github.io/lego-ble-wireless-protocol-docs/ Lego has not so far released documentation for the LPF2 wire protocol though, but I believe they plan to - the SPIKE Prime vision sensor has a removable back, exposing an 8-pin connector and enabling hardware enthusiasts to design and connect up their own motors and sensors. They'll need to release the LPF2 wire protocol publicly to enable people to do this.

I don't agree that the colors are _girly_ per se, but I agree that the color choice is part of a wider swing towards a more inclusive STEM education. By choosing neutral colors that offend neither group (EV3's red/gray/white/black colors are definitely more male orientated, and red and black are known for evoking strong feelings) they're hoping to get more girls into programming and robotics. Personally, I actually love the color choice. :) EV3's color scheme made me think a Razer gaming pc had thrown up all over my Lego collection.