Difference between revisions of "Gen 1 Architecture"
| Line 10: | Line 10: | ||
The first-ever architecture had two primary components -- the physical form factor, as well as the electrical standards. These will both be addressed individually. | 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 two connector inputs for BMS Power Input & BMS Data Input. These two connectors provided power and data analytics about the BMS, respectively. | ||
| + | |||
| + | 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 decreasing the size of the BMS Data connector. | ||
| + | |||
| + | === 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. | ||
| + | |||
[[Category: High Altitude Balloons]][[Category: HABEES]] | [[Category: High Altitude Balloons]][[Category: HABEES]] | ||
Revision as of 23:11, 23 August 2017
| 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 two connector inputs for BMS Power Input & BMS Data Input. These two connectors provided power and data analytics about the BMS, respectively.
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 decreasing the size of the BMS Data connector.
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.