Rocket Payload

Project Overview

The overall goal of this final project is to implement a set of electrical components inside a model rocket to collect data and store this data for later use. In this rocket payload, we plan to use an altimeter, an SD card, and a Teensy in communication with the MSP432.

Project Scope

The scope of this project involves building and testing the electronic payload consisting of two main functional systems. The first system is active during pre-launch and flight, and consists of an Altimeter to read altitude data and an SD card system to record this data. The second subsystem is active upon descent/landing (determined by a predetermined time limit, possibly with altimeter input). This subsystem is a radio beacon that will transmit a morse code beacon which we can use to locate the rocket when it lands. The overall system will be controlled by an MSP432. We will be using a combination of breakout boards and custom circuits in the form of a shield for the MSP432 to do this project and will also include power circuits for the system.

Due to the challenges posed by implementing SD card functionality, this project will have two SD card configurations. The first will leverage an Arduino-type intermediary that will receive the altimeter data through UART communication with the MSP432 and write it to the SD card, leveraging freely available SD card libraries. The second is a stretch goal, and will interface with the SD card directly via SPI using our own drivers for the MSP432.

The altimeter will require implementation of the I2C driver functions provided by the MSP432 in order to write the driver to retrieve data from the sensor.

The radio beacon will require the use of a UART interface for initial configuration, drivers to create a PWM-generated audio tone, and software to allow us to periodically key out a morse code sequence using a GPIO push to talk (PTT) signal.

Additional goals for the project include designing the physical mounting system to house the electronics payload inside the rocket. Additional stretch goals include building a directional receiving Yagi antenna (testing will be performed with the stock omnidirectional antenna) and performing actual rocket launch to test the system in its use case scenario.

Functional Block Diagram

In the image above, we illustrate the basic outline of how our project functions. First we start with the MSP432, that everything flows through, which then branches off into different subsystems (radio module, altimeter, and the SD-card). In the radio module, the plan was to place a custom made DRA818V breakout board that would transmit a signal from the rocket to an external device that locates the rocket based off of the PWM audio signal. On this breakout board, an antenna would transmit an audio signal using UART that would then be played on the receiver end of the radio beacon aid in detecting the location of the rocket. Then, in the altimeter module of the project, we planned to record the data of the launched rocket throughout the flight, and used the MSP432 to help transport the data from the altimeter to the Teensy, which then stored the logged data on an SD-card.Functional Block Diagram

Bill of Materials / Inventory Tracking Table

We kept track of our parts using this bill of materials and inventory tracking table. This was very helpful as we were using a combination of parts we already had and parts we needed to order.

Wiring Diagram

We used the wiring diagram to help us design our PCBs and make sure we were making all the connections we needed.

PCB Design

We designed two PCBs: a main shield for the MSP432, and a breakout board for the DRA818v radio module. We decided to split the project into these two parts because we knew the DRA818v would be the most difficult to pull off. Much of the design work was outside of the scope of this class, but we still wanted to take on the challenge. We did our design using Autodesk Eagle.

Pin Map

Schematic for PCB

Main Shield Schematic

Radio Board Schematic

PCB Layout

Eagle Board Layout images

Main board layout

Radio Board layout

For this project, we decided to fabricate our PCB through PCBWay. In designing and choosing how to fabricate our PCB we selected the following parameters.

Fabricated PCB

The vias are mistakenly not tented, so we need to be careful we don’t short anything, especially the back side of the DRA818v module. Once we received the fabricated PCBs we used the ohmmeter to check continuity among each of the connections and ensured that the traces we created were correct.

Arduino Testing

We did initial testing on the components using Arduino-type platforms that have off-the-shelf libraries and hookup guides. This allowed us to confirm that the components were functional and able to meet our requirements.

SD Card / UART

Left: Teensy 3.2. Used in place of MSP432 to generate arbitrary numbers (a single uint8_t that increments) and sends over UART every 50 ms

Right: Teensy 3.6. Has a built in microSD card slot. For every byte received on UART Serial1, it writes to a CSV alongside a millis() timestamp.

Used: https://github.com/greiman/SdFat/

Results: Able to log bytes of data sent through UART with no apparent packet drops. Able to generate a CSV file of arbitrary length and open it on a computer.

Altimeter

Used Teensy 3.6, which has firmware for the altimeter already developed for it, we were successfully able to retrieve part number, calibration factors and pressure / altitude readings, which were apparently pretty off, but documentation notes that the altitude readings were simply offset and have good relative accuracy.

MSP432 Testing

We did our initial software tests using breadboards, testing individual functionality of components before combining the software and testing them on our PCB.

Altimeter

The final payload uses an MSP to communicate with the Altimeter instead of the Teensy, so I2C drivers needed to be written for the MSP432 in order to retrieve data from the Altimeter.

A logic analyzer was used to look at the information sent between the Altimeter and the MSP432. The waveform and values obtained is shown below.

Result: We were successfully able to obtain both pressure and temperature data, as well as validate the data using the CRC bytes. We were able to obtain the calibration constants to convert the pressure and temperature data into an actual altitude value.

SD Card / UART

We implemented one of the hardware UART ports on the MSP432 in order to pass the altimeter data we retrieve over I2C. The same Teensy from the Arduino Testing section still handled and logged the data received.

An oscilloscope with UART decoding was used to look at the information being passed between the Teensy and the MSP432.

Result: We were successfully able to log first arbitrary data sent from the MSP432, and then eventually the data from the altimeter, and view this data on a computer. We were also able to pass “handshake” signals over UART to pass the state of the Teensy and MSP432 between the two devices.

Software Diagrams

Trade Studies

We had to select two voltage regulators - a 4V regulator for the radio and a 3.3v regulator for everything else. For each regulator, we did analysis on

• Input Voltage limits
• Max current output
• Thermal power dissipation
• Voltage Drop Out based on discharge profile
• Monte Carlo variations for adjustable power supplies

4V (Adjustable) regulator:

We used a combination of LTSpice and PSpice to do analysis on these components to ensure that they are able to provide the voltage levels we need during the entire lifetime of our batteries. Here is the summary of our findings.

Final Conclusion:

The LT1963 is the most expensive and also is not automotive grade. It might work electrically, but is not ideal.

The AZ2085 and NCV317 require a higher supply voltage, 4 cells instead of 3 in order to output the desired voltage, due to their high voltage drop. The AZ2085 also fails the power dissipation analysis by a rather large margin in its 4 cell configuration.

The BD00COAWxx is cheaper than the LT1963 and is automotive grade, and passes all of our requirements.

3.3V regulator

Discharge profile

Since they’re both fixed voltage regulators instead of adjustable, we don’t have to do the monte carlo on the voltage divider resistors to see how that affects output. Instead, let’s just analyze the output voltage using the drop out voltage of each regulator and the lower bound of the supply.

Each battery cell is dead at 1.4 V. 3 cells = 4.2 V. We want our output voltage to be 3.3V.

It is worth noting that the BD33 recommends Vin to be at least Vout + 1.0V, which would be 4.3V. Our lower bound is 4.2V which is below that, but it’s not ridiculously out of range. This note might mean that despite the fact that Vin - VDO > Vout, Vout might not make their +/- 3% Vout tolerance, but it’s not outrageously off so it is probably okay for our application.

The BD33 performs equally or better in all considerations except for price, where it is more than twice the cost of the NCV1117. But since we’re doing a small run (qty=1, maybe with a few spares) this price is acceptable.

Morse Code Theoretical Analysis

We are required to transmit identification at least every 10 minutes during a communication (source). In order to easily fulfill this task, we will simply use Giselle’s call sign, which serves to identify the source of transmission, as the periodic signal, encoded in morse code.

To calculate timing of a morse code message: (source)

KC1KKR

-.- -.-..---- -.- -.-.-.

13 dashes = 39 units

8 dots = 8 units

15 in between (within a letter) = 15 units

5 in between (between letters) = 15 units

Total: 77 units for the word “KC1KKR”

We have no particular reason to transmit quickly. In fact, in order to make the signal useful for location finding, a longer transmission is better. However, a too long transmission time would just waste battery without helping much. A reasonable slow speed to key our morse code at is 5 words per minute, which is a traditional standard, a former HAM radio license requirement, and current Boy Scout interpreter strip requirement (source). Aviation standard is around 7-10 words per minute (source). These words per minute measurements are defined with standard words such as PARIS and CODEX. PARIS is convenient because it’s exactly 50 units long.

5 words per minute = 12 seconds per word

12 sec/word / 50 units / word =.24 seconds per unit

.24 sec per unit * 77 units = 18.48 seconds

Therefore, at this speed, the call sign will be transmitting for 18.48 seconds.

You can hear our transmitted message using this website:

https://morsecode.scphillips.com/translator.html

Enter this text into the input: -.- -.-..---- -.- -.-.-.

Pitch = 600 Hz

Speed / wpm = 5

Farnsworth = 5

Transmit duty %:

How do we figure out how much power is actually going to be consumed? When the device is transmitting, it will draw 700mA / 750mA peak, and when it is in receive mode (which we’re using as idle) it draws 60 mA (source).

Dashes and dots are on, in betweens are off

39 + 8 = 47 on

15 + 15 = 30 off

During transmission of the word, we are transmitting 61% of the time.

(47/77)*18.48 = 11.28 seconds of ON time.

11.28 sec / 60 sec = 18.8 % ON

Average Current: 60mA off, 750 mA (peak) on

(.188) * 750 + (0.812) * 60 = 189.72 mA average drawMorse Code Theoretical AnalysisWe are required to transmit identification at least every 10 minutes during a communication (source). In order to easily fulfill this task, we will simply use Giselle’s call sign, which serves to identify the source of transmission, as the periodic signal, encoded in morse code.To calculate timing of a morse code message: (source)KC1KKR-.- -.-..---- -.- -.-.-.13 dashes = 39 units8 dots = 8 units15 in between (within a letter) = 15 units5 in between (between letters) = 15 unitsTotal: 77 units for the word “KC1KKR”We have no particular reason to transmit quickly. In fact, in order to make the signal useful for location finding, a longer transmission is better. However, a too long transmission time would just waste battery without helping much. A reasonable slow speed to key our morse code at is 5 words per minute, which is a traditional standard, a former HAM radio license requirement, and current Boy Scout interpreter strip requirement (source). Aviation standard is around 7-10 words per minute (source). These words per minute measurements are defined with standard words such as PARIS and CODEX. PARIS is convenient because it’s exactly 50 units long.5 words per minute = 12 seconds per word12 sec/word / 50 units / word =.24 seconds per unit.24 sec per unit * 77 units = 18.48 secondsTherefore, at this speed, the call sign will be transmitting for 18.48 seconds.You can hear our transmitted message using this website:https://morsecode.scphillips.com/translator.htmlEnter this text into the input: -.- -.-..---- -.- -.-.-.Pitch = 600 HzSpeed / wpm = 5Farnsworth = 5Transmit duty %:How do we figure out how much power is actually going to be consumed? When the device is transmitting, it will draw 700mA / 750mA peak, and when it is in receive mode (which we’re using as idle) it draws 60 mA (source).Dashes and dots are on, in betweens are off39 + 8 = 47 on15 + 15 = 30 offDuring transmission of the word, we are transmitting 61% of the time.(47/77)*18.48 = 11.28 seconds of ON time.11.28 sec / 60 sec = 18.8 % ONAverage Current: 60mA off, 750 mA (peak) on

Housing for Rocket Prototype #3

For the housing design of this project, the goal was to create a structure that would withlast and support the electronics if a failure in the rocket launch occurred. In order to do this, a structure was created that could fit inside the electronics bay of the rocket and have the availability for multiple mounting points, ensuring that the electronics could be supported and protecting in the event of a fall. To do this, we implemented a tube like feature that included various mounting holes, in addition to space and slots for cords, and electronics to fit. When printing these prototypes, a couple features were played with in how the structure was designed. The team finally decided that a honeycomb structured print would support the design and electronics in the best way. Therefore, in the 3-D print the walls and fibers of the materials were printed in small honeycomb shapes ensuring strength.

This planning was very helpful in that when the rocket was launched and tested, the parachute did not deploy without the electronics bay attached, therefore the electronics bay fell from just over 800 feet in the air to the ground. With this being said, our structure held through for the most part showing minimal damage to both the 3-D print and electronics inside.

The Radio

We designed a circuit board for the DRA818v and planned on transmitting a call sign over CW on the 2m HAM radio band. Unfortunately, there was a shipping mishap with the low pass filter that filters out the harmonics produced by the DRA818v, so it did not arrive on time. We wanted to launch the rocket before the final project was due, so we decided to hold off on the development of the radio-related software and focus exclusively on the data logging aspects.

We are hoping to continue work on this project as time goes on, and have obtained a 2m band pass filter from hobbypcb.com.

Launch Day

In an attempt to test our project and learn more about how we can improve our devices we found a launch site near Greeley, Colorado and launched our project on Saturday, December 7th. The launch site was in the middle of a large field with no roads nearby, and plenty of clear airspace.

To practice launching rockets, we first started with two empty rockets with no electronics bay. We launched each of these rockets and gained a better understanding of the process of launching rockets and a predicted location for where the wind would potentially blow our payload.

Finally, after some tweaking with our electronics and ensuring that our devices were functioning in the way they were expected, we launched our large rocket in hopes of taking measurements during the launch. When the rocket launched, the altimeter was recording data, and storing it on the SD-card, however when the rocket reached is apogee (highest point), the parachute deployed, but the electronics bay became disconnected from the parachute. The electronics bay quickly fell 800 feet to the ground without the parachute, leaving some of the electronics cracked or lightly ruined. Although the housing was designed to support these electronics in times of failure, it was not enough to save the SD-card and all its memory. Therefore, there was no way of retrieving the data we collected during the flight. Below are a couple images of the launch day and all the great experiences we had.

GitHub Link:

https://github.com/gisellegk/ECEN2440-final-project