treczoks

Documenting the LEGO PoweredUp! System

Recommended Posts

Hi,

I'm just working on my small python-Script and I'm facing a stanage behavior of the PoweredUp-Hubs according to the documentation.
I am sending commands every 0.2 sec to change speed.
Works fine.

But after app. 100 commands motor runs continuosly with last speed.
Commands are sent, but not executed any more.

This is the command:
char-write-cmd 0x0e 0a00810016000xx0000, xx replaced  by speed

Any ideas?

 

 

Share this post


Link to post
Share on other sites

Hi,

good idea!

Logilink BT0015 or ASUS USB-BT400

Same with both
Is the a method to clear something?
 

 

Share this post


Link to post
Share on other sites
Just now, MajorAlvega said:

not sure... what python library are you using?

??

I use gatttool -I as a background process and then send the commands

But I fear that's not what you wanted to know.....

Share this post


Link to post
Share on other sites

I was suspecting that you were running linux :)
you can reset the hci device with "hciconfig -a hciX down" then "hciconfig -a hciX up". Sometimes I have problems with my Intel-based internal BLE adapter (Dell laptop) but never or almost never with my Cambrige-based USB dongle. Can you checj with "hciconfig -a" and perhaps "lsusb" what chipset you have?

Also the problem may be from Hub's side:

when this happens, after a while the link drops (the hub starts blinking and disconnects) or it stays connected?

If it stays connected then the hub is really receiving the commands and doing nothing with them.

Edited by MajorAlvega

Share this post


Link to post
Share on other sites

Hm.

Now it works....same Hub, same program.

Difference: I had removed the Dongle, and I resetted hci.
Spooky.

But thanks for your help!

 

Share this post


Link to post
Share on other sites

chipsets are not all equal
You might try taking gatttool in Interactive mode out of the equation and using system calls directly, i did that a few years ago while testing SBrick (there was no decent BLE library for python at that time):

 

from subprocess import call

...

command="gatttool -b 00:07:80:7F:28:E1 -i hci0 --char-write --handle=0x0025 --value=01"+channel+direction+dt_hexa[2:];
call(command, shell=True);

 

Edited by MajorAlvega

Share this post


Link to post
Share on other sites

Yes, that's what I did with SBrick.

just wrote a small routine to test, works fine, but only sending commands

But how to send i.E. "000f"  "0100" and get the output returned?

Share this post


Link to post
Share on other sites

hmm...  you are pushing it to the limits :)

you should really try pygatt or pygattlib and subscribe for notifications if you need to get the outputs.
I'm not a programmer but I know you can make system calls with the subprocess library and get returns but your code will became complex.

Share this post


Link to post
Share on other sites

hi, thanks.

yes, got different examples using GATT.
I'll have a closer look at those.

The idea is to read the buttons of the handheld.
+ accelerates until  you release the button
- descending until you release the button

And my programm does, if it doesnt fail for any reasons....

 

 

 

Share this post


Link to post
Share on other sites
6 hours ago, Lok24 said:

This is the command:
char-write-cmd 0x0e 0a00810016000xx0000, xx replaced  by speed

Hi @Lok24

again - I don't want to be the smart guy here - others will know much better!!!

Although I did not run into the exact same problem to the extent that things fried up, the response to violently sliding a VB6 slider control from min to max value became rather slow, when having 4 hubs connected and doing that swiftly on all 4 hubs. With one hub connected, it was all good.

What alleviated the situation a lot was a) telling my BLE client to minimize logging to the minimum amount (basically none) and b) using the "post" instead of the "write" method. Writing means - as far as I understood - that the server is transparently acknowledging each write. You can actually see that when logging is turned on: Each successful "write" is throwing the log message event "successfully wrote to characteristic …". Posting to a characteristic just sends out the request to the server and that's it. 

So when you generate a lot of bidirectional traffic, all the overhead may slow down things to the extent of freezing??? Dunno could be, could also be garbage.

When you want to keep track of these swiftly repeated power changes (0.2 s = 5/s), you could post these and then explicitly ask the server after lets say every 2 seconds, whether things are OK or not.

Oh well - just began to understand a couple of things and I am already doing as if I would by a wise guy … which is not the case at all.

All the best and good luck!
Thorsten 

   

 

Edited by Toastie

Share this post


Link to post
Share on other sites
Just now, Toastie said:

What alleviated the situation a lot was a) telling my BLE client to minimize logging to the minimum amount (basically none) and b) using the "post" instead of the "write" method. Writing means - as far as I understood - that the server is transparently acknowledging each write. You can actually see that when logging is turned on: Each successful "write" is throwing the log message event "successfully wrote to characteristic …". Posting to a characteristic just sends out the request to the server and that's it. 

 

Hi, Posting too many commands to a characterestic could flood the server resulting unexpected behavior (depending on the server device), so I think it is safer to "write" the characteristic and wait for the response meaning that the server is ready to receive a new command.

Share this post


Link to post
Share on other sites

Oh I see! Thank you very much.

Now, would it be than OK to not crank out the posted requests at highest possible speed but in a more controlled manner? For example, it does not make sense to change the power setting within ms as the device (lets say a hub) propelling e.g. train did not even have the chance to accelerate the vehicle to the new setting.

I am just curious about the overhead traffic generated with acknowledgements - this has to be somehow handled in the BLE stack/dongle whatever, right?

Best
Thorsten   

Share this post


Link to post
Share on other sites

If you want fast changes (like a fast Technic car with SBrick) you will want to send short messages and don't waste time with answers. Vengit guys implemented a shorter command format just because of that.

The Powered Up "Hub no.4" is not designed for fast Technic cars (to be honest... I still think that BT BLE itself wasn't). Probably the new "CONTROL+" announced for August will have a new kind of smart hub and maybe (just maybe) will handle it better.

But even "Hub no.4" can handle 5 to 10 commands per second. If you have several hubs at the same time you will need a BLE controller that can handle more simultanous sessions (or several BLE controllers) and an operating system that handles better those kind of operations (Windows is now better but still not really designed for that and sometimes Microsoft likes to release an hotfix that breaks everything without warning).

Edited by MajorAlvega

Share this post


Link to post
Share on other sites
1 hour ago, MajorAlvega said:

But even "Hub no.4" can handle 5 to 10 commands per second. If you have several hubs at the same time you will need a BLE controller that can handle more simultanous sessions (or several BLE controllers) and an operating system that handles better those kind of operations (Windows is now better but still not really designed for that and sometimes Microsoft likes to release an hotfix that breaks everything without warning).

Yes, I can see that! And I believe that.

Just because we had a serious and lively discussion about "OS total failures" in my group (there are a few hardcore programmers - mention Microsoft, and it begins - the volcano eruption type of discussion …:laugh::laugh:). I like to trigger that from time to time, just for fun. It >always< works.  

The ActiveX BLE control for VB6 I am using (from /n_software) does behave very, very nicely though. I do only own 4 real "Hub No.4" and one remote. The control (implemented as control array in my VB6 programs), i.e. a dedicated instance for each Hub/Handset/BLE server, works like a charm. Just for fun I extended the control array to 50 and told BLEClient(50) to connect to one of the hubs (by letting BLEClient(0) scan for mac addresses, let it catch the one for this hub and then pass this info to client #50).

At least it appears as if the Win10/64 bit OS along with this ActiveX control for VB6 does do a decent job. It may also be that with more than 5 BLE servers actually present (and not just the control array producing the 50 instances) that this all goes belly up. So far though, things are looking very good - despite the fact that this is all Microsoft stuff.

@Cosmik42 is doing his superb programming in C# … and his software is beyond believe, IMHO. I cannot imagine how much traffic his software produces - and it simply works. Have my copy of his software here for sure, learning from that as much as I can.   

So. I have to admit: I do like Microsoft stuff. Which puts me into a bad position, I know. Never really learned anything else - because there was no need. Did CP/M and MP/M in the 80's, Unix/5 in the 90's, played with Z80's and 80XX families on machine code level, loved the Sinclair ZX81/Spectrum "computers":excited: (I still have them - but the analog TV sets are dying out …) and then came Win3.11 onto my radar screen. And Word and Excel (and all this horror software, I know) in the late 90's. I am still using it today. Since 20 years … and now they gave me an ActiveX control for VB6 and I just drift on through programming heaven … before December 2018 I did not know that BLE even exists. As of today, 4 BLE Hubs automatically connect to my VB6 train control program, which is additionally handling 10 PF, RC, and RCX controlled trains, and 30 switch points. And this is Microsoft Windows crap. No that bad, I'd say.

Why did I write up all this? Don't even know. Maybe it was todays discussion. I am not affiliated with Microsoft at all. None. I am a chemist:ugh:

All the best
Thorsten 

        

          

Share this post


Link to post
Share on other sites

I am with you @Toastie :)

I love the Microsoft OS, and at this point I have over 14 Hubs connected simultaneously on my personal layout and the OS handles it like a charm.

i have never tried to use the software for Technics, but the Batman model proves the tech is ready for it.

Share this post


Link to post
Share on other sites
10 hours ago, MajorAlvega said:

If you want fast changes (like a fast Technic car with SBrick) you will want to send short messages and don't waste time with answers. Vengit guys implemented a shorter command format just because of that.

The Powered Up "Hub no.4" is not designed for fast Technic cars (to be honest... I still think that BT BLE itself wasn't). Probably the new "CONTROL+" announced for August will have a new kind of smart hub and maybe (just maybe) will handle it better.

Hi, With SBrick and BuWizz fast changes are possible because all the outputs can be controller by issuing a single command on the characteristic. Fortunately it is also possible on the PowerUp HUB and and on the Boost HUBs internal motors only. It works quite well in my BrickController2 app. The source can be found here 

Share this post


Link to post
Share on other sites

@Toastie I like your backlog :)
And I didn't say Microsoft Windows is bad (i can say that on other discussions more related to security, it's my day time job to deal with MS servers... their bad decisions pay my kids' school)... just that the Windows kernel wasn't designed for real time or direct hardware control operations - you are using VB6, i remember it was a problem to use VB6 with parallel (printer) ports, a special driver was needed for that. Not that linux is perfect or easier or whatever... it isn't, it just better feats my own needs like VB6 feats yours. I'm surprised that VB6 has support for BLE nowadays, that's an amazing feature.

Share this post


Link to post
Share on other sites
1 hour ago, MajorAlvega said:

it just better feats my own needs like VB6 feats yours.

@MajorAlvega: And this is all what counts, isn't. I like this attitude the most. It is my way of thinking with regard to Life, the Universe, and Everything.

All the best and have a very nice day!

Thosten

 

Share this post


Link to post
Share on other sites

Dear all,

I need a little help in further understanding the BLE protocol stuff.

What I did so far was using @treczoks documentation (which is my preferred reference) for getting access to the PuP Hub/Handheld. In first instance I am using the "Bluetooth LE Explorer" "App" from the MS store - it comes for free. Works very well.

After connecting and discovery etc. and having access to the "00001624 -1212-EFDE-1623-785FEABCD123" characteristic I writing the value:

0A 00 81 00 00 which is the first "fixed length part" as referenced in the official LWP 3.0 documentation. These bytes mean: (1) Message length (0x0A) - (2) as of now always 0x00 (3) Port Putput Command (0x81) - (4) I/O port - (5) startup and completion byte (encoded as bit field ssss cccc = 0000 0000 for "buffer as necessary" and "no action").

So far all is well.

But then @treczoks states: (byte 6) "Always 60, like the 51 for the RGB LEDs. If you change this, the command will not be executed." And that is true. Regardless of what I tried: 60 or nothing happens. Nowhere in the LWP 3.0 documentation "60" appears as any valid op-code or the like.

Further, the sequence following "60", which is: (7) 00 (?) - (8) Speed byte (I understood the encoding) - (9) ?? and (10) ?? need to be there or nothing happens.

In total the byte message "0A 00 81 00 00 60 00 XX 00 00" sets the motor on port A to power XX. That is cool. But why???

When following step by step the LWP 3.0 document this isn't even implemented???

Also: There is this "51" subcommand that works on he handheld but apparently not at all on the hub.

I know that I am not comprehending what is going on. @Cosmik42's software uses the "3.27.3. Output Sub Command - SetAccTime (Time, ProfileNo) [0x05]" (right? the motors smoothly accelerate to the final power setting in your software - is this the mode you are using?)

But without the (undocumented) 0x60 byte#6 I am not getting anywhere.

Any help is appreciated!

Best
Thorsten  

Share this post


Link to post
Share on other sites
4 hours ago, Toastie said:

...snip...

The official Lego documentation is unfortunate in that while it describes the wire protocol itself in great detail, it doesn't document the available commands. This makes sense somewhat, as the available commands vary by a) The hub type you're communicating with, and b) The devices plugged into that hub. It's like teaching the someone the syntax of the English language (nouns, verbs, placement, etc) without going into detail about what words are available for use.

In your case you're asking about the 0x60 command. The 0x60 command is actually a special command introduced for the Powered UP "Hub No.4". It doesn't exist on the Boost hub. It was actually introduced for the Batmobile model for a couple of special modes available in the app.

Byte (9) in your example is how long the motor should run for.

Byte (10) activates a swing mode and sets the time. It will run for the time defined in byte (9), reverse direction, and run for the time run in byte (10), before reversing direction back, etc etc. This allows the "backing up"/retreat motion activated by pressing one of the buttons.

There is another command for activating motors on the Powered UP hub:

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

This works on port 0x39, which is a special port "AB" created in firmware when it detects two motors of the same type (Train motor or M motor, NOT Boost motor). The last two bytes set the speed of each individual motor.

This command *does* exist on the Boost hub, it is used for controlling vernie, and it's also documented in the Lego documentation. It's probably also useful for controlling locomotives with two motors.

Edited by Mr Hobbles

Share this post


Link to post
Share on other sites
15 hours ago, Mr Hobbles said:

This works on port 0x39, which is a special port "AB" created in firmware when it detects two motors of the same type (Train motor or M motor, NOT Boost motor). The last two bytes set the speed of each individual motor.

@Mr Hobbles: Thank you very very much! I was rather frustrated when I could sort of handle the properties of the characteristic using the LPW document but virtually none of the output messages.

May I ask one more question: In @Cosmik42's software, upon releasing the power slider, the train motor(s) begin to accelerate for a certain amount of time and the slowly reach the final power setting. It appears as if this is what the LWP  section 3.27.3. "Output Sub Command - SetAccTime (Time, ProfileNo) [0x05]" and section 3.27.4. "Output Sub Command - SetDecTime (Time, ProfileNo) [0x06]".

This is a very nice feature particularly for trains. Is that implemented in the Hub. No4 as well? Or is a rapid succession of plain [0x60] messages from the client required to do that?

Thanks a lot in advance!

Best regards,

Thorsten

Share this post


Link to post
Share on other sites
49 minutes ago, Toastie said:

May I ask one more question: In @Cosmik42's software, upon releasing the power slider, the train motor(s) begin to accelerate for a certain amount of time and the slowly reach the final power setting. It appears as if this is what the LWP  section 3.27.3. "Output Sub Command - SetAccTime (Time, ProfileNo) [0x05]" and section 3.27.4. "Output Sub Command - SetDecTime (Time, ProfileNo) [0x06]".

 This is a very nice feature particularly for trains. Is that implemented in the Hub. No4 as well? Or is a rapid succession of plain [0x60] messages from the client required to do that?

I must admit I haven't tried these commands yet, as the LWP document was released after I implemented my own motor ramp in the node-poweredup library, which, as you say, works by issuing a rapid succession of motor commands. 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! :)

Edited by Mr Hobbles

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.