ColorSensors: Byte 2/3/4. #8
Comments
|
Hi. You might be right about 2nd byte, but more than 255 bytes in one BLE command seems rather strange (default MTU doesn't support that, I believe). Also reserving a byte for future seems a waste when commands are already so long. If LEGO developers want to add commands they just need to release a new firmware [and break everything I got til now]. 4th byte is indeed related to the port - 01, 02, 37, 38 and 39 are observed (39 for A+B) And yes, the 3rd byte seems to be the opcode or packet type. I wish the BOOST App had names for the blocks so I could at least match their names with the opcodes. |
I don't think that this is an option. They can't arbitrarily change the protocol or the apps will break. But maybe this is a version field. v0.
Note that the port is really dynamic. When you connect to the device you get the 0x4 packets which give you the available ports & types (i.e. the mapping). 39 is a port group, quite likely defined by the 0x2 value on byte 5 (maybe the 0x2 is even the child port count). Note how the port group denotes the child ports in byte 8&9.
That the blocks have no explanation is really awkward. You never know what they do ... |
|
3A is the internal 6-axis tilt sensor, just added a new file for it I have a new idea for the 4th byte:
|
|
Port 3A, that would be port type 0x28, cool. So that leaves port types 0x14/0x15 as unknown. Wrt the 4th byte, I really don't think that you are supposed to hardcode types to port numbers, but instead use the port/type mapping reported using the 0x4 packets on connect. Though I guess it doesn't matter for a specific device ;-) |
|
I think one of those last port types is the battery. It is bothering me that there isn't a standard characteristic for Battery like they did with WeDo 2.0. But the App reads battery level and warns when it is bellow some threshold so it must read somewhere. |
|
I already got a warning when motors got stalled, the LED changes color and/or blinks (don't remember). Perhaps there is an overcurrent sensor inside? |
|
Forget last one. Most probably it's the button. |
|
05:00:03:01:03 Need to get a good capture of the startup and post. |
|
I can initialize 3b and 3c devices but don't understand what they do: 3B: and then it keeps changing 83 / 82, sometimes stops for a while then start again 3C: and then it keeps slowly decreasing. Battery level? 59h = 89d = 8.9 Volt ? |
|
Well, they have device types 0x1x - so maybe 0x1x ports are system ports, like battery? |
|
So something like current consumption and voltage level? |
|
I did snapshots of the notifications before and after a low battery change. I don't think the 3C port is battery, it actually looks like a counter (countdown), maybe a keepalive ping? Look at that (and it goes on): and after the change: |
|
Port numbers and device numbers seem to re-use the values from the WeDo 2.0. So port 3b and 3c would actually be the "current" and "voltage" ports. The devices reported there on the connection event are 0x15 and 0x14 which in WeDo 2.0 was "Current sensor" and "Voltage sensor". One can actually connect WeDo-2,0-Devices to the Boost port C and D and they are correctly reported. But they need to be enabled like all other sensors before they deliver values. BTW: It seems the third last byte in the motor command (the one that's usually 100) seems to be some current limit. If you lower it the motor becomes weak and can easily be stopped. If that happens the LED on the Boost starts blinking. |
|
Ah nice, is the WeDo protocol documented somewhere? |
|
Yes, it's buried in the source code of the wedo developent kit: https://education.lego.com/en-us/support/wedo-2/developer-kits But it's quite hard to find the interesting data inside. Also quite useful is this: |
|
I have a few posts also: |
|
And that info about WeDo 2.0 is great because I got these notifications with the WeDo sensors: So 22 is the WeDo 2.0 Tilt Sensor and 23 is the WeDo 2.0 Distance Sensor |
|
Yes, that's what i meant in the previous posting. I'll try to send one of the enable commands as used with the color and tilt sensors to these and see if they start delivering values. Also controlling the WeDo 2.0 motor would be interesting. |
|
I'm not sure I can follow you. So the traffic above is stuff you captured using WeDo? Or you connected WeDo sensors to the Boost ports? |
|
Yes, it's the messages the Boost reports when connecting wedo sensors to it. |
|
Can you actually buy WeDo stuff as a private user? |
|
Sure. Even Amazon sells them. But they are the same price as the boost but have way less features. |
|
You can buy through LEGO Education or you can buy in Bricklink. |
|
@harbaum I tried to enable 22 and 22 devices but my Move Hub crashes and need to take battery off. |
|
As @harbaum says, you can buy the stuff from Lego on Amazon.de. But the WeDo hub uses a different BLE protocol? |
|
Yes, several services instead of just one. And the battery is a standard GATT service. |
|
@JorgePe How did you try that? 22/23 would be the device types, not the port, right? That would be 0x1/0x2. |
|
Funny stuff is that wedo 2.0 uses the uuid of some led button service by nordic semiconducturs. Seems to me that the wedo still included a lot of demo code they took from nordic. This is interesting because the OID of the mac address was from TI. So it looks like they took a TI chip and used some code from nordic semi on it and released that as the wedo 2.0. Now they seem to have cleaned up a lot :-) |
|
To enable the distance sensor 0a00413b000100000001 |
|
I'd simply send "0a004101000100000001" to a sensor connected to port C |
|
There is an internal resistor or/and a connection to ground that identifies the motors (probably also the sensors). |
|
We can make the WeDo 2.0 think that any motor is a WeDo 2.0 motorby using this AutoID trick: Tonight I'll try the same with the BOOST. |
|
Since the boost recognizes the motor with it's correct type i'd be pretty surprised if it cannot control it. But the wedo motor doesn't include the encoder required for angle and speed measurement. So indeed some other command may be needed. |
|
I had hope that timed command was enough. Timed command doesn't use encoders info from BOOST motors. |
|
I may remember that wrong, but I think @hobbyquaker said that the timed commands probably use the encoder (and are not very reliable due to this, depending on the duty cycle). |
|
Eh eh It works!!!! |
|
I just copy the command for RGB LED, changed 32 to 01 and last byte put 64 as Duty Cycle. |
|
08008102 115100 xx also works on port D as expected |
|
I think the commands are: 0x11 = "something" for Non Encoded motors 0x51 0x00 -> changing these values does nothing at all |
|
0x0C - Angle Multi Value for groups of encoded motors |
|
|
Port 0x17 and port 0x01, hm. Maybe 0x17 is a motor group which includes 0x01? Do you get a port registration for 0x17? (a 0x4 packet). |
|
Just get these 8 lines I already wrote above
|
|
Nop. |
The 0x11 is always there in any write to 0x81 i've seen so far. The 0x51 is where the other motor commands have their 0x09, 0x0a, 0x0b, ... And i am sure i've seen a 0x07 as a motor command as well somewhere else. |
|
I'm totally lost on this 4th byte:
|
If I write a different first byte (message length) it also works. Not the first time that I see the Move Hub ignoring the message length indication. |
|
It doesn't run for 3 seconds. It runs forever. But it stops a few seconds after the bluetooth connection is terminated. Thus it stops. |
|
Good, at least I know why cannot control timing. |
|
For "stop" i'd try sending a speed of 0. I also tested this and this command is acknowledged as being "finished" even if the motor is still running. I am not sure there's a timed version for this motor. |
|
Yes, that works. |
|
I made a short video showing WeDo 2.0 motors with the BOOST Move Hub: |
|
Playing around with all kinds of sensor config parameters gives funny results. E.g. try sending a different number where the '8' is in the enable color sensor command. A 2 makes it light green, a 3 makes it light red, a 4 makes it light blue. And i am not talking about the built-in led. I am talking about the color sensor which can change color itself :-) All the other sensors seem to have special modes as well. The WeDo-Sensor e.g. has a step counter like mode. |
|
Oh, wow. A "6" makes it return 3*16 bit RGB values instead of the color indices. Now i need to find an RGB mode for the built-in LED .... |
|
Can you talk packets? :-) I can't really follow you. E.g.
You mean in a 0x45 (subscribe) packet? Or do you 0x81 write to the port? Does it affect the colours it can read? (maybe it changing the color is just a side effect for changing the color reading mode?) |
|
It's a little hard to talk packets since i have abstracted most packet generation away in my setup. Instead of And yes, this changes everything. Totally different values are returned for different settings. |
|
Yes, I think this is an I was thinking about |
|
It's an effect of the 0x41 command. I would call the command "sensor set mode". It's always the same command which has a different effect on different sensors. |
|
That's one of the blocks on the App I (we) had not sniffed yet. |
|
There are tons of other Formats. If you send an unsupported format request then a 05 error event is generated. So all settings which don't raise an error are probably valid. |
Color Sensor says:
I think the second byte might be the high byte of the length, there are just no packets longer than 0xFF yet. Or reserved, not sure.
The 3rd byte is quite clearly the packet type.
The 4th byte seems to be the port (as registered by the 0x4 packets). 0x01, the color-distance sensor, at least in my setup.
The text was updated successfully, but these errors were encountered: