JopieK

Powered Up - A tear down...

Recommended Posts

32 minutes ago, Lok24 said:

The only thing that doesn't work is my Boost App with Win 10.

Have you updated to the latest version? Stability has improved over time...

Share this post


Link to post
Share on other sites

Hi,

 

Updatet what ? Windows or Boost?

Windows is on 1803, for Boost you can't tell.

I assume 1.8.x, but shown is still 1.7.1

Have a look at the other users on the Microsoft site.

Edited by Lok24

Share this post


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

The steps to change the name of the hub (saved in flash memory) from the App
https://itlug.org/forum/topic/7615-lego-poweredup-aka-power-functions-20/page/3/?tab=comments#comment-75176

P.S. Sorry for the external link, but i don't have the possibility to upload picture here (Max total size 0.01MB for upload)

You can copy the image location of each picture from the itlug.org site and paste the link in your message here.  It should pull in the pictures.

2025005503_WhatsAppImage2019-04-19at10_5

334849869_WhatsAppImage2019-04-19at10_53

99146260_WhatsAppImage2019-04-19at10_53.

 

Share this post


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

So just assume I am rather old and a little slow. I have a few questions:

  • The lastest LPF2 documentation is the "LEGO Wireless Protocol 3.0.00 Doc v3.0.00 r17 documentation" (Dec 2018) right? I am trying to follow the LPF2 stuff on EB, but the Boost this and Move that, along with Spike here and Prime there, Hubs, PoweredUp and whatnot is (for me) getting tough. I don't have all these devices, just plain vanilla "Hub.No4s". TrainTech has several threads on that, Mindstorms as well, and there is Cosmik, who just fixes things over night when he is travelling and some of you guys were getting nervous:tongue:.
  • Is there a way to update Hub.No4's firmware (what is this box called correctly?) without using the stupid LEGO app? Reason: I don't have a smartphone (believe it or not, but the world is still spinning, I can read printed maps, Google maps, know what time it is, can do SMS on my steam-operated cell phone, know the protocol of TCP/IP, somehow managed to work with BLE … and frequently use Skype for Business to to talk to people quite far away). If not, then I'll ask my wife to download the stupid app, but this is not as it should be; I believe none of you guys are running your fantastic automated layouts from your cell phone ...

Thanks for your help!!!

Best wishes,
Thorsten       

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.

Share this post


Link to post
Share on other sites
7 minutes ago, Mr Hobbles said:

You can plug a Boost motor into a WeDo 2.0 hub and it'll recognize it.

Have you confirmed that? I was under the impression the possibility to update the firmware on the WeDo 2.0 hub made it impossible for that hub to recognise and deal with components that were developed later 

Share this post


Link to post
Share on other sites
2 minutes ago, coinoperator said:

Yeps...
Since the update this is possible, I tried it and it worked.

Using what software? The Powered Up app won't allow it. 

Share this post


Link to post
Share on other sites
38 minutes ago, Jetro said:

Have you confirmed that? I was under the impression the possibility to update the firmware on the WeDo 2.0 hub made it impossible for that hub to recognise and deal with components that were developed later 

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.

Edited by Mr Hobbles

Share this post


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

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

Thank you @Mr Hobbles for the insightful comment. As more details emerge, I feel Lego is coming out with a wonderful set of new electronics hardware.

Lego's software has never been great ... hence the complex software, acronyms, and marketing names for the various products is not surprising.

The smaller children and younger teens will probably stick to one kind of product, like boost, but the older kids and adults will try to mix and match. For the latter a "real" programming language like python will be absolutely great. And it will work irrespective of which hardware is being used !

I am looking forward to the emergence of this potentially great ecosystem. It will unleash a new wave of creative and ingenious creations.

I believe Lego will do great service if they formally support the various open source efforts by fans. They can help in various ways like finance, hosting multi platform test frameworks etc.

Share this post


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

Lego's software has never been great ...

My experiences with the mindstorms software couldn't be better.

1 hour ago, iLego said:

 ... hence the complex software, acronyms, and marketing names for the various products is not surprising.

The smaller children and younger teens will probably stick to one kind of product, like boost,

Boost ist not a "kind of product", and none of the electronic compenents in the Set named "Boost" or other components are called "Boost" in any form.
It's not that confusing if names are used properly.

"Boost" is a Set,
"MoveHub" is an electronic component, belonging to the PoweredUp-familiy (because of protocol and connectors), and
it is contained  in the Boost-Set, but it's never called Boost-Hub.

 

Edited by Lok24

Share this post


Link to post
Share on other sites
On ‎4‎/‎13‎/‎2019 at 12:28 AM, Mr Hobbles said:

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.

@Mr Hobbles

(SORRY: Just found out I believe!!! Don't waste you time here)

I have never used the virtual port before - so I am a bit confused of what to do to do so:blush:

Updated the hub firmware with the help of my daughter's smart phone (only one hub, as I may screw up entirely …) Check.

I understood on how to change from the 81/60 output command (just copied that from somewhere and never understood what was going on) to the 81/51 as documented for one output/motor/Hub LED etc. Works well. Check. 

Also 81/01 (01 = "N/A" in the LWP3 protocol document, right?) works well.

I do get the appropriate messages from the hub (I only have the 2I/O version) when devices are attached/detached.

From what you have posted before, I would like to try to combine both hub outputs:

First send the combine command: 06 00 61 01 00 01 (is that correct? I believe now it is, there there is the port notification, right?)

An output command to turn both motors on would be: 08 00 81 ?? 00 02 XX YY (XX = power 1, YY = power 2, ?? = PortID, is that correct? YES, from hub)

My question is: How do I find out the PortID for the virtual port? Is there a reply from the hub when I connect both outputs? YES THERE IS

Thank you very much in advance!

Best regards,

Thorsten    

    

Edited by Toastie
first think then ask

Share this post


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

@Mr Hobbles

(SORRY: Just found out I believe!!! Don't waste you time here)

My question is: How do I find out the PortID for the virtual port? Is there a reply from the hub when I connect both outputs? YES THERE IS

   

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

Share this post


Link to post
Share on other sites

@Mr Hobbles

Thank you very much!

Quick question: After updating one of my 2I/O hubs to new firmware, I noticed that a) the battery level notification comes in immediately (after subscribing and requesting the update) but then b) I don't see any further updates. The RSSI level is (as before firmware update) sent out about every second, depending on BLE traffic. With the old firmware, the battery level was provided every ten seconds or so.

I believe not notifying the battery level every 10 s is very reasonable to decrease BLE traffic, as the battery level simply won't change permanently within 10 s. In the even of e.g. stalling a motor, the over current alarm event is thrown - it does thus not make sense to monitor the (then) temporally decreasing voltage level as well with high temporal resolution.  

Is that so or do I screw up on reading out the hub notifications?

(Reason for asking: I am rewriting my VB6 code so that the BLE value event "only" populates a stack with corresponding stack pointer change - but does not do any "data interpretation" as before. That is moved to a timer driven event routine, which processes the stack asynchronously. Well the value event is thrown asynchronously whereas the timer runs with fixed intervals of course. I just want to make sure that I don't miss any hub data. Attachment/detachment I/O events are very well captured. Monitoring the value event though just shows I/O and RSSI updates) 

Best wishes
Thorsten

Share this post


Link to post
Share on other sites
On 4/26/2019 at 4:12 PM, Toastie said:

Quick question: After updating one of my 2I/O hubs to new firmware, I noticed that a) the battery level notification comes in immediately (after subscribing and requesting the update) but then b) I don't see any further updates. The RSSI level is (as before firmware update) sent out about every second, depending on BLE traffic. With the old firmware, the battery level was provided every ten seconds or so.

I believe not notifying the battery level every 10 s is very reasonable to decrease BLE traffic, as the battery level simply won't change permanently within 10 s. In the even of e.g. stalling a motor, the over current alarm event is thrown - it does thus not make sense to monitor the (then) temporally decreasing voltage level as well with high temporal resolution.  

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.

Share this post


Link to post
Share on other sites
27 minutes ago, Mr Hobbles said:

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.

I was assuming the same. And I believe it is like that. I can't find it for some reason (is it just me or are any of you getting sometimes fuzzy as well when browsing the document? It is getting better as I am getting used to the intrinsic logic - which is - from my point of view - simply brilliant. I like the approach they're using very much) , but somewhere in the LWP3 documentation the threshold for such events are/can be declared/defined.

I believe I used a hub where the batteries were running low on purpose (as I could then test the little graphical things happening, e.g. when stalling a motor.). So the battery data on that one were changing gradually over time.

I believe also that the RSSI level is sent out on a more regular schedule as that one is more critical with regard to running out of range. And maybe the RSSI raw signal is simply much more jittery so it appears as if the hub just sends them out more often.

Thanks for your reply though. I really appreciate that.

Stack stuff is working now - I don't miss barely any event type message now, even when running VB6 in full debug mode.

All the best
Thorsten   

Share this post


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

I believe also that the RSSI level is sent out on a more regular schedule as that one is more critical with regard to running out of range. And maybe the RSSI raw signal is simply much more jittery so it appears as if the hub just sends them out more often.

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.

Edited by Mr Hobbles

Share this post


Link to post
Share on other sites
On ‎4‎/‎29‎/‎2019 at 10:13 PM, Mr Hobbles said:

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?

Well, I don't really have/don't know how to get direct access to the Bluetooth stack on my laptop (w/ built-in radio) as I am using a Vb6 ActiveX control from /n_software. When scanning I can read out the RSSI level reported from the control for every device - upon connecting that stops.

So I did that - and also used the Win10 BLE Explorer app. Both deliver (with high rate) RSSI level data, that jitter (a lot) around a mean value. When comparing that to RSSI data from the hub, these are much smoother (guess via averaging by the hubs firmware) and are in the same ballpark. As these data are apparently remotely reflecting the signal strength on a dB scale, the result is actually almost identical. There are some differences but that does really not matter.

But as said, I need to get the RSSI levels from the hub, as I don't get them form my laptop directly, when connected to the BLE device. The levels are reported  by the hub as rather smooth signed 8bit integers (I believe). What I do is putting a hub very close to my laptop and define that level as full reception level, which is around -40 dB , and then move it as far away as I can within the "environment" = my attic space with different types of obstacles in the line of sight (brick, wood, etc.) and define the smallest distance before disconnection occurs as minimum reception level. The latter changes when operating the devices in less densely packed spaces of course:tongue:.

On ‎4‎/‎29‎/‎2019 at 10:13 PM, Mr Hobbles said:

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 fully agree. It really does not make sense to report the current, as BLE is LE:laugh: and presumably the highest current drawn is for the RGB LED lighting up when pressing a button on the remote. 

Best regards,
Thorsten

 

Share this post


Link to post
Share on other sites

Hi all,

I'm really lost and hope someone can help me. Till the update I used the follwing command to use a WeDo-Motor on a Smart Hub (no.4)

char-write-cmd 0x0e 0a0081PP016000VV0000 (with PP as Port and VV as speed)

I hoped changing 60 to 51 would solve, but doesn't.
Could anyone support me with the correct command, please?
Thanks in advance.

 

 

Edited by Lok24

Share this post


Link to post
Share on other sites

@Lok24

6 hours ago, Lok24 said:

0a0081PP016000VV0000 (with PP as Port and VV as speed)

Oh my, I am not the guru here but: The 60 apparently does not work anymore after the update. After updating to latest firmware version, everything works according to the LWP3 protocol though, which is very nice!

As far as I read that document you have tow options (have tested both on my updated 2I/O hub):

  1. Using the "write mode direct" (51) sub-command of 81, which I believe addresses devices on a "lower" level:
    08 00 81 PP 00 51 00 VV
  2. Using the "start power" sub-command (01) of 81
    07 00 81 PP 00 01 VV

At least, this worked for me with PuP train motors and PF and 9V motors wired to behave as PuP train motors (ID 02).

@Mr Hobbles provided that insight. When it comes to pairing outputs things have also changed at tiny bit but that is not what you are looking into, right?

Once again: I am not the one who provided all that insight. I am just applying what others have taught me.

Good luck and all the best!
Thorsten

 

Share this post


Link to post
Share on other sites

Thanks a lot, both work fine!

I will show that all at BrickBits 2019 next week (EV3,Boos,PuP, Sbrick), so it's good to know that it works.

Share this post


Link to post
Share on other sites

Just went through all pages of this thread and learn so much about the many possibilities with Lego train control, thank you all for being so kind, it all seems like a dream to me. I don't want to clutter this thread so let me say that I agree with  @treczoks that some way to unify this much information is needed. Let me also just say that if someone work is needed in Android programming for the trains I can step in and help in any way needed.

Cheers

Edited by hsousa
grammar

Share this post


Link to post
Share on other sites
On ‎5‎/‎14‎/‎2019 at 1:21 AM, hsousa said:

Just went through all pages of this thread and learn so much about the many possibilities with Lego train control, thank you all for being so kind, it all seems like a dream to me. I don't want to clutter this thread so let me say that I agree with  @treczoks that some way to unify this much information is needed. Let me also just say that if someone work is needed in Android programming for the trains I can step in and help in any way needed.

@hsousa

I completely agree with you on @treczoks work. Yes, the LWP3.0 protocol and documentation is out, it vis good, but to be honest, whenever I run into trouble figuring out things, I go back to his document first. It is a very nice and educational approach he has chosen.

Good luck with your future work!

All the best,
Thorsten

 

Share this post


Link to post
Share on other sites

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.

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.