Page MenuHomePhabricator

Serial communication sends invalid data when tracking with Aurora components under Linux
Closed, ResolvedPublic

Description

When using Aurora tracking components under Linux, strange behaviour occurs when starting to track:

Preparation:
Attach the equipment, connect tools and autodetect Tools, then start tracking

  1. For an extended period of time (seemingly random from 5 to approx. 60 seconds the device does not find the sensor. Tracking has started, but the coordinates are shown in red (outside of bounds)
  2. Short tracking occurs: This period is interrupted by short spikes of tracking (apparantly only one package) with correct coordinates
  3. After this timespan, tracking starts behaving as expected.

Apparantly, the SerialCommunications class recieves bad packages intermittently. This cannot be directly related to the behaviour yet, though.

Event Timeline

Further investigation showed that during the no tracking phase, serial communication only recieves error codes. This Error code is different from the "Out of bounds" code sent, when the tool is outside the tracking volume.

The short spikes are single packages of correct data. After a while, correct data is consistently being sent.

This sounds like a hardware problem. Surprisingly, this behaviour could be reproduced with different pieces of hardware as well and does not appear on windows PCs.

It is now confirmed that the error is due to a Linux specific code fragment in the SerialCommunications class. Obviously, an "OKAY" reply is ignored, and lingering fragments clog the serial communication until it randomly reestablishes itself. We don't understand the why yet, but it should be fixed soon.

[a3f026]: Merge branch 'bug-11825-SerialCommunicationSendsInvalidDataWhenTrackin

Merged commits:

2012-05-16 16:28:47 Keno Maerz [669dc5]
Fix for Serial Communication under Linux: RecieveBuffer is cleared with every send

Problem is probably a place in the Code where the CRC16 is not processed after an INIT Command. Strangely enough, the Windows specific Code seems to recover from this, while the Linux specific one doesn't.
It is worth noting that the Linux code to read out Serial Communication is handwritten - this might be suboptimal since there are Linux system commands for that.
Solution for now was to clear the RecieveBuffer with every send.