Date: Wed, 12 Apr 2006 00:32:28 -0500 (CDT)
Subject: bit banged serial completely solved
X-UID: 161

I'm preparing an onboard data logging and recording system for the robot. 
This will not allow autonomous driving. But it will allow full recording 
of all activity. That includes radio communications, sensor readings, the 
drive by wire system, and camera video in a correlated time base. This 
will allow visualization of the system in the environment. Many of the 
DARPA Grand Challenge vehicles had visualization software like this to 
gain insight into the robot's operation during testing.

One problem I had deferred is the jitter noise in the bit banged serial 
communications between the onboard computer and the motor control 
microcontroller. This resulted in very noisy sensor readings for the gyro, 
wheel position, and IR distance sensors.

I felt that filtering in the control system could manage the high levels 
of noise. This was wrongheaded (although it did work for the gyro due to 
luck). The prospect of visualized output forced a solution for this 
problem. It would be embarrassing to see super noisy sensor readings.

An incredibly simple modification to the bit banging dramatically reduces 
jitter noise.

Out of 1000 serial frame of 3 octets each:

byte 1 = gyro reading
byte 2 = steering potentiometer
byte 3 = average of two Sharp IR distance sensors

The new bit banging code had 3 corrupted frames with 3 bad octets. The 
error rate was .1 percent.

The old bit banging code had 118 corrupted frames with 140 bad octets. The 
error rate was 4.6 percent.

The change is to divide each pulse corresponding to a bit into 16 segments 
and then look for the center of the leading low bit before reading out the 
following octet. It is necessary to do this for every octet read. Jitter 
accumulates very rapidly.

I think that I've read about UARTs doing this in hardware. I wasn't. Some 
of the EEs reading this will be laughing at me as it's an obvious thing to 
do. Now I understand. I think that with more sophisticated sampling, the 
error rate could be decreased to effectively zero. But .1 percent is good 
enough as the upstream software has additional noise reduction.