Flight Computer and Sensor Integration

Flight Computer and Sensor Integration Addendum

Brett Russell

Flight Computer Initiation

                  The data logger needs to complete an initiation sequence before it will write to the USB drive, essentially syncing the chip with the Arduino.  This process can be completed by bridging the RTS/CTS pins, which I have found to require hard coded delays to ensure smooth transfers, or by running a digital output from the Arduino and setting it LOW during this initiation sequence. 

                  Once initialized the data logger needs to be sent two commands , FFC 0 and IPA, to indicate the communication handshake standard and set input commands to ASCII format respectively.

Now the data logger is ready to open, close, read and write to files assuming the proper wiring.

Data Writing Sequence

                  Recording data fast for extended periods of time requires the Arduino to know when the data logger needs a second to catch up and when the data logger has encountered a buffer overflow.  The latter situation completely stops the writing of data, explained in my previous entry, but I have implemented a sequence to prevent loosing the data as follows.

1.     Initiate the write sequence by sending the open write command to the data logger.

2.     Turn a digital pin wired to the RTS pin of the data logger high.

3.     Write the data using the write file command and ASCII character array.

4.     Drop the signal to RTS to low.

5.     Close the file.

                  Steps two and four are synchronizing the Arduino's transmissions to the data loggers internal clock.  Essentially, the Arduino "requests to send data" by setting the pin high, transmits in step 3, and signals the data logger that the transmission is over.  Opening and closing the file each write protects against data corruption from the file not being closed.  Worst case scenario, the data will still be recoverable.

                  A write delay() function, as seen in my last post, is still implemented to allow the data logger time to catch up if it signals for it.  Reading the RTS pin is as follows:

State	Analog Read	Voltage
Ready	0	0
Buffer nearing capacity	400 - 450	~2.1 V
Buffer overflow	700-750	~3.5 V

                  Initiate the delay() function if the analog read is greater than zero, but also call the reset() function inside of the delay() function.  If this is not done an infinite loop will be performed if the data logger has a buffer flow situation instead of executing the reset.  This function is simply protection to ensure that even if the data logger locks up from a bad transmission, data logging will restart itself.  The function itself is straight forwards; however, the location must be proper to avoid an infinite loop:  

1.     Determine if buffer overflow has occurred in the delay() loop.

2.     Have the data logger powered by a digital output on the Arduino, if 1 is true set to LOW.

3.     Wait 1 second.

4.     Turn the digital output to the data loggers power back on.

5.     Wait 2-3 seconds for the data logger to recognize the communication channel and USB drive.

6.     Perform the two initiation commands listed at the beginning of this post.

7.     Continue on with the loop.

Flight Computer and Sensor Integration

Flight Computer and Sensor Integration

Brett Russell

Description of Interconnections

                  The flight computer must communicate with four sensors and the data logger during flight in order to record the data; below is how we connected all five of these devices to the Arduino.

Analog Pin	Peripherial Device	Digital Pin	Peripherial Device
0	Humidity Sensor	2	Serial RX
1	Temperature Sensor	3	Serial TX
2	Data Logger CTS
3	Accelerometer X
4	Pressure Sensor
5	Pressure Sensor
6	Accelerometer Y
7	Accelerometer Z

                                       Table 1: Device Interconnections

                  Each sensor must be grounded and provided a different supply voltage, 3.3V or 5V, listed in Table 2.  We opted to simplify the voltage regulation circuit to a 3.3V regulator placed off of the 5V Arduino rail, as the 3.3V rail does not work when it is externally powered, versus supplying a larger range of voltages using a voltage divider. (http://arduino.cc/en/Main/ArduinoBoardNano, Accessed: 3/4/2012)

Peripherial Device	Input Voltage	Voltage Ranges
Pressure Sensor	3.30 V	1.8 - 3.6 V
Humidity Sensor	3.30 V	4.0 - 5.8 V
Temperature Sensor	5.00 V	2.7 - 5.7 V
Accelerometer	3.30 V	1.8 - 3.6 V
USB Datalogger	5.00 V	4.75 - 5.25 V

Table 2: Device Input Voltages

Code

                  The Arduino communicates with the USB Data logger using serial communications sent from the built in FTDI chip.  The specific set of commands accepted by the data logger can be found in my previous post on the USB Data Logger. 

Handing Changing Sensor Data Length

Every sensor outputs data in different lengths and has different ranges; for instance, the temperature can range from -99 degrees Celsius to 99 degrees Celsius.  If the temperature happens to be 0.00 degrees Celsius  and changes to -0.02 degrees Celsius the data logger takes a different length command and the dtostrf(FLOAT, WIDTH, PRECISION, CHAR[]) function takes different arguments, seen in Figure 1.  Each situation per sensor needs to be handled in the code or the data logger will fail to write, never closing the file.  In any case if the file is not properly closed it becomes corrupted, rendering it unreadable, and can corrupt the rest of the data on the data logger.

Figure 1: Determining Data Length

Range (°C)	Output Chars
-999.99 to -100.00	7	Not Possible
-99.99 to -10.00	6	Possible
-9.99 to -0.01	5	Possible
0.00 to 9.99	4	Possible
10.00 to 99.99	5	Possible
100.00 to 999.99	6	Not Possible

                                                                           Table 3: Temperature Write Range

Handling Improper Data Reads

Once all possible cases are covered to send to the data logger, I placed a catch all for any erroneous readings that may be encountered due to unforeseen events.  This also preserves the row and column arrangement of the data in the excel file if a mishap were to occur.

  Figure 2: Erroneous Reading Catch    

Handling Write Speeds

The baud rate of the communication between the Arduino and the data logger is set when defining the SoftwareSerial variable; however, using 9600 the Arduino will occasionally send information too fast. 

                              Figure 3: Setting Serial Communication Rate

There are a few ways to fix this problem:

1.     Add delays between output commands

2.     Use the clear to send (CTS) signal from the data logger

3.     Change the baud rate

The first becomes an issue if an improper amount of time is allocated, but will work with a much slower write rate.  The third option would half the communication process, leading to inefficiencies like the first method.  We opted to use the second to maximize the amount of data we can output to the USB drive.  In order to use the CTS pin from the data logger, the request to send (RTS) pin must still be bridged to the CTS pin in order to successfully complete the devices initiation sequence.  The difference is also connecting the CTS pin to an analog pin on the Arduino, we used A2 seen in Table 1.

The easiest implementation of writeDelay() is shown in Figure 4, Serial outputs are embedded for testing purposes.  Although still in the early phases of testing, our experience has shown that the write delay function is seldom used in a one minute time frame and this function has doubled data output from using simple delays.

Figure 4: USB Data Logger Write Delay Function

Comments

                  The main loop program consists of a string of function calls that each read and print out different sensors data intertwined with write delay functions, this part of the loop can be seen in Figure 5.  

Figure 5: Write Loop if(File Open)    

***The total size of the program has reached 19994 bytes of a 30720 byte capacity***