Cosmik42

Control all your Powered Up & Power Function (SBrick) devices with a single software

Recommended Posts

12 hours ago, coinoperator said:

LEDS are Light Emiting Diodes
They give ligt but they are still diodes and will block a max. X voltage in reverse direction
To find out what X is just should read the datasheet

Well I believe I know some of electronics. Not too much but enough to get this and that going.

Haha: The datasheet of a ten LED dirt-cheap string running on two 1.5 V AA batteries tells me nothing. But they were in some glass container with a little Christmas tree and some fake snow - and were decorating our dining room - and were - important:look:. I hope you understand … not that much to me …

12 hours ago, coinoperator said:

But whatever, this reverse V didn't destroy them

Phew - another one of these strings of LEDs (2 x 1.5V) this time with spring season stuff - turned them off as soon as I read your post. Had 3.2 V regulators/100 mA at hand, used a 5V (+X) wall wart and now we should be good, right?

Thanks for letting me know!

All the best,
Thorsten

Share this post


Link to post
Share on other sites

ROTFLMAO

just like capacitors you can use them as some kind of popcorn
they digest badly but make about the same sounds on overcurrent/voltage.

Edited by coinoperator
oh well, lets blow them

Share this post


Link to post
Share on other sites
On 1/8/2019 at 8:44 PM, Cosmik42 said:

For now there's no clear plan on releasing the source officially, mostly because it is a side project and the code is really ugly :D

If you ever do decide to open source it (or part of it), let me/us know. I am having some issues getting my own application to properly connect to the PUP hub in my train, and would like to see how you solved that. The Bluetooth API has so far been quite annoying to wrangle into something useful :p

Share this post


Link to post
Share on other sites
23 hours ago, coinoperator said:

just like capacitors you can use them as some kind of popcorn
they digest badly but make about the same sounds on overcurrent/voltage.

That would be fun :excited: 

BUT: These strings are for >serious< decoration purposes (i.e. my wife's efforts). I am just the guy who has to minimize battery consumption :wink:

Hmmm ... maybe I should get my own 3V strings - there is a 48 V DC power supply in the work shop. From the good ol'days where telephones could be used to make phone calls as well as cause serious injuries:laugh:

All the best,
Thosten

So back on topic:

I believe that @Cosmik42 makes a very good point with regard to releasing his source code: Looking at my >mess< of messy VB6 code (that does actually works rather nicely with PuP devices) - I would not want that anybody sees it. On the other hand, he is a programmer. So his mess is not a mess, but a just a freaking good solution.   

Share this post


Link to post
Share on other sites

Hello @Cosmik42
I have two questions on the "Self-Driving Train Module".
First: Can you rewrite the program so that the number of repetitions can be entered? Or set to infinite? Instead of repeating the path?
Second: Is it possible to drive with two-way traffic in this mode? I have seen that you only provide an "End Section Detector", that could be a problem. Imagine an oval with two alternative routes:
Oval.JPG

Share this post


Link to post
Share on other sites
19 hours ago, mawe said:

First: Can you rewrite the program so that the number of repetitions can be entered? Or set to infinite? Instead of repeating the path?

This is totally doable

19 hours ago, mawe said:

Second: Is it possible to drive with two-way traffic in this mode?

This has always been in my mind, but I never found the time to make it happen.

It create some much more complex edge cases unfortunately.

Share this post


Link to post
Share on other sites

Hi Cosmik42,

I've found another issue with the latest version 1.2 dealing with the train hub:

If I connect a WeDo 2.0 / Batmobile motor in combination with the colour/distance sensor to a train hub, everything works well.

If I connect a Boost motor (with build in tacho sensor) but without the colour/distance sensor, everything also works well.

But if I combine the Boost motor with the colour/distance sensor, the train hub crashes and finishes the BT connection.

No big deal, but I am think about to equip my trains with colour sensors for further functionality. And the Boost motor has a slower gear ratio for more torque.

BTW: It seem, several PU components will be available in the near future ...

Best wishes

Share this post


Link to post
Share on other sites
47 minutes ago, Giottist said:

Hi Cosmik42,

I've found another issue with the latest version 1.2 dealing with the train hub:

 If I connect a WeDo 2.0 / Batmobile motor in combination with the colour/distance sensor to a train hub, everything works well.

 If I connect a Boost motor (with build in tacho sensor) but without the colour/distance sensor, everything also works well.

 But if I combine the Boost motor with the colour/distance sensor, the train hub crashes and finishes the BT connection.

 No big deal, but I am think about to equip my trains with colour sensors for further functionality. And the Boost motor has a slower gear ratio for more torque.

BTW: It seem, several PU components will be available in the near future ...

Best wishes

This is a known issue with the Powered Up hub and not isolated to Cosmik42's software. It only occurs with "intelligent peripherals" - sensors and tacho motors, but not basic motors and leds. As soon as you plug two in, boom - crash and restart.

There are various rumors flying around why it occurs, such as it only having the internal hardware to handle communication with one sensor at a time, who knows. But I've also heard that Lego intends to release a firmware update at some point to stop the crash.

Share this post


Link to post
Share on other sites
On 4/4/2019 at 10:01 PM, Giottist said:

Ah, I didn't know - thank you :classic:

Turns out that day was today. :) New Powered Up app has new firmware update for PUP hub that fixes that bug.

Share this post


Link to post
Share on other sites

Just updated all my hubs ... And yes, the new app for Android works much better than the old. There are no crashes with old Android 5.0.2 any more. There is no need to buy a new smartphone/tablet.

And then I tested the new firmware for the train hub with the lates version of Cosmiks software:

The crashbug with the combination of tacho motor and the colur/distance sensor has gone - But!

No motor reacts anymore. All motors are recognized correct, either by cold or hot plugging. But no motor of any kind shows a reaction to the speed sliders. Hmm ... Another bugfix is neccessary ...

The new LEGO app performs very well instead, so I sure no hardware error occured.

Share this post


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

No motor reacts anymore. All motors are recognized correct, either by cold or hot plugging. But no motor of any kind shows a reaction to the speed sliders. Hmm ... Another bugfix is neccessary ...

 

have a look:

https://www.eurobricks.com/forum/index.php?/forums/topic/162288-powered-up-a-tear-down/&page=16&tab=comments#comment-3100211

Share this post


Link to post
Share on other sites

That sounds pretty serious and worthy of immediate attention.

You updated the firmware via the latest app?
@Mr Hobbles - did you notice an update in the protocol with this update?

Share this post


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

That sounds pretty serious and worthy of immediate attention.

You updated the firmware via the latest app?
@Mr Hobbles - did you notice an update in the protocol with this update?

Yes, both app and firmware are updated today before testing.

Share this post


Link to post
Share on other sites
8 minutes ago, Cosmik42 said:

That sounds pretty serious and worthy of immediate attention. 

You updated the firmware via the latest app?
@Mr Hobbles - did you notice an update in the protocol with this update?

Yes he did, have a look:

https://www.eurobricks.com/forum/index.php?/forums/topic/162288-powered-up-a-tear-down/&page=16&tab=comments#comment-3100211

Edited by Lok24

Share this post


Link to post
Share on other sites

Would be nice to know if LEDs are still working and motor is running with 0x51 instead of 0x60

Share this post


Link to post
Share on other sites
2 hours ago, Cosmik42 said:

 

@Mr Hobblesid you notice an update in the protocol with this update?

Kinda...the main problem is they now follow their own spec to the letter! 😁

Basically virtual port AB is no longer implicitly created when you plug in two devices of the same type. It now expects you to send commands to manually create a grouping. This is something their LWP docs said we should do, but actually wasn’t possible until now. I’ll go into more detail in the other thread.

I was using the 0x60 subcommand to control the motors as it was the only one that could control all three, also due to bugs. That’s no longer the case - we can now use DirectModeWrite 0x51 and all motors recognize it. It also looks like they’ve changed 0x60 to properly rely on the existence of AB, which doesn’t unless we create the grouping in firmware.

In short, use the same commands to conte motor speed as you would an LED now, as it’ll now correctly work for all motors!

 

 

Edited by Mr Hobbles

Share this post


Link to post
Share on other sites

@Cosmik42As promised I posted about it in the Powered Up teardown thread. :) You can either form the AB virtual port back again manually, or migrate your motor commands to the Boost format, since they're now standarised. \o/ To note, I'd expect the Boost move hub to break with its next firmware update too. I imagine they'll also remove the auto combination port forming like they've done with the PUP hub.

Edited by Mr Hobbles

Share this post


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

Kinda...the main problem is they now follow their own spec to the letter! 😁

Basically virtual port AB is no longer implicitly created when you plug in two devices of the same type. It now expects you to send commands to manually create a grouping. This is something their LWP docs said we should do, but actually wasn’t possible until now. I’ll go into more detail in the other thread.

I was using the 0x60 subcommand to control the motors as it was the only one that could control all three, also due to bugs. That’s no longer the case - we can now use DirectModeWrite 0x51 and all motors recognize it. It also looks like they’ve changed 0x60 to properly rely on the existence of AB, which doesn’t unless we create the grouping in firmware.

In short, use the same commands to conte motor speed as you would an LED now, as it’ll now correctly work for all motors!

 

 

So my biggest issue is that on my side I need to keep both version compatible.
I cannot simply move to 0x51 because then I'll break backward compatibility.

I think my best option is to recreate the virtual AB group.
About to investigate how to do this.

Share this post


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

So my biggest issue is that on my side I need to keep both version compatible.
I cannot simply move to 0x51 because then I'll break backward compatibility.

I think my best option is to recreate the virtual AB group.
About to investigate how to do this.

That's fair. :) I've chosen not to support the older firmware and am instead putting a warning message in to ask people to upgrade.

However for you, to activate your virtual port I think the command you want is [0x06, 0x00, 0x61, 0x01, 0x00, 0x01], right after you get the port notifications for 0x00 and 0x01. This will cause an error you can just ignore on the old firmware. Also note that the combined port id will no longer be 0x39, it'll be 0x10 - but you can read that from the virtual port setup response, as the docs say it may vary (Though I don't see it happening on the PUP hub due to it only having two ports)

Share this post


Link to post
Share on other sites
On 4/13/2019 at 7:52 AM, Cosmik42 said:

So my biggest issue is that on my side I need to keep both version compatible.
I cannot simply move to 0x51 because then I'll break backward compatibility.

I think my best option is to recreate the virtual AB group.
About to investigate how to do this.

Hmm, the hubs will update their firmware automatically by switching them on when the original LEGO app is running. After a while the old firmware will be vanish anyway. Do you be convinced the extra work for downward compatibility is worth all the efforts?

Up to then we can use only SBricks and the move hub with the BAP software, the motor commands are ignored by all PUP hubs with actual firmware.

Share this post


Link to post
Share on other sites

@Giottist I agree.

But: if its only one line in the pogramm it should be easy to switch this according to release, that's my plan for my python-program.

In the moment I can't use BAP and not everything is prepared for the next convention coming in four weeks.
 

Share this post


Link to post
Share on other sites

[Irony] I've found a workaround for the motor issue with the actual PUP hub firmware: Just configure it as light - and you can go forward with full speed and stop - a little bit limited, but it works fine. OK you can't go backwards but hey, go one full loop around. [/Irony]

There is another argument not to support old and vanishing firmeware versions anymore. From now on LEGO will sell hubs only with the actual firmware, both as single component or as part of a set. So elder firmware versions will only found in hubs beeing ealier in the free market. And they will become lesser if they meet the app which will update elder versions to the actual one.

For programmers of PUP software the situation is not comfortable and somewhat confusing, since up to the hiring of JJ van Oosten as chief digital officer chaos and a lack of communication seemed to rule between the different teams like WeDo, PUP, Boost and so on. The unification has begun since his start in early March. I assume, his first measure was and is the unification of TLGs IT strategy and particular the new BT protocol.  I assume all diferences between the different product lines using BT will die out very quick. I recommend to continue only using the actual command codes. Updating old firmware is a matter of minutes and is reasonably.

Share this post


Link to post
Share on other sites

Alright guys - so I have a build, but it is not tested. I am on the road until Friday at which day I will be able to properly test my fixes localy.

For now I call if V1.3 Alpha to indicate its nature.

You can download it here: https://www.dropbox.com/sh/q4yhiyfgrtd3udx/AAB1nrm2637Ix4J2r40tXLFOa?dl=1

Would appreciate if some of you can test its stability!

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.