Changes

{{tech-sidebar

{{HONEY-sidebar

| header = HONEY

| header = HONEY Architecture

| img link = File:HONEy.jpg

| img link = File:HONEY2.jpg

| designer = Kirill Safin

| designer = Kirill Safin

| techline = Balloons Core Architecture

| techline = Balloons Core Architecture

| version = Generation II

| version = Generation II

| name = HONEY

| name = HONEY

| missions = SSI-52 onward

| 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.  

'''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.  

The HONEY specification is outlined below in exhaustive detail, and the bottom of the page lists implementations required by any board utilizing the HONEY architecture.

The HONEY specification is outlined below in exhaustive detail, and the bottom of the page lists implementations required by any board utilizing the HONEY architecture.

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 10-pin (5x2) connector for the flight stack power bus, a 6-pin (3x2) connector for the flight stack CAN bus, and an 8 pin (4x2) connector (NON stack through) for holding jumpers for implementing CAN terminating impedances. These connectors are not physically located on the board in a whole-number fashion, but must be implemented with exact precision to allow for proper stack-through ability. The PC/104+ connector also comes with a paired shroud that clips onto the board via four through-holes, which, while not strictly required for operation, is highly encouraged and is part of the stack-up Altium part. Boards are expected to not exceed their boundaries by more than 0.25". The flight stack has 0.5" of space around it, between its outer dimensions and the walls of the payload container.

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 10-pin (5x2) connector for the flight stack power bus, a 6-pin (3x2) connector for the flight stack CAN bus, and an 8 pin (4x2) connector (NON stack through) for holding jumpers for implementing CAN terminating impedances. These connectors are not physically located on the board in a whole-number fashion, but must be implemented with exact precision to allow for proper stack-through ability. The PC/104+ connector also comes with a paired shroud that clips onto the board via four through-holes, which, while not strictly required for operation, is highly encouraged and is part of the stack-up Altium part. Boards are expected to not exceed their boundaries by more than 0.25". The flight stack has 0.5" of space around it, between its outer dimensions and the walls of the payload container.

The connectors and hardware used in each case are:

The connectors and hardware used in each case can be found on the [[HONEY_Standardized_Connectors|HONEY Standardized Connectors Page]]

* Data Bus: Harwin M22-6003005

* Data Bus: Harwin M22-6003005

* Data Bus Shroud: Harwin M22-6043098

* Data Bus Shroud: Harwin M22-6043098

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 Biscuit, and the following will be written with the Biscuit specifications.

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 Biscuit, and the following will be written with the Biscuit specifications.

The power bus provides a +5V supply, with a flight-stack current limit of 4A -- this voltage should be used for devices that specifically require 5 volts (such as Iridium), or in many cases for more localized and low-noise voltage regulation on individual boards (i.e. LDO'ing the 5V to 3.3V for a local Teensy).  

The power bus provides a +5V supply, with a flight-stack current limit of 4A -- this voltage should be used for devices that specifically require 5 volts (such as Iridium), or in many cases for more localized and low-noise voltage regulation on individual boards (i.e. LDO'ing the 5V to 3.3V for a local Teensy).  

The power bus also provides two utility regulators -- 1.8V for specific 1.8V applications for some specialty IC's (250 mA limit), and an adjustable buck that regulates to a voltage between 0V and 5V, as dictated by the Avionics. The Avionics is solely responsible for regulating the adjustable voltage, using the VA_PWM pin on the data bus -- if your board necessitates an adjustable voltage, it must request the adjustment via the avionics, which will either accept or deny the request, and act accordingly.  

The power bus also provides two utility regulators -- 1.8V for specific 1.8V applications for some specialty IC's (250 mA limit), and an adjustable buck that regulates to a voltage between 0V and 5V, as dictated by the Avionics. The Avionics is solely responsible for regulating the adjustable voltage, using the VA_PWM pin on the data bus -- if your board necessitates an adjustable voltage, it must request the adjustment via the avionics, which will either accept or deny the request, and act accordingly.  

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

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 ===

=== Data Bus ===

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 number of pins will, in the future, become tertiary power pins for advanced BMS applications. These will likely occupy the bottom of the data bus. Pins on the data bus are to be occupied on a top-down basis, filling from top-down and left-right, with the exception of RESERVED pins that are amidst dedicated pins, which are strictly reserved for possible future flight-critical services.

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 number of pins will, in the future, become tertiary power pins for advanced BMS applications. These will likely occupy the bottom of the data bus. Pins on the data bus are to be occupied on a top-down basis, filling from top-down and left-right, with the exception of RESERVED pins that are amidst dedicated pins, which are strictly reserved for possible future flight-critical services.

|NO

|NO

|-

|-

|29-36, 38-41

|29-36, 38-40

|IO/1 - IO/13

|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).

|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

|NO

|-

|-

|37, 42-111, 113-120

|37, 42-111, 117-120

|NC

|NC

|Reserved -- these can be used for any purpose at the time being, as long as it is agreed in advance.

|Reserved -- these can be used for any purpose at the time being, as long as it is agreed in advance.

|IO/12

|IO/12

|-

|-

|IO/13

|BLUEJ_PRESENT

|RESERVED

|RESERVED

|RESERVED

|RESERVED

|RESERVED

|RESERVED

|-

|-

|RESERVED

|RB_TX -->

|RESERVED

|RB_RX <--

|RESERVED

|RB_NETAV

|RESERVED

|RB_SLP

|-

|-

|RESERVED

|RB_RI

|RESERVED

|RB_EN

|RESERVED

|RESERVED

|RESERVED

|RESERVED

|RESERVED

|RESERVED

|-

|-

|RESERVED

|12V

|RESERVED

|12V

|RESERVED

|12V

|RESERVED

|12V

|-

|-

|RESERVED

|RESERVED

|CAN_SPD

|CAN_SPD

|-

|-

|RESERVED

|Pos 5V (SIG)

|RESERVED

|Neg 5V (SIG)

|RESERVED

|Pos 12V (SIG)

|RESERVED

|Neg 12V (SIG)

|-

|-

|RESERVED

|RESERVED

=== CAN BUS ===

=== CAN BUS ===

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.  

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.  

|-

|-

|2_TERM_1

|2_TERM_1

|2_TERM_21

|2_TERM_2

|-

|-

|NC

|NC

|NC

|NC

|}

|}

== Implementation ==

== Implementation ==

#Make sure +3.3_CAN is used only to power the transceiver, and nothing else.  

#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.

#Make sure CAN_SPD is hard-wired to the transceiver speed pin.