<Perhaps inane comment> RE: ... If you're willing to hack the firmware ...
It's *so* cool that the hardware/firmware/software is open source! </Perhaps inane comment> On Fri, Nov 15, 2013 at 7:27 PM, Keith Packard <[email protected]> wrote: > Casey Barker <[email protected]> writes: > > > What's the expected sample rate during the ascent? Storage limits aside, > > what could the hardware do? > > We're running everything at 100 samples/second, and the GPS at 1 > sample/second. If you're willing to hack the firmware, you could > increase the rates significantly for some of the sensors. Just to remind > you, here are the sensors that we're using: > > sensor model resolution max rate > > Z axis accelerometer Freescale MMA6555 12 bits 500 > IMU (3 axis accel/gyro) Invensense MPU6000 16 bits 1000 > Mag sensor (3 axis) Honeywell HMC5883L 12 bits 160 > Baro sensor Measspec MS5607 24 bits 100 > GPS u-Blox MAX 7Q 10 > > As you can see, the baro sensor is the slowest at a 100 samples/sec max > to get the full 24 bits. Reduce the resolution of that sensor and you > can make it go faster, but that means more noise in the height data. > > We've got 8MB of flash space, and the logging format stores 64 bytes per > sample, so enough space for 128K samples. > > I've got profiling support for the hardware, and at the current sampling > rate we're using less than 10% of the CPU, so it's pretty clear we've > got lots of head room for faster sampling. > > I haven't measured SPI or I2C bus utilization. The hardware is designed > to minimize contention by avoiding long delays with the bus busy > (thanks, MS5607), but it's possible that you'll just run out of steam -- > the IMU, Z accel and baro sensor are all on a single SPI bus as the > other SPI bus is used for the radio, which uses the bus for extended > periods and would cause a bunch of sample rate jitter if we stuck a > sensor on that. > > From a firmware perspective, we've always used a 100Hz clock > tick. There are a bunch of pieces of the system which have that value > baked-into the algorithms, from the Kalman filters for the vertical > motion to the quaternion integration of the gyroscopes. Note also that > the flight logging and telemetry uses 100Hz timestamps on everything, so > changing that rate would mean hacking all of the ground software too. > > Another trick here is that you'd be running the z-axis and baro sensors > at different rates, and that would significantly complicate the Kalman > filter implementation, which currently assumes that the measurements are > perfectly synchronized. > > Overall, I think this would be quite do-able, but it looks like a fair > bit of work. > > > Our major point of interest is the first > > ~second after ignition, down to the effects of buttons leaving the rail. > We > > really want to understand that phase. Beyond that, staging and motor burn > > are more interesting than coast. I know on TeleMetrum, descent has a > slower > > sample rate, so I wonder if we could further refine the rate over the > > flight profile. > > Yeah, that'd be an easy hack in the firmware; there's a flight-state > dependent logging rate which would be easy to extend. > > > We'd still like to include a 70-cm 100-mW Beeline APRS, mostly because > > we've got all the gear and familiarity tracking these. > > Backups are good. Note that TeleMega can also send APRS beacons, > although as they consume 1 second of bandwidth per position fix, it does > mean a significant reduction in telemetry transmission. > > > I know the Beeline would interfere with rx on the TeleMega, but do you > > foresee any issues with the TeleMega in pad/flight transmit-only mode? > > Could they be in the same bay? > > There shouldn't be any problem; TeleMega doesn't care about other RF > transmitters as long as they're of modest power. A 5W transmitter right > next to the board might cause issues. Of course, ground testing is your > friend here; just make sure you light up *all* of the electronics when > checking for interference. > > > Whatever the answer, we'll bench test it. Just looking for a swag, and > > a sense of whether it might kill the rx front end. Plan B is to move the > > Beeline up to the nose. > > I suspect your range for RX on the TeleMega board itself would be > dramatically reduced with another transmitter in the same bay, but that > would only affect the 'idle' mode command link. > > It shouldn't have any effect on the TeleDongle (or TeleBT) receivers, as > long as you're well away from them in frequency. > > -- > [email protected] > > _______________________________________________ > altusmetrum mailing list > [email protected] > http://lists.gag.com/mailman/listinfo/altusmetrum > >
_______________________________________________ altusmetrum mailing list [email protected] http://lists.gag.com/mailman/listinfo/altusmetrum
