Mr Hobbles

There’s no such command as far as I know, but the motor is already capable of acting like a sensor. When you send it a command to move, it can also keep reporting back how far it’s moved in degrees. So one way to do what you’re proposing is to activate the motor for X seconds. Assuming it gets blocked at some point while doing that, time will run out and the motor will stop trying to move. By recording the rotation notifications you can tell how far it’s moved.

So, firstly, yes, PPP is silly, for the reasons you mention. Size of parts, size of packaging, shipment costs, molds, etc. But, you mention 42099 and 42100. 42099 and 42100 are interesting cases, and probably only comparable to sets that came out in 2009-2011 during the introduction of Power Functions. 42099 and 42100 are flagship models designed to showcase the power of Powered UP in technic models through Control+. As a result, at this early stage, the cost of the set has to include: 1. The cost of the ABS plastic that went into them (weight/quantity). 2. The cost of new molds for those parts. 3. Additional new materials for the new components - PCB's, chipsets, metal, wires, etc. 4. The new supply chain requirements for those parts. 5. The cost of developing the new apps, and firmware for the electronics components. 6. Recouping the costs for 2-4 in a reasonable timeframe. The sixth one is important. A business functions by return-on-investment, and that time period is not indefinite. They can't say "we can spend this much up front because we think we'll get it back over time" like Power Functions, because at this point they have no measure of whether Powered UP will be a success yet. They may be forced to replace it in a couple of years time due to people not liking it. They'll have had to make the same decisions at the start of Power Functions too. We know Lego typically works in 3 year blocks from previous experience through themes, products, etc. If it hasn't turned out to be succesful by whatever internal measures they have in place by year 2, they've typically had no qualms in calling it quits by the end of year 3. This means that they'll have likely worked out amortizing the cost over 3 years. No doubt, as Powered UP sticks around for longer the cost of parts will come down as they did for Power Functions, and future sets 3+ years out will be perceived as better value for money - the costs of hardware, firmware and app development will come down as most of the work will have been done, and they'll be able to focus on charging for material and production.

Bang bang like the PUP and Boost motors when used with a paired physical remote control. From an app or custom software it can operate however you want.

Hmm interesting. As mentioned this differs from the behaviour I see, but indeed, it could be that its using a different subset of commands from the AbsolutePosition commands noted already in the documentation. I have a BTLE sniffer that I'm planning to use in the next few days to try and get some more commands, so we'll see what that comes up with. Will let us know if there are additional commands its using for absolute 0 or if its using a combination of the existing commands.

I think you can block it on one side because only one side is required to know where the center is. For example the app knows (because it is designed for 42099) how many degrees it should be able to move in any direction. So if it knows it should be able to move 75 to the left from forward, and it only manages to move 35, then forward must be an offset of 40, regardless of the other side. The 0/90/180/270 theory doesn't match up with my testing. For example, when I send the PresetEncoder command I'm able to reset the internal absolute zero to wherever the motor is at the time, and then I can use GoToAbsolutePosition to move to any position relative to whereever I set it, and not just within 90 degree increments. Also when I use the hub with my other code, GoToAbsolutePositon moves from the position where first turned on, regardless what the actual position is.

Well, for lack of a better place to discuss this stuff, I've been working with the Control+ stuff and adding support to node_poweredup. :) Here's what I've discovered: 1. For the first time, the hubs internal tilt sensor supports X/Y AND Z axis. The inbuilt accelerometer works nicely too and is a seperate sensor that reports acceleration. 2. There's an internal temperature sensor. It reports in degrees c. Mine reports about 28c while running, so I'm guessing this is CPU temperature. 3. The new motors allow you to specify an absolute position to move to. HOWEVER, there is NO absolute zero coded in. Absolute zero is whatever the position is when first turned on. I sniffed the BTLE comms between the Control+ app and the hub when playing with 42099 and it's really interesting. It does a little calibration dance where it moves the wheels as far left as possible then as far right (until blocked by the models superstructure), then measures the actual travel. Using these numbers it can determine where absolute zero should be. It then moves the motor to that position, then send a command to the hub telling it to "reset" the absolute zero position to there. 4. The new Control+ motors work fine on the PUP Hub and the WeDo 2.0 Smart Hub. However while they are recognised by the Boost Move Hub, they refuse to work, and instead send error notifications back. Perhaps a firmware update is required? Still investigating.

Just to note, I discovered when adding support to my library that there is no such thing as absolute zero on these motors. Absolute zero becomes whatever the motor is positioned at when the hub is first turned on, so marking it with a sharpie won't help. The way it calibrates when you use 42099 with the Control+ app is that it does a little calibration dance - first it moves the wheels as far to the left as possible (until blocked by the rest of the structure), and measures how far it actually moved. Then it does the same to the right. Using this, it determines how many degrees it should adjust to face forward. It then adjusts the motor to face forward, then sends a command to the hub to "reset" its internal idea of zero to whereever this forward position is. Any third party controller or app will need to do something similar when connecting to your MOC.

Thanks, and looks like you're making good progress! I have a query for you actually. :) Up until now I've ignored the reported RSSI values as most Bluetooth stacks report the RSSI level from the BLE central device (ie. my laptop). Have you noticed a big difference between the peripheral reported RSSI and that? This came into the forefront of my mind as I recently discovered one of the things that's been bugging me about the Powered Up remote. On most LPF2 hubs, ports 0x3b is voltage and 0x3c is current. But on the remote, 0x3c is RSSI. They don't seem to bother with current reporting on the remote, which makes sense as with no physical ports, it's not gonna fluctuate much.

I haven't actually tested it in a while, but I always assumed it only sent out a new value when the value changed? I could be wrong though.

:) Glad you worked it out. You might have noticed that the "reply" is actually the same message we got in the old firmware, that was automatically sent when the firmware automatically created the virtual port. So you can look for that message with the same code on both firmwares. And if you send the virtual port formation message on the old firmware you get an error reply, but nothing bad happens. So my backwards compatible solution is to send the virtual port formation message regardless, and just parse the reply the same on both.

And WeDo 2.0 motors and sensors. It supports the whole LPF2 range currently.

Yes, my library supports it, and there's no firmware update necessary. I have a compatibility table on the readme - https://github.com/nathankellenicki/node-poweredup The WeDo 2.0 hub successfully reports the motor as type 38. I can control it by speed, and I can get rotation notifications from the hub when I turn the motor by hand. The only thing that either doesn't work, or I haven't figured out how to make work, is to rotate the motor by a specific angle. This may be due to a lack of a DirectWrite mode in the limited protocol the WeDo 2.0 hub supports. Or if it has it, I haven't discovered it yet. Currently the Boost motor and sensor _partially work_, and the train motor and LED's fully work. The LFP2 protocol is quite well designed - the hub doesn't really need to do anything special to support different motors and sensors. Most of the logic is up to the controlling smart device/app.

There are certainly a lot of components coming out, I expect it to get even more confusing! I think one thing to note is that all the "hubs" (PUP Hub, Boost move hub, SPIKE Prime hub, Duplo train base, even PUP remote control) are basically they same. They all speak the same Bluetooth protocol to the app as each other. The only difference is with the inbuilt motors and sensors and number of ports. Even the different inbuilt functionality (RGB lights, Duplo built in speaker, voltage and current, etc) are all just "sensors" in the firmware. The only difference is that you can't physically unplug them. :) Just an example - even the PUP remote is just another "hub"! The only difference is it has no ports, and the left and right buttons are just two inbuilt/non-removable sensors. Every hub also supports every other LPF2 device. You can plug a Boost motor into a WeDo 2.0 hub and it'll recognize it. You should be able to put a SPIKE Prime motor into a PUP hub and it'll recognize it. The only differences is whether the app you're using allows you to use that device. :) So, if you're only interested in the PUP hub ("Hub.No4", "Smart Hub 2 I/O", whatever you/they want to call it), it's quite exciting as hopefully you'll be able to use the entire range of LPF2 motors and sensors with it. Perhaps Lego will be slow with updating their official apps to support them, but our third-party apps and libraries should be faster! (I already have orders in for SPIKE Prime, and intend to do the same with the LEGO Technic Liebherr on launch). Regarding the firmware - the protocol for updating the firmware seems to be documented, but we don't have any firmware to try it with at the moment. :) As @veezer suggested perhaps someone can do a TCP dump of the app traffic and figure out where it's downloading the firmware from. But it's not on my roadmap.

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. :)