BYTE_SYNC for EV3 sensors

[JakubVanek]

Hi all,

I am currently digging deeper into the EV3 sensor protocol. During this, I have found a disagreement between the UART sensor documentation and what I can observe. In particular, the documentation states:

The [information about the device] sequence sent by the device is terminated by BYTE_ACK and BYTE_SYNC.

When I probe EV3 sensor UART lines with a logic analyzer, I can only observe the BYTE_ACK message and not the BYTE_SYNC:

The trace above is from the EV3 color sensor. However, I'm seeing a similar pattern from other devices too. I have tested the following sensors against the stock EV3 firmware 1.10E:

• EV3 Ultrasonic sensor 50N3
• EV3 Color sensor 47N3
• EV3 Gyro sensor 49N3

I have not tested the IR sensor yet.

The documentation also disagrees with what I thought about the BYTE_SYNC message. Comments in earlier EV3 firmware revisions hint that this message was intended for achieving baud rate synchronization before the sensor info sequence (link). The reverse-engineered firmware of a 20N7 EV3 color sensor seems to confirm this (link; the SYNC code is located at the beginning of the sequence, yet actually it is never executed).

However, I cannot rule out that LEGO repurposed the message. Is it possible that the BYTE_SYNC part is new to SPIKE Prime sensors or that this appeared later during the EV3 lifetime?

Thank you,
Jakub

[dlech]

Which sensors have you analyzed? Sending only the ACK at the end is typical for the newer Powered Up UART devices.

The comments about BYTE_SYNC might have been inferred from the comments in the original LEGO source code, which is as you noted, not how things are actually implemented.

Happy to take a pull request to fix the docs. But I think we should have a look at all of the sensors, especially the EV3 IR sensor to make sure we aren't missing something.

[JakubVanek]

I have only analyzed the EV3 gyro, ultrasonic and color sensors (and all of them quite old). I haven't checked any Powered Up sensors yet. I'm quite curious about the EV3 IR sensor too, as I have read about the checksum-after-SYNC bug. I will try to test one in the following days.

[dlech]

the checksum-after-SYNC bug

I suspect we will find that it is really checksum-after-ACK bug and I just had the terminology confused when I first started working on this 10 years ago. 😁

[JakubVanek]

Hello, unfortunately the "few days" got a bit longer than I expected 😄 I have some results:

• the checksum-after-SYNC bug of the infrared sensor is real. The sensor sends a 0x00 0xFF message a few times when sending the sensor metadata:
  
• I have hopefully checked all the major types of the EV3 sensors - Pulseview traces can be found here. It seems to me that the sensors send only the BYTE_ACK after they are finished with sending the metadata.
• However, I have sometimes received a 0xFF after the ACK when I was playing with the sensors from some Python scripts from Linux userspace (from a custom sensor stack with a USB-to-UART converter). My hypothesis is that the script failed to change the baudrate fast enough and so the USB-to-UART converter interpreted some of the 57600 Bd data as a 2400 Bd data.

[dlech]

the "few days" got a bit longer than I expected

Heh, it has only been a few days on Venus.

• My hypothesis is that the script failed to change the baudrate fast enough

That sounds vaguely familiar, so I'll agree with that hypothesis.

[laurensvalk]

Thanks for sharing @JakubVanek!

Would you perhaps be interested in trying to make the EV3 uart sensors work with the Pybricks legodev_pup_uart.c driver on Spike/Technic?

In principle, they are supposed to work with the PUPDevice class but I don't think they currently even sync up. Some of the EV3-specific workarounds may also no longer be present.

The goal here isn't so much about making EV3 sensors work on Spike/Technic (not many people would do that). But rather to get the drivers ready-to-go when we port this to EV3 later. (We've been making some progress on NXT and EV3 porting recently!)

[JakubVanek]

Hi @laurensvalk,

unfortunately I am not able to look into it at this time, but I general I am not opposed to it.

[laurensvalk]

No worries! In case case, I just thought I'd let you know that we have not forgotten about EV3 😄