Welcome to the WRFL (Water Rocket Flight Logger) wiki!

After building my first water rocket with my kids a few months ago, I was amazed by how high it (looked like it) flew. I wanted to know how high... and after reading more about water rockets, I also wanted to know how fast and at what acceleration.

looking around on line, there are several boards that can do this, some didn't have all the features I wanted and others were very expensive.

And so, came the WRFL project to life (at least in my head).

1. Supplied by a rechargeable battery
2. Can record the maximum acceleration and height of a single flight
3. Can release a parachute (i.e. control a servo) after detecting maximum height (apogee)
4. Basic UI for user control and data read out (buttons and LCD)

5. USB charging of the battery
6. Logging the entire flight's height and acceleration at at least 100 Hz rate (according to online simulations I have seen, the acceleration change is very rapid)
7. Storing several flight logs on a non volatile memory
8. Accessing above memory from a PC as a USB mass storage device
9. Keeping date and time for as long as the battery will allow
10. Real-time reports to a smartphone using Bluetooth or BLE

I wanted the hardware platform to be flexible enough and support all the above requirements

So, first off was the MCU selection - an obvious and popular choice are the Arduino platforms, they have a lot of code base and projects on line. Another possible choice is the ARM Cortex based MCUs, very reasonably priced, development boards from ST and TI. The choice was the TI TM4C123GXL launchpad as it was the smallest Cortex (TM4C123GH6PM)based dev board at an ok price point. I think that the Cortex boards give you much more bang for your $ in terms of processing power and flexibility, both TI and ST have a lot of example code/projects and convenient libraries of course. (I know that the Arduino community is huge and there are a lot of "Shields" which is very helpful and convenient, however, since I wanted to design my own HW and the fact that I have some experience with Cortex processors, it was an easy choice for me)

The WRFL HW is basically the TI LaunchPad and a booster pack ("Shield" for all you Arduino fans) that I will design that will include the sensors, memory, UI and power management.

The blocks are color coded according to their power supply. I did not draw all the power lines from the LDOs in order to keep the diagram as clear as possible. The MCU is supplied by the boosterpack's MCU LDO. (and not the Launchpad's on-board 3.3V regulator)

All the blocks outside the LauchhPad boundary are on the boosterpack, except the accelerometer. The reason for having the accelerometer seperately is that I want the entire Logger to be protected from the rocket's return impact, I will cover it with some padding etc. The accelerometer, however, needs to be "hard-coupled" to the rocket's body in order to get an accurate reading, so it will be mounted on, it's own, small, external board. (connected with a wire harness to the WRFL)

The sensors have their own SSI as it is recommended in the pressure sensor's datasheet that the SSI interface will not be active during measurements, and there will be cases where I will want the SSI active e.g. file writes to the flash memory.

The reason for having a voltage reference is that the MCU's ADC reference is it's analog supply which is supplied directly from the MCU LDO. Since I may want to keep using the battery close to or below the nominal output voltage of the LDO, it may not be regulating at this input voltage, and will be an unusable reference as it will track the battery's voltage.

The power switch control is explained in the power management wiki page.

Functions that are not in the diagram:

• measurement of the following signals:
  • Battery voltage
  • Battery's temperature sensor (NTC resistor)
  • VBUS voltage
• Rotary Encoder's pull-ups - if you look at the schematics (specifically the UI sheet), you will notice that the encoder's pull-ups are tied to the peripheral rather than the MCU supply. The reason is that, at any point in time (i.e. at any encoder position), at least on of it's switches may be conducting. So, in order to minimize the current consumption during hibernate (when there is no UI anyway) I connected it to the peripheral supply, that will be turned off during hibernate.

• power management
• Design documents, datasheets and other links
• MCU pin Mapping

The End (for now...).

°C

---

WRFL by Ran Katz (Nightmechanic) is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Based on a work at https://github.com/nightmechanic/WRFL.