700
edits
Changes
Jump to navigation
Jump to search
Line 58:
Line 58: − + + + + Line 75:
Line 78: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 231:
Line 355: + + + + + + + + Line 244:
Line 376: + + + + + + +
→Electrical Specifications
== Electrical Specifications ==
== 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. The pinouts for the various buses are as follows:
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 ===
=== Power Bus ===
The power bus pin-out is as follows:
{| class="wikitable"
{| class="wikitable"
|-
|-
|GND
|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 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 +3.3V supply, with a flight-stack current limit of 1A -- this voltage should be used for powering most low-power logic-level devices, and in many cases embedded Teensies as well. At time of writing, Biscuit is still being brought to operating state, and all FTC's are advised to either regulate 3.3V locally, or have a switch for selecting between BUS +3.3 and local +3.3 -- this is done on Macaw, which can be looked at as an example. Ideally, all +3.3 devices run on the BMS supplied +3.3V.
The power bus also provides raw cell voltage +VBATT -- 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 VBATT 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).
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.
=== 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.
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-41
|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).
|NO
|-
|37, 42-111, 113-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"
{| class="wikitable"
|-
|-
=== 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.
Every board, except in very extenuating circumstances, is required to implement the CAN bus.
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.
{| class="wikitable"
{| class="wikitable"
|-
|-
=== CAN Terminating Jumpers ===
=== 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.
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"
{| class="wikitable"
|-
|-