BOOST Color and Distance Sensor info #33
Comments
Cheat-sheet for interpreting messages// FIRST BYTE |
|
Here is the results in table form:
Feel free to copy and paste this somewhere in the repo. |
|
One pattern I noticed with the unknown values is that the output modes ( |
|
Here is the BOOST Interactive motor dump: click to expand40 MESSAGE_CMD + LENGTH_1 + CMD_TYPE 26 Type = 38; BOOST Interactive Motor 99 checksum 49 MESSAGE_CMD + LENGTH_2 + CMD_MODES 03 3 + 1; Modes = 4 02 2 + 1; Views = 3 b7 checksum 52 MESSAGE_CMD + LENGTH_4 + CMD_SPEED 00 LSB c2 .. 01 .. 00 MSB; BitRate = 115200 6e checksum 5f MESSAGE_CMD + LENGTH_8 + CMD_UNK1 (new PF2 command) 00 LSB 00 .. 00 .. 10 MSB; ??? = 0x10000000 00 LSB 00 .. 00 .. 10 MSB; ??? = 0x10000000 a0 checksum 93 MESSAGE_INFO + LENGTH_4 + MODE_3; 00 INFO_NAME 54 'T' 45 'E' 53 'S' 54 'T'; Name = "TEST" 7a checksum 9b MESSAGE_INFO + LENGTH_8 + MODE_3; 01 INFO_RAW 00 LSB 00 .. c8 .. c2 MSB; RawMin = -100.0 00 LSB 00 .. c8 .. 42 MSB; RawMax = 100.0 e5 checksum 9b MESSAGE_INFO + LENGTH_8 + MODE_3; 02 INFO_PCT 00 LSB 00 .. c8 .. c2 MSB; PctMin = -100.0 00 LSB 00 .. c8 .. 42 MSB; PctMax = 100.0 e6 checksum 9b MESSAGE_INFO + LENGTH_8 + MODE_3; 03 INFO_SI 00 LSB 00 .. c8 .. c2 MSB; SiMin = -100.0 00 LSB 00 .. c8 .. 42 MSB; SiMax = 100.0 e7 checsum 93 MESSAGE_INFO + LENGTH_4 + MODE_3; 04 INFO_SYMBOL 54 'T' 53 'S' 54 'T' 00 ''; Symbol = "TST" 3b checksum 8b MESSAGE_INFO + LENGTH_2 + MODE_3; 05 INFO_UNK1 00 ??? 00 ??? 71 checksum 93 MESSAGE_INFO + LENGTH_4 + MODE_3; 80 INFO_FORMAT 05 DataSets = 5 01 Format = DATA16 06 Digits = 6 00 Decimals = 0 ee checksum 92 MESSAGE_INFO + LENGTH_4 + MODE_2 00 INFO_NAME 50 'P' 4f 'O' 53 'S' 00 ''; Name = "POS" 21 checksum 9a MESSAGE_INFO + LENGTH_8 + MODE_2 01 INFO_RAW 00 LSB 00 .. b4 .. c3 MSB; RawMin = -360.0 00 LSB 00 .. b4 .. 43 MSB; RawMax = 360.0 e4 checksum 9a MESSAGE_INFO + LENGTH_8 + MODE_2 02 INFO_PCT 00 LSB 00 .. c8 .. c2 MSB; PctMin = -100.0 00 LSB 00 .. c8 .. 42 MSB; PctMax = 100.0 e7 checksum 9a MESSAGE_INFO + LENGTH_8 + MODE_2 03 INFO_SI 00 LSB 00 .. b4 .. c3 MSB; SiMin = -360.0 00 LSB 00 .. b4 .. 43 MSB; SiMax = 360.0 e6 checksum 92 MESSAGE_INFO + LENGTH_4 + MODE_2 04 INFO_SYMBOL 44 'D' 45 'E' 47 'G' 00 ''; Symbol = "DEG" 2f checksum 8a MESSAGE_INFO + LENGTH_2 + MODE_2 05 INFO_UNK1 08 ??? 00 ??? 78 checksum 92 MESSAGE_INFO + LENGTH_4 + MODE_2 80 INFO_FORMAT 01 DataSets = 1 02 Format = DATA32 06 Figures = 6 00 Decimals = 0 e8 checksum 99 MESSAGE_INFO + LENGTH_8 + MODE_1 00 INFO_NAME 53 'S' 50 'P' 45 'E' 45 'E' 44 'D' 00 '' 00 '' 00 ''; Name = "SPEED" 21 checksum 99 MESSAGE_INFO + LENGTH_8 + MODE_1 01 INFO_RAW 00 LSB 00 .. c8 .. c2 MSB; RawMin = -100.0 00 LSB 00 .. c8 .. 42 MSB; RawMax = 100.0 e7 checksum 99 MESSAGE_INFO + LENGTH_8 + MODE_1 02 INFO_PCT 00 LSB 00 .. c8 .. c2 MSB; PctMin = -100.0 00 LSB 00 .. c8 .. 42 MSB; PctMax = 100.0 e4 checksum 99 MESSAGE_INFO + LENGTH_8 + MODE_1 03 INFO_SI 00 LSB 00 .. c8 .. c2 MSB; SiMin = -100.0 00 LSB 00 .. c8 .. 42 MSB; SiMax = 100.0 e5 checksum 91 MESSAGE_INFO + LENGTH_4 + MODE_1 04 INFO_SYMBOL 50 'P' 43 'C' 54 'T' 00 ''; Symbol = "PCT" 2d checksum 89 MESSAGE_INFO + LENGTH_2 + MODE_1 05 INFO_UNK1 10 ??? 00 ??? 63 checksum 91 MESSAGE_INFO + LENGTH_4 + MODE_1 80 INFO_FORMAT 01 DataSets = 1 00 Format = DATA8 04 Figures = 4 00 Decimals = 0 eb checksum 98 MESSAGE_INFO + LENGTH_8 + MODE_0 00 INFO_NAME 50 'P' 4f 'O' 57 'W' 45 'E' 52 'R' 00 '' 00 '' 00 ''; Name = "POWER" 38 checksum 98 MESSAGE_INFO + LENGTH_8 + MODE_0 01 INFO_RAW 00 LSB 00 .. c8 .. c2 MSB; RawMin = -100.0 00 LSB 00 .. c8 .. 42 MSB; RawMax = 100.0 e6 checksum 98 MESSAGE_INFO + LENGTH_8 + MODE_0 02 INFO_PCT 00 LSB 00 .. c8 .. c2 MSB; PctMin = -100.0 00 LSB 00 .. c8 .. 42 MSB; PctMax = 100.0 e5 checksum 98 MESSAGE_INFO + LENGTH_8 + MODE_0 03 INFO_SI 00 LSB 00 .. c8 .. c2 MSB; SiMin = -100.0 00 LSB 00 .. c8 .. 42 MSB; SiMax = 100.0 e4 checksum 90 MESSAGE_INFO + LENGTH_4 + MODE_0 04 INFO_SYMBOL 50 'P' 43 'C' 54 'T' 00 ''; Symbol = "PCT" 2c checksum 88 MESSAGE_INFO + LENGTH_2 + MODE_0 05 INFO_UNK1 00 ??? 50 ??? 22 checksum 90 MESSAGE_INFO + LENGTH_4 + MODE_0 80 INFO_FORMAT 01 DataSets = 1 00 Format = DATA8 04 Figures = 4 00 Decimals = 0 ea checksum 88 MESSAGE_INFO + LENGTH_2 + MODE_0 06 INFO_UNK2 (second new PF2 info - others are 05) 06 ??? 00 ??? 77 checksum 04 MESSAGE_SYS + BYTE_ACK 00 MESSAGE_SYS + BYTE_SYNC |
|
|
Following this with interest! Not sure if you have already looked at the UART hardware circuit but I looked at the wedo2 and sensors a couple of years back and noticed the TX circuit was completely identical to EV3 circuit with one exception, the BAT54 diodes were not put on the board (even though the empty pcb pads were there for them!). The buffer used is type 74HC2G125 but it is the same circuit.
However the RX circuit is different to EV3, in fact it is exactly the same circuit as the TX circuit with the buffer simply pointing the other way. This is a bit simpler than the EV3 RX circuit because it does not need to be able to support the old RCX sensors. So basically the options are
I also took a tilt sensor apart and noticed that the 3-axis accelerometer chip was connected across the power rails directly. As this is a 3V device any voltage above 3V would permanently damage it. Therefore I assume that no higher voltage (e.g. 5V) will ever be put out of the V+ pin? The serial interface in the tilt sensor is 100% identical to the serial EV3 sensors (e.g. gyro) too. A lot of circuit designs being reused!
Let me know if you want to borrow tilt/motion sensors for testing. |
|
Thanks for the insights. 😄 Part of my reason for doing this is too see how compatible Powered Up is with EV3. I was thinking it might be possible to use Powered Up sensors on EV3. But, it looks like the EV3 firmware will have to be modified to ignore the new message types. And as you pointed out, if 5V on pin 4 is a problem, then connecting Powered Up devices to EV3 is bad idea (it has 4V on pin 4). And since there is nothing connected to pins 1 and 2 on the tilt sensor schematic above, that tells me LEGO didn't plan on this anyway. However, connecting EV3 sensors to Powered Up devices still seems like a possibility (assuming the Powered Up firmwares don't require any of the new UART messages). FWIW, it looks like they did include the Schottky diodes in BOOST. |
|
Maybe the reel ran out when they were building my wedo! |
Actually that is the serial circuit borrowed from the gyro schematic in the EV3 hardware developer pack, I didn't bother redrawing it accurately as it is much the same. In reality the tilt sensor has a capacitor to ground on each of the motor pins (1 and 2).
|
|
Thanks guys. Lots of new info and much better than what I got on holidays with my cheap analyzer. |
|
I think you can get the same information with your analyzer if you set it to 2400 baud or just use a USB serial adapter set to 2400 baud. I was hoping you might be able to get a dump of the two WeDo 2.0 sensors. (Although I'm sure I will buy some for myself eventually.) |
|
I tried 2400 at start but never saw nothing... Not sure why but 300 gave more consistent data than everything else until I tried 115200. |
|
I resume this post... Starting from the data captured by @dlech I have wrote this code: unfortunately, the handshaking is not successful and I don't explain why since the byte stream is identical to that detected by @dlech |
|
Some ideas:
|
Yes. If the sensor don't receive ACK from the hub in 1 second, the device reboot and try a new attempt.
Removed. But not change... Still, it should work ... |
|
Do you have a logic analyzer? |
|
No... |
|
Boost Color Sensor data in Google Sheet format: |
I really like https://www.saleae.com/ (if you have the budget for it). The one you linked says it can do RS232 and has good reviews, so it probably will do the job just fine. |
|
I tried to connect the sensor to an USB-Serial adapter, to read the handshake data (2400 bps ,8n1). I powered the sensor with 3.3v. The Pin 1 & 2 are not connected. The RGB LEDs switch continuosly from red to green (with a small pause), but not data is showed in the Serial Terminal. |
|
Maybe Tx and Rx are backwards? |
|
@dlech I tried both combinations. |
|
maybe hardware flow control is enabled? |
|
is ground connected to both the power supply and the USB adapter? |
|
|
|
Ok, finally!!! |
|
@dlech there is an error in your dump ;) ... |
|
Now, my sensor and the original Color Sensor write on serial interface the same data. So, what other thing I try to check? |
|
@Philo have send to me the data captured in the communication between sensor and hub (waiting Amazon deliver to me the Logic Analyzer). After the communication switch to 115.200 bps, the hub start to send the NACK byte (0x02) at which one the sensor reply with this bytes sequence: Each NACK are sent every 100ms The bytes D0 09 01 FF 3B E3 are the data message. I don't understand these bytes: Note: these bytes are not sent to every NACK from the hub |
|
Finally, I have a project that work! |
|
Very nice! |
|
@GianCann Where to find the code and a hardware description of your example? I would like to port it to arduino to develop a complete powerd-up-device-simulation-library over time. |
|
@mw75 in the next days I put all code and info on my GitHub repository. |
|
Hello every one , i wrapped up the interesting work done in this discussion , and i make up an Arduino Library (that works with all Arduino s version - using the main serial port + extra serial for debugging) which Emulates Lego Powered Up Color/Distance sensor, i also added another class for emulating Tilt sensor https://github.com/ahmedjouirou/legopup_arduino Example of usage: ` SoftwareSerial DbgSerial(2, 8); // RX:2 TX:8 // Test sensing pin(s) int8_t SensorX; LegoPupTilt lpup(&SensorX, &SensorY); void setup() { DbgSerial.begin(9600); } void loop() { lpup.Process(); if(lpup.IsConnected()){ int sensorValue = analogRead(AnalogPinSens); ` |
|
Hi, I used the work done here, and especially that of @ahmedjouirou & @GianCann to make a complete library supporting (hopefully) all the features/modes of the "Color & Distance" and "Tilt" sensors. It is now easy to interface any electronic component to the PoweredUp Hub via an Arduino/ESP experiment board, and the implementation of other LEGO peripherals should be simplified. I Hope it will be useful for some of you. Happy hacking ;) |
@GianCann Hello, I wonder how you fixed your original issue. I am working on a similar project with the Spike Prime hub. My hardware is sending the same config data as the color sensor. But I receive no ACK from the hub at all. Also, do you know if your project works with Spike Prime hub? Your help will be greatly appreciated. Thank you. |
|
@joehui Sadly GianCann passed away in 2020. |
|
@joehui : Hi maybe you could take a look at https://github.com/ysard/MyOwnBricks/blob/db6b9ba5735cccc290d2dd2d3dc3dc154203d4c5/src/ColorDistanceSensor.cpp#L191 for a working init sequence. and here https://github.com/ysard/MyOwnBricks/blob/db6b9ba5735cccc290d2dd2d3dc3dc154203d4c5/src/ColorDistanceSensor.cpp#L315 for the handling of NACKs and mode requests from the hub. It's the same protocol for all hubs but be sure that the peripheral you're trying to emulate is supposed to be supported by the hub. See the following pages for a compatibility update : For the moment you will notice that the compatibility information for the spike hubs seems to be missing (too recent hardware). I had found the following image which summarized the situation in 2020 (hubs, peripherals, apps) (didn't find its origin). Modules have been added since then, but unfortunately I doubt that the compatibility table has evolved a lot.
Keep in mind that the support on hubs of new devices is a goodwill of LEGO, not a hardware limitation. Pybricks firmware supports all PoweredUp devices : If you are sending the correct Boost Color and Distance Sensor | 88007 init sequence, and still receive nothing, I think there is a compatibility issue. Spike hubs support SPIKE Prime Color Sensor | 45678 which has its own init sequence. For now you will notice that in projects such as mine the sequence is just took without really trying to dissect its meaning. ... or, you can just flash your hub with pybricks and continue what you are doing.... GL & HF |
|
@ysard Thanks for your detailed reply. I actually figured out the issue with my project a while ago. I don't remember what the exact problem was, but it was some silly mistake in my code. Anyway, the info you sent is used for other parts of my project. Thank you. |
|
@joehui : Happy to see that the problem is solved. So to resume, you have successfully emulated a sensor Boost Color and Distance Sensor | 88007 running on a Spike hub? Also, it could be nice to update MyOwnBricks with a new example or supported hardware if it doesn't already exist ;) |
|
@ysard I was actually emulating the color sensor (Sensor ID: 0x3D) that comes with the Robot Inventor kit running on its hub, which is basically the same as the one the Spike Prime's. And, yes, I was able to emulate it successfully using an ESP8266. For the protocol, the only thing new that really matters as compared to EV3 is the combination mode sequence for Mode 0 as described in https://github.com/pybricks/technical-info/blob/master/uart-protocol.md regarding INFO_MODE_COMBO. After the config info sequence, the hub will send the following command: Sensor will reply with the following msg to confirm: Then hub will send a command to combine the multiple modes into 1 mode at Mode 0: Sensor should reply back with the same message to confirm: { 5C 25 00 10 00 50 51 52 00 C5 } After that, the sensor should start sending Mode 0 data messages that contain data from all 3 modes. Joseph |
|
Thanks for your quick answer, I spent some time on the subject to develop a proof of concept on a dedicated branch: https://github.com/ysard/MyOwnBricks/tree/spike_color_sensor Source: However I admit I'm confused about the INFO_MODE_COMBOS message because pybricks does not use it. => As you mentioned, the packet I took the opportunity to upload a reference containing the meaning of all the protocol headers here. PyBricks also does not take into account the reception of CMD_WRITE commands addressed to it In short there is little documentation about INFO_MODE_COMBOS. If I understand correctly the CMD_WRITE command sent from the hub to the sensor Thus,
mode 5 being the RGB_I mode, this implies the exchange of RGB values, that is 3 * int16. PS: I don't know what the 4th int16 of this mode corresponds to. Also, mode 1 being REFLT on 1 byte, and mode 0 being COLOR on 1 byte, I agree with your interpretation of I note that the "0x5C" packet uses also an unknown |
This documentation on Spike Pike python library provide some insight into how the combination modes can be used: If you look at the “mode(mode: Iterable[Tuple[int, int]]) → None” method, you see that one can specify a combination mode like this: This will make the sensor output the combination data as Mode 0. And yes, using this combination, you get 8 bytes of data: |
See JorgePe/BOOSTreveng#33; These messages (received & sent) are not parsed, they are fixed in place
|
Thanks for taking the time to write this very useful information and for the link to the documentation! I have implemented the thing on MyOwnBricks and it should work™; although for the moment the combo packages are not parsed (the code expects the same behavior as yours). |
|
@ysard Glad that I was able to help. |
|
Can any one with a Spike Prime Force sensor post its full initialization sequence? For my project, I am trying to emulate this force sensor. I have the Toy Inventor kit that doesn't include this sensor. The only information I have is that its ID is 0x3F. Any help on this would be greatly appreciated. |
|
Indeed, I found a bit more information on what I am looking for. In pybricks' code, I found that the "Force Raw" mode is 4, and the sensor has at least up to mode 6: By faking the force sensor with a made-up initialization sequence, then observing the response from the hub, I found that the hub's default combination mode uses these values: {Mode 0 Value 0}, {Mode 1 Value 0}, {Mode 4 Value 0}. From the list of value options available on the "Hub Connection" UI, it seems like these mode values correspond to: Force (Mode 0), Touched (Mode 1), Force RAW (Mode 4). From the above information, and many Trials and Errors, I believe the Force Sensor's main modes are: Mode 0 (8-bit unsigned int): Force (in Newton), value ranges from 0 to 10. Mode 1 (8-bit unsigned int): Touched (in %), I expected that its value range from 0 to 100. However, I was only able to make the value of 1% show in the UI. Anything above 1 will become zero in App's UI. I am not able to understand why. Is this the expected behavior? And, what is this "Touched" value really meant for? Is it supposed to only register when the user lightly touched on the sensor? Mode 4 (16-bit unsigned int): Force (Raw), value ranges from 0 to 1000. If someone can shed some light on my questions on the "Touched" Mode 1 value, it will be greatly appreciated! |
|
Touched is just a boolean on/off, so reproducing the way the older ev3 and nxt touch sensors also worked. This repo has useful info for sensor modes too |
|
@cpseager So is it normally that I should only see 0% or 1% as valid value on the following screen? Note that "Touched" is selected for display here.
|
|
@joehui : Yes from the technical specs of this sensor for the mode "Touch sensing": "Sensor output is binary (1=activated or 0=not activated)". For "Tap sensing": "Sensor data output: 0-3 : [Nothing], Single tap, Quick tap, Press and hold" In the missing modes (3 or 5) there should be the mode "Force-filter sensing (high speed “peak” sensing)": |
|
@ysard It's just a bit weird that a boolean is being shown as %. For "Touched" mode, after reading the spec document you sent now, its default value when released is 0. When pressed lightly, its value should be 1. But when too much force is applied, its value should become 0. And for "Force" mode, it says that its activation zone starts at 2.5 newtons. So I suppose that whenever Touched has a value of "1", Force will remain at "0". Until the force exceeds 2.5 N, Force should then start showing a value between 2-10. |
Take the example of the Force Sensor; See JorgePe/BOOSTreveng#33
@dlech These dumps are super helpful. Are they in the pybricks repo somewhere for all sensors? Where should I look? |
|
No, I don't think we posted them anywhere other than here. |
I've been spying on my BOOST Color and Distance sensor
Like EV3 UART sensors, Powered Up UART devices (can't say "sensors" anymore since BOOST Interactive Motor is also UART) send data about the device at 2400 baud until the brick syncs with the device.
Here is the data that I captured and the interpretation according to lms2012.h and d_uart_mod.c.
Recorded bytes and interpretation (click to expand)
The text was updated successfully, but these errors were encountered: