Stanford SSI Wiki - User contributions [en]

Template:Balloon-sidebar

2018-08-12T00:48:30Z

Vnguyen5:

{| class="wikitable" style="float:right; margin-left: 10px; font-size:85%;max-width:250px; text-align:center"
{{red-header|size=150}}High Altitude Balloons
|-
| Part of the [[High Altitude Balloons Team | High Altitude Balloons]] series
|-
{{red-header}} Team Goals
|-
| [[Altitude Control]] • [[Balloon Research | Research]]
|-
{{red-header}} Balloon Culture & Tradition
|-
| [[Balloons Culture | What Is it?]] • [[Balloons Breakfast | Breakfast]] • [[Balloons Lunch | Lunch]] • [[Balloon Release | Release]] • [[Balloon Bonfires | Bonfires]] • [[Overnight Launches]]
|-
{{red-header}} Important Concepts
|-
| [[Balloon Mechanics]] • [[Atmospheric Conditions]] • [[Altitude Control]] • [[GPS Flight Mode]] • [[Heating & Thermal]] • [[Communications]]
|-
{{red-header}} Core Architecture
|-
| [[Gen 1 Architecture | Gen 1 Architecture]] • [[Gen 2 Architecture Rev1 | HONEY]]
|-
{{red-header}} Core Software
|-
| [[Gen 1 Software | STINGR ]]
|-
{{red-header}} Core Avionics
|-
| [[Balloon Gen 1 Avionics | Oscar]] • [[Balloon Gen 2 Avionics | Cookie Monster]] • [[Medusa | Medusa]] • [[Balloons Gen 3 Avionics | Elmo]] • [[Balloons Gen 4 Avionics | The Count]] • [[Balloons Gen 5 Avionics | Kermit]]
|-
{{red-header}} Core Power
|-
| [[Balloon Gen 1 BMS | Apple Turnover]]• [[Balloon Gen 2 BMS | Biscuit]] • [[Balloon Gen 3 BMS | Cupcake]]
|-
|-
{{red-header}} Core Peripherals
|-
| [[Balloons Gen 1 Radio | Macaw]] • [[Balloons Gen 1 Expander | Cobra]] • [[Balloons Gen 1 Breakout | Viper]] • [[Balloons Gen 1 TestBench | QueenBee]] • [[Balloons Gen 1 ProtoBoard | ProtoBee]]

|-
{{red-header}} ValBal Avionics
|-
| [[VB Gen 1 Avionics | Gen 1]] • [[VB Gen 2 Avionics | Gen 2]] • [[VB Gen 3 Avionics | Gen 3]] • [[VB Gen 4 Avionics | Gen 4]]
|-
{{red-header}} ValBal
|-
| [[ValBal Mk 1 | Mk 1 (adVENTurer)]] • [[ValBal Mk 2 | Mk 2 (VENTuri)]] • [[ValBal Mk 3 | Mk 3 (Voyager)]] • [[ValBal Mk 4 | Mk 4 (Ivy)]]
|-
{{red-header}} Projects
|-
| [[Project Sol | Sol]] • [[Project UV | UV]] • [[Project X | X]] • [[Project SPACE | SPACE]] • [[Project habmc | habmc]] • [[:Category:HABEES | HABEES]]
|-
{{red-header}} Lore & Chronicles
|-
| [[The Puerto Rico Incident]] • [[The Surprise Equilibration]] • [[The Mountain Climbers]] • [[The Little ZPB That Could]] • [[The Balcony Bonanza]]
|-
{{red-header}} Launch Sites
|-
| [[Laird Park]] • [[Brigantino Park]]
|-
{{red-header|textalign=right}} [[Template:Balloon-sidebar | V]] • [http://wiki.stanfordssi.org/index.php?title=Template:Balloon-sidebar&action=edit E] 
|}

Template:Balloon-sidebar

2018-08-12T00:46:04Z

Vnguyen5:

{| class="wikitable" style="float:right; margin-left: 10px; font-size:85%;max-width:250px; text-align:center"
{{red-header|size=150}}High Altitude Balloons
|-
| Part of the [[High Altitude Balloons Team | High Altitude Balloons]] series
|-
{{red-header}} Team Goals
|-
| [[Altitude Control]] • [[Balloon Research | Research]]
|-
{{red-header}} Balloon Culture & Tradition
|-
| [[Balloons Culture | What Is it?]] • [[Balloons Breakfast | Breakfast]] • [[Balloons Lunch | Lunch]] • [[Balloon Release | Release]] • [[Balloon Bonfires | Bonfires]] • [[Overnight Launches]]
|-
{{red-header}} Important Concepts
|-
| [[Balloon Mechanics]] • [[Atmospheric Conditions]] • [[Altitude Control]] • [[GPS Flight Mode]] • [[Heating & Thermal]] • [[Communications]]
|-
{{red-header}} Core Architecture
|-
| [[Gen 1 Architecture | Gen 1 Architecture]] • [[Gen 2 Architecture | HONEY]]
|-
{{red-header}} Core Software
|-
| [[Gen 1 Software | STINGR ]]
|-
{{red-header}} Core Avionics
|-
| [[Balloon Gen 1 Avionics | Oscar]] • [[Balloon Gen 2 Avionics | Cookie Monster]] • [[Medusa | Medusa]] • [[Balloons Gen 3 Avionics | Elmo]] • [[Balloons Gen 4 Avionics | The Count]] • [[Balloons Gen 5 Avionics | Kermit]]
|-
{{red-header}} Core Power
|-
| [[Balloon Gen 1 BMS | Apple Turnover]]• [[Balloon Gen 2 BMS | Biscuit]] • [[Balloon Gen 3 BMS | Cupcake]]
|-
|-
{{red-header}} Core Peripherals
|-
| [[Balloons Gen 1 Radio | Macaw]] • [[Balloons Gen 1 Expander | Cobra]] • [[Balloons Gen 1 Breakout | Viper]] • [[Balloons Gen 1 TestBench | QueenBee]] • [[Balloons Gen 1 ProtoBoard | ProtoBee]]

|-
{{red-header}} ValBal Avionics
|-
| [[VB Gen 1 Avionics | Gen 1]] • [[VB Gen 2 Avionics | Gen 2]] • [[VB Gen 3 Avionics | Gen 3]] • [[VB Gen 4 Avionics | Gen 4]]
|-
{{red-header}} ValBal
|-
| [[ValBal Mk 1 | Mk 1 (adVENTurer)]] • [[ValBal Mk 2 | Mk 2 (VENTuri)]] • [[ValBal Mk 3 | Mk 3 (Voyager)]] • [[ValBal Mk 4 | Mk 4 (Ivy)]]
|-
{{red-header}} Projects
|-
| [[Project Sol | Sol]] • [[Project UV | UV]] • [[Project X | X]] • [[Project SPACE | SPACE]] • [[Project habmc | habmc]] • [[:Category:HABEES | HABEES]]
|-
{{red-header}} Lore & Chronicles
|-
| [[The Puerto Rico Incident]] • [[The Surprise Equilibration]] • [[The Mountain Climbers]] • [[The Little ZPB That Could]] • [[The Balcony Bonanza]]
|-
{{red-header}} Launch Sites
|-
| [[Laird Park]] • [[Brigantino Park]]
|-
{{red-header|textalign=right}} [[Template:Balloon-sidebar | V]] • [http://wiki.stanfordssi.org/index.php?title=Template:Balloon-sidebar&action=edit E] 
|}

HONEY

2018-08-12T00:45:18Z

Vnguyen5: Redirected page to Gen 2 Architecture Rev1

#REDIRECT [[Gen 2 Architecture Rev1]]

Gen 2 Architecture Rev1

2018-08-12T00:32:49Z

Vnguyen5:

{{HONEY-sidebar
| header = HONEY Architecture
| img link = File:HONEY2_rev1.jpg
| designer = Vinh Nguyen
| techline = Balloons Core Architecture
| version = Generation II
| name = HONEY
| acronym = Hardware Optimized Nested Electronics sYstem
}}

'''HONEY (Hardware Optimized Nested Electronics sYstem)''' is the second generation Core Flight Architecture, designed by HABEES. The HONEY architecture makes significant changes and improvements on the Generation I Architecture, including changes in physical dimensioning, stacking connectors, common power and data buses, and more.

Changes to the HONEY Architecture were made with Avionics Gen 5 and BMS Gen 3, which split the data bus into two in order to reduce routing complexity. Some features of HONEY were removed and are documented below under 'Data Bus'

== Physical Specifications ==
The HONEY architecture physical specifications comprise two categories: board specifications and stack specifications.

=== Board Specification ===
All boards implementing the HONEY spec must meet strict physical requirements. There is a standardized set of measurements, mounting holes, connector placements, and board dimensions that must be met for proper integration with the flight stack.

[[File:pcbtemplate_rev1.JPG | right| thumb | <center> PCB Template </center>]]

The dimensions of a HONEY-compliant board are exactly 10x10 cm. Boards are 0.062" in thickness (this is important for the physical fastening of the flight stack to the payload container, which is sensitive to the thicknesses of boards in the flight stack. Boards also have four through-holes at each corner, designated for standoffs. The holes are designed for M3 standoffs, which are indented 250 mil from both edges of the respective corner. The board also necessarily consists of a PC/104+ connector for the flight stack data bus, a 14-pin (7x2) connector for the flight stack power bus, a 4-pin (2x2) connector for the flight stack CAN bus, and an 2 pin (2x2) connector (NON stack through) for holding jumpers for implementing CAN terminating impedances. These connectors must be implemented exactly via the use of the HABEES_NEW_STACK compoenent.

The connectors and hardware used in each case can be found on the [[HONEY_Standardized_Connectors|HONEY Standardized Connectors Page]]
* Data Bus: 2x Harwin M20-6112045
* Power Bus: Samtec ESQ-107-38-G-D-LL
* CAN Bus: Samtec ESQ-102-38-G-D-LL
* CAN Jump Holder: Samtec TSW-102-07-G-D
* CAN Terminating Jumper: Samtec SNT-100-BK-T
* Stack Standoffs: Harwin R6104-02

The physical footprint of a HONEY base-board can be found in the Altium library as "HABEES_NEW_STACK" -- this features both a compliant and properly dimensioned 2PCB, as well as a schematic symbol for accessing the power, data, and CAN buses.

=== Stack Specification ===
The HONEY architecture is defined by a flight stack, comprised of stacked HONEY-compliant boards, with common data, power, and CAN buses, physically integrated through a series of four corner standoffs. Flight boards in the flight stack are inter-connected by the standoffs mentioned above (Harwin R6104-02 standoffs). Boards are expected to be 0.062" thickness.

The flight-stack is compromised of two primary divisions: ''Flight Critical Components (FCC)'' and ''Flight Tertiary Components (FTC)''. At time of writing, there are only two FCC's -- the Core Avionics and the Core BMS. All other boards, non-essential to flight operation, are considered FTC. Components are categorized and assessed as FCC or FTC upon design and implementation on a rolling basis. A flight-ready flight-stack must consist of at least one of each of the Flight Critical Components, and can include zero or any number of Tertiary Flight Components.

The Avionics & BMS are specified by the HONEY spec as being the strictly top-most and strictly bottom-most boards in the flight stack, with all FTC in-between. This is the case for two reasons: Core Avionics required a clear view of the sky for proper Iridium & GPS reception, and therefore must be on the top of the stack. The BMS holds four 18650 Li-Ion cells on its bottom, and the standard inter-board spacing is insufficient to fit the battery pack. it is therefore allocated to the bottom of the stack, which is fastened to the payload container by longer standoffs to accommodate the battery pack size.

The flight stack is therefore comprised of a minimum of two boards, and can theoretically be any defined height. Currently, a flight stack of five boards is categorized as a "1U flight-stack" for payload-integration purposes. An additional sixth board results in a 2U flight stack, an eleventh board results in a 3U flight stack, and so on.

As defined by the current spec, the physical stack dimensioning is as so:

* XY-Board Dimensions: 10x10 cm
* Z-Board Thickness: 0.062"
* Permissible Extension outside of Board Dimensions: 0.25"
* Maximum spacing outside of Board Dimensions: 0.5"
* Inter-Board spacing: 15.24mm, as defined by the Harwin R6104-02 standoff.
* BMS-Payload Base spacing: 25mm, as defined by McMaster 94868A013, 10/12mm standoffs (McMaster 92005A120, 92005A122)
* Avionics-Roof spacing: Variable, depending on stack height.

Avionics-Roof spacing, by stack height:
* 2-Boards (Base Stack): 51mm spacing, 60mm fixture bolt. (McMaster 94669A127, 92005A140)
* 3-Boards (Base + 1 FTC): 35mm spacing, 45mm fixture bolt. (McMaster 94669A121, 92005A136)
* 4-Boards (Base + 2 FTC): 16mm spacing, 30/25mm fixture bolt. (McMaster 94669A111, 92005A132, 92005A130)
* 5-Boards (Base + 3 FTC): 25mm spacing, same as BMS. (McMaster 94868A013, 92005A120, 92005A122)

== Electrical Specifications ==
The HONEY architecture defines pinouts for the various bus connectors, as well as pins required for implementation and auxiliary pins one can use on a given stack-board.

There are three defined buses, with specific purposes, limitations, and requirements as defined by the HONEY electrical specification.

=== Power Bus ===
The power bus pin-out is as follows:
{| class="wikitable"
|-
|VBAT
|1.8EXP
|3.3EXP
|5EXP
|5AVI
|3.3AVI
|GND
|-
|VBAT
|1.8EXP
|3.3EXP
|5EXP
|5AVI
|3.3AVI
|GND
|}

The purpose of the power bus to supply power to the entirety of the flight-stack. It does this using high-current rated pins, ultimately deriving their power from the BMS. At the time of writing, the active BMS is Cupcake, and the following will be written with the Cupcake specifications.

[[File:pbus_rev1.JPG | right| thumb | <center> Power Bus Pin-Out </center>]]

The power bus provides two separate power buses for the Avionics and Expansion boards. Each provides 5V, 3.3V and has a separate maximum current limit of 5A, beyond which the protection on the BMS will shut the violating power line(s). The power bus for expansion boards additionally provides 1.8V. It is required that expansion boards use only the expansion board power bus to ensure nominal function of main avionics.

The power bus also provides raw cell voltage +VBAT -- this voltage is nominally 3.7V, 4.25V at full capacity, and changes from ~ 4.25V down to ~ 3.2V at pack end-of-life. It's purpose is strictly for high current applications where high power with few voltage requirements is the defining characteristic. The pack can source ~ 12 amps from the VBAT line at peak (should not be tapped at this current for too long). Examples of its current application are for nickel chromium cutdown (1A), and in-board heaters for the BMS and Avionics (~ 500 mA), as well as powering the Dorji Radio Transceivers on Macaw (1W @ 4.2V).

Lastly, the power bus provides two nodes for common ground, which must be implemented to common-ground a board to the BMS/flight-stack.

=== Data Bus ===

[[File:dbus_top_rev1.JPG | right| thumb | <center> Data Bus Top </center>]]
[[File:dbus_bottom_rev1.JPG | right| thumb | <center> Data Bus Bottom </center>]]

The data bus serves as a means by which to transfer specific reserved signals throughout the flight stack, access reserved Core Avionics UART lines, as well as Core Avionics SPI/I2C, as well as implement system flags, and some other utility features. While primary communication between boards happens via the CAN bus, certain pins on the data bus are required to be implemented by all boards in the flight stack, and other pins may yield utility, depending on the specific application of a board. All "RESERVED" pins currently serve no purpose, and may be reserved by your board for transitioning signals up and down the flight stack.

A description of all the pins and whether they are required to be implemented is found in the following table, and the entire pinout can be found following this table.

{| class="wikitable"
|-
|Pin
|Net
|Purpose
|REQ?
|-
|1-4
|GND
|GND
|YES
|-
|5
|VBCKP
|The VBCKP pin is connected to a +3V coin cell located on the BMS. This pin serves as a backup, low-current 3V supply primarily for memory applications, such as RTC's & GPS memory. It continues to power crystals and internal memory to keep the state of RTC's, etc, even through power-cycles.
|NO
|-
|6
|R_MCU
|The R_MCU pin, if pulled high, resets the Core Avionics board remotely. This pin should be implemented under almost '''NO CIRUMSTANCES'''. The Avionics largely in charge of the flight stack, and very few boards should ever have the authority to reset it. It exists for possible, if seldom, application.
|NO
|-
|7
|R_ALL
|The R_ALL pin, if pulled high, will reset all boards in the flight stack. This pin is controlled exclusively by the Core Avionics, and should be tied to the reset pin of any MCU found on a board. The Avionics has the authority to reset all flight stack boards in the case of excessive power consumption, poor responsiveness, or erratic behavior.
|YES
|-
|8
|S_READY
|The S_READY pin, once pulled high, alerts all flight stack boards that the Core Avionics has passed initial booting, and is ready to accept requests and provide flight services. All boards should wait until S_READY is high to begin their initialization and operating procedures.
|YES
|-
|9
|LOW_PWR
|The LOW_PWR pin, once pulled high, alerts all flight stack boards that they should enter low power mode, whereby they should conduct all possible actions to minimize power consumption. This flag is pulled high in the case that the payload is losing power, and must retain all power for flight critical operations.
|YES
|-
|10
|FMODE
|The FMODE pin, once pulled high, alerts all flight stack boards that the payload has been released, and is ascending, and in flight mode. This is a utility flag that can be implemented if your board desires to know whether flight has begun, or whether the payload has not yet been released, or has landed.
|YES
|-
|11-14
|SYS_F(3-6)
|Reserved System Flags for future purposes.
|YES
|-
|15, 16
|SDA/SCL
|These pins provide access to the Core Avionics I2C bus. This should be used in very extenuating circumstances, when Core Avionics control over an I2C device on a board is desired.
|NO
|-
|17-19
|SPI
|These pins provide access to the Core Avionics SPI bus. This should be used in very extenuating circumstances, when Core Avionics control over an SPI device on your board is desired.
|NO
|-
|20
|VA_PWM
|This pin is a pulse-width modulated pin, controlled exclusively by the avionics, that adjusts the VADJ voltage, found on the power bus. While a board can technically implement this pin, VADJ control is exclusively in the hands of the avionics, and nobody should attempt to modulate this pin.
|NO
|-
|21
|CHIRP
|This pin is a UART TX pin from the Core Avionics, on which the Core Avionics will transmit a regular status message to the entire flight stack. This message will consist of information of various payload vitals, such as internal/external temperature, altitude, ascent rate, lat, long, etc. While not required, it is highly recommended to implement this pin for the purpose of being able to receive the broadcast message and have high-level flight awareness for a board. The board can specifically request data over CAN, if it chooses.
|YES
|-
|22
|RX2
|This pin is the RX partner of the CHIRP pin, which has no likely purpose, and should not be implemented.
|NO
|-
|23/24
|UART4
|This provides access to the Core Avionics Hardware UART #4 -- this should not be utilized unless expressly agreed upon, as it alters the architecture definition and devotes this UART specifically for one board.
|NO
|-
|25/26
|UART6
|This provides access to the Core Avionics Hardware UART #6 -- this should not be utilized unless expressly agreed upon, as it alters the architecture definition and devotes this UART specifically for one board.
|NO
|-
|27/28
|DAC0/1
|These pins provide access to the two Core Avionics DAC outputs. These should be used strictly as input pins -- if a board requires an analog signal to be produced, it should notify the Core Avionics of the desired signal, desired DAC channel for output, and use the output.
|NO
|-
|29-36, 38-40
|IO/1 - IO/13
|These are GPIO pins directly connected to the Core Avionics. These can be used to transfer a digital signal to the avionics, have the avionics sample an analog signal, or have the avionics PWM a signal, depending on the specific GPIO pin used. If this functionality is desired, one should reference the Core Avionics schematic to determine the pin capabilities of each of the GPIO's. These can be used both as inputs (to the Core Avionics) or outputs (from the Core Avionics). On the schematic symbol for the HABEES stackup, these are referred to as "AV____" where ____ is the corresponding pin on the Main Avionics MCU (a teensy 3.6). Reference the ____ pin on the 3.6 schematic to determine its functionality.
|NO
|-
|41
|BLUEJ_PRESENT
|This pin is pulled high by the BlueJay RockBlock breakout board -- to signal to the main avionics that it is in use, as opposed to the on-board 9603 modem.
|NO
|-
|81-86
|RB Breakout
|These pins are connected to the avionics RockBlock signal lines -- including TX, RX, SLP, NETAV, ENABLE, and RING INDICATOR. They are meant to allow the avionics to use an external RockBlock breakout board instead of its on-board 9603 modem, or, in the future, to allow the RockBlock to be broken out from the avionics if desired. They should not be touched by anything except the avionics. In this breakout, TX connects to an MCU TX, and RX connects to an MCU RX (as opposed to the standard swapped interface).
|NO
|-
|105-108
|12V
|These pins, although on the databus, provide 12V power for 12V applications -- when used, all four nets should be connected together and used in parallel.
|NO
|-
|113/114
|(+5V and -5V) (SIG)
|These pins are meant to be used for signal applications requiring a dual polarity +5V to -5V rail-to-rail supply. They only put out 15 mA, and should not be used for any power applications whatsoever.
|NO
|-
|115/114
|(+12V and -12V) (SIG)
|These pins are meant to be used for signal applications requiring a dual polarity +12V to -12V rail-to-rail supply. They only put out 15 mA, and should not be used for any power applications whatsoever.
|NO
|-
|37, 42-111, 117-120
|NC
|Reserved -- these can be used for any purpose at the time being, as long as it is agreed in advance.
|NO
|-
|112
|CAN_SPD
|This pin, controlled by the Core Avionics, determines the current speed of the flight stack CAN bus. This pin should be directly tied to the speed-select pin of the CAN Transceiver on a given board. No board should control this pin in any way, except to feed it in this fashion. The Core Avionics will adjust the speed of the CAN Bus as necessary, thereby adjusting all board Transceivers simultaneously.
|YES
|}

{| class="wikitable"
|-
|GND
|GND
|GND
|GND
|-
|VBCKP
|R_MCU
|R_ALL
|S_READY
|-
|LOW_PWR
|FMODE
|SYS_F3
|SYS_F4
|-
|SYS_F5
|SYS_F6
|SDA
|SCL
|-
|MOSI
|MISO
|SCLK
|VA_PWM
|-
|CHIRP
|RX2
|TX4
|RX4
|-
|TX6
|RX6
|DAC0
|DAC1
|-
|IO/1
|IO/2
|IO/3
|IO/4
|-
|IO/5
|IO/6
|IO/7
|IO/8
|-
|RESERVED
|IO/10
|IO/11
|IO/12
|-
|BLUEJ_PRESENT
|RESERVED
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|RB_TX -->
|RB_RX <--
|RB_NETAV
|RB_SLP
|-
|RB_RI
|RB_EN
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|12V
|12V
|12V
|12V
|-
|RESERVED
|RESERVED
|RESERVED
|CAN_SPD
|-
|Pos 5V (SIG)
|Neg 5V (SIG)
|Pos 12V (SIG)
|Neg 12V (SIG)
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|}

=== CAN BUS ===

[[File:cbus_rev1.JPG | right| thumb | <center> CAN Bus Pin-Out </center>]]
The CAN bus is the primary means of communication within the flight stack. The CAN bus is the means by which any board can request data from the avionics, receive data from the avionics, as well as receive commands and requests from the avionics for a specific action.

Every board, except in very extenuating circumstances, is required to implement the CAN bus.

The required, standardized HONEY transceiver is the TI_SN65HVD230.

The schematic for the CAN system for each board is well defined, and should be implemented exactly as shown. The CAN connector, in addition to the above described four nodes, includes a +3.3_CAN pin and a GND pin. GND should be common grounded, while +3.3_CAN should be used to power the CAN transceiver -- it should power no other device on a board, and the CAN transceiver should exclusively use this pin as its power source.

Shown here is the CAN schematic that should be implemented on any board.
[[File:can.JPG | right| thumb | <center> CAN Schematic </center>]]
{| class="wikitable"
|-
|CAN1_H
|CAN1_L
|-
|CAN2_H
|CAN2_L
|-
|3.3V_CAN
|GND
|}

=== CAN Terminating Jumpers ===

The CAN Terminating Impedance Connector, a 2x2 male terminal strip, is used for the purpose of applying the necessary 120-ohm terminating impedance on each end of the CAN bus. Since the current HONEY architecture dictates that the Core Avionics and Core BMS occupy the top and bottom positions in the stack, they are currently the only boards to utilize this connector.

[[File:can_stack.JPG | right| thumb | <center> CAN Stack Implementation </center>]]
[[File:can_wires.JPG | right| thumb | <center> CAN Feed-through </center>]]

A CAN bus requires a 120 ohm resistor between CAN HIGH and CAN LOW for the first and last devices on the bus to prevent reflections. This is achieved by jumping two pins, with a resistor in between. In this case, for CAN1, this is achieved by the top two pins in this connector. 1_TERM_1 and 1_TERM_2 are open-circuit, but, when jumped, become closed. 1_TERM_2 is connected to CAN1_L. 1_TERM_1 is connected to one end of a 120 ohm resistor -- the other end of the resistor is connected to CAN1_H. Thereby, by placing a jumper on the two pins and closing the circuit, a 120 ohm impedance is effectively engaged, properly terminating the bus.
The schematic for the implementation of this connector, including both the relevant portion of the stack connector, and its connection to the CAN transceiver, is shown here.

{| class="wikitable"
|-
|1_TERM_1
|1_TERM_2
|-
|2_TERM_1
|2_TERM_2
|-
|NC
|NC
|-
|NC
|NC
|}

[[File:allcan_rev1.JPG | right| thumb | <center> CAN, showing terminating impedance implemented </center>]]

== Software Specification ==
HONEY implements a flight stack-wide software suite called '''STINGR (Stack Transmission & Inter-Nodal Gesture Repository''', which provides a variety of function calls, interrupt handlers, and error-handling for communication within the stack, primarily utilizing the CAN Bus.

The full STINGR specification can be found on the [[Gen 1 Software|STINGR]] page.

== Implementation ==
Below is a short guide/list of steps to guide the design and implementation of a board for the HONEY architecture. One should follow it carefully, as it is specifically written to prevent one from making mistakes by forgetting to implement a required functionality, or using a restricted functionality.

=== Required Implementation ===
#Use the HABEES_NEW_STACK part from the Altium library. This is to be kept updated by HABEES members to reflect changes in pinout, physical layout, etc, and is required to make your board meet the physical and electrical bare requirements.
#Common Ground all GND nets on the stack connectors to your GND -- this includes two on the Power Bus, four on the Data Bus, and one on the CAN bus.
#For the nets of the power bus that your board is utilizing, make sure to electrically short the nets together, and join them by a 40/50-mil trace. The reason there are two pins is to provide a higher current-limit, so you should tie them together to ensure proper rating.
#Make '''SURE TO IMPLEMENT''' the following pins as INPUTS to your MCU -- 7 (R_ALL), 8 (S_READY), 9 (LOW_PWR), 10 (FMODE), 11-14 (System Flags 3-6, reserved), 21 (CHIRP -- should go to a Serial RX pin on your MCU).
#Make sure to properly implement the CAN Bus -- duplicate the existing schematic for the primary circuit, and verify that you have properly implemented the terminating impedance sub-circuit.
#Be sure to use +3.3_CAN pin from the CAN Bus EXCLUSIVELY to power your Transceiver, and make sure it powers nothing else.
#Make sure no component of the board extends more than 0.25" over the board edge.

[[Category: High Altitude Balloons]][[Category: HABEES]][[Category: HONEY]]

Gen 2 Architecture Rev1

2018-08-12T00:17:31Z

Vnguyen5: Created page with "{{HONEY-sidebar | header = HONEY Architecture | img link = File:HONEY2_rev1.jpg | designer = Vinh Nguyen | techline = Balloons Core Architecture | version = Generation II | na..."

{{HONEY-sidebar
| header = HONEY Architecture
| img link = File:HONEY2_rev1.jpg
| designer = Vinh Nguyen
| techline = Balloons Core Architecture
| version = Generation II
| name = HONEY
| acronym = Hardware Optimized Nested Electronics sYstem
}}

'''HONEY (Hardware Optimized Nested Electronics sYstem)''' is the second generation Core Flight Architecture, designed by HABEES. The HONEY architecture makes significant changes and improvements on the Generation I Architecture, including changes in physical dimensioning, stacking connectors, common power and data buses, and more.

Changes to the HONEY Architecture were made with Avionics Gen 5 and BMS Gen 3, which split the data bus into two in order to reduce routing complexity. Some features of HONEY were removed and are documented below under 'Data Bus'

== Physical Specifications ==
The HONEY architecture physical specifications comprise two categories: board specifications and stack specifications.

=== Board Specification ===
All boards implementing the HONEY spec must meet strict physical requirements. There is a standardized set of measurements, mounting holes, connector placements, and board dimensions that must be met for proper integration with the flight stack.

[[File:pcbtemplate_rev1.JPG | right| thumb | <center> PCB Template </center>]]

The dimensions of a HONEY-compliant board are exactly 10x10 cm. Boards are 0.062" in thickness (this is important for the physical fastening of the flight stack to the payload container, which is sensitive to the thicknesses of boards in the flight stack. Boards also have four through-holes at each corner, designated for standoffs. The holes are designed for M3 standoffs, which are indented 250 mil from both edges of the respective corner. The board also necessarily consists of a PC/104+ connector for the flight stack data bus, a 14-pin (7x2) connector for the flight stack power bus, a 4-pin (2x2) connector for the flight stack CAN bus, and an 2 pin (2x2) connector (NON stack through) for holding jumpers for implementing CAN terminating impedances. These connectors must be implemented exactly via the use of the HABEES_NEW_STACK compoenent.

The connectors and hardware used in each case can be found on the [[HONEY_Standardized_Connectors|HONEY Standardized Connectors Page]]
* Data Bus: 2x Harwin M20-6112045
* Power Bus: Samtec ESQ-107-38-G-D-LL
* CAN Bus: Samtec ESQ-102-38-G-D-LL
* CAN Jump Holder: Samtec TSW-102-07-G-D
* CAN Terminating Jumper: Samtec SNT-100-BK-T
* Stack Standoffs: Harwin R6104-02

The physical footprint of a HONEY base-board can be found in the Altium library as "HABEES_NEW_STACK" -- this features both a compliant and properly dimensioned 2PCB, as well as a schematic symbol for accessing the power, data, and CAN buses.

=== Stack Specification ===
The HONEY architecture is defined by a flight stack, comprised of stacked HONEY-compliant boards, with common data, power, and CAN buses, physically integrated through a series of four corner standoffs. Flight boards in the flight stack are inter-connected by the standoffs mentioned above (Harwin R6104-02 standoffs). Boards are expected to be 0.062" thickness.

The flight-stack is compromised of two primary divisions: ''Flight Critical Components (FCC)'' and ''Flight Tertiary Components (FTC)''. At time of writing, there are only two FCC's -- the Core Avionics and the Core BMS. All other boards, non-essential to flight operation, are considered FTC. Components are categorized and assessed as FCC or FTC upon design and implementation on a rolling basis. A flight-ready flight-stack must consist of at least one of each of the Flight Critical Components, and can include zero or any number of Tertiary Flight Components.

The Avionics & BMS are specified by the HONEY spec as being the strictly top-most and strictly bottom-most boards in the flight stack, with all FTC in-between. This is the case for two reasons: Core Avionics required a clear view of the sky for proper Iridium & GPS reception, and therefore must be on the top of the stack. The BMS holds four 18650 Li-Ion cells on its bottom, and the standard inter-board spacing is insufficient to fit the battery pack. it is therefore allocated to the bottom of the stack, which is fastened to the payload container by longer standoffs to accommodate the battery pack size.

The flight stack is therefore comprised of a minimum of two boards, and can theoretically be any defined height. Currently, a flight stack of five boards is categorized as a "1U flight-stack" for payload-integration purposes. An additional sixth board results in a 2U flight stack, an eleventh board results in a 3U flight stack, and so on.

As defined by the current spec, the physical stack dimensioning is as so:

* XY-Board Dimensions: 10x10 cm
* Z-Board Thickness: 0.062"
* Permissible Extension outside of Board Dimensions: 0.25"
* Maximum spacing outside of Board Dimensions: 0.5"
* Inter-Board spacing: 15.24mm, as defined by the Harwin R6104-02 standoff.
* BMS-Payload Base spacing: 25mm, as defined by McMaster 94868A013, 10/12mm standoffs (McMaster 92005A120, 92005A122)
* Avionics-Roof spacing: Variable, depending on stack height.

Avionics-Roof spacing, by stack height:
* 2-Boards (Base Stack): 51mm spacing, 60mm fixture bolt. (McMaster 94669A127, 92005A140)
* 3-Boards (Base + 1 FTC): 35mm spacing, 45mm fixture bolt. (McMaster 94669A121, 92005A136)
* 4-Boards (Base + 2 FTC): 16mm spacing, 30/25mm fixture bolt. (McMaster 94669A111, 92005A132, 92005A130)
* 5-Boards (Base + 3 FTC): 25mm spacing, same as BMS. (McMaster 94868A013, 92005A120, 92005A122)

== Electrical Specifications ==
The HONEY architecture defines pinouts for the various bus connectors, as well as pins required for implementation and auxiliary pins one can use on a given stack-board.

There are three defined buses, with specific purposes, limitations, and requirements as defined by the HONEY electrical specification.

=== Power Bus ===
The power bus pin-out is as follows:
{| class="wikitable"
|-
|VBAT
|1.8EXP
|3.3EXP
|5EXP
|5AVI
|3.3AVI
|GND
|-
|VBAT
|1.8EXP
|3.3EXP
|5EXP
|5AVI
|3.3AVI
|GND
|}

The purpose of the power bus to supply power to the entirety of the flight-stack. It does this using high-current rated pins, ultimately deriving their power from the BMS. At the time of writing, the active BMS is Cupcake, and the following will be written with the Cupcake specifications.

[[File:pbus_rev1.JPG | right| thumb | <center> Power Bus Pin-Out </center>]]

The power bus provides two separate power buses for the Avionics and Expansion boards. Each provides 5V, 3.3V and has a separate maximum current limit of 5A, beyond which the protection on the BMS will shut the violating power line(s). The power bus for expansion boards additionally provides 1.8V. It is required that expansion boards use only the expansion board power bus to ensure nominal function of main avionics.

The power bus also provides raw cell voltage +VBAT -- this voltage is nominally 3.7V, 4.25V at full capacity, and changes from ~ 4.25V down to ~ 3.2V at pack end-of-life. It's purpose is strictly for high current applications where high power with few voltage requirements is the defining characteristic. The pack can source ~ 12 amps from the VBAT line at peak (should not be tapped at this current for too long). Examples of its current application are for nickel chromium cutdown (1A), and in-board heaters for the BMS and Avionics (~ 500 mA), as well as powering the Dorji Radio Transceivers on Macaw (1W @ 4.2V).

Lastly, the power bus provides two nodes for common ground, which must be implemented to common-ground a board to the BMS/flight-stack.

=== Data Bus ===

[[File:dbus_top_rev1.JPG | right| thumb | <center> Data Bus Top </center>]]
[[File:dbus_bottom_rev1.JPG | right| thumb | <center> Data Bus Bottom </center>]]

The data bus serves as a means by which to transfer specific reserved signals throughout the flight stack, access reserved Core Avionics UART lines, as well as Core Avionics SPI/I2C, as well as implement system flags, and some other utility features. While primary communication between boards happens via the CAN bus, certain pins on the data bus are required to be implemented by all boards in the flight stack, and other pins may yield utility, depending on the specific application of a board. All "RESERVED" pins currently serve no purpose, and may be reserved by your board for transitioning signals up and down the flight stack.

A description of all the pins and whether they are required to be implemented is found in the following table, and the entire pinout can be found following this table.

{| class="wikitable"
|-
|Pin
|Net
|Purpose
|REQ?
|-
|1-4
|GND
|GND
|YES
|-
|5
|VBCKP
|The VBCKP pin is connected to a +3V coin cell located on the BMS. This pin serves as a backup, low-current 3V supply primarily for memory applications, such as RTC's & GPS memory. It continues to power crystals and internal memory to keep the state of RTC's, etc, even through power-cycles.
|NO
|-
|6
|R_MCU
|The R_MCU pin, if pulled high, resets the Core Avionics board remotely. This pin should be implemented under almost '''NO CIRUMSTANCES'''. The Avionics largely in charge of the flight stack, and very few boards should ever have the authority to reset it. It exists for possible, if seldom, application.
|NO
|-
|7
|R_ALL
|The R_ALL pin, if pulled high, will reset all boards in the flight stack. This pin is controlled exclusively by the Core Avionics, and should be tied to the reset pin of any MCU found on a board. The Avionics has the authority to reset all flight stack boards in the case of excessive power consumption, poor responsiveness, or erratic behavior.
|YES
|-
|8
|S_READY
|The S_READY pin, once pulled high, alerts all flight stack boards that the Core Avionics has passed initial booting, and is ready to accept requests and provide flight services. All boards should wait until S_READY is high to begin their initialization and operating procedures.
|YES
|-
|9
|LOW_PWR
|The LOW_PWR pin, once pulled high, alerts all flight stack boards that they should enter low power mode, whereby they should conduct all possible actions to minimize power consumption. This flag is pulled high in the case that the payload is losing power, and must retain all power for flight critical operations.
|YES
|-
|10
|FMODE
|The FMODE pin, once pulled high, alerts all flight stack boards that the payload has been released, and is ascending, and in flight mode. This is a utility flag that can be implemented if your board desires to know whether flight has begun, or whether the payload has not yet been released, or has landed.
|YES
|-
|11-14
|SYS_F(3-6)
|Reserved System Flags for future purposes.
|YES
|-
|15, 16
|SDA/SCL
|These pins provide access to the Core Avionics I2C bus. This should be used in very extenuating circumstances, when Core Avionics control over an I2C device on a board is desired.
|NO
|-
|17-19
|SPI
|These pins provide access to the Core Avionics SPI bus. This should be used in very extenuating circumstances, when Core Avionics control over an SPI device on your board is desired.
|NO
|-
|20
|VA_PWM
|This pin is a pulse-width modulated pin, controlled exclusively by the avionics, that adjusts the VADJ voltage, found on the power bus. While a board can technically implement this pin, VADJ control is exclusively in the hands of the avionics, and nobody should attempt to modulate this pin.
|NO
|-
|21
|CHIRP
|This pin is a UART TX pin from the Core Avionics, on which the Core Avionics will transmit a regular status message to the entire flight stack. This message will consist of information of various payload vitals, such as internal/external temperature, altitude, ascent rate, lat, long, etc. While not required, it is highly recommended to implement this pin for the purpose of being able to receive the broadcast message and have high-level flight awareness for a board. The board can specifically request data over CAN, if it chooses.
|YES
|-
|22
|RX2
|This pin is the RX partner of the CHIRP pin, which has no likely purpose, and should not be implemented.
|NO
|-
|23/24
|UART4
|This provides access to the Core Avionics Hardware UART #4 -- this should not be utilized unless expressly agreed upon, as it alters the architecture definition and devotes this UART specifically for one board.
|NO
|-
|25/26
|UART6
|This provides access to the Core Avionics Hardware UART #6 -- this should not be utilized unless expressly agreed upon, as it alters the architecture definition and devotes this UART specifically for one board.
|NO
|-
|27/28
|DAC0/1
|These pins provide access to the two Core Avionics DAC outputs. These should be used strictly as input pins -- if a board requires an analog signal to be produced, it should notify the Core Avionics of the desired signal, desired DAC channel for output, and use the output.
|NO
|-
|29-36, 38-40
|IO/1 - IO/13
|These are GPIO pins directly connected to the Core Avionics. These can be used to transfer a digital signal to the avionics, have the avionics sample an analog signal, or have the avionics PWM a signal, depending on the specific GPIO pin used. If this functionality is desired, one should reference the Core Avionics schematic to determine the pin capabilities of each of the GPIO's. These can be used both as inputs (to the Core Avionics) or outputs (from the Core Avionics). On the schematic symbol for the HABEES stackup, these are referred to as "AV____" where ____ is the corresponding pin on the Main Avionics MCU (a teensy 3.6). Reference the ____ pin on the 3.6 schematic to determine its functionality.
|NO
|-
|41
|BLUEJ_PRESENT
|This pin is pulled high by the BlueJay RockBlock breakout board -- to signal to the main avionics that it is in use, as opposed to the on-board 9603 modem.
|NO
|-
|81-86
|RB Breakout
|These pins are connected to the avionics RockBlock signal lines -- including TX, RX, SLP, NETAV, ENABLE, and RING INDICATOR. They are meant to allow the avionics to use an external RockBlock breakout board instead of its on-board 9603 modem, or, in the future, to allow the RockBlock to be broken out from the avionics if desired. They should not be touched by anything except the avionics. In this breakout, TX connects to an MCU TX, and RX connects to an MCU RX (as opposed to the standard swapped interface).
|NO
|-
|105-108
|12V
|These pins, although on the databus, provide 12V power for 12V applications -- when used, all four nets should be connected together and used in parallel.
|NO
|-
|113/114
|(+5V and -5V) (SIG)
|These pins are meant to be used for signal applications requiring a dual polarity +5V to -5V rail-to-rail supply. They only put out 15 mA, and should not be used for any power applications whatsoever.
|NO
|-
|115/114
|(+12V and -12V) (SIG)
|These pins are meant to be used for signal applications requiring a dual polarity +12V to -12V rail-to-rail supply. They only put out 15 mA, and should not be used for any power applications whatsoever.
|NO
|-
|37, 42-111, 117-120
|NC
|Reserved -- these can be used for any purpose at the time being, as long as it is agreed in advance.
|NO
|-
|112
|CAN_SPD
|This pin, controlled by the Core Avionics, determines the current speed of the flight stack CAN bus. This pin should be directly tied to the speed-select pin of the CAN Transceiver on a given board. No board should control this pin in any way, except to feed it in this fashion. The Core Avionics will adjust the speed of the CAN Bus as necessary, thereby adjusting all board Transceivers simultaneously.
|YES
|}

{| class="wikitable"
|-
|GND
|GND
|GND
|GND
|-
|VBCKP
|R_MCU
|R_ALL
|S_READY
|-
|LOW_PWR
|FMODE
|SYS_F3
|SYS_F4
|-
|SYS_F5
|SYS_F6
|SDA
|SCL
|-
|MOSI
|MISO
|SCLK
|VA_PWM
|-
|CHIRP
|RX2
|TX4
|RX4
|-
|TX6
|RX6
|DAC0
|DAC1
|-
|IO/1
|IO/2
|IO/3
|IO/4
|-
|IO/5
|IO/6
|IO/7
|IO/8
|-
|RESERVED
|IO/10
|IO/11
|IO/12
|-
|BLUEJ_PRESENT
|RESERVED
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|RB_TX -->
|RB_RX <--
|RB_NETAV
|RB_SLP
|-
|RB_RI
|RB_EN
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|-
|12V
|12V
|12V
|12V
|-
|RESERVED
|RESERVED
|RESERVED
|CAN_SPD
|-
|Pos 5V (SIG)
|Neg 5V (SIG)
|Pos 12V (SIG)
|Neg 12V (SIG)
|-
|RESERVED
|RESERVED
|RESERVED
|RESERVED
|}

=== CAN BUS ===

[[File:cbus.JPG | right| thumb | <center> CAN Bus Pin-Out </center>]]
The CAN bus is the primary means of communication within the flight stack. The CAN bus is the means by which any board can request data from the avionics, receive data from the avionics, as well as receive commands and requests from the avionics for a specific action.

Every board, except in very extenuating circumstances, is required to implement the CAN bus.

The required, standardized HONEY transceiver is the TI_SN65HVD230.

There are ''two'' CAN buses -- CAN1 and CAN2. CAN1 is the primary CAN bus used for the flight stack, while CAN2 is a secondary bus that exists only for possible future use. All boards should implement CAN1. The schematic for the CAN system for each board is well defined, and should be implemented exactly as shown. The CAN connector, in addition to the above described four nodes, includes a +3.3_CAN pin and a GND pin. GND should be common grounded, while +3.3_CAN should be used to power the CAN transceiver -- it should power no other device on a board, and the CAN transceiver should exclusively use this pin as its power source.

Shown here is the CAN schematic that should be implemented on any board.
[[File:can.JPG | right| thumb | <center> CAN Schematic </center>]]
{| class="wikitable"
|-
|CAN1_H
|CAN1_L
|-
|CAN2_H
|CAN2_L
|-
|3.3V_CAN
|GND
|}

=== CAN Terminating Jumpers ===

The CAN Terminating Impedance Connector, a 2x4 male terminal strip, is used for the purpose of applying the necessary 120-ohm terminating impedance on each end of the CAN bus. Since the current HONEY architecture dictates that the Core Avionics and Core BMS occupy the top and bottom positions in the stack, they are currently the only boards to utilize this connector. However, as the architecture may evolve, and positions of boards change, it is necessary to implement this connector so that your board may effectively institute the necessary terminating impedance.

[[File:can_stack.JPG | right| thumb | <center> CAN Stack Implementation </center>]]
[[File:can_wires.JPG | right| thumb | <center> CAN Feed-through </center>]]

A CAN bus requires a 120 ohm resistor between CAN HIGH and CAN LOW for the first and last devices on the bus to prevent reflections. This is achieved by jumping two pins, with a resistor in between. In this case, for CAN1, this is achieved by the top two pins in this connector. 1_TERM_1 and 1_TERM_2 are open-circuit, but, when jumped, become closed. 1_TERM_2 is connected to CAN1_L. 1_TERM_1 is connected to one end of a 120 ohm resistor -- the other end of the resistor is connected to CAN1_H. Thereby, by placing a jumper on the two pins and closing the circuit, a 120 ohm impedance is effectively engaged, properly terminating the bus. The same is true for pins 3/4, which are for CAN2 (not used by most boards). Pins 4-8 exist solely as a position to place jumpers when they are not used by a board -- IE when the board is not implementing the terminating impedance.

The schematic for the implementation of this connector, including both the relevant portion of the stack connector, and its connection to the CAN transceiver, is shown here.

{| class="wikitable"
|-
|1_TERM_1
|1_TERM_2
|-
|2_TERM_1
|2_TERM_2
|-
|NC
|NC
|-
|NC
|NC
|}

[[File:allcan.JPG | right| thumb | <center> CAN, showing terminating impedance implemented </center>]]

== Software Specification ==
HONEY implements a flight stack-wide software suite called '''STINGR (Stack Transmission & Inter-Nodal Gesture Repository''', which provides a variety of function calls, interrupt handlers, and error-handling for communication within the stack, primarily utilizing the CAN Bus.

The full STINGR specification can be found on the [[Gen 1 Software|STINGR]] page.

== Implementation ==
Below is a short guide/list of steps to guide the design and implementation of a board for the HONEY architecture. One should follow it carefully, as it is specifically written to prevent one from making mistakes by forgetting to implement a required functionality, or using a restricted functionality.

=== Required Implementation ===
#Use the latest HABEES_STACK_TEMPLATE part from the Altium library. This is to be kept updated by HABEES members to reflect changes in pinout, physical layout, etc, and is required to make your board meet the physical and electrical bare requirements.
#Common Ground all GND nets on the stack connectors to your GND -- this includes two on the Power Bus, four on the Data Bus, and one on the CAN bus.
#For the nets of the power bus that your board is utilizing, make sure to electrically short the nets together, and join them by a 40/50-mil trace. The reason there are two pins is to provide a higher current-limit, so you should tie them together to ensure proper rating.
#Make sure to '''NOT IMPLEMENT''' any of the following restricted pins, unless specifically agreed upon in advance (don't touch them at all, even as an input) -- 6 (R_MCU), 22 (RX2) 112 (CAN_MODE -- this shouldn't go anywhere except your Transceiver)
#Make '''SURE TO IMPLEMENT''' the following pins as INPUTS to your MCU -- 7 (R_ALL), 8 (S_READY), 9 (LOW_PWR), 10 (FMODE), 11-14 (System Flags 3-6, reserved), 21 (CHIRP -- should go to a Serial RX pin on your MCU).
#Make sure to properly implement the CAN Bus -- duplicate the existing schematic for the primary circuit, and verify that you have properly implemented the terminating impedance sub-circuit.
#Be sure to connect pin 112 (CAN_SPD) from the data bus to the speed pin on your CAN Transceiver. Without this, it will not function.
#Be sure to use +3.3_CAN pin from the CAN Bus EXCLUSIVELY to power your Transceiver, and make sure it powers nothing else.
#Make sure pin 7 (R_ALL) is directly wired to your MCU reset pin, to allow Core Avionics remote reset.
#If using RTC, make sure to implement pin 5 (+VBCKP).
#Make sure no component of the board extends more than 0.25" over the board edge.

=== Self-Help FAQ ===
#If implementing the data bus SPI or I2C lines, this should be agreed upon by current HABEES members as an appropriate use of the Core Avionics I2C/SPI buses before action is taken.
#If using either of the dedicated Core Avionics Hardware UARTs (pins 23/24 and 25/26), this should be agreed as constituting a reasonable use -- being that it is critical enough to warrant their use, or otherwise cannot be achieved.
#If using either DAC (pins 27 and 28) verify it can only be used as an input, and will not be used in any way as an output (IE do not output to those pins).
#If using any of the Core Avionics GPIO's on the data bus (pins 29-36, 38-41), be sure that it isn't currently being used by another board (unless you specifically want it to be, such as using the pin as a feed-through signal line), whether the pin is able to perform the desired action (PWM, ADC, DIO), and agree amongst HABEES members that it is a reasonable and just usage of the pin, which would henceforth be reserved for your purpose.
#If using any of the current RESERVED pins (37, 42-111, 113-120), agree amongst HABEES members that it is a just and fair usage of the pin, which would henceforth be reserved for your purpose.
#Make sure, unless for some reason you're using it, CAN2 is not connected to anything.
#Make sure +3.3_CAN is used only to power the transceiver, and nothing else.
#Make sure CAN_SPD is hard-wired to the transceiver speed pin.

[[Category: High Altitude Balloons]][[Category: HABEES]][[Category: HONEY]]

Balloons Gen 5 Avionics

2018-07-15T05:36:17Z

Vnguyen5:

{{HABEES-sidebar
| header = Kermit
| img link = File:Gen5s.PNG
| designer = Vinh Nguyen
| techline = Balloons Core Avionics
| version = Generation V
| name = Kermit
}}

[[Category: High Altitude Balloons]][[Category: HABEES]]

'''Kermit''' is the fifth revision of the HABEES Standard Avionics Platform. It implements most of the functionality that exists in Gen 4 rev 2 Avionics, but the architecture of the boards has been changed, and functionality removed to reduce the complexity of implementation and application of the flight stack. 

Kermit provides the following flight critical systems features: 

* A Teensy 3.6 embedded Microcontroller
* A ublox-M8Q GNSS (GPS/GLONASS/Beidou/Galileo) receiver with embedded patch antenna
* MicroSD data logging
* A thermocouple for external temperature sensing
* Two BMP280 pressure/temperature sensors
* A PWM-operated cutdown FET
* An inboard heater
* Power, CAN, and data bus connectors
* 8 RGB indicator LED's about various system states
* A power-selector to enable 5V operation from BMS or USB
* CAN Transceiver for use with the HONEY CAN bus
* Additional bypass capacitors
* Current sensors for GPS and Cutdown 

Notable differences from the previous generation include:
* SiLabs 4463 Radio, the same used as Valbal v9. 
This provides a higher bandwidth data link for use by expansion boards so that future applications need only generate data and send it to main avionics.
* Connector for Iridium RockBlock module 
An embedded module proved to be too difficult to implement in the previous revision, while not providing significant benefit over using the out-of-the-box RockBlock module + connector alternative.

== Development ==
Given the difficulty that was experienced in assembling and testing the previous generation of standard avionics, the current generation was built with the primary goal in mind of reducing the complexity and producing a system whose core functionality is easier to realize and least liable to fail after assembly (given that most likely avionics must be manually assembled and debugged).
Several changes were made from Rev 4.2 in order to reduce the complexity: 
* The data bus was split into two, and the number of pins broken out was reduced only to the number of GPIOs free after all avionics systems, simplifying routing and reducing the number of pins.
**
* Abandoning an embedded RockBlock and its dedicated power circuitry, which required a large footprint and ultimately incredibly dense packing and clever routing to accommodate the rest of the system.
* Removing auxiliary heater FETs
* Removing some current sensors, because power consumption data for its own sake is not considered a priority for standard-profile launches
* Removing the second, excessive CAN bus
* Removing the IMU
* Removing watchdog circuitry, because historical standard-profile launches have not shown frequent anomalies that would make a watchdog critical, let alone problems that would be solved by the watchdog as it was implemented in Gen 4.2
* Forgoing power select circuitry for a simple switch 

== Testing ==
The boards are set to be assembled and tested during the fall of the 2018/19 academic year, with a first launch planned for Winter 2019.

== Issues ==
The inclusion of the SiLabs radio may be adding unnecessary complexity that is best deferred to an expansion board.

== PCB Layout ==
Gen 5 Avionics remains a 4-layer board, compliant with Gen 2 Architecture. All signals were routed on the top and bottom layers, while only the heater trace went beyond those two layers. While it may be possible to route the heater trace on the top and bottom layer, it will be much more difficult, if impossible, to apply the traces directly to the components which require heat, such as the GPS and MCU.

== Schematics ==
<gallery widths=200px heights=200px>
File:g5_top.PNG | <center> Top Sheet </center>
File:bypasscaps.PNG | <center> Bypass Capacitors </center>
File:can.PNG | <center> CAN </center>
File:gps.PNG | <center> GPS </center>
File:GFSK.PNG | <center> Radio </center>
File:cutdown.PNG | <center> Cutdown </center>
File:g5_micro_sd.PNG | <center> SD Card </center>
File:g5_thermocouple.PNG | <center> External Temperature Sensing </center>
File:g5_multiplexer.PNG | <center> Multiplexer for LEDS </center>
File:leds.PNG | <center> Status LEDs </center>
File:g5_rb_connector.PNG | <center> RockBlock Connector </center>
File:g5_stackbus.PNG | <center> Connections to Stackbus </center>
File:g5_teensycore.PNG | <center> Teensy 3.6 </center>
File:g5_pressure_sensors.PNG | <center> Pressure Sensors/center>
</gallery>

Balloons Gen 3 BMS

2018-07-15T05:29:30Z

Vnguyen5:

{{HABEES-sidebar
| header = Cupcake
| img link = File:Gen5bms_s.PNG
| designer = Zachary Belateche
| techline = Balloons Core Power
| version = Generation III
| name = Cupcake
}}

[[Category: High Altitude Balloons]][[Category: HABEES]]

'''Cupcake''' is the 3rd iteration of the '''B'''attery '''M'''anagement '''S'''system for the HABEES Standard Avionics Platform. It addresses the complexity issue of the previous generation by removing the data collection circuitry/microcontroller, and adding a separate power path for expansion boards. It is compliant with the Gen 2 Architecture. 

Outputs: 

* Main Avionics Power Path
** 3.3V, 5V
* Expansion Board Power Path
** 1.8V, 3.3V, 5V
* Shared raw cell voltage (VBAT) 

Features of each power path: 
* Voltage and Current Protector (Undervoltage 3V, Overvoltage 5V, Overcurrent 5A)
* Buckboost for 5V and LDO (low dropout regulator) for 3.3V 

Additional features:
* Temperature Monitor (Overtemp 50C, Heater activated at -10C)
* inboard heater
* Status LEDs for charging indicator and faults

== Testing ==
Cupcake is planned to be assembled in the fall of the 2018-2019 academic year, with the first launch planned for Winter 2019.

== Schematics ==
<gallery widths=200px heights=200px>
File:g3_top.PNG | <center> Top Sheet </center>
File:g3_ldo.PNG | <center> Batteries </center>
File:g3_boost.PNG | <center> Boost </center>
File:g3_output_connectors.PNG | <center> Output Connectors </center>
File:g3_protector.PNG | <center> Protector </center>
File:g3_tmon.PNG | <center> Temperature Monitor </center>
File:g3_usbcharger.PNG | <center> USB Charger </center>
</gallery>

Balloons Gen 3 BMS

2018-07-15T05:26:27Z

Vnguyen5:

{{HABEES-sidebar
| header = Cupcake
| img link = File:Gen5bms_s.PNG
| designer = Zachary Belateche
| techline = Balloons Core Power
| version = Generation III
| name = Cupcake
}}

[[Category: High Altitude Balloons]][[Category: HABEES]]

'''Cupcake''' is the 3rd iteration of the '''B'''attery '''M'''anagement '''S'''system for the HABEES Standard Avionics Platform. It addresses the complexity issue of the previous generation by removing the data collection circuitry/microcontroller, and adding a separate power path for expansion boards. It is compliant with the Gen 2 Architecture. 

Outputs: 

* Main Avionics Power Path
** 3.3V, 5V
* Expansion Board Power Path
** 1.8V, 3.3V, 5V
* Shared raw cell voltage (VBAT) 

Features of each power path: 
* Voltage and Current Protector (Undervoltage 3V, Overvoltage 5V, Overcurrent 5A)
* Buckboost for 5V and LDO (low dropout regulator) for 3.3V 

Additional features:
* Temperature Monitor (Overtemp 50C, Heater activated at -10C)
* inboard heater
* Status LEDs for charging indicator and faults

== Testing ==
Cupcake is planned to be assembled in the fall of the 2018-2019 academic year, with the first launch planned for Winter 2019.

== Schematics ==
<gallery widths=200px heights=200px>
File:g3_top.JPG | <center> Top Sheet </center>
File:g3_ldo.JPG | <center> Batteries </center>
File:g3_boost.JPG | <center> Boost </center>
File:g3_output_connectors.JPG | <center> Output Connectors </center>
File:g3_protector.JPG | <center> Protector </center>
File:g3_tmon.JPG | <center> Temperature Monitor </center>
File:g3_usbcharger.JPG | <center> USB Charger </center>
</gallery>

File:G3 usbcharger.PNG

2018-07-15T05:23:42Z

Vnguyen5:

File:G3 top.PNG

2018-07-15T05:23:24Z

Vnguyen5:

File:G3 tmon.PNG

2018-07-15T05:23:02Z

Vnguyen5:

File:G3 protector.PNG

2018-07-15T05:22:38Z

Vnguyen5:

File:G3 output connectors.PNG

2018-07-15T05:22:17Z

Vnguyen5:

File:G3 ldo.PNG

2018-07-15T05:21:57Z

Vnguyen5:

File:G3 boost.PNG

2018-07-15T05:21:36Z

Vnguyen5:

File:G3 batteries.PNG

2018-07-15T05:21:14Z

Vnguyen5:

File:G5 top.PNG

2018-07-15T05:20:14Z

Vnguyen5:

File:G5 thermocouple.PNG

2018-07-15T05:19:35Z

Vnguyen5:

File:G5 teensycore.PNG

2018-07-15T05:19:05Z

Vnguyen5:

File:G5 stackbus.PNG

2018-07-15T05:18:39Z

Vnguyen5:

File:G5 rb connector.PNG

2018-07-15T05:18:19Z

Vnguyen5:

File:G5 pressure sensors.PNG

2018-07-15T05:17:57Z

Vnguyen5:

File:G5 multiplexer.PNG

2018-07-15T05:17:34Z

Vnguyen5:

File:G5 micro sd.PNG

2018-07-15T05:17:04Z

Vnguyen5:

File:Leds.PNG

2018-07-15T05:16:26Z

Vnguyen5:

File:Gps.PNG

2018-07-15T05:16:11Z

Vnguyen5:

File:GFSK.PNG

2018-07-15T05:15:52Z

Vnguyen5:

File:Cutdown.PNG

2018-07-15T05:15:30Z

Vnguyen5: Used to sever the payload from the balloon in a controlled manner. Use cases include cutting down at a particular altitude, or to limit how far the balloon travels.

Used to sever the payload from the balloon in a controlled manner. Use cases include cutting down at a particular altitude, or to limit how far the balloon travels.

File:Can.PNG

2018-07-15T05:13:57Z

Vnguyen5: Used for high-speed communication between boards on the stack.

Used for high-speed communication between boards on the stack.

File:Bypasscaps.PNG

2018-07-15T05:12:47Z

Vnguyen5: Capacitors charged directly by the batteries used to deliver the initial burst of current to parts of the system faster than the batteries can, due to their closer proximity to loads than the batteries.

Capacitors charged directly by the batteries used to deliver the initial burst of current to parts of the system faster than the batteries can, due to their closer proximity to loads than the batteries.

Balloons Gen 5 Avionics

2018-07-15T04:54:56Z

Vnguyen5:

Balloons Gen 5 Avionics

2018-07-15T04:54:30Z

Vnguyen5:

{{HABEES-sidebar
| header = Kermit
| img link = File:Gen5s.PNG
| designer = Vinh Nguyen
| techline = Balloons Core Avionics
| version = Generation V
| name = Kermit
}}

[[Category: High Altitude Balloons]][[Category: HABEES]]

'''Kermit''' is the fifth revision of the HABEES Standard Avionics Platform. It implements most of the functionality that exists in Gen 4 rev 2 Avionics, but the architecture of the boards has been changed, and functionality removed to reduce the complexity of implementation and application of the flight stack. 

Kermit provides the following flight critical systems features: 

* A Teensy 3.6 embedded Microcontroller
* A ublox-M8Q GNSS (GPS/GLONASS/Beidou/Galileo) receiver with embedded patch antenna
* MicroSD data logging
* A thermocouple for external temperature sensing
* Two BMP280 pressure/temperature sensors
* A PWM-operated cutdown FET
* An inboard heater
* Power, CAN, and data bus connectors
* 8 RGB indicator LED's about various system states
* A power-selector to enable 5V operation from BMS or USB
* CAN Transceiver for use with the HONEY CAN bus
* Additional bypass capacitors
* Current sensors for GPS and Cutdown 

Notable differences from the previous generation include:
* SiLabs 4463 Radio, the same used as Valbal v9. 
This provides a higher bandwidth data link for use by expansion boards so that future applications need only generate data and send it to main avionics.
* Connector for Iridium RockBlock module 
An embedded module proved to be too difficult to implement in the previous revision, while not providing significant benefit over using the out-of-the-box RockBlock module + connector alternative.

== Development ==
Given the difficulty that was experienced in assembling and testing the previous generation of standard avionics, the current generation was built with the primary goal in mind of reducing the complexity and producing a system whose core functionality is easier to realize and least liable to fail after assembly (given that most likely avionics must be manually assembled and debugged).
Several changes were made from Rev 4.2 in order to reduce the complexity: 
* The data bus was split into two, and the number of pins broken out was reduced only to the number of GPIOs free after all avionics systems, simplifying routing and reducing the number of pins.
**
* Abandoning an embedded RockBlock and its dedicated power circuitry, which required a large foot print and ultimately incredibly dense packing and clever routing to accommodate the rest of the system.
* Removing auxiliary heater FETs
* Removing some current sensors, because power consumption data for its own sake is not considered a priority for standard-profile launches
* Removing the second, excessive CAN bus
* Removing the IMU
* Removing watchdog circuitry, because historical standard-profile launches have not shown frequent anomalies that would make a watchdog critical, let alone problems that would be solved by the watchdog as it was implemented in Gen 4.2
* Forgoing power select circuitry for a simple switch 

== Testing ==
The boards are set to be assembled and tested during the fall of the 2018/19 academic year, with a first launch planned for Winter 2019.

== Issues ==
The inclusion of the SiLabs radio may be adding unnecessary complexity that is best deferred to an expansion board.

== PCB Layout ==
Gen 5 Avionics remains a 4-layer board, compliant with Gen 2 Architecture. All signals were routed on the top and bottom layers, while only the heater trace went beyond those two layers. While it may be possible to route the heater trace on the top and bottom layer, it will be much more difficult, if impossible, to apply the traces directly to the components which require heat, such as the GPS and MCU.

Balloons Gen 3 BMS

2018-07-15T04:53:04Z

Vnguyen5:

Balloons Gen 5 Avionics

2018-07-15T04:51:25Z

Vnguyen5:

{{HABEES-sidebar
| header = Kermit
| img link = File:Gen5s.PNG
| designer = Vinh Nguyen
| techline = Balloons Core Avionics
| version = Generation V
| name = Kermit
}}

[[Category: High Altitude Balloons]][[Category: HABEES]]

'''Kermit''' is the fifth revision of the HABEES Standard Avionics Platform. It implements most of the functionality that exists in Gen 4 rev 2 Avionics, but the architecture of the boards has been changed, and functionality removed to reduce the complexity of implementation and application of the flight stack. 

Kermit provides the following flight critical systems features: 

* A Teensy 3.6 embedded Microcontroller
* A ublox-M8Q GNSS (GPS/GLONASS/Beidou/Galileo) receiver with embedded patch antenna
* MicroSD data logging
* A thermocouple for external temperature sensing
* Two BMP280 pressure/temperature sensors
* A PWM-operated cutdown FET
* An inboard heater
* Power, CAN, and data bus connectors
* 8 RGB indicator LED's about various system states
* A power-selector to enable 5V operation from BMS or USB
* CAN Transceiver for use with the HONEY CAN bus
* Additional bypass capacitors
* Current sensors for GPS and Cutdown 

Notable differences from the previous generation include:
* SiLabs 4463 Radio, the same used as Valbal v9. 
This provides a higher bandwidth data link for use by expansion boards so that future applications need only generate data and send it to main avionics.
* Connector for Iridium RockBlock module 
An embedded module proved to be too difficult to implement in the previous revision, while not providing significant benefit over using the out-of-the-box RockBlock module + connector alternative.

== Development ==
Given the difficulty that was experienced in assembling and testing the previous generation of standard avionics, the current generation was built with the primary goal in mind of reducing the complexity and producing a system whose core functionality is easier to realize and least liable to fail after assembly (given that most likely avionics must be manually assembled and debugged).
Several changes were made from Rev 4.2 in order to reduce the complexity: 
* The data bus was split into two, and the number of pins broken out was reduced only to the number of GPIOs free after all avionics systems, simplifying routing and reducing the number of pins.
**
* Abandoning an embedded RockBlock, which required dedicated power circuitry and a very large footprint which required incredibly dense packing and clever routing to accommodate the rest of the system
* Removing auxiliary heater FETs
* Removing some current sensors, because power consumption data for its own sake is not considered a priority for standard-profile launches
* Removing the second, excessive CAN bus
* Removing the IMU
* Removing watchdog circuitry, because historical standard-profile launches have not shown frequent anomalies that would make a watchdog critical, let alone problems that would be solved by the watchdog as it was implemented in Gen 4.2
* Forgoing power select circuitry for a simple switch 

== Testing ==
The boards are set to be assembled and tested during the fall of the 2018/19 academic year, with a first launch planned for Winter 2019.

== Issues ==
The inclusion of the SiLabs radio may be adding unnecessary complexity that is best deferred to an expansion board.

== PCB Layout ==
Gen 5 Avionics remains a 4-layer board, compliant with Gen 2 Architecture. All signals were routed on the top and bottom layers, while only the heater trace went beyond those two layers. While it may be possible to route the heater trace on the top and bottom layer, it will be much more difficult, if impossible, to apply the traces directly to the components which require heat, such as the GPS and MCU.

Balloons Gen 3 BMS

2018-07-15T04:50:03Z

Vnguyen5:

{{HABEES-sidebar
| header = Cupcake
| img link = File:appleturnover.png
| designer = Zachary Belateche
| techline = Balloons Core Power
| version = Generation III
| name = Cupcake
}}

[[Category: High Altitude Balloons]][[Category: HABEES]]

'''Cupcake''' is the 3rd iteration of the '''B'''attery '''M'''anagement '''S'''system for the HABEES Standard Avionics Platform. It addresses the complexity issue of the previous generation by removing the data collection circuitry/microcontroller, and adding a separate power path for expansion boards. It is compliant with the Gen 2 Architecture. 

Outputs: 

* Main Avionics Power Path
** 3.3V, 5V
* Expansion Board Power Path
** 1.8V, 3.3V, 5V
* Shared raw cell voltage (VBAT) 

Features of each power path: 
* Voltage and Current Protector (Undervoltage 3V, Overvoltage 5V, Overcurrent 5A)
* Buckboost for 5V and LDO (low dropout regulator) for 3.3V 

Additional features:
* Temperature Monitor (Overtemp 50C, Heater activated at -10C)
* inboard heater
* Status LEDs for charging indicator and faults

Balloons Gen 3 BMS

2018-07-15T04:48:24Z

Vnguyen5: Created page with "'''Cupcake''' is the 3rd iteration of the '''B'''attery '''M'''anagement '''S'''system for the HABEES Standard Avionics Platform. It addresses the complexity issue of the prev..."

'''Cupcake''' is the 3rd iteration of the '''B'''attery '''M'''anagement '''S'''system for the HABEES Standard Avionics Platform. It addresses the complexity issue of the previous generation by removing the data collection circuitry/microcontroller, and adding a separate power path for expansion boards. It is compliant with the Gen 2 Architecture. 

Outputs: 

* Main Avionics Power Path
** 3.3V, 5V
* Expansion Board Power Path
** 1.8V, 3.3V, 5V
* Shared raw cell voltage (VBAT) 

Features of each power path: 
* Voltage and Current Protector (Undervoltage 3V, Overvoltage 5V, Overcurrent 5A)
* Buckboost for 5V and LDO (low dropout regulator) for 3.3V 

Additional features:
* Temperature Monitor (Overtemp 50C, Heater activated at -10C)
* inboard heater
* Status LEDs for charging indicator and faults

File:Gen5bms s.PNG

2018-07-15T04:34:34Z

Vnguyen5: Cupcake PCB layout

Cupcake PCB layout

Balloons Gen 5 Avionics

2018-07-15T04:25:49Z

Vnguyen5: Created page with "{{HONEY-sidebar | header = Kermit | img link = File:Gen5s.PNG | designer = Vinh Nguyen | techline = Balloons Core Avionics | version = Generation V | name = Kermit }} '''Kermi..."

{{HONEY-sidebar
| header = Kermit
| img link = File:Gen5s.PNG
| designer = Vinh Nguyen
| techline = Balloons Core Avionics
| version = Generation V
| name = Kermit
}}
'''Kermit''' is the fifth revision of the HABEES Standard Avionics Platform. It implements most of the functionality that exists in Gen 4 rev 2 Avionics, but the architecture of the boards has been changed, and functionality removed to reduce the complexity of implementation and application of the flight stack. 

Kermit provides the following flight critical systems features: 

* A Teensy 3.6 embedded Microcontroller
* A ublox-M8Q GNSS (GPS/GLONASS/Beidou/Galileo) receiver with embedded patch antenna
* MicroSD data logging
* A thermocouple for external temperature sensing
* Two BMP280 pressure/temperature sensors
* A PWM-operated cutdown FET
* An inboard heater
* Power, CAN, and data bus connectors
* 8 RGB indicator LED's about various system states
* A power-selector to enable 5V operation from BMS or USB
* CAN Transceiver for use with the HONEY CAN bus
* Additional bypass capacitors
* Current sensors for GPS and Cutdown 

Notable differences from the previous generation include:
* SiLabs 4463 Radio, the same used as Valbal v9. 
This provides a higher bandwidth data link for use by expansion boards so that future applications need only generate data and send it to main avionics.
* Connector for Iridium RockBlock module 
An embedded module proved to be too difficult to implement in the previous revision, while not providing significant benefit over using the out-of-the-box RockBlock module + connector alternative.

== Development ==
Given the difficulty that was experienced in assembling and testing the previous generation of standard avionics, the current generation was built with the primary goal in mind of reducing the complexity and producing a system whose core functionality is easier to realize and least liable to fail after assembly (given that most likely avionics must be manually assembled and debugged).
Several changes were made from Rev 4.2 in order to reduce the complexity: 
* The data bus was split into two, and the number of pins broken out was reduced only to the number of GPIOs free after all avionics systems, simplifying routing and reducing the number of pins.
**
* Abandoning an embedded RockBlock, which required dedicated power circuitry and a very large footprint which required incredibly dense packing and clever routing to accommodate the rest of the system
* Removing auxiliary heater FETs
* Removing some current sensors, because power consumption data for its own sake is not considered a priority for standard-profile launches
* Removing the second, excessive CAN bus
* Removing the IMU
* Removing watchdog circuitry, because historical standard-profile launches have not shown frequent anomalies that would make a watchdog critical, let alone problems that would be solved by the watchdog as it was implemented in Gen 4.2
* Forgoing power select circuitry for a simple switch 

== Testing ==
The boards are set to be assembled and tested during the fall of the 2018/19 academic year, with a first launch planned for Winter 2019.

== Issues ==
The inclusion of the SiLabs radio may be adding unnecessary complexity that is best deferred to an expansion board.

== PCB Layout ==
Gen 5 Avionics remains a 4-layer board. All signals were routed on the top and bottom layers, while only the heater trace went beyond those two layers. While it may be possible to route the heater trace on the top and bottom layer, it will be much more difficult, if impossible, to apply the traces directly to the components which require heat, such as the GPS and MCU.

File:Gen5s.PNG

2018-07-15T04:25:21Z

Vnguyen5: PCB Layout of Gen5 Avionics.

PCB Layout of Gen5 Avionics.

PlatformIO

2018-07-07T19:36:50Z

Vnguyen5: /* Instalation */

{{guide| authors=John Dean ({{slack-user|johndean}})}}

==Background==

[http://platformio.org/ PlatformIO] is an open source Integrated Development Environment (IDE) for programming microcontrollers (like arduino) and embedded systems. For our purposes, we mainly use it to write software for the [https://www.pjrc.com/store/teensy32.html Teensy 3.2 Microcontoller]. In the past, we previously had used the easy to set up [https://www.arduino.cc/en/Guide/Environment Arduino IDE], however it has many drawbacks and lacks many of the features of a full IDE.

==Installation==

To install the PlatformIO IDE, follow the installation steps on [http://docs.platformio.org/en/latest/ide/atom.html#installation the PlatformIO website]

There are a fair number of steps to follow if you do not have any of the software that PlatformIO incorporates, but it should be fairly straightforward.

'''OS X Users:''' due to a a problem with the program that loads your compiled code to the teensy on OS X, you will need to used a custom executable file in place of the original.
''there will be more added here later''

==Usage Guide==

To get started in PlatformIO, follow the [http://docs.platformio.org/en/latest/ide/atom.html#quick-start PlatformIO Quickstart tutorial]

===Library Dependencies===

If you used the Ardiuno IDE, you will be used to having an folder on your computers where you install libraries. If you downloaded a project from the internet that needed a bunch of new libraries, you would have to install all of them manually. Thankfully, with PlatformIO, you no longer have to worry about this. Dependencies for libraries are added to the <code>platformio.ini</code> file with a github link, so that they are automatically downloaded if you do not already have them on your computer.

For information on exactly how to set it up, follow [http://docs.platformio.org/en/latest/librarymanager/index.html?highlight=libraries this guide]

[[Category:Raccoonworks]]
[[Category:Getting started]]

Balloons Gen 1 Radio

2017-06-22T05:48:37Z

Vnguyen5: Created page with "'''Macaw''' is the first generation of a VHF/UHF transmit/receive board for Balloons Core Avionics. The purpose of the radio board is to provide an alternate means of transmit..."

'''Macaw''' is the first generation of a VHF/UHF transmit/receive board for Balloons Core Avionics. The purpose of the radio board is to provide an alternate means of transmitting payload vitals to the ground, in addition to RockBlock (which requires buying credits to transmit data). In addition, the radio board provides a much higher data rate than Iridium, which can be used to transmit payload vitals more often, and larger data (such as images or video).

== Design ==
Macaw has three DORJI radios, which can be either DRA818Vs (which can transmit from 134MHz to 174MHz in the Very High Frequency(VHF) Band) or DRA818Us (which can transmit from 400-470MHz in the Ultra High Frequency (UHF) Band). Each radio also has a current sensor to monitor the amount of current being drawn from that radio. In Macaw all functionalities of the DORJI radios are supported, which means that any of the radios can be transmit or receive radios, and VHF or UHF radios, although one is designated as the APRS radio (Automatic Packet Reporting System), and the other two are designated as VHF Transmit and VHF Receive. The APRS radio is responsible for transmitting the payload vitals to the ground, while the other two are reserved for higher data-rate applications; however, in the board the hardware for each radio is identical and any VHF radio can transmit or receive any data.

== Schematics ==

<gallery widths=200px heights=200px>
File:HAB_Macaw_TopSheet.PNG | <center> Top Sheet </center>
File:HAB_Macaw_APRS.PNG | <center> Radio 1/APRS </center>
File:HAB_Macaw_VHFRX.PNG | <center> Radio 2/RX </center>
File:HAB_Macaw_VHFTX.PNG | <center> Radio 3/TX </center>
File:HAB_Macaw_StackBus.PNG | <center> Stackbus Connections </center>
File:HAB_Macaw_PCB.PNG | <center> PCB Layout </center>
File:Macaw.jpg | <center> Assembled </center>
</gallery>

== Pinout ==
-APRS = Radio 1; Bottom

-VHFRX = Radio 2; Middle

-VHFTX = Radio 3; Top

Serial Ports: The communication interface between the radio and the microcontroller; used to set settings (ie transmit frequency). RX here is in the frame of the Teensy (MCU RX; radio TX).

{| class="wikitable"
|Pin
|APRS
|VHFRX
|VHFTX
|-
|RX
|7(RX3)
|9
|0
|-
|TX
|8 (TX3)
|10
|1
|}

MIC(Microphone): The signal input to the radio transmitter.
{| class="wikitable"
|Pin
|APRS
|VHFRX
|VHFTX
|-
|
|DAC/A14
|22/A8
|32
|}

PTT (Push-To-Talk): The signal which enables or disables transmission
{| class="wikitable"
|Pin
|APRS
|VHFRX
|VHFTX
|-
|
|6
|13
|25
|}

AF_OUT (Audio Out): The output of the radio receiver.
{| class="wikitable"
|Pin
|APRS
|VHFRX
|VHFTX
|-
|
|14/A0
|17/A3
|28/A17
|}

SQ:(Squelch): Signal for setting the squelch level (threshold for suppressing noise in received signals)
{| class="wikitable"
|Pin
|APRS
|VHFRX
|VHFTX
|-
|
|5
|12
|16/A2
|}

PD/SLP (Sleep): Signal for setting the radio to low power mode
{| class="wikitable"
|Pin
|APRS
|VHFRX
|VHFTX
|-
|
|20/A6
|23/A9
|15/A1
|}

RFPWR (RF Power): Signal for setting the radio to .5W output power or 1W output power
{| class="wikitable"
|Pin
|APRS
|VHFRX
|VHFTX
|-
|
|21/A7
|19/A5
|27/A16
|}

EN (Enable): Signal for driving a FET switch to power or unpower each radio (radio is powered if this is LOW)
{| class="wikitable"
|Pin
|APRS
|VHFRX
|VHFTX
|-
|
|2
|11
|18/A4
|}

Other
System Flags

LOW PWR (Flag from Main Avionics for asserting Low Power Mode)- 24

System Ready (Flag from Main Avionics for enabling startup) - A10

F3- A11

F4- A12

F5- A13

I2C

SCL - 29/A18

SDA - 30/A19

CHIRP (Serial Communication with Main Avionics). Uses the alternate pins for HWSerial 2 on the Teensy 3.2. Radio 2 Serial will be disabled during use.

RX- 26/A15 (RX2 Alt)

TX- 31/A20 (TX2 Alt)

== Issues and Future Design Ideas ==
• '''Number and Kind of Radios'''

One issue with having three VHF radios on one board is the potential for one to interfere with the others if the transmit and receive frequencies are too near one another (crosstalk). A filter between the antenna and radio could solve this, however it requires additional space and components. If interference is significant then a receiving radio would not be able to receive while another is transmitting. In effect this would be no different than having one radio operating half-duplex; components, space, and pins could be saved by removing one radio entirely; the second radio could be changed to UHF. Additional pins and board space allows for more interfacing with the main avionics and other functionality, such as data logging or image/video recording.

[[Category: High Altitude Balloons]]

File:Macaw.jpg

2017-06-22T05:47:23Z

Vnguyen5: Assembled radio board

Assembled radio board

File:HAB Macaw PCB.PNG

2017-06-22T05:43:56Z

Vnguyen5: PCB Layout for Macaw.

PCB Layout for Macaw.

File:HAB Macaw VHFTX.PNG

2017-06-22T05:37:02Z

Vnguyen5: Schematic showing the connections to the third Dorji radio.

Schematic showing the connections to the third Dorji radio.

File:HAB Macaw VHFRX.PNG

2017-06-22T05:36:33Z

Vnguyen5: Schematic of the connections to the second Dorji radio.

Schematic of the connections to the second Dorji radio.

File:HAB Macaw TopSheet.PNG

2017-06-22T05:35:48Z

Vnguyen5: Main schematic of Macaw.

Main schematic of Macaw.

File:HAB Macaw Stackbus.PNG

2017-06-22T05:34:45Z

Vnguyen5: Avionics Stackbus connections for Macaw

Avionics Stackbus connections for Macaw

File:HAB Macaw APRS.PNG

2017-06-22T05:34:10Z

Vnguyen5: Schematic of the APRS Radio on Macaw.

Schematic of the APRS Radio on Macaw.

Template:Balloon-sidebar

2017-06-22T04:04:11Z

Vnguyen5:

{| class="wikitable" style="float:right; margin-left: 10px; font-size:85%;max-width:250px; text-align:center"
{{red-header|size=150}}High Altitude Balloons
|-
| Part of the [[High Altitude Balloons Team | High Altitude Balloons]] series
|-
{{red-header}} Team Goals
|-
| [[Altitude Control]] • [[Balloon Research | Research]]
|-
{{red-header}} Balloon Culture & Tradition
|-
| [[Balloons Culture | What Is it?]] • [[Balloons Breakfast | Breakfast]] • [[Balloons Lunch | Lunch]] • [[Balloon Release | Release]] • [[Balloon Bonfires | Bonfires]] • [[Overnight Launches]]
|-
{{red-header}} Important Concepts
|-
| [[Balloon Mechanics]] • [[Atmospheric Conditions]] • [[Altitude Control]] • [[GPS Flight Mode]] • [[Heating & Thermal]] • [[Communications]]
|-
{{red-header}} Core Architecture
|-
| [[Gen 1 Architecture | Gen 1 Architecture]] • [[Gen 2 Architecture | HONEY]]
|-
{{red-header}} Core Software
|-
| [[Gen 1 Software | STINGR ]]
|-
{{red-header}} Core Avionics
|-
| [[Balloon Gen 1 Avionics | Oscar]] • [[Balloon Gen 2 Avionics | Cookie Monster]] • [[Medusa | Medusa]] • [[Balloons Gen 3 Avionics | Elmo]] • [[Balloons Gen 4 Avionics | The Count]] • [[Balloons Gen 1 Radio | Macaw]]
|-
{{red-header}} Core Power
|-
| [[Balloon Gen 1 BMS | Apple Turnover]]• [[Balloon Gen 2 BMS | Biscuit]]
|-
{{red-header}} ValBal Avionics
|-
| [[VB Gen 1 Avionics | Gen 1]] • [[VB Gen 2 Avionics | Gen 2]] • [[VB Gen 3 Avionics | Gen 3]] • [[VB Gen 4 Avionics | Gen 4]]
|-
{{red-header}} ValBal
|-
| [[ValBal Mk 1 | Mk 1 (adVENTurer)]] • [[ValBal Mk 2 | Mk 2 (VENTuri)]] • [[ValBal Mk 3 | Mk 3 (Voyager)]] • [[ValBal Mk 4 | Mk 4 (Ivy)]]
|-
{{red-header}} Projects
|-
| [[Project Sol | Sol]] • [[Project UV | UV]] • [[Project X | X]] • [[Project SPACE | SPACE]] • [[Project habmc | habmc]] • [[Project HABEES | HABEES]]
|-
{{red-header}} Lore & Chronicles
|-
| [[The Puerto Rico Incident]] • [[The Surprise Equilibration]] • [[The Mountain Climbers]] • [[The Little ZPB That Could]] • [[The Balcony Bonanza]]
|-
{{red-header}} Launch Sites
|-
| [[Laird Park]] • [[Brigantino Park]]
|-
{{red-header|textalign=right}} [[Template:Balloon-sidebar | V]] • [http://wiki.stanfordssi.org/index.php?title=Template:Balloon-sidebar&action=edit E] 
|}

Template:Balloon-sidebar

2017-06-22T04:03:23Z

Vnguyen5:

{| class="wikitable" style="float:right; margin-left: 10px; font-size:85%;max-width:250px; text-align:center"
{{red-header|size=150}}High Altitude Balloons
|-
| Part of the [[High Altitude Balloons Team | High Altitude Balloons]] series
|-
{{red-header}} Team Goals
|-
| [[Altitude Control]] • [[Balloon Research | Research]]
|-
{{red-header}} Balloon Culture & Tradition
|-
| [[Balloons Culture | What Is it?]] • [[Balloons Breakfast | Breakfast]] • [[Balloons Lunch | Lunch]] • [[Balloon Release | Release]] • [[Balloon Bonfires | Bonfires]] • [[Overnight Launches]]
|-
{{red-header}} Important Concepts
|-
| [[Balloon Mechanics]] • [[Atmospheric Conditions]] • [[Altitude Control]] • [[GPS Flight Mode]] • [[Heating & Thermal]] • [[Communications]]
|-
{{red-header}} Core Architecture
|-
| [[Gen 1 Architecture | Gen 1 Architecture]] • [[Gen 2 Architecture | HONEY]]
|-
{{red-header}} Core Software
|-
| [[Gen 1 Software | STINGR ]]
|-
{{red-header}} Core Avionics
|-
| [[Balloon Gen 1 Avionics | Oscar]] • [[Balloon Gen 2 Avionics | Cookie Monster]] • [[Medusa | Medusa]] • [[Balloons Gen 3 Avionics | Elmo]] • [[Balloons Gen 4 Avionics | The Count]] • [[Balloon Gen 1 Radio | Macaw]]
|-
{{red-header}} Core Power
|-
| [[Balloon Gen 1 BMS | Apple Turnover]]• [[Balloon Gen 2 BMS | Biscuit]]
|-
{{red-header}} ValBal Avionics
|-
| [[VB Gen 1 Avionics | Gen 1]] • [[VB Gen 2 Avionics | Gen 2]] • [[VB Gen 3 Avionics | Gen 3]] • [[VB Gen 4 Avionics | Gen 4]]
|-
{{red-header}} ValBal
|-
| [[ValBal Mk 1 | Mk 1 (adVENTurer)]] • [[ValBal Mk 2 | Mk 2 (VENTuri)]] • [[ValBal Mk 3 | Mk 3 (Voyager)]] • [[ValBal Mk 4 | Mk 4 (Ivy)]]
|-
{{red-header}} Projects
|-
| [[Project Sol | Sol]] • [[Project UV | UV]] • [[Project X | X]] • [[Project SPACE | SPACE]] • [[Project habmc | habmc]] • [[Project HABEES | HABEES]]
|-
{{red-header}} Lore & Chronicles
|-
| [[The Puerto Rico Incident]] • [[The Surprise Equilibration]] • [[The Mountain Climbers]] • [[The Little ZPB That Could]] • [[The Balcony Bonanza]]
|-
{{red-header}} Launch Sites
|-
| [[Laird Park]] • [[Brigantino Park]]
|-
{{red-header|textalign=right}} [[Template:Balloon-sidebar | V]] • [http://wiki.stanfordssi.org/index.php?title=Template:Balloon-sidebar&action=edit E] 
|}