-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathMethods_RESU.tex
67 lines (56 loc) · 5.23 KB
/
Methods_RESU.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
%\clearpage
\subsection{Electronics System Design}
\label{sec:RESU}
\subsubsection{Overview}
The RESUs primary purpose during the flight will be to monitor environmental conditions and control the astrobiology systems. It will monitor temperature of the various subsystems and the humidity and pressure of the environment throughout the flight. All recorded data will continuously be written to an SD card mounted on a shield on top of the Arduino. It will also accept discrete commands from the HASP systems to turn the astrobiology collection system on and off.
\subsubsection{The Sensors}
Our payload will utilize eight thermistors to measure temperature at various points in our payload. The decision to use thermistors was based primarily on the performance of the analog temperature sensors during our 2017 flight, during which several of those sensors failed. Thermistors are able to accurately measure temperature in the range \SIrange{-55}{125}{\celsius} and should therefore be adequate for the conditions in the stratosphere. Pressure will be recorded from two identical digital pressure sensors in order to ensure accuracy and should be able to record accurately in the range \SIrange{0}{14000}{\milli\bara}. Finally, humidity will be measured from a basic analog humidity sensor. All sensor data will be UTC timestamped via the onboard Real Time Clock and recorded to the SD card.
%UVC radiation was measured by three identical sensors. They supported light ranging from \SIrange{210}{380}{\watt\per\square\meter} and were located outside the roof of the payload. These sensors were analog so their readings were voltages induced by incident rays on the surface of each sensor. To stabilize the voltage readings from each sensor, a \SI{3300}{\micro\farad} capacitor was placed across the ground and analog out pins of the sensor. Data was collected every \SIrange{3}{4}{\second}.
% \subsubsection{Powering It All Up}
% In order to stay within the power constraints, a robust power supply will need to handle all the components of the payload. The power supply we will be using is the PPM-DC-ATX-P by WinSystems INC. It offers the desired number of \SI{+5}{\volt} and \SI{+12}{\volt} outputs needed to power the payload's electronics. This power supply could effectively take \SI{+30}{\volt} and step it down to two \SI{+12}{\volt} and two \SI{+5 }{\volt} outputs. One of the \SI{+12}{\volt} outputs goes to the Arduino since it can step down to the appropriate voltages internally while the other goes to a PWM motor for the solenoid. One of the \SI{+5 }{\volt} outputs powers two analog sensors that will be sent to HASP through the EDAC connection (more on that in the next sections). The remaining \SI{+5 }{\volt} output is converted to a USB power cable for the RP3. The power supply also has four ground outputs that will be used by each respective component.
%Listing~\ref{Downlinks} is a sample downlink data packet received during our previous flight.
%\lstset{basicstyle=\small, numbers=left, xleftmargin=2em, frame=tb, label = Downlinks, framexleftmargin=1.5em}
%\begin{lstlisting}[caption = Sample of downlinked data packets ID: 15667 - 15670 from SORA 2017~\cite{SORA}.]
%...
%begin_packet
%15667,-21.05,-0.33,35.62,-1.00,0.12,0.25,-0.71,0.63,9.30,-30.25,-26.69,-60.88
%3.14,2.86,0.00,0.00,0.60,9:29:39 9/4/17
%end_packet
%begin_packet
%15668,-20.95,-0.54,35.62,0.75,0.06,-0.69,0.25,-2.00,9.67,-28.37,-28.06,-60.06
%3.80,3.33,0.00,0.00,0.60,9:29:42 9/4/17
%end_packet
%begin_packet
%15669,-21.15,-0.54,35.62,0.81,-0.06,-0.56,1.22,-2.13,9.86,-29.56,-27.75,-57.88
%1.86,2.86,0.01,0.02,0.61,9:29:45 9/4/17
%end_packet
%begin_packet
%15670,-21.15,-0.54,35.62,-1.00,0.00,0.12,-0.55,0.73,9.37,-27.37,-30.00,-58.75
%1.86,3.96,0.00,0.00,0.61,9:29:48 9/4/17
%end_packet
%...
%\end{lstlisting}
%\medskip
%
%Each packet of data will be delimited by keywords \verb|begin_packet| and \verb|end_packet| so that parsing each file be easier. During our previous flight, these data packets were crucial status updates to the state of our payload. We will once again use them for the same purpose to keep a close eye on our payload.
%
%Data packets will contain information about the readings from each sensor. The first integer represents the ID of the packet. Following the packet ID are the three temperature readings, gyroscope $x, y, z$ values, accelerometer $x, y, z$ values, magnetometer $x, y, z$ values, pressure readings, humidity readings, UV \#1, \#2, \#3 voltage readings, and finally the timestamp in $HH$:$MM$:$SS$ $MM$/$DD$/$YY$ at which the packet was written.
%
%In addition to downlinking sensor data, we also want to downlink serial uplink commands as shown in listing \ref{Uplinks}.
%
%\lstset{basicstyle=\small, numbers=left, frame=tb, linewidth=11.5cm, xleftmargin=.4\textwidth, label = Uplinks}
%\begin{lstlisting}[caption = Sample of received uplink commands in downlinked packets in SORA 2017~\cite{SORA}]
%...
%1
%2
%71
%FFFFFFFF
%3
%D
%A
%Received Command: 71
%...
%\end{lstlisting}
%\medskip
%
%Each line within a received uplink command represents the string of bytes that will be read by our payload. The last line of the listing shows what command will be parsed and processed by RESU. Table \ref{tab:All-Commands} shows all the possible commands that we are expecting to process.