ColorSensors: Byte 2/3/4. about boostreveng HOT 93 OPEN

The WeDo motor has type 0x01. That's correct. That's exactly the message i'd expect.

from boostreveng.

I just copy the command for RGB LED, changed 32 to 01 and last byte put 64 as Duty Cycle.
lucky guess, but motor spins
9B spins opposite

from boostreveng.

Sure. Even Amazon sells them. But they are the same price as the boost but have way less features.

from boostreveng.

You are confusing ports and devices...

0x3b is the port of the internal tilt sensor and 0x28 is the internal tilt sensor device. So you need to use 0x01 (for port C) or 0x02 (for port D) as the port. Not 0x22 as this is the device.

from boostreveng.

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.

from boostreveng.

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.

from boostreveng.

If LEGO developers want to add commands they just need to release a new firmware

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.

4th byte is indeed related to the port - 01, 02, 37, 38 and 39 are observed

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.

                 /- Port (A=0x37, B=0x38, C=0x01, D=0x02, AB=0x39)
                 |
                 |  /- On/Off/2
                 |  |
        /- len!  |  |  /- Device Type (just 0x04 packets?)
        |        |  |  |
        0. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10 11 12 13 14
  data: 0f 00 04 01 01 25 00 00 00 00 10 00 00 00 10   - Port C, color/distance sensor[0x25]
  data: 0f 00 04 02 01 26 00 00 00 00 10 00 00 00 10   - Port D, iMotor
  data: 0f 00 04 37 01 27 00 00 00 00 10 00 00 00 10   - Port A, Motor
  data: 0f 00 04 38 01 27 00 00 00 00 10 00 00 00 10   - Port B, Motor
  data: 09 00 04 39 02 27 00 37 38                     - Port AB, len: 9 (Motor?) What is 2?
  data: 0f 00 04 32 01 17 00 00 00 00 10 00 00 00 10   - LED
  data: 0f 00 04 3a 01 28 00 00 00 00 10 00 00 00 02   - what?
  data: 0f 00 04 3b 01 15 00 02 00 00 00 02 00 00 00   - what?
  data: 0f 00 04 3c 01 14 00 02 00 00 00 02 00 00 00   - what?
              |
              \- packet-type 0x4

I wish the BOOST App had names.

That the blocks have no explanation is really awkward. You never know what they do ...

from boostreveng.

3A is the internal 6-axis tilt sensor, just added a new file for it

I have a new idea for the 4th byte:

• above 30 is the address or port of an internal device
• 01 and 02 are addresses of external devices or just the addresses of the ports that allow external devices

from boostreveng.

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 ;-)
Yup, the ports below 30 seem to be the external ones. But why would you care? :-)

from boostreveng.

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.

from boostreveng.

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?

from boostreveng.

Forget last one. Most probably it's the button.

from boostreveng.

Forget last one. Most probably it's the button.
Nop. The button is one of the several devices that App initiates at start with several short commands like

05:00:03:01:03

Need to get a good capture of the startup and post.

from boostreveng.

I can initialize 3b and 3c devices but don't understand what they do:

3B:

gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0f --value=0100; gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=0a00413b000100000001 --listen
Characteristic value was written successfully
Characteristic value was written successfully
Notification handle = 0x000e value: 0a 00 47 3b 00 01 00 00 00 01 
Notification handle = 0x000e value: 06 00 45 3b 82 00 
Notification handle = 0x000e value: 06 00 45 3b 81 00 
Notification handle = 0x000e value: 06 00 45 3b 82 00 
Notification handle = 0x000e value: 06 00 45 3b 81 00 
Notification handle = 0x000e value: 06 00 45 3b 82 00 
Notification handle = 0x000e value: 06 00 45 3b 83 00 

and then it keeps changing 83 / 82, sometimes stops for a while then start again

3C:

gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0f --value=0100; gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=0a00413c000100000001 --listen
Characteristic value was written successfully
Characteristic value was written successfully
Notification handle = 0x000e value: 0a 00 47 3c 00 01 00 00 00 01 
Notification handle = 0x000e value: 06 00 45 3c 58 0c 
Notification handle = 0x000e value: 06 00 45 3c 59 0c 
Notification handle = 0x000e value: 06 00 45 3c 58 0c 
Notification handle = 0x000e value: 06 00 45 3c 59 0c 
Notification handle = 0x000e value: 06 00 45 3c 58 0c 
Notification handle = 0x000e value: 06 00 45 3c 59 0c 
Notification handle = 0x000e value: 06 00 45 3c 58 0c 
Notification handle = 0x000e value: 06 00 45 3c 59 0c 
Notification handle = 0x000e value: 06 00 45 3c 58 0c 
Notification handle = 0x000e value: 06 00 45 3c 59 0c 
Notification handle = 0x000e value: 06 00 45 3c 58 0c 
Notification handle = 0x000e value: 06 00 45 3c 57 0c 

and then it keeps slowly decreasing. Battery level? 59h = 89d = 8.9 Volt ?
It can also be an internal timer/watchdog

from boostreveng.

Well, they have device types 0x1x - so maybe 0x1x ports are system ports, like battery?

from boostreveng.

So something like current consumption and voltage level?
Will try to check this tonight.

from boostreveng.

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):

ERROR: could not decode packet: <UnsupportedPacket: 06-00-45-3c-ce-0a> CE=206
ERROR: could not decode packet: <UnsupportedPacket: 06-00-45-3c-cd-0a> CD=205
ERROR: could not decode packet: <UnsupportedPacket: 06-00-45-3c-cc-0a> CC=204
ERROR: could not decode packet: <UnsupportedPacket: 06-00-45-3c-cb-0a> CB=203
ERROR: could not decode packet: <UnsupportedPacket: 06-00-45-3c-ca-0a> CA=202
ERROR: could not decode packet: <UnsupportedPacket: 06-00-45-3c-c9-0a>
ERROR: could not decode packet: <UnsupportedPacket: 06-00-45-3c-c8-0a>
ERROR: could not decode packet: <UnsupportedPacket: 06-00-45-3c-c7-0a>
ERROR: could not decode packet: <UnsupportedPacket: 06-00-45-3c-c6-0a>
ERROR: could not decode packet: <UnsupportedPacket: 06-00-45-3c-c5-0a>
ERROR: could not decode packet: <UnsupportedPacket: 06-00-45-3c-c4-0a>
ERROR: could not decode packet: <UnsupportedPacket: 06-00-45-3c-c3-0a>
ERROR: could not decode packet: <UnsupportedPacket: 06-00-45-3c-c2-0a>
ERROR: could not decode packet: <UnsupportedPacket: 06-00-45-3c-c1-0a>

and after the change:

ERROR: could not decode packet: <UnsupportedPacket: 06-00-45-3c-ef-0d> 239
ERROR: could not decode packet: <UnsupportedPacket: 06-00-45-3b-a3-00>
ERROR: could not decode packet: <UnsupportedPacket: 06-00-45-3b-a4-00>
ERROR: could not decode packet: <UnsupportedPacket: 06-00-45-3c-ee-0d> *
ERROR: could not decode packet: <UnsupportedPacket: 06-00-45-3b-a3-00>
ERROR: could not decode packet: <UnsupportedPacket: 06-00-45-3b-a4-00>
ERROR: could not decode packet: <UnsupportedPacket: 06-00-45-3c-ed-0d> *
ERROR: could not decode packet: <UnsupportedPacket: 06-00-45-3b-a3-00>
ERROR: could not decode packet: <UnsupportedPacket: 06-00-45-3b-a4-00>
ERROR: could not decode packet: <UnsupportedPacket: 06-00-45-3b-a3-00>
ERROR: could not decode packet: <UnsupportedPacket: 06-00-45-3c-ec-0d> *

from boostreveng.

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.

from boostreveng.

Ah nice, is the WeDo protocol documented somewhere?

from boostreveng.

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:
https://github.com/cpseager/WeDo2-BLE-Protocol/blob/master/wedo2_summary.txt

from boostreveng.

I have a few posts also:
http://ofalcao.pt/blog/2016/wedo-2-0-reverse-engineering

from boostreveng.

And that info about WeDo 2.0 is great because I got these notifications with the WeDo sensors:

tilt C
0f 00 04 01 01 22 00 00 00 00 10 00 00 00 10 

remove
05 00 04 01 00

tilt D
0f 00 04 02 01 22 00 00 00 00 10 00 00 00 10

remove
05 00 04 02 00

dist C
0f 00 04 01 01 23 00 00 00 00 10 00 00 00 10

remove
05 00 04 01 00

dist D
0f 00 04 02 01 23 00 00 00 00 10 00 00 00 10

remove
05 00 04 02 00

So 22 is the WeDo 2.0 Tilt Sensor and 23 is the WeDo 2.0 Distance Sensor
(and yes, in fact they they are)

from boostreveng.

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.

from boostreveng.

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?

from boostreveng.

Yes, it's the messages the Boost reports when connecting wedo sensors to it.

from boostreveng.

Can you actually buy WeDo stuff as a private user?

from boostreveng.

You can buy through LEGO Education or you can buy in Bricklink.
I don't consider WeDo 2.0 less featured. It just lacks the servo/tacho motors but the firmware seems better planned and at least I can get more colors with the color sensor.

from boostreveng.

@harbaum I tried to enable 22 and 22 devices but my Move Hub crashes and need to take battery off.

from boostreveng.

As @harbaum says, you can buy the stuff from Lego on Amazon.de.

But the WeDo hub uses a different BLE protocol?

from boostreveng.

Yes, several services instead of just one. And the battery is a standard GATT service.

from boostreveng.

@JorgePe How did you try that? 22/23 would be the device types, not the port, right? That would be 0x1/0x2.

from boostreveng.

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 :-)

from boostreveng.

To enable the distance sensor 0a00413b000100000001
So to enable WeDo2 tilt I tried 0a004122000100000001
where should i put the port?

from boostreveng.

I'd simply send "0a004101000100000001" to a sensor connected to port C

from boostreveng.

I love you!

gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0f --value=0100; gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=0a004101000100000001 --listen
Characteristic value was written successfully
Characteristic value was written successfully
Notification handle = 0x000e value: 0a 00 47 01 00 01 00 00 00 01 
Notification handle = 0x000e value: 06 00 45 01 00 00 
Notification handle = 0x000e value: 06 00 45 01 00 ff 
Notification handle = 0x000e value: 06 00 45 01 00 00 
Notification handle = 0x000e value: 06 00 45 01 00 ff 
Notification handle = 0x000e value: 06 00 45 01 00 00 

from boostreveng.

Well ...

from boostreveng.

Excellent. So this is now exceeding the capabilities of the lego app which is where things are getting interesting ...

from boostreveng.

gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0f --value=0100; gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=0a004102000100000001 --listen
Characteristic value was written successfully
Notification handle = 0x000e value: 0f 00 04 3c 01 14 00 02 00 00 00 02 00 00 00 
Characteristic value was written successfully
Notification handle = 0x000e value: 0a 00 47 02 00 01 00 00 00 01 
Notification handle = 0x000e value: 05 00 45 02 00 
Notification handle = 0x000e value: 05 00 45 02 01 
Notification handle = 0x000e value: 05 00 45 02 04 
Notification handle = 0x000e value: 05 00 45 02 07 
Notification handle = 0x000e value: 05 00 45 02 06 
Notification handle = 0x000e value: 05 00 45 02 05 

from boostreveng.

3C is the motor, what port registration do you get for port 0x02?

from boostreveng.

And the WeDo tilt sensor can only do a single value? (the notification payload is just a byte?)

from boostreveng.

3c is the internal voltage port. The wedo2.0 motor should be recognized as device 0x01.

ISR that yes, the Wedo2.0 tilt sensor is 1 dimensional indeed.

from boostreveng.

slowdown boys, its monday and my brain is a mess

WeDo2 motor on C
0a 00 47 01 00 01 00 00 00 01

port 47?

from boostreveng.

no, this is the subscription acknowledgement (packet type 0x47, port 0x01 - you subscribed to that successfully)

from boostreveng.

That's reply code 47 for port 01

from boostreveng.

I need to read all your recent updates again, I'm a bit lost.
How do I get port registrations?

from boostreveng.

I'd try one of the commands that work for the boost motor on port C also with that motor. So the command should be the same.

from boostreveng.

The port registration come in when you connect to the BLE device. They tell which port has which device type attached. I don't know how you do that with your cmdline tool. Essentially you immediately need to start listening when you connect. You should get a 0x4 packet for each port.

from boostreveng.

You get port registrations automatically once you enable notifications on that characteristic.

from boostreveng.

This "--char-write-req --handle=0x0f --value=0100" enables them.

from boostreveng.

Those are the subscriptions. The registrations arrive right after the connect. (they don't need to be enabled, they are automatically sent after the device is connected)

from boostreveng.

Huh? Nothing will be sent by default. You either send explicit requests or you enable notifications.

from boostreveng.

Yes, I've done that. That's the only characteristic available (except the general).
But I've got none.
And for the motor C I already tried,nothing. The Move hUb recongnizes the motor but there must be a different command or at least a diferrent byte.

from boostreveng.

How do you know it recognizes the wedo motor?

from boostreveng.

gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0f --value=0100 --listen

Power ON with just WeDo2 motor on port C:

Characteristic value was written successfully
Notification handle = 0x000e value: 0f 00 04 01 01 01 00 00 00 00 00 00 00 00 00
Notification handle = 0x000e value: 0f 00 04 37 01 27 00 00 00 00 10 00 00 00 10
Notification handle = 0x000e value: 0f 00 04 38 01 27 00 00 00 00 10 00 00 00 10
Notification handle = 0x000e value: 09 00 04 39 02 27 00 37 38
Notification handle = 0x000e value: 0f 00 04 32 01 17 00 00 00 00 10 00 00 00 10
Notification handle = 0x000e value: 0f 00 04 3a 01 28 00 00 00 00 10 00 00 00 02
Notification handle = 0x000e value: 0f 00 04 3b 01 15 00 02 00 00 00 02 00 00 00
Notification handle = 0x000e value: 0f 00 04 3c 01 14 00 02 00 00 00 02 00 00 00

from boostreveng.

There it is:
Notification handle = 0x000e value: 0f 00 04 01 01 01 00 00 00 00 00 00 00 00 00

Device type 0x01 (wedo motor) on port 0x01 (port c)

from boostreveng.

Huh? Nothing will be sent by default. You either send explicit requests or you enable notifications.

I get them, @hobbyquaker gets them. In fact you need to wait for them before you can send commands to the ports. ¯_(ツ)_/¯

from boostreveng.

Perhaps we are confusing terminology here. But a BLE device will send nothing unless asked for attribute values or unless you enable notifications for a characterstic. What do you mean by "subscriptions"? BLE notifications?

from boostreveng.

That value doesn't look very good, it has 0x01 as the type?

Oh, OK, yes. Of course you need to enable BLE notifications. That layer is of no interest :-)

from boostreveng.

It recognizes something, or at least something invalid.
But if it recognizes WeDo2 sensors, it would make sense also Motor

from boostreveng.

So what should the timed command for motor type 01 be?

from boostreveng.

Try "0C0081011109640032647f03" for port C.

from boostreveng.

The command should be the same as for the external boost motor. Commands are sent to ports, not devices. So the motor type shouldn't matter.

from boostreveng.

Already tried that. Nope.

from boostreveng.

The external boos motor has a different AutoID than the WeDo 2.0 motor.
So the firmware must know the difference. There must be a different command. Or no command at all.

from boostreveng.

What is the "AutoID"?

from boostreveng.

There is an internal resistor or/and a connection to ground that identifies the motors (probably also the sensors).
WeDo 2.0 motor has a 2k2 resistor between pin 3 and 4 and pin 3 also connects to pin 6.
BOOST interactive motor also has a 2k2 resistor but between pin 3 and 5 and not foind any other connection yet.
Some think that pin 3 is GND, pin 4 is VCC, pin 6 is ADC_IN.
MINDSTORMS EV3 has a simillar AutoID proptocol.
Some Power Functions motors and the WeDo 1.0 (USB) sensor also have.

from boostreveng.

We can make the WeDo 2.0 think that any motor is a WeDo 2.0 motorby using this AutoID trick:
https://www.youtube.com/watch?v=YKgTLXC89CI

Tonight I'll try the same with the BOOST.

from boostreveng.

I had hope that timed command was enough. Timed command doesn't use encoders info from BOOST motors.

from boostreveng.

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).

from boostreveng.

Eh eh
gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=0800810111510064
Characteristic value was written successfully

It works!!!!

from boostreveng.

08008102 115100 xx also works on port D as expected
But no idea of the meaning of 115100 and how to control timing

from boostreveng.

I think the commands are:

0x09 - Time Value for Encoded motors
0x0A - Time Multi Motor Value for Encoded motors
0x0B - Angle Value for Encoded motors

0x11 = "something" for Non Encoded motors

0x51 0x00 -> changing these values does nothing at all

from boostreveng.

0x0C - Angle Multi Value for groups of encoded motors

from boostreveng.

0800811711510032 and 0800810111510032
do the same.
Why?

from boostreveng.

                 /- Port (C=0x01, D=0x02, AB=0x39)
                 |
        /- len   |  /- non-encoded motor cmd?
        |        |  |
        0. 1. 2. 3. 4. 5. 6. 7.
  data: 08 00 81 17 11 51 00 32
  data: 08 00 81 01 11 51 00 32
              |
              \- packet-type 0x81

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).

from boostreveng.

Just get these 8 lines I already wrote above

gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0f --value=0100 --listen
Characteristic value was written successfully
Notification handle = 0x000e value: 0f 00 04 01 01 01 00 00 00 00 00 00 00 00 00 
Notification handle = 0x000e value: 0f 00 04 37 01 27 00 00 00 00 10 00 00 00 10 
Notification handle = 0x000e value: 0f 00 04 38 01 27 00 00 00 00 10 00 00 00 10 
Notification handle = 0x000e value: 09 00 04 39 02 27 00 37 38 
Notification handle = 0x000e value: 0f 00 04 32 01 17 00 00 00 00 10 00 00 00 10 
Notification handle = 0x000e value: 0f 00 04 3a 01 28 00 00 00 00 10 00 00 00 02 
Notification handle = 0x000e value: 0f 00 04 3b 01 15 00 02 00 00 00 02 00 00 00 
Notification handle = 0x000e value: 0f 00 04 3c 01 14 00 02 00 00 00 02 00 00 00 

The fifth line, 0f 00 04 32 01 17 00 00 00 00 10 00 00 00 10
32 is the RGB LED... or is something more? I had lucky using the command for RGB LED or is there any relation between LED and motor?

from boostreveng.

Nop.
080081 01 11510032 doess the same if I change 01 by several other bytes, 04 and above up to 31
(but not 02 or 03 or 32)

from boostreveng.

...
0x11 = "something" for Non Encoded motors

0x51 0x00 -> changing these values does nothing at all

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.

from boostreveng.

I'm totally lost on this 4th byte:

• for a WeDo 2.0 motor on port C can use 01 or any value beetween 04...31
• for same motor on port D only 02 works, as expected
  What are those 04..31 ports? Alias to 01? Why?

from boostreveng.

0700810111 01 xx controls WeDo 2.0 motor on port C where xx is Duty Cycle (PWM) for about 3 seconds

0800810111 5100 xx  does the same

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.

from boostreveng.

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.

from boostreveng.

Good, at least I know why cannot control timing.
Now there must be a stop command and a damn timed command.

from boostreveng.

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.

from boostreveng.

Yes, that works.
It doesn't make sense not having a timed command... unless the timing is not done on the Move Hub side but on the Interactive Motor itself. I wish Philo had already opened its BOOST devices, don't wnat to mess with mines right now.

from boostreveng.

I made a short video showing WeDo 2.0 motors with the BOOST Move Hub:
https://youtu.be/RNBSJTIzT8o

from boostreveng.

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.

from boostreveng.

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 ....

from boostreveng.

Can you talk packets? :-) I can't really follow you. E.g.

try sending a different number where the '8' is in the enable color sensor command

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?)

from boostreveng.

It's a little hard to talk packets since i have abstracted most packet generation away in my setup. Instead of
0a004101080100000001
send
0a004101060100000001
and you'll get 3*16 Bit RGB

And yes, this changes everything. Totally different values are returned for different settings.

from boostreveng.

Yes, I think this is an option field (I think @hobbyquaker came up with that naming ;-) ).

I was thinking about color sensor which can change color itself. This can change color itself, is that a side effect of the 0x41 subscription, or can you just change the color of the sensor? (i.e. using a 0x81)

from boostreveng.

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.

from boostreveng.

That's one of the blocks on the App I (we) had not sniffed yet.
Who knows what other commands are still there...

from boostreveng.

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.

from boostreveng.