| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
|
|
|
|
|
| |
Now that we have a viable telemetry-signal based RDF device via TeleDongle,
there's no reason to continue to waste power and bandwidth with a NFM tone.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
|
|
|
|
|
|
| |
Adding two 16 bit integers together can wrap around to negative numbers,
this resulted in velocity values which never decreased, making the switch
from coast to apogee state not occur.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We integrate acceleration to get velocity, but that means sitting on the pad
for a long time can add substantial error to the velocity value. Each
second, take the velocity value from a full second ago and subtract that out
of the current velocity. Once we detect boost, this will stop, which means
that as long as we detect boost within a second, we won't have subtracted
out any "real" velocity.
This keeps the pad velocity hovering around zero, which is pretty useful.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
|
|
|
|
|
|
|
| |
Integrating the accelerometer data to compute velocity worked for one rocket
flight, but additional testing shows that it doesn't work in other
airframes. Until we figure out how this should work, we'll rely on the
altimeter to detect apogee.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
|
|
|
|
|
|
|
| |
Because the orientation of the flight computer relative to the ground is
unknown after apogee, the accelerometer data cannot be integrated to compute
velocity. Main deploy is now based purely on barometric altitude and landing
detection no longer checks for a low velocity value.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
|
|
|
|
|
|
| |
Bumping the rocket can cause a brief period of high acceleration, which may
cause a mistaken boost detection. Require both a high acceleration and
reasonable velocity to trigger boost phase.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
|
|
|
|
|
| |
The landing range values are used only after apogee detect, so we need only
initialize them on the transition from apogee to drogue.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
|
|
|
|
|
|
| |
As ao_min_vel is stored as an absolute value, it's important to preserve
that invariant, even though we don't expect ao_flight_vel to be negative at
coast.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
|
|
|
|
|
|
| |
Transmitting telemetry through the radio consumes a significant amount of
battery; reducing the rate to 1/sec will reduce power usage while waiting
for launch.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
|
|
|
|
|
| |
To get an accurate baseline of the launchpad state, take a longer average of
the two sensors as the unit boots up.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
|
|
|
|
| |
This moves all of the interval management into the landing test code and
out of the main loop. The interval is reset at apogee to make sure the
sensors produce a stable reading for at least 20 seconds
|
| |
|
|
|
|
| |
The final state change to landing is recorded in the logging thread, so have
that turn off logging once it has recorded that state. Then make it go to
sleep.
|
| |
|
|
|
|
|
|
|
|
|
| |
Current config variables:
Main deploy altitude above launch (in meters)
Acceleration zero g calibration (manual or automatic)
Radio channel (freq = 435.550MHz + channel * 100kHz)
Callsign (max 8 characters)
Supporting this involved shuffling code around so that the
non-telemetrum builds could include only the stuff they needed.
|
| |
|
|
|
|
| |
This tries to make the flight computer use less power by disabling USB in
flight mode, lowering the telemetry rate after ascent. It also disables the
RDF beacon during ascent and re-enables it once descent has started.
|
| |
|
|
|
|
|
|
|
| |
This change ensures that we actually got going fairly fast, and then slowed
down a bunch before enabling apogee detect. Otherwise, we'll detect apogee
right off the pad as we're not going very fast at that point...
This also adds the 'f' command to show the current flight status on the USB
port.
|
| |
|
|
|
|
|
|
| |
This now correctly sequences through the flight data collected from the
first TeleMetrum test flight.
This also completes up the flight algorithm test harness (ao_flight_test),
which runs the flight algorithm on the Linux host from a captured data log.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Ok, way too big a patch, but things were in rough shape.
This patch adds support for the radio, both transmit and receive.
Then, because I could no longer run the TeleMetrum code on the TI
dongle, I ended up building a separate image for the TI board, which
involved creating a mechanism for having multiple command sets and splitting
code for different functions into different files.
|
| |
|
|
| |
The T command shows the current wchan and PC for each task in the system.
|
| |
|
|
| |
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| |
|
|
|
|
|
|
| |
GPS also pulled in serial support. The altitude tables take raw 11-bit
pressure sample numbers and convert them to standard pressure altitude
values.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
| | |
|
|
|
These pieces come from the old telemetrum firmware.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
