AXEtimeter I - model rocket datalogger - part 2

Hemi345

Senior Member


A rundown on how it works
The user presses the MODE button briefly to power on the device. The LEDs display a short light show to indicate it's powering on. The last eeprom register used, stored in register 0 of the 24FC512, is loaded into a variable. If the eeprom memory has been reset (a menu option), this value will be 1024. Registers <1024 are used to store last eeprom register written for flight data, max height (in meters) of the last flight, and running total of flights recorded.

Pressing the MODE button cycles the menu options (indicated by the LEDs) and pressing the SELECT button chooses that option.

The ALTitude LED will blink indicating the current menu option is altitude. Pressing SELECT will slowly blink out the last maximum height in meters. For example, if my daughter's rocket flew 1243 meters (no, she doesn't have anything that powerful....yet), the 1000 LED will blink once, then the 100 LED will blink 2 times, the 10 LED will blink 4 times, and the 1 LED will blink 3 times. Then a short pause and the ALTitude LED will go back to blinking.

Pressing MODE will switch to the next menu option LED, which is TRANS. SELECTing the TRANSmit option, the device will upload all the eeprom flight data through the programming cable to a PC with CSV header data. Then the user just saves it as a .csv file and loads it into Excel to graph and such.
The CSV header and flight data look like:
Code:
Register,Flight#,FlightTime,Altitude(M),Temperature(C)
1024,0001,00:02.24,1553.00,23.25
The entry above is from register 1024 in the eeprom, for flight number 1, 2.24 seconds into the flight, the altitude is 1553.00 meters above sea level, and the temperature is 23.25 degrees C.

Each row of flight data is 13 bytes and padded out to 16 bytes. Decimal points, commas, semicolons, etc, are added during the transfer to free up space and reduce write time during the flight. Since the eeprom has 128 byte pages, each entry is entered on '16 byte centers' (carpentry term in electronics?) because 128 is equally divisible by 16 and this keeps from running into an issue where the write wraps around in the page and corrupts the data. This wastes 3 bytes of space but I think it's easier this way. Maybe we'll find something else to log in those 3 bytes.

SELECTing the MEMory menu option will use the LEDs like a fuel gauge to display how full the eeprom is based on the last eeprom register written to for flight data. LED 1 will quickly blink if the eeprom is nearly/empty all the way up to all the LEDs lit if the eeprom is nearly/full.

Pressing MODE will switch to the next menu option, which lights both MEM and TRANS LEDs. Pressing SELECT on this option will reset the eeprom pointer back to 1024 basically clearing the memory (subsequent flights will overwrite existing data). There's a slow countdown (using the LEDs as an indicator) to the memory reset so if this option is accidentally selected, the user has time to cancel it.

Update: Pressing MODE again switches to the SuperCap voltage display, ALT, MEM, and TRANS LEDs are lit. Pressing SELECT will read the SuperCap voltage and blink it out just like it does for the altitude. If the SuperCap voltage is 2.16V, it will blink the 100s LED twice, the 10s LED one time, and the 1s LED, six times.

Pressing SELECT while the LAUNCH LED is blinking will begin the launch sequence. The RTC is zero'd for everything (mainly the 100ths of seconds, seconds and minutes are all we care about). The flight number is read out of register 2 of the eeprom and poked into RAM. The pressure sensor will take about 90 readings, averaging 30 at a time, to make sure the launching altitude has stabilized (the sensor needs a few seconds to stabilize after powering on), and then the launching altitude is recorded. The the pressure sensor will start taking readings (currently at about 15hz - I'm still balancing optimization of the code with the sensor's oversample rate to keep the accuracy high with the number of data points) and wait for the altitude to change. No logging will take place until the altitude changes. So if the altitude is 1553 meters, the actual logging to the eeprom won't happen till the altitude is > 1555 meters. The altitude readings bounce around a bit so this provides a buffer to prevent a false start. As we get quicker with launches, we may just start logging after x seconds to capture the launch rather then after the rocket is already in flight. At this point, 'we' really only care about the maximum height traveled, so the current method will give us time to 'arm' the device and not rush the countdown/launch. Safety first! Once the altitude rises, the readings and RTC timestamp will be written to the eeprom for the duration of the flight.

When the rocket lands and the altitude stabilizes for about 6-8 seconds, the last eeprom location written will be saved in register 0 of the eeprom, the flight number will be written to register 2, and the launching altitude is subtracted from the max altitude pulled from a special register in the pressure sensor and stored as max height in register 4. The AXEtimeter will automatically power off.

After recovery, we can power up the device by pressing the MODE button, then SELECT the ALTitude option. The LEDs will blink out the maximum height traveled (in meters) that is stored in register 4.

I soldered in the supercap. I've found that when the supercap gets down to about 0.85V, the interrupt routine quits working when the MODE button is pressed, so that's a good indication that it needs to be charged. I still have some program space left, so I might use the LEDs to blink out the actual supercap Volts (I purposely put the MODE button on a ADC-capable pin). Still, I've only charged it 3 times the entire time I've been playing with it and developing the program so the 5F size has been really nice in that respect.

Once this wacky Colorado weather gets back to rocket launching conditions (it's currently a blizzard outside), we'll send it on it's maiden voyage. Of course, we'll have more pictures and possible video. We've been testing it out by running upstairs and back and the AXEtimeter seems to be behaving pretty well, but I don't think you want to see video of that. :)

The code will be posted soon. Just need to clean it up a bit. Really loving the 2 slots and #include features of Programming Editor 6!
 
Top