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]
pgp8ZzpA25Pl8.pgp
Description: PGP signature
_______________________________________________ altusmetrum mailing list [email protected] http://lists.gag.com/mailman/listinfo/altusmetrum
