Mr Hobbles

For completeness sake, I've discovered how to get the firmware revision from the WeDo 2.0 Smart Hub too. As usual, it's completely different. BLE Service 0x180a, Characteristic 0x2a26 freely reports requesting the firmware revision as a string. My hub reports [0x31, 0x2e, 0x30, 0x2e, 0x30, 0x39, 0x2e, 0x30, 0x30, 0x30, 0x30], which is simply "1.0.09.0000". In fact, service 0x180a and characteristic 0x2a26 are standard parts of the BLE spec. It was nice when TLG followed specs. :) https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.device_information.xml https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.characteristic.firmware_revision_string.xml I doubt the revisions of this are related to that of the Boost/PUP hubs though as the firmware is clearly different. It's likely a completely different project (read: older) within TLG.

Thank you for this! I was having trouble grokking the format used in the firmware reports. :) FYI, here's what one of my PUP Hubs reports: 1.0.03/0000 Here is one of my PUP Remotes: 1.0.00/0004 And here is one of my Boost Move Hubs: 1.0.00/0547 Not sure what exact functionality you're looking for, but [0x03, 0x00, 0x02] seems to force a disconnect from the hubs side. But it doesn't turn it off - so it immediately goes back into searching mode, and if you're still scanning, you'll reconnect a second or two later. Usually though I just disconnect from my side and let the hub turn itself off. :)

Maybe...in my preliminary testing there's a command to retrieve it, but I'm unsure of the format of the returned data. Also the command doesn't seem to work on the Boost Move Hub. More testing required. :)

As a follow up, as promised, I tested your problem out this evening, and, can confirm, it happens to me too! So, the bug is not just limited to Boost motors, but to both the Boost motor and Boost color sensor too. So: Plugging 2x Boost devices into a PUP Hub will crash it and cause it to restart. :) 1x Boost device (and any other device) should work fine.

The PUP motors and hub have this built in, this is what speed value 127 triggers (As opposed to value 0, which lets the motors float to a stop).

2x WeDo motors work fine as they are an output device only. Same with LED lights and train motors. All multiplex to port AB fine with no issues. It is only Boost motors that cause issues as they are an output device (you can sent motor drive commands to) and an input device (you can receive rotation angle notifications from) at the same time.

Glad you found the library useful! That's a very good point though, I don't have an example for the Duplo train yet, and I don't document the motor strings in use (Sidenode, it's "MOTOR" as opposed to "A" or "B" because it's not a port that can be unplugged or replaced with something else). I'll add it to my to-do list for this week to dig out my Duplo train and make an example. :)

Yes, that *might* be related to the existing bug you mention, but I'm not sure. The PUP Hub has two ports, port A and port B, that you can individually send commands to. When you plug in two identical devices (eg. two train motors or two led lights), internally, the hub creates a new virtual port, AB, that you can send a single command to, to control both motors at the same time. The problem is, that Boost motor is both an output device *and* and input device, so when it tries to create the virtual port, it crashes, as multiplexing two input devices doesn't make sense. :) Apparently Lego will fix this in the future, but they haven't yet. So, in your case, plugging in a Boost motor and a Boost sensor would be two input devices, but I don't think it should try to multiplex them though, as they aren't identical devices (they have different device ids). I'll do some testing tonight to see what it does, just out of curiosity. :)

Speed value 127 is a hard stop/"brake". :) Obviously there will still be a bit of a "float" depending on the weight of the train and the speed it is going, but it's the closest you'll get without using sensors and a slowly decreasing speed to stop at an "exact" spot.

Thanks for the run down! Seems like a very cool system. :)

I am very intrigued with this! Can you describe the mechanism/parts a bit more? Do you use Lego 9v track? How do you connect the wheels to the battery box (PF I presume)?

Right, all that may be true, but the thread title is "Rechargeable batteries for powered up hubs". I think it's important to point out that one can use standard rechargeable batteries without needing to modify your battery box or risk blowing your battery box by using too many LiPo's. NiMH rechargeable's are commonplace and provide a perfectly reasonable almost-as-good solution without risk. However if you do want to use LiPo's, @Giottist's research and solution is awesome! :)

I have to back that up - I've used both Eneloop and GP ReCyko Pro rechargeable AAA's and AA's over the years with no issues. I use both a GP ReCyko charger and a cheap 16 bay one I got from Amazon. I get a few hours (maybe 3ish?) from my Powered UP trains per charge and then I charge them again. Quite convenient. I have no idea about their mAh properties, I've never cared - they just work. :) I pop six of them in a hub like any other battery and off I go.

Yes, and yes. :) A Boost Motor will work on a Powered UP hub, but does not support angle rotation or reporting the angle rotated. It allows speed control only. Boost Sensor is fully supported on Powered UP hub. Powered UP motor is fully supported on a Boost Move Hub. (All this is only true when used with third-party non-LEGO software to talk to the hubs)

Pardon my ignorance, but why not use normal AAA rechargeables? I have about 60 Eneloop's I use with my Boost, Powered UP and WeDo 2.0 hubs with no issues.

Yeah, in fact there seem to be several references to the hardware being LPF2 (Lego Power Functions 2), as also referred to on the replacement pieces website. Interesting that the BLE protocol is called Lego Wireless Protocol 3.0 - I wonder what 1.0 and 2.0 were?!

Now THIS is something I’m very happy to see! A lot of useful information in here! I’d suspected there was a bit more to peripheral subscription modes, but wasn’t quite sure how to find out. I also didn’t realize that you can set individual motor acceleration curves. I’m eager to try all this when I get back to my PUP components in the new year. I also now wonder of this is implemented on each hub (The PUP hub and Move Hub don’t seem to implement everything the same for example) I’d also like to see some documentation for the individual peripheral commands rather than just the BLE wire protocol. Either way, I’m very happy that this is out there, and especially on GitHub. :) Such a great sharing platform.

Most of the voltage and current readings I've estimated based on whats looks reasonable, as I haven't done any measurements with a voltmeter. :) If you have a better formula, I'll take a look! I have access to all the hardware as I've bought it, but I have no inside links within Lego for information about the hardware. It's all reverse engineering. I also worked with Jorge, as well as a few others as mentioned in the credits - we have a mostly quiet Slack chat we use when new hardware is released! Yes, virtual port 57 only appears when two identical *motors* are installed. This allows you to send a single motor command and drive both at the same time (Different from command 0x60, which allows you to control both ports independently in a single command). Note there is an oddity: if you plug in two Boost motors, the PUP hub fully crashes (blinky lights, disconnect, reset). I don't think it properly knows how to handle a device that is both a motor and a sensor at the same time.

Nice documentation! I like the style, very traditional network protocol style which I find very easy to read. It’s good to have it all written down somewhere. :) You may be interested in this Node.js library I’ve been working on, which provides most of the documented functionality, and brings compatibility between WeDo 2.0, Boost, Powered UP, and the Duplo Trains - https://github.com/nathankellenicki/node-poweredup

My own WeDo 2.0 hubs that have updated (quite a few times) in the past from my Windows 10 app.

It actually does, LEGO has constantly released new firmware for it through the WeDo 2.0 apps. I think the crux of the problem though is that it functions so very differently from the Boost Move Hub and PUP Hub. The Bluetooth protocol is totally different. To make it compatible would not only require a new firmware, but changing all the WeDo 2.0 software out there to make it compatible with a WeDo 2.0 Hub with updated firmware. It would be a LOT of effort for them, so I understand them not wanting to do it.

It's interesting that they've released the Boost Move Hub seperately. I wonder if there'll be a firmware update that makes it compatible with the Remote Control. Also, I hope they've fixed that bug with the normal Hub that causes it to crash when two Boost Interactive Motors are plugged in. :)

I don't think they will ever be "finished", that's too definitive a close to put on the line. Instead, I think the current sales of the line don't warrant a new one every 1 or even 2 years. It may be a few years until we see another one. Whenever Lego deems the time to be right. The exceptions being that, as Jamie Berard said, if there's an opportunity to cross a train with another theme or idea. The Winter Village train, Harry Potter trains, etc.

Actually the port multiplexing already exists on both the Boost Hub and the Powered UP Hub. On the Boost Hub there is a virtual port "AB", which you can send commands to, and it will set that command on both port "A" and "B" at the same time. I actually haven't tested this with ports "C" and "D" though! I might do that this evening. On the Powered UP hub a virtual port "AB" is created internally when you plug in two devices of the same Auto ID. However, it currently crashes the Hub if you plug in two sensors (Boost Color/Distance, WeDo 2.0 Distance/Tilt) or Boost Interactive Motors. I guess there is something here incompatible with sensors as it doesn't expect them to be plugged in, so with two it crashes. With motors it works though. If you plug two train motors in you can control both with a single command on port "AB" (even in opposite directions). For example when you use the Batmobile app with the slider mode for the wheels, it actually sends a single command to port "AB" to control both wheels at the same time.

I didn't mean to say that's what you were suggesting, I was merely saying it seems like it was different somehow rather than broken, perhaps a different/older firmware as you suggest. :) Apologies if I caused offense!