circuitcellar.com
Magazine Support   Digital Library   Products & Services   Suppliers Directory 
 
 





 

Issue 98, September 1998
Smart Rockets - Data Acquisition in Model Rocketry


by Tom Consi & Jim Bales

Start Introduction to Model Rocketry Rocket Science 101Control & Data LoggingThe Accelerometer SoftwarePowerSystem Construction Launch Control Box Results Future Developments Software & Sources

CONTROL & DATA LOGGING

We chose the Microchip PIC16C73 microcontroller as our data-logging engine (see Figure 2). This chip has all the I/O functions we need: DIO pins, a five-channel eight-bit ADC, a USART, and an SPI synchronous serial port.

Its 4 K words of data space (we used the reprogrammable windowed EPROM version) and 192 bytes of RAM easily accommodate our application code as well as provide some head-room for future expansion.

Size was a key factor in determining what microcontroller to use. The PIC16C73 comes in a 28-pin skinny-DIP package that fits our space constraints.

The only thing the ’16C73 lacks is nonvolatile data storage. This is provided by a Xicor 25F128 serial flash-memory chip that contains 16 KB of memory in an 8-pin DIP package.

The Xicor chip communicates with the ’16C73 via the PIC’s SPI serial interface. A 4-MHz crystal (Y1) was chosen so each of the PIC instructions executes in 1 µs, which is convenient for calculating code-execution times. The reset button (SW1) is a tiny SPST momentary On push button which grounds the MCLR pin of the PIC.

We considered two methods of triggering data collection by the PIC. One is to have the PIC continually read the ADC and use the flash memory as a ring buffer. The PIC waits for the accelerometer output to exceed a threshold and stops writing to the buffer just before completing the next loop around the ring.

The drawbacks are the added software complexity (a concern for students just learning PIC programming) and the finite number of write cycles allowed by the flash chip. Also, for the first launch, we would have to set the threshold based on our predicted acceleration curve, a golden opportunity for Murphy to intervene!

Instead, we chose to supply an external electrical signal when the launch switch is pressed. This technique removes all the objections listed above and also provides us with data on the lag between pressing the launch button and the liftoff.

However, it presents a new challenge: how to make a reliable electrical connection that can be broken with very little force. We need this type of connection in two places—between the launch pad and the rocket and between the rocket body and the nose cone/payload section (which must separate during ejection). Our solution is in the "System Construction" section.

Two digital input pins control the system operation. When grounded, the trigger input (RB0) starts the program running.

On triggering, the program enters one of two modes, determined by the jumper on digital input pin RB1. Mode A (RB1 low) causes the PIC to acquire accelerometer data. In mode B (RB1 high), the PIC immediately dumps its stored data to a host computer though its USART.

As Photo 1 shows, the trigger lines (RB0 and ground) are brought out of the payload section and down the rocket body to the fin tips where they contact two plates on the launch pad, which are, in turn, connected to the launch control box (see Figure 3). The launch button (SW2) shorts these contacts together, triggering the system to start acquiring data (if it is in mode A).

Green and red status LEDs connect to digital outputs RB6 and RB7, respectively. The green LED indicates that the system is on and waiting for a trigger signal. The red LED means the system is either acquiring data (mode A) or dumping data through its USART (mode B).

Four other digital outputs (RB2–5) were used for debugging purposes.

To get the data onto a PC, we built a small interface box that has a push button to trigger RB0 while in mode B. This interface box contains a MAX233 TTL to RS-232 level shifting chip that eliminates this chip from the payload’s circuit board. The box also has its own battery so the payload’s battery isn’t drained during retrieval of data (see Figure 3).