alternate aviation solutions 2008 - messiah college · a satellite-based company that offers many...

Alternate

Aviation

Solutions

2008

Final Design Report

Jeffrey Eng

Jonathan Patrick

Nathan Horst

May 9, 2008

Alternate Aviation Solutions 2008 – Final Design Report Page 1

Note that portions of this document may be

protected through a non-disclosure agreement

between JAARS, Inc and Messiah College. As

such, this document may not be reproduced in

part, or in whole, without the express permission

of JAARS, Inc.


Abstract

Alternate Aviation Solutions (AAS) 2008 is a third-year senior design project within the

Department of Engineering at Messiah College, exploring opportunities to better serve those

in the mission aviation field through low-cost alternative communications and flight tracking

solutions. In adapting JAARS’ Automated Flight Following System (AFFS) to interact with

the line of Codan transceivers currently used by the team’s client, Mission Aviation

Fellowship (MAF), AAS 2008 has created a lower-cost and simplified solution to serve

MAF’s fleet of 134 aircraft in 51 locations worldwide, and paved the way to better the

manufacturability of JAARS’ AFFS in future years.

Acknowledgements

This project has been guided in this and past years by many talented and generous

individuals. First and foremost, AAS 2008 gratefully acknowledges the support of Dr.

Harold Underwood and Dr. Don Pratt, faculty of the Department of Engineering and faithful

advisors to this team’s work. Dedication and expertise are two characteristics which only

begin to describe these individuals’ work over the years. Secondly, AAS 2008 is

appreciative of the support of Mr. Cary Cupka, Research and Development Coordinator for

Mission Safety International (MSI), for his assistant in the initial vision of this and all past

AAS projects. Cary Cupka has been a servant to the mission aviation field for many years,

and his instinct and knowledge in all relevant areas have been gratefully appreciated.

Additionally, Mr. Tim Dyk of MAF and Mr. Carmen Frith of JAARS have endured many

phone calls, emails, and other various pleas for support and have generously given of their

time and patience. Without the support of these two individuals, the work of AAS 2008

would not have been accomplished. Last, and certainly not least, AAS 2008 appreciates and

acknowledges the support of Mr. Marten Beels, a graduate of Messiah College and member

of the AAS 2006 project team. Martin Beels was able to jump start this year’s team with

much needed information and guidance, and was on-call throughout the year to support the

team’s technical needs. There are a number of others within MAF, JAARS, and Messiah

College that have given of their time in less visual ways. For their support and

encouragement, the team is thankful and hopes it has made a positive impact in the mission

aviation field.


Contents 1 Introduction ............................................................................................................................................... 4

1.1 Description .......................................................................................................................................... 4

1.2 Literature Review ................................................................................................................................ 4

1.3 Solution ............................................................................................................................................... 7

2 Design Process ........................................................................................................................................... 7

2.1 Modification of the ACU (Hardware) .................................................................................................. 7

2.2 Modification of the ACU (Firmware) ................................................................................................... 9

2.3 Modification of AFFSWIN (Software) ................................................................................................ 10

3 Implementation ....................................................................................................................................... 12

3.1 Construction ...................................................................................................................................... 12

3.2 Operation .......................................................................................................................................... 13

3.2.1 AFFSWIN ..................................................................................................................................... 14

3.2.2 AFFS Control Unit ....................................................................................................................... 14

4 Schedule ................................................................................................................................................... 15

5 Budget ...................................................................................................................................................... 17

6 Conclusions .............................................................................................................................................. 17

7 Recommendations for Future Work ........................................................................................................ 18

7.1 Upgrade of the Single-Board Computer ........................................................................................... 18

7.2 Power Circuitry .................................................................................................................................. 19

8 Appendices ............................................................................................................................................... 19

8.1 ACU Firmware Revision Changes ...................................................................................................... 19

8.2 AFFSWIN Revision Changes ............................................................................................................... 21

Tables and Figures Figure 1 - Diagram of DB-25 socket on rear of ACU.......................................................………………………..…7

Figure 2 - AFFS data packet encapsulation within a CICS PAGECALL message……………………………….........10

Figure 3 - Original AFFSWIN input character state diagram……………………………………………………………………11

Figure 4 - AFFSWIN input character state diagram with modifications.....................................................11

Table 1 - Feature comparison of Rabbit BL1500 and BL1800………………………………………………………………......8

Table 2 - Schedule……………………………………………………………………………………………………….…...................15-17

Table 3 - Expenses and Funding……………………………………………………………………………………………………………..17


1 Introduction

1.1 Description

AAS 2008 sought to develop a combined flight tracking and text-based communications

package using Codan high frequency (HF) New Generation Transceivers (NGTs), a standard

for the fleet of aircraft owned by MAF. Currently, MAF relies on voice and paper solutions

when tracking its fleet and communicating with its pilots, while barely tapping or just

beginning to tap the integrated power of their Codan NGTs to better support their flight

tracking and communication needs. Codan NGTs natively support a Computer Interface

Command Set, or CICS, which allow automatic polling of an attached Global Positioning

Service (GPS) device, text messaging between units, frequency and channel selection, and a

host of other useful commands. CICS was designed to allow a user to operate her Codan

from a computer terminal or other computer system designed around these commands.

Essentially, Codan NGTs are both a typical transceiver and a digital interface combined,

where most other HF flight tracking and communication solutions require a separate pair of

modems between a user or device and each transceiver. MAF is aggressively working to

equip their entire fleet with these Codan NGTs, a significant investment for an organization

with a limited budget, and would like to see a return on this new technology. This was the

problem AAS 2008 sought to address. Developing a solution that worked around the

capabilities of the Codan NGT would allow MAF to see a return on their investment in

technology that would greatly increase the efficiency of their operation and the safety of their

pilots.

1.2 Literature Review

Blue Sky Network (BSN)

A satellite-based company that offers many different global tracking and communications systems, ranging from ground and marine transportation to aviation. Satellite communication technology, such as that offered by BSN, often offers solutions that meets or exceeds the need of a client, however the up-front and monthly costs associated with these solutions are typically above the budgetary allowances of most mission aviation departments. That said, satellite communications technologies are becoming increasingly attractive and affordable. www.BlueSkyNetwork.com


Codan NGT

HF radio solutions are common to many mission aviation departments in the field today. HF

radio solutions are attractive as they are serviced entirely in-house, where the operator pays

no monthly fee and operates its own HF radio network. Codan, a manufacturer based in

Australia, produces a line of HF transceivers that are well suited to this purpose. The AAS

2008 project team has specifically looking at Codan NGT SRs, as they seemed to serve the

team’s apparent needs, are well documented, and are well tested in the field.

www.Codan.com.au

JAARS Automated Flight Following System (AFFS)

JAARS is a branch of Wycliffe Bible Translators. Their mission is to provide aviation and radio services to allow Bible translation in every language around the globe. JAARS was the primary developer in its AFFS solution, a proprietary system consisting of a control unit in the cockpit and a software dispatch interface. The aircraft’s instrumentation and GPS data are fed into the AFFS control unit, which relays the information via a generic Pactor-capable HF transceiver. Reaching the dispatch station, the flight data is fed through another Pactor modem into the dispatch interface, AFFSWIN. The JAARS AFFS is a commercialized solution offering many benefits to pilots and their organizations. AFFS Datasheet, available upon request

C/O JAARS

Garmin 16 GPS

The Garmin 16 GPS unit is a complete GPS sensor including embedded receiver and

antenna, designed for a broad spectrum of system applications. The Garmin 16 GPS unit

tracks up to twelve satellites at a time, while providing fast time-to-first-fix, one-second

navigation updates, and low power consumption. Used by AAS 2006, the NMEA-0183

output format is well documented and supported by the Codan NGT.

www.Garmin.com/products/GPS16/

Alternate Aviation Solutions (2006)

The first iteration of the Alternate Aviation Solutions project, AAS 2006 designed and

protyped a flight tracking solution using a pair of Codan NGT SR radios and a Garmin 16

GPS unit. This solution used a polling technique of flight tracking, where the dispatch

officer requests and receives a location report, visually displayed using an Automatic

Position Reporting System (APRS), with the push of a button.

Final Design Review, available upon request

C/O Messiah College Department of Engineering


Continuing Alternate Aviation Solutions (2007)

The second iteration of the Alternate Aviation Solutions project, AAS 2007 designed and

protyped a pilot-to-dispatch text-based communications and flight tracking system using

satellite technology. This solution employed a pilot interface module (PIM), giving the pilot

the ability to send a hard-coded text message from the cockpit to the dispatch station. The

pilot’s location is sent automatically using the GPS functionality built into the satellite

modem, and displayed using Google Earth.

Final Design Review, available upon request

C/O Messiah College Department of Engineering

Mission Safety International (MSI)

Since its incorporation as a non-profit mission agency in 1983, MSI has worked tirelessly to

meet the safety needs of mission aviation departments spread from one side of the globe to

the other. While small and agile as an organization, MSI has developed connections with a

host of experienced aviation and safety volunteers who can be called upon at a moment’s

notice to meet specific needs just about anywhere in the world.

www.MSIsafety.org

Mission Aviation Fellowship (MAF)

MAF is a mission aviation department whose passion is to see individuals, communities, and

nations transformed by the Gospel of Jesus Christ. They promote this transformation by

positioning Christ-centered staff in strategic locations worldwide utilizing aviation,

communications, learning technologies, other appropriate technologies and related services.

www.MAF.org

The Collaboratory for Strategic Partners and Applied Research

The Communications Group of the Collaboratory is the sponsoring organization, along with

the Department of Engineering, of the AAS continuing project at Messiah College. The

Communications Group exists to meet the needs of clients with low cost, high quality,

effective solutions appropriate to the context of the application in the area of communication

technologies.

www.theCollaboratoryonline.org


1.3 Solution

As recommended by MSI, AAS 2008 pursued a solution that builds upon existing

technology rather than work to develop an ultimately competing design. The team lacked a

unique experience in aviation, and thus, in cooperation with JAARS, sought to build upon

the already tested and proven AFFS solution. In this, AAS 2008 removed the pair of Pactor-

II modems in the AFFS solution and modified the software of its ACU and AFFSWIN

dispatch interface for interoperability with the digital CICS native to the Codan NGTs

employed by MAF. In removing the Pactor-II modems, the AAS 2008 team was able to

reduce the final approximate cost of the AFFS solution (one dispatch unit and one aircraft

unit) by $1400. This savings will soon allow the JAARS AFFS to be a more affordable

solution to those organizations using the Codan NGT, and will allow MAF to automate their

flight tracking processes to better provide for the safety of their pilots and advancement of

their work.

2 Design Process

2.1 Modification of the ACU (Hardware)

In removing the Pactor-II modem from the ACU, the team had three main concerns. The

first was to reroute the serial communication from the single-board computer (SBC), through

the display board, from the Pactor-II modem to the rear DB-25 socket. The team originally

assumed the serial connection between the SBC and the Pactor-II modem was within the

enclosure, but was surprised to find that this serial connection occurred outside of the

enclosure. The Tx pin of the SBC

(pin 7 on the rear DB-25) was

connected directly to the Rx pin of

the Pactor-II modem (pin 25) through

the DB-25 connector (and vice versa

with the Rx pin of the SBC, pin 19, to

the Tx pin of the Pactor-II modem,

pin 13). See Figure 1 for

clarification. This clever design

allowed the team to easily bypass the

Pactor-II modem’s functionality,

leaving only the task of redesigning

the cable that connected to the DB-25

connection from the back of the

ACU.

Figure 1 Diagram of DB-25 socket on rear of ACU


While the functionality of the Pactor-II modem was easily removed in severing this serial

connection, the team further realized that it must deal with the modem’s power circuitry that

feeds the SBC and display board. The ACU is designed to accept power inputs from +9 to

+32 Vdc, with an approximate load of .5A. The modem is currently responsible for dropping

this voltage to a level appropriate for the SBC and display board. For the purposes of its

demonstration, and with consideration of time, the team physically left the modem within the

enclosure of the ACU for the use of this power circuitry. An ideal solution, of course, would

remove the Pactor-II modem entirely. This is further discussed in Section 7,

Recommendations for Future Work.

AAS 2008 also worked to upgrade the BL1500 SBC internal to the ACU to allow for future

manufacturability of the system as a whole. Currently, JAARS is unable to produce new

units as Rabbit Semiconductors, the manufacturer of the BL1500, has halted production of

these single-board computers. JAARS has been unable to upgrade their design to a new

SBC, and asked that AAS 2008 incorporate this upgrade into their project. To build on the

AFFS solution, this problem in manufacturability must be solved to provide any real solution

to MAF.

After much research, the

team chose to upgrade to the

BL1800, also of Rabbit

Semiconductors. The

BL1800 offers 4 CMOS-

compatible digital outputs, 6

digital inputs, and 14 user-

configurable input/outputs

(see Table 1 for a side-by-

side comparison). At the

time, with the team’s yet-

limited understanding of the

AFFS solution (only knowing

its use of the subservient BL1500 and its features, without knowing how those features were

employed), the team purchased the BL1800 thinking 24 I/O lines would be sufficient for the

needs of the modified ACU.

Unfortunately, however, the team later realized the BL1800 would not be a sufficient replacement for the outdated BL1500. The BL1500 sported 26 user-configurable I/O pins whose functionality were difficult to replace using only the 14 user-configurable I/O pins of the BL1800. While it may have been possible to make amends for this either in software (employing the dedicated input and/or output lines) or with additional hardware (an I/O expansion chip), the team determined it would be unable to deliver an appropriate solution

BL1500 BL1800

Microprocessor 9.216 MHz 29.5 MHz

Flash 256 KB 256 KB

SRAM 128 KB 128 KB

Digital Inputs 0 6

Digital Outputs 0 4

Configurable I/O 26 14

Serial Ports 1 xRS-232 1xRS-485

2xRS-232 1xRS-485

Real-Time Clock Yes Yes

Voltage 9-12 Vdc 8-40 Vdc

Board Size 3.2” x 2.3” x 0.56” 3.50” x 2.50” x 0.94”

Operating Temp -40ºC to 70ºC -40ºC to 70ºC

Humidity 5-95%, non-condensing 5-95%, non-condensing

Table 1

Feature comparison of Rabbit BL1500 and BL1800


under its time constraints when this problem surfaced. The team regrets not being able to replace the SBC, as requested by JAARS and needed for any practical application of its work this year, but is hopeful that a future team can take this aspect of the project, as AAS 2008 still believes it to be achievable. This task is outlined in Section 7 of this report, under Recommendations for Future Work.

2.2 Modification of the ACU (Firmware)

Without the upgrade from the BL1500, the team essentially focused only on input and output,

disregarding the inner-workings of the firmware’s functionality or making any attempt to

port it to a new SBC. To this end, the team had three main concerns. The first was to

eliminate any dependence on the Pactor-II modem, including its initialization. The team had

little trouble in removing this initialization as the original developers were kind enough to

neatly package everything into a single subroutine. Also necessary in removing the Pactor-II

modem was removing strings of data specific only to the Pactor-II modem, as opposed to

those strings of data meant to be transmitted. The Pactor-II modem has its own command

set, all instances of which were removed.

Slightly more difficult was deciding how to handle cases where the firmware behaved in

certain ways based on specific modem commands sent from the modem to the SBC, such as

“*** CONNECTED TO” or “*** NO RESPONSE”. In these case statements, the team

decided to employ a standard in which it would always follow the best case, or the path the

firmware would have taken assuming there were no problems in the modem’s initialization

or connection. The Codan NGT’s use their own connection routines and error correction, so

it is a safe assumption to assume that the connection will always be made properly if the

Codans in the cockpit and dispatch station are set up correctly.

Finally, the team was able to tackle the complex input and output, translating these data

streams from that which is understood by the Pactor-II modem to that which is understood by

the Codan. The team was able to employ the same serial interface used with the Pactor-II

modem, including its I/O buffers and read/write command set. This greatly simplified what

could have been a much more complex task. Deciding to keep JAARS’ packet structure

intact, so as to best keep the original functionality of the AFFS system, the team decided to

encapsulate the firmware’s packet construction within the CICS PAGECALL, or text

message, command.

To use the PAGECALL command, the team had to locate the construction of each data

packet sent from the ACU to AFFSWIN (the dispatch interface) and add both a prefix and a

suffix. Figure 2 illustrates this process. Essentially, the firmware builds packets to send in

two instances. The first is when the pilot, either manually or automatically, decides to send a

message to the dispatch station, and the second is when the pilot declares an emergency

situation and latches the emergency switch on the ACU. In both of these cases, the packet is


built within the

ACU’s firmware

and sent over the

serial interface.

The team had to

find these loops

within the

firmware, and add

the prefix “pagecall <dispatch ID> ‘”. PAGECALL designates the command being asked of

the Codan through its CICS command set, <dispatch ID> is the numeric radio ID specific to

the tracking station, and the single apostrophe designates the beginning of the variable text

message, or AFFS data packet. After the loop is allowed to complete its packet build, the

final suffix is added, “’CR”. The final apostrophe designates the conclusion of the variable

text message, or AFFS data packet, while the Carriage Return (0x0D) instructs the Codan to

process the command.

In this encapsulation, the team faced one particular challenge. The PAGECALL command

can accommodate a variable message of only 64 characters. Quite often, especially when a

text-message is included in the AFFS Data Packet, the length of that packet is well over 64

characters. To ensure that the packet length never exceeded 64 characters, logic was inserted

that removed all “non-essential” data from the packet in any instance where a text-message is

included. In these cases, only the pilot’s callsign, GPS coordinates, and the text-message are

included. All other data (persons on board, fuel efficiency, etc) are outputted with the next

available packet not including a text-message. Using this method, there are always 26

characters available for a text-message within the packet of 64 characters. After truncating

the five stored messages that were longer than 26 characters, the team’s new methodology

was tested and proven successful in ensuring a data packet length of no longer than 64

characters, as specified by the CICS PAGECALL command.

One final task was to implement a system which allows the pilot to input the tracking

station’s radio ID. This is a new concept to the AFFS system, as radio IDs were not

originally needed. Thankfully, this was somewhat easy to overcome. Using Codans, the

AFFS system no longer has a use for storing callsigns. Because of this, the team was able to

reallocate this functionality to allow it to store radio IDs.

2.3 Modification of AFFSWIN (Software)

The last in this three part modification process, AFFSWIN, the dispatch interface, was

subsequently altered to extract the AFFS data packet that was encapsulated within the

PAGECALL command. To the operator, all functionality of the AFFS system, as to the

pilot, must appear unchanged. To accomplish this, two components required modification.

Figure 2

AFFS data packet encapsulation within a CICS PAGECALL message


The first, and most important, was a

restructuring of the state machine used

to parse all data input from the radio.

The original developer had created a

sophisticated character-by-character

state machine designed to extract data

from the AFFS data packet into

AFFSWIN. As the team strived to

preserve the original functionality of

the AFFS system, and as the original

AFFS data packet was still intact within

the PAGECALL command, much of

this state machine could also be

preserved. See Figure 3 for a visual representation. The major modification to be made was

added as a prefix to this state machine, first ensuring that the string of data received from the

Codan was, in fact, a PAGECALL. Second, the sender’s ID was extracted to keep the unique

“ping-back” method of communication, where all conversations are initiated by the pilot and

all messages from the dispatch officer are kept in queue until this communication is received.

In extracting the sender’s radio ID, AFFSWIN has no need to keep tabular storage of the

aircraft being tracked, which greatly simplifies its source code. Last in this modification to

the state machine was an extraction of the automatically generated timestamp included with

each PAGECALL. Originally, AFFSWIN depended on timestamps included in the string of

data received from the Pactor-II modem. With its loss, AFFSWIN must now depend on a

similar timestamp

automatically generated by the

Codan radio. These

modifications can be seen in

Figure 4. As also seen in

Figure 4, all states concerning

usage of the Pactor-II modem

were left intact, as the very

specific commands which

would guide AFFSWIN

through these states will no

longer be seen.

Figure 3

Original AFFSWIN input character state diagram

Figure 4

AFFSWIN input character state diagram with modifications


The second modification made to AFFSWIN, and very minor in scale compared to the

modification of its input parsing mechanisms, was the alteration of its “Modem Commands”

menu option. Quite clearly, this feature is no longer useful without the Pactor-II modems,

although its usage is quite similar to a terminal gateway to the Codan radio. As such, slight

modifications were made, largely in labeling alone, to make this a “Codan CICS Commands”

menu option which allows the dispatch operator to issue an alternate CICS command to the

Codan radio.

3 Implementation

3.1 Construction

Several revisions were made to the team’s planned outcomes throughout the design and

implementation of these modifications. As stated in Section 1.3, the team’s original concept

was to create a system similar to JAARS’ AFFS built on the CICS framework of the Codan

NGT. With little experience in aviation, and knowing little about the special needs of pilots,

this original idea was quickly scrapped in favor of building on the already proven and

capable AFFS solution. Once this decision was made, with the input of the team’s various

sponsors and clients, the team moved to secure a Non Disclosure Agreement with JAARS to

secure the needed information to modify its AFFS solution, including source code and

detailed schematics of the ACU itself. While this process was moving along, the team took

time to do as much research as possible, at the time learning about the Codan NGT and its

CICS architecture and exploring various options for the AFFS system, such as changing its

LED display and possibilities for an upgraded microcontroller (as suggested by MSI as

specific needs of the AFFS).

One challenge the team faced at this point in conception was the struggle to research and

design around a system with very little published literature or technical details. A simple

task such as selecting an upgraded microcontroller became a large challenge as the team

knew nothing about the specific requirements of this microcontroller. Much of the team’s

research in this early stage of the project produced results that were quickly invalidated when

addition information would be passed from JAARS (as the Non Disclosure Agreement was

solidified).

When more information did become available, the team quickly shaped its focus on two main

tasks. First and foremost, the team wanted to be sure to make all necessary modifications to

hardware, firmware, and software to allow the JAARS AFFS system to function successfully

with the Codan NGT using the CICS architecture. Secondly, the team wanted to make all

efforts to upgrade and replace the existing SBC, as this presented the greatest challenge to the

system as a whole, blocking any attempt at reproducing the team’s modified design. As an


aside, the team also wanted to make some attempt at replacing the current LED display, as

MSI seemed to suggest this display did not satisfy most pilots.

Along the path to completion, the team quickly devised a strategy for emulating the AFFS’

functionality using the CICS PAGECALL command, as discussed in Section 2.2. However,

the team hit a road-block when it discovered its hoped-for replacement of the BL1500 SBC,

the BL1820, would not suffice. Largely due to problems discussed earlier (a lack of

information early on and a lack of understanding of the AFFS system), the new BL1820 SBC

was purchased on spec alone, a seemingly great match to the BL1500. More about this can

be read in Section 7, Recommendations for Future Work, but this issue with the SBC was

clearly the team’s greatest disappointment. However, in jettisoning this task, the team was

able to complete a successful prototype based on the BL1500.

Finally, there were several small issues that are to be expected when modifying code to

function using a different communication device. The ACU’s firmware modifications

proved difficult as the team had to face challenges with timing based on the Codan’s

connection times. Several rounds of testing had to be done to ensure enough time was given

waiting on the Codan’s response to a PAGECALL command, while being sure not to grant a

delay that would limit the unit’s overall feel as compared to the Pactor-II modem. Along

with timing, the limited size of the variable message contained within a PAGECALL

command became an unexpected problem. It was originally thought that this 64 character

limit would not pose a problem, and when it did a few last-minute changes had to be made to

ensure the proper functionality of the AFFS solution as a whole when faced with data packets

larger than 64 characters.

Overall, the team faced many challenges to its scope when working through the original

conceptual phases of its project. Once the scope of its project became firm, after the Non

Disclosure Agreement was finalized and the need was clearly stated, the team was able to

progress fairly successfully in developing its final prototype.

3.2 Operation

As hoped, the team was able to modify JAARS’ AFFS solution without major changes to its

functionality. As such, its operation has remained largely the same with the exception of

these few items. The team would refer the reader to the operating manuals available through

JAARS, and offers this section only as an outline of the few changes that would be apparent

to the end user. These manuals include:

• Automated Flight Following System, AFFS Ground Station Operating Manual

GND-AFFS-2003-02 Rev. IR September 27, 2004

• Automated Flight Following System, Aircraft Control Unit Model F5K Pilot’s Guide

POM-AFFS-2003-02 Rev. IR March 01, 2004


3.2.1 AFFSWIN

The largest noticeable change to AFFSWIN exists in the transformation of its “Modem

Commands” menu option to the new “Codan CICS Commands” menu option. Serving much

the same purpose, this new option allows the operator to send specific CICS commands to

the Codan radio through AFFSWIN, the results of which can be seen in the raw data window

toward the bottom of the screen.

Less noticeable, AFFSWIN now relies on the timestamp seen in the PAGECALL string,

which contains not only the time but also the date. This is now seen in place of the

timestamp.

3.2.2 AFFS Control Unit

Changes to the ACU were slightly more abundant than changes to AFFSWIN, although

minor nonetheless. First, the user will now notice inputs for tracking station IDs instead of

callsigns. The pilot’s callsign is still requested, but other callsigns are no longer needed, and

in their place are the specific Codan radio IDs of other radios. This is needed for the

PAGECALL command.

Second, the user will notice that the functionality of the cancel button has been completely

removed. As the message is built and sent to the Codan, it is no longer possible for it to be

canceled (a functionality change of the Codan as compared to the Pactor-II modem).

Because of this, the team decided to simply remove this button’s functionality in the ACU’s

firmware.

Third, the user will find that five of the stored text-messages have been shortened to a

version that is 26 characters or less. This became necessary as the team had to face the 64

character limit of the PAGECALL command.

Lastly, the user will find timing to be slightly different than expected with the Pactor-II

modem. The team was unable to compare, but found that its current implementation using

the PAGECALL command takes approximately 50-60 seconds to send a message and receive

the PAGE-CALL-ACK that confirms its arrival. Another 50 seconds must be allowed when

the dispatch station has a message queued for delivery to the pilot. To ensure a proper

emergency response time, the team disabled messages from the dispatch station to the pilot

while this emergency button is latched. This will ensure the pilot can send position reports

roughly once per minute.


4 Schedule

Task

Planned

Start

Actual

Start

Planned

Finish

Actual

Finish

Aca

de

mic

Da

tes

Fall Break 10/12/2007 10/12/2007 10/14/2007 10/14/2007

Thanksgiving Break 11/21/2007 11/21/2007 11/25/2007 11/25/2007

Fall Finals 12/17/2007 12/17/2007 12/20/2007 12/20/2007

Christmas Break 12/21/2007 12/21/2007 1/8/2008 1/8/2008

MLK Day 1/21/2008 1/21/2008 1/21/2008 1/21/2008

J-Term Break 2/1/2008 2/1/2008 2/3/2008 2/3/2008

Easter Break 3/14/2008 3/14/2008 3/24/2008 3/24/2008

Good Friday 4/11/2008 4/11/2008 4/11/2008 4/11/2008

Spring Finals 5/8/2008 5/8/2008 5/13/2008 5/13/2008

Du

e D

ate

s

Proposal 9/17/2007 9/17/2007 10/1/2007 10/1/2007

Logbooks 10/8/2007 10/8/2007 10/15/2007 10/15/2007

Spec 10/22/2007 10/22/2007 10/29/2007 10/29/2007

EDR Draft 10/29/2007 10/29/2007 11/12/2007 11/12/2007

Oral Presentation 11/19/2007 11/19/2007 12/3/2007 12/3/2007

EDR 11/12/2007 11/12/2007 12/10/2007 12/10/2007

Logbooks 12/3/2007 12/3/2007 12/10/2007 12/10/2007

Logbooks 3/7/2008 3/7/2008 3/14/2008 3/14/2008

FDR Draft 3/21/2008 3/21/2008 4/4/2008 4/4/2008

Final Presentation Draft 3/31/2008 3/31/2008 4/14/2008 4/14/2008

Final Presentation 4/11/2008 4/11/2008 4/25/2008 4/25/2008

FDR 4/4/2008 4/4/2008 4/25/2008 4/25/2008

Logbooks 4/18/2008 4/18/2008 4/25/2008 4/25/2008

Pro

po

sal

Pre-project planning with

advisor 8/29/2007 8/29/2007 9/10/2007 9/10/2007

Learning-curve research 8/29/2007 8/29/2007 9/17/2007 9/17/2007

Research past AAS projects 9/10/2007 9/10/2007 9/17/2007 9/17/2007

Initiate client contact 9/10/2007 9/10/2007 9/17/2007 9/17/2007

Develop fundamental project

scope 9/10/2007 9/10/2007 10/1/2007 10/1/2007

Write the proposal 9/17/2007 9/17/2007 10/1/2007 10/1/2007

Sy

ste

m S

pe

cifi

cati

on

Determine specific

functionality of the PIM 10/1/2007 10/1/2007 10/15/2007 10/15/2007

Determine specific

functionality of the dispatch

interface 10/1/2007 10/1/2007 10/15/2007 10/15/2007

Get client feedback 10/15/2007 10/15/2007 10/22/2007 10/22/2007

Revise functionality of the

PIM 10/15/2007 10/15/2007 10/29/2007 10/29/2007

Revise functionality of the

dispatch interface 10/15/2007 10/15/2007 10/29/2007 10/29/2007

Write the system spec 10/22/2007 10/22/2007 10/29/2007 10/29/2007


Pre

-Ph

ase

Ex

plo

rati

on

Obtain Codan NGT SR from

MAF (?) 10/1/2007 10/1/2007 10/8/2007 10/8/2007

Obtain Garmin 16 GPS from

Communications Group 10/1/2007 10/1/2007 10/8/2007 10/8/2007

Obtain AAS 2006

documentation and materials 10/1/2007 10/1/2007 10/8/2007 10/8/2007

Get NGT/CICS tutorial from

Marten 11/5/2007 11/5/2007 11/12/2007 11/12/2007

Determine bit-orientation of

all needed CICS commands 11/12/2007 SCRATCHED 11/26/2007 SCRATCHED

Spec each translator 11/12/2007 SCRATCHED 12/3/2007 SCRATCHED

Obtain 2nd Codan NGT SR

from CodanUSA through MAF 11/12/2007 11/12/2007 12/3/2007 12/3/2007

Obtain AFFS CU and AFFSwin

from JAARS 11/12/2007 11/12/2007 12/3/2007 12/3/2007


all I/O from AFFS CU 12/3/2007

SCRATCHED 12/17/2007

SCRATCHED

Determine bit-oriention of all

I/O from AFFS CU modem 12/3/2007


SCRATCHED


all I/O from AFFSwin 12/3/2007


SCRATCHED

Ensure all needed materials

are available in the Spring 12/3/2007 12/3/2007 12/17/2007 12/17/2007

ED

R

Write the draft EDR 10/29/2007 10/29/2007 11/12/2007 11/12/2007

Prepare for the oral

presentation 11/19/2007 11/19/2007 12/3/2007 12/3/2007

Write the EDR 11/12/2007 11/12/2007 12/10/2007 12/10/2007

Ite

rati

on

I

Modify AFFSWIN to

incorporate CICS 1/9/2008

1/9/2008 2/4/2008

2/18/2008

Fit current CU firmware to

BL1800 AS IS (no CICS

modification) 1/9/2008

SCRATCHED 2/4/2008

SCRATCHED

Breadboard CU component

modifications 1/9/2008

SCRATCHED 2/4/2008

SCRATCHED

It.

II

Arrange for pair of NGTs 2/4/2008 2/4/2008 3/3/2008 3/3/2008

Test AFFSWIN for ALL

functionality 2/4/2008

2/4/2008 3/3/2008

3/17/2008

Adapt CU firmware to

incorporate CICS 2/4/2008

2/4/2008 3/3/2008

4/18/2007

Test Breadboarded CU

component modifications 2/4/2008

SCRATCHED 3/3/2008

SCRATCHED

TEST I 3/3/2008 3/3/2008 3/10/2008 4/18/2008

It.

III Fix problems found in TEST I 3/10/2008 4/18/2008 4/7/2008 4/25/2008

Mill CU component

modifications 3/10/2008

SCRATCHED 4/7/2008

SCRATCHED


Finalize firmware 3/10/2008 4/25/2008 4/7/2008 5/2/2008

Finalize AFFSWIN 3/10/2008 3/17/2008 4/7/2008 5/2/2008

TEST II 4/7/2008 5/2/2008 4/14/2008 5/9/2008 It

. IV

Fix problems found in TEST II 4/14/2008

5/2/2008 4/21/2008

5/9/2008

FD

R

Write the draft EDR 3/21/2008 3/21/2008 4/4/2008 4/4/2008

Prepare for the final

presentation 4/4/2008

4/4/2008 4/14/2008

4/14/2008

Write the FDR 4/4/2008 4/4/2008 4/25/2008 5/9/2008

Table 2

Schedule

5 Budget

6 Conclusions

This year’s Alternate Aviation Solutions team is very pleased with the level and caliber of

their work. All five objectives have been met, as the functionality of the AFFS solution has

been maintained. As was mentioned before, the product of this year’s work was a conceptual

prototype proving the AFFS can be modified to operate with the Codan NGT via its CICS

architecture. More work is needed, as seen in Section 7, before proper field testing can

begin. This field testing must include multiple aircraft, as this capability has been assumed

but remains untested. It is assumed that MSI will coordinate field testing with JAARS and

Item Quantity Unit Price Total Price

Expenses

BL1800 Jackrabbit Development Kit 1 $ 139.00 $ 150.72

Mirror mount antennae bracket 1 $ 14.99 $ 15.89

Miniplug 3 conductor (2PK) 1 $ 3.99 $ 4.23

HI8 Video Tape (2PK) 1 $ 11.95 $ 12.67

CD Envelopes (50PK) 1 $ 4.99 $ 5.29

Shipping 4 varies $ 118.17

Printing 347 $ 0.08 $ 27.76

Subtotal Expenses $ 334.73

Funding Messiah College

Department of Engineering $ 500.00

Collaboratory Communications Group

$ 27.76

Subtotal Funding $ 527.76

Total Remaining $ 193.03

Table 3

Expenses and Funding


MAF, upon completion of the work at Messiah, to ensure the safety and proper operation of

the concept and product of the continuing team’s work.

The AAS 2008 team is grateful for the opportunity to provide some assistance to the

missions aviation community and is hopeful that the product of their work will become a

substantial improvement to the operations of MAF, the safety of their pilots, and the brevity

of their work.

7 Recommendations for Future Work

7.1 Upgrade of the Single-Board Computer

The most substantial task yet to be completed is the upgrade of the SBC within the AFFS

Control Unit. Currently, the design relies on the BL1500, produced by Rabbit

Semiconductors. As the design is now twelve years old, this particular SBC is no longer

produced and is the greatest limiting factor in the ACU’s continuing manufacturability.

While the AAS 2008 team did prototype a design that proves the AFFS’ interoperability with

the Codan NGT via the CICS architecture, they did so building on the BL1500 and thus, their

work cannot be reproduced on a large scale.

There are three main aspects to this task, each interwoven with the others. First, the BL1500

contains 26 user-programmable I/O lines. This is an unusually high number compared to its

successors, such as the BL1820, which contains only 14 user-programmable I/O lines. This

becomes a problem when trying to upgrade the SBC without significant changes to the rest of

the design, specifically to the display board.

This presents the second task. As each of the boards within the ACU are designed to seat

themselves right onto the others, any significant upgrade to the SBC is likely not to have the

same footprint as the BL1500, and will therefore likely not fit into the space allocated within

the ACU to seat directly to the display board. Therefore, any upgrade the SBC will likely

also involve a modification to the display board, at very least to accommodate this new

footprint.

Modifying the display board provides another significant opportunity. It has been suggested

that the LED display used in the ACU has not been fully accepted by most pilots. MSI has

asked that the AAS 2008 team to look into replacing this LED display with a more

appropriate display that will not place as much strain on the pilot. Looking into this, the

team discovered the display to use, itself, 16 I/O lines from the SBC. This is an archaic

design for a display, as modern LED displays tend to use far fewer than one I/O line per

character. So, in modifying the display board to seat the upgraded SBC, future teams have a

unique chance to replace this LED with a more efficient LED, which would in turn provide


greater flexibility in selecting a new SBC as it would not need to provide quite as many I/O

lines. This, the AAS 2008 team suggests, would be the best overall solution to upgrading the

SBC. Future teams ought to consider the upgraded SBC and this LED display

simultaneously, and alter the display board as needed to accommodate both.

7.2 Power Circuitry

While the team was successful in removing the functionality of the Pactor-II modem, the team did not

have the time to consider designing and implementing certain power circuitry needed to provide

power to the ACU which is currently provided through the Pactor-II modem. Because of this, while

the functionality has been removed, the modem itself has not. To realize any real price savings in this

year’s modifications, this power circuitry must be implemented and the Pactor-II modem physically

removed.

8 Appendices

8.1 ACU Firmware Revision Changes

28mar08 – Removed (commented out) Pactor initialization commands

01apr08 – Removed (commented out) packet building Dwrite() commands related to Pactor

protocols, and Pactor specific commands such as connect, disconnect and clear buffer.

03apr08 – Created a send buffer to store the AFFS data packet before sending. We thought

that there was no send and receive buffer on the single board computer. So we were going to

use a string to house all information before sending it out all at once for the send side. For

the receive side we were going to constantly poll for incoming data and dump the

information into a read buffer.

04apr08 – Modified the Defaults.C file to skip over EEPROM memory that was used for the

power level of the Pactor modems.

10apr08 – Adjusted reading from the EEPROM memory to skip over power level

information pertaining to the Pactor modems. Other EEPROM information regarding stored

memory was left in the same location. Modified AFFS packet building in format used by the

Codan NGT’s.

12apr08 – Added a myid[] variable to replace mycall[], there was no change in function

between the two variables we just replaced one with the other. This was done because we

though we needed to make changes to the myid[] but in the end it wasn’t required. Realized

that there is a transmit and receive buffer on the single board computer!!! Removed previous

changes building the send buffer string. We could revert to the old method of just dumping


information out piece by piece onto the transmit buffers. Rebuilt the packet for an high

frequency call using Codan commands.

13apr08 – Made most of the mycall[] to myid[] changes on this date. Removed modem read

information from Emergency reporting section. Added the looking for PAGE-CALL-ACK:

checking feature.

14apr08 – Added test statements to at time_out during “waiting” sections. Most of this code

was removed at a later stage. There were significant differences in time waiting times after

some of our code modifications. The main change was from 100000 to about 5000. The

longest wait times should only be about 1 min for a response from the dispatch radio.

15apr08 – Continued with test statements trying to figure out the reason for the timing issues.

All of the modifications made on this date were removed at a later stage.

16apr08 – After testing the PAGE-CALL-ACK: finding feature and the incoming text

message parsing, we came across some issues from the Dread commands. We gathered from

the documentation that the function was reading everything up to the specified character,

removing it from the read buffer and the inserting it into a predetermined array and thus

leaving everything else intact. This was not happening after running several tests. The

function was reading everything up to the specified character and putting it into our array, but

it was leaving that character in the read buffer and wiping out everything that came after it.

Not entirely sure the exact details this function was doing. Removed many of the test

statements made in the previous modifications. Removed the cancel feature. (For some

reason adding a 300ms delay, for debouncing, before unlatching of the emergency switch

would cause the system to crash)

17apr08 – Removed another cancel feature in different section of code. Moved the altitude

building of AFFS packet to a different section of code because it would send altitude

information even though there was no GPS data. Turn off a blink due to message changes.

20apr08 – Added a timer2 variable. Fixed some bugs in looking for PAGE-CALL-ACK:.

Added test statements for looking for PAGE-CALL-ACK: still was having some trouble,

would only read it correctly occasionally.

23apr08 - added receive message parsing and display. Redesigned the “checking for

message” section, worked correctly this time.

24apr08 – fixed crashing bug with receive message by increasing Modem_rbuf and

Modem_readbuf, increased to 500 character length.

25apr08 – fixed crash by removing a “break” which was terminating the main while loop. -

Added error checking and correction for messages longer than 16 characters.


27apr08 – added 5 sec delay after receiving a PAGE-CALL-ACK: , to allow codan’s some

time before sending next emergency message. Added check for responses during page-call-

ack: verifying the message was at least 13 characters long. Previously short messages with a

“:” would reset the system. Increased wait time for message response from dispatch to 5000

28apr08 – During test we ran into the issue of exceeding the maximum length of characters

allowed by the PAGECALL function. There were 64 characters allowed between the ‘ ‘

marks. Found this issue late due to the receiving a GPS unit later. Without GPS coordinates

the packet would not contain markers and data that corresponded with GPS data. Also

during the first “send” of a data packet program would send flight status information as well,

such as passengers on board, waypoints and fuel on board. On a next send if flight status

information did not change it would not send the information. The problem arose when we

had GPS data and sent a text message during the first send operation. All the information

was exceeding the 64 character limit. To solve this issue we elected not to send flight status

when sending messages and only send our id and GPS coordinates. We also had to add a

check so during a normal send (without text message) it would send the flight status if it had

not been changed.

29apr08 – Some of the custom text messages were extremely long, over 30 characters just for

the message. We had to modify 5 of the custom text message so it would be no more than 26

characters which would be our new limit.

8.2 AFFSWIN Revision Changes

07FEB08 - Change from MnuOption "Modem Commands" to mnuOption "CICS Commands" AFF.frm

Changed Menu/Options/"Modem Commands..." to Menu/Options/"Codan CICS Commands..."

AFFMODEM.frm Changed Properties/frmModemCmd/Caption/"Modem Commands" to Properties/frmModemCmd/Caption/"Codan CICS Commands"

Changed Properties/lblModemCmd/Caption/"Modem Command" to Properties/lblModemCmd/Caption/"CICS Command"

Changed Properties/cmdSend/Caption/"Send Command to Modem" to Properties/cmdSend/Caption/"Send Command to Codan"

AFFMODEM.frm/Object:cmdSend/Proc:Click

No longer looks for an input beginning with the ESC code, as this was specific to the PACTOR-II Modem

26FEB08 - Modification of ParseInput subroutine to accept and output CICS PAGECALL


AFF.BAS AFF.BAS/Object:(general)/Proc:(declarations)

13 new Global Constants to represent new states in the ParseInput subroutine

1 new Global string to store the source ID of the pilot's radio in the ParseInput subroutine

AFF.FRM AFF.FRM/Object:(general)/Proc:(ParseInput) 13 new cases (states) Grabs source ID as String Modified the existing state machine (hijacked the initial state) Modified the outgoing message to CICS PAGECALL Uses Global string, sourceID

04MAR08 - Cleanup of ParseInput, including status labels, timestamps, etc. AFF.FRM AFF.FRM/Object:(general)/Proc:ParseInput 2 new cases (states) to extract the timestamp from the CICS PAGE-CALL

Old calls to change the Mh3dmlblStatus.SegCaption LINKSTATUS caption

New calls to change the Mh3dmlblStatus.SegCaption LINKSTATUS caption

AFF.BAS AFF.BAS/Object:(general)/Proc:(declarations) New Global constants to represent new states in the ParseInput subroutine 15APR08 - Tightening ParseInput, Fixing to allow extra spaces between pagecall parameters AFF.FRM AFF.FRM/Object:(general)/Proc:ParseInput PAGE-CALL-ACK cases no longer needed

Edited syntax of other cases to match (PAG_ECALLACK -> PAG_ECALL)

Edited case "PAGECALL_" (formerly PAGECALL_ACK to remove elseif branch to PAGECALL_ACK)


Added FIND_SPACE_ID to edit out all spaces before the sender ID in PAGECALL

Added FIND_SPACE_TIME to edit out all spaces before the timestamp in PAGECALL

AFF.BAS AFF.BAS/Object:(General)/Proc:(declarations) New Global constants to represent new states in the ParseInput subroutine Old states for PAGE-CALL-ACKs. No longer needed.

Edited syntax of other constants to match (PAG_ECALLACK -> PAG_ECALL)

20APR08 - Further tightening ParseInput. (1) added a reset mechanism in ParseInput (2) removed MSGRECVD and added a delay. Final Cleanup 28APR08 - Fixed Timestamp bug

alternate aviation solutions 2008 - messiah college · a satellite-based company that offers many...

Documents