AVCampos Posted January 14, 2019 Posted January 14, 2019 Did you connect your hub to the official PUp app? The first time I did that with my Batmobile, the app updated the hub's firmware. Quote
Mr Hobbles Posted January 14, 2019 Posted January 14, 2019 (edited) 7 minutes ago, Lok24 said: 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 in about a quarter showing the project of Cosmik42 in the other thread! Yes, that *might* be related to the existing bug you mention, but I'm not sure. The PUP Hub has two ports, port A and port B, that you can individually send commands to. When you plug in two identical devices (eg. two train motors or two led lights), internally, the hub creates a new virtual port, AB, that you can send a single command to, to control both motors at the same time. The problem is, that Boost motor is both an output device *and* and input device, so when it tries to create the virtual port, it crashes, as multiplexing two input devices doesn't make sense. :) Apparently Lego will fix this in the future, but they haven't yet. So, in your case, plugging in a Boost motor and a Boost sensor would be two input devices, but I don't think it should try to multiplex them though, as they aren't identical devices (they have different device ids). I'll do some testing tonight to see what it does, just out of curiosity. :) Edited January 14, 2019 by Mr Hobbles Quote
Lok24 Posted January 14, 2019 Posted January 14, 2019 Just now, AVCampos said: Did you connect your hub to the official PUp app? The first time I did that with my Batmobile, the app updated the hub's firmware. Hi, yes, I did, and it did Quote
Mr Hobbles Posted January 14, 2019 Posted January 14, 2019 5 hours ago, rzido said: 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). Glad you found the library useful! That's a very good point though, I don't have an example for the Duplo train yet, and I don't document the motor strings in use (Sidenode, it's "MOTOR" as opposed to "A" or "B" because it's not a port that can be unplugged or replaced with something else). I'll add it to my to-do list for this week to dig out my Duplo train and make an example. :) Quote
Lok24 Posted January 14, 2019 Posted January 14, 2019 Hi Mr Hobbles, that explains it, would it be the same with the Wedo motors? Quote
Mr Hobbles Posted January 14, 2019 Posted January 14, 2019 Just now, Lok24 said: Hi Mr Hobbles, that explains it, would it be the same with the Wedo motors? 2x WeDo motors work fine as they are an output device only. Same with LED lights and train motors. All multiplex to port AB fine with no issues. It is only Boost motors that cause issues as they are an output device (you can sent motor drive commands to) and an input device (you can receive rotation angle notifications from) at the same time. Quote
Mr Hobbles Posted January 15, 2019 Posted January 15, 2019 11 hours ago, Mr Hobbles said: 2x WeDo motors work fine as they are an output device only. Same with LED lights and train motors. All multiplex to port AB fine with no issues. It is only Boost motors that cause issues as they are an output device (you can sent motor drive commands to) and an input device (you can receive rotation angle notifications from) at the same time. As a follow up, as promised, I tested your problem out this evening, and, can confirm, it happens to me too! So, the bug is not just limited to Boost motors, but to both the Boost motor and Boost color sensor too. So: Plugging 2x Boost devices into a PUP Hub will crash it and cause it to restart. :) 1x Boost device (and any other device) should work fine. Quote
treczoks Posted January 15, 2019 Posted January 15, 2019 1 hour ago, Mr Hobbles said: So: Plugging 2x Boost devices into a PUP Hub will crash it and cause it to restart. :) 1x Boost device (and any other device) should work fine. Both the Color Sensor and the Boost Motor need a UART connection to work. The Color Sensor communicates its settings and readings over this channel, the Boost Motor uses it for speed or angle data. My educated guess (from programming such embedded devices for a living): They either only have one UART interface on the chip and thus just don't have the resources to communicate to two smart devices, or allocation/mapping or driver of the second device has a bug. All in all, if one Boost Motor and one Color Sensor don't work, and two Boost Motors don't work too, then I would expect two Color Sensors to fail in a similar manner. Regardless of what the problem actually is, I would report this to LEGO Customer Service. Quote
Lok24 Posted January 15, 2019 Posted January 15, 2019 I expect (delivery this week) two WeDo motors and two WeDo sensors. I'll test and tell you what'll happen. @treczoks I understand what you mean, indeed the complete idea of compatiliby is useless if the simplest things don't work. Quote
Matt Dawson Posted January 15, 2019 Posted January 15, 2019 @treczoks That does actually make sense. It could be that there is only one UART interface (I don't recall any documentation saying it supports more than one input device either!) but I'd harbour the suggestion it crashes when the second device initiates a connection/feeds it info, and as it's not expecting input from this new device it causes the shutdown. The one thing to test would be if there is a differentiation between output A and B (i.e. one prefers sensors, the other motors), although I would think Lego would simply make them both the same with only the output reference changing. Quote
Lok24 Posted January 15, 2019 Posted January 15, 2019 (edited) 6 minutes ago, Matt Dawson said: @treczoks The one thing to test would be if there is a differentiation between output A and B (i.e. one prefers sensors, the other motors), although I would think Lego would simply make them both the same with only the output reference changing. It doesn't matter if sensor is assigned to A and motor to B or vice versa. Error is the same. Edited January 15, 2019 by Lok24 Quote
Bilout Posted January 15, 2019 Posted January 15, 2019 Hello all ! I'm new here and I'm fan of Lego trains. I use an arduino to control Lego power functions and I want also control powered up with the arduino. Is it possible ? If yes, do you know a document which explains how control powered up with an arduino ? Thank you for your help ! Bilout Quote
Lok24 Posted January 16, 2019 Posted January 16, 2019 Hi all, strange! Got now a second PoweredUp Hub. And: Boost sensor + Boost motor work together! the difference: the one not working I had already connected to the App and it made a FW upgrade the one working is "out of the Box". Is there a way to read the FW-version without updating? Quote
Mr Hobbles Posted January 16, 2019 Posted January 16, 2019 6 hours ago, Lok24 said: Hi all, strange! Got now a second PoweredUp Hub. And: Boost sensor + Boost motor work together! the difference: the one not working I had already connected to the App and it made a FW upgrade the one working is "out of the Box". Is there a way to read the FW-version without updating? Maybe...in my preliminary testing there's a command to retrieve it, but I'm unsure of the format of the returned data. Also the command doesn't seem to work on the Boost Move Hub. More testing required. :) Quote
Cosmik42 Posted January 17, 2019 Posted January 17, 2019 14 hours ago, Lok24 said: Hi all, strange! Got now a second PoweredUp Hub. And: Boost sensor + Boost motor work together! the difference: the one not working I had already connected to the App and it made a FW upgrade the one working is "out of the Box". Is there a way to read the FW-version without updating? Do you see similar crashing behavior with The Lego Train Project? I have tons of device and have never encountered a crashing of a Hub. Quote
Lok24 Posted January 17, 2019 Posted January 17, 2019 Yes, it is the same using your software or the handheld. And Mr Hobbles confirmed the behaviour. Quote
Cosmik42 Posted January 18, 2019 Posted January 18, 2019 @Mr Hobbles, do you know how to force an immediate disconnection from a Hub? I'd like to stop my software with a clean cut off of connections! Thanks! Quote
Lok24 Posted January 18, 2019 Posted January 18, 2019 (edited) The connctions are cut very quick (1-2 sec) after closing your software, immediately reconnect via handheld is no problem. Edited January 18, 2019 by Lok24 Quote
Cosmik42 Posted January 18, 2019 Posted January 18, 2019 (edited) 43 minutes ago, Lok24 said: The connctions are cut very quick (1-2 sec) after closing your software, immediately reconnect via handheld is no problem. Playing with these things all the time, I can tell you that some time not. It is unclear what triggers it, but I sometime have hubs who keep thinking they are connected, and it drives me crazy :) Edited January 18, 2019 by Cosmik42 Quote
treczoks Posted January 18, 2019 Posted January 18, 2019 (edited) On 1/16/2019 at 5:14 PM, Lok24 said: Is there a way to read the FW-version without updating? Yes, there is - if you have Linux+BT. I have no idea how this works under windows. If you don't know your hubs MAC address already find it with "hcitool lescan" (might need a "sudo"). The device you are looking for is called "HUB NO.4" or "Smart Hub". I use my Smart Hubs address in the following example: 90:84:2B:05:B1:C6 Enter "gatttool -b 90:84:2B:05:B1:C6 -I" to open the gatttool (yes, three t's!), it will give you a prompt like "[90:84:2B:05:B1:C6][LE]>", at which you enter "connect". The gatttool should reply "Attempting to connect" and then "Connection successful", and the LED on the hub should change from blinking to on. Now enter "char-write-req 000f 0100" to request messages, and then "char-write-req 000e 0500010305" to read the firmware version. The Smart Hub will reply with something like "Notification handle = 0x000e value: 09 00 01 03 06 00 00 03 10". The telegram 09 00 01 03 06 00 00 03 10 can be read as follows: 1. Byte 09: Message Length 2. Byte 00: Hub ID, always 0 3. Byte 01: Command ID for "Hub Property" 4. Byte 03: Kind of property requested, here: 03=Firmware Version 5. Byte 06: Sub-ID for "this is an information update" 6. and 7. Byte 0000: 4-digit BCD Build Number: V-.-.--/0000 8. Byte 03: 2-digit BCD Bug Fixing Number: V-.-.03/---- 9. Byte 10: Major (Bits 6..4) and Minor (Bits 3..0) Version Number: V1.0.--/---- So my Smart Hub has a version number of "V1.0.03/0000" - Build Numbers seem to be missing. Which I can understand, merging build numbers right into a binary build took some thinking back when I needed to do this... You can then "disconnect" from the hub, and "quit" the gatttool. Hope this helps. Maybe someone here can provide a Windows-way to do this. Edited January 18, 2019 by treczoks Removed double quote Quote
AVCampos Posted January 18, 2019 Posted January 18, 2019 It might be possible to do something similar in nRF Connect for Android, although I can't test it right now (I'm at work and my hub is at home). Quote
Mr Hobbles Posted January 18, 2019 Posted January 18, 2019 (edited) 2 hours ago, treczoks said: ...snip... Thank you for this! I was having trouble grokking the format used in the firmware reports. :) FYI, here's what one of my PUP Hubs reports: 1.0.03/0000 Here is one of my PUP Remotes: 1.0.00/0004 And here is one of my Boost Move Hubs: 1.0.00/0547 17 hours ago, Cosmik42 said: @Mr Hobbles, do you know how to force an immediate disconnection from a Hub? I'd like to stop my software with a clean cut off of connections! Thanks! Not sure what exact functionality you're looking for, but [0x03, 0x00, 0x02] seems to force a disconnect from the hubs side. But it doesn't turn it off - so it immediately goes back into searching mode, and if you're still scanning, you'll reconnect a second or two later. Usually though I just disconnect from my side and let the hub turn itself off. :) Edited January 18, 2019 by Mr Hobbles Quote
Mr Hobbles Posted January 18, 2019 Posted January 18, 2019 (edited) For completeness sake, I've discovered how to get the firmware revision from the WeDo 2.0 Smart Hub too. As usual, it's completely different. BLE Service 0x180a, Characteristic 0x2a26 freely reports requesting the firmware revision as a string. My hub reports [0x31, 0x2e, 0x30, 0x2e, 0x30, 0x39, 0x2e, 0x30, 0x30, 0x30, 0x30], which is simply "1.0.09.0000". In fact, service 0x180a and characteristic 0x2a26 are standard parts of the BLE spec. It was nice when TLG followed specs. :) https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.device_information.xmlhttps://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.characteristic.firmware_revision_string.xml I doubt the revisions of this are related to that of the Boost/PUP hubs though as the firmware is clearly different. It's likely a completely different project (read: older) within TLG. Edited January 18, 2019 by Mr Hobbles Quote
Cosmik42 Posted January 19, 2019 Posted January 19, 2019 18 hours ago, Mr Hobbles said: [0x03, 0x00, 0x02] seems to force a disconnect That's what I was looking for! Thanks! Quote
Lok24 Posted January 19, 2019 Posted January 19, 2019 On 1/18/2019 at 5:29 PM, treczoks said: Hope this helps. Maybe someone here can provide a Windows-way to do this. Yes, that helps a lot. Thank you fo this good explanantion. I now checked my two Powered Up Hubs and found out the following: The one which allows 2 sensors or 1 sensor and one 1 boost-motor attached has version 01 10 The one which allows only one sensor has version 03 10 I did it with my RasberryPi! Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.