Timing issues with EV3 UART sensors.

[dlech]

I've notice that the EV3 UART sensors return an error value quite often instead of the sensor value. Usually, the value is -2, and sometimes -4. I can see these are error values returned by the EV3_Update function. I stuck my logic analyzer on it and immediately saw the problem.

Normally, the timing works like this...

1. The RPi polls the BrickPi by executing the BrickPiUpdateValues function.
2. The BrickPi sends a keep-alive (called NAK in the code) to the UART sensor.
3. The UART sensor sends back data in response to keep-alive.
4. The BrickPi sends the data back to the RPi.

However, quite often, this happens...

1. The RPi polls the BrickPi by executing the BrickPiUpdateValues function.
2. The BrickPi sends a keep-alive (called NAK in the code) to the UART sensor.
3. (This happens after 4, which is too late.) The UART sensor sends back data in response to keep-alive.
4. The BrickPi sends the data back an error because there was not data to be read.

---

It seems that this happens most often when data value is changing rapidly. A couple of easy fixes would be to A) wait a bit longer for the UART sensor to respond before sending an error or B) send the previous value received.

---

I've worked around this for now by filtering out the error values, but it makes the sensor unresponsive for noticeable periods of time, which does not make for good robot building. Also, some of the sensors can return negative values in certain modes, so I also have to filter out possibly good data in those modes, which is not nice.

[dlech]

The hard fix would be to make receiving the UART data in the BrickPi happen asynchronously and cache the most recent value. Then the EV3_Update function could always just return the most recent value without having to wait for a send and receive to/from the UART sensor.

[ghost]

In file BrickPiEV3.cpp line 176, we check that at least one byte is available before reading it line 178.
Line 183, we read the remaining of the message from the EV3 sensor without checking that it is already available.

Could it be the reason of all these error values ?

[dlech]

What happens is that no data is available in line 176, so sensor1.available() is false and the function returns -4 at line 203.

It been so long since I looked at this, I don't remember if I was also seeing a -2 error or how frequently.

[ghost]

In your first comment of this issue you said "Usually, the value is -2, and sometimes -4" (top of this page).

I definitively suspect this piece of code to be the source of the read errors with EV3 sensors.

[kortschak]

I've just stumbled across this problem. Is there any intention in @DexterInd to fix this? The device is being sold as something that "works with all NXT and EV3 sensors and motors."

[DexterInd]

@kortschak it's something we're working on. Yes, we have intention to fix it.

[kortschak]

@DexterInd, what is the time-frame for this?