Gen 1 Architecture

Gen 1 Architecture
Part of the HABEES series
Chief Designer	Kirill Safin
Technology Line	Balloons Core Architecture
Version	Generation I
General
HONEY Standards • Venom Breakout • Fang Breakout • Board Naming
Core Architecture
Gen 1 Architecture • HONEY
Core Avionics
Oscar • Cookie Monster • Elmo • The Count
Core Power
Apple Turnover• Biscuit
Core Peripherals
Medusa • Cobra • Viper • QueenBee • ProtoBee
Core Radio
Macaw
Test & Prototype
QueenBee
Guides
Making a HONEY Board • Using STINGR • Using QueenBee • Making a Prototype
V • E

The Balloons Gen 1 Architecture was the first attempt within the Balloons Team at standardizing the form factor & electrical standards for standard-profile balloon avionics, power, and control systems. The architecture was introduced in Spring of 2016, and lasted until Spring of 2017, when it was replaced by HONEY, the Gen 2 Architecture.

The first-ever architecture had two primary components -- the physical form factor, as well as the electrical standards. These will both be addressed individually.

Physical Form Factor

The physical form factor of the Gen 1 Architecture was decided upon primarily based on the physical dimensions of the payload container, which, at the time of invention, was habhive. habhive, at the time, was a hexagonal payload container which had a standardized internal hexagonal surface area to fit HABEES boards. To maximize board area and conform to the habhive dimensioning, a 3/4 hexagonal shape was chosen. This allowed maximum utilization of the internal area, while the 1/4 hexagon that was cut off allowed wires & connections to be funneled throughout the height of the payload container.

Benefits

The decided form-factor fit very well into the habhive container, and effectively allowed inter-roping of internal boards and connections using the alloted 1/4 hexagonal spacing. The boards fit very snugly, and had sufficient space for the vast majority of electronics.

Drawbacks

One of the primary drawbacks of the form factor was it's strict adherence to the habhive spec, which, as a hexagon, was very specific and a very niche shape that would not be found outside of the habhive box. The hexagonal boards, outside of habhive, seemed strange and unintuitive in their shape.

Further, while the spacing maximized surface area and provided a space to run wires, it was tight enough that reaching in and altering connections/moving devices was difficult with a fully assembled payload.

Electrical Specification

The electrical specifications of the Gen 1 Architecture changed rapidly -- owing to the fact that it was the first ever balloons standardized architecture, and the needs, limitations, and wants of an architecture arose quickly as the architecture was implemented. The architecture evolved with each board that was added to it, and hence the specifications will be cataloged and described in that fashion.

Oscar Spec

Oscar, the first Gen 1 Architecture compliant board, introduced a very simple and bare-bones electrical standard.

Oscar only provided a 2-pin microfit connector for connection to a battery pack -- that is, Oscar conducted all power-regulation onboard, producing necessary voltages and handling pack protection circuitry. Oscar did, however, provide header pinouts for various signal and power lines -- including GND, 3.3V, 5V, raw pack, I2C, and SPI. This first electrical specification speculated that additional connections to the avionics would utilize jumper wires and these simple pinouts.

Cookie Monster Spec

As the limitations and general simpleness of the Oscar Spec became apparent, many new additions and alterations were made to provide for a more scalable and robust architecture -- introduced in Cookie Monster.

One of the key introductions with the Cookie Monster spec was the separation of power regulation and avionics. All power regulation was broken out onto a separate PCB -- the newly introduced BMS, Apple Turnover -- and the avionics, Cookie Monster, added a BMS connector including power & data pins.

In addition to splitting controls & power into separate domains, Cookie Monster added an important system that would persist in balloons architecture to this day -- the CAN interface. Cookie Monster added two connectors for CAN -- one input and one output. This multi-master interface would allow for scaling the architecture to any number of boards, allowing multiple boards to be connected and interface easily.

Cookie Monster did, however, retain the male header pinouts of Oscar, while downsizing them significantly (to 5 pins per protocol/voltage). This was still seen as a useful functionality to easily access the various signal nets and power nets.

In introducing CAN, the Cookie Monster spec also introduced the first possibility for expansion -- Medusa. Medusa was a Gen 1 compliant board that communicated with Cookie Monster over CAN, and allowed the creation of small board-edge PCB's to expand the core system functionality. This was the first attempt of the Gen 1 Architecture to allow enhancing and expanding the system functionality past the core avionics platform.

Elmo Spec

The Elmo Spec maintained the introductions of the Cookie Monster spec, while splitting the size of the BMS connector into discrete data & power connectors.

Issues

There were many issues with the electrical spec of the Gen 1 Architecture, which arose over time. They are, primarily:

• The wired CAN interface took up a lot of space and expensive shielded twisted-pair wires
• The Medusa Expansion board didn't allow for making very large boards to expand functionality
• The first BMS, Apple Turnover, didn't function
• There was too much wiring all-together necessitated between boards

Transition to HONEY

The above issues, and a number of new considerations, resulted in the introduction of the HONEY standard (Gen 2 Architecture).

The HONEY standard introduced the following changes & additions to the Gen 1 Architecture:

• Stack-through format instead of by-wire format of interconnect.
• 10x10cm "cubesat format" form-factor, over random hexagonal boards.
• Stack-through CAN bus (two).
• Stack-through Power bus.
• Stack-through data bus.
• Breakout boards to provide non-stack connections over a large distance.
• Backwards compatibility between board iterations.
• Core Software for communication between boards.