Documenting the LEGO PoweredUp! System

[treczoks]

2 hours ago, Lok24 said:

I do the ramp by single steps too (raspberry PI, python)

This is actually not necessary. The Smart Hub has two very interesting features here: a) a "ramp" command to gradually change to a target speed, and b) the ability to queue commands. So you can e.g. send a command to "ramp up to 50%", followed by a "run at 50%", and it will ramp up and stay there automatically.

Details will follow - as soon as I have time to work on my documentation again.... ;-(

[Cosmik42]

3 hours ago, Mr Hobbles said:

I can't speak for @Cosmik42, but as I think his software was also released before the document came out, and he's said in the past that portions of it were inspired by node-poweredup, I'm guessing he uses the same method. If he does in fact use the new method, I might steal that in return as I haven't implemented it yet! :)

You are correct :) I am using a similar method as yours. But with the official documentation it should be easy to figure this out!

I won't be implementing it because my abstraction layer works for many other devices and this one is too hardware specific. So I won't be able to give you that bit of code @Mr Hobbles, but I don't desperate to send you back the elevator somehow :)

Edited February 15, 2019 by Cosmik42

[Mr Hobbles]

1 hour ago, treczoks said:

This is actually not necessary. The Smart Hub has two very interesting features here: a) a "ramp" command to gradually change to a target speed, and b) the ability to queue commands. So you can e.g. send a command to "ramp up to 50%", followed by a "run at 50%", and it will ramp up and stay there automatically.

Details will follow - as soon as I have time to work on my documentation again.... ;-(

Have you managed to get the ramp working? I've been trying to grok the official documentation around the accel/decel profiles this morning, but finding it a bit hard to follow in places. My hubs throw errors regardless of what bytes I throw at them. :)

I've got the queue working, but the hub has a limited buffer, so without the ramp command its difficult to use for ramping up through individual steps.

Edited February 15, 2019 by Mr Hobbles

[Toastie]

1 hour ago, treczoks said:

This is actually not necessary. The Smart Hub has two very interesting features here: a) a "ramp" command to gradually change to a target speed, and b) the ability to queue commands. So you can e.g. send a command to "ramp up to 50%", followed by a "run at 50%", and it will ramp up and stay there automatically.

That is very exciting. Particularly because it does not create that significant amount of BLE traffic. Looking forward to read your updated document!

42 minutes ago, Cosmik42 said:

You are correct :) I am using a similar method as yours. But with the official documentation it should be easy to figure this out!

Well - as Mr Hobbles said: The LWP documentation does not document all the commands very well. the 0x60 command isn't even mentioned. 

8 minutes ago, Mr Hobbles said:

Have you managed to get the ramp working? I've been trying to grok the official documentation around the accel/decel profiles this morning, but finding it a bit hard to follow in places. My hubs throw errors regardless of what bytes I throw at them. :)

Same here. My Hubs No. 4 don't do anything when using the "advanced" LWP protocol message byte coding (I believe). I am using the MS Bluetooth Explorer for that, which does a fairly good job (at least I believe) ...

All the best,
Thorsten

 

[Lok24]

9 hours ago, treczoks said:

This is actually not necessary. The Smart Hub has two very interesting features here: a) a "ramp" command to gradually change to a target speed, and b) the ability to queue commands. So you can e.g. send a command to "ramp up to 50%", followed by a "run at 50%", and it will ramp up and stay there automatically.

Details will follow - as soon as I have time to work on my documentation again.... ;-(

Sending single commands you can easily use another characteristic than linear....

Edited February 16, 2019 by Lok24

[Toastie]

On ‎2‎/‎15‎/‎2019 at 2:42 AM, Mr Hobbles said:

[0x08, 0x00, 0x81, 0x39, 0x11, 0x02, 0x20, 0x20]

@Mr Hobbles:

Even that does not work on any of my four hubs. The notification reply is: [0x05, 0x00, 0x05, 0x81, 0x06]

Does that mean anything to you?

Thanks and best regards,
Thorsten

[veezer]

After a fair bit of experimentation, I actually don’t think the train motors support the accel/decel profiles. It was fairly straightforward to get those working with the Boost hub internal motors, so I don’t think it’s an issue with the commands. Rather, I think the train motors are rather dumb; they can’t report back speed and tach position like the the other motors. Might be one of the reasons the built in ramp profile commands return errors with train motors. I’d love to be proven wrong though!

[Lok24]

Hi @veezer,

you need in any case different commands for the differents motors!

Edited February 24, 2019 by Lok24

[XG BC]

9 hours ago, veezer said:

After a fair bit of experimentation, I actually don’t think the train motors support the accel/decel profiles. It was fairly straightforward to get those working with the Boost hub internal motors, so I don’t think it’s an issue with the commands. Rather, I think the train motors are rather dumb; they can’t report back speed and tach position like the the other motors. Might be one of the reasons the built in ramp profile commands return errors with train motors. I’d love to be proven wrong though!

the train motors definetely dont have tachs in them they just have a slightly different motor than the pf one in them and the id board with the resistors and a self resetting fuse in them.

XG BC

[veezer]

@Lok24  I was commenting on the fact that someone mentioned that the commands setting acceleration and deceleration profiles (0x81 subcommand 0x05/0x06) apply to the train motor.  I don't believe that is the case.

[imurvai]

Have you guys realized that something has changed on the control protocol? I just updated the firmware of my PU hub and can't control it anymore. The connection itself still works though.

[Toastie]

@imurvai

yes, it now works in full accord to the LWP3.0 document.

See here (close to the end):

Best,
Thorsten

 

[imurvai]

23 minutes ago, Toastie said:

@imurvai

yes, it now works in full accord to the LWP3.0 document.'

Ah ok, I managed to operate the PUP hub outputs separately. Do you know if there is still an option to operate both outputs by issuing a single BLE command? It used to be '0x08, 0x00, 0x81, 0x39, 0x11, 0x02, 0x00, 0x00' where the last two bytes defined the output levels. 0x39 as port id is no longer working apparently.

[Toastie]

Well, I am not the expert here, just learned from others.

@Mr Hobbles is pretty much the one who knows it all and @Cosmik42 makes everything just work.

As far as I understand, the hub does no longer send the virtual port ID when two identical devices are attached to the two I/O ports, now you have to ask for that one. It is always 0x10 on my hubs but I am requesting a pairing with "06 00 61 01 00 01". I the get the virtual ID as reply, which I then use with the "StartPower(Power1, Power2) sub command (02) "08 00 81 VirtualPortID 00 02 Power1 Power2".

But you have to ask the experts for in-depth information! I just had some spare time riding an IC train from Hamburg to Düsseldorf

Best
Thorsten 

[imurvai]

Ah ok, so I need to create a virtual port. I'll try that... Thanks for the info.