| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
| |
This works way better than attempting to use the beeper pin.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
|
| |
Connect this pin to GND (pin 3) and TeleMini will come up with N0CALL
at 434.550MHz using the original frequency calibration. Helps recover
from accidental mis-configuration.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
| |
Instead of having to add it to each product using this variable.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
| |
This allows other systems to see what baud rate the host has requested.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
|
|
|
|
|
|
| |
We'll have to rewrite some of the serial code to avoid sucking memory here.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
| |
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
|
| |
This tries to be a bit more logical about the board initialization
sequence, starting with the OS, then the support hardware, internal
drivers, external drivers and finally services.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
| |
Also remove some unneeded config of an additional pin for MCU wakeup,
which the CC1120 needs but the CC1200 does not.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
| |
Turn on serial 2 and use it for GPS.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
| |
HAS_MS5607 and HAS_RADIO_RECV aren't useful.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
| |
Rewire as needed.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
| |
Turns out the CPU doesn't run well at that speed. Who would have guessed?
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
| |
The LED is green, not red. Use it for panic and GPS lock.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
|
|
| |
TeleGPS v2 uses the STMF0 processor instead of the LPC11, which means
the ADC range is different. As the raw ADC value was getting sent to
represent battery voltage in the config packet, we need to scale that
for the different processor. This patch allows that to happen.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
| |
Blinks an LED briefly once every three seconds when GPS is locked.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
| |
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
|
|
|
| |
stm32f042 processor replaces the attiny85 and adds USB support along
with more storage.
Signed-off-by: Keith Packard <keithp@keithp.com>
|