search

pybricks / technical-info

Detailed technical info for Pybricks hackers
MIT License
35 stars 9 forks source link

BYTE_SYNC for EV3 sensors #10

Open JakubVanek opened 1 year ago

JakubVanek commented 1 year ago

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:

Screenshot of a logic analyzer where the sensor and the brick exchange ACKs. No SYNC bytes are visible

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:

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

JakubVanek commented 1 month ago

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

dlech commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

Hi @laurensvalk,

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

laurensvalk commented 1 month ago

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