Powered Up - A tear down...

[Fidelio]

On 6/7/2018 at 4:59 AM, JopieK said:

Last up is the inside of the motor:

That HL05 golden thing is a self resetting fuse, would protect the system from harm if a short / stall occurred. The other little thingy (C2) is a capacitor that tries to prevent spikes coming from the motor while running, harming the rest of the electronics (read the controller).  

Does anyone have any specs on the capacitor and self-resetting fuse?  I imagine there are all fairly standard components, perhaps a 100nF capacitor for noise filtering and 2A or less current limiting fuse.

I'm looking to fit a similar circuit to an existing motor and wanted to replicate the setup as much as possible to protect the upstream Powered Up circuitry.

[treczoks]

2 hours ago, Fidelio said:

Does anyone have any specs on the capacitor and self-resetting fuse?

No idea on the capacitor, but the PTC reset fuse is a 15V 500mA type.

Source on Alibaba.com

Edited February 17, 2019 by treczoks
Added link

[Mr Hobbles]

Here's a small anecdote for you: I had some free time today, and the wife is out of town, so I decided to set up a large track layout in our living room, play around with some trains, and annoy the dog. I brought out my Emerald Night, Maersk train, Metroliner, and Horizon Express, all of which have been converted to Powered UP (The Horizon Express has two hubs and two motors, and the Emerald Night is powering an XL PF motor through a conversion cable I made. The Metroliners headlights are also using a home made conversion cable.).

I'm running some code on my laptop and connecting all the trains to it. I try turning the first hub on the Horizon Express on. It immediately goes solid white. "Huh, that's weird", I think to myself. I hold down the button and turn it off. I press the button again - once again, solid white. "wtf?", I think to myself. I turn it off. My laptop isn't discovering the hubs.

I start Googling search terms to find out the problem, on a Lego troubleshooting site or something. Nothing. Eventually I think to myself maybe this hub's firmware is corrupted somehow, so I try a different hub - the one on the Maersk. I press the button, and again, it immediately goes to solid white. Even my Powered UP remotes are exhibiting the same behaviour. At this point I'm very confused, and wondering whether the last time I connected the hubs to the official iOS app a firmware update was applied that changed the behaviour of the hub.

About 30 minutes of repeatedly turning various hubs on and off and cursing and then I suddenly had a thought - "Is there something else in the house that's searching for Bluetooth devices and connecting to the hubs immediately upon discovering them?". A few more minutes of cursing then it dawns on me, I have a Raspberry Pi acting like a Bluetooth hub to connect to some smart home devices we have. I turn it off, try again on the hubs - and, nice blinking lights! It all works as normal.

It turns out that some of my (at least 3+ year old) code I have running on the Raspberry Pi has a bug. If one of the light switches in the house runs out of battery and disconnects, the Pi starts searching again, except it doesn't make sure its the correct type of device. It was connecting to all my hubs thinking they were light switches. :)

Oh well, about 45 minutes lost due to stupidity!

It did get me thinking though, this could be a problem at exhibitions for train layout displays. At worst, a malicious actor could bring with them a device that connects to hubs as soon as they turn on and prevent layout operators from connecting to them. At best, layout operators could cause confusion amongst themselves by not properly filtering for UUID's or hub names and stealing each others trains from across the hall.

Edited February 18, 2019 by Mr Hobbles

[XG BC]

13 minutes ago, Mr Hobbles said:

Here's a small anecdote for you: I had some free time today, and the wife is out of town, so I decided to set up a large track layout in our living room, play around with some trains, and annoy the dog. I brought out my Emerald Night, Maersk train, Metroliner, and Horizon Express, all of which have been converted to Powered UP (The Horizon Express has two hubs and two motors, and the Emerald Night is powering an XL PF motor through a conversion cable I made. The Metroliners headlights are also using a home made conversion cable.).

I'm running some code on my laptop and connecting all the trains to it. I try turning the first hub on the Horizon Express on. It immediately goes solid white. "Huh, that's weird", I think to myself. I hold down the button and turn it off. I press the button again - once again, solid white. "wtf?", I think to myself. I turn it off. My laptop isn't discovering the hubs.

I start Googling search terms to find out the problem, on a Lego troubleshooting site or something. Nothing. Eventually I think to myself maybe this hub's firmware is corrupted somehow, so I try a different hub - the one on the Maersk. I press the button, and again, it immediately goes to solid white. Even my Powered UP remotes are exhibiting the same behaviour. At this point I'm very confused, and wondering whether the last time I connected the hubs to the official iOS app a firmware update was applied that changed the behaviour of the hub.

About 30 minutes of repeatedly turning various hubs on and off and cursing and then I suddenly had a thought - "Is there something else in the house that's searching for Bluetooth devices and connecting to the hubs immediately upon discovering them?". A few more minutes of cursing then it dawns on me, I have a Raspberry Pi acting like a Bluetooth hub to connect to some smart home devices we have. I turn it off, try again on the hubs - and, nice blinking lights! It all works as normal.

It turns out that some of my (at least 3+ year old) code I have running on the Raspberry Pi has a bug. If one of the light switches in the house runs out of battery and disconnects, the Pi starts searching again, except it doesn't make sure its the correct type of device. It was connecting to all my hubs thinking they were light switches. :)

Oh well, about 45 minutes lost due to stupidity!

It did get me thinking though, this could be a problem at exhibitions for train layout displays. At worst, a malicious actor could bring with them a device that connects to hubs as soon as they turn on and prevent layout operators from connecting to them. At best, layout operators could cause confusion amongst themselves by not properly filtering for UUID's or hub names and stealing each others trains from across the hall.

if you wanna prank the people wich are still using pf ir you could do the same you could just bring a train remote controll and press stop on every channel. But the bluetooth system has some other problems aswell. however i dont suggest pranking people because you could destroy their work by crashing the trains

XG BC

[Bartosz]

1 hour ago, Mr Hobbles said:

Oh well, about 45 minutes lost due to stupidity!

Glad you've solved it! Would be a bummer to waste such circumstances (a free time without SO ;) ;) ) 

[Lok24]

 

2 hours ago, Mr Hobbles said:

Oh well, about 45 minutes lost due to stupidity!

My "problem" is similar, but different ;-)

I start my python script on the RaspPi and then push the three buttons on two hubs and the handheld, everything brillant.

When stopping programm it takes app 2 secs - and hub and handheld have paired on "green", I never get them accessed .....
Execpt removing battery.

Now I turn them off via prog exit, much better.

 

 

Edited February 18, 2019 by Lok24

[Mr Hobbles]

5 minutes ago, Lok24 said:

 

My "problem" is similar, but different ;-)

I start my python script on the RaspPi and then push the three buttons on two hubs and the handheld, everything brillant. 

When stopping programm it takes app 2 secs - and hub and handheld have paired on "green", I never get them accessed .....
Execpt removing battery.

Now I turn them off via prog exit, much better.

 

 

You probably know this already, but when the hub/remote is turned off, you can hold down the button until it flashes purple to make it forget its pairing. So they will never connect to each other on disconnect again. :)

[GianCann]

There is a way to increase number of decice connected via Bluetooth?

Nooble library seems to work o up to 5 device.

[Lok24]

Last info was that it depends on storage in dongle, using a PC with memory should do more,
that's what I understood.

Edited February 18, 2019 by Lok24

[Mr Hobbles]

50 minutes ago, GianCann said:

There is a way to increase number of decice connected via Bluetooth?

Nooble library seems to work o up to 5 device.

As @Lok24 says, it’s dependent on your hardware. With my MacBook Pro late 2013 model I’ve had 14 Lego BLE devices connected with noble/node-poweredup.

[Lok24]

Hi, new program new problems

I'm using this:

if self.htype == "Hub"
            s = "char-write-cmd 0x0e 0a0081PP016000VV0000"
if self.htype == "MoveHub":
            s = "char-write-cmd 0x0e 0c0081PP110900a0VV647f03"

PP is replaced with port, vv with speed, and that works fine.

But not when I connect a WeDo Motor on Boost Hub Port C or D

 

[Mr Hobbles]

4 hours ago, Lok24 said:

Hi, new program new problems

I'm using this:

if self.htype == "Hub"
            s = "char-write-cmd 0x0e 0a0081PP016000VV0000"
if self.htype == "MoveHub":
            s = "char-write-cmd 0x0e 0c0081PP110900a0VV647f03"

PP is replaced with port, vv with speed, and that works fine.

But not when I connect a WeDo Motor on Boost Hub Port C or D

 

[0x11, 0x09] is for activating a motor for a specific amount of time - this doesn't work for the WeDo 2.0 motor on the Move Hub as it uses the hardware inside the Tacho motor for the timing. You need to check the type of motor, then revert to our old friend [0x11, 0x51] to activate the WeDo 2.0 motor (Note: This is also true for the Train motor).

In your case I think the full command you're looking for is 070081PP1151VV. :)

Edited February 19, 2019 by Mr Hobbles

[veezer]

[edit] So, I probably shouldn't have picked a name for this project at 3am without doing a search first.  I didn't know about the other Blue Brick layout software.  So, I've gone ahead and renamed this project to BrickNil, and updated the links below

[/edit]

Just wanted to mention that v0.1 v0.3 of my BlueBrick BrickNil Python async library for interfacing to Boost and PoweredUp Hubs is now published, open-source licensed under Apache2.0.  Source is on github, and docs are at

https://virantha.github.io/bricknil/

Still early days, and only on Mac OS X so far, but supports all the Boost and PoweredUp Train motors and sensors I could find. I did spend some time figuring out how to do arbitrary mode combinations on the sensors, so I thought I'd share some of that back here since I learned so much from everyone's contribution on this thread.  This is really useful when you want to, for example, get the raw 3-axis accelerometer data plus the tilt data from a Boost hub at the same time.   There's some extra information (still incomplete) on each sensor I was able to get by querying the hub based on the protocol, and that lists more information on the specific mode combinations supported here: https://virantha.github.io/bricknil/lego_api/lego.html

All the information is what's reported back from the sensors directly (in other words, no interpretation from me).  Some things I don't understand yet, but here's how I combine multiple mode updates, taken from my BlueBrick BrickNil API documentation, after much experimentation and parsing of the official LEGO wireless protocol:

• * **Multiple capabilities** - This is more complicated because we need to put the sensor port into CombinedMode
  • Send a [0x42, port, 0x02] message to lock the port
  • Send multiple 0x41 messages to activate each capability/mode we want updates from
  • Send a [0x42, port, 0x01, ..] message with the following bytes:
    • 0x00 = Row entry 0 in the supported combination mode table. (hard-coded for simplicity here because LEGO seems to only use this entry most of the time)
    • For each mode/capability, send a byte like the following:
      • Upper 4-bits is mode number
      • Lower 4-bits is the dataset number
      • For example, for getting RGB values, it's mode 6, and we want all three datasets (for each color), so we'd add three bytes [0x60, 0x61, 0x62].  If you just wanted the Red value, you just append [0x60]
  • Send a [0x42, port, 0x03] message to unlock the port
  • Now, when the sensor sends back values, it uses 0x46 messages with the following byte sequence:
    • Port id
    • 16-bit entry where the true bits mark which mode has values included in this message. (So 0x00 0x05 means values from Modes 2 and 0)
    •  Then the set of values from the sensor, which are ordered by Mode number (so the sensor reading from mode 0 would come before the reading from mode 2)
      • Each set of values includes however many bytes are needed to represent each dataset (for example, up to 3 for RGB colors), and the byte-width of each value (4 bytes for a 32-bit int)

Edited February 23, 2019 by veezer
renamed project to BrickNil

[bogieman]

On 11/22/2018 at 8:05 PM, viktor_kovacs said:

A bit more hacking, this time the new Powered Up M motor (or what it's called). I changed the ID of the motor to the train motor by disconnecting the absolutely tiny 2.2k pulldown resistor in the middle just north of the number 4 (i just turned it out of the way, didn't fully remove it) and bridging pins 4 and 5.

A bit of extra info about the pins first:
-pin 1: motor 1
-pin 2: motor 2
-pin 3: ground
-pin 4: 3.3V logic power
-pin 5: id1
-pin 6: id2

And the ID pin connections for what i gathered from various forums:
-train motor: id1 to 3.3V, id2 to ground
-medium motor: id1 2.2k to ground, id2 to ground
-leds (unchecked): id1 2.2k to ground, id2 unconnected

These hacks are not that nice, but allow modified (useful) operation without hacking the software of the hubs or the remote or using a phone or other computer to control the hubs. Also they are easily doable and look pretty much reversible.

I just did a similar mod on a WeDo 2.0 medium motor used in a locomotive by just unsoldering the wire on terminal 5 and soldering it on top of the wire on VCC terminal 4. I didn't touch the resistor so restoring it to it's original configuration would be easy.

WeDo 2 Motor Rewiring for Trains by David Goding, on Flickr

[Mr Hobbles]

Massive update to the Powered UP ecosystem today: LEGO Education SPIKE Prime!

Lots of info here: https://education.lego.com/en-us/meetspikeprime

Looks like a new Mindstorms style hub with 6 Powered UP ports and a charging port. Also a programmable 5x5 LED matrix on the front.

New EV3 style motors, and a new EV3 style vision sensor (I'm guessing IR again). Two other sensors, can't tell what they are yet.

$329.99, preorder today.

I'm guessing this will be the basis for a new consumer LEGO Mindstorms set somewhere down the line (Maybe even as soon as summer release? Though I think January is more likely).

EDIT: On closer inspection, the motors and sensors seem to match those in the EV3 set. One IR distance sensor, one light sensor (but with an LED that can be lit up on the front), a touch sensor, and two motors.

Edited April 2, 2019 by Mr Hobbles

[AVCampos]

That looks quite interesting. But 6 general-purpose ports can be in some circumstances more limited than the EV3's 4+4 ports, and so far we don't know about its computational capabilities. These two points are important to decide if this replaces or not the EV3.

[Mr Hobbles]

17 minutes ago, AVCampos said:

That looks quite interesting. But 6 general-purpose ports can be in some circumstances more limited than the EV3's 4+4 ports, and so far we don't know about its computational capabilities. These two points are important to decide if this replaces or not the EV3.

I think it's interesting that it includes exactly the same sensors and motors as EV3, and LEGO places it into the same "Secondary Education" category as EV3. They've left WeDo 2.0 in the line up as the "Primary Education" entry. I think this may very well be intended to replace EV3. We'll have to see what the consumer set looks like.

CNET though says the processor is an "100MHz M4 320 KB RAM 1M FLASH", which definitely isn't up to par with EV3.

Edited April 2, 2019 by Mr Hobbles

[dr_spock]

Can it store programs like the EV3 or it just executes commands from a smart device controller?

 

[AVCampos]

It's autonomous like the EV3, although it can also work tethered like the Boost hub.

[Mr Hobbles]

43 minutes ago, AVCampos said:

It's autonomous like the EV3, although it can also work tethered like the Boost hub.

Interesting, do you have a link where I can read some more about that? I couldn’t find anything on stored program capability.

[Modeltrainman]

Is the Hub(for trains) the same size as the PF rechargeable? Also, does anybody know of anything for Windows to control the train?

Edited April 3, 2019 by Modeltrainman

[supertruper1988]

33 minutes ago, Modeltrainman said:

Is the Hub(for trains) the same size as the PF rechargeable? Also, does anybody know of anything for Windows to control the train?

They are the same size but the connection for the motors is in a different location so depending on the locomotive design, you may need to alter some areas. 

For windows, have a look at this thread

https://www.eurobricks.com/forum/index.php?/forums/topic/169318-control-all-your-powered-up-power-function-sbrick-devices-with-a-single-software/

[Modeltrainman]

@supertruper1988Thank you!

[AVCampos]

9 hours ago, Mr Hobbles said:

Interesting, do you have a link where I can read some more about that? I couldn’t find anything on stored program capability.

No, I was told that by a person involved in the project.

[Mr Hobbles]

7 hours ago, AVCampos said:

No, I was told that by a person involved in the project.

Aha I see, thanks for the info! I'm curious to see how it all works - already have my preorder in on the Education site. (July 29th shipping, it's a looong wait)