Project Report
Version 6 3/29/2016
FTMS
Client
Cary Cupka
Project Team Members
Michael Torres (Leader)
Dan Marquez (Leader)
Hoang Nguyen
Carman Frith
The Collaboratory and Department of Engineering at Messiah College acknowledge and are
grateful to the EPICS program at Purdue University for the use of their project reporting
template in developing this template.
Project Report: Version [6] [3/29/16]
ABSTRACT
Once outside radar range, small planes flying in remote locations must be tracked by
alternative means. Organizations focused on emergency relief, humanitarian development and
missionary support need to follow such flights, for reasons of safety and more. The
Automatic Flight Following System (AFFS) owned has been safety tested and used
extensively for this purpose, but its central microcontroller (a small single board computer /
SBC) has become obsolete, since it is no longer marketed or supported by the manufacturer.
Thus, FTMS at Messiah College has agreed with stakeholder Cary Cupka to upgrade AFFS
1.0, so additional units could be fabricated. With the technological move towards making
electronic systems mobile, FTMS has decided to reinvent the wheel. We plan to replace the
existing Rabbit SBC in AFFS 1.0 with a new microprocessor capable of using consumer
electronic technology e.g. tablets and smartphones to interface AFFS with the pilot. The ACU
will be able to measure things such as fuel level, pressure altitude, and airspeed. Replacing
the existing Rabbit SBC in AFFS 1.0 with a new microprocessor will involve both hardware
and software challenges, since the physical footprint and pin-out of each do not match. The
microprocessor elected for further research and application has been the Arduino Mega ADK.
To streamline the process of understanding the AFFS system as well as creating functional
code, the introduction of MagicDraw UML, a software modeling tool that will ease
communication and planning with our stakeholder.
VERSION HISTORY
Version
1
Author(s)
Joel Love
2
3
Joel Love
John Deseno
4
5
Brianna Wenger
Michael Torres
Dan Marquez
Michael Torres
Dan Marquez
Hoang Nguyen
Date
12/18/1
3
5/13/14
12/14/1
4
5/7/15
5/15/15
Description
Report Creation
File Name
FTMS_Report
Updated
Updated
FTMS_Report
FTMS_Report
Updated
Updated
FTMS_Report
FTMS_Report
3/29/16
Updated
FTMS_Report
Page 2 of 6
Project Report: Version [6] [3/29/16]
Section 1: Project Identification
The first of the Collaboratory core values is Sharing the Gospel of Jesus in life, deed and
word so that others may come to know him. In accordance with this, this project strives to
complete a AFFS prototype for the safety and well being of pilots in remote locations. Our
principle investigator, Cary Cupka will consult with us as we serve groups specializing in
missionary or translation work with technical expertise. JAARS provides leadership in
technical support and transportation to meet these safety and well-being needs.
Section 2: Specifications
Project Specifications
1. AFFS 2.0 must function similarly to AFFS 1.0, include new features, and include interfacing
with AFFSWin
a. Its user interface will be located somewhere near the pilot.
b. It should send data to AFFSWin and receive data from AFFSWin in the same format as AFFS
1.0.
2. AFFS 2.0 will use an Arduino Mega ADK that is available for purchase to manufacture
additional AFFS units
3. AFFS 2.0 will have the same form-factor as AFFS 1.0
4. It will be no heavier than TBD
5. AFFS 2.0 will be able to measure the following using A/D converters and I/O pins on the new
microprocessor:
a. Flight dynamics
b. Flap position
c. Pressure altitude
d. Air speed
6. AFFS 2.0s ACU will be able to be controlled by a smartphone/tablet using Bluetooth
technology.
7. AFFS 2.0 will be able to receive messages and convert them to voice using text-to-voice
capabilities
8. AFFS 2.0 will communicate with a Garmin 100 AVD global positioning system along with a
Navspark global positioning system and report this data to AFFSWin.
Section 3: Conceptual Design
The project will use an Arduino Mega ADK. This microprocessor will interface with different
systems on the plane using its A/D converters and I/O pins in order to measure and display
different levels of the systems. This system will also be interfaced with a 10DOF board and a
Navspark that will measure flight dynamics and gps positions. It will then display this
information upon request to the ACUs display or inform the pilot using text-to-voice
technology as well as send this information to a ground station.
Section 4: Detailed Design
Page 3 of 6
Project Report: Version [6] [3/29/16]
Spring 2013, we completed porting the AFFS 2.0 code and corrected it into a state where it
would compile. Fall 2013, we began debugging and testing the code to ensure it works as
desired. We also completed the installation of AFFSWin onto our project computer and
interfaced it with its own Paccom modem to act as a ground station. In Spring 2014, we
continued debugging the Send code. We also began interfacing the GPS with the
microprocessor in the Spring 2014 semester.
In Fall 2014, we decided to change the goals of our current project. We not only
restructured the older project to use multiple modes of communication such as the HF
Paccom modems, but we also began to follow the aviation industry practice of integrating
consumer technology (Smartphones/Tablets and Bluetooth) into our new design.
After extensive research on our Rabbit BL2610 microprocessor we realized it was not
widely portable. Therefore, if we ever wanted to upgrade our microprocessor incase we
needed more A/D converters, I/O pins or any other capability, we would need to port all of
the code that we had previously written into a new language that some software is able to
compile to machine code. The problem is that the Rabbit SBC microprocessor we currently
have is compile able only with the dynamic C language. This is good in one way because it is
difficult for competitors to steal code from AFFS, but in another way it is not good because
it makes updating code a very difficult task. Along with this, some processors are not
designed to include the Bluetooth chip needed for communication. This is a major problem
and we need to make sure that as we go along deciding which processor to use that the
chosen processor either has a built in Bluetooth chip, or it is capable of add-on Bluetooth
technology. Extensive research and details are shown in the Microprocessors Project Record
(Microprocessors Project Record.docx) concerning whether or not our current
microprocessors would suffice for the project.
Another area that we worked on during Fall 2014 was obtaining a functional GPS
capable of readable data. The GPS we used to have was a Bendix/King KLN90a model that
was functional and capable of outputting NMEA data. This is exactly what we wanted, but as
we began to test the KLN90a at the start of the Fall 2014 semester, it failed and we soon
realized that purchasing a new one or asking Carman Frith for an older used one was the next
correct move. Fortunately, Carman had an old Garmin 100 AVD to his disposal, which he
shipped to us allowing us to begin working with the GPS as we were before. We were able to
use an oscilloscope and adjust its trigger and timescale in order to record one string of data,
which is included in the report. This has not helped us discover what exactly the GPS is
receiving yet, but we hope in the future using a real-time decoder supplied by Tony Beers, we
will be able to figure out what the receivers data is and begin to parse the data with our new
microprocessor. A more detailed explanation of our research is shown in the FTMS GPS
Project Record (FTMS GPS.docx.)
Bluetooth capability was another aspect of research that we spent a great deal of time
on. Bluetooth is a short distance communication that transmits very low power levels. It can
transmit any type of data which is why we originally had the idea to use a smart phones
built-in GPS to fix a location of where the plane was and send that data to the microprocessor
using the phones Bluetooth system. Smartphones have apps already written to make the
smartphone a GPS transmitter using Bluetooth. The only problem we found with this idea is
that the smartphones GPS receiver is not as accurate as a GPS receiver like the Garmin 100
AVD. This is important on planes flying in remote locations because they need to feel safe
wherever they go. On the contrary, the smartphones Bluetooth capability is extraordinary, and
Page 4 of 6
Project Report: Version [6] [3/29/16]
we plan to use the smartphones Bluetooth system in order to account for the voice-to-text
transmission and text-to-voice transmission. A more detailed description of Bluetooth
research is shown in the Bluetooth Technology (FTMS_bluetoothResearch.doc.)
Spring of 2015 began with us choosing a microprocessor. After looking at some of the
popular microprocessors we chose an Arduino because it is easy to use. For more information
see the FTMS Micro document (FTMSMICRO.docx.) Tony Beers had an extra Arduino uno
so we began using that microprocessor to program two other devices that we are going to use
in the final product. The first device was a 10DOF. 10DOF stands for ten degrees of freedom
and can be used to measure flight dynamics, how a plane is moving through the air, as well as
altitude and direction. We also began programming a display unit that will allow the user to
see the different menu options. Once we began programming the display unit we realized that
we were going to need a larger microprocessor to connect the entire display so we decided we
will be upgrading to an Arduino Mega ADK. The Arduino Mega ADK has a lot of ports and
can be interfaced with an android phone.
We also looked at what type of on board global positioning system we may want to get as
well as collecting more information about global navigation satellite systems. Our one project
partner mentioned using Cospas-Sarsat so we wanted to do more research on the system.
Cospas-Sarsat is a global satellite system that is used to detect emergency calls and forward
that information to local search and rescue. More information about this system and global
navigation satellite systems in general can be found in the GNSS Project Record (GNSS
Project Record.docx.) We also looked at several GPS chips and will probably acquire the
Navspark since it uses more than one global navigation satellite system.
Fall of 2015 began with the effort of recovering lost literature, research and documentation of
the project from previous years, due to the lack of overlap from the previous year. Once the
team understood the direction the project was heading, we met with our stakeholder Cary
Cupka to refine this understanding and begin to prioritize what needed to be done on the
project itself to further progress towards a finished prototype. Refer to Project Record 1 Stakeholders Objectives for more information.
Research was also conducted on the Unified Modelling Language (UML) for the purpose of
being able to effectively model the hardware and software components of the AFFS system.
To aid with this research and visualization, MagicDraw software was acquired in order to
better format the ACU and communicate with our stakeholders more effectively. Refer to
Project Record 3 - MagicDraw Software for more information.
We have also have begun to look into the vibrational issue. Only a few hours of research was
conducted in order begin conceptualization of the problem and possible solutions, however
more research will be done once the microprocessor is purchased and coded and when the
project is closer to having a working prototype. Refer to Project Record 2 - Vibrational
Problem Research for more information.
Spring of 2016 began with refocusing the project on its future and the direction we wanted it
to head. As a result, we began by emailing and attempting to contact Cary Cupka, our
stakeholder, to prioritize our direction for the semester and our first MVP. However, we were
unable to reach him due to extraneous circumstances, until the last week in February. As a
result, much of February was spent researching UML, going over the existing code from the
Rabbit microprocessor and researching the AFFS manual for our own benefit moving
forward. Upon talking to Cary, however we decided that it would be best to reprioritize our
Page 5 of 6
Project Report: Version [6] [3/29/16]
project by focusing firstly on choosing what microcontroller we wanted to use in our ACU
and also to continue to establish a means of serial communication with our microcontroller
and the ground controls AFFSWin.
We found that the best way to establish a serial connection between AFFSWin and the
microcontroller would be to use an RS-232 type connection (refer to the Arduino-AFFSWin
Serial Communication project record for more detail.) Also, we thought it would be most
advantageous to us and upcoming groups to have better reasoning and documentation than
the previous year on what microcontroller we will use going forward. As a result, we
conducted some research and decided that best suited microcontroller for our project would
be the Arduino Mega 2560 (refer to Decision Matrix for Microcontroller for ACU project
record.)
Section 5: Delivery
N/A
Section 6: Service
[For projects involving engineering work, a detailed description of what goes in each
section can be found at the IPC Project Report page on the Collaboratory wiki.]
Section 7: Conclusion
Due to the directional change mid-way through the semester, we did not make very
much progress on UML coding, however we were able to further our progress towards
enabling coding to be done in the microcontroller, as well as allowing for serial
communication between the microcontroller and AFFSWin. As a result of this, as well as
deciding on what kind and specifically what microcontroller to move forward with, we are
now in a position to begin porting the code and communication of the ACU. In addition we
will constantly keep track of where we are in the original code while porting it into the
microprocessor for easy translation into the UML coding for MagicDraw.
Page 6 of 6
