Defense

MIL-STD-1553B Embedded Development Kit

Who: Georgia Tech Research Institute (GTRI), Georgia Institute of Technology (GT)
When: 2012
Where: Atlanta, GA
Languages: C (pre-C99), i8085 assembly, VHDL

GTRI has multiple contracts to redesign existing systems and update them with modern electronics. The i8085 was nearing end-of-life, so GTRI requested that we implement the i8085 in VHDL and produce a development kit for prototyping new hardware. The final product resulted in a Micro-C program (running on i8085 in VHDL) talking over a MIL-STD-1553B bus to blink a light on a receiving board.

The MIL-STD-1553B Embedded Development Kit consisted of a Xilinx Spartan FPGA and two MIL-STD-1553B capable daughter cards of our own design. The FPGA board interfaced with MIL-STD-1553B transceivers to prove that we could communicate over the bus with our software.

Our primary challenge was getting software running on our i8085 FPGA device. We revived an old ISO-C compiler (Micro-C) and managed to get software compiling in a virtual machine. Next, the vendor's 1553 driver needed to be back-ported for i8085 compilation. This was challening, as many modern conveniences and best practices are not valid in prior to C99. The compiler also had its own separate limitations, such as lack of support for float/double/long/enum/typedef.

After getting example code running on our i8085 design, we created a VHDL system architecture that allowed us to interface with our daughter board and run the i8085 demo program.

Writing Samples

Source Code

8085-HI6130-Port: Port of HI-6130 Driver and Demo Project to a MICRO-C Compiler for the 8085
SREC-to-COE: Converter to convert Motorola SREC hex files to Xilinx COE memory initialization files.
1553-Firmware: Contains VHDL implementing an 8085, Holt HI-6130 1553 IC, and Memory. Also includes firmware used to demo the system.

High Level Schedule / Waterfall

1474993589111.png

I-BESS

Who: Georgia Tech Research Institute (GTRI)
When: 2010-2011
Where: Atlanta, GA; Charleston, SC; Aberdeen, MD
Languages: C, ASM

The I-BESS project was sponsored by the U.S. Army Rapid Equipping Force (REF). I-BESS was developed to collect data on the effect of IED blasts on a soldier. Many soldiers were coming back from Iraq and Afghanistan with traumatic brain injuries (TBI) and the Army needed data to understand how soldiers were being injured.

The I-BESS system consisted of four parts: a soldier body unit (SBU), a vehicle unit mounted to the back of each seat (VIA), a headset, and a black box recorder which stored the data inside each vehicle. The SBU and headset were designed to collect directionality, pressure, force, and head rotation that a soldier experienced during an IED event.

Phillip was the lead developer for the VIA system. The VIA system utilized bluetooth, wifi, RFID, and CAN to communicate with the other products in the ecosystem. It also included a high-g accelerometer to measure force during an IED event. When a soldier sat in a seat, the VIA would exchange wifi connection information over RFID, download the stored event data, and send the data to the black box computer. Both the VIA and black box recorder collected their own IMU data during IED events involving the vehicle.

In the early stages Phillip was responsible for bringup of the new design, working closely with the HW and RF teams to debug issues. One of the key parts - the RFID controller - had very poor documentation from TI, and the RF group was undergoing restructuring. Phillip reverse engineered the communication protocol using example binaries provided from TI and produced an Interface Control Document (ICD) for the part.

The project involved frequent travel to the SPAWAR facility in Charleston, SC to perform various tests: fit check, radio jamming, installation, in-vehicle performance. During later stages of the project, the travel shifted to the U.S. Army proving grounds in Aberdeen, MD, where live demolition tests were performed.

System Architecture

ref_arch.png

VIA System

via.jpg.png

Future Airborne Capability Environment (FACE)

Who: Georgia Tech Research Institute (GTRI)
When: 2010
Where: Atlanta, GA
Skills Developed: Research, Documentation, API Design

The Future Airborne Capability Environment (FACE) project was started by the U.S. Navy. The stated goal was to produce a common software architecture that contractors would adhere to. Software projects would be decoupled from the hardware interfaces, allowing the U.S. government to accept competitive bids from multiple software developers. The status quo is/was to be locked into a single vendor due to complaints about opening up their own intellectual property.

When the FACE was being formed, GTRI was tasked with working in parallel to the committee to come up with an alternative common architecture proposal. While working on this team, Phillip's role was to perform research on API design, military architecture challenges, military hardware, and software architecture. These findings fed into a section of the original GTRI FACE proposal.

GTRI later worked with the FACE consortium to develop the final standard and proof-of-concept software implementations.

Further Reading:
Wikipedia summary
OpenGroup: Future Airborne Capability Environment
Five Reasons FACE is Succeeding as a Global Military Standard

MIL-STD-1553B Bus Analyzer

Who: Georgia Tech Research Institute (GTRI)
When: 2009-2010
Where: Atlanta, GA
Languages: C, Visual C++

Phillip's major software development experience was working on a MIL-STD-1553B bus analyzer. The software supported monitoring, recording, playback, and decoding messages sent to EW/avionics systems. This software had been written and maintained by GTRI for 10-20 years, leading to a large and unruly code base.

Phillip supported a major release cycle and was responsible for a variety of activities:

  • Integrating support for decoding traffic on new systems
  • Incorporating new interface updates for supported systems
  • Fixing bugs identified in previous releases
  • Reviewing formal software test plan, fixing errors, and incorporating requirements for new feature sets
  • Running formal software tests prior to releasing the software to the customer