| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
Flight numbers are now limited to 32767 to allow for negative values
for corrupted slots.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
| |
This is clearer than using '0'.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
| |
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Move common logging APIs from per-format files into ao_log.c. Then,
change that code to check the first log record in a slot (containing
the flight number) to see if it's invalid and deal with it. That
involves not re-using that slot, and allowing it to be erased.
Corrupted log blocks are reported with a negative flight number.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
| |
Instead of having a global variable define the log format, use a macro
instead to save data space.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
|
| |
We don't ever need to be able to do storage read/write across chunks
of flash on the old cc1111 products, so remove the loops that support
it to save space.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
| |
The remaining hooks to make the MPU9250 work in flight.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
| |
This is almost an exact copy of the MPU6000 driver, just a few minor
register changes.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
|
|
|
|
| |
We already have the fired status saved in the ao_pyro_fired variable,
so just use that to detect whether a channel has already been fired.
Fixes possible cases where the pyro config data gets written back to
eeprom with the fired bit set, which then inhibits the channel during
flight.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
|
| |
A pyro config like 'Descending' has no value associated. When it is at
the end of the line, allow a newline to terminate the name instead of
just a space.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
| |
Disable radios when plugged in to USB to save power and avoid being
noisy.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|\ |
|
| |
| |
| |
| |
| |
| | |
Can compare with computed values.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|/ |
|
| |
|
|
|
|
|
|
|
| |
Parse eeprom config using libjson-c, then read the hex values into a
giant blob.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
| |
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
| |
The ADC data takes a while to start working after power on; wait for
the range of input values to look reasonable before using the data.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
|
| |
We only use this for baro-only devices to avoid firing drogue charges
at mach transitions; we trust the combination of accel+baro to do the
right thing when available.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
|
| |
This flight had a baro spike due to an accidental drogue charge firing
but is otherwise quite useful when testing for various mach delay
effects, so fake out the data during that spike.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
|
| |
This can provide a useful visualization of the 'true' vs 'kalman'
speed value, as the kalman is necessarily delayed due to the model
assuming constant acceleration.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
| |
No need for the test code to invert it during replay
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of completely eliminating the baro sensor above mach speed,
just derate it a bit so that the accel will dominate for speed
computation and keep the device from false-triggering across mach
transitions.
When we completely ignored the baro sensor above mach, and the flight
spent considerable time in that speed range, then the estimated height
could be far from the real value. When the estimated speed dropped
back down and the baro values were brought back into the computation,
then the resulting rapid shift in estimated speed could trigger
accidental apogee detection.
By mixing in a bit of baro data even above mach, we keep the estimated
height closer to the baro value and prevent this error, at least in
flights measured so far.
The flight known to have this problem is:
2015-09-26-serial-2093-flight-0012.eeprom
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
| |
We don't use the error value in flight for those models anyways; it's
only useful on baro-only hardware.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
| |
Subtracting two 16-bit unsigned values to perform time comparisons
yields mystic results unless we carefully cast that to int16_t.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|\ |
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
Use temp variable instead of stepping on the AES name.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |/
|/|
| |
| |
| |
| | |
Use 'long long' and %lld for 64-bit values when printing.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
| |
| |
| |
| |
| | |
Use baro-only mode, parse easymini logs.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
| |
| |
| |
| |
| | |
Now that the stmf0 HW flow control works...
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
| |
| |
| |
| |
| | |
If you try this after the UART is running, it won't work.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
| |
| |
| |
| |
| | |
This just means ignoring the BLE connect status message.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
| |
| |
| | |
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
If we see the start of an RN4678 status message, but then output
pauses, assume that this isn't the start of a status message and flush
the pending data.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
| |
| |
| |
| |
| |
| | |
The ADC in the STM32F0 is different than the LPC, with a range of
0-4095 instead of 0-32767.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Re-label everything to have the correct names. This doesn't actually
change the code at all, so the eeprom and telemetry is all compatible.
Matching changes on the host side will be required to actually process
the data correctly, of course.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Read data into a temp variable, block interrupts, then update the
published value.
The bug is easy to see with the HMC5883 which has to byte-swap the
output of the chip, and hence can occasionally get caught with the
wrong byte order data.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
| |
| |
| |
| |
| | |
Useful for doing host-based RF protocols.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
| |
| |
| |
| |
| | |
This isn't being used anymore.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|/
|
|
|
|
|
| |
USE_INTERNAL_FLASH is about storing config data in internal flash, and
should be on for telefireone.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
New devices won't respond to the cmd pin we have configured, so get
them to command mode by sending the $$$ string. Somehow I'd botched
the name setting code and hadn't caught it as I hadn't tried a new
device...
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
|
|
| |
Compute whether any sw/hw flow control is in use.
Compute whether hw flow control is in use as a separate value.
These make the code a bit easier to follow.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
| |
We've switched from the BM70 to this module which offers a virtual
serial channel over both BT and BTLE.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
|
|
| |
This works much like the old BTM module, but supports both bluetooth
and bluetooth LE. I've poked at it briefly over BTLE to see that it
appears to have the right name, but haven't attempted to communicate
over BTLE yet.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
|