getScan() hangs after resetting stationary device, regardless of new motor speed

[dcyoung]

We just discovered a bug in the current firmware (v1.3) that occurs when a device is reset while stationary (motor speed setting 0Hz)

Example:

1. Device is stationary
2. Device is reset using RR command
3. do anything here... including adjust motor speed to non-zero setting
4. Start scanning
5. getScan() hangs

Any other device interactions work as expected, yielding normal responses. Additionally, the data stream actually initiates just fine, and the individual scan packets are received without error.

getScan() hangs because accumulate_scans() never encounters a sync reading. Instead, all the incoming data packets contain an azimuth value of 0°. ie: each 7 byte scan packet looks like [0,0,0,x,x,x,x] where x is a non-zero value.

Because the azimuth values do not increase, a sync reading is never encountered and a new scan is never produced. But neither is an error. The reason an error is never produced is because all the incoming scan packets pass their checksum. Its possible libsweep would break from this after receiving more than SWEEP_MAX_SAMPLES data packet responses. But my applications were timing out before that anyhow.

This is a firmware bug. We are working on a fix which will be released ASAP. However, we may still want to implement a check in accumulate_scans() for successive packets that have the exact same azimuth, and throw an error.

[dcyoung]

New firmware (v1.4) was released today, resolving this issue.