Powered Up - A tear down...

[TrainDragon]

On 12/23/2018 at 6:14 AM, Bartosz said:

That's exactly what I've been asking - whether it's possible to build extension for hub without altering hub (or its firmware) itself. Thanks.

I'm just now checking out the BLE wireless protocol doc that LEGO released recently.  It does seem to indicate that there are future plans for hub chaining:

Quote

Hub identifier is needed when a Hub is connected as a bridge to a network formerly build without a SMART DEVICE. E.g. HUB A is connected to HUB B and HUB C is added. After a while the SMART DEVICE is connected to the network. HUB A is now acting as a Central for B and C while acting as a Peripheral to the SMART DEVICE. Data from B and C will be routed through HUB A.

NOT USE at the moment!

So, who knows when, but there is hope!

[miobricks]

On 7/1/2018 at 3:14 AM, 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 ...

 

Hi, I thought I would try @Mr Hobbles node.js library to control pup trains, and happy to report it works. I don’t have the color sensor, so at the moment it is just start and stop at an interval. But I like the ability to do smooth starts and stops. See video:

 

[Cosmik42]

Hi guys, I have a question.

Have you succesfully connected a WeDo 2.0 Distance Sensor to a Train Hub and managed to receive data?

I had no problem connecting a Boost Color/Distance sensor and reading its data thanks to this great article: https://github.com/JorgePe/BOOSTreveng/blob/master/ColorDistanceSensor.md

However, this protocol does not activate WeDo 2.0 distance sensor when mounted on a train hub.

Help! :D

[Cosmik42]

Well, nevermind, I just figured it out. It was simply port 0x00!

=> This gets the WeDo 2.0 Distance-Only sensor to start talking

WriteMessage(new byte[] { 0x41, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01 }); 

 

[viktor_kovacs]

On 12/30/2018 at 8:11 PM, Bartosz said:

Could you elaborate? What does "other" stands for? A particular off-brand product (SBrick?)

Actually the 6 wire cables are standard sized, so you can either use a 3x2 standard raster pin IDC plug, mostly found in computers and other digital circuits as the socket fits nicely into raster boards and could even be added in the middle of the cable (parallel ata sytle) or if's possible to use any 6 or more wires registered jack crimp plugs if you split the ends of the wire so they could feed into the new plug. The modified 6 pin RJ plug is used by NXT/EV3. In the latter case, be careful as the protocols as not compatible, so don't mix the two systems without proper converter circuits. Also shorting or higher voltage feedback on the 3.3V lead of the PU wires could very easily damage the HUBS and the sensor circuits in the smart accessories. (pretty much how more than 5V would kill most USB devices)

Speaking of conveters, one of the LEGO Q&A blog pages state that the PF and PU protocols are not compatible but the PU and 9V outputs are, mostly because how the 9V high current line was swapped for a 3.3V low current one. Fortunatley the motor connections are the same, so it's possible to create a PU to 9V converter cable or a PU to PF output only cable, but this happening is not too likely as it would require a new dedicated ID from LEGO and would still run the possiblity of a 9V or PF output feeding into the motor outputs of the HUBs, creating an instant short between the two outputs or worse burning the protection diodes of the HUB's H bridge if the HUB is powered down. The use of exension cables was one way to damage PF receivers or WeDo1s. (one way is to use two extension wires to attach two sensors to the same port or to feed reverse direction switched power from a 9V battery box into the output of a PF receiver, both are very easy to do accidentially without any modified parts)

Personally i think a straight extension cable from lego would be great for those who would like to hack around or just want to build larger MOCs and it would not cause any problems in the PU system. The not enough outputs problem could be solved by LEGO by making HUBs with more ports or by using more than one HUB in a MOC.

ps: I also think the 12V system was the most hack-able without custom parts of modifying LEGO components but it was really hard for the kids (and sometimes even for their parents) to set up a working train layout or anything more than a basic loop. The current PU system makes if harder to miswire and damage the components than the PF system and at the same time makes it easier for kids to assemble everything alone as currently there is no way to connect anything the wrong way.

[AVCampos]

5 hours ago, viktor_kovacs said:

it's possible to create a PU to 9V converter cable or a PU to PF output only cable, but this happening is not too likely as it would require a new dedicated ID from LEGO and would still run the possiblity of a 9V or PF output feeding into the motor outputs of the HUBs, creating an instant short between the two outputs or worse burning the protection diodes of the HUB's H bridge if the HUB is powered down.

That could be solved by a different PF plug at the end of that adapter cable, with an electrical connection only at the top (like the PF extension cable without the 9V connection). The design of PF is smart in that regard, having power always flowing bottom to top in stacked PF plugs.

[Cosmik42]

Hi everyone,

Just a small word to let you know that this very thread was a huge source of inspiration for my latest piece of code:

The goal was to produce a software that would encapsulate most of your work but in a way that would be usable by anyone, without the need for any tech knowledge. 

The Lego Train Project can connect to any Powered Up hubs and allow you to control its port through a simple UI. But you can also program complex scenario and even write custom code in C# without the need for a compiler.

Would love your feedback!

[viktor_kovacs]

14 hours ago, AVCampos said:

That could be solved by a different PF plug at the end of that adapter cable, with an electrical connection only at the top (like the PF extension cable without the 9V connection). The design of PF is smart in that regard, having power always flowing bottom to top in stacked PF plugs.

Unfortunately no as the already existing PF extension cable then could be connected on top and the other end of that to the 9V battery i mentioned. This setup would even allow reverse powering drained non rechargable batteries, which is a fire hazard. The overcurrent protection in the old battery boxes might protect the driving HUB, but the batteries would still get damaged. There is no clean solution for this as long as there is a pathway to an old 9V part or the PF battery boxes are allowed. (see: the empty PF AA battery box hack for powering a PF receiver from old 9V power sources like the LEGO train transformer) These completly legal and no modification required hacks mean any kid could accidentally do them and then you have wrong polarity power going into a PF receiver (there is a shorting diode to save the receiver, but that causes a short on the input line) or charging some non rechargable batteries or just two HUBs shorting together their motor outputs. The new PU system fixes these holes but this also means LEGO had to get rid of any compatiblity. This, in theory allows the PU system to be used by much younger kids without any danger of miswiring something. The inclusion of PU in the Duplo range is imho a good example.

ps: In theory it would be possible to make an app controlled Duplo locomotive or even a programmable app controlled one... :-)

[treczoks]

16 hours ago, AVCampos said:

The design of PF is smart in that regard, having power always flowing bottom to top in stacked PF plugs.

No, it totally isn't. The top and bottom connectors of PF plugs are simply connected, at least all the ones I've opened so far, which are quite a lot. There is no kind of "direction" in there. Which would be quite miraculous, if one takes into consideration that a connected motor has to be able to turn in both directions...

What can be done to drive a PF motor with PuP is to cut a PuP cable, take "3 GND (0V)" and connect it to "6 ID 2", take "4 VCC (9V)" (which is wrongly labeled in this picture, it's actually 3.3V!) and connect it to "5 ID 1". "1 Motor lead 1" and "2 Motor lead 2" of the PuP wire can then be connected to the "C1" and "C2" connections of the PF wire to drive the PF motor. I usually open the PF connector and put my wires directly in there. The PF motor will then be recognized by the hub as a train motor.

Unverified, but worth a try, based on the reports by viktor_kovacs in this tread from November 23rd: To drive a PF LED with this, wire the PuP cables "6 ID 1" with a 2.2kOhm resistor to "3 GND (0V)", and leave "5 ID 2" and "4 VCC (9V)" open.

Yes, you can drive the LED with the above mentioned motor cable, too, but they would identify as a train motor.

Do not use this for XL or Servo motors, the PuP hub is not powerful enough to drive the XL motor, and it does not provide the fixed 9V necessary for the Servo.

I've blatantly copied the pictures from the net for this post so you don't have to dig for them yourself. I hope nobody objects.

On another note. Someone has already opened the PuP LED "box". I thought the article was here, but I cannot find it. Does anybody know who did this? I'd like to know how to open the LED box without breaking it - I assume it is somehow clipped close, not glued.

[TrainDragon]

I sacrificed a PUP LED for its connector.  I did open up the box as well to peek inside.

Here is a photo of the result:

I desoldered the cables to use elsewhere.  The PCB is only populated on this side, no components on the reverse.

It looks to me that the box is glued shut.  even after prying it apart, there is no obvious clip mechanism to be seen.  As you can see, three of the posts simply broke when i pried it apart.  The fourth post didn't have as much glue on it so it separated with the post intact, but I can see some glue residue.  However, the box does friction-fit back together fairly snugly even after my abuse.

 

[treczoks]

3 hours ago, TrainDragon said:

I sacrificed a PUP LED for its connector.  I did open up the box as well to peek inside.

Thank you for your sacrifice! Could you do me a favor and post a magnified picture of the PCB?

[TrainDragon]

13 hours ago, treczoks said:

Thank you for your sacrifice! Could you do me a favor and post a magnified picture of the PCB?

No problem:

Looks like the "222" resistor (2.2 kΩ) ties to one of the ID pins as previously noted, and the two "511" resistors (510 Ω each) are the current-limiting resistors for the two LEDs.  The chip labeled "K1t" is presumably a bridge rectifier.  Not sure what value the capacitors are.

 

[AVCampos]

4 hours ago, TrainDragon said:

Not sure what value the capacitors are.

I was wondering that myself. I didn't follow the traces, so I'm just spitballing here: could they be used to filter noise from any eventual motors connected to other ports? This shouldn't be an issue with LEDs, but I see no other explanation.

[treczoks]

11 hours ago, TrainDragon said:

Looks like the "222" resistor (2.2 kΩ) ties to one of the ID pins as previously noted, and the two "511" resistors (510 Ω each) are the current-limiting resistors for the two LEDs.  The chip labeled "K1t" is presumably a bridge rectifier.  Not sure what value the capacitors are.

Thanks for the pictures!

Yes, the 2k2 matches the other descriptions, but the 510 ohm resistors make me wonder, IIRC, the PF version had 4k7 in this place, which, at 9V input and an assumed 2.6V for the LED somewhere about 1.25mA. Using 510 ohm instead would yield somewhere around 18mA for the new LEDs. That's something to keep in mind here for me, if the old PF LEDs were of the 2mA variant and the new ones are 20mA. I intend to buy a bunch of PF LEDs in the near future just to cut out the box, and attach the LEDs to my Arduino, and the PF cable will be used to "feed" the motor via a mosfet chip.

I totally agree with you on the K11 chip. The way it integrates into the schematics as well as its denomination as "D1" supports this.

But you should definitely work on your de-soldering skills ;-)

6 hours ago, AVCampos said:

I was wondering that myself. I didn't follow the traces, so I'm just spitballing here: could they be used to filter noise from any eventual motors connected to other ports? This shouldn't be an issue with LEDs, but I see no other explanation.

As the LEDs are driven with a PWN interface, this is probably to reduce reflections and/or electromagnetic emissions.

[viktor_kovacs]

4 hours ago, treczoks said:

Yes, the 2k2 matches the other descriptions, but the 510 ohm resistors make me wonder, IIRC, the PF version had 4k7 in this place, which, at 9V input and an assumed 2.6V for the LED somewhere about 1.25mA. Using 510 ohm instead would yield somewhere around 18mA for the new LEDs. That's something to keep in mind here for me, if the old PF LEDs were of the 2mA variant and the new ones are 20mA. I intend to buy a bunch of PF LEDs in the near future just to cut out the box, and attach the LEDs to my Arduino, and the PF cable will be used to "feed" the motor via a mosfet chip.

Imho the standard 20 mA white leds usually have a forward voltage of somewhere around 3.3V, so (9V - 3.3V) / 510 ohm = 0.011176 A ~ 11 mA.

I've compared the brightness of two unmodified ones and they are much brighter than the latest PF ones, which are brighter than the previous PF variant and way brighter than the 1st run warm whites. (so far i've seen 3 PF led board variants, the original 1st run warm whites, the newer cold whites with the brighter green PCB and the latest darker green PCB with a modified component layout and higher brightness) The PU ones outshine all of the PF ones.

On the other hand, is there a way to take these PU leds apart and assemble them without visibly damaging the circuit housing in the process? For the PF ones, it was relatively easy to take apart, mod for polarity and reassemble (take off diode bridge, bridge it with solder and reverse one led wire).

Edit: i've scribbled over the picture above my polarity converson idea: http://www.brickshelf.com/gallery/kvp/pfpu/pu_led.png

Edited January 8, 2019 by viktor_kovacs
adding one extra link to a brickshelf picture

[treczoks]

55 minutes ago, viktor_kovacs said:

Imho the standard 20 mA white leds usually have a forward voltage of somewhere around 3.3V

Yea, you're right, they run more in the 3-3.6V range, with 3.3V getting more and more common nowadays (probably because people want to use white LED on 3.3V circuits, too.

As long as we don't know the values, we'll have to guess. But nonetheless, the PuP LEDs are way brighter than the old ones indeed.

58 minutes ago, viktor_kovacs said:

For the PF ones, it was relatively easy to take apart, mod for polarity and reassemble (take off diode bridge, bridge it with solder and reverse one led wire).

I did that, too. But I always added a normal diode, too, as LEDs don't really like being powered against their polarity (Is "reverse biased" the right English term for this?). They might be called diodes, but they are not like a good old 4001 in many aspects.

While the polarity reversion is a nice trick, I nowadays prefer to control them directly via Arduino.

On another note, has anyone managed to open the LED housings themselves? There are four clips, but the transparent plastic is usually quite brittle, so I have not tried this.

 

[Lok24]

Hi all,

 

just to be sure before destroy mya new hardware

I can connect both Boost-Motor and Boost-Senser to a PoweredUp-Hub?

I can connect PoweredUp-Motor to a Boost-Move Hub?

 

Edited January 8, 2019 by Lok24

[AVCampos]

No, you won't damage any hardware: the worst that can happen is the hub's (current) software not recognising the motor/sensor. 

[Mr Hobbles]

2 hours ago, Lok24 said:

Hi all,

 

just to be sure before destroy mya new hardware

I can connect both Boost-Motor and Boost-Senser to a PoweredUp-Hub?

 I can connect PoweredUp-Motor to a Boost-Move Hub?

 

Yes, and yes. :)

A Boost Motor will work on a Powered UP hub, but does not support angle rotation or reporting the angle rotated. It allows speed control only.

Boost Sensor is fully supported on Powered UP hub.

Powered UP motor is fully supported on a Boost Move Hub.

(All this is only true when used with third-party non-LEGO software to talk to the hubs)

[Lok24]

Hi,

thanks, that was what I assumend and hoped.

I tried to install your packet on Win 10, but thats  a bit tricky (Noble BLE library prerequisits), but I'll try with  my raspberry next weekend.

 

[rzido]

Hi all!

I’m a completely newbie to LEGO World and AFOL Community. This is my first post. Two weeks ago I got a Lego Duplo Cargo Train (10875) for my 2 years old son.  And I started to put my hands on it.  Next I’ll explain some of my researching in case it could be useful for someone: 

1. First of all, I could verify that is possible to use your own created action bricks.  I found this video and it works for me. I tried it with my own home made action bricks made of cardboard. Yellow, red, green, white and blue cardboard action bricks worked fine and train played sound associated to each color. I tried another colors but with no result. As Nathan said in an early post seems that it’s actually hardcoded in the sensors and actuator firmware the capability to detect a limited number of colors and play a limited number of sounds. Maybe we can see new action bricks in the future, new built in sounds, and new updates to firmware to unlock functionality.  It could be awesome that LEGO unlocked the possibility of playing custom sounds.
2. I also tried a bunch of LEGO apps for controlling the train (Lego Connected Train and also Coding Express). Coding Express (45025) allows, with 4 different themed activities, change the way the action bricks behave, altering the effect on the train. The train/hub detects the  color for an action brick and the app plays a sound associated to it (i.e. an animal or instrument sound)
3. I tried node-poweredup  (great job Nathan). It was, at first, a bit confusing for me use it for send commands to my Duplo Train.  I think there is no specific example for duplo train and the train examples confused me (I suppose these examples are for Lego City Train). At last I found that setting TRAIN_MOTOR_PORT = “MOTOR” (not “A” or “B” or “AB”)worked fine. I tried application with some of my cardboard action bricks and it detected some of my cardboard action bricks in the 10 hardcoded detected colors range posted by Nathan (I didn’t try all 10 colors).
4. I  got my hands on LEGO Wireless Protocol 3.0.00 Documentation in order to obtain some more knowledge about the train. I'm still studying it. 
5. I also tried to make a preliminary/inside analysis of LEGO apps. The apps analyzed were Lego Connected Train v1.2, Coding Express v1.0, LEGO Boost  1.8.0 and LEGO Powered UP 2.0). All, but LEGO Powered UP, seem to use a common SDK (device sdk).  Will be this the base for the future SDK to be released by LEGO?

            From the analysis I could detect some, nowadays, undocumented information in LWP 3.0.0 docs. LEGO WP 3.0.00 Documentation (2.1) only specifies 4 System Types:

            000    LEGO Wedo 2.0

            001    LEGO Duplo

            010    LEGO System

            011    LEGO System

            But from the apps I’ve found that, at least, LEGO could have in mind four more (2 Technic -4 and 5- and 2 Third Party System Types - 6 and 7-)

I will continue my research and I’ll post my findings and testings in case there could be useful for the community. Thank you all for your posts and work.

[Lok24]

Hi all,

I just tried to build my first remote controlled  layout, but it doesn't work!

Connecting a boost sensor and boost external motor to a PoweredUp Hub stops the connection immediatly.

Sensor or motor alone work fine.

Is this a known issue? Can anybody confirm?

Boost sensor an PU Train motor work as well.

 

Edited January 14, 2019 by Lok24

[XGBC]

The pictures on these site might help you

https://bricks.stackexchange.com/questions/9148/what-internal-electronics-does-lego-boost-use

 

XGBC

[Giottist]

Perhaps it's useful to mention an existing software which supports PU hubs, the BOOST hub and (!)SBrick devices running on Windows 10. This software written by Eurobricks member Cosmik42 distiguishes between different sensors and the lights but makes no difference between motor types in the actual version. Stability is excellent and I could not find any issue with the BOOST motor connected to the train hub. Try it, you will be convinced

[Lok24]

Thanks for your reply.

Behavior is exactly the same with the handheld and the mentioned software.

I remeber a post here where same was reported, but with two motors. can't find it anymore.

Might be a bug in the hub?

You'll find a short video showing the project of Cosmik42 in the other thread!

 

Edited January 14, 2019 by Lok24