BARCoMmS Ground Station Testing System

NASA – Internship Final Report
Summer 2016 Session1
BARCoMmS:
iSat Ground Station Testing System
Benjamin Kingen
Alissa Smith
Riley Waite
Marshall Space Flight Center
August 12, 2016
Reviewed by NASA Mentor
Scott Akridge
ES-52
____________________________________
Mentor Signature Here

BARCoMmS: iSat Ground Station Testing System
Benjamin Kingen1, Alissa Smith2, and Riley Waite3
A ground station test software for the iSat project will be written with the intent of
replicating a mission-viable ground station with the Consultative Committee for Space Data
Systems’ (CCSDS) File Delivery Protocol (CFDP) capability and a modular user interface
with packet transfer visualization, a satellite command issuer, CFDP command-line
integration, and satellite event history displays. Named BARCoMmS (Ben, Alissa, and
Riley’s Communication Management System) after the intern group, the software will be
capable of interfacing with the closed-loop iSat data pipeline during Critical Design Review
(CDR), and, as such, will be integral to the simulation of satellite operations. The system will
send and receive CCSDS space packets through specified UDP ports to the Programmable
Telemetry Processor (PTP) with certain ports representing specific virtual channels through
which telemetry and satellite commands will run.
Nomenclature
ACK = Acknowledgment
APID = Application Process Identifier
BARCoMmS = Ben, Alissa, and Riley’s Communication Management System
CCSDS = The Consultative Committee for Space Data Systems
CFDP = CCSDS File Delivery Protocol
DITL = Day in the Life
EOF = End of file
Graphics Items = Qt QGraphicsItem Inheriting Object for painting (e.g. ellipse, rectangle, text)
NAK = Negative Acknowledgment
PDU = Protocol Data Unit
I. Introduction
he use of iodine propellant for Hall thrusters has been studied and proposed by multiple organizations due to the
potential mission benefits over xenon. In 2013, NASA Marshall Space Flight Center competitively selected a
project for the maturation of an iodine flight operational feed system through the Technology Investment Program.
Multiple partnerships and collaborations have allowed the team to expand the scope to include additional mission
concept development and risk reduction to support a flight systemdemonstration, the iodine Satellite (iSat). The iSat
project is now progressing towards a technology demonstration mission critical design review.
In order to facilitate the stimulation, simulation, and testing of the iSat’s flight software, a ground station testing
framework needs to be rapidly deployable, easily modified, and portable; these were the qualities sought out by the
team when creating BARCoMmS. The software is modular, capable of packet communication visualization,
command issuing, CFDP communication, and event history timeline display. The software allows for speedy and
simple integration of additional modules, commands, and GUI features, and lends itself nicely to the testing and
development of the iSat flight software.
1 Computer Science and Applied Mathematics, NASA MSFC, South-East Missouri State University.
2 Electrical Engineering and Applied Physics, NASA MSFC, The Pennsylvania State University.
3 Aerospace and Mechanical Engineering, NASA MSFC, Rose-Hulman Institute of Technology.
T

II. System Overview
Figure 1 BARCoMmS Process Flow Diagram
A. Initialization
BARCoMmS currently consists of four modules: DITL, CFDP, Bulletin, and Command. Upon initialization, the
four modules (green), along with two packet listener threads (blue), are instantiated. Listener threads open and listen
to their respective UDP ports (yellow). Qt Slots (white diamonds; covered later) connect to the necessary Signals.
B. Modular Architecture
The Qt framework allows for a highly modular system architecture. Modules exist within class objects,
interfacing with any other module or application object via Qt Signals and Slots. Additional modules can be
appended to the system simply by instantiating an object of them and calling appropriate initiation methods within
the initialization process.
C. Signals and Slots
The modules connect to each other and the listener threads via signals and slots, a subscription-publication
systemnative to the Qt framework that BARCoMmS was developed in. Connections are as follows:
•Bulletin listens to CFDP for CFDP transaction information
•Bulletin listens to Command for command information
•Bulletin listens to the Telemetry Packet Listener for Health and Status PDUs and command acknowledgments
•DITL listens to the Telemetry Packet Listener for Event PDUs
•Telemetry Packet Listener listens on incoming FSW telemetry UDP port
•Command Packet Listener listens on incoming external command UDP port
•CFDP module connects to the FSW’s CFDP client through UDP port for CCSDS space packet PDU transfers
•Command listens to the Telemetry Packet Listener for telemetry PDUs
•Command listens to Bulletin for Health and Status received signal strength
•Command sends command PDUs to FSW
D. Packet Listener Threads
The two packet listener threads, the Telemetry Packet Listener (TPL) and the Command Packet Listener (CPL),
run concurrently with the primary BARCoMmS application. These threads respectively listen for incoming
telemetry and command PDUs on specified UDP ports. The listeners then disseminate, via aforementioned Qt signal
emission, these PDUs to the appropriately connected modules (e.g. event PDUs to the DITL and command ACK
PDUs to the Bulletin). Packet Listener Threads will only terminate when there are no longer modules listening to
their signals, thus eliminating erroneous processes when possible.

Figure 2 BARCoMmS CFDP Main Window.
III. Modules
A. CFDP
1. Overview
At its core, the CFDP module enables the reliable and unreliable (for test purposes) delivery of space packets. In
addition to this, however, the module supports a variety of functions helpful during communication passes. The
ability to freeze and thaw the engine, suspend or cancel transactions, and change the file chunk sizes are just a few.
The module is also fully capable of fault injection testing with built-in faults provided by the link simulator.
The CFDP module consists of two separate implementations: one for ground and one for flight. The ground
implementation (also known as BARCoMmS CFDP) is a user-friendly GUI-wrapped version of CCSDS’s CFDP
library with functionality that enables the user to quickly view the status of transactions and any engine parameters
as well as issue all commands necessary for ensuring reliable file transfers. Equipped with an initialization file, the
user can configure all engine settings and other parameters once to their preference such that, on load, the program
will start with the user’s preferences. The engine is also capable of sending and receiving files at any time while the
program is running (unless the engine is frozen). This means that once the userissues a request to download files, no
further action is required to receive the files. Likewise, once the user initiates a put request, no further action is
necessary. The flight implementation is an embedded solution for use on the satellite itself. Rather than having a
GUI for user input, the system waits for commands issued to the satellite and then responds accordingly. For
example, if the ground operator issues the “Download Camera Images” command, the on-board CFDP client is
notified to “put” the n most recent camera images. Furthermore, like the ground implementation’s engine, the engine
is always ready to receive incoming PDUs (unless the engine has been frozen), meaning that if the ground wanted to
send a packet to the satellite (say a software update), it could do so at any time (also assuming a connection has been
established).

The primary purpose for using CFDP on the iSat is to reliably transfer photographs taken by the satellite’s
camera from the satellite to the ground during communication passes. The photos will display the thruster’s plume
and any build-up that accumulates on the thruster itself. A future implementation under consideration is to use
CFDP as a means of not only image transfers, but also software update transfers . Since CFDP is simply a file
delivery protocol, it is fully capable of handling any type of file. As such, the software side of things needs no
changes to handle transactions that are not images. Moreover, it is important to note that CFDP is not limited to just
these two examples.
2. Functionality
The functionality of the engine can be broken up into five categories: requests, engine toggles, engine settings,
statuses, and miscellaneous features. Requests handle the file transactions. Engine toggles handle the freezing and
thawing of the engine. Engine settings handle the configuration of engine-specific parameters (e.g. for address
mapping and for communication timers). Statuses handle user-informative requests. Miscellaneous features are
simply “other” features that could be useful during a communication pass. Note that the statuses and miscellaneous
features are only available for the ground client, since messages will be non-existent on the satellite.
Requests:
i. Put – Given a transfer type, receiver ID, source file, and destination file, allows a transaction to begin.
ii. Suspend – Halts the transaction’s progress until it is resumed or canceled/abandoned.
iii. Resume – Resumes a suspended transaction’s progress.
iv. Cancel – Alerts the transaction partner that the file is to be canceled. Awaits for ACK before killing the
transaction.
v. Abandon – Kills the transaction without telling the partner.
vi. Report – Displays the current status of a transaction.
Engine Toggles:
i. Freeze Engine – Halts the engine’s state such that no transactions can continue until the engine thaws. This
is ideal for when a satellite has finished its communication pass and communication is no longer required.
ii. Disable Engine Messages – Prevents messages pertaining to engine events from displaying.
Engine Settings:
i. MIB (Management Information Base) – Allows the user to control engine parameter settings. These
parameters consist of the following:
a. Issue EOF sent indications
b. Issue EOF received indications
c. Issue file segment sent indications
d. Issue file segment received indications
e. Issue resumed indications
f. Issue suspended indications
g. Issue transaction finished indications
h. Save incomplete files
i. ACK limit
j. ACK timeout
k. NAK limit
l. NAK timeout
m. Inactivity timeout
n. Outgoing file chunk size
o. Entity (node) ID
ii. Message Classes – Allows the user to enable or disable classes of messages that display information
pertaining to their respective events. The classes are the following:
a. Indications
b. Debug memory use
c. Debug NAK
d. Debug PDU
e. PDU file data
f. PDU non-file data
g. PDU retransmitted file data
h. State all
i. State change

iii. Link Simulator – A built in fault-injection tool used to set the connection’s strength (as a success rate),
corrupt checksums or file sizes, and performactions such as dropping all transactions or all NAKs. A list of
provided fault parameters follows below:
a. Connection strength (as a success rate)
b. Delay between PDUs
c. Duplicate
d. Reorder
e. Drop all
f. Drop all ACK and Fin
g. Drop all Fin
h. Drop all NAK
i. Drop all but EOF
j. Drop one ACK EOF
k. Drop one ACK Fin
l. Drop one EOF
m. Drop one Fin
Statuses
iv. Detailed Status – Provides details about a specific transaction such as transaction start time, file size, and
bytes transferred so far.
v. Periodic Status – Displays the Trans Status information at a constant rate.
vi. List – Displays a list of every current transaction.
vii. Summary – Displays statistics relating to past and current transactions such as total frozen transactions,
total send-fails, and total receive-fails.
viii. Reset Totals – Resets the statistics displayed in Summary.
Misc.
ix. Robustness Test – Engine robustness test used to ensure the engine is running properly.
x. Echo – A simple tool used to echo back commands to the user, similar to the “echo” function used in the
Linux environment.
xi. Event Log – A means of logging all the input/output fromCFDP.
3. Sample CFDP Application
Consider the case where an operator would like to download the five most recent camera images from the
satellite. The following steps would occur in order to receive the images:
Step 1: The operator uses BARCoMmS Command to issue the “Download Camera Images” command with a
parameter of five (indicating that the satellite should send the five most recent files).
Step 2: The flight software receives the command and notifies CFDP Flight.
Step 3: CFDP Flight begins transaction 1 by sending down the most recent image.
Step 4: CFDP Flight waits for transaction 1 to complete successfully or for the transaction to be
cancelled/abandoned/suspended.
Step 5: If the file transfer was successful, CFDP Flight deletes the image from transaction 1 from on-board
memory as a means of memory management. CFDP Flight continues on to step 6.
Step 6: Repeat steps 3 through 5 until all files transfer successfully or cancel/abandon/suspend.
While these steps perform, in the background BARCoMmS Camera is constantly scanning a directory for any
new images. If a new image is found (e.g. an image that was transferred from CFDP Flight), then it will
automatically display in the Camera module.

Figure 3 Sample CFDP application for requesting camera images.
4. Output
BARCoMmS CFDP takes its displayed output straight from the CFDP library’s callback routine to print
statements. As such, it displays all information in a very verbose manner. This is great for debugging and simple to
follow during single transactions. Once multiple files are sending, however, the information is difficult to manage.
BARCoMmS CFDP handles this by sending the output to BARCoMmS Bulletin as well, where all the information
is processed and put in a user-friendly format for viewing. See the Bulletin section for more information.
5. Nodes
Unlike most communication frameworks that use IP addresses and ports directly to reference other
communication-capable entities, CFDP uses so-called “nodes” as a means of identifying those entities. A node,
however, is simply an IP/port pair. A file called mib.nodes defines these pairs. Because of this, whenever a new
connection is necessary, one will need to update the mib.nodes file with a new “node” with the corresponding
IP/port pair. While this is a drawback, it comes with the advantage of being capable of easily identifying CFDP
entities capable of communication.

B. Command
1. Overview
The Command module is still a naïve implementation of what will eventually become a fully equipped satellite
control and command interface. It is responsible for sending command packets to the satellite, as well as displaying
relevant telemetry received from the satellite.
Each command packet consists of a CCSDS Space Packet Header, which contains several fields pertinent to the
application. The first is the Application Process Identifier (APID). Each type of telemetry packet (e.g. events,
Guidance, Navigation, and Control data, and Health and Status data) and command packet (e.g. ping, downlink
buffer, and downlink camera images) has a predefined APID that distinguishes it from other telemetry or
commands. Further, every single command packet sent to the satellite has a unique ID, which distinguishes it from
other packets that may have the same APID. The BARCoMmS application assigns this value sequentially just before
it sends a packet.
Some command packets also contain additional parameters to specify actions the satellite should take. The
ground station operator assigns these values at the time of packet construction.
The flight software also downlinks telemetry packets. Most relevant to the Command module are Health and
Status packets, which contain various housekeeping data and are sent down once per second. Two such data are the
unique ID of the last command received by the flight software along with the status of that command (i.e. whether or
not the satellite will execute the command). Another is the received signal strength, a measure of the strength of the
connection from the satellite's point of view. The BARCoMmS application uses these data to determine what is
happening on the flight software at any given time during a communications pass.
2. User Interface
The Command module has two main viewports. The Telemetry Display, outlined in green in Fig. 2, further
consists of the telemetry activity light and a display for the received signal strength, a field in the Health and Status
telemetry packets. When the telemetry activity light is green and the number displayed by the received signal
strength display is above a certain threshold, the connection to the satellite is secure, and it is safe for the ground
operator to begin sending commands to the flight software. The Command GUI, outlined in blue in Fig. 2, is a user-
friendly interface that allows the ground station operator to create and send command packets at the push of a
button.
Figure 4 The two primary Command viewports: Command GUI (top, blue) and Telemetry Display (bottom right, green).

3. Communication with Other Modules
The Telemetry Display has two significant slots. When a telemetry packet passes through the specified UDP
port, the Telemetry Packet Listener Thread emits a signal. The Command module has a slot which then turns the
telemetry activity light green and starts a timer. After the timer expires, the telemetry activity light turns red,
indicating that the ground station received no telemetry packets for the specified timer length. Additionally, when a
telemetry packet passes through the specified UDP port and the Bulletin module accepts and parses it, the Bulletin
module emits a signal containing the received signal strength in the form of an integer. The Command module has a
second slot that displays this value next to the telemetry activity light.
The Command GUI has one significant signal. When the Command module sends a command, it emits a signal
containing the command’s APID and unique ID in the form of integers. The Bulletin module has a slot that accepts
these values and displays themaccordingly.
4. Communication with Flight Software
During the Command module’s initialization, it establishes an outgoing connection to the flight software. It
initializes the connection's endpoints, the BARCoMmS application and the flight software, by specifying their
respective IP addresses and the UDP port over which to communicate. It then ins tantiates a buffer of bytes that holds
the serialized packets. The Command module provides two methods by which to send command packets through
this connection.
The first is the Command GUI, which creates and sends command packets within the application. W hen a button
on the GUI is pressed,an object of that class is instantiated. This object, which acts as the command packet, contains
a CCSDS Space Packet Header and any additional command parameters. If the object contains additional
parameters, a dialog window opens which allows the user to choose the values of each parameter. Otherwise, the
Command module assigns the header fields that are unique to each command, namely the APID and unique ID. It
then serializes the packet, writes it to the byte buffer, and sends this buffer to the flight software through the
connection established during instantiation. Finally, the Command module emits a signal containing the APID and
unique ID in the form of integers to notify the Bulletin module that it sent a command packet.
The Command module is also capable of accepting command packets generated outside of the application. When
such a command packet passes through the specified UDP port, the Command Packet Listener Thread emits a signal
with the packet’s byte buffer. The Command module has a slot that accepts this and operates on the packet in its
serialized state. It extracts the APID and reassigns the unique ID to match the BARCoMmS sequential system. The
Command module then treats the packet like any other packet originating from within the BARCoMmS application.
It sends the packet to the flight software through the connection established during instantiation, and emits a signal
to notify the Bulletin module that it sent a command packet.

C. Bulletin
1. Overview
The Bulletin module provides real-time packet transfer visualization in a user-friendly format, allowing the
ground station operator to take a quick survey of the satellite’s status and make informed decisions regarding further
operations during a short communications pass.
Figure 5 The three primary Bulletin viewports: CFDP Display (left, blue), Command Display (right, green), and Navigation
(bottom, yellow).
2. User Interface
The Bulletin module consists of three main viewports. The CFDP Display, outlined in blue in Fig. 1, shows the
current and previous statuses of all CFPD file transfers. It organizes information into two columns, based on whether
the ground station sent or received the information. The top-level items, which each represent a single file transfer,
display the CFDP transaction number, file name, and file size. It displays any further details about the transaction,
such as sent or received metadata, file segments, EOF or finished indications, ACKs, and NAKs as children of the
top-level item. It displays any further details, including timestamps, as children of their respective parents or as
grandchildren of the top-level item.
Items in the CFDP Display are color coded to make errors instantly known to the ground station operator. In
general, green indicates that a transaction has completed successfully, yellow indicates that an ACK or NAK timer
has expired or that the CFDP engine has issued a warning message, orange indicates that the transaction has been
cancelled or that a fault has occurred, and red indicates that the transaction has been abandoned. A non -colored item
simply indicates that the transaction is progressing normally.
The Command Display, outlined in green in Fig. 1, shows all commands sent to the flight software and their
status according to the Health and Status telemetry packets received from the flight software. The top-level items,
which each represent a single command, contain the APID and name of the command. It displays any further details
about the command, including the unique ID, timestamp, and status of the command, as children of the top-level
item.
Items in the Command Display are also color-coded. In general, green indicates that the flight software has
received and acknowledged the command, yellow serves as the first warning that the flight software has not
responded to the command, orange serves as the second warning that the flight software has not responded to the
command, and red serves as the third and final warning that the flight software has not responded to the command.
Red can also indicate that the flight software received the command, but replied with a negative acknowledgment. A
non-colored item simply indicates the ground station has not yet heard a response, but that the first warning timer
has not yet expired.

Navigation, outlined in yellow in Fig. 1, provides several means by which to navigate through the two displays.
Located underneath the main displays, five buttons allow the ground station operator to expand or collapse a single
item and its children, expand or collapse all items and their children, automatically scroll to new items as they are
added, automatically expand new items as they are added, or choose from eight different methods by which to sort
the items in the displays. Additionally, it provides a search bar for ease of navigation.
3. Communication with Other Modules
The CFDP display has one significant slot. When the CFDP engine prints a new line to the terminal, the CFDP
module emits a signal containing the text in the line. The Bulletin module uses regular expressions to interpret this
text and determine what it should display: a more user-friendly tree item in the CFDP display.
The Command display has two significant slots. When the Command module sends a command packet to the
flight software, it emits a signal containing the command’s APID and unique ID in the formof integers. The Bulletin
module has a slot that accepts these integers and displays the new command. Additionally, when a telemetry packet
passes through the specified UDP port, the Telemetry Packet Listener Thread emits a signal containing the serialized
contents of the packet. The Bulletin module has a second slot that accepts this and extracts the APID. If the APID is
equal to one, indicating a Health and Status Packet, it extracts the unique ID and status of the last command received
by the flight software. The Bulletin module then displays this status as a child item of the specified command, and
color-codes the item accordingly.
Finally, the Command display has one significant signal. Within its second slot, which parses Health and Status
packets received from the flight software, it also extracts the received signal strength, another field in the packet. It
then emits a signal containing this value in the form of an integer. The Command module has a slot that accepts this
value and displays it accordingly.

D. Day in the Life
1. Initialization
The Day in the Life (DITL) module’s primary goal is to provide a ground station technician with visual, instant
information about the iSat’s event history and operations timeline. It is the only BARCoMmS module that exists
independently of the others. It cares only about incoming event PDU telemetry.
The DITL Log File simply records all application processes for potential review in case of a significant failure
event or application crash. The logging system is naïve in that all streams to it are software defined; the log file
manager does not track low-level content such as threads, memory blocks, thrown errors, etc. An additional DITL
Event Log File (not pictured) keeps a record of all event PDUs that the application has received. In case of an
application crash, power outage, or other critical event, the software can load this logged data to revert to its
previous state.
Fig. 1 covers GUI initialization only in broad strokes. The Qt Ui Child is parented to the host application
(DITL), enabling the reference of its children (e.g. GUI objects) from the application class scope. The viewport
layouts and geometries are software defined, but scale dynamically with GUI resizing by the user. The DITL
allocates static graphics items: definite graphical elements such as highlighting graphics items. It then defines
painters, brushes, and typefaces within the software, and so are not user configurable. Finally, the software allocates
and paints the application resources to their respective viewports, such as the application icon, the BARCoMmS
logo, and other GUI image resources.
After successful GUI initialization, the application will instantiate, allocate and populate objects of its data base
singleton classes. The DITL uses three database singletons:
1) Primary Event and Graphics Database (PEG)
2) Local Event Reference Database (LER)
3) Local Event Painter Reference Database (LPR)
Of the three, the DITL populates the PEG, the only database that with generated data; the other two, as their names
would suggest, are loaded on initialization from local files stored and upkept by ground control systems. The LER
and LPR hold references to expected events and origins and what, if any, the application ought to color them as,
respectively. A ground user can predefine LPR data via its configuration file, but may not change the LER. The LER
should perfectly mirror the events possibly logged by the iSat, and so removal of these without also doing so on the
flight software could lead to unrecognized event PDUs; adding possible events to the LER is allowable and safe, but
ultimately pointless without flight software additions to compliment it.
The PEG contains data pertaining to events (e.g. time, severity, source), their respective graphics items, time
parameters (e.g. timestep, earliest and latest times), and the DITL Tree Navigator (covered later). This data is
populated and expanded in real-time as the software receives event PDUs from the Packet Listener Thread. The
class also contains the necessary methods to extract and export data to the DITL Event Log File if necessitated by an
unexpected termination.
After the database singleton objects have been instantiated and loaded, the application prepares its graphics
viewports for event PDUs to begin populating. This consists of two simply, but important activities. Firstly, the
application will populate its leftmost column of the DITL Main Viewport (DMV; covered later) with possible events
from the LER database. Secondly, the application will prepare the DMV’s graphics scenes for event PDUs by
superimposing an incorporeal Cartesian coordinate grid on them, with an origin in the upper leftmost corner of each
scene.
Figure 6 DITL Module Instantiation Process

2. Event Population
The DITL module contains a very simple method to add an event to its database. This method connects to the
PLT’s PDU signal, and emits whenever the software receives a PDU. If the PDU is an event PDU, then the DITL
will add this event to its database. The DITL has a very simply ruleset for pairing events, as follows:
When the method receives an event, it checks to see if the event has a corresponding “start” event, in which case the
range on that event will become concrete. Otherwise, an event must be either a point, or an unfinished (unf.) or
unstarted (uns.) event, meaning that the application will assume that the event will continue on forever o r was
started in a previous event PDU. Both unf. and uns. events are reduced to finite ranges if the application receives its
partner event PDU.
3. User Interface
The module’s interface is very simplistic, consisting of three primary viewports: the DITL Main Viewport
(DMV), Tree Navigator (DTN), and Toolbar.
The DMV itself contains three child viewports, each of which serve as graphics displays for the primary timeline
display: namely, a Y-axis list of possible events from the LER, an X-axis timeline iterated by a user defined
timestep, and their intersecting grid of event PDUs. When hovering a cursor over an event, a ground us er can see
pertinent information about that PDU via a tooltip box. Additionally, the DTN nests events under user defined
categories. By default, the software nests events by their severities. The DITL will center on and highlight an event
of interest on the DTN when a ground station user clicks on its corresponding tree item.
Figure 7 The three primary DITL viewports: Main Viewport (left, blue), Tree Navigator (right, green), and Toolbar (bottom,
yellow)

The DITL Toolbar only houses two buttons, but like the rest of the software is easily expandable. The “Show
Legend” button does exactly that: opens a modular always-on-top dialogue that displays the event color reference
legend. This portion of the software is not yet complete, and so has been loaded with a canned image file
representing a probably legend. The second button, “Change Zoom,” allows the user to select their desired X-axis
timestep (in minutes). Upon a zoom event, the application will repaint its scenes with the new timestep.
IV. Resources and Acknowledgments
Works Cited
Dankanich, John W., Kurt A. Polzin, Derek Calvert, and Hani Kamhawi. "NASA Technical Reports Server
(NTRS)." - The Iodine Satellite (iSAT) Hall Thruster Demonstration Mission Concept and Development. NASA,
28 July 2014. Web. 10 Aug. 2016.
Appendix
Source code for BARCoMmS v1.0 is available at https://github.com/Rileybrains/BARCoMmS. Any
questions about the software can be directed to riley.s.waite@gmail.com.
Acknowledgments
The intern group would like to thank mentors Scott Akridge, Jim Cecil, and especially Jamie Moyers for their
support, guidance, and patience. We thank Tina Atchley for her support as our intern coordinator, and Daniel Heater
for his generosity in selecting us for these positions. We would also like to thank Alex Lay, a volunteer intern, for
his hard work on, and dedication to, the project.

BARCoMmS Ground Station Testing System

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (12)

Similar to BARCoMmS Ground Station Testing System

Similar to BARCoMmS Ground Station Testing System (20)

BARCoMmS Ground Station Testing System