Powered Up - A tear down...

[Jetro]

4 hours ago, Giottist said:

Please use at least Android 5.1

exactly what I was going to say. Still, it's a pity it doesn't work on older devices. What device did you try it on?

[Dragunov2]

New update to the app Today, it gives the possibility to add your own directions to the Batmobile

[AVCampos]

11 minutes ago, Dragunov2 said:

New update to the app Today, it gives the possibility to add your own directions to the Batmobile

 

12 hours ago, AVCampos said:

Coincidentally (or not?), a new update to the PUp app has just become available, which appears (I can't fully confirm at work) to allow us to program the Batmobile in a Boost-like IDE!

 

[dr_spock]

Is there a way to revert back to the original PUP app that worked on 5.0.2 and earlier?

 

 

[AVCampos]

If I knew about this issue before updating my phone and tablet, I could have saved an APK backup of the previous version and share it. This is the app I usually use for backups.

[Bartosz]

17 hours ago, Lok24 said:

Edit: Yes, confirmed, only movements, no sensors (or not found yet l)

But then, if there are 2 motors, where you'd connect the sensors? (it's the same 2-input hub as in trains, right?)

[treczoks]

1 hour ago, Bartosz said:

But then, if there are 2 motors, where you'd connect the sensors? (it's the same 2-input hub as in trains, right?)

That is my problem at the moment, too. Train front: First motor and white lights. Train rear: Second motor and red lights. And the sensor?

[Lok24]

1 hour ago, Bartosz said:

But then, if there are 2 motors, where you'd connect the sensors? (it's the same 2-input hub as in trains, right?)

Yes, that's the situation. It's only made for a two-WeDo-motor-modell.

it would be nice to have in the future some possibilities to add conditions and 1 motor (no matter which) and a sensor (no matter which)

Edited December 18, 2018 by Lok24

[Bartosz]

I wonder what would it take to make a connection hub, and by the hub I mean a device that allows more inputs, and just routes the messages to the pup hub, and then back to proper device.

Devices have those identifiers,  yet currently there's no advantage made of them as compared to PF...

// Edit

With such limitations, for those more electronically inclined it seems to just be better to roll something on their own - some small microcontroller, a plug hacked to connect to hub (or BLE capable microcontroller and just scraping the official hub, whatever, possibilities are endless), and then add plethora of (cheap) sensors as you please...

Edited December 18, 2018 by Bartosz

[Lok24]

11 minutes ago, Bartosz said:

I wonder what would it take to make a connection hub, and by the hub I mean a device that allows more inputs, and just routes the messages to the pup hub, and then back to proper device.

 

That's what i thought when I first saw the hub. And you could add very small boosters for more motor outputs. Or Speakers?

These Gadgets just need a special coding on ID1/ID2 and send the complete protocoll via  M1/M2

Quote

Devices have those identifiers,  yet currently there's no advantage made of them as compared to PF...

There is. Only when the appropriate hardware is connected the apps work properly, the same with boost.

And as far as I know you can connect motor or sensor  to each port, and it will be detected without demaging anything.

( And you can "ask" the hub what ist connected, via Software)

 

Edited December 18, 2018 by Lok24

[Bartosz]

Just now, Lok24 said:

These Gadgets just need a special coding on ID1/ID2 and send the complete protocoll via  M1/M2

I'm gonna skim the thread in search of info on those IDs, bit before I do - maybe you know I'd there's some info on them somewhere? I'm wondering how to they work at all - given 2 lines are devoted to those...

[Lok24]

Just now, Bartosz said:

I'm gonna skim the thread in search of info on those IDs, bit before I do - maybe you know I'd there's some info on them somewhere? I'm wondering how to they work at all - given 2 lines are devoted to those...

It depends on the voltage level, sometimes they are connected to VCC or ground, sometimes there are resistors in addition, their values help to decode the type.

Same with EV3/NXT

Have a look how to change type of motor:

 

[Bartosz]

1 hour ago, Lok24 said:

It depends on the voltage level, sometimes they are connected to VCC or ground, sometimes there are resistors in addition, their values help to decode the type.

Right, that was the only thing I remember from that thread. But then - that'd be a waste, to have dedicated two lines to carry some hardcoded logic levels (which would give 2 bits of info?).

But then I found info from @TrainDragon:

which clearly indicates the lines are used for communications (their voltage levels seem to be 3.3V).

This might indicate, the "dumb" devices are using "hardcoded" levels, whereas devices with some microcontroller can use it for communication, and hub should recognize it. To me it also seems like it'd be just impossible to mix such "dumb"/"smart" devices in one socket with some kind of "switcher" inbetween, because dumb devices don't receive commands, but are controlled "dicerctly" by the main voltage lines.

But all that would also require a spec of a protocol of all those devices...

[TrainDragon]

17 hours ago, Bartosz said:

which clearly indicates the lines are used for communications (their voltage levels seem to be 3.3V).

That is correct.  For "dumb" devices like the Train Motor, the lines can be tied to specific voltages to indicate to the Hub what they are.  For "smart" devices, they use the two lines as UARTs at 115200 baud -- one line is communication from the Hub to the Peripheral, and the other is from Peripheral to Hub.  I wrote a little about this in the Documenting the LEGO PoweredUp! System thread.

I've written a plugin for the open-source "sigrok" signal analyzer software that can decode some of that serial communication between the Hub and Peripheral and turn it into human-readable info about the current state of the motor/sensor.  For example, the motor that comes in the Boost kit reports back to the Hub about its current speed and angular position: Screenshot

 

[Bartosz]

1 hour ago, TrainDragon said:

For example, the motor that comes in the Boost kit reports back to the Hub about its current speed and angular position

Were you able to find out how device is identified? Does it send some info in some handshake, or maybe every message carries some identifier?

[AVCampos]

On 12/18/2018 at 12:06 AM, dr_spock said:

Is there a way to revert back to the original PUP app that worked on 5.0.2 and earlier?

I found this site, that appears to have previous versions of the app for download. I have no idea if it's safe, though.

[Lok24]

Hi,

my question referrs to Mr Hobbles train show here:

Is there a "ready to use" program or some  package which I can use?

 

[viktor_kovacs]

On 12/19/2018 at 6:22 AM, Bartosz said:

Were you able to find out how device is identified? Does it send some info in some handshake, or maybe every message carries some identifier?

The sign of a smart accessory is that the ID lines are not fixed to anywhere. There is a small imho AD chip for each port in the HUB to detect this. If they are not fixed, the HUB sends a query command to the accessory (smart motor/sensor) every now and then and it reports back its info in a response packet. This allows on the fly plug and play detection and the type info and actual values could be requested in one message.

So far all high current output driving is done on the two motor output pins as there are no other high voltage and high current outputs on the connector. The 4 other pins are for signal ground, 3.3V logic power and the ID-s. This, in theory would allow a smart, but battery and radioless hub to be added (kind of like a distribution strip) that has a microcontroller and reports back to the main hub. Then the main hub could query the ID-s or info packets of each connected accessory, while driving them with the same output signal. This would require an upgrade to the current protocol and new software for the HUB-s and the remote controller. Sadly without having a way to drive the motor inputs of each accessory differently based on its type, this would break the current beaviour of the PU system.

Doable, but adding extra fully featured hubs or even an up to 16 port one would be much easier and probably much cheaper for LEGO. Using a dedicated HUB for every 2 or 4 outputs is imho a simple way to get around the output current limitations of AAA batteries and avoid the software complexities that come with a tree structure. Imho a 4 port hub with AA batteries is possible and seems logical for larger technic builds, but LEGO could as well just use two 2 port hubs and have the same end result.

[Bartosz]

1 hour ago, viktor_kovacs said:

This would require an upgrade to the current protocol and new software for the HUB-s and the remote controller.

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.

For those with electronic skills (which is like, probably everyone that's hacking on it right now ;))  it seems it'd be just way easier to roll own solution (some BLE-capable microcontroller + plethora of cheap peripherals that are available)...

[JopieK]

Did someone already find this: https://lego.github.io/lego-ble-wireless-protocol-docs/ it was posted at 1000steine :) (I just saw it was also already in the 

 topic as well). 

Edited December 23, 2018 by JopieK
Added info.

[treczoks]

47 minutes ago, JopieK said:

Did someone already find this: https://lego.github.io/lego-ble-wireless-protocol-docs/

I'm already tearing this documentation apart for my documentation, and I already found at least one issue where the LEGO documentation and reality don't match. That*s why I'm doing all this testing and verifying.

[Brickthus]

On 7/27/2018 at 7:22 PM, Paperballpark said:

I was only saying that because the Lego trains FAQ says this:

Can I use and connect the new LEGO® Powered Up Smarthub, motors and lights with my older LEGO Power Functions battery box and motors?
Unfortunately, no. The change of technology between LEGO® Power Functions (infra-red signal) and LEGO® Powered Up (Bluetooth connection), combined with a change of the wire connectors, means the two systems are not compatible.

Which strongly implies that they're not going to release a converter cable.

 

On 7/27/2018 at 9:46 PM, Jetro said:

I'd take that as a description of the current state of the platform. If LEGO were to say anything else they'd get an avalanche of questions on how to make it work right now. Not that I'm optimistic about the chances of it actually happening, but FAQs have been known to change over time.

We can only hope.  Otherwise the applications with our previous product investments are limited.  I do get the feeling PU is designed for the modern "module + app" generation and have less appeal to those of us who are used to making compatible hardware.  The most fun I had with PF was to create my own circuits to go with its protocol.  I had in mind to make a multi-coloured LED signal and also a flashing light like the 9V light pair.

If TLG do not announce a set of leads soon, including some compatibility with PF, then I'll be tempted by the other IDC plug idea.

However, the problem of obsolescence of older products is serious; many of us have large investments in previous electrical products.  9V leads degrade.  Track connectors crumble and other leads are showing similar signs.  I'm not sure whether the PF or PU lead insulation material is similar or not, but it has similar flexibility and feel.  Either way, it indicates that there is a life limit on electrical products with cables, far short of the life of ordinary bricks, which will severely limit my purchasing unless a maintainability solution can be found.

Oddly enough the 4.5V and 12V leads are fine, and use plugs that are easy to rewire.  Best cable system yet!

Given that the PU plugs are unique to TLG, is the 6-way cable available commercially?  If so, I'd like to get some and re-wire some 9V leads and track connectors.  That would keep things going at least until PU is fully deployed.

Thanks for the teardown and interesting discussion.  It seems the 6 pins are similar to the NXT/EV3 interface, where Gnd and Vcc (3.3V) are similar and ID1 and ID2 work as serial ports.  I drove an LED from the NXT by changing the sensor type in software.  Perhaps PU will be able to control an NXT/EV3 motor with only an interface programming change in an app?

Mark

[AVCampos]

34 minutes ago, Mark Bellis said:

9V leads degrade. 

Actually, older 9V leads (those narrower and shinier) don't degrade: I have some pre-RCX touch sensors (the yellow ones with integrated lead) and they're fine. For some reason TLG changed the insulation material for something worse during the 9V era, but at least PF and NXT cables don't appear to be made from this brittle material.

[Bartosz]

6 hours ago, Mark Bellis said:

by the other IDC plug idea

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

[dr_spock]

Perhaps LEGO will license others to make the adapter cables if they don't.  That way they can make some money off their IP instead of making a niche product that may not be worth their while.