Powered Up - A tear down...

[Mr Hobbles]

I've discovered in my testing that after you change the Boost Move Hub's name using the Boost app, it changes the advertised BLE localName. This means that there's no way to reliably tell a Boost Move Hub apart from a Powered Up Hub or Remote in code, as the service UUID's are also the same, and the local name can't be relied upon.

Is there something I'm missing? I assume the Boost and Powered Up apps refuse to connect to Hubs of the wrong type but I can't test yet as the trains aren't released for another three days (local shops don't have them yet). I can probably tell the Hubs apart after an initial connection by watching the port advertisements, but that requires connecting first, then disconnecting if its the wrong type.

[Jetro]

6 minutes ago, Mr Hobbles said:

This means that there's no way to reliably tell a Boost Move Hub apart from a Powered Up Hub or Remote in code

Have you been able to test with a Powered Up hub to see if it advertises in the same way?
Does the whole localName change or only a section of the localName?
Is the localName the only piece of code that is advertised or are there other chunks of data that might indicate a hub type? So far we have WeDo, Boost and Powered Up hbs and no matter how I change my WeDo or Boost hub name, the Boost app will never detect a WeDo hub the WeDo app doesn't "see" the Boost hub either.

[Mr Hobbles]

17 minutes ago, Jetro said:

Have you been able to test with a Powered Up hub to see if it advertises in the same way?
Does the whole localName change or only a section of the localName?
 Is the localName the only piece of code that is advertised or are there other chunks of data that might indicate a hub type? So far we have WeDo, Boost and Powered Up hbs and no matter how I change my WeDo or Boost hub name, the Boost app will never detect a WeDo hub the WeDo app doesn't "see" the Boost hub either.

The whole localName changes. There is also a manufacturerData string, which I assume is a unique ID for Lego and probably consistent between hubs (I'll check on my WeDo 2.0 hub tonight).

I don't have a Powered Up hub or remote yet, I'm going by the information given to me earlier in the thread. But once I get one in a couple of days I'll try and see what else is different.

The WeDo 2.0 and Boost Hubs are quite different in how they work (although they support mostly the same LPF2 components). WeDo 2.0 advertises with a service UUID of "000015231212efde1523785feabcd123", whereas the Boost Hub advertises with a service UUID of "000016231212efde1623785feabcd123" (Notice the 5 or 6). Also the wire protocol is quite different. You can tell this without connecting the hub, merely looking at the advertised data during discovery.

@JopieK stated earlier that the PU hub and remote both advertise under the same service UUID as the Boost hub so I was hoping to rely on the localName, but given this can be changed by users, I'll have to rely on something else.

After you've connected to the hub, the hub blasts a whole bunch of messages to you. One of those messages tells you about what ports are available on the device, so this will definitely be different between the hubs. But this requires connecting first, it can't be determined during discovery.

Edited June 28, 2018 by Mr Hobbles

[JopieK]

I must have misread the UUID then ;) I did not do a diff on the UUID's! Makes it easier though! I hope to be able to obtain a Boost set next week (and an extra train), would be a nice summer holidays project to work further on it. Interesting to hear that there are indeed differences. Now we need to wait till new UP products will be released (e.g. the Batman set) to get a better insight in what LEGO has planned for us. EV3 is also nearing the end of it's cycle so who knows it will also evolve in a Boost and/or UP compatible system.

[Mr Hobbles]

14 minutes ago, JopieK said:

I must have misread the UUID then ;) I did not do a diff on the UUID's! Makes it easier though! I hope to be able to obtain a Boost set next week (and an extra train), would be a nice summer holidays project to work further on it. Interesting to hear that there are indeed differences. Now we need to wait till new UP products will be released (e.g. the Batman set) to get a better insight in what LEGO has planned for us. EV3 is also nearing the end of it's cycle so who knows it will also evolve in a Boost and/or UP compatible system.

Could you paste the service UUID of the Powered Up Hub and Remote? :) Also the manufacturerData string if you can get it.

The back of the Batmobile box did the rounds a few days ago, seems the contents are the Powered Up Hub (same from train) and two WeDo 2.0 motors.

[JopieK]

public struct BLEHelper {
     let serviceUuid          = CBUUID(string: "00001623-1212-EFDE-1623-785FEABCD123")
     let characteristicUuid   = CBUUID(string: "00001624-1212-EFDE-1623-785FEABCD123")
     let deviceNameHandset = "Handset" // -> train remote controller
     let deviceNameHub = "HUB NO.4"  // -> train motor receiver HUB
}

(I don't have the manufacturerData right now).

Brickset has some nice info indeed on the Batman set: https://brickset.com/article/36853/powered-up-motors-first-look

[Mr Hobbles]

20 minutes ago, JopieK said:

public struct BLEHelper {
     let serviceUuid          = CBUUID(string: "00001623-1212-EFDE-1623-785FEABCD123")
     let characteristicUuid   = CBUUID(string: "00001624-1212-EFDE-1623-785FEABCD123")
     let deviceNameHandset = "Handset" // -> train remote controller
     let deviceNameHub = "HUB NO.4"  // -> train motor receiver HUB
}

(I don't have the manufacturerData right now).

Brickset has some nice info indeed on the Batman set: https://brickset.com/article/36853/powered-up-motors-first-look

Thanks for that. It does indeed look like the service UUID's are the same. And given that the local/device name can be changed by users in the official apps, we can't rely on those to tell the difference between the PU Hub and Boost Hub. I wonder if the manufacturer data is different.

Re. the Batman set, indeed, just a PU Hub and 2x WeDo 2.0 motors. It explains why the remote is not bundled with it - it is not capable of driving those motors in the fashion the app does. As the WeDo 2.0 motors have the same type as the train motor, pressing up/down on the remote would increase/decrease speed, rather than only turn them on for as long as the button is held.

Edited June 28, 2018 by Mr Hobbles

[JopieK]

You never know if a more advanced remote, capable of controlling the two motors will be available later on.

[Jetro]

Or maybe there is a different firmware version depending on how you want to use the hub (train or RC).

[JopieK]

Yup, that would be a good solution I think.

[Mr Hobbles]

I got my hands on the Cargo Train earlier! First thing I did, take out the Hub, and start hacking away. Things I've discovered.

1. As @JopieK said, service ID is the same.

2. manufacturerData is *different* between the powered up remote, powered up hub, and boost move hub. Byte 3 appears to be the type of the hub. Boost is 0x40, Powered Up Hub is 0x41, and Powered Up Remote is 0x42.

3. Train motor is *not* the same as the WeDo 2.0 motor! It has ID of 0x02, whereas WeDo 2.0 motor is 0x01 as previously reported.

4. I've managed to get all the Boost and WeDo 2.0 sensors working! In fact they pretty much worked out of the box, It's the exact same protocol as Boost.

5. I haven't yet figured out how to control the LED, or detect button presses on the remote.

I'll be publishing my code shortly.

EDIT: Also note, as a result of the WeDo 2.0 motor having a different ID, the Remote *does* behave properly out of the box (ie. app-powered Batmobile style). As long as your finger is on the button, the motor goes. When you let go, it stops.

Edited June 30, 2018 by Mr Hobbles

[Jetro]

Making progress!!

[JopieK]

Today I received the Boost color sensor and like I expected (especially because of this topic) the train hub works also with the color sensor:

See the Boost commands: https://github.com/JorgePe/BOOSTreveng/blob/master/ColorDistanceSensor.md they work exactly the same.

I really like this option. Like the setup from @dr_spock we did something like that a few years ago by controlling the motor of the train with an on-board Arduino with color sensor, but now we can do this with LEGO only options. This is especially useful for educational purposes, you only need a train, about 20 bucks for a color sensor and a few extra bricks and can make an intelligent train! I'm working on teaching materials for it (using Swift playgrounds), as soon as I have something concrete I will share it of course. Meanwhile I have added color sensor support in the train control app for iOS (I did not push this version to GitHub / App Store yet since it still needs work). 

[Mr Hobbles]

17 minutes ago, JopieK said:

Today I received the Boost color sensor and like I expected (especially because of this topic) the train hub works also with the color sensor:

Woo hoo, it's very exciting isn't it!

I've uploaded a YouTube video of the simplest example I could think of: 

 

[JopieK]

Yups it works very well @Mr Hobbles LEGO did a great job there, we couldn't get it working that well when using our own hardware (with high school / college students). Fortunately it will even fit under the locomotive of 60198 so without a lot of change people can integrate it into their own sets, luckily the sensor is not a big brick but has an L-shape.

 

[Mr Hobbles]

Annnd I've sussed out the remote. :) Port 0x00 appears to be the buttons on the left hand side, and 0x01 is on the right. They are advertised as sensor type 0x37. Activating the sensor with mode 0x00 begins button press notifications, emitted from the remote as standard sensor messages.

Edited June 30, 2018 by Mr Hobbles

[JopieK]

Great to hear, that allows even for much more possibilities! How do you get the remote to report back to your software? Do you send it a sensor message just like with the color sensor (e.g. [0x0a, 0x00, 0x41, port, sensorMode, 0x01, 0x00, 0x00, 0x00, 0x01])?

[Mr Hobbles]

5 minutes ago, JopieK said:

Great to hear, that allows even for much more possibilities! How do you get the remote to report back to your software? Do you send it a sensor message just like with the color sensor (e.g. [0x0a, 0x00, 0x41, port, sensorMode, 0x01, 0x00, 0x00, 0x00, 0x01])?

Exactly. Port 0x00 for left, 0x01 for right, sensorMode 0x00. You start getting 0x45 notifications (same as color sensor), and byte 5 is the button state. Button states are: x01 up pressed, 0xff down pressed, 0x7f stop pressed, 0x00 released (Looks like 0x00 is emitted for release regardless of which button was pressed. If you want determine what button was released I guess you need to maintain state somewhere in your application as to the last pressed button).

Did you manage to get the remote's LED color to change? The hub was simple, works the same as the boost hub, but the remote LED appears to be different.

Edited June 30, 2018 by Mr Hobbles

[JopieK]

Yups. But that is typical, one also would need that with what item is attached to what port since a disconnect message also seems to be generic (same for motor and sensor). Very nice find, how did you reach that solution (just trying I guess?)? Seems LEGO keept all items basically the same!

[Mr Hobbles]

23 minutes ago, JopieK said:

Yups. But that is typical, one also would need that with what item is attached to what port since a disconnect message also seems to be generic (same for motor and sensor). Very nice find, how did you reach that solution (just trying I guess?)? Seems LEGO keept all items basically the same!

The benefits of a standard protocol! LEGO has really thought this through.

Pretty much guessing. When the hub connects it advertises all its ports, and what device (if any) is connected to it. The remote advertises 5 when it powers up, 0x00, 0x01, and three others. I have no idea what the other three do right now. Maybe one is the LED? But that's inconsistent to how the LED works on other hubs). One of them also has an "attached" id 0x38, which is interesting as the buttons are 0x37, so it might be some other functionality of the remote?

I then decided to fire off a standard port activation message, starting at 0x00, and moving upwards if I got no notifications. Luckily, 0x00 worked perfectly. :)

Edited June 30, 2018 by Mr Hobbles

[JopieK]

The LED works exactly the same as the one of Boost, so I don't think it is used for that. I don't see any other sensors, would be cool if LEGO would have a motion sensor in it but I'm pretty sure they don't.

[Mr Hobbles]

46 minutes ago, JopieK said:

The LED works exactly the same as the one of Boost, so I don't think it is used for that. I don't see any other sensors, would be cool if LEGO would have a motion sensor in it but I'm pretty sure they don't.

On the remote? The LED on the hub works the same as Boost hub, but I haven't figure out how to control the remote's LED yet. The 5 ports I was talking about are what the remote reports (2 are the buttons).

Edited June 30, 2018 by Mr Hobbles

[JopieK]

Ah, no I meant the hub indeed... 

[Lok24]

13 hours ago, Mr Hobbles said:

Woo hoo, it's very exciting isn't it!

I've uploaded a YouTube video of the simplest example I could think of: 

 

This is really amazing!

[technic70s]

Being able to connect a colour sensor is fantastic, we will be able to set up a tram that travels down the end of a line, stops and then reverses back down the track to repeat over and over again. Awesome!!!!