MSP430 Overview: The purpose of the microcontroller is to execute a series of commands in a loop while waiting for commands from ground control to do otherwise. While it has not received a command it populates data from the sensors and GPS to form packets of data which are regularly sent to the two meter radio for transmission via the APRS network and to the OSD for text overlay on the analog video signal that the platform will be transmitting. This requires the microcontroller to be able to control these systems. This is done through a series of control signals like a four bit signal, which gets sent to the video MUX and tells it which camera should be outputting video and an eight bit signal where only one bit is high at any given moment in order to power the currently selected camera. Problems: This design is a continuation of the previous teams design. The working parts of it will be reused and redesigns will be done as needed based on problems with the design that are discovered. One of the major problems that was considered is that the MSP430 outputs a logical signal with an absolute maximum of 3.3V and previously one of these signals was used by the video MUX board in an inverter chip that required a minimum of 4V for a logical high level in the input. To remedy this the inverter is going to be removed from the design and instead an extra control signal will be used so that there are two enables for the video MUX chips and two signals to select the channel. Also instead of decoding three bits in to signals used to power the camera that is currently selected to be outputting video the eight signals will be generated through code. In addition to the hardware change it will be necessary to update the software to reflect this change. Also the code was modified to allow for switching between all 8 cameras whereas before the code only switched between 4 cameras. These new changes required the usage of more pins making it necessary to use I2C sensors since they only require two pins to cover a large number of devices. The previous design intended to use these same sensors but the code was never developed and the design was flawed which caused over-voltaging of components. So both the hardware and the software had to be developed and fixed. Also the previous design used a for loop in software to wait for the next GPS data bit. This makes for unreliable code since optimizations will remove this loop because it does nothing and relies on the clock frequency being static. So the code for the GPS needed to be rewritten to make it more functional and robust. This was achieved by utilizing the UARTs interrupt flags to enter an ISR where the data is thrown into an array for storage. Since only 2 out of the 5 GPS data formats were used and the data was stored and then every element was stepped through to find desired pieces of information flags were created to indicate if each desired format was found and if both have been located then the code breaks without looking through the rest of the data which saves time. It was believed that the previous design had wired the humidity sensor incorrectly so the traces had been cut on the previous design and the sensor was
never used but it was discovered that the hardware was fine and that the software was written incorrectly. This software was fixed. The code for the pressure sensors was also written incorrectly. The previous version of the code checked the value of the low pressure sensor and if the pressure was lower than a certain value then the high pressure sensor was used. Additionally it was unclear what units the data was being stored in and since previous conversions were wrong a new conversion was written based on the datasheet to yield pressure in kpa just to be safe. In addition to this it was discovered that the previous design had a voltage divider added on to the outputs of the pressure sensors as a last minute fix but these dividers were put in backwards so this change was added to the new design so surface mount resistors could be used and the voltage divider was flipped around so it would function properly. Also the were some issues with last year s code that made it so it would not compile such as functions being called that were not defined so the code was cleaned up so it could compile. Requirements: Some of the key requirements for the microcontroller include being able to operate within the expected temperature range, being able to control the cameras, being able to regularly generate packets of data and send them to the two meter radio for transmission and the OSD for text overlay, not being susceptible to hang-ups in the code. These are crucial because if these requirements are not met then after launching the platform the necessary data to retrieve the platform will not be received making the mission a complete failure. In order to prevent the processor from getting stuck in the code, the MSP430s watchdog timer will be used so that if a certain amount of time has passed and the processor has not finished executing the code then it will trigger an interrupt that will reset the system. Alternatively if the system receives a command from ground control to reset then it will execute the command. Component Selection: The MSP430 was chosen as the microcontroller because it was used in EE365 so it has the added benefit of familiarity in addition to meeting the basic needs of the platform without unnecessary complexity. It has enough ports to accommodate all the needed sensors. I2C is only available on USART0 so the digital sensors such as the temperature sensors, the accelerometer and the compass use this mode. USART0 was also used in UART mode to acquire data from the GPS and other sensors. USART1 stays in UART mode while it is listening for commands from ground control but after every minute it sends data to the radio it will be switched to SPI mode which will allow for data transmission to the SD card. The EM-408 GPS was chosen because it is capable of operating within the expected temperature range. The data is received at 5000 baud and is used based upon two forms. The first is GPRMC which is used to acquire time, date, latitude, longitude, speed and heading data. It takes this form:
$GPRMC,005142.000,A,4304.7754,N,07741.1764,W,0.27,218.44,100407,,*1C This data is defined in the following table. Data Meaning 005142.000 Time 00:51:42 UTC A Status A=active or void 4304.7754, N Latitude 43 degree 04 minute 7754 sec N 07741.1764, Longitude 077 degree 41 minute 1764 sec W W 0.27 Speed over ground in knots 218.44 Track angle in degree, true 100407 Data 10 April 07 The other form is GPGGA which is used to acquire the altitude. It takes this form: $GPGGA,005143.000,4304.7752,N,07741.1763,W,1,08,1.1,169.3,M,- 34.4,M,0000#64 where 169.3 represents an altitude of 169.3 meters. Two crystals were selected, X415 6.5MHz and SE2405CT 32.768kHz, with different frequencies of oscillations because the RC like aspect of the system clock is very sensitive to temperature fluctuations and thus cannot deliver a reliable clock signal. The two different frequencies were used so that the processor can run at different speeds as needed. The capacitors and resistors were chosen because they are within the expected temperature range the platform will experience during its ascent. The TMP100 temperature sensors were chosen because they are both capable of operating within and measuring the temperatures of the expected range. They output 12 bits with a logical high value up to V DD which for these sensors has a wide range of 2.7V to 5V so to make them compatible with the processors logical level they are powered at 3.3V. They are digital sensors and utilize the I 2 C bus and master-slave addressing. This facilitates having multipurpose purpose pins on the MSP430 so that the other digital sensors do not require their own pin to transmit their data to. Each digital sensor has its own slave address that it checks to see if it is equivalent to the data it is receiving after it has received a start signal. The HTM2500 relative humidity/temperature sensor was chosen because it is capable of operating within the expected temperature range. The MPX series pressure sensors were chosen because they can operate within the expected temperature range. Two sensors have to be used however because the sensor that can measure higher pressures cannot measure pressure down to 0kPa so an additional sensor that could measure a range of pressures from 0kPa to 50kPa. When the pressure transitions below 20kPa then the processor starts taking data from the smaller sensor. This is needed because at 100,000ft the pressure is 0kPa. These sensors output a maximum value of 5V so a voltage divider was necessary.
The B3F-1022 switch was chosen because it can operate within the expected temperature range. It is used as a manual reset for the system. The MAX3232 RS232 receiver was chosen because it can operate within the expected temperature range. The TS3A5018 analog switch was chosen because it can operate within the expected temperature range. These two components work together so that in the debug phase of the project the MSP430 can output its packets through the analog switch which will be setup to decide that the RS232 should get the data or alternatively the signal gets sent to a computer and the data can be displayed via hyperterminal to verify packet generation and reasonable data. Subsystem Block Diagram: GPS UART Digital Sensors: Temperature Compass Accelerometer I2C ANALOG PINS Analog Sensors Humidity Pressure Radio Uplink and Downlink 2m Tx/Rx (TNC) UART MSP430 Main Processor MSP430F169 SPI UART On Board Storage (SD Card) Software Flow: On Screen Display (Video Overlay) Cut Down Transmission
Power Up /Reset Command Received Interrupt Service Routine Initialize Ports Start Receiver Input Get GPS Data Get Temperature Data (4 External, 4 internal and 1 thermistor) Yes Execute command Is it a valid command? No Get Heading Send notification Get Humidity Clear command counters Get Pressure Return from interrupt false Altitude > 45000 ft true APRS Packet Send Interrupt Service Routine APRS Packet Period = 20 Yes TNC Count Done? No Send APRS Packet to TNC false Roll Video Camera Video Camera Countdown done? true Switch to SPI Mode and Send Packet to SD Card Reset Timer Instruction Set: Clear Watch Dog Timer Return from Interrupt
COMMAND LIST $COSDS DESCRIPTION Recreate the OSD screen. Helpful if the OSD screen gets corrupted $VCAM1 Choose the camera channel 1. $VCAM2 Choose the camera channel 2. $VCAM3 Choose the camera channel 3. $VCAM4 Choose the camera channel 4. $VCAM5 Choose the camera channel 5. $VCAM6 Choose the camera channel 6. $VCAM7 Choose the camera channel 7. $VCAM8 Choose the camera channel 8. $VCAMR Roll camera channel to the next one. $CUTDN $APRSx $TNCUx $CAMPx $NAMES Cut down the platform from the zero pressure balloon Change APRS packet period to 10x seconds Change APRS packet in TNC refresh period to 2x seconds Change Video Camera Channel Roll period to 20x seconds Print names of the team members
$TESTS $FIRER $RESET Testing the Command Functionality Fire the Rocket Resets the Results: The temperature sensors all gave an output of around 23 C which is a reasonable value for room temperature. Additionally this value was observed increasing if a finger was placed on the device for an extended period of time as body heat warmed up the sensor. The pressure sensors were outputting a value of around 100kPa which is a pretty reasonable value. The humidity sensor was outputting around 30% humidity which is pretty reasonable for a lab room environment. Additionally after exhaling on the sensor repeatedly for an extended period of time the humidity was observed increasing from the moisture of a person s breath. The GPS device was first tested in Rochester, NY where it read 8:56PM May 9 th 2008, 43 5.0811 minutes North, 77 40.7609 minutes W, 0.69 knots at 186.60 and an altitude of 161.6 meters. Then it was tested in Vestal, NY where it read 2:27PM May 10 th 2008, 42 3.2177 minutes N, 76 5.0421 minutes W, 0.03 knots at 104.89 and an altitude of 271.6 meters. Breakpoints were set and the video mux and camera power signals were probed and the proper values were showing up when expected. The channel was getting changed once every 70 seconds. Code was written to output serial data to the radio board and the bits were probed to confirm a 1200 baud rate and proper character transmission. Transmissions were occurring approximately once every 20 seconds. Future Considerations: Since the data the microcontroller sensor populates gets sent out serially in char format it would be more efficient to convert the data received into chars and store them in the array that will be used to transmit the data thus saving memory and time. Soldering connectors on proved to be awkward and messy. The system would be more space efficient if a data bus was used much like the concept use in the satellite teams design. An SD card could be used for on board storage. Data could be transmitted to the OSD subsystem via UART or SPI. This years hardware was setup for SPI but the software was never implemented due to time constraints and a critical error in the OSD subsystems design that rendered it unusable. If the design reaches a point where pin usage becomes an issue more sensors could be replaced with I2C or multiplexers could be used to reduce pin usage. However with the usage of I2C comes a loss in speed. Also more sensors could be used as a redundancy.
At the end it was discovered that the pins for the radio connector were switched for the receive and transmit lines. The new owners of these subsystems should meet and decide who is going to flip their lines. For a temporary fix a wire was used to route the signals to the correct destination.