| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
| |
A previous change discarded previous *telemetry* state, but failed to
discard any previous overall flight state. This would reset some of
the data fields, but wouldn't reset the GPS state and max measurements.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
| |
Make AltosRecord simply track the raw data and have AltosState hold
all computed values, including cross-packet averages and computed speeds.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
During replay, AltosState may not see a new GPS value as soon as it
lands in the state field as additional records with the same timestamp
may come in after the GPS record.
Instead of resetting the new_gps indication when the new record is
created, wait until the new_gps indication is seen by the AltosState
update code and have that clear the new_gps indication.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
| |
Signed-off-by: Mike Beattie <mike@ethernal.org>
|
|
|
|
|
|
|
|
| |
Deal with missing data by checking for MISSING in more places.
Handle serial communication failures during send by reporting back
from libaltos.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
| |
Early telemetry state may be missing critical data, don't use MISSING
values in computing max ranges.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
| |
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
No sense having them live deep in the file system.
Signed-off-by: Keith Packard <keithp@keithp.com>
|