Changes

Jump to navigation Jump to search

Gen 2 Architecture (view source)

Revision as of 22:41, 31 August 2017

6,017 bytes added ,  22:41, 31 August 2017
→‎Data Bus
Line 1: Line 1: −
{{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.
Line 18: Line 18:  
=== Board Specification ===
 
=== 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.
 
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.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 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
Line 80: Line 82:     
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.
 +
 +
[[File:pbus.JPG | right| thumb | <center> Power Bus Pin-Out </center>]]
    
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).  
Line 89: Line 93:  
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 ===
 +
 +
 +
[[File:dbus_top.JPG | right| thumb | <center> Data Bus Top </center>]]
 +
[[File:dbus_bottom.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 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.
Line 184: Line 192:  
|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
 +
|-
 +
|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
 
|NO
 
|-
 
|-
−
|37, 42-111, 113-120
+
|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
 
|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.
Line 253: Line 286:  
|IO/12
 
|IO/12
 
|-
 
|-
−
|IO/13
+
|BLUEJ_PRESENT
 
|RESERVED
 
|RESERVED
 
|RESERVED
 
|RESERVED
Line 303: Line 336:  
|RESERVED
 
|RESERVED
 
|-
 
|-
−
|RESERVED
+
|RB_TX -->
−
|RESERVED
+
|RB_RX <--
−
|RESERVED
+
|RB_NETAV
−
|RESERVED
+
|RB_SLP
 
|-
 
|-
−
|RESERVED
+
|RB_RI
−
|RESERVED
+
|RB_EN
 
|RESERVED
 
|RESERVED
 
|RESERVED
 
|RESERVED
Line 333: Line 366:  
|RESERVED
 
|RESERVED
 
|-
 
|-
−
|RESERVED
+
|12V
−
|RESERVED
+
|12V
−
|RESERVED
+
|12V
−
|RESERVED
+
|12V
 
|-
 
|-
 
|RESERVED
 
|RESERVED
Line 343: Line 376:  
|CAN_SPD
 
|CAN_SPD
 
|-
 
|-
−
|RESERVED
+
|Pos 5V (SIG)
−
|RESERVED
+
|Neg 5V (SIG)
−
|RESERVED
+
|Pos 12V (SIG)
−
|RESERVED
+
|Neg 12V (SIG)
 
|-
 
|-
 
|RESERVED
 
|RESERVED
Line 355: Line 388:     
=== CAN BUS ===
 
=== 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.  
 
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.  
   Line 394: Line 429:  
|-
 
|-
 
|2_TERM_1
 
|2_TERM_1
−
|2_TERM_21
+
|2_TERM_2
 
|-
 
|-
 
|NC
 
|NC
Line 402: Line 437:  
|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 ==
 
== 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.
 
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]]
Retrieved from "https://ssi-wiki.stanford.edu/Special:MobileDiff/2459...2961"

Navigation menu