https://ssi-wiki.stanford.edu/w/api.php?action=feedcontributions&user=Ksafin&feedformat=atomStanford SSI Wiki - User contributions [en]2024-03-29T01:41:55ZUser contributionsMediaWiki 1.35.0https://ssi-wiki.stanford.edu/w/index.php?title=Balloons_Gen_1_TestBench&diff=3250Balloons Gen 1 TestBench2017-09-28T21:15:08Z<p>Ksafin: /* HONEY Pin Out */</p>
<hr />
<div>{{HONEY-sidebar<br />
| header = QueenBee<br />
| designer = Kirill Safin<br />
| img link = File:QueenBee1.jpg<br />
| techline = Balloons TestBench<br />
| version = Generation I<br />
| name = QueenBee<br />
}}<br />
<br />
'''QueenBee''' is the first generation HONEY TestBench. QueenBee provides a number of utilities that allow for extensive & straightforward testing of new HONEY compliant boards, and for the prototyping of new designs & features on a breadboard, with access to the HONEY power, data, and CAN buses. <br />
<br />
== Operation ==<br />
QueenBee has a number of features and functions, but can be broken down into a few discrete sections<br />
* Stack Fixture<br />
* DUT (Device Under Test) Fixture<br />
* Breadboard<br />
* HONEY Pin Out<br />
* QueenBee Pin Out<br />
* Venom Breakout<br />
* 5" assistive display<br />
* Teensy 3.2 Socket + microSD logger + Pin Out<br />
* Teensy 3.6 QueenBee Master Computer<br />
* Power Inputs & Power Regulation<br />
* LED Indicators<br />
<br />
These sections will be discussed individually in more depth below.<br />
<br />
=== HONEY Fixtures ===<br />
QueenBee comes with two fixtures -- one called the Stack Fixture and one called the DUT Fixture. The Stack Fixture, the right of the two fixtures, is meant to accept a multi-board HONEY flight stack. This is meant to be the exact flight stack you intend to fly your board with -- to best mimic the exact electrical connections and software your board will interact with.<br />
<br />
The left fixture, called the DUT Fixture, is meant to accept your board, in this case, the DUT, or "Device Under Test" -- this fixture is meant to hold one board and one board only (although, electrically speaking, it can accept any number of boards). <br />
<br />
By breaking the flight stack into two sets of boards -- yours, and everything else -- you will have the flexibility to more easily debug your board for issues -- both software and electrical. Having your board be totally visible allows for easy probing and scoping for electrical debugging, access to any possible buttons, jumpers, connectors, etc, that your board may have, and more. <br />
<br />
It also permits altering the primary flight stack quickly & easily (by taking boards out and putting boards in) without swapping your board out or in. This can allow debugging possible conflicts you might have with specific boards, by swapping them in and out.<br />
<br />
=== HONEY Pin Out ===<br />
To the left of the DUT Fixture, one can find the HONEY Pin Out. This faithfully replicates the HONEY power, data, and CAN buses to the exact pin number of each pin, but with standard pitch to allow for using jumper cables. That is, the entire 4x30 data bus, which is normally 2.00mm PC/104+, is now available in 4x30 2.54mm standard headers. You can use this as a faithful reference to see the exact pin mapping of the actual HONEY data bus, and to probe and scope specific lines, as well as use this pinout in conjunction with the breadboard to develop and testing a new project.<br />
<br />
The Power Bus, Data Bus, and CAN Bus are all found separately here, just as they would in an actual HONEY flight stack, and follow the same pinout.<br />
<br />
[[File:QueenBee2.jpg | right| thumb | <center> QueenBee on boot-up </center>]]<br />
[[File:QueenBee-SW.jpg | right| thumb | <center> QueenBee main screen </center>]]<br />
[[File:QueenBee-routing.png | right| thumb | <center> QueenBee routing job </center>]]<br />
<br />
=== Venom Breakout ===<br />
To the left of the breadboard, there are two Venom Breakouts -- this allows for the testing of ProtoBee's and other cabled assemblies in conjunction with the QueenBee TestBench.<br />
<br />
=== Teensy 3.2 Socket ===<br />
As with ProtoBee and Cobra, QueenBee comes with a socket fit for a Teensy 3.2. While a portion of QueenBee is dedicated to testing newly made HONEY boards, the other portion of it is dedicated to allowing the prototyping, development, and testing of new projects -- whether they end up on a ProtoBee, Cobra, or as an actual HONEY board. <br />
<br />
This prototyping/development portion of QueenBee is comprised of the Teensy 3.2 socket, micro SD data logger, Teensy Pin Out, and Breadboard. As with Cobra & Proto Bee, if you desire, you can insert a Teensy 3.2 into the socket to add an MCU to your project.<br />
<br />
The Teensy 3.2, as in Cobra & ProtoBee, has all of its pins broken out onto a set of headers, which you can easily tap with jumper wires and connect to your breadboard project. A microSD socket and CAN Transceiever are also included, to mimic ProtoBee/Cobra, and provide all the standard functionality available to a HONEY board.<br />
<br />
=== BreadBoard ===<br />
As already mentioned, the Breadboard is the key part of QueenBee dedicated to prototyping and developing new projects for the HONEY stack. At the immediete right of the breadboard are pinouts for the power bus, data bus, CAN bus, and Teensy 3.2 -- all of the things you'd generally have accessible to you in a ProtoBee, Cobra, or an actual HONEY board. Between all of these, you should be able to test & try anything you'd like.<br />
<br />
=== QueenBee Master Computer ===<br />
QueenBee is equipped with a Teensy 3.6 that serves as the master computer for the TestBench. This Teensy serves a variety of purposes. Firstly, it controls and drives a set of 24 status LED's that provide a very quick picture of the state of the flight stack. Secondly, it listens to the CAN Bus and is able to read and output all STINGR Gestures. Third, it can be connected to a PC, where it will dump a large log over Serial (112500 baud) of all of the CAN, Serial, etc data it sees. This can help with debugging.<br />
<br />
Fourth, and perhaps most useful, it drives and controls a large diagnostic 5" display found in the center of QueenBee, which has a number of useful functionalities, such as:<br />
* Giving diagnostic feedback about various signal/power lines<br />
* Outputting CAN messages directly to the display for you to see<br />
* Outputting the CHIRP messages to the screen for you to see<br />
* Showing the current pulled by the test fixture/breadboard on all power lines<br />
<br />
However, its power is enhanced when considering the QueenBee Pin Out -- a set of headers by the breadboard directly connected to the QueenBee computer. This stack of headers has a variety of pins on it -- analog pins, DACs, PWM pins, Serial UART pins, etc.<br />
<br />
In conjunction with the assistive display (which is touch screen), you can use any of these pins for debugging or testing your project. You can request QueenBee to provide a PWM voltage on a PWM output pin, act as a multimeter by sampling its analog pins, have it produce a sin wave (or other signals) using its DAC, and even function as a device to test your Serial connections with -- IE, it can output whatever it receives over one of its Serial pins, or whatever it sends, etc.<br />
<br />
By using the QueenBee pinout and the assistive display, you have at the tip of your hands (a sort of low end, but still cool) signal generator, multimeter, and UART decoder.<br />
<br />
=== Power Input & Regulation ===<br />
On QueenBee, you have the choice of either using an actual HONEY BMS in the Flight Stack for all of your power regulation needs (a good thing to do to test actual real implementations of your board as it will fly), or, alternatively, use an external power supply to power all operations.<br />
<br />
There are four inputs for external power from a power supply -- one for 4.2V, and one for 12V. These must be connected to two power supply outputs and common grounded at QueenBee.<br />
<br />
If using an external power supply, you must flip the "BMS PRESENT?" switch to "NO" to enable external power. '''Enabling external power while the BMS is connected may cause permanent damage to the BMS.''' <br />
<br />
There are two additional switches -- one to select whether the BMS is loaded with batteries (or, alternatively, whether to use the power supply to power the BMS) and one to select whether the flight stack has a 12V source (or, alternatively, whether to use the power supply).<br />
<br />
For the first switch ("BATTERIES PRESENT?"), if flipped to "YES", QueenBee assumes the BMS is loaded with the batteries that will be powering everything. If flipped to "NO", QueenBee will provide the power supply 4.2V to the barrel jack connector located by the Stack Fixture. One must then connect a barrel jack-to-alligator-clip connector to this jack, and connect the alligator clips to the battery terminals of the BMS. In this fashion, QueenBee will provide an external 4.2V to act as the batteries, but allow the flight stack BMS to conduct all power regulation.<br />
<br />
For the second switch ("PSU 12V?"), if flipped to "YES", QueenBee will use the attached 12V power supply for all 12V power rails. If flipped to "NO", QueenBee will assume a 12V supply is included in the flight stack -- and, if not, will leave the net floating.<br />
<br />
In the case that the "BMS PRESENT?" switch is set to "NO", QueenBee will use its onboard power regulation circuitry to provide all of the power for the flight fixture, DUT fixture, pin outs, and teensies. It is worth noting that QueenBee uses identical circuitry to Biscuit, the Gen 2 HAB BMS -- in this sense, you will get an accurate portrayal of power regulation to some extent.<br />
<br />
Post-power regulation, you may disable or enable any power line individually using the set of slide switches to the right of the QueenBee computer. This allows you to turn off supplies you don't need, supplies that are shorting, or resetting supplies to see if your board/project react appropriately to having certain power supplies reset or lost.<br />
<br />
=== LED Indicators ===<br />
At the very top right of QueenBee is a set of 24 LED's that provide feedback as to the state of a number of key variables. They indicate the nominality of various supply voltages, indicate the states of various HONEY system flags, and provide other visual feedback at a glance. They switch between being Green, Red, and off.<br />
<br />
[[Category: High Altitude Balloons]][[Category: HABEES]][[Category: HONEY]]</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Balloons_Gen_1_TestBench&diff=3249Balloons Gen 1 TestBench2017-09-28T21:14:15Z<p>Ksafin: </p>
<hr />
<div>{{HONEY-sidebar<br />
| header = QueenBee<br />
| designer = Kirill Safin<br />
| img link = File:QueenBee1.jpg<br />
| techline = Balloons TestBench<br />
| version = Generation I<br />
| name = QueenBee<br />
}}<br />
<br />
'''QueenBee''' is the first generation HONEY TestBench. QueenBee provides a number of utilities that allow for extensive & straightforward testing of new HONEY compliant boards, and for the prototyping of new designs & features on a breadboard, with access to the HONEY power, data, and CAN buses. <br />
<br />
== Operation ==<br />
QueenBee has a number of features and functions, but can be broken down into a few discrete sections<br />
* Stack Fixture<br />
* DUT (Device Under Test) Fixture<br />
* Breadboard<br />
* HONEY Pin Out<br />
* QueenBee Pin Out<br />
* Venom Breakout<br />
* 5" assistive display<br />
* Teensy 3.2 Socket + microSD logger + Pin Out<br />
* Teensy 3.6 QueenBee Master Computer<br />
* Power Inputs & Power Regulation<br />
* LED Indicators<br />
<br />
These sections will be discussed individually in more depth below.<br />
<br />
=== HONEY Fixtures ===<br />
QueenBee comes with two fixtures -- one called the Stack Fixture and one called the DUT Fixture. The Stack Fixture, the right of the two fixtures, is meant to accept a multi-board HONEY flight stack. This is meant to be the exact flight stack you intend to fly your board with -- to best mimic the exact electrical connections and software your board will interact with.<br />
<br />
The left fixture, called the DUT Fixture, is meant to accept your board, in this case, the DUT, or "Device Under Test" -- this fixture is meant to hold one board and one board only (although, electrically speaking, it can accept any number of boards). <br />
<br />
By breaking the flight stack into two sets of boards -- yours, and everything else -- you will have the flexibility to more easily debug your board for issues -- both software and electrical. Having your board be totally visible allows for easy probing and scoping for electrical debugging, access to any possible buttons, jumpers, connectors, etc, that your board may have, and more. <br />
<br />
It also permits altering the primary flight stack quickly & easily (by taking boards out and putting boards in) without swapping your board out or in. This can allow debugging possible conflicts you might have with specific boards, by swapping them in and out.<br />
<br />
=== HONEY Pin Out ===<br />
To the left of the DUT Fixture, one can find the HONEY Pin Out. This faithfully replicates the HONEY power, data, and CAN buses to the exact pin number of each pin, but with standard pitch to allow for using jumper cables. That is, the entire 4x30 data bus, which is normally 2.00mm PC/104+, is now available in 4x30 2.54mm standard headers. You can use this as a faithful reference to see the exact pin mapping of the actual HONEY data bus, and to probe and scope specific lines, as well as use this pinout in conjunction with the breadboard to develop and testing a new project.<br />
<br />
The Power Bus, Data Bus, and CAN Bus are all found separately here, just as they would in an actual HONEY flight stack, and follow the same pinout. <br />
<br />
=== Venom Breakout ===<br />
To the left of the breadboard, there are two Venom Breakouts -- this allows for the testing of ProtoBee's and other cabled assemblies in conjunction with the QueenBee TestBench.<br />
<br />
=== Teensy 3.2 Socket ===<br />
As with ProtoBee and Cobra, QueenBee comes with a socket fit for a Teensy 3.2. While a portion of QueenBee is dedicated to testing newly made HONEY boards, the other portion of it is dedicated to allowing the prototyping, development, and testing of new projects -- whether they end up on a ProtoBee, Cobra, or as an actual HONEY board. <br />
<br />
This prototyping/development portion of QueenBee is comprised of the Teensy 3.2 socket, micro SD data logger, Teensy Pin Out, and Breadboard. As with Cobra & Proto Bee, if you desire, you can insert a Teensy 3.2 into the socket to add an MCU to your project.<br />
<br />
The Teensy 3.2, as in Cobra & ProtoBee, has all of its pins broken out onto a set of headers, which you can easily tap with jumper wires and connect to your breadboard project. A microSD socket and CAN Transceiever are also included, to mimic ProtoBee/Cobra, and provide all the standard functionality available to a HONEY board.<br />
<br />
=== BreadBoard ===<br />
As already mentioned, the Breadboard is the key part of QueenBee dedicated to prototyping and developing new projects for the HONEY stack. At the immediete right of the breadboard are pinouts for the power bus, data bus, CAN bus, and Teensy 3.2 -- all of the things you'd generally have accessible to you in a ProtoBee, Cobra, or an actual HONEY board. Between all of these, you should be able to test & try anything you'd like.<br />
<br />
=== QueenBee Master Computer ===<br />
QueenBee is equipped with a Teensy 3.6 that serves as the master computer for the TestBench. This Teensy serves a variety of purposes. Firstly, it controls and drives a set of 24 status LED's that provide a very quick picture of the state of the flight stack. Secondly, it listens to the CAN Bus and is able to read and output all STINGR Gestures. Third, it can be connected to a PC, where it will dump a large log over Serial (112500 baud) of all of the CAN, Serial, etc data it sees. This can help with debugging.<br />
<br />
Fourth, and perhaps most useful, it drives and controls a large diagnostic 5" display found in the center of QueenBee, which has a number of useful functionalities, such as:<br />
* Giving diagnostic feedback about various signal/power lines<br />
* Outputting CAN messages directly to the display for you to see<br />
* Outputting the CHIRP messages to the screen for you to see<br />
* Showing the current pulled by the test fixture/breadboard on all power lines<br />
<br />
However, its power is enhanced when considering the QueenBee Pin Out -- a set of headers by the breadboard directly connected to the QueenBee computer. This stack of headers has a variety of pins on it -- analog pins, DACs, PWM pins, Serial UART pins, etc.<br />
<br />
In conjunction with the assistive display (which is touch screen), you can use any of these pins for debugging or testing your project. You can request QueenBee to provide a PWM voltage on a PWM output pin, act as a multimeter by sampling its analog pins, have it produce a sin wave (or other signals) using its DAC, and even function as a device to test your Serial connections with -- IE, it can output whatever it receives over one of its Serial pins, or whatever it sends, etc.<br />
<br />
By using the QueenBee pinout and the assistive display, you have at the tip of your hands (a sort of low end, but still cool) signal generator, multimeter, and UART decoder.<br />
<br />
=== Power Input & Regulation ===<br />
On QueenBee, you have the choice of either using an actual HONEY BMS in the Flight Stack for all of your power regulation needs (a good thing to do to test actual real implementations of your board as it will fly), or, alternatively, use an external power supply to power all operations.<br />
<br />
There are four inputs for external power from a power supply -- one for 4.2V, and one for 12V. These must be connected to two power supply outputs and common grounded at QueenBee.<br />
<br />
If using an external power supply, you must flip the "BMS PRESENT?" switch to "NO" to enable external power. '''Enabling external power while the BMS is connected may cause permanent damage to the BMS.''' <br />
<br />
There are two additional switches -- one to select whether the BMS is loaded with batteries (or, alternatively, whether to use the power supply to power the BMS) and one to select whether the flight stack has a 12V source (or, alternatively, whether to use the power supply).<br />
<br />
For the first switch ("BATTERIES PRESENT?"), if flipped to "YES", QueenBee assumes the BMS is loaded with the batteries that will be powering everything. If flipped to "NO", QueenBee will provide the power supply 4.2V to the barrel jack connector located by the Stack Fixture. One must then connect a barrel jack-to-alligator-clip connector to this jack, and connect the alligator clips to the battery terminals of the BMS. In this fashion, QueenBee will provide an external 4.2V to act as the batteries, but allow the flight stack BMS to conduct all power regulation.<br />
<br />
For the second switch ("PSU 12V?"), if flipped to "YES", QueenBee will use the attached 12V power supply for all 12V power rails. If flipped to "NO", QueenBee will assume a 12V supply is included in the flight stack -- and, if not, will leave the net floating.<br />
<br />
In the case that the "BMS PRESENT?" switch is set to "NO", QueenBee will use its onboard power regulation circuitry to provide all of the power for the flight fixture, DUT fixture, pin outs, and teensies. It is worth noting that QueenBee uses identical circuitry to Biscuit, the Gen 2 HAB BMS -- in this sense, you will get an accurate portrayal of power regulation to some extent.<br />
<br />
Post-power regulation, you may disable or enable any power line individually using the set of slide switches to the right of the QueenBee computer. This allows you to turn off supplies you don't need, supplies that are shorting, or resetting supplies to see if your board/project react appropriately to having certain power supplies reset or lost.<br />
<br />
=== LED Indicators ===<br />
At the very top right of QueenBee is a set of 24 LED's that provide feedback as to the state of a number of key variables. They indicate the nominality of various supply voltages, indicate the states of various HONEY system flags, and provide other visual feedback at a glance. They switch between being Green, Red, and off.<br />
<br />
[[Category: High Altitude Balloons]][[Category: HABEES]][[Category: HONEY]]</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Balloons_Gen_1_Breakout&diff=3248Balloons Gen 1 Breakout2017-09-28T21:13:35Z<p>Ksafin: </p>
<hr />
<div>{{HONEY-sidebar<br />
| header = Viper<br />
| img link = File:Viper.jpg<br />
| designer = Kirill Safin<br />
| techline = Balloons Breakouts<br />
| version = Generation I<br />
| name = Viper<br />
}}<br />
<br />
'''Viper''' is the first generation HONEY Breakout Board. Viper breaks out most of the important signal and power lines from the HONEY stack Data Bus & Power Bus, as well as the CAN Bus, to enable connecting to the HONEY flight stack remotely, over cable.<br />
<br />
As of August 10th, 2017, all HONEY flight stacks require Viper as the bottom-most (stack-terminating) board. This makes Viper a FCC (Flight Critical Component). This is both for physical and electrical reasons -- Viper is the only board with a non-stackthrough data bus, making it the choice for the bottom-most board. This was previously the BMS, due to the need for enough space for the battery pack -- however, the maximum spacing between flight stack boards has since increased to 20mm, allowing the BMS to be on the stack interior, and necessitating an alternate stack-terminating board -- Viper was chosen. Necessarily having Viper in a Flight Stack also guarantees any stack can be debugged using the master breakout, or expanded using payload breakouts.<br />
<br />
This enables two important capabilities, such as:<br />
* The Flight Stack can be broken into two compartments, and connected seamlessly via cable, continuing to act as one complete flight stack (unless there are relevant data bus signals that aren't broken out).<br />
* The Flight Stack can be broken out to an external payload, which, with the correct receiving connector, can have access to all of the stack data/power/signal lines. This enables using the HONEY flight stack for non-HONEY payloads -- such as ProtoBee's or similar projects.<br />
<br />
These functions, as well as a breakdown of the Viper Breakout Pinout, are explained below:<br />
<br />
== Pinout ==<br />
<br />
Viper comes with three connectors -- two "Payload Breakouts" and one "Master Breakout". They are discussed in detail below.<br />
<br />
=== Payload Breakout ===<br />
Viper has two Payload Breakout connectors -- this allows for the possibility of daisy chaining vertically or horizontally through the same flight stack. That is, you can "extend" the flight stack downward by having another flight stack below it, connected to the original flight stacks Viper boad, AND simultaneously extend the flight stack vertically, by adding a flight stack above the original flight stack, and connecting it to the other payload breakout. <br />
<br />
The Payload Breakout format (meaning, the particular connector, cabling) as well as the specific pinout, is called '''Venom Breakout'''.<br />
<br />
There is no need for more than two payload breakouts, with the expectation that all boards that receive the payload breakout also have a secondary connector to allow for continued daisy chaining. This is the case, for example, on ProtoBee.<br />
<br />
Details of the Venom Breakout can be found on the [[Venom_Breakout | Venom Breakout]] page.<br />
<br />
[[File: Viper2.png | right| thumb | <center> Viper Routing </center>]]<br />
<br />
=== Master Breakout ===<br />
In addition to the Venom Breakout, Viper also includes a larger, 56-pin 2.54mm (standard) pitch connector known as the Master Breakout -- or, more formally, the '''Fang Breakout'''.<br />
<br />
The ''Fang Breakout'' breaks out the remainder of what the Viper Breakout was unable to breakout, or what was deemed inessential for a payload to have access to. This includes the secondary CAN Bus and some additional avionics GPIO pins.<br />
<br />
[[Category:HONEY]]</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Balloons_Gen_1_Breakout&diff=3247Balloons Gen 1 Breakout2017-09-28T21:13:20Z<p>Ksafin: </p>
<hr />
<div>{{HONEY-sidebar<br />
| header = Viper<br />
| imglink = File:Viper.jpg<br />
| designer = Kirill Safin<br />
| techline = Balloons Breakouts<br />
| version = Generation I<br />
| name = Viper<br />
}}<br />
<br />
'''Viper''' is the first generation HONEY Breakout Board. Viper breaks out most of the important signal and power lines from the HONEY stack Data Bus & Power Bus, as well as the CAN Bus, to enable connecting to the HONEY flight stack remotely, over cable.<br />
<br />
As of August 10th, 2017, all HONEY flight stacks require Viper as the bottom-most (stack-terminating) board. This makes Viper a FCC (Flight Critical Component). This is both for physical and electrical reasons -- Viper is the only board with a non-stackthrough data bus, making it the choice for the bottom-most board. This was previously the BMS, due to the need for enough space for the battery pack -- however, the maximum spacing between flight stack boards has since increased to 20mm, allowing the BMS to be on the stack interior, and necessitating an alternate stack-terminating board -- Viper was chosen. Necessarily having Viper in a Flight Stack also guarantees any stack can be debugged using the master breakout, or expanded using payload breakouts.<br />
<br />
This enables two important capabilities, such as:<br />
* The Flight Stack can be broken into two compartments, and connected seamlessly via cable, continuing to act as one complete flight stack (unless there are relevant data bus signals that aren't broken out).<br />
* The Flight Stack can be broken out to an external payload, which, with the correct receiving connector, can have access to all of the stack data/power/signal lines. This enables using the HONEY flight stack for non-HONEY payloads -- such as ProtoBee's or similar projects.<br />
<br />
These functions, as well as a breakdown of the Viper Breakout Pinout, are explained below:<br />
<br />
== Pinout ==<br />
<br />
Viper comes with three connectors -- two "Payload Breakouts" and one "Master Breakout". They are discussed in detail below.<br />
<br />
=== Payload Breakout ===<br />
Viper has two Payload Breakout connectors -- this allows for the possibility of daisy chaining vertically or horizontally through the same flight stack. That is, you can "extend" the flight stack downward by having another flight stack below it, connected to the original flight stacks Viper boad, AND simultaneously extend the flight stack vertically, by adding a flight stack above the original flight stack, and connecting it to the other payload breakout. <br />
<br />
The Payload Breakout format (meaning, the particular connector, cabling) as well as the specific pinout, is called '''Venom Breakout'''.<br />
<br />
There is no need for more than two payload breakouts, with the expectation that all boards that receive the payload breakout also have a secondary connector to allow for continued daisy chaining. This is the case, for example, on ProtoBee.<br />
<br />
Details of the Venom Breakout can be found on the [[Venom_Breakout | Venom Breakout]] page.<br />
<br />
[[File: Viper2.png | right| thumb | <center> Viper Routing </center>]]<br />
<br />
=== Master Breakout ===<br />
In addition to the Venom Breakout, Viper also includes a larger, 56-pin 2.54mm (standard) pitch connector known as the Master Breakout -- or, more formally, the '''Fang Breakout'''.<br />
<br />
The ''Fang Breakout'' breaks out the remainder of what the Viper Breakout was unable to breakout, or what was deemed inessential for a payload to have access to. This includes the secondary CAN Bus and some additional avionics GPIO pins.<br />
<br />
[[Category:HONEY]]</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Balloons_Gen_1_Breakout&diff=3246Balloons Gen 1 Breakout2017-09-28T21:13:14Z<p>Ksafin: </p>
<hr />
<div>{{HONEY-sidebar<br />
| header = Viper<br />
| img = File:Viper.jpg<br />
| designer = Kirill Safin<br />
| techline = Balloons Breakouts<br />
| version = Generation I<br />
| name = Viper<br />
}}<br />
<br />
'''Viper''' is the first generation HONEY Breakout Board. Viper breaks out most of the important signal and power lines from the HONEY stack Data Bus & Power Bus, as well as the CAN Bus, to enable connecting to the HONEY flight stack remotely, over cable.<br />
<br />
As of August 10th, 2017, all HONEY flight stacks require Viper as the bottom-most (stack-terminating) board. This makes Viper a FCC (Flight Critical Component). This is both for physical and electrical reasons -- Viper is the only board with a non-stackthrough data bus, making it the choice for the bottom-most board. This was previously the BMS, due to the need for enough space for the battery pack -- however, the maximum spacing between flight stack boards has since increased to 20mm, allowing the BMS to be on the stack interior, and necessitating an alternate stack-terminating board -- Viper was chosen. Necessarily having Viper in a Flight Stack also guarantees any stack can be debugged using the master breakout, or expanded using payload breakouts.<br />
<br />
This enables two important capabilities, such as:<br />
* The Flight Stack can be broken into two compartments, and connected seamlessly via cable, continuing to act as one complete flight stack (unless there are relevant data bus signals that aren't broken out).<br />
* The Flight Stack can be broken out to an external payload, which, with the correct receiving connector, can have access to all of the stack data/power/signal lines. This enables using the HONEY flight stack for non-HONEY payloads -- such as ProtoBee's or similar projects.<br />
<br />
These functions, as well as a breakdown of the Viper Breakout Pinout, are explained below:<br />
<br />
== Pinout ==<br />
<br />
Viper comes with three connectors -- two "Payload Breakouts" and one "Master Breakout". They are discussed in detail below.<br />
<br />
=== Payload Breakout ===<br />
Viper has two Payload Breakout connectors -- this allows for the possibility of daisy chaining vertically or horizontally through the same flight stack. That is, you can "extend" the flight stack downward by having another flight stack below it, connected to the original flight stacks Viper boad, AND simultaneously extend the flight stack vertically, by adding a flight stack above the original flight stack, and connecting it to the other payload breakout. <br />
<br />
The Payload Breakout format (meaning, the particular connector, cabling) as well as the specific pinout, is called '''Venom Breakout'''.<br />
<br />
There is no need for more than two payload breakouts, with the expectation that all boards that receive the payload breakout also have a secondary connector to allow for continued daisy chaining. This is the case, for example, on ProtoBee.<br />
<br />
Details of the Venom Breakout can be found on the [[Venom_Breakout | Venom Breakout]] page.<br />
<br />
[[File: Viper2.png | right| thumb | <center> Viper Routing </center>]]<br />
<br />
=== Master Breakout ===<br />
In addition to the Venom Breakout, Viper also includes a larger, 56-pin 2.54mm (standard) pitch connector known as the Master Breakout -- or, more formally, the '''Fang Breakout'''.<br />
<br />
The ''Fang Breakout'' breaks out the remainder of what the Viper Breakout was unable to breakout, or what was deemed inessential for a payload to have access to. This includes the secondary CAN Bus and some additional avionics GPIO pins.<br />
<br />
[[Category:HONEY]]</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Balloons_Gen_1_Breakout&diff=3245Balloons Gen 1 Breakout2017-09-28T21:13:00Z<p>Ksafin: /* Payload Breakout */</p>
<hr />
<div>{{HONEY-sidebar<br />
| header = Viper<br />
| designer = Kirill Safin<br />
| techline = Balloons Breakouts<br />
| version = Generation I<br />
| name = Viper<br />
}}<br />
<br />
'''Viper''' is the first generation HONEY Breakout Board. Viper breaks out most of the important signal and power lines from the HONEY stack Data Bus & Power Bus, as well as the CAN Bus, to enable connecting to the HONEY flight stack remotely, over cable.<br />
<br />
As of August 10th, 2017, all HONEY flight stacks require Viper as the bottom-most (stack-terminating) board. This makes Viper a FCC (Flight Critical Component). This is both for physical and electrical reasons -- Viper is the only board with a non-stackthrough data bus, making it the choice for the bottom-most board. This was previously the BMS, due to the need for enough space for the battery pack -- however, the maximum spacing between flight stack boards has since increased to 20mm, allowing the BMS to be on the stack interior, and necessitating an alternate stack-terminating board -- Viper was chosen. Necessarily having Viper in a Flight Stack also guarantees any stack can be debugged using the master breakout, or expanded using payload breakouts.<br />
<br />
This enables two important capabilities, such as:<br />
* The Flight Stack can be broken into two compartments, and connected seamlessly via cable, continuing to act as one complete flight stack (unless there are relevant data bus signals that aren't broken out).<br />
* The Flight Stack can be broken out to an external payload, which, with the correct receiving connector, can have access to all of the stack data/power/signal lines. This enables using the HONEY flight stack for non-HONEY payloads -- such as ProtoBee's or similar projects.<br />
<br />
These functions, as well as a breakdown of the Viper Breakout Pinout, are explained below:<br />
<br />
== Pinout ==<br />
<br />
Viper comes with three connectors -- two "Payload Breakouts" and one "Master Breakout". They are discussed in detail below.<br />
<br />
=== Payload Breakout ===<br />
Viper has two Payload Breakout connectors -- this allows for the possibility of daisy chaining vertically or horizontally through the same flight stack. That is, you can "extend" the flight stack downward by having another flight stack below it, connected to the original flight stacks Viper boad, AND simultaneously extend the flight stack vertically, by adding a flight stack above the original flight stack, and connecting it to the other payload breakout. <br />
<br />
The Payload Breakout format (meaning, the particular connector, cabling) as well as the specific pinout, is called '''Venom Breakout'''.<br />
<br />
There is no need for more than two payload breakouts, with the expectation that all boards that receive the payload breakout also have a secondary connector to allow for continued daisy chaining. This is the case, for example, on ProtoBee.<br />
<br />
Details of the Venom Breakout can be found on the [[Venom_Breakout | Venom Breakout]] page.<br />
<br />
[[File: Viper2.png | right| thumb | <center> Viper Routing </center>]]<br />
<br />
=== Master Breakout ===<br />
In addition to the Venom Breakout, Viper also includes a larger, 56-pin 2.54mm (standard) pitch connector known as the Master Breakout -- or, more formally, the '''Fang Breakout'''.<br />
<br />
The ''Fang Breakout'' breaks out the remainder of what the Viper Breakout was unable to breakout, or what was deemed inessential for a payload to have access to. This includes the secondary CAN Bus and some additional avionics GPIO pins.<br />
<br />
[[Category:HONEY]]</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Balloons_Gen_1_Breakout&diff=3244Balloons Gen 1 Breakout2017-09-28T21:12:42Z<p>Ksafin: /* Pinout */</p>
<hr />
<div>{{HONEY-sidebar<br />
| header = Viper<br />
| designer = Kirill Safin<br />
| techline = Balloons Breakouts<br />
| version = Generation I<br />
| name = Viper<br />
}}<br />
<br />
'''Viper''' is the first generation HONEY Breakout Board. Viper breaks out most of the important signal and power lines from the HONEY stack Data Bus & Power Bus, as well as the CAN Bus, to enable connecting to the HONEY flight stack remotely, over cable.<br />
<br />
As of August 10th, 2017, all HONEY flight stacks require Viper as the bottom-most (stack-terminating) board. This makes Viper a FCC (Flight Critical Component). This is both for physical and electrical reasons -- Viper is the only board with a non-stackthrough data bus, making it the choice for the bottom-most board. This was previously the BMS, due to the need for enough space for the battery pack -- however, the maximum spacing between flight stack boards has since increased to 20mm, allowing the BMS to be on the stack interior, and necessitating an alternate stack-terminating board -- Viper was chosen. Necessarily having Viper in a Flight Stack also guarantees any stack can be debugged using the master breakout, or expanded using payload breakouts.<br />
<br />
This enables two important capabilities, such as:<br />
* The Flight Stack can be broken into two compartments, and connected seamlessly via cable, continuing to act as one complete flight stack (unless there are relevant data bus signals that aren't broken out).<br />
* The Flight Stack can be broken out to an external payload, which, with the correct receiving connector, can have access to all of the stack data/power/signal lines. This enables using the HONEY flight stack for non-HONEY payloads -- such as ProtoBee's or similar projects.<br />
<br />
These functions, as well as a breakdown of the Viper Breakout Pinout, are explained below:<br />
<br />
== Pinout ==<br />
<br />
Viper comes with three connectors -- two "Payload Breakouts" and one "Master Breakout". They are discussed in detail below.<br />
<br />
=== Payload Breakout ===<br />
Viper has two Payload Breakout connectors -- this allows for the possibility of daisy chaining vertically or horizontally through the same flight stack. That is, you can "extend" the flight stack downward by having another flight stack below it, connected to the original flight stacks Viper boad, AND simultaneously extend the flight stack vertically, by adding a flight stack above the original flight stack, and connecting it to the other payload breakout. <br />
<br />
The Payload Breakout format (meaning, the particular connector, cabling) as well as the specific pinout, is called '''Venom Breakout'''.<br />
<br />
There is no need for more than two payload breakouts, with the expectation that all boards that receive the payload breakout also have a secondary connector to allow for continued daisy chaining. This is the case, for example, on ProtoBee.<br />
<br />
Details of the Venom Breakout can be found on the [[Venom_Breakout | Venom Breakout]] page.<br />
<br />
[[File:Viper2.PNG | right| thumb | <center> Viper Routing </center>]]<br />
<br />
=== Master Breakout ===<br />
In addition to the Venom Breakout, Viper also includes a larger, 56-pin 2.54mm (standard) pitch connector known as the Master Breakout -- or, more formally, the '''Fang Breakout'''.<br />
<br />
The ''Fang Breakout'' breaks out the remainder of what the Viper Breakout was unable to breakout, or what was deemed inessential for a payload to have access to. This includes the secondary CAN Bus and some additional avionics GPIO pins.<br />
<br />
[[Category:HONEY]]</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Balloons_Gen_1_Expander&diff=3243Balloons Gen 1 Expander2017-09-28T21:11:54Z<p>Ksafin: /* Stack Pinout */</p>
<hr />
<div>{{HONEY-sidebar<br />
| header = Cobra<br />
| img link = File:Cobra.jpg<br />
| designer = Kirill Safin<br />
| techline = Balloons Expanders<br />
| version = Generation I<br />
| name = Cobra<br />
}}<br />
<br />
'''Cobra''' is the first generation of HABEES HONEY Expander Boards. Expander Boards ae HONEY-compliant boards that allow expanding the capabilities of a HONEY flight stack in a rapid-prototyping manner. That is, one can test new circuits or projects readily in a HONEY flight stack without making a HONEY compliant board.<br />
<br />
Cobra provides this capability by allowing one to slot in a 1/2 size Adafruit Perma-protoboard (a half-size solderable breadboard) as well as an optional Teensy 3.2. This allows one to very quickly attempt a project or circuit and fly it in a full-fledged HONEY flight stack. <br />
<br />
== Operation ==<br />
'''Cobra''' has a number of useful features aboard to make prototyping & integration easy. The following sections highlight these capabilities, how they work, and how to use them.<br />
<br />
=== ProtoBoard Mating ===<br />
The majority of the board is left blank to permit plugging-in the 1/2 size protoboard. The protoboard plugs in to a set of 2x1 sockets at each corner of the protoboard -- at each extreme end of both power rails. The protoboard must have a matching set of male connectors to mate with the sockets.<br />
<br />
The sockets in question, and the appropriate mating connectors, are:<br />
Sockets: Samtec SL-12-G-10<br />
Headers: Samtec BBL-12-G-E<br />
<br />
For mating with Cobra, a protoboard must have these header connectors soldered in the appropriate four corners, to enable mating.<br />
<br />
=== ProtoBoard Power ===<br />
After mating the ProtoBoard to Cobra, one can select the voltages applied to each of the power rails automatically by Cobra -- by using a pair of jumpers at the power selection headers in the top right of the board.<br />
<br />
Simply apply a jumper between the desired voltage (provided by the HONEY stack or the on-board Teensy). The provided voltages are +5, +4.2 (raw battery), +12, and +3.3 (this 3.3V is from the on-board optional teensy, NOT the HONEY bus). <br />
<br />
Be certain to not jump more than one voltage on a given rail -- this could cause permanent damage to the BMS or Teensy. You may select different voltages for each of the power rails, if desired (ie +5 on one, +12 on the other), or you can set the same voltage source for both. <br />
<br />
The shunt used is the Samtec SNT-100-BK-G (0.100" Shunt).<br />
The headers themselves are Samtec TSW-14-07-G-D<br />
<br />
=== MCU Socket ===<br />
If the circuit or project being tested requires a microcontroller, Cobra is equipped with a socket for an optional Teensy 3.2 device. Even more conveniently, this socket breaks out all of the Teensy pins into a convenient right-angle standard pitch set of headers. One can easily, then, tap into a teensy pin and connect it to the protoboard by using a female-male jumper cable.<br />
<br />
The right-angle header strip is at a right angle as opposed to straight up (as is usual) because of clearance limitations. A standard HONEY board has 15mm of vertical clearance, while a female header cable itself is at least 1 cm at its base. By making the breakout right-angled, header cables can be used in this slim profile.<br />
<br />
The Teensy socket, if used, also comes with an included MicroSD socket for data logging (at the top of the board), and a CAN Transceiver, for interfacing with the HONEY stack. The implementation of these, however, results in the utilization of Teensy pins 3 & 4 (for CAN) and one for the microSD chip-select. These pins, are, therefore, off-limits for use as they are already reserved for these functionalities.<br />
<br />
The socket is comprised of the following parts:<br />
SDL-17-G-10 (long 2-row part)<br />
SL-114-G-10 (2 side parts)<br />
SL-15-G-10 (back part)<br />
SL-13-G-10 (analog pins part)<br />
<br />
And the mated teensy side has these headers:<br />
<br />
BBL-114-G-E<br />
BBL-15-G-E<br />
BBL-13-G-E<br />
<br />
The breakout for the Teensy pin right-angled header is as so, with the first row being the top row, and the second row being the bottom row; left to right as viewd down the Cobra PCB from the top.<br />
<br />
The right-angle connector used is the Samtec TSW-120-08-G-D-RA.<br />
<br />
{| class="wikitable"<br />
|-<br />
|0<br />
|1<br />
|2<br />
|5<br />
|6<br />
|7<br />
|8<br />
|9<br />
|10<br />
|11<br />
|12<br />
|13<br />
|14<br />
|15<br />
|16<br />
|17<br />
|18<br />
|19<br />
|20<br />
|21<br />
|-<br />
|22<br />
|23<br />
|24<br />
|25<br />
|26<br />
|27<br />
|28<br />
|29<br />
|30<br />
|31<br />
|32<br />
|33<br />
|A10<br />
|A11<br />
|A12<br />
|A13<br />
|A14<br />
|AREF<br />
|AGND<br />
|GND<br />
|}<br />
<br />
=== Stack Pinout ===<br />
[[File: Cobra3.png | right| thumb | <center> Cobra Routing </center>]]<br />
There is, additionally, a smaller pinout for the HONEY stack -- providing access to all of the most important data and power lines in the HONEY stack. Due to lack of space on the interior of Cobra, this breakout faces the exterior edge.<br />
<br />
It is worth noting that this connector breaks out the Teensy 3.3V (+3.3), as well as the HONEY Power Bus 3.3V (+3.3 BUS). This allows using +3.3 from the teensy without utilizing the power-rail voltage selectors, and also allows using +3.3V without a Teensy (by using the bus supply).<br />
<br />
For understanding of all other pins and their function, reference the HONEY spec.<br />
<br />
The breakout of these pins is as so, with the first row being the top row, and the second row being the bottom row, shown left-to-right, as seen looking at the connector down the board from the top.<br />
<br />
The connector used is the Samtec TSW-114-08-G-D-RA<br />
<br />
{| class="wikitable"<br />
|-<br />
|5V<br />
|3.3V<br />
|3.3V BUS<br />
|VBATT (4.2V)<br />
|GND<br />
|12V<br />
|VADJ_PWM<br />
|R_MCU<br />
|R_ALL<br />
|S_READY<br />
|LOW_PWR<br />
|FMODE<br />
|F3<br />
|F4<br />
|-<br />
|5V<br />
|3.3V<br />
|3.3V BUS<br />
|VBATT (4.2V)<br />
|GND<br />
|12V<br />
|(-12 S)<br />
|(+12 S)<br />
|(-5 S)<br />
|(+5 S)<br />
|CHIRP<br />
|F6<br />
|F5<br />
|VADJ OUT<br />
|}<br />
<br />
[[Category: High Altitude Balloons]][[Category: HABEES]][[Category: HONEY]]</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Balloons_Gen_1_Expander&diff=3242Balloons Gen 1 Expander2017-09-28T21:11:39Z<p>Ksafin: /* Stack Pinout */</p>
<hr />
<div>{{HONEY-sidebar<br />
| header = Cobra<br />
| img link = File:Cobra.jpg<br />
| designer = Kirill Safin<br />
| techline = Balloons Expanders<br />
| version = Generation I<br />
| name = Cobra<br />
}}<br />
<br />
'''Cobra''' is the first generation of HABEES HONEY Expander Boards. Expander Boards ae HONEY-compliant boards that allow expanding the capabilities of a HONEY flight stack in a rapid-prototyping manner. That is, one can test new circuits or projects readily in a HONEY flight stack without making a HONEY compliant board.<br />
<br />
Cobra provides this capability by allowing one to slot in a 1/2 size Adafruit Perma-protoboard (a half-size solderable breadboard) as well as an optional Teensy 3.2. This allows one to very quickly attempt a project or circuit and fly it in a full-fledged HONEY flight stack. <br />
<br />
== Operation ==<br />
'''Cobra''' has a number of useful features aboard to make prototyping & integration easy. The following sections highlight these capabilities, how they work, and how to use them.<br />
<br />
=== ProtoBoard Mating ===<br />
The majority of the board is left blank to permit plugging-in the 1/2 size protoboard. The protoboard plugs in to a set of 2x1 sockets at each corner of the protoboard -- at each extreme end of both power rails. The protoboard must have a matching set of male connectors to mate with the sockets.<br />
<br />
The sockets in question, and the appropriate mating connectors, are:<br />
Sockets: Samtec SL-12-G-10<br />
Headers: Samtec BBL-12-G-E<br />
<br />
For mating with Cobra, a protoboard must have these header connectors soldered in the appropriate four corners, to enable mating.<br />
<br />
=== ProtoBoard Power ===<br />
After mating the ProtoBoard to Cobra, one can select the voltages applied to each of the power rails automatically by Cobra -- by using a pair of jumpers at the power selection headers in the top right of the board.<br />
<br />
Simply apply a jumper between the desired voltage (provided by the HONEY stack or the on-board Teensy). The provided voltages are +5, +4.2 (raw battery), +12, and +3.3 (this 3.3V is from the on-board optional teensy, NOT the HONEY bus). <br />
<br />
Be certain to not jump more than one voltage on a given rail -- this could cause permanent damage to the BMS or Teensy. You may select different voltages for each of the power rails, if desired (ie +5 on one, +12 on the other), or you can set the same voltage source for both. <br />
<br />
The shunt used is the Samtec SNT-100-BK-G (0.100" Shunt).<br />
The headers themselves are Samtec TSW-14-07-G-D<br />
<br />
=== MCU Socket ===<br />
If the circuit or project being tested requires a microcontroller, Cobra is equipped with a socket for an optional Teensy 3.2 device. Even more conveniently, this socket breaks out all of the Teensy pins into a convenient right-angle standard pitch set of headers. One can easily, then, tap into a teensy pin and connect it to the protoboard by using a female-male jumper cable.<br />
<br />
The right-angle header strip is at a right angle as opposed to straight up (as is usual) because of clearance limitations. A standard HONEY board has 15mm of vertical clearance, while a female header cable itself is at least 1 cm at its base. By making the breakout right-angled, header cables can be used in this slim profile.<br />
<br />
The Teensy socket, if used, also comes with an included MicroSD socket for data logging (at the top of the board), and a CAN Transceiver, for interfacing with the HONEY stack. The implementation of these, however, results in the utilization of Teensy pins 3 & 4 (for CAN) and one for the microSD chip-select. These pins, are, therefore, off-limits for use as they are already reserved for these functionalities.<br />
<br />
The socket is comprised of the following parts:<br />
SDL-17-G-10 (long 2-row part)<br />
SL-114-G-10 (2 side parts)<br />
SL-15-G-10 (back part)<br />
SL-13-G-10 (analog pins part)<br />
<br />
And the mated teensy side has these headers:<br />
<br />
BBL-114-G-E<br />
BBL-15-G-E<br />
BBL-13-G-E<br />
<br />
The breakout for the Teensy pin right-angled header is as so, with the first row being the top row, and the second row being the bottom row; left to right as viewd down the Cobra PCB from the top.<br />
<br />
The right-angle connector used is the Samtec TSW-120-08-G-D-RA.<br />
<br />
{| class="wikitable"<br />
|-<br />
|0<br />
|1<br />
|2<br />
|5<br />
|6<br />
|7<br />
|8<br />
|9<br />
|10<br />
|11<br />
|12<br />
|13<br />
|14<br />
|15<br />
|16<br />
|17<br />
|18<br />
|19<br />
|20<br />
|21<br />
|-<br />
|22<br />
|23<br />
|24<br />
|25<br />
|26<br />
|27<br />
|28<br />
|29<br />
|30<br />
|31<br />
|32<br />
|33<br />
|A10<br />
|A11<br />
|A12<br />
|A13<br />
|A14<br />
|AREF<br />
|AGND<br />
|GND<br />
|}<br />
<br />
=== Stack Pinout ===<br />
[[File:Cobra3.jpg | right| thumb | <center> Cobra Routing </center>]]<br />
There is, additionally, a smaller pinout for the HONEY stack -- providing access to all of the most important data and power lines in the HONEY stack. Due to lack of space on the interior of Cobra, this breakout faces the exterior edge.<br />
<br />
It is worth noting that this connector breaks out the Teensy 3.3V (+3.3), as well as the HONEY Power Bus 3.3V (+3.3 BUS). This allows using +3.3 from the teensy without utilizing the power-rail voltage selectors, and also allows using +3.3V without a Teensy (by using the bus supply).<br />
<br />
For understanding of all other pins and their function, reference the HONEY spec.<br />
<br />
The breakout of these pins is as so, with the first row being the top row, and the second row being the bottom row, shown left-to-right, as seen looking at the connector down the board from the top.<br />
<br />
The connector used is the Samtec TSW-114-08-G-D-RA<br />
<br />
{| class="wikitable"<br />
|-<br />
|5V<br />
|3.3V<br />
|3.3V BUS<br />
|VBATT (4.2V)<br />
|GND<br />
|12V<br />
|VADJ_PWM<br />
|R_MCU<br />
|R_ALL<br />
|S_READY<br />
|LOW_PWR<br />
|FMODE<br />
|F3<br />
|F4<br />
|-<br />
|5V<br />
|3.3V<br />
|3.3V BUS<br />
|VBATT (4.2V)<br />
|GND<br />
|12V<br />
|(-12 S)<br />
|(+12 S)<br />
|(-5 S)<br />
|(+5 S)<br />
|CHIRP<br />
|F6<br />
|F5<br />
|VADJ OUT<br />
|}<br />
<br />
[[Category: High Altitude Balloons]][[Category: HABEES]][[Category: HONEY]]</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Balloons_Gen_1_Expander&diff=3241Balloons Gen 1 Expander2017-09-28T21:10:51Z<p>Ksafin: </p>
<hr />
<div>{{HONEY-sidebar<br />
| header = Cobra<br />
| img link = File:Cobra.jpg<br />
| designer = Kirill Safin<br />
| techline = Balloons Expanders<br />
| version = Generation I<br />
| name = Cobra<br />
}}<br />
<br />
'''Cobra''' is the first generation of HABEES HONEY Expander Boards. Expander Boards ae HONEY-compliant boards that allow expanding the capabilities of a HONEY flight stack in a rapid-prototyping manner. That is, one can test new circuits or projects readily in a HONEY flight stack without making a HONEY compliant board.<br />
<br />
Cobra provides this capability by allowing one to slot in a 1/2 size Adafruit Perma-protoboard (a half-size solderable breadboard) as well as an optional Teensy 3.2. This allows one to very quickly attempt a project or circuit and fly it in a full-fledged HONEY flight stack. <br />
<br />
== Operation ==<br />
'''Cobra''' has a number of useful features aboard to make prototyping & integration easy. The following sections highlight these capabilities, how they work, and how to use them.<br />
<br />
=== ProtoBoard Mating ===<br />
The majority of the board is left blank to permit plugging-in the 1/2 size protoboard. The protoboard plugs in to a set of 2x1 sockets at each corner of the protoboard -- at each extreme end of both power rails. The protoboard must have a matching set of male connectors to mate with the sockets.<br />
<br />
The sockets in question, and the appropriate mating connectors, are:<br />
Sockets: Samtec SL-12-G-10<br />
Headers: Samtec BBL-12-G-E<br />
<br />
For mating with Cobra, a protoboard must have these header connectors soldered in the appropriate four corners, to enable mating.<br />
<br />
=== ProtoBoard Power ===<br />
After mating the ProtoBoard to Cobra, one can select the voltages applied to each of the power rails automatically by Cobra -- by using a pair of jumpers at the power selection headers in the top right of the board.<br />
<br />
Simply apply a jumper between the desired voltage (provided by the HONEY stack or the on-board Teensy). The provided voltages are +5, +4.2 (raw battery), +12, and +3.3 (this 3.3V is from the on-board optional teensy, NOT the HONEY bus). <br />
<br />
Be certain to not jump more than one voltage on a given rail -- this could cause permanent damage to the BMS or Teensy. You may select different voltages for each of the power rails, if desired (ie +5 on one, +12 on the other), or you can set the same voltage source for both. <br />
<br />
The shunt used is the Samtec SNT-100-BK-G (0.100" Shunt).<br />
The headers themselves are Samtec TSW-14-07-G-D<br />
<br />
=== MCU Socket ===<br />
If the circuit or project being tested requires a microcontroller, Cobra is equipped with a socket for an optional Teensy 3.2 device. Even more conveniently, this socket breaks out all of the Teensy pins into a convenient right-angle standard pitch set of headers. One can easily, then, tap into a teensy pin and connect it to the protoboard by using a female-male jumper cable.<br />
<br />
The right-angle header strip is at a right angle as opposed to straight up (as is usual) because of clearance limitations. A standard HONEY board has 15mm of vertical clearance, while a female header cable itself is at least 1 cm at its base. By making the breakout right-angled, header cables can be used in this slim profile.<br />
<br />
The Teensy socket, if used, also comes with an included MicroSD socket for data logging (at the top of the board), and a CAN Transceiver, for interfacing with the HONEY stack. The implementation of these, however, results in the utilization of Teensy pins 3 & 4 (for CAN) and one for the microSD chip-select. These pins, are, therefore, off-limits for use as they are already reserved for these functionalities.<br />
<br />
The socket is comprised of the following parts:<br />
SDL-17-G-10 (long 2-row part)<br />
SL-114-G-10 (2 side parts)<br />
SL-15-G-10 (back part)<br />
SL-13-G-10 (analog pins part)<br />
<br />
And the mated teensy side has these headers:<br />
<br />
BBL-114-G-E<br />
BBL-15-G-E<br />
BBL-13-G-E<br />
<br />
The breakout for the Teensy pin right-angled header is as so, with the first row being the top row, and the second row being the bottom row; left to right as viewd down the Cobra PCB from the top.<br />
<br />
The right-angle connector used is the Samtec TSW-120-08-G-D-RA.<br />
<br />
{| class="wikitable"<br />
|-<br />
|0<br />
|1<br />
|2<br />
|5<br />
|6<br />
|7<br />
|8<br />
|9<br />
|10<br />
|11<br />
|12<br />
|13<br />
|14<br />
|15<br />
|16<br />
|17<br />
|18<br />
|19<br />
|20<br />
|21<br />
|-<br />
|22<br />
|23<br />
|24<br />
|25<br />
|26<br />
|27<br />
|28<br />
|29<br />
|30<br />
|31<br />
|32<br />
|33<br />
|A10<br />
|A11<br />
|A12<br />
|A13<br />
|A14<br />
|AREF<br />
|AGND<br />
|GND<br />
|}<br />
<br />
=== Stack Pinout ===<br />
There is, additionally, a smaller pinout for the HONEY stack -- providing access to all of the most important data and power lines in the HONEY stack. Due to lack of space on the interior of Cobra, this breakout faces the exterior edge.<br />
<br />
It is worth noting that this connector breaks out the Teensy 3.3V (+3.3), as well as the HONEY Power Bus 3.3V (+3.3 BUS). This allows using +3.3 from the teensy without utilizing the power-rail voltage selectors, and also allows using +3.3V without a Teensy (by using the bus supply).<br />
<br />
For understanding of all other pins and their function, reference the HONEY spec.<br />
<br />
The breakout of these pins is as so, with the first row being the top row, and the second row being the bottom row, shown left-to-right, as seen looking at the connector down the board from the top.<br />
<br />
The connector used is the Samtec TSW-114-08-G-D-RA<br />
<br />
{| class="wikitable"<br />
|-<br />
|5V<br />
|3.3V<br />
|3.3V BUS<br />
|VBATT (4.2V)<br />
|GND<br />
|12V<br />
|VADJ_PWM<br />
|R_MCU<br />
|R_ALL<br />
|S_READY<br />
|LOW_PWR<br />
|FMODE<br />
|F3<br />
|F4<br />
|-<br />
|5V<br />
|3.3V<br />
|3.3V BUS<br />
|VBATT (4.2V)<br />
|GND<br />
|12V<br />
|(-12 S)<br />
|(+12 S)<br />
|(-5 S)<br />
|(+5 S)<br />
|CHIRP<br />
|F6<br />
|F5<br />
|VADJ OUT<br />
|}<br />
<br />
[[Category: High Altitude Balloons]][[Category: HABEES]][[Category: HONEY]]</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=File:Viper2.png&diff=3240File:Viper2.png2017-09-28T21:10:00Z<p>Ksafin: </p>
<hr />
<div></div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=File:Viper.jpg&diff=3239File:Viper.jpg2017-09-28T21:09:50Z<p>Ksafin: </p>
<hr />
<div></div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=File:QueenBee2.jpg&diff=3238File:QueenBee2.jpg2017-09-28T21:09:42Z<p>Ksafin: </p>
<hr />
<div></div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=File:QueenBee1.jpg&diff=3237File:QueenBee1.jpg2017-09-28T21:09:30Z<p>Ksafin: </p>
<hr />
<div></div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=File:QueenBee-SW.jpg&diff=3236File:QueenBee-SW.jpg2017-09-28T21:09:20Z<p>Ksafin: </p>
<hr />
<div></div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=File:QueenBee-routing.png&diff=3235File:QueenBee-routing.png2017-09-28T21:09:11Z<p>Ksafin: </p>
<hr />
<div></div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=File:Cobra3.png&diff=3234File:Cobra3.png2017-09-28T21:08:57Z<p>Ksafin: </p>
<hr />
<div></div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=File:Cobra.jpg&diff=3233File:Cobra.jpg2017-09-28T21:08:46Z<p>Ksafin: </p>
<hr />
<div></div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Slack_Directory&diff=3232Slack Directory2017-09-28T21:05:04Z<p>Ksafin: /* Balloons */</p>
<hr />
<div>== Non-team specific Channels ==<br />
While SSI consists of 6 distinct teams, a large number of channels are general to all SSI members. These channels are great for cross-ssi discussions.<br />
=== General Channels ===<br />
:* #general - typically for general SSI-wide announcements <br />
:* #random - for things you want to share with SSI that doesn’t belong in any other channels<br />
:* #dankmemes - pretty self explanatory. Try typing "/dank" in the channel.<br />
:* #spacenews - to talk about the current state of space affairs<br />
:* #ssipac - politics<br />
:* #best-of-slack - compilation of the best moments on SSI slack<br />
:* #welcome-to-ssi - channel to welcome new members and answer any questions<br />
:* #diverssity - A place to speak about relavant issues <br />
:* #women - A place for women and gender minorities to speak about relavant issues and bond and stuff<br />
:* #new-frosh - for the new frosh to speak among each other about young people problems<br />
=== Fun channels ===<br />
:* #ssi-finds-a-path - DnD roleplaying<br />
:* #ssi-does-exercise - ssi attempts to stay fit<br />
:* #ssi-makes-stuff - a channel to discuss non ssi related personal projects<br />
:* #ssiplacesblocks - ssi’s minecraft group<br />
:* #ssi-plays-video-games - video games in general, played together. <br />
:* #ssi-jams - ssi makes melodic noises<br />
<br />
=== Non team-specific Engineering Channels ===<br />
Interteam collaboration on a technical projects. Why is it called raccoonworks? Who knows.<br />
:* #raccoonworks-eecs - to talk about and get help with random EE or CS related things<br />
:* #raccoonworks-me - to talk about and get help with random ME related things<br />
:* #prak-ssi<br />
=== Class Channels ===<br />
Want to collaborate on a classes with other SSI members? We make channels for classes in the format: #ssitakes[course#]. Ex:<br />
:* #ssitakesme203<br />
:* #ssitakescs106b<br />
<br />
== Team Channels ==<br />
Each team has a general announcements channel of the format: #[teamname] (ex #rockets) where general team wide discussion and announcements will be made. Sub-projects, and often subsystems of subprojects will be in their own channels. This is usually where the engineering takes place! <br />
=== Rockets ===<br />
:* #rockets<br />
:* #rockets-irec - our largest project each year<br />
:* #rockets-argus - the Argus Daedalus Project, with RF activated cameras and so forth.<br />
:* #rockets-charybdis - the Charybdis Daedalus Project, which is a rocket that spins like a rifle bullet. <br />
:* #rockets-icarus - the Icarus Daedalus Project, which is a rocket that has a multi-activated reefed parachute. <br />
:* #rockets-ksp: shooting for the Mun (playing Kerbal Space Program)<br />
<br />
=== Balloons ===<br />
:* #balloons<br />
:* #balloons-valbal<br />
:* #balloons-buzz<br />
:* #balloons-habees<br />
:* #balloons-habhive<br />
:* #habmc<br />
<br />
=== Sats ===<br />
:* #satellites<br />
=== Bio ===<br />
:* #biology<br />
:* #biology-reading<br />
:* #biology-terminator<br />
:* #biology-backspace<br />
:* #biology-device<br />
=== Operations ===<br />
:* #operations<br />
:* #operations-herbs<br />
:* #operations-community<br />
:* #operations-diverssity<br />
:* #operations-marketing<br />
=== Policy ===<br />
:* #policy <br />
<br />
Contacts<br />
:* {{slack-user|kai}} - operations lead. Talk to him if you want to help make SSI run!<br />
:* {{slack-user|dragland}} and {{slack-user|paigebrown}} - balloons coleads<br />
:* {{slack-user|thomaswhite}} and {{slack-user|williamalvero}} - rockets coleads<br />
:* {{slack-user|chao16}} and {{slack-user|tomusiak}} - Biology Co-Leads<br />
:* {{slack-user|johndean}} and {{slack-user|smaldonado}} - Co-Presidents</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=History_of_the_SSI_Logo&diff=3177History of the SSI Logo2017-09-18T08:23:09Z<p>Ksafin: </p>
<hr />
<div>Many of you may wonder where the artistic, beautiful SSI logo came from. Well, here is that story. You may think that it improved with time, but really, the first logo was the best we ever had - except that some people just didn't quite see the beauty in it... that's probably why we have no shirts with it on them.<br />
<br />
The idea for a logo began in the spring of 2012 when SSI was just getting started and needed a logo for branding material that we were handing out about the group. David Gerson, the president of the time (full disclosure, I'm writing this article) had absolutely no artistic talent (or taste as will become apparent shortly) and so needed to outsource the idea. Kyle Anderson had made an image of a Stanford S with a rocket in the middle instead of a tree, so he was recruited to iterate on ideas and in Gerson's opinion, the best version was this - a Stanford S with a star in the middle with some stuff circling it (like the NASA meatball logo)<br />
<br />
[[File:Logo_idea.jpg|600px]]<br />
<br />
With no ability to turn this into something useable, Gerson sent this to a CS friend Omar Diab with instructions to make something space related and useable. Without much to go on, Omar leveraged the NASA meatball logo with a Stanford S in the middle. But Gerson wanted to make it clear that the group wasn't just about rockets, and so requested the addition of other things on the outside - because the other projects at the time were a PhoneSat and Lunabotics, the satellite and excavator were chosen which resulted in SSI's first official logo. Though there was an option (that wasn't chosen) that showed a moon rover instead. Omar definitely wouldn't have chosen to put these things on the outside himself, but Gerson insisted.<br />
<br />
[[File:Stanford space logo excavator.png|600px]]<br />
<br />
[[File:Stanford_space_logo-rover.png|600px]]<br />
<br />
And yes, at the time our name was the Stanford Spaceflight Initiative. It would be months until we were forbidden from using Stanford in the name (we weren't an approved group) or using the Stanford S with a rocket in the middle (breaks branding rules). When that happened, we creatively changed things up to remove the Stanford S (we were too stubborn to change our name until later)<br />
<br />
[[File:Ssi logo without stanford.png|600px|]]<br />
<br />
Despite it obviously being amazing, Robert Jackson and Ben Todd soon started a campaign to get a better logo. We went through many iterations of things to try and find something that looked good, but many never saw the light of day. We even tried to hold a logo competition where the winner would receive $100, but that didn't result in anything. Eventually, Charlie Cox and Robert Jackson (second Co-Presidents of SSI) settled on a new version of the logo, which was actually a bit respectable:<br />
<br />
[[File:SSI logo 2.jpg|600px|]]<br />
<br />
This served faithfully, until the next generation of SSIers decided it was too phallic and changed it to result in the logo we have today. It was designed by Kirill Safin after a series of 200 potential logos that he developed. It seems we did something right, because for the first time, a logo has lasted past a presidential transition.<br />
<br />
[[File:Current_logo.png|600px]]<br />
<br />
[[Category:Operations]]</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Find_a_Project&diff=3105Find a Project2017-09-17T22:36:41Z<p>Ksafin: /* BUZZ */</p>
<hr />
<div>= SSI Overload = <br />
So you've joined [https://ssi-teams.slack.com/join] Slack, maybe gone to a meeting or two, but you're not sure what you can do or what there even is to do with so many teams swirling around? Well you've come to right place! Below are all the projects each team is working on, what skills they utilize or where they're especially looking for help, and who you can contact to jump in! Think of this like a jobs listing page except that the jobs are always available and you apply by poking the person of contact and saying you want the job -- and it's probably yours.<br />
<br />
As you can see from the length of this list, there will always be more SSI to do than you will have hours in a day, week, month, or year -- don't feel pressured to overextend yourself! If you have questions, are feeling overwhelmed, or just want to chat with someone, don't hesitate to reach out to a leadership member. ''SSI exists for, and because of, its members (that's you.) Your sanity, health, and overall well-being always come first.''<br />
<br />
= Balloons =<br />
<br />
== HABMC ==<br />
HABMC has a request list a mile long, but here are a couple highlights. Feel free to slack {{slack-user|kai}} if you have ideas or questions<br />
* 3D visualizations using Cesium or Unity<br />
* Natural Language Processing for the commands module<br />
* Create a mobile app using React Native<br />
* Improved [[Balloons Radio Projects|RF integrations]]<br />
* Overhaul security on websocket connections<br />
* Navigation algorithms<br />
<br />
== ValBal ==<br />
<br />
== HABEES ==<br />
HABEES (High Altitude Balloon Electrical Engineering Systems) is the the umbrella project for all EE & CS projects outside of ValBal (that is, largely oriented at standard profile balloon launches). Because of this, there is a nearly limitless number of possibilities and projects to pursue within HABEES -- with that said, if you're new to EE or CS, or a veteran, and just generally want some ideas of what you can make, here's a bunch! Contact {{slack-user|kirillsafin}} to discuss working on any of these!<br />
<br />
* HONEY EE -- the primary electronics in HABEES revolve around the HONEY architecture. If you're interested in EE, you can test circuits and/or make PCB's for this architecture and have it fly with other boards. Head over to the [[Gen_2_Architecture | HONEY]] page to understand more about it. Below are some project ideas for circuits/boards you can make for HONEY!<br />
** Motor/Servo Driver <br />
** External/Internal Payload Heaters<br />
** Atmospheric Gas Sensors<br />
** Wind Sensors<br />
** SSTV Radio Board<br />
** WinLink Radio Email Board<br />
** APRS Radio Board<br />
** 12V Battery Management System<br />
** General Purpose Radio Transceiver<br />
** Camera Board<br />
** CubeSat Mapping Board<br />
** Literally anything else<br />
* HONEY CS -- although there's a lot of electronics in HABEES, they all need some software; and, even better, that software always has room for improvement, so here's some possible projects!<br />
** Software for tracking something (with motors/servos)<br />
** Improving filtering/error checking for sensors<br />
** Compression algorithms for logged & transmitted data<br />
** Enhancing speed, quality, and throughput of CAN Bus<br />
** Enhancing TestBench (QueenBee) test software<br />
** Introducing/Developing radio encoding & decoding schemes<br />
** Developing forward & reverse error correction for radio links<br />
** Developing Point-To-Point radar link software<br />
<br />
== BUZZ ==<br />
BUZZ is the umbrella subteam for balloons radio projects. It operated as part of HABEES, and works to develop/try/test new radio technologies within balloons. ValBal also develops independent and system-specific radio systems. Some ideas for possible projects, as well as ongoing projects, are below: Talk to {{slack-user|kirillsafin}} and {{slack-user|ariatedjarati}} about them!<br />
* Improved ATV link quality<br />
* Teensy-native SSTV Transmission & Reception<br />
* APRS development<br />
* Native GFSK/FSK/OOK transceivers & software<br />
* WiFi downlink/uplink (2.4GHz / 5 GHz)<br />
* Stanford Ground Station (high gain, directional)<br />
* Portable Field Ground Station<br />
* Balloons National Ground Station Networ<br />
* WinLink Global Radio E-Mail<br />
* Digital Video/Image encoding<br />
<br />
= Rockets =<br />
== Onboarding ==<br />
<br />
== Daedalus ==<br />
<br />
== Competition (IREC/SA Cup) ==<br />
* Structures<br />
* Payload<br />
* Recovery<br />
* Avionics, '''Leads: Sharon, Julea''' {{slack-user|splatt}} {{slack-user|juleachin}}<br />
** Design, implement, and test all the hardware and software that goes into our flight computers<br />
** Design and manufacture structures for avionics bay and work with other subteams to implement interfaces and integration processes<br />
** Design and test radio communications system for our rocket to talk to the ground <br />
** Write software to parse and visualize data, build a protective cooling case for laptops & other electronics so they don't die in the blazing desert heat and dust (yes there's a story here)<br />
* Launch Operations, '''Lead: WANTED'''<br />
** Work with each subteam to coordinate and prepare launch materials<br />
** Plan & execute travel and launch logistics <br />
** Oversee launch procedures, checklists, and go/no calls<br />
** Many more additional projects for ground support designable around personal interests<br />
* Simulations<br />
<br />
= Satellites =<br />
<br />
= Biology =<br />
<br />
= Policy =<br />
<br />
= Operations =<br />
<br />
== Community ==<br />
* Come up with a theme for Special Dinner and make decorations (like a model Falcon 9!)<br />
* Help {{slack-user|dragland}} run SSI general dinners<br />
* Plan and run general community events like Trivia Night, Pathfinder, and Movie Night<br />
== Diversity ==<br />
* Build connections with engineering diversity groups on campus<br />
* Help {{slack-user|ruqayyatoorawa}} run workshops<br />
== Events ==<br />
* Find an interesting company and arrange a tour or talk<br />
* Help handle logistics of an existing talk, like by meeting an astronaut and walking him to Durand 450<br />
* Give a CEO or Venture Capitalist a tour of ESIII<br />
== Finance == <br />
* Complete reimbursements <br />
* Apply for grants & seek out new sponsors<br />
== Marketing ==<br />
* Design awesome swag (t-shirts, jackets, posters)<br />
* Reach out to reporters<br />
* Social media guru! (Facebook, Twitter, and Instagram posts)<br />
* Creating Snapchat filters for events<br />
* Designing flyers for upcoming talks<br />
* Going on launches to take pictures and videos<br />
== Outreach ==<br />
* Start discussions with local highschools and their science clubs<br />
* Organize or join an existing trip to a local school<br />
== Sponsors ==<br />
* Pursue a sponsorship (we'll walk you through how!)<br />
* Compile a list of bay-area aerospace companies<br />
== Website ==<br />
* Overhaul the budgeting system<br />
* Give the sponsors page dynamic content<br />
* Manage this very wiki<br />
* Manage our public and internal websites<br />
== Workspace ==<br />
* Make space-themed artwork to decorate ESIII<br />
* Plant more herbs<br />
* Paint a mural<br />
* Track inventory of supplies and parts</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Find_a_Project&diff=3104Find a Project2017-09-17T22:36:31Z<p>Ksafin: /* BUZZ */</p>
<hr />
<div>= SSI Overload = <br />
So you've joined [https://ssi-teams.slack.com/join] Slack, maybe gone to a meeting or two, but you're not sure what you can do or what there even is to do with so many teams swirling around? Well you've come to right place! Below are all the projects each team is working on, what skills they utilize or where they're especially looking for help, and who you can contact to jump in! Think of this like a jobs listing page except that the jobs are always available and you apply by poking the person of contact and saying you want the job -- and it's probably yours.<br />
<br />
As you can see from the length of this list, there will always be more SSI to do than you will have hours in a day, week, month, or year -- don't feel pressured to overextend yourself! If you have questions, are feeling overwhelmed, or just want to chat with someone, don't hesitate to reach out to a leadership member. ''SSI exists for, and because of, its members (that's you.) Your sanity, health, and overall well-being always come first.''<br />
<br />
= Balloons =<br />
<br />
== HABMC ==<br />
HABMC has a request list a mile long, but here are a couple highlights. Feel free to slack {{slack-user|kai}} if you have ideas or questions<br />
* 3D visualizations using Cesium or Unity<br />
* Natural Language Processing for the commands module<br />
* Create a mobile app using React Native<br />
* Improved [[Balloons Radio Projects|RF integrations]]<br />
* Overhaul security on websocket connections<br />
* Navigation algorithms<br />
<br />
== ValBal ==<br />
<br />
== HABEES ==<br />
HABEES (High Altitude Balloon Electrical Engineering Systems) is the the umbrella project for all EE & CS projects outside of ValBal (that is, largely oriented at standard profile balloon launches). Because of this, there is a nearly limitless number of possibilities and projects to pursue within HABEES -- with that said, if you're new to EE or CS, or a veteran, and just generally want some ideas of what you can make, here's a bunch! Contact {{slack-user|kirillsafin}} to discuss working on any of these!<br />
<br />
* HONEY EE -- the primary electronics in HABEES revolve around the HONEY architecture. If you're interested in EE, you can test circuits and/or make PCB's for this architecture and have it fly with other boards. Head over to the [[Gen_2_Architecture | HONEY]] page to understand more about it. Below are some project ideas for circuits/boards you can make for HONEY!<br />
** Motor/Servo Driver <br />
** External/Internal Payload Heaters<br />
** Atmospheric Gas Sensors<br />
** Wind Sensors<br />
** SSTV Radio Board<br />
** WinLink Radio Email Board<br />
** APRS Radio Board<br />
** 12V Battery Management System<br />
** General Purpose Radio Transceiver<br />
** Camera Board<br />
** CubeSat Mapping Board<br />
** Literally anything else<br />
* HONEY CS -- although there's a lot of electronics in HABEES, they all need some software; and, even better, that software always has room for improvement, so here's some possible projects!<br />
** Software for tracking something (with motors/servos)<br />
** Improving filtering/error checking for sensors<br />
** Compression algorithms for logged & transmitted data<br />
** Enhancing speed, quality, and throughput of CAN Bus<br />
** Enhancing TestBench (QueenBee) test software<br />
** Introducing/Developing radio encoding & decoding schemes<br />
** Developing forward & reverse error correction for radio links<br />
** Developing Point-To-Point radar link software<br />
<br />
== BUZZ ==<br />
BUZZ is the umbrella subteam for balloons radio projects. It operated as part of HABEES, and works to develop/try/test new radio technologies within balloons. ValBal also develops independent and system-specific radio systems. Some ideas for possible projects, as well as ongoing projects, are below: Talk to {{slack-user|kirillsafin}} and {{slack-user|ariatedjarati}} about them! Also Join {{slack-user|#balloons-rf}}<br />
* Improved ATV link quality<br />
* Teensy-native SSTV Transmission & Reception<br />
* APRS development<br />
* Native GFSK/FSK/OOK transceivers & software<br />
* WiFi downlink/uplink (2.4GHz / 5 GHz)<br />
* Stanford Ground Station (high gain, directional)<br />
* Portable Field Ground Station<br />
* Balloons National Ground Station Networ<br />
* WinLink Global Radio E-Mail<br />
* Digital Video/Image encoding<br />
<br />
= Rockets =<br />
== Onboarding ==<br />
<br />
== Daedalus ==<br />
<br />
== Competition (IREC/SA Cup) ==<br />
* Structures<br />
* Payload<br />
* Recovery<br />
* Avionics, '''Leads: Sharon, Julea''' {{slack-user|splatt}} {{slack-user|juleachin}}<br />
** Design, implement, and test all the hardware and software that goes into our flight computers<br />
** Design and manufacture structures for avionics bay and work with other subteams to implement interfaces and integration processes<br />
** Design and test radio communications system for our rocket to talk to the ground <br />
** Write software to parse and visualize data, build a protective cooling case for laptops & other electronics so they don't die in the blazing desert heat and dust (yes there's a story here)<br />
* Launch Operations, '''Lead: WANTED'''<br />
** Work with each subteam to coordinate and prepare launch materials<br />
** Plan & execute travel and launch logistics <br />
** Oversee launch procedures, checklists, and go/no calls<br />
** Many more additional projects for ground support designable around personal interests<br />
* Simulations<br />
<br />
= Satellites =<br />
<br />
= Biology =<br />
<br />
= Policy =<br />
<br />
= Operations =<br />
<br />
== Community ==<br />
* Come up with a theme for Special Dinner and make decorations (like a model Falcon 9!)<br />
* Help {{slack-user|dragland}} run SSI general dinners<br />
* Plan and run general community events like Trivia Night, Pathfinder, and Movie Night<br />
== Diversity ==<br />
* Build connections with engineering diversity groups on campus<br />
* Help {{slack-user|ruqayyatoorawa}} run workshops<br />
== Events ==<br />
* Find an interesting company and arrange a tour or talk<br />
* Help handle logistics of an existing talk, like by meeting an astronaut and walking him to Durand 450<br />
* Give a CEO or Venture Capitalist a tour of ESIII<br />
== Finance == <br />
* Complete reimbursements <br />
* Apply for grants & seek out new sponsors<br />
== Marketing ==<br />
* Design awesome swag (t-shirts, jackets, posters)<br />
* Reach out to reporters<br />
* Social media guru! (Facebook, Twitter, and Instagram posts)<br />
* Creating Snapchat filters for events<br />
* Designing flyers for upcoming talks<br />
* Going on launches to take pictures and videos<br />
== Outreach ==<br />
* Start discussions with local highschools and their science clubs<br />
* Organize or join an existing trip to a local school<br />
== Sponsors ==<br />
* Pursue a sponsorship (we'll walk you through how!)<br />
* Compile a list of bay-area aerospace companies<br />
== Website ==<br />
* Overhaul the budgeting system<br />
* Give the sponsors page dynamic content<br />
* Manage this very wiki<br />
* Manage our public and internal websites<br />
== Workspace ==<br />
* Make space-themed artwork to decorate ESIII<br />
* Plant more herbs<br />
* Paint a mural<br />
* Track inventory of supplies and parts</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Find_a_Project&diff=3103Find a Project2017-09-17T22:36:16Z<p>Ksafin: /* BUZZ */</p>
<hr />
<div>= SSI Overload = <br />
So you've joined [https://ssi-teams.slack.com/join] Slack, maybe gone to a meeting or two, but you're not sure what you can do or what there even is to do with so many teams swirling around? Well you've come to right place! Below are all the projects each team is working on, what skills they utilize or where they're especially looking for help, and who you can contact to jump in! Think of this like a jobs listing page except that the jobs are always available and you apply by poking the person of contact and saying you want the job -- and it's probably yours.<br />
<br />
As you can see from the length of this list, there will always be more SSI to do than you will have hours in a day, week, month, or year -- don't feel pressured to overextend yourself! If you have questions, are feeling overwhelmed, or just want to chat with someone, don't hesitate to reach out to a leadership member. ''SSI exists for, and because of, its members (that's you.) Your sanity, health, and overall well-being always come first.''<br />
<br />
= Balloons =<br />
<br />
== HABMC ==<br />
HABMC has a request list a mile long, but here are a couple highlights. Feel free to slack {{slack-user|kai}} if you have ideas or questions<br />
* 3D visualizations using Cesium or Unity<br />
* Natural Language Processing for the commands module<br />
* Create a mobile app using React Native<br />
* Improved [[Balloons Radio Projects|RF integrations]]<br />
* Overhaul security on websocket connections<br />
* Navigation algorithms<br />
<br />
== ValBal ==<br />
<br />
== HABEES ==<br />
HABEES (High Altitude Balloon Electrical Engineering Systems) is the the umbrella project for all EE & CS projects outside of ValBal (that is, largely oriented at standard profile balloon launches). Because of this, there is a nearly limitless number of possibilities and projects to pursue within HABEES -- with that said, if you're new to EE or CS, or a veteran, and just generally want some ideas of what you can make, here's a bunch! Contact {{slack-user|kirillsafin}} to discuss working on any of these!<br />
<br />
* HONEY EE -- the primary electronics in HABEES revolve around the HONEY architecture. If you're interested in EE, you can test circuits and/or make PCB's for this architecture and have it fly with other boards. Head over to the [[Gen_2_Architecture | HONEY]] page to understand more about it. Below are some project ideas for circuits/boards you can make for HONEY!<br />
** Motor/Servo Driver <br />
** External/Internal Payload Heaters<br />
** Atmospheric Gas Sensors<br />
** Wind Sensors<br />
** SSTV Radio Board<br />
** WinLink Radio Email Board<br />
** APRS Radio Board<br />
** 12V Battery Management System<br />
** General Purpose Radio Transceiver<br />
** Camera Board<br />
** CubeSat Mapping Board<br />
** Literally anything else<br />
* HONEY CS -- although there's a lot of electronics in HABEES, they all need some software; and, even better, that software always has room for improvement, so here's some possible projects!<br />
** Software for tracking something (with motors/servos)<br />
** Improving filtering/error checking for sensors<br />
** Compression algorithms for logged & transmitted data<br />
** Enhancing speed, quality, and throughput of CAN Bus<br />
** Enhancing TestBench (QueenBee) test software<br />
** Introducing/Developing radio encoding & decoding schemes<br />
** Developing forward & reverse error correction for radio links<br />
** Developing Point-To-Point radar link software<br />
<br />
== BUZZ ==<br />
BUZZ is the umbrella subteam for balloons radio projects. It operated as part of HABEES, and works to develop/try/test new radio technologies within balloons. ValBal also develops independent and system-specific radio systems. Some ideas for possible projects, as well as ongoing projects, are below: Talk to {{slack-user|kirillsafin}} and {{slack-user|ariatedjarati}} about them!<br />
* Improved ATV link quality<br />
* Teensy-native SSTV Transmission & Reception<br />
* APRS development<br />
* Native GFSK/FSK/OOK transceivers & software<br />
* WiFi downlink/uplink (2.4GHz / 5 GHz)<br />
* Stanford Ground Station (high gain, directional)<br />
* Portable Field Ground Station<br />
* Balloons National Ground Station Networ<br />
* WinLink Global Radio E-Mail<br />
* Digital Video/Image encoding<br />
<br />
= Rockets =<br />
== Onboarding ==<br />
<br />
== Daedalus ==<br />
<br />
== Competition (IREC/SA Cup) ==<br />
* Structures<br />
* Payload<br />
* Recovery<br />
* Avionics, '''Leads: Sharon, Julea''' {{slack-user|splatt}} {{slack-user|juleachin}}<br />
** Design, implement, and test all the hardware and software that goes into our flight computers<br />
** Design and manufacture structures for avionics bay and work with other subteams to implement interfaces and integration processes<br />
** Design and test radio communications system for our rocket to talk to the ground <br />
** Write software to parse and visualize data, build a protective cooling case for laptops & other electronics so they don't die in the blazing desert heat and dust (yes there's a story here)<br />
* Launch Operations, '''Lead: WANTED'''<br />
** Work with each subteam to coordinate and prepare launch materials<br />
** Plan & execute travel and launch logistics <br />
** Oversee launch procedures, checklists, and go/no calls<br />
** Many more additional projects for ground support designable around personal interests<br />
* Simulations<br />
<br />
= Satellites =<br />
<br />
= Biology =<br />
<br />
= Policy =<br />
<br />
= Operations =<br />
<br />
== Community ==<br />
* Come up with a theme for Special Dinner and make decorations (like a model Falcon 9!)<br />
* Help {{slack-user|dragland}} run SSI general dinners<br />
* Plan and run general community events like Trivia Night, Pathfinder, and Movie Night<br />
== Diversity ==<br />
* Build connections with engineering diversity groups on campus<br />
* Help {{slack-user|ruqayyatoorawa}} run workshops<br />
== Events ==<br />
* Find an interesting company and arrange a tour or talk<br />
* Help handle logistics of an existing talk, like by meeting an astronaut and walking him to Durand 450<br />
* Give a CEO or Venture Capitalist a tour of ESIII<br />
== Finance == <br />
* Complete reimbursements <br />
* Apply for grants & seek out new sponsors<br />
== Marketing ==<br />
* Design awesome swag (t-shirts, jackets, posters)<br />
* Reach out to reporters<br />
* Social media guru! (Facebook, Twitter, and Instagram posts)<br />
* Creating Snapchat filters for events<br />
* Designing flyers for upcoming talks<br />
* Going on launches to take pictures and videos<br />
== Outreach ==<br />
* Start discussions with local highschools and their science clubs<br />
* Organize or join an existing trip to a local school<br />
== Sponsors ==<br />
* Pursue a sponsorship (we'll walk you through how!)<br />
* Compile a list of bay-area aerospace companies<br />
== Website ==<br />
* Overhaul the budgeting system<br />
* Give the sponsors page dynamic content<br />
* Manage this very wiki<br />
* Manage our public and internal websites<br />
== Workspace ==<br />
* Make space-themed artwork to decorate ESIII<br />
* Plant more herbs<br />
* Paint a mural<br />
* Track inventory of supplies and parts</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Find_a_Project&diff=3102Find a Project2017-09-17T22:35:41Z<p>Ksafin: /* BUZZ */</p>
<hr />
<div>= SSI Overload = <br />
So you've joined [https://ssi-teams.slack.com/join] Slack, maybe gone to a meeting or two, but you're not sure what you can do or what there even is to do with so many teams swirling around? Well you've come to right place! Below are all the projects each team is working on, what skills they utilize or where they're especially looking for help, and who you can contact to jump in! Think of this like a jobs listing page except that the jobs are always available and you apply by poking the person of contact and saying you want the job -- and it's probably yours.<br />
<br />
As you can see from the length of this list, there will always be more SSI to do than you will have hours in a day, week, month, or year -- don't feel pressured to overextend yourself! If you have questions, are feeling overwhelmed, or just want to chat with someone, don't hesitate to reach out to a leadership member. ''SSI exists for, and because of, its members (that's you.) Your sanity, health, and overall well-being always come first.''<br />
<br />
= Balloons =<br />
<br />
== HABMC ==<br />
HABMC has a request list a mile long, but here are a couple highlights. Feel free to slack {{slack-user|kai}} if you have ideas or questions<br />
* 3D visualizations using Cesium or Unity<br />
* Natural Language Processing for the commands module<br />
* Create a mobile app using React Native<br />
* Improved [[Balloons Radio Projects|RF integrations]]<br />
* Overhaul security on websocket connections<br />
* Navigation algorithms<br />
<br />
== ValBal ==<br />
<br />
== HABEES ==<br />
HABEES (High Altitude Balloon Electrical Engineering Systems) is the the umbrella project for all EE & CS projects outside of ValBal (that is, largely oriented at standard profile balloon launches). Because of this, there is a nearly limitless number of possibilities and projects to pursue within HABEES -- with that said, if you're new to EE or CS, or a veteran, and just generally want some ideas of what you can make, here's a bunch! Contact {{slack-user|kirillsafin}} to discuss working on any of these!<br />
<br />
* HONEY EE -- the primary electronics in HABEES revolve around the HONEY architecture. If you're interested in EE, you can test circuits and/or make PCB's for this architecture and have it fly with other boards. Head over to the [[Gen_2_Architecture | HONEY]] page to understand more about it. Below are some project ideas for circuits/boards you can make for HONEY!<br />
** Motor/Servo Driver <br />
** External/Internal Payload Heaters<br />
** Atmospheric Gas Sensors<br />
** Wind Sensors<br />
** SSTV Radio Board<br />
** WinLink Radio Email Board<br />
** APRS Radio Board<br />
** 12V Battery Management System<br />
** General Purpose Radio Transceiver<br />
** Camera Board<br />
** CubeSat Mapping Board<br />
** Literally anything else<br />
* HONEY CS -- although there's a lot of electronics in HABEES, they all need some software; and, even better, that software always has room for improvement, so here's some possible projects!<br />
** Software for tracking something (with motors/servos)<br />
** Improving filtering/error checking for sensors<br />
** Compression algorithms for logged & transmitted data<br />
** Enhancing speed, quality, and throughput of CAN Bus<br />
** Enhancing TestBench (QueenBee) test software<br />
** Introducing/Developing radio encoding & decoding schemes<br />
** Developing forward & reverse error correction for radio links<br />
** Developing Point-To-Point radar link software<br />
<br />
== BUZZ ==<br />
BUZZ is the umbrella subteam for balloons radio projects. It operated as part of HABEES, and works to develop/try/test new radio technologies within balloons. ValBal also develops independent and system-specific radio systems. Some ideas for possible projects, as well as ongoing projects, are below: Talk to <br />
* Improved ATV link quality<br />
* Teensy-native SSTV Transmission & Reception<br />
* APRS development<br />
* Native GFSK/FSK/OOK transceivers & software<br />
* WiFi downlink/uplink (2.4GHz / 5 GHz)<br />
* Stanford Ground Station (high gain, directional)<br />
* Portable Field Ground Station<br />
* Balloons National Ground Station Networ<br />
* WinLink Global Radio E-Mail<br />
* Digital Video/Image encoding<br />
<br />
= Rockets =<br />
== Onboarding ==<br />
<br />
== Daedalus ==<br />
<br />
== Competition (IREC/SA Cup) ==<br />
* Structures<br />
* Payload<br />
* Recovery<br />
* Avionics, '''Leads: Sharon, Julea''' {{slack-user|splatt}} {{slack-user|juleachin}}<br />
** Design, implement, and test all the hardware and software that goes into our flight computers<br />
** Design and manufacture structures for avionics bay and work with other subteams to implement interfaces and integration processes<br />
** Design and test radio communications system for our rocket to talk to the ground <br />
** Write software to parse and visualize data, build a protective cooling case for laptops & other electronics so they don't die in the blazing desert heat and dust (yes there's a story here)<br />
* Launch Operations, '''Lead: WANTED'''<br />
** Work with each subteam to coordinate and prepare launch materials<br />
** Plan & execute travel and launch logistics <br />
** Oversee launch procedures, checklists, and go/no calls<br />
** Many more additional projects for ground support designable around personal interests<br />
* Simulations<br />
<br />
= Satellites =<br />
<br />
= Biology =<br />
<br />
= Policy =<br />
<br />
= Operations =<br />
<br />
== Community ==<br />
* Come up with a theme for Special Dinner and make decorations (like a model Falcon 9!)<br />
* Help {{slack-user|dragland}} run SSI general dinners<br />
* Plan and run general community events like Trivia Night, Pathfinder, and Movie Night<br />
== Diversity ==<br />
* Build connections with engineering diversity groups on campus<br />
* Help {{slack-user|ruqayyatoorawa}} run workshops<br />
== Events ==<br />
* Find an interesting company and arrange a tour or talk<br />
* Help handle logistics of an existing talk, like by meeting an astronaut and walking him to Durand 450<br />
* Give a CEO or Venture Capitalist a tour of ESIII<br />
== Finance == <br />
* Complete reimbursements <br />
* Apply for grants & seek out new sponsors<br />
== Marketing ==<br />
* Design awesome swag (t-shirts, jackets, posters)<br />
* Reach out to reporters<br />
* Social media guru! (Facebook, Twitter, and Instagram posts)<br />
* Creating Snapchat filters for events<br />
* Designing flyers for upcoming talks<br />
* Going on launches to take pictures and videos<br />
== Outreach ==<br />
* Start discussions with local highschools and their science clubs<br />
* Organize or join an existing trip to a local school<br />
== Sponsors ==<br />
* Pursue a sponsorship (we'll walk you through how!)<br />
* Compile a list of bay-area aerospace companies<br />
== Website ==<br />
* Overhaul the budgeting system<br />
* Give the sponsors page dynamic content<br />
* Manage this very wiki<br />
* Manage our public and internal websites<br />
== Workspace ==<br />
* Make space-themed artwork to decorate ESIII<br />
* Plant more herbs<br />
* Paint a mural<br />
* Track inventory of supplies and parts</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Find_a_Project&diff=3101Find a Project2017-09-17T22:35:33Z<p>Ksafin: /* BUZZ */</p>
<hr />
<div>= SSI Overload = <br />
So you've joined [https://ssi-teams.slack.com/join] Slack, maybe gone to a meeting or two, but you're not sure what you can do or what there even is to do with so many teams swirling around? Well you've come to right place! Below are all the projects each team is working on, what skills they utilize or where they're especially looking for help, and who you can contact to jump in! Think of this like a jobs listing page except that the jobs are always available and you apply by poking the person of contact and saying you want the job -- and it's probably yours.<br />
<br />
As you can see from the length of this list, there will always be more SSI to do than you will have hours in a day, week, month, or year -- don't feel pressured to overextend yourself! If you have questions, are feeling overwhelmed, or just want to chat with someone, don't hesitate to reach out to a leadership member. ''SSI exists for, and because of, its members (that's you.) Your sanity, health, and overall well-being always come first.''<br />
<br />
= Balloons =<br />
<br />
== HABMC ==<br />
HABMC has a request list a mile long, but here are a couple highlights. Feel free to slack {{slack-user|kai}} if you have ideas or questions<br />
* 3D visualizations using Cesium or Unity<br />
* Natural Language Processing for the commands module<br />
* Create a mobile app using React Native<br />
* Improved [[Balloons Radio Projects|RF integrations]]<br />
* Overhaul security on websocket connections<br />
* Navigation algorithms<br />
<br />
== ValBal ==<br />
<br />
== HABEES ==<br />
HABEES (High Altitude Balloon Electrical Engineering Systems) is the the umbrella project for all EE & CS projects outside of ValBal (that is, largely oriented at standard profile balloon launches). Because of this, there is a nearly limitless number of possibilities and projects to pursue within HABEES -- with that said, if you're new to EE or CS, or a veteran, and just generally want some ideas of what you can make, here's a bunch! Contact {{slack-user|kirillsafin}} to discuss working on any of these!<br />
<br />
* HONEY EE -- the primary electronics in HABEES revolve around the HONEY architecture. If you're interested in EE, you can test circuits and/or make PCB's for this architecture and have it fly with other boards. Head over to the [[Gen_2_Architecture | HONEY]] page to understand more about it. Below are some project ideas for circuits/boards you can make for HONEY!<br />
** Motor/Servo Driver <br />
** External/Internal Payload Heaters<br />
** Atmospheric Gas Sensors<br />
** Wind Sensors<br />
** SSTV Radio Board<br />
** WinLink Radio Email Board<br />
** APRS Radio Board<br />
** 12V Battery Management System<br />
** General Purpose Radio Transceiver<br />
** Camera Board<br />
** CubeSat Mapping Board<br />
** Literally anything else<br />
* HONEY CS -- although there's a lot of electronics in HABEES, they all need some software; and, even better, that software always has room for improvement, so here's some possible projects!<br />
** Software for tracking something (with motors/servos)<br />
** Improving filtering/error checking for sensors<br />
** Compression algorithms for logged & transmitted data<br />
** Enhancing speed, quality, and throughput of CAN Bus<br />
** Enhancing TestBench (QueenBee) test software<br />
** Introducing/Developing radio encoding & decoding schemes<br />
** Developing forward & reverse error correction for radio links<br />
** Developing Point-To-Point radar link software<br />
<br />
== BUZZ ==<br />
BUZZ is the umbrella subteam for balloons radio projects. It operated as part of HABEES, and works to develop/try/test new radio technologies within balloons. ValBal also develops independent and system-specific radio systems. Some ideas for possible projects, as well as ongoing projects, are below:<br />
* Improved ATV link quality<br />
* Teensy-native SSTV Transmission & Reception<br />
* APRS development<br />
* Native GFSK/FSK/OOK transceivers & software<br />
* WiFi downlink/uplink (2.4GHz / 5 GHz)<br />
* Stanford Ground Station (high gain, directional)<br />
* Portable Field Ground Station<br />
* Balloons National Ground Station Networ<br />
* WinLink Global Radio E-Mail<br />
* Digital Video/Image encoding<br />
<br />
= Rockets =<br />
== Onboarding ==<br />
<br />
== Daedalus ==<br />
<br />
== Competition (IREC/SA Cup) ==<br />
* Structures<br />
* Payload<br />
* Recovery<br />
* Avionics, '''Leads: Sharon, Julea''' {{slack-user|splatt}} {{slack-user|juleachin}}<br />
** Design, implement, and test all the hardware and software that goes into our flight computers<br />
** Design and manufacture structures for avionics bay and work with other subteams to implement interfaces and integration processes<br />
** Design and test radio communications system for our rocket to talk to the ground <br />
** Write software to parse and visualize data, build a protective cooling case for laptops & other electronics so they don't die in the blazing desert heat and dust (yes there's a story here)<br />
* Launch Operations, '''Lead: WANTED'''<br />
** Work with each subteam to coordinate and prepare launch materials<br />
** Plan & execute travel and launch logistics <br />
** Oversee launch procedures, checklists, and go/no calls<br />
** Many more additional projects for ground support designable around personal interests<br />
* Simulations<br />
<br />
= Satellites =<br />
<br />
= Biology =<br />
<br />
= Policy =<br />
<br />
= Operations =<br />
<br />
== Community ==<br />
* Come up with a theme for Special Dinner and make decorations (like a model Falcon 9!)<br />
* Help {{slack-user|dragland}} run SSI general dinners<br />
* Plan and run general community events like Trivia Night, Pathfinder, and Movie Night<br />
== Diversity ==<br />
* Build connections with engineering diversity groups on campus<br />
* Help {{slack-user|ruqayyatoorawa}} run workshops<br />
== Events ==<br />
* Find an interesting company and arrange a tour or talk<br />
* Help handle logistics of an existing talk, like by meeting an astronaut and walking him to Durand 450<br />
* Give a CEO or Venture Capitalist a tour of ESIII<br />
== Finance == <br />
* Complete reimbursements <br />
* Apply for grants & seek out new sponsors<br />
== Marketing ==<br />
* Design awesome swag (t-shirts, jackets, posters)<br />
* Reach out to reporters<br />
* Social media guru! (Facebook, Twitter, and Instagram posts)<br />
* Creating Snapchat filters for events<br />
* Designing flyers for upcoming talks<br />
* Going on launches to take pictures and videos<br />
== Outreach ==<br />
* Start discussions with local highschools and their science clubs<br />
* Organize or join an existing trip to a local school<br />
== Sponsors ==<br />
* Pursue a sponsorship (we'll walk you through how!)<br />
* Compile a list of bay-area aerospace companies<br />
== Website ==<br />
* Overhaul the budgeting system<br />
* Give the sponsors page dynamic content<br />
* Manage this very wiki<br />
* Manage our public and internal websites<br />
== Workspace ==<br />
* Make space-themed artwork to decorate ESIII<br />
* Plant more herbs<br />
* Paint a mural<br />
* Track inventory of supplies and parts</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Find_a_Project&diff=3100Find a Project2017-09-17T22:31:40Z<p>Ksafin: /* HABEES */</p>
<hr />
<div>= SSI Overload = <br />
So you've joined [https://ssi-teams.slack.com/join] Slack, maybe gone to a meeting or two, but you're not sure what you can do or what there even is to do with so many teams swirling around? Well you've come to right place! Below are all the projects each team is working on, what skills they utilize or where they're especially looking for help, and who you can contact to jump in! Think of this like a jobs listing page except that the jobs are always available and you apply by poking the person of contact and saying you want the job -- and it's probably yours.<br />
<br />
As you can see from the length of this list, there will always be more SSI to do than you will have hours in a day, week, month, or year -- don't feel pressured to overextend yourself! If you have questions, are feeling overwhelmed, or just want to chat with someone, don't hesitate to reach out to a leadership member. ''SSI exists for, and because of, its members (that's you.) Your sanity, health, and overall well-being always come first.''<br />
<br />
= Balloons =<br />
<br />
== HABMC ==<br />
HABMC has a request list a mile long, but here are a couple highlights. Feel free to slack {{slack-user|kai}} if you have ideas or questions<br />
* 3D visualizations using Cesium or Unity<br />
* Natural Language Processing for the commands module<br />
* Create a mobile app using React Native<br />
* Improved [[Balloons Radio Projects|RF integrations]]<br />
* Overhaul security on websocket connections<br />
* Navigation algorithms<br />
<br />
== ValBal ==<br />
<br />
== HABEES ==<br />
HABEES (High Altitude Balloon Electrical Engineering Systems) is the the umbrella project for all EE & CS projects outside of ValBal (that is, largely oriented at standard profile balloon launches). Because of this, there is a nearly limitless number of possibilities and projects to pursue within HABEES -- with that said, if you're new to EE or CS, or a veteran, and just generally want some ideas of what you can make, here's a bunch! Contact {{slack-user|kirillsafin}} to discuss working on any of these!<br />
<br />
* HONEY EE -- the primary electronics in HABEES revolve around the HONEY architecture. If you're interested in EE, you can test circuits and/or make PCB's for this architecture and have it fly with other boards. Head over to the [[Gen_2_Architecture | HONEY]] page to understand more about it. Below are some project ideas for circuits/boards you can make for HONEY!<br />
** Motor/Servo Driver <br />
** External/Internal Payload Heaters<br />
** Atmospheric Gas Sensors<br />
** Wind Sensors<br />
** SSTV Radio Board<br />
** WinLink Radio Email Board<br />
** APRS Radio Board<br />
** 12V Battery Management System<br />
** General Purpose Radio Transceiver<br />
** Camera Board<br />
** CubeSat Mapping Board<br />
** Literally anything else<br />
* HONEY CS -- although there's a lot of electronics in HABEES, they all need some software; and, even better, that software always has room for improvement, so here's some possible projects!<br />
** Software for tracking something (with motors/servos)<br />
** Improving filtering/error checking for sensors<br />
** Compression algorithms for logged & transmitted data<br />
** Enhancing speed, quality, and throughput of CAN Bus<br />
** Enhancing TestBench (QueenBee) test software<br />
** Introducing/Developing radio encoding & decoding schemes<br />
** Developing forward & reverse error correction for radio links<br />
** Developing Point-To-Point radar link software<br />
<br />
== BUZZ ==<br />
<br />
= Rockets =<br />
== Onboarding ==<br />
<br />
== Daedalus ==<br />
<br />
== Competition (IREC/SA Cup) ==<br />
* Structures<br />
* Payload<br />
* Recovery<br />
* Avionics, '''Leads: Sharon, Julea''' {{slack-user|splatt}} {{slack-user|juleachin}}<br />
** Design, implement, and test all the hardware and software that goes into our flight computers<br />
** Design and manufacture structures for avionics bay and work with other subteams to implement interfaces and integration processes<br />
** Design and test radio communications system for our rocket to talk to the ground <br />
** Write software to parse and visualize data, build a protective cooling case for laptops & other electronics so they don't die in the blazing desert heat and dust (yes there's a story here)<br />
* Launch Operations, '''Lead: WANTED'''<br />
** Work with each subteam to coordinate and prepare launch materials<br />
** Plan & execute travel and launch logistics <br />
** Oversee launch procedures, checklists, and go/no calls<br />
** Many more additional projects for ground support designable around personal interests<br />
* Simulations<br />
<br />
= Satellites =<br />
<br />
= Biology =<br />
<br />
= Policy =<br />
<br />
= Operations =<br />
<br />
== Community ==<br />
* Come up with a theme for Special Dinner and make decorations (like a model Falcon 9!)<br />
* Help {{slack-user|dragland}} run SSI general dinners<br />
* Plan and run general community events like Trivia Night, Pathfinder, and Movie Night<br />
== Diversity ==<br />
* Build connections with engineering diversity groups on campus<br />
* Help {{slack-user|ruqayyatoorawa}} run workshops<br />
== Events ==<br />
* Find an interesting company and arrange a tour or talk<br />
* Help handle logistics of an existing talk, like by meeting an astronaut and walking him to Durand 450<br />
* Give a CEO or Venture Capitalist a tour of ESIII<br />
== Finance == <br />
* Complete reimbursements <br />
* Apply for grants & seek out new sponsors<br />
== Marketing ==<br />
* Design awesome swag (t-shirts, jackets, posters)<br />
* Reach out to reporters<br />
* Social media guru! (Facebook, Twitter, and Instagram posts)<br />
* Creating Snapchat filters for events<br />
* Designing flyers for upcoming talks<br />
* Going on launches to take pictures and videos<br />
== Outreach ==<br />
* Start discussions with local highschools and their science clubs<br />
* Organize or join an existing trip to a local school<br />
== Sponsors ==<br />
* Pursue a sponsorship (we'll walk you through how!)<br />
* Compile a list of bay-area aerospace companies<br />
== Website ==<br />
* Overhaul the budgeting system<br />
* Give the sponsors page dynamic content<br />
* Manage this very wiki<br />
* Manage our public and internal websites<br />
== Workspace ==<br />
* Make space-themed artwork to decorate ESIII<br />
* Plant more herbs<br />
* Paint a mural<br />
* Track inventory of supplies and parts</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Find_a_Project&diff=3099Find a Project2017-09-17T22:13:09Z<p>Ksafin: /* HABEES */</p>
<hr />
<div>= SSI Overload = <br />
So you've joined [https://ssi-teams.slack.com/join] Slack, maybe gone to a meeting or two, but you're not sure what you can do or what there even is to do with so many teams swirling around? Well you've come to right place! Below are all the projects each team is working on, what skills they utilize or where they're especially looking for help, and who you can contact to jump in! Think of this like a jobs listing page except that the jobs are always available and you apply by poking the person of contact and saying you want the job -- and it's probably yours.<br />
<br />
As you can see from the length of this list, there will always be more SSI to do than you will have hours in a day, week, month, or year -- don't feel pressured to overextend yourself! If you have questions, are feeling overwhelmed, or just want to chat with someone, don't hesitate to reach out to a leadership member. ''SSI exists for, and because of, its members (that's you.) Your sanity, health, and overall well-being always come first.''<br />
<br />
= Balloons =<br />
<br />
== HABMC ==<br />
HABMC has a request list a mile long, but here are a couple highlights. Feel free to slack {{slack-user|kai}} if you have ideas or questions<br />
* 3D visualizations using Cesium or Unity<br />
* Natural Language Processing for the commands module<br />
* Create a mobile app using React Native<br />
* Improved [[Balloons Radio Projects|RF integrations]]<br />
* Overhaul security on websocket connections<br />
* Navigation algorithms<br />
<br />
== ValBal ==<br />
<br />
== HABEES ==<br />
HABEES (High Altitude Balloon Electrical Engineering Systems) is the the umbrella project for all EE & CS projects outside of ValBal (that is, largely oriented at standard profile balloon launches). Because of this, there is a nearly limitless number of possibilities and projects to pursue within HABEES -- with that said, if you're new to EE or CS, or a veteran, and just generally want some ideas of what you can make, here's a bunch! Contact {{slack-user|kirillsafin}} to discuss working on any of these!<br />
<br />
* HONEY EE -- the primary electronics in HABEES revolve around the HONEY architecture. If you're interested in EE, you can test circuits and/or make PCB's for this architecture and have it fly with other boards. Head over to the [[Gen_2_Architecture | HONEY]] page to understand more about it.<br />
<br />
== BUZZ ==<br />
<br />
= Rockets =<br />
== Onboarding ==<br />
<br />
== Daedalus ==<br />
<br />
== Competition (IREC/SA Cup) ==<br />
* Structures<br />
* Payload<br />
* Recovery<br />
* Avionics, '''Leads: Sharon, Julea''' {{slack-user|splatt}} {{slack-user|juleachin}}<br />
** Design, implement, and test all the hardware and software that goes into our flight computers<br />
** Design and manufacture structures for avionics bay and work with other subteams to implement interfaces and integration processes<br />
** Design and test radio communications system for our rocket to talk to the ground <br />
** Write software to parse and visualize data, build a protective cooling case for laptops & other electronics so they don't die in the blazing desert heat and dust (yes there's a story here)<br />
* Launch Operations, '''Lead: WANTED'''<br />
** Work with each subteam to coordinate and prepare launch materials<br />
** Plan & execute travel and launch logistics <br />
** Oversee launch procedures, checklists, and go/no calls<br />
** Many more additional projects for ground support designable around personal interests<br />
* Simulations<br />
<br />
= Satellites =<br />
<br />
= Biology =<br />
<br />
= Policy =<br />
<br />
= Operations =<br />
<br />
== Community ==<br />
* Come up with a theme for Special Dinner and make decorations (like a model Falcon 9!)<br />
* Help {{slack-user|dragland}} run SSI general dinners<br />
* Plan and run general community events like Trivia Night, Pathfinder, and Movie Night<br />
== Diversity ==<br />
* Build connections with engineering diversity groups on campus<br />
* Help {{slack-user|ruqayyatoorawa}} run workshops<br />
== Events ==<br />
* Find an interesting company and arrange a tour or talk<br />
* Help handle logistics of an existing talk, like by meeting an astronaut and walking him to Durand 450<br />
* Give a CEO or Venture Capitalist a tour of ESIII<br />
== Finance == <br />
* Complete reimbursements <br />
* Apply for grants & seek out new sponsors<br />
== Marketing ==<br />
* Design awesome swag (t-shirts, jackets, posters)<br />
* Reach out to reporters<br />
* Social media guru! (Facebook, Twitter, and Instagram posts)<br />
* Creating Snapchat filters for events<br />
* Designing flyers for upcoming talks<br />
* Going on launches to take pictures and videos<br />
== Outreach ==<br />
* Start discussions with local highschools and their science clubs<br />
* Organize or join an existing trip to a local school<br />
== Sponsors ==<br />
* Pursue a sponsorship (we'll walk you through how!)<br />
* Compile a list of bay-area aerospace companies<br />
== Website ==<br />
* Overhaul the budgeting system<br />
* Give the sponsors page dynamic content<br />
* Manage this very wiki<br />
* Manage our public and internal websites<br />
== Workspace ==<br />
* Make space-themed artwork to decorate ESIII<br />
* Plant more herbs<br />
* Paint a mural<br />
* Track inventory of supplies and parts</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Find_a_Project&diff=3098Find a Project2017-09-17T22:13:01Z<p>Ksafin: /* HABEES */</p>
<hr />
<div>= SSI Overload = <br />
So you've joined [https://ssi-teams.slack.com/join] Slack, maybe gone to a meeting or two, but you're not sure what you can do or what there even is to do with so many teams swirling around? Well you've come to right place! Below are all the projects each team is working on, what skills they utilize or where they're especially looking for help, and who you can contact to jump in! Think of this like a jobs listing page except that the jobs are always available and you apply by poking the person of contact and saying you want the job -- and it's probably yours.<br />
<br />
As you can see from the length of this list, there will always be more SSI to do than you will have hours in a day, week, month, or year -- don't feel pressured to overextend yourself! If you have questions, are feeling overwhelmed, or just want to chat with someone, don't hesitate to reach out to a leadership member. ''SSI exists for, and because of, its members (that's you.) Your sanity, health, and overall well-being always come first.''<br />
<br />
= Balloons =<br />
<br />
== HABMC ==<br />
HABMC has a request list a mile long, but here are a couple highlights. Feel free to slack {{slack-user|kai}} if you have ideas or questions<br />
* 3D visualizations using Cesium or Unity<br />
* Natural Language Processing for the commands module<br />
* Create a mobile app using React Native<br />
* Improved [[Balloons Radio Projects|RF integrations]]<br />
* Overhaul security on websocket connections<br />
* Navigation algorithms<br />
<br />
== ValBal ==<br />
<br />
== HABEES ==<br />
HABEES (High Altitude Balloon Electrical Engineering Systems) is the the umbrella project for all EE & CS projects outside of ValBal (that is, largely oriented at standard profile balloon launches). Because of this, there is a nearly limitless number of possibilities and projects to pursue within HABEES -- with that said, if you're new to EE or CS, or a veteran, and just generally want some ideas of what you can make, here's a bunch! Contact {{slack-user|kirillsafin}} to discuss working on any of these!<br />
<br />
* HONEY EE -- the primary electronics in HABEES revolve around the HONEY architecture. If you're interested in EE, you can test circuits and/or make PCB's for this architecture and have it fly with other boards. Head over to the [[HONEY Gen_2_Architecture]] page to understand more about it.<br />
<br />
== BUZZ ==<br />
<br />
= Rockets =<br />
== Onboarding ==<br />
<br />
== Daedalus ==<br />
<br />
== Competition (IREC/SA Cup) ==<br />
* Structures<br />
* Payload<br />
* Recovery<br />
* Avionics, '''Leads: Sharon, Julea''' {{slack-user|splatt}} {{slack-user|juleachin}}<br />
** Design, implement, and test all the hardware and software that goes into our flight computers<br />
** Design and manufacture structures for avionics bay and work with other subteams to implement interfaces and integration processes<br />
** Design and test radio communications system for our rocket to talk to the ground <br />
** Write software to parse and visualize data, build a protective cooling case for laptops & other electronics so they don't die in the blazing desert heat and dust (yes there's a story here)<br />
* Launch Operations, '''Lead: WANTED'''<br />
** Work with each subteam to coordinate and prepare launch materials<br />
** Plan & execute travel and launch logistics <br />
** Oversee launch procedures, checklists, and go/no calls<br />
** Many more additional projects for ground support designable around personal interests<br />
* Simulations<br />
<br />
= Satellites =<br />
<br />
= Biology =<br />
<br />
= Policy =<br />
<br />
= Operations =<br />
<br />
== Community ==<br />
* Come up with a theme for Special Dinner and make decorations (like a model Falcon 9!)<br />
* Help {{slack-user|dragland}} run SSI general dinners<br />
* Plan and run general community events like Trivia Night, Pathfinder, and Movie Night<br />
== Diversity ==<br />
* Build connections with engineering diversity groups on campus<br />
* Help {{slack-user|ruqayyatoorawa}} run workshops<br />
== Events ==<br />
* Find an interesting company and arrange a tour or talk<br />
* Help handle logistics of an existing talk, like by meeting an astronaut and walking him to Durand 450<br />
* Give a CEO or Venture Capitalist a tour of ESIII<br />
== Finance == <br />
* Complete reimbursements <br />
* Apply for grants & seek out new sponsors<br />
== Marketing ==<br />
* Design awesome swag (t-shirts, jackets, posters)<br />
* Reach out to reporters<br />
* Social media guru! (Facebook, Twitter, and Instagram posts)<br />
* Creating Snapchat filters for events<br />
* Designing flyers for upcoming talks<br />
* Going on launches to take pictures and videos<br />
== Outreach ==<br />
* Start discussions with local highschools and their science clubs<br />
* Organize or join an existing trip to a local school<br />
== Sponsors ==<br />
* Pursue a sponsorship (we'll walk you through how!)<br />
* Compile a list of bay-area aerospace companies<br />
== Website ==<br />
* Overhaul the budgeting system<br />
* Give the sponsors page dynamic content<br />
* Manage this very wiki<br />
* Manage our public and internal websites<br />
== Workspace ==<br />
* Make space-themed artwork to decorate ESIII<br />
* Plant more herbs<br />
* Paint a mural<br />
* Track inventory of supplies and parts</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Find_a_Project&diff=3097Find a Project2017-09-17T22:12:52Z<p>Ksafin: /* HABEES */</p>
<hr />
<div>= SSI Overload = <br />
So you've joined [https://ssi-teams.slack.com/join] Slack, maybe gone to a meeting or two, but you're not sure what you can do or what there even is to do with so many teams swirling around? Well you've come to right place! Below are all the projects each team is working on, what skills they utilize or where they're especially looking for help, and who you can contact to jump in! Think of this like a jobs listing page except that the jobs are always available and you apply by poking the person of contact and saying you want the job -- and it's probably yours.<br />
<br />
As you can see from the length of this list, there will always be more SSI to do than you will have hours in a day, week, month, or year -- don't feel pressured to overextend yourself! If you have questions, are feeling overwhelmed, or just want to chat with someone, don't hesitate to reach out to a leadership member. ''SSI exists for, and because of, its members (that's you.) Your sanity, health, and overall well-being always come first.''<br />
<br />
= Balloons =<br />
<br />
== HABMC ==<br />
HABMC has a request list a mile long, but here are a couple highlights. Feel free to slack {{slack-user|kai}} if you have ideas or questions<br />
* 3D visualizations using Cesium or Unity<br />
* Natural Language Processing for the commands module<br />
* Create a mobile app using React Native<br />
* Improved [[Balloons Radio Projects|RF integrations]]<br />
* Overhaul security on websocket connections<br />
* Navigation algorithms<br />
<br />
== ValBal ==<br />
<br />
== HABEES ==<br />
HABEES (High Altitude Balloon Electrical Engineering Systems) is the the umbrella project for all EE & CS projects outside of ValBal (that is, largely oriented at standard profile balloon launches). Because of this, there is a nearly limitless number of possibilities and projects to pursue within HABEES -- with that said, if you're new to EE or CS, or a veteran, and just generally want some ideas of what you can make, here's a bunch! Contact {{slack-user|kirillsafin}} to discuss working on any of these!<br />
<br />
* HONEY EE -- the primary electronics in HABEES revolve around the HONEY architecture. If you're interested in EE, you can test circuits and/or make PCB's for this architecture and have it fly with other boards. Head over to the [[HONEY|Gen_2_Architecture]] page to understand more about it.<br />
<br />
== BUZZ ==<br />
<br />
= Rockets =<br />
== Onboarding ==<br />
<br />
== Daedalus ==<br />
<br />
== Competition (IREC/SA Cup) ==<br />
* Structures<br />
* Payload<br />
* Recovery<br />
* Avionics, '''Leads: Sharon, Julea''' {{slack-user|splatt}} {{slack-user|juleachin}}<br />
** Design, implement, and test all the hardware and software that goes into our flight computers<br />
** Design and manufacture structures for avionics bay and work with other subteams to implement interfaces and integration processes<br />
** Design and test radio communications system for our rocket to talk to the ground <br />
** Write software to parse and visualize data, build a protective cooling case for laptops & other electronics so they don't die in the blazing desert heat and dust (yes there's a story here)<br />
* Launch Operations, '''Lead: WANTED'''<br />
** Work with each subteam to coordinate and prepare launch materials<br />
** Plan & execute travel and launch logistics <br />
** Oversee launch procedures, checklists, and go/no calls<br />
** Many more additional projects for ground support designable around personal interests<br />
* Simulations<br />
<br />
= Satellites =<br />
<br />
= Biology =<br />
<br />
= Policy =<br />
<br />
= Operations =<br />
<br />
== Community ==<br />
* Come up with a theme for Special Dinner and make decorations (like a model Falcon 9!)<br />
* Help {{slack-user|dragland}} run SSI general dinners<br />
* Plan and run general community events like Trivia Night, Pathfinder, and Movie Night<br />
== Diversity ==<br />
* Build connections with engineering diversity groups on campus<br />
* Help {{slack-user|ruqayyatoorawa}} run workshops<br />
== Events ==<br />
* Find an interesting company and arrange a tour or talk<br />
* Help handle logistics of an existing talk, like by meeting an astronaut and walking him to Durand 450<br />
* Give a CEO or Venture Capitalist a tour of ESIII<br />
== Finance == <br />
* Complete reimbursements <br />
* Apply for grants & seek out new sponsors<br />
== Marketing ==<br />
* Design awesome swag (t-shirts, jackets, posters)<br />
* Reach out to reporters<br />
* Social media guru! (Facebook, Twitter, and Instagram posts)<br />
* Creating Snapchat filters for events<br />
* Designing flyers for upcoming talks<br />
* Going on launches to take pictures and videos<br />
== Outreach ==<br />
* Start discussions with local highschools and their science clubs<br />
* Organize or join an existing trip to a local school<br />
== Sponsors ==<br />
* Pursue a sponsorship (we'll walk you through how!)<br />
* Compile a list of bay-area aerospace companies<br />
== Website ==<br />
* Overhaul the budgeting system<br />
* Give the sponsors page dynamic content<br />
* Manage this very wiki<br />
* Manage our public and internal websites<br />
== Workspace ==<br />
* Make space-themed artwork to decorate ESIII<br />
* Plant more herbs<br />
* Paint a mural<br />
* Track inventory of supplies and parts</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Find_a_Project&diff=3096Find a Project2017-09-17T22:12:44Z<p>Ksafin: /* HABEES */</p>
<hr />
<div>= SSI Overload = <br />
So you've joined [https://ssi-teams.slack.com/join] Slack, maybe gone to a meeting or two, but you're not sure what you can do or what there even is to do with so many teams swirling around? Well you've come to right place! Below are all the projects each team is working on, what skills they utilize or where they're especially looking for help, and who you can contact to jump in! Think of this like a jobs listing page except that the jobs are always available and you apply by poking the person of contact and saying you want the job -- and it's probably yours.<br />
<br />
As you can see from the length of this list, there will always be more SSI to do than you will have hours in a day, week, month, or year -- don't feel pressured to overextend yourself! If you have questions, are feeling overwhelmed, or just want to chat with someone, don't hesitate to reach out to a leadership member. ''SSI exists for, and because of, its members (that's you.) Your sanity, health, and overall well-being always come first.''<br />
<br />
= Balloons =<br />
<br />
== HABMC ==<br />
HABMC has a request list a mile long, but here are a couple highlights. Feel free to slack {{slack-user|kai}} if you have ideas or questions<br />
* 3D visualizations using Cesium or Unity<br />
* Natural Language Processing for the commands module<br />
* Create a mobile app using React Native<br />
* Improved [[Balloons Radio Projects|RF integrations]]<br />
* Overhaul security on websocket connections<br />
* Navigation algorithms<br />
<br />
== ValBal ==<br />
<br />
== HABEES ==<br />
HABEES (High Altitude Balloon Electrical Engineering Systems) is the the umbrella project for all EE & CS projects outside of ValBal (that is, largely oriented at standard profile balloon launches). Because of this, there is a nearly limitless number of possibilities and projects to pursue within HABEES -- with that said, if you're new to EE or CS, or a veteran, and just generally want some ideas of what you can make, here's a bunch! Contact {{slack-user|kirillsafin}} to discuss working on any of these!<br />
<br />
* HONEY EE -- the primary electronics in HABEES revolve around the HONEY architecture. If you're interested in EE, you can test circuits and/or make PCB's for this architecture and have it fly with other boards. Head over to the [[HONEY|Gen_2_Architecture] page to understand more about it.<br />
<br />
== BUZZ ==<br />
<br />
= Rockets =<br />
== Onboarding ==<br />
<br />
== Daedalus ==<br />
<br />
== Competition (IREC/SA Cup) ==<br />
* Structures<br />
* Payload<br />
* Recovery<br />
* Avionics, '''Leads: Sharon, Julea''' {{slack-user|splatt}} {{slack-user|juleachin}}<br />
** Design, implement, and test all the hardware and software that goes into our flight computers<br />
** Design and manufacture structures for avionics bay and work with other subteams to implement interfaces and integration processes<br />
** Design and test radio communications system for our rocket to talk to the ground <br />
** Write software to parse and visualize data, build a protective cooling case for laptops & other electronics so they don't die in the blazing desert heat and dust (yes there's a story here)<br />
* Launch Operations, '''Lead: WANTED'''<br />
** Work with each subteam to coordinate and prepare launch materials<br />
** Plan & execute travel and launch logistics <br />
** Oversee launch procedures, checklists, and go/no calls<br />
** Many more additional projects for ground support designable around personal interests<br />
* Simulations<br />
<br />
= Satellites =<br />
<br />
= Biology =<br />
<br />
= Policy =<br />
<br />
= Operations =<br />
<br />
== Community ==<br />
* Come up with a theme for Special Dinner and make decorations (like a model Falcon 9!)<br />
* Help {{slack-user|dragland}} run SSI general dinners<br />
* Plan and run general community events like Trivia Night, Pathfinder, and Movie Night<br />
== Diversity ==<br />
* Build connections with engineering diversity groups on campus<br />
* Help {{slack-user|ruqayyatoorawa}} run workshops<br />
== Events ==<br />
* Find an interesting company and arrange a tour or talk<br />
* Help handle logistics of an existing talk, like by meeting an astronaut and walking him to Durand 450<br />
* Give a CEO or Venture Capitalist a tour of ESIII<br />
== Finance == <br />
* Complete reimbursements <br />
* Apply for grants & seek out new sponsors<br />
== Marketing ==<br />
* Design awesome swag (t-shirts, jackets, posters)<br />
* Reach out to reporters<br />
* Social media guru! (Facebook, Twitter, and Instagram posts)<br />
* Creating Snapchat filters for events<br />
* Designing flyers for upcoming talks<br />
* Going on launches to take pictures and videos<br />
== Outreach ==<br />
* Start discussions with local highschools and their science clubs<br />
* Organize or join an existing trip to a local school<br />
== Sponsors ==<br />
* Pursue a sponsorship (we'll walk you through how!)<br />
* Compile a list of bay-area aerospace companies<br />
== Website ==<br />
* Overhaul the budgeting system<br />
* Give the sponsors page dynamic content<br />
* Manage this very wiki<br />
* Manage our public and internal websites<br />
== Workspace ==<br />
* Make space-themed artwork to decorate ESIII<br />
* Plant more herbs<br />
* Paint a mural<br />
* Track inventory of supplies and parts</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Template:HONEY-sidebar&diff=3095Template:HONEY-sidebar2017-09-17T22:11:58Z<p>Ksafin: Reverted edits by Ariatedjarati (talk) to last revision by Ksafin</p>
<hr />
<div>{| class="wikitable" style="float:right; margin-left: 10px; font-size:85%;max-width:300px; text-align:center"<br />
|-<br />
{{red-headerwidebig}}'''{{{header}}}'''<br />
|-<br />
|colspan="2"| Part of the [[HONEY | HONEY Architecture]] series<br/> & the [[:Category:HABEES | HABEES]] series<br />
|-<br />
|-<br />
{{pipe}}-<br />
{{#if:{{{img link|}}}|<br />
{{pipe}}colspan="2" style="text-align:center;"{{pipe}} [[{{{img link}}} {{pipe}} 250px]]<br />
{{pipe}}-}}<br />
{{#if:{{{designer|}}}|<br />
{{pipe}}<b>Chief Designer</b><br />
{{pipe}}{{{designer}}}<br />
{{pipe}}-}}<br />
{{#if:{{{designers|}}}|<br />
{{pipe}}<b>Designers</b><br />
{{pipe}}{{{designers}}}<br />
{{pipe}}-}}<br />
{{#if:{{{techline|}}}|<br />
{{pipe}}<b>Technology Line</b><br />
{{pipe}}{{{techline}}}<br />
{{pipe}}-}}<br />
{{#if:{{{version|}}}|<br />
{{pipe}}<b>Version</b><br />
{{pipe}}{{{version}}}<br />
{{pipe}}-}}<br />
{{#if:{{{name|}}}|<br />
{{pipe}}<b>Name</b><br />
{{pipe}}{{{name}}}<br />
{{pipe}}-}}<br />
{{#if:{{{acronym|}}}|<br />
{{pipe}}<b>Acronym</b><br />
{{pipe}}{{{acronym}}}<br />
{{pipe}}-}}<br />
{{#if:{{{missions|}}}|<br />
{{pipe}}<b>Missions</b><br />
{{pipe}}{{{missions}}}<br />
{{pipe}}-}}<br />
|-<br />
{{red-headerwide}} General<br />
|- <br />
|colspan="2"| [[HONEY_Standardized_Connectors | HONEY Standards]] &bull; [[Venom_Breakout | Venom Breakout]] &bull; [[Fang_Breakout | Fang Breakout]] &bull; [[Naming_Conventions| Board Naming]]<br />
|-<br />
{{red-headerwide}} Core Software<br />
|- <br />
|colspan="2"| [[Gen 1 Software | STINGR ]]<br />
|-<br />
{{red-headerwide}} Core Avionics<br />
|- <br />
|colspan="2"| [[Balloons Gen 4 Avionics | The Count]]<br />
|-<br />
{{red-headerwide}} Core Power<br />
|- <br />
|colspan="2"| [[Balloon Gen 2 BMS | Biscuit]]<br />
|-<br />
{{red-headerwide}} Core Peripherals<br />
|- <br />
|colspan="2"| [[Balloons Gen 1 Expander | Cobra]] &bull; [[Balloons Gen 1 Breakout | Viper]] &bull; [[Balloons Gen 1 ProtoBoard | ProtoBee]]<br />
|-<br />
{{red-headerwide}} Core Radio<br />
|- <br />
|colspan="2"| [[Balloons Gen 1 Radio | Macaw]]<br />
|-<br />
{{red-headerwide}} Test & Prototype<br />
|- <br />
|colspan="2"| [[Balloons Gen 1 TestBench | QueenBee]]<br />
|-<br />
{{red-headerwide}} Guides<br />
|- <br />
|colspan="2"| [[HONEY Getting Started | Making a HONEY Board]] &bull; [[STINGR Getting Started | Using STINGR]] &bull; [[QueenBee Getting Started | Using QueenBee]] &bull; [[ProtoBee Getting Started | Making a Prototype]]<br />
|-<br />
{{red-headerwide|textalign=right}} <span class="plainlinks" style = "text-align: right"> [[Template:HONEY-sidebar | V]] &bull; [http://wiki.stanfordssi.org/index.php?title=Template:HONEY-sidebar&action=edit E] </span><br />
|}</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Find_a_Project&diff=3093Find a Project2017-09-17T22:09:11Z<p>Ksafin: /* HABEES */</p>
<hr />
<div>= SSI Overload = <br />
So you've joined [https://ssi-teams.slack.com/join] Slack, maybe gone to a meeting or two, but you're not sure what you can do or what there even is to do with so many teams swirling around? Well you've come to right place! Below are all the projects each team is working on, what skills they utilize or where they're especially looking for help, and who you can contact to jump in! Think of this like a jobs listing page except that the jobs are always available and you apply by poking the person of contact and saying you want the job -- and it's probably yours.<br />
<br />
As you can see from the length of this list, there will always be more SSI to do than you will have hours in a day, week, month, or year -- don't feel pressured to overextend yourself! If you have questions, are feeling overwhelmed, or just want to chat with someone, don't hesitate to reach out to a leadership member. ''SSI exists for, and because of, its members (that's you.) Your sanity, health, and overall well-being always come first.''<br />
<br />
= Balloons =<br />
<br />
== HABMC ==<br />
HABMC has a request list a mile long, but here are a couple highlights. Feel free to slack {{slack-user|kai}} if you have ideas or questions<br />
* 3D visualizations using Cesium or Unity<br />
* Natural Language Processing for the commands module<br />
* Create a mobile app using React Native<br />
* Improved [[Balloons Radio Projects|RF integrations]]<br />
* Overhaul security on websocket connections<br />
* Navigation algorithms<br />
<br />
== ValBal ==<br />
<br />
== HABEES ==<br />
HABEES (High Altitude Balloon Electrical Engineering Systems) is the the umbrella project for all EE & CS projects outside of ValBal (that is, largely oriented at standard profile balloon launches). Because of this, there is a nearly limitless number of possibilities and projects to pursue within HABEES -- with that said, if you're new to EE or CS, or a veteran, and just generally want some ideas of what you can make, here's a bunch! Contact {{slack-user|kirillsafin}} to discuss working on any of these!<br />
<br />
== BUZZ ==<br />
<br />
= Rockets =<br />
== Onboarding ==<br />
<br />
== Daedalus ==<br />
<br />
== Competition (IREC/SA Cup) ==<br />
* Structures<br />
* Payload<br />
* Recovery<br />
* Avionics<br />
** Avionics Bay Hardware & Software: Responsible for selecting parts (sensors, microcontrollers, connectors, etc), designing and validating circuit boards, programming everything, working with RF for testing, and making sure we have reliable, redundant flight computers that will trigger recovery separation events and send data back to the ground. '''Skills: EE, CS; Lead: Sharon''' {{slack-user|splatt}}<br />
** Avionics Bay Structures & Integration: Responsible for design and manufacturing of structures for avionics bay; working with HW/SW for PCB interfaces and connections; working with Recovery for interfaces and connections; working with Structures and Systems for overall design, rocket placement, and integration processes. '''Skills: ME, Good organization & communications skills; Lead: Julea''' {{slack-user|juleachin}}<br />
** Avionics Radio (RF) Communications: Responsible for designing and testing radio communications system for rocket to talk to the ground including: radio and antenna selection; link budget creation; ground testing (on & off campus); working with HW/SW and Ground Station for interfaces. '''Skills: EE; Lead: Sharon''' {{slack-user|splatt}}<br />
** Avionics Ground Station: Responsible for writing software to parse and visualize data; working with RF to coordinate ground radios and antennas; designing & building protective case to make sure laptops & other electronics don't die in the blazing desert heat and dust. '''Skills: ME, CS; Lead: WANTED'''<br />
* Launch Operations: Responsible for working with each subteam to coordinate and prepare launch materials; planning & executing travel and launch logistics; overseeing launch procedures, checklists, and go/no calls. Additional projects for ground support designable around personal interests. '''Skills: Organization, Willingness to just jump in; Lead: WANTED'''<br />
* Simulations<br />
<br />
= Satellites =<br />
<br />
= Biology =<br />
<br />
= Policy =<br />
<br />
= Operations =<br />
<br />
== Community ==<br />
* Come up with a theme for Special Dinner<br />
* Help {{slack-user|dragland}} run SSI general dinners<br />
* Plan and run general community events like Trivia Night, Pathfinder, and Movie Night<br />
== Diversity ==<br />
* Build connections to engineering diversity groups on campus<br />
* Help {{slack-user|ruqayyatoorawa}} run workshops<br />
== Events ==<br />
* Find a company and arrange a tour<br />
* Help handle logistics of an existing talk, like by meeting an astronaut and walking him to Durand 450<br />
* Give a CEO or Venture Capitalist a tour of ESIII<br />
== Finance == <br />
* Complete reimbursements<br />
* Search for grants<br />
== Marketing ==<br />
* Design a T-Shirt<br />
* Reach out to reporters<br />
* Regular Facebook, Twitter, and Instagram posts<br />
* Creating Snapchat filters for events<br />
* Make flyers for upcoming talks<br />
* Going on launches to take pictures and video<br />
== Outreach ==<br />
* Start discussions with local highschools and their science clubs<br />
* Organize or join an existing trip to a local school<br />
== Sponsors ==<br />
* Pursue a sponsorship (we'll walk you through how!)<br />
* Compile a list of bay-area aerospace companies<br />
== Website ==<br />
* Overhaul the budgeting system<br />
* Give the sponsors page dynamic content<br />
* Manage this very wiki<br />
== Workspace ==<br />
* Make space-themed artwork to decorate ESIII<br />
* Plant more herbs<br />
* Paint a mural<br />
* Track inventory of supplies and parts</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Find_a_Project&diff=3092Find a Project2017-09-17T22:08:39Z<p>Ksafin: /* HABEES */</p>
<hr />
<div>= SSI Overload = <br />
So you've joined [https://ssi-teams.slack.com/join] Slack, maybe gone to a meeting or two, but you're not sure what you can do or what there even is to do with so many teams swirling around? Well you've come to right place! Below are all the projects each team is working on, what skills they utilize or where they're especially looking for help, and who you can contact to jump in! Think of this like a jobs listing page except that the jobs are always available and you apply by poking the person of contact and saying you want the job -- and it's probably yours.<br />
<br />
As you can see from the length of this list, there will always be more SSI to do than you will have hours in a day, week, month, or year -- don't feel pressured to overextend yourself! If you have questions, are feeling overwhelmed, or just want to chat with someone, don't hesitate to reach out to a leadership member. ''SSI exists for, and because of, its members (that's you.) Your sanity, health, and overall well-being always come first.''<br />
<br />
= Balloons =<br />
<br />
== HABMC ==<br />
HABMC has a request list a mile long, but here are a couple highlights. Feel free to slack {{slack-user|kai}} if you have ideas or questions<br />
* 3D visualizations using Cesium or Unity<br />
* Natural Language Processing for the commands module<br />
* Create a mobile app using React Native<br />
* Improved [[Balloons Radio Projects|RF integrations]]<br />
* Overhaul security on websocket connections<br />
* Navigation algorithms<br />
<br />
== ValBal ==<br />
<br />
== HABEES ==<br />
HABEES (High Altitude Balloon Electrical Engineering Systems) is the the umbrella project for all EE & CS projects outside of ValBal (that is, largely oriented at standard profile balloon launches). Because of this, there is a nearly limitless number of possibilities and projects to pursue within HABEES -- with that said, if you're new to EE or CS, or a veteran, and just generally want some ideas of what you can make, here's a bunch! Contact<br />
<br />
== BUZZ ==<br />
<br />
= Rockets =<br />
== Onboarding ==<br />
<br />
== Daedalus ==<br />
<br />
== Competition (IREC/SA Cup) ==<br />
* Structures<br />
* Payload<br />
* Recovery<br />
* Avionics<br />
** Avionics Bay Hardware & Software: Responsible for selecting parts (sensors, microcontrollers, connectors, etc), designing and validating circuit boards, programming everything, working with RF for testing, and making sure we have reliable, redundant flight computers that will trigger recovery separation events and send data back to the ground. '''Skills: EE, CS; Lead: Sharon''' {{slack-user|splatt}}<br />
** Avionics Bay Structures & Integration: Responsible for design and manufacturing of structures for avionics bay; working with HW/SW for PCB interfaces and connections; working with Recovery for interfaces and connections; working with Structures and Systems for overall design, rocket placement, and integration processes. '''Skills: ME, Good organization & communications skills; Lead: Julea''' {{slack-user|juleachin}}<br />
** Avionics Radio (RF) Communications: Responsible for designing and testing radio communications system for rocket to talk to the ground including: radio and antenna selection; link budget creation; ground testing (on & off campus); working with HW/SW and Ground Station for interfaces. '''Skills: EE; Lead: Sharon''' {{slack-user|splatt}}<br />
** Avionics Ground Station: Responsible for writing software to parse and visualize data; working with RF to coordinate ground radios and antennas; designing & building protective case to make sure laptops & other electronics don't die in the blazing desert heat and dust. '''Skills: ME, CS; Lead: WANTED'''<br />
* Launch Operations: Responsible for working with each subteam to coordinate and prepare launch materials; planning & executing travel and launch logistics; overseeing launch procedures, checklists, and go/no calls. Additional projects for ground support designable around personal interests. '''Skills: Organization, Willingness to just jump in; Lead: WANTED'''<br />
* Simulations<br />
<br />
= Satellites =<br />
<br />
= Biology =<br />
<br />
= Policy =<br />
<br />
= Operations =<br />
<br />
== Community ==<br />
* Come up with a theme for Special Dinner<br />
* Help {{slack-user|dragland}} run SSI general dinners<br />
* Plan and run general community events like Trivia Night, Pathfinder, and Movie Night<br />
== Diversity ==<br />
* Build connections to engineering diversity groups on campus<br />
* Help {{slack-user|ruqayyatoorawa}} run workshops<br />
== Events ==<br />
* Find a company and arrange a tour<br />
* Help handle logistics of an existing talk, like by meeting an astronaut and walking him to Durand 450<br />
* Give a CEO or Venture Capitalist a tour of ESIII<br />
== Finance == <br />
* Complete reimbursements<br />
* Search for grants<br />
== Marketing ==<br />
* Design a T-Shirt<br />
* Reach out to reporters<br />
* Regular Facebook, Twitter, and Instagram posts<br />
* Creating Snapchat filters for events<br />
* Make flyers for upcoming talks<br />
* Going on launches to take pictures and video<br />
== Outreach ==<br />
* Start discussions with local highschools and their science clubs<br />
* Organize or join an existing trip to a local school<br />
== Sponsors ==<br />
* Pursue a sponsorship (we'll walk you through how!)<br />
* Compile a list of bay-area aerospace companies<br />
== Website ==<br />
* Overhaul the budgeting system<br />
* Give the sponsors page dynamic content<br />
* Manage this very wiki<br />
== Workspace ==<br />
* Make space-themed artwork to decorate ESIII<br />
* Plant more herbs<br />
* Paint a mural<br />
* Track inventory of supplies and parts</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Gen_2_Architecture&diff=2961Gen 2 Architecture2017-08-31T22:41:17Z<p>Ksafin: /* Data Bus */</p>
<hr />
<div>{{HONEY-sidebar<br />
| header = HONEY Architecture<br />
| img link = File:HONEY2.jpg<br />
| designer = Kirill Safin<br />
| techline = Balloons Core Architecture<br />
| version = Generation II<br />
| name = HONEY<br />
| acronym = Hardware Optimized Nested Electronics sYstem<br />
}}<br />
<br />
'''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. <br />
<br />
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.<br />
<br />
== Physical Specifications ==<br />
The HONEY architecture physical specifications comprise two categories: board specifications and stack specifications. <br />
<br />
=== Board Specification ===<br />
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.<br />
<br />
[[File:pcbtemplate.JPG | right| thumb | <center> PCB Template </center>]]<br />
<br />
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.<br />
<br />
The connectors and hardware used in each case can be found on the [[HONEY_Standardized_Connectors|HONEY Standardized Connectors Page]]<br />
* Data Bus: Harwin M22-6003005<br />
* Data Bus Shroud: Harwin M22-6043098<br />
* Power Bus: Samtec ESQ-105-38-G-D-LL <br />
* CAN Bus: Samtec ESQ-103-38-G-D-LL<br />
* CAN Jump Holder: Samtec TSW-104-07-G-D<br />
* CAN Terminating Jumper: Samtec SNT-100-BK-T<br />
* Stack Standoffs: Harwin R6104-02<br />
<br />
The physical footprint of a HONEY base-board can be found in the Altium library as "HABEES STACKUP" -- this features both a compliant and properly dimensioned PCB PCB, as well as a schematic symbol for accessing the power, data, and CAN buses.<br />
<br />
=== Stack Specification ===<br />
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. <br />
<br />
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.<br />
<br />
As of writing, The FCC (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. <br />
<br />
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.<br />
<br />
As defined by the current spec, the physical stack dimensioning is as so:<br />
<br />
* XY-Board Dimensions: 10x10 cm<br />
* Z-Board Thickness: 0.062"<br />
* Permissible Extension outside of Board Dimensions: 0.25"<br />
* Maximum spacing outside of Board Dimensions: 0.5"<br />
* Inter-Board spacing: 15.24mm, as defined by the Harwin R6104-02 standoff.<br />
* BMS-Payload Base spacing: 25mm, as defined by McMaster 94868A013, 10/12mm standoffs (McMaster 92005A120, 92005A122)<br />
* Avionics-Roof spacing: Variable, depending on stack height.<br />
<br />
Avionics-Roof spacing, by stack height:<br />
* 2-Boards (Base Stack): 51mm spacing, 60mm fixture bolt. (McMaster 94669A127, 92005A140)<br />
* 3-Boards (Base + 1 FTC): 35mm spacing, 45mm fixture bolt. (McMaster 94669A121, 92005A136)<br />
* 4-Boards (Base + 2 FTC): 16mm spacing, 30/25mm fixture bolt. (McMaster 94669A111, 92005A132, 92005A130)<br />
* 5-Boards (Base + 3 FTC): 25mm spacing, same as BMS. (McMaster 94868A013, 92005A120, 92005A122)<br />
<br />
== Electrical Specifications ==<br />
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.<br />
<br />
There are three defined buses, with specific purposes, limitations, and requirements as defined by the HONEY electrical specification.<br />
<br />
=== Power Bus ===<br />
The power bus pin-out is as follows:<br />
{| class="wikitable"<br />
|-<br />
|3.3V<br />
|5V<br />
|VBATT<br />
|VADJ<br />
|GND<br />
|-<br />
|3.3V<br />
|5V<br />
|VBATT<br />
|1.8V<br />
|GND<br />
|}<br />
<br />
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.<br />
<br />
[[File:pbus.JPG | right| thumb | <center> Power Bus Pin-Out </center>]]<br />
<br />
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). <br />
<br />
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.<br />
<br />
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).<br />
<br />
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. <br />
<br />
Lastly, the power bus provides two nodes for common ground, which must be implemented to common-ground a board to the BMS/flight-stack.<br />
<br />
=== Data Bus ===<br />
<br />
<br />
[[File:dbus_top.JPG | right| thumb | <center> Data Bus Top </center>]]<br />
[[File:dbus_bottom.JPG | right| thumb | <center> Data Bus Bottom </center>]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
{| class="wikitable"<br />
|-<br />
|Pin<br />
|Net<br />
|Purpose<br />
|REQ?<br />
|-<br />
|1-4<br />
|GND<br />
|GND<br />
|YES<br />
|-<br />
|5<br />
|VBCKP<br />
|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.<br />
|NO<br />
|-<br />
|6<br />
|R_MCU<br />
|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.<br />
|NO<br />
|-<br />
|7<br />
|R_ALL<br />
|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.<br />
|YES<br />
|-<br />
|8<br />
|S_READY<br />
|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. <br />
|YES<br />
|-<br />
|9<br />
|LOW_PWR<br />
|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.<br />
|YES<br />
|-<br />
|10<br />
|FMODE<br />
|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.<br />
|YES<br />
|-<br />
|11-14<br />
|SYS_F(3-6)<br />
|Reserved System Flags for future purposes.<br />
|YES<br />
|-<br />
|15, 16<br />
|SDA/SCL<br />
|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.<br />
|NO<br />
|-<br />
|17-19<br />
|SPI<br />
|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.<br />
|NO<br />
|-<br />
|20<br />
|VA_PWM<br />
|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.<br />
|NO<br />
|-<br />
|21<br />
|CHIRP<br />
|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.<br />
|YES<br />
|-<br />
|22<br />
|RX2<br />
|This pin is the RX partner of the CHIRP pin, which has no likely purpose, and should not be implemented.<br />
|NO<br />
|-<br />
|23/24<br />
|UART4<br />
|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.<br />
|NO<br />
|-<br />
|25/26<br />
|UART6<br />
|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.<br />
|NO<br />
|-<br />
|27/28<br />
|DAC0/1<br />
|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.<br />
|NO<br />
|-<br />
|29-36, 38-40<br />
|IO/1 - IO/13<br />
|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.<br />
|NO<br />
|-<br />
|41<br />
|BLUEJ_PRESENT<br />
|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.<br />
|NO<br />
|-<br />
|81-86<br />
|RB Breakout<br />
|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). <br />
|NO<br />
|-<br />
|105-108<br />
|12V<br />
|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. <br />
|NO<br />
|-<br />
|113/114<br />
|(+5V and -5V) (SIG)<br />
|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.<br />
|NO<br />
|-<br />
|115/114<br />
|(+12V and -12V) (SIG)<br />
|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.<br />
|NO<br />
|-<br />
|37, 42-111, 117-120<br />
|NC<br />
|Reserved -- these can be used for any purpose at the time being, as long as it is agreed in advance.<br />
|NO<br />
|-<br />
|112<br />
|CAN_SPD<br />
|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.<br />
|YES<br />
|}<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
|GND<br />
|GND<br />
|GND<br />
|GND<br />
|-<br />
|VBCKP<br />
|R_MCU<br />
|R_ALL<br />
|S_READY<br />
|-<br />
|LOW_PWR<br />
|FMODE<br />
|SYS_F3<br />
|SYS_F4<br />
|-<br />
|SYS_F5<br />
|SYS_F6<br />
|SDA<br />
|SCL<br />
|-<br />
|MOSI<br />
|MISO<br />
|SCLK<br />
|VA_PWM<br />
|-<br />
|CHIRP<br />
|RX2<br />
|TX4<br />
|RX4<br />
|-<br />
|TX6<br />
|RX6<br />
|DAC0<br />
|DAC1<br />
|-<br />
|IO/1<br />
|IO/2<br />
|IO/3<br />
|IO/4<br />
|-<br />
|IO/5<br />
|IO/6<br />
|IO/7<br />
|IO/8<br />
|-<br />
|RESERVED<br />
|IO/10<br />
|IO/11<br />
|IO/12<br />
|-<br />
|BLUEJ_PRESENT<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RB_TX --><br />
|RB_RX <--<br />
|RB_NETAV<br />
|RB_SLP<br />
|-<br />
|RB_RI<br />
|RB_EN<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|12V<br />
|12V<br />
|12V<br />
|12V<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|CAN_SPD<br />
|-<br />
|Pos 5V (SIG)<br />
|Neg 5V (SIG)<br />
|Pos 12V (SIG)<br />
|Neg 12V (SIG)<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|}<br />
<br />
=== CAN BUS ===<br />
<br />
[[File:cbus.JPG | right| thumb | <center> CAN Bus Pin-Out </center>]]<br />
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. <br />
<br />
Every board, except in very extenuating circumstances, is required to implement the CAN bus.<br />
<br />
The required, standardized HONEY transceiver is the TI_SN65HVD230.<br />
<br />
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.<br />
<br />
Shown here is the CAN schematic that should be implemented on any board.<br />
[[File:can.JPG | right| thumb | <center> CAN Schematic </center>]]<br />
{| class="wikitable"<br />
|-<br />
|CAN1_H<br />
|CAN1_L<br />
|-<br />
|CAN2_H<br />
|CAN2_L<br />
|-<br />
|3.3V_CAN<br />
|GND<br />
|}<br />
<br />
=== CAN Terminating Jumpers ===<br />
<br />
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.<br />
<br />
[[File:can_stack.JPG | right| thumb | <center> CAN Stack Implementation </center>]]<br />
[[File:can_wires.JPG | right| thumb | <center> CAN Feed-through </center>]]<br />
<br />
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. <br />
<br />
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.<br />
<br />
{| class="wikitable"<br />
|-<br />
|1_TERM_1<br />
|1_TERM_2<br />
|-<br />
|2_TERM_1<br />
|2_TERM_2<br />
|-<br />
|NC<br />
|NC<br />
|-<br />
|NC<br />
|NC<br />
|}<br />
<br />
<br />
[[File:allcan.JPG | right| thumb | <center> CAN, showing terminating impedance implemented </center>]]<br />
<br />
<br />
== Software Specification ==<br />
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.<br />
<br />
The full STINGR specification can be found on the [[Gen 1 Software|STINGR]] page.<br />
<br />
== Implementation ==<br />
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.<br />
<br />
=== Required Implementation ===<br />
#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.<br />
#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.<br />
#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.<br />
#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)<br />
#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). <br />
#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.<br />
#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.<br />
#Be sure to use +3.3_CAN pin from the CAN Bus EXCLUSIVELY to power your Transceiver, and make sure it powers nothing else.<br />
#Make sure pin 7 (R_ALL) is directly wired to your MCU reset pin, to allow Core Avionics remote reset. <br />
#If using RTC, make sure to implement pin 5 (+VBCKP). <br />
#Make sure no component of the board extends more than 0.25" over the board edge.<br />
<br />
=== Self-Help FAQ ===<br />
#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. <br />
#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. <br />
#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).<br />
#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.<br />
#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.<br />
#Make sure, unless for some reason you're using it, CAN2 is not connected to anything.<br />
#Make sure +3.3_CAN is used only to power the transceiver, and nothing else. <br />
#Make sure CAN_SPD is hard-wired to the transceiver speed pin.<br />
<br />
[[Category: High Altitude Balloons]][[Category: HABEES]][[Category: HONEY]]</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Gen_2_Architecture&diff=2960Gen 2 Architecture2017-08-31T21:57:05Z<p>Ksafin: /* Data Bus */</p>
<hr />
<div>{{HONEY-sidebar<br />
| header = HONEY Architecture<br />
| img link = File:HONEY2.jpg<br />
| designer = Kirill Safin<br />
| techline = Balloons Core Architecture<br />
| version = Generation II<br />
| name = HONEY<br />
| acronym = Hardware Optimized Nested Electronics sYstem<br />
}}<br />
<br />
'''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. <br />
<br />
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.<br />
<br />
== Physical Specifications ==<br />
The HONEY architecture physical specifications comprise two categories: board specifications and stack specifications. <br />
<br />
=== Board Specification ===<br />
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.<br />
<br />
[[File:pcbtemplate.JPG | right| thumb | <center> PCB Template </center>]]<br />
<br />
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.<br />
<br />
The connectors and hardware used in each case can be found on the [[HONEY_Standardized_Connectors|HONEY Standardized Connectors Page]]<br />
* Data Bus: Harwin M22-6003005<br />
* Data Bus Shroud: Harwin M22-6043098<br />
* Power Bus: Samtec ESQ-105-38-G-D-LL <br />
* CAN Bus: Samtec ESQ-103-38-G-D-LL<br />
* CAN Jump Holder: Samtec TSW-104-07-G-D<br />
* CAN Terminating Jumper: Samtec SNT-100-BK-T<br />
* Stack Standoffs: Harwin R6104-02<br />
<br />
The physical footprint of a HONEY base-board can be found in the Altium library as "HABEES STACKUP" -- this features both a compliant and properly dimensioned PCB PCB, as well as a schematic symbol for accessing the power, data, and CAN buses.<br />
<br />
=== Stack Specification ===<br />
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. <br />
<br />
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.<br />
<br />
As of writing, The FCC (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. <br />
<br />
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.<br />
<br />
As defined by the current spec, the physical stack dimensioning is as so:<br />
<br />
* XY-Board Dimensions: 10x10 cm<br />
* Z-Board Thickness: 0.062"<br />
* Permissible Extension outside of Board Dimensions: 0.25"<br />
* Maximum spacing outside of Board Dimensions: 0.5"<br />
* Inter-Board spacing: 15.24mm, as defined by the Harwin R6104-02 standoff.<br />
* BMS-Payload Base spacing: 25mm, as defined by McMaster 94868A013, 10/12mm standoffs (McMaster 92005A120, 92005A122)<br />
* Avionics-Roof spacing: Variable, depending on stack height.<br />
<br />
Avionics-Roof spacing, by stack height:<br />
* 2-Boards (Base Stack): 51mm spacing, 60mm fixture bolt. (McMaster 94669A127, 92005A140)<br />
* 3-Boards (Base + 1 FTC): 35mm spacing, 45mm fixture bolt. (McMaster 94669A121, 92005A136)<br />
* 4-Boards (Base + 2 FTC): 16mm spacing, 30/25mm fixture bolt. (McMaster 94669A111, 92005A132, 92005A130)<br />
* 5-Boards (Base + 3 FTC): 25mm spacing, same as BMS. (McMaster 94868A013, 92005A120, 92005A122)<br />
<br />
== Electrical Specifications ==<br />
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.<br />
<br />
There are three defined buses, with specific purposes, limitations, and requirements as defined by the HONEY electrical specification.<br />
<br />
=== Power Bus ===<br />
The power bus pin-out is as follows:<br />
{| class="wikitable"<br />
|-<br />
|3.3V<br />
|5V<br />
|VBATT<br />
|VADJ<br />
|GND<br />
|-<br />
|3.3V<br />
|5V<br />
|VBATT<br />
|1.8V<br />
|GND<br />
|}<br />
<br />
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.<br />
<br />
[[File:pbus.JPG | right| thumb | <center> Power Bus Pin-Out </center>]]<br />
<br />
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). <br />
<br />
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.<br />
<br />
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).<br />
<br />
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. <br />
<br />
Lastly, the power bus provides two nodes for common ground, which must be implemented to common-ground a board to the BMS/flight-stack.<br />
<br />
=== Data Bus ===<br />
<br />
<br />
[[File:dbus_top.JPG | right| thumb | <center> Data Bus Top </center>]]<br />
[[File:dbus_bottom.JPG | right| thumb | <center> Data Bus Bottom </center>]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
{| class="wikitable"<br />
|-<br />
|Pin<br />
|Net<br />
|Purpose<br />
|REQ?<br />
|-<br />
|1-4<br />
|GND<br />
|GND<br />
|YES<br />
|-<br />
|5<br />
|VBCKP<br />
|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.<br />
|NO<br />
|-<br />
|6<br />
|R_MCU<br />
|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.<br />
|NO<br />
|-<br />
|7<br />
|R_ALL<br />
|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.<br />
|YES<br />
|-<br />
|8<br />
|S_READY<br />
|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. <br />
|YES<br />
|-<br />
|9<br />
|LOW_PWR<br />
|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.<br />
|YES<br />
|-<br />
|10<br />
|FMODE<br />
|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.<br />
|YES<br />
|-<br />
|11-14<br />
|SYS_F(3-6)<br />
|Reserved System Flags for future purposes.<br />
|YES<br />
|-<br />
|15, 16<br />
|SDA/SCL<br />
|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.<br />
|NO<br />
|-<br />
|17-19<br />
|SPI<br />
|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.<br />
|NO<br />
|-<br />
|20<br />
|VA_PWM<br />
|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.<br />
|NO<br />
|-<br />
|21<br />
|CHIRP<br />
|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.<br />
|YES<br />
|-<br />
|22<br />
|RX2<br />
|This pin is the RX partner of the CHIRP pin, which has no likely purpose, and should not be implemented.<br />
|NO<br />
|-<br />
|23/24<br />
|UART4<br />
|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.<br />
|NO<br />
|-<br />
|25/26<br />
|UART6<br />
|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.<br />
|NO<br />
|-<br />
|27/28<br />
|DAC0/1<br />
|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.<br />
|NO<br />
|-<br />
|29-36, 38-41<br />
|IO/1 - IO/13<br />
|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.<br />
|NO<br />
|-<br />
|81-86<br />
|RB Breakout<br />
|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). <br />
|NO<br />
|-<br />
|105-108<br />
|12V<br />
|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. <br />
|NO<br />
|-<br />
|113/114<br />
|(+5V and -5V) (SIG)<br />
|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.<br />
|NO<br />
|-<br />
|115/114<br />
|(+12V and -12V) (SIG)<br />
|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.<br />
|NO<br />
|-<br />
|37, 42-111, 117-120<br />
|NC<br />
|Reserved -- these can be used for any purpose at the time being, as long as it is agreed in advance.<br />
|NO<br />
|-<br />
|112<br />
|CAN_SPD<br />
|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.<br />
|YES<br />
|}<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
|GND<br />
|GND<br />
|GND<br />
|GND<br />
|-<br />
|VBCKP<br />
|R_MCU<br />
|R_ALL<br />
|S_READY<br />
|-<br />
|LOW_PWR<br />
|FMODE<br />
|SYS_F3<br />
|SYS_F4<br />
|-<br />
|SYS_F5<br />
|SYS_F6<br />
|SDA<br />
|SCL<br />
|-<br />
|MOSI<br />
|MISO<br />
|SCLK<br />
|VA_PWM<br />
|-<br />
|CHIRP<br />
|RX2<br />
|TX4<br />
|RX4<br />
|-<br />
|TX6<br />
|RX6<br />
|DAC0<br />
|DAC1<br />
|-<br />
|IO/1<br />
|IO/2<br />
|IO/3<br />
|IO/4<br />
|-<br />
|IO/5<br />
|IO/6<br />
|IO/7<br />
|IO/8<br />
|-<br />
|RESERVED<br />
|IO/10<br />
|IO/11<br />
|IO/12<br />
|-<br />
|IO/13<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RB_TX --><br />
|RB_RX <--<br />
|RB_NETAV<br />
|RB_SLP<br />
|-<br />
|RB_RI<br />
|RB_EN<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|12V<br />
|12V<br />
|12V<br />
|12V<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|CAN_SPD<br />
|-<br />
|Pos 5V (SIG)<br />
|Neg 5V (SIG)<br />
|Pos 12V (SIG)<br />
|Neg 12V (SIG)<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|}<br />
<br />
=== CAN BUS ===<br />
<br />
[[File:cbus.JPG | right| thumb | <center> CAN Bus Pin-Out </center>]]<br />
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. <br />
<br />
Every board, except in very extenuating circumstances, is required to implement the CAN bus.<br />
<br />
The required, standardized HONEY transceiver is the TI_SN65HVD230.<br />
<br />
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.<br />
<br />
Shown here is the CAN schematic that should be implemented on any board.<br />
[[File:can.JPG | right| thumb | <center> CAN Schematic </center>]]<br />
{| class="wikitable"<br />
|-<br />
|CAN1_H<br />
|CAN1_L<br />
|-<br />
|CAN2_H<br />
|CAN2_L<br />
|-<br />
|3.3V_CAN<br />
|GND<br />
|}<br />
<br />
=== CAN Terminating Jumpers ===<br />
<br />
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.<br />
<br />
[[File:can_stack.JPG | right| thumb | <center> CAN Stack Implementation </center>]]<br />
[[File:can_wires.JPG | right| thumb | <center> CAN Feed-through </center>]]<br />
<br />
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. <br />
<br />
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.<br />
<br />
{| class="wikitable"<br />
|-<br />
|1_TERM_1<br />
|1_TERM_2<br />
|-<br />
|2_TERM_1<br />
|2_TERM_2<br />
|-<br />
|NC<br />
|NC<br />
|-<br />
|NC<br />
|NC<br />
|}<br />
<br />
<br />
[[File:allcan.JPG | right| thumb | <center> CAN, showing terminating impedance implemented </center>]]<br />
<br />
<br />
== Software Specification ==<br />
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.<br />
<br />
The full STINGR specification can be found on the [[Gen 1 Software|STINGR]] page.<br />
<br />
== Implementation ==<br />
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.<br />
<br />
=== Required Implementation ===<br />
#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.<br />
#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.<br />
#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.<br />
#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)<br />
#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). <br />
#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.<br />
#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.<br />
#Be sure to use +3.3_CAN pin from the CAN Bus EXCLUSIVELY to power your Transceiver, and make sure it powers nothing else.<br />
#Make sure pin 7 (R_ALL) is directly wired to your MCU reset pin, to allow Core Avionics remote reset. <br />
#If using RTC, make sure to implement pin 5 (+VBCKP). <br />
#Make sure no component of the board extends more than 0.25" over the board edge.<br />
<br />
=== Self-Help FAQ ===<br />
#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. <br />
#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. <br />
#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).<br />
#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.<br />
#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.<br />
#Make sure, unless for some reason you're using it, CAN2 is not connected to anything.<br />
#Make sure +3.3_CAN is used only to power the transceiver, and nothing else. <br />
#Make sure CAN_SPD is hard-wired to the transceiver speed pin.<br />
<br />
[[Category: High Altitude Balloons]][[Category: HABEES]][[Category: HONEY]]</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Gen_2_Architecture&diff=2959Gen 2 Architecture2017-08-31T21:54:12Z<p>Ksafin: /* Data Bus */</p>
<hr />
<div>{{HONEY-sidebar<br />
| header = HONEY Architecture<br />
| img link = File:HONEY2.jpg<br />
| designer = Kirill Safin<br />
| techline = Balloons Core Architecture<br />
| version = Generation II<br />
| name = HONEY<br />
| acronym = Hardware Optimized Nested Electronics sYstem<br />
}}<br />
<br />
'''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. <br />
<br />
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.<br />
<br />
== Physical Specifications ==<br />
The HONEY architecture physical specifications comprise two categories: board specifications and stack specifications. <br />
<br />
=== Board Specification ===<br />
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.<br />
<br />
[[File:pcbtemplate.JPG | right| thumb | <center> PCB Template </center>]]<br />
<br />
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.<br />
<br />
The connectors and hardware used in each case can be found on the [[HONEY_Standardized_Connectors|HONEY Standardized Connectors Page]]<br />
* Data Bus: Harwin M22-6003005<br />
* Data Bus Shroud: Harwin M22-6043098<br />
* Power Bus: Samtec ESQ-105-38-G-D-LL <br />
* CAN Bus: Samtec ESQ-103-38-G-D-LL<br />
* CAN Jump Holder: Samtec TSW-104-07-G-D<br />
* CAN Terminating Jumper: Samtec SNT-100-BK-T<br />
* Stack Standoffs: Harwin R6104-02<br />
<br />
The physical footprint of a HONEY base-board can be found in the Altium library as "HABEES STACKUP" -- this features both a compliant and properly dimensioned PCB PCB, as well as a schematic symbol for accessing the power, data, and CAN buses.<br />
<br />
=== Stack Specification ===<br />
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. <br />
<br />
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.<br />
<br />
As of writing, The FCC (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. <br />
<br />
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.<br />
<br />
As defined by the current spec, the physical stack dimensioning is as so:<br />
<br />
* XY-Board Dimensions: 10x10 cm<br />
* Z-Board Thickness: 0.062"<br />
* Permissible Extension outside of Board Dimensions: 0.25"<br />
* Maximum spacing outside of Board Dimensions: 0.5"<br />
* Inter-Board spacing: 15.24mm, as defined by the Harwin R6104-02 standoff.<br />
* BMS-Payload Base spacing: 25mm, as defined by McMaster 94868A013, 10/12mm standoffs (McMaster 92005A120, 92005A122)<br />
* Avionics-Roof spacing: Variable, depending on stack height.<br />
<br />
Avionics-Roof spacing, by stack height:<br />
* 2-Boards (Base Stack): 51mm spacing, 60mm fixture bolt. (McMaster 94669A127, 92005A140)<br />
* 3-Boards (Base + 1 FTC): 35mm spacing, 45mm fixture bolt. (McMaster 94669A121, 92005A136)<br />
* 4-Boards (Base + 2 FTC): 16mm spacing, 30/25mm fixture bolt. (McMaster 94669A111, 92005A132, 92005A130)<br />
* 5-Boards (Base + 3 FTC): 25mm spacing, same as BMS. (McMaster 94868A013, 92005A120, 92005A122)<br />
<br />
== Electrical Specifications ==<br />
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.<br />
<br />
There are three defined buses, with specific purposes, limitations, and requirements as defined by the HONEY electrical specification.<br />
<br />
=== Power Bus ===<br />
The power bus pin-out is as follows:<br />
{| class="wikitable"<br />
|-<br />
|3.3V<br />
|5V<br />
|VBATT<br />
|VADJ<br />
|GND<br />
|-<br />
|3.3V<br />
|5V<br />
|VBATT<br />
|1.8V<br />
|GND<br />
|}<br />
<br />
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.<br />
<br />
[[File:pbus.JPG | right| thumb | <center> Power Bus Pin-Out </center>]]<br />
<br />
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). <br />
<br />
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.<br />
<br />
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).<br />
<br />
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. <br />
<br />
Lastly, the power bus provides two nodes for common ground, which must be implemented to common-ground a board to the BMS/flight-stack.<br />
<br />
=== Data Bus ===<br />
<br />
<br />
[[File:dbus_top.JPG | right| thumb | <center> Data Bus Top </center>]]<br />
[[File:dbus_bottom.JPG | right| thumb | <center> Data Bus Bottom </center>]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
{| class="wikitable"<br />
|-<br />
|Pin<br />
|Net<br />
|Purpose<br />
|REQ?<br />
|-<br />
|1-4<br />
|GND<br />
|GND<br />
|YES<br />
|-<br />
|5<br />
|VBCKP<br />
|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.<br />
|NO<br />
|-<br />
|6<br />
|R_MCU<br />
|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.<br />
|NO<br />
|-<br />
|7<br />
|R_ALL<br />
|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.<br />
|YES<br />
|-<br />
|8<br />
|S_READY<br />
|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. <br />
|YES<br />
|-<br />
|9<br />
|LOW_PWR<br />
|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.<br />
|YES<br />
|-<br />
|10<br />
|FMODE<br />
|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.<br />
|YES<br />
|-<br />
|11-14<br />
|SYS_F(3-6)<br />
|Reserved System Flags for future purposes.<br />
|YES<br />
|-<br />
|15, 16<br />
|SDA/SCL<br />
|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.<br />
|NO<br />
|-<br />
|17-19<br />
|SPI<br />
|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.<br />
|NO<br />
|-<br />
|20<br />
|VA_PWM<br />
|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.<br />
|NO<br />
|-<br />
|21<br />
|CHIRP<br />
|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.<br />
|YES<br />
|-<br />
|22<br />
|RX2<br />
|This pin is the RX partner of the CHIRP pin, which has no likely purpose, and should not be implemented.<br />
|NO<br />
|-<br />
|23/24<br />
|UART4<br />
|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.<br />
|NO<br />
|-<br />
|25/26<br />
|UART6<br />
|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.<br />
|NO<br />
|-<br />
|27/28<br />
|DAC0/1<br />
|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.<br />
|NO<br />
|-<br />
|29-36, 38-41<br />
|IO/1 - IO/13<br />
|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.<br />
|NO<br />
|-<br />
|105-108<br />
|12V<br />
|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. <br />
|NO<br />
|-<br />
|113/114<br />
|(+5V and -5V) (SIG)<br />
|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.<br />
|NO<br />
|-<br />
|115/114<br />
|(+12V and -12V) (SIG)<br />
|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.<br />
|NO<br />
|-<br />
|37, 42-111, 117-120<br />
|NC<br />
|Reserved -- these can be used for any purpose at the time being, as long as it is agreed in advance.<br />
|NO<br />
|-<br />
|112<br />
|CAN_SPD<br />
|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.<br />
|YES<br />
|}<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
|GND<br />
|GND<br />
|GND<br />
|GND<br />
|-<br />
|VBCKP<br />
|R_MCU<br />
|R_ALL<br />
|S_READY<br />
|-<br />
|LOW_PWR<br />
|FMODE<br />
|SYS_F3<br />
|SYS_F4<br />
|-<br />
|SYS_F5<br />
|SYS_F6<br />
|SDA<br />
|SCL<br />
|-<br />
|MOSI<br />
|MISO<br />
|SCLK<br />
|VA_PWM<br />
|-<br />
|CHIRP<br />
|RX2<br />
|TX4<br />
|RX4<br />
|-<br />
|TX6<br />
|RX6<br />
|DAC0<br />
|DAC1<br />
|-<br />
|IO/1<br />
|IO/2<br />
|IO/3<br />
|IO/4<br />
|-<br />
|IO/5<br />
|IO/6<br />
|IO/7<br />
|IO/8<br />
|-<br />
|RESERVED<br />
|IO/10<br />
|IO/11<br />
|IO/12<br />
|-<br />
|IO/13<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RB_TX --><br />
|RB_RX <--<br />
|RB_NETAV<br />
|RB_SLP<br />
|-<br />
|RB_RI<br />
|RB_EN<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|-<br />
|12V<br />
|12V<br />
|12V<br />
|12V<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|CAN_SPD<br />
|-<br />
|Pos 5V (SIG)<br />
|Neg 5V (SIG)<br />
|Pos 12V (SIG)<br />
|Neg 12V (SIG)<br />
|-<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|RESERVED<br />
|}<br />
<br />
=== CAN BUS ===<br />
<br />
[[File:cbus.JPG | right| thumb | <center> CAN Bus Pin-Out </center>]]<br />
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. <br />
<br />
Every board, except in very extenuating circumstances, is required to implement the CAN bus.<br />
<br />
The required, standardized HONEY transceiver is the TI_SN65HVD230.<br />
<br />
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.<br />
<br />
Shown here is the CAN schematic that should be implemented on any board.<br />
[[File:can.JPG | right| thumb | <center> CAN Schematic </center>]]<br />
{| class="wikitable"<br />
|-<br />
|CAN1_H<br />
|CAN1_L<br />
|-<br />
|CAN2_H<br />
|CAN2_L<br />
|-<br />
|3.3V_CAN<br />
|GND<br />
|}<br />
<br />
=== CAN Terminating Jumpers ===<br />
<br />
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.<br />
<br />
[[File:can_stack.JPG | right| thumb | <center> CAN Stack Implementation </center>]]<br />
[[File:can_wires.JPG | right| thumb | <center> CAN Feed-through </center>]]<br />
<br />
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. <br />
<br />
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.<br />
<br />
{| class="wikitable"<br />
|-<br />
|1_TERM_1<br />
|1_TERM_2<br />
|-<br />
|2_TERM_1<br />
|2_TERM_2<br />
|-<br />
|NC<br />
|NC<br />
|-<br />
|NC<br />
|NC<br />
|}<br />
<br />
<br />
[[File:allcan.JPG | right| thumb | <center> CAN, showing terminating impedance implemented </center>]]<br />
<br />
<br />
== Software Specification ==<br />
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.<br />
<br />
The full STINGR specification can be found on the [[Gen 1 Software|STINGR]] page.<br />
<br />
== Implementation ==<br />
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.<br />
<br />
=== Required Implementation ===<br />
#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.<br />
#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.<br />
#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.<br />
#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)<br />
#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). <br />
#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.<br />
#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.<br />
#Be sure to use +3.3_CAN pin from the CAN Bus EXCLUSIVELY to power your Transceiver, and make sure it powers nothing else.<br />
#Make sure pin 7 (R_ALL) is directly wired to your MCU reset pin, to allow Core Avionics remote reset. <br />
#If using RTC, make sure to implement pin 5 (+VBCKP). <br />
#Make sure no component of the board extends more than 0.25" over the board edge.<br />
<br />
=== Self-Help FAQ ===<br />
#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. <br />
#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. <br />
#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).<br />
#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.<br />
#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.<br />
#Make sure, unless for some reason you're using it, CAN2 is not connected to anything.<br />
#Make sure +3.3_CAN is used only to power the transceiver, and nothing else. <br />
#Make sure CAN_SPD is hard-wired to the transceiver speed pin.<br />
<br />
[[Category: High Altitude Balloons]][[Category: HABEES]][[Category: HONEY]]</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Naming_Conventions&diff=2956Naming Conventions2017-08-23T23:22:14Z<p>Ksafin: </p>
<hr />
<div>{{HONEY-sidebar<br />
| header = Naming Conventions<br />
| techline = Balloons Core Architecture<br />
}}<br />
<br />
Boards developed within HABEES and HONEY can have, as their designer wishes, any name (as long as it is appropriate). However, there are general naming conventions and trends within HABEES for a variety of board-types and functions that have persisted and, should a new board fall under one of these categories, a suitable naming convention would be preferable.<br/><br />
<br />
Consistent naming conventions across board-types decreases confusion, as the simple/fun names associated with boards become very easy to relate to the function of a board, and hearing a board named "Pound Cake" will immediately cause one to think it is power-related (Power related boards are nicknamed after desserts).<br/><br />
<br />
The following are various current categorizations and naming conventions, as well as the boards that follow them.<br/><br />
<br />
'''Avionics & Flight Control Boards:''' Sesame Street Characters<br/><br />
'''Power Regulation & Management Boards:''' Desserts<br/><br />
'''Radio Boards:''' Birds & Parrots<br/><br />
'''Breakout/Expansion Boards:''' Snakes<br/><br />
'''Test Boards:''' Bee-related<br/><br />
<br />
{| class="wikitable"<br />
|-<br />
|'''Avionics'''<br />
|'''Power'''<br />
|'''Radio'''<br />
|'''Breakout'''<br />
|'''Test'''<br />
|-<br />
|Oscar (the Grouch)<br />
|Apple Turnover<br />
|Macaw<br />
|Cobra<br />
|QueenBee<br />
|-<br />
|Cookie Monster<br />
|Biscuit<br />
|<br />
|Viper<br />
|<br />
|-<br />
|Elmo<br />
|Cupcake<br />
|<br />
|<br />
|<br />
|-<br />
|The Count (von Count)<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
<br />
[[Category: High Altitude Balloons]][[Category: HABEES]][[Category: HONEY]]</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Naming_Conventions&diff=2955Naming Conventions2017-08-23T23:22:00Z<p>Ksafin: </p>
<hr />
<div>{{HONEY-sidebar<br />
| header = Naming Conventions<br />
| techline = Balloons Core Architecture<br />
}}<br />
<br />
Boards developed within HABEES and HONEY can have, as their designer wishes, any name (as long as it is appropriate). However, there are general naming conventions and trends within HABEES for a variety of board-types and functions that have persisted and, should a new board fall under one of these categories, a suitable naming convention would be preferable.<br/><br />
<br />
Consistent naming conventions across board-types decreases confusion, as the simple/fun names associated with boards become very easy to relate to the function of a board, and hearing a board named "Pound Cake" will immediately cause one to think it is power-related (Power related boards are nicknamed after desserts).<br/><br />
<br />
The following are various current categorizations and naming conventions, as well as the boards that follow them.<br/><br />
<br />
'''Avionics & Flight Control Boards:''' Sesame Street Characters<br/><br />
'''Power Regulation & Management Boards:''' Desserts<br/><br />
'''Radio Boards:''' Birds & Parrots<br/><br />
'''Breakout/Expansion Boards:''' Snakes<br/><br />
'''Test Boards:''' Bee-related<br/><br />
<br />
{| class="wikitable"<br />
|-<br />
|'''Avionics'''<br />
|'''Power'''<br />
|'''Radio'''<br />
|'''Breakout'''<br />
|'''Test'''<br />
|-<br />
|Oscar (the Grouch)<br />
|Apple Turnover<br />
|Macaw<br />
|Cobra<br />
|QueenBee<br />
|-<br />
|Cookie Monster<br />
|Biscuit<br />
|<br />
|<br />
|<br />
|-<br />
|Elmo<br />
|Cupcake<br />
|Viper<br />
|<br />
|<br />
|-<br />
|The Count (von Count)<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
<br />
[[Category: High Altitude Balloons]][[Category: HABEES]][[Category: HONEY]]</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Medusa&diff=2954Medusa2017-08-23T23:21:18Z<p>Ksafin: </p>
<hr />
<div>{{HABEES-sidebar<br />
| header = Medusa<br />
| img link = File:Medusa.jpg<br />
| designer = Kirill Safin<br />
| techline = Balloons Core Peripherals<br />
| version = Generation I<br />
| name = Medusa<br />
}}<br />
<br />
'''Medusa''' is a HABEES-developed expansion board for the Balloons Core Avionics. Medusa is designed to accept five 40-pin edge-cards to support a variety of add-on functionalities to enhance the capabilities of the Core Avionics suite. <br />
<br />
Medusa consists of five board-locking 80 pin edge-card slots, a micro SD for data logging, a Teensy 3.2 MCU, power input, and a CAN transceiver. <br />
<br />
Medusa functions by providing appropriate power & signal buses to all card slots, allowing external boards to implement I2C, SPI, UART, Analog, PWM functionalities to perform meaningful operations. Medusa receives commands from the Core Avionics over CAN, and is able to transmit data back to the Core Avionics along CAN as well. It is capable of logging all raw readings from installed cards locally, and transmitting only necessary or otherwise processed data back to the avionics.<br />
<br />
== Design ==<br />
<br />
Medusa is partitioned into five total slots -- three of which are standard slots, and two of which are ''god slots''. Standard slots partition various pins to reduce or eliminate any conflicts among simultaneously installed cards. God Slots provide access to all Teensy pins that are broken out to the slots.<br />
<br />
Each card slot is provided: +5V, +3.3V, +VBAT, GND, I2C, SPI with a unique chip select pin, and a card-detect LED. <br />
<br />
Each of the standard slots partition a subset of pins and protocols. Each of the standard slots is provided a Hardware Serial line; Slot 1 utilizes Hardware Serial 1, Slot 2 uses Hardware Serial 2, and so on. They also partition a subset of the PWM and ANALOG pins broken out by the Teensy. All Standard slots have '''two''' PWM pins, located on pins 37/38 and 39/40. Each standard slot also has '''four''' ANALOG pins, located on pins 53/54, 55/56, 57/58, and 59/60. <br />
<br />
Slot 1 uses PWM 3/4 and ANALOG 5/6/7/8, Slot 2 uses PWM 1/2 and ANALOG 1/2/3/4, while Slot 3 uses PWM 5/6 and ANALOG 9/10/11/12. This is enumerated on the breakout manifest found on the PCB silkscreen. <br />
<br />
The God Slots, however, break out all of these pins. That is, the God Slots have access to PWM 1-6 and ANALOG 1-12. The God Slots should only be used under two conditions: one is the necessity for a large number of ANALOG or PWM pins (more than a standard slot provides), and two being the need for four total cards, with the standard three slots being already taken up. In any case, it is critical for slots to be chosen wisely to avoid conflicts between cards.<br />
<br />
God Slots also have the option of using Serial -- however, they utilize Software Serial, and only if enabled using the SS jumpers found on the left of each of the slots. Slot 4 uses Analog pins 1 & 12 for Serial, while Slot 5 uses Analog pins 2 & 11.<br />
<br />
All cards should include a trace from pin 71 to pin 72 to enable the on-board medusa card-detect LED. <br />
<br />
== Schematics ==<br />
<br />
All Medusa Schematics, as well as the PCB Layout, can be found below. <br />
<br />
<gallery widths=200px heights=200px><br />
File:Medusa_top.PNG | <center> Top Sheet </center><br />
File:Medusa_pow.PNG | <center> Power Connector </center><br />
File:Medusa_can.PNG | <center> CAN Bus </center><br />
File:Medusa_microsd.PNG | <center> Micro SD </center><br />
File:Medusa_sslots.PNG | <center> Standard Slots </center><br />
File:Medusa_gslots.PNG | <center> God Slots </center><br />
File:Medusa_pcb.PNG | <center> PCB Layout </center><br />
</gallery><br />
<br />
== Pinouts ==<br />
<br />
{| class="wikitable"<br />
| Pin<br />
| Slot 1<br />
| Slot 2<br />
| Slot 3<br />
| Slot 4<br />
| Slot 5<br />
|-<br />
| 1<br />
| +5V <br />
| +5V <br />
| +5V <br />
| +5V <br />
| +5V <br />
|-<br />
| 2<br />
| +5V <br />
| +5V <br />
| +5V <br />
| +5V <br />
| +5V <br />
|-<br />
| 3<br />
| +3.3V <br />
| +3.3V <br />
| +3.3V <br />
| +3.3V <br />
| +3.3V <br />
|-<br />
| 4<br />
| +3.3V <br />
| +3.3V <br />
| +3.3V <br />
| +3.3V <br />
| +3.3V <br />
|-<br />
| 5<br />
| +VBAT<br />
| +VBAT <br />
| +VBAT <br />
| +VBAT <br />
| +VBAT <br />
|-<br />
| 6<br />
| +VBAT<br />
| +VBAT <br />
| +VBAT <br />
| +VBAT <br />
| +VBAT <br />
|-<br />
| 7<br />
| GND<br />
| GND <br />
| GND <br />
| GND <br />
| GND <br />
|-<br />
| 8<br />
| GND<br />
| GND <br />
| GND <br />
| GND <br />
| GND <br />
|-<br />
| 9<br />
| RX1<br />
| RX2 <br />
| RX3 <br />
| A12 (SSE) <br />
| A11 (SSE)<br />
|-<br />
| 10<br />
| TX1<br />
| TX2 <br />
| TX3 <br />
| A1 (SSE) <br />
| A2 (SSE)<br />
|-<br />
| 11<br />
| MOSI<br />
| MOSI<br />
| MOSI<br />
| MOSI<br />
| MOSI<br />
|-<br />
| 12<br />
| MISO<br />
| MISO<br />
| MISO<br />
| MISO <br />
| MISO<br />
|-<br />
| 13<br />
| SCLK<br />
| SCLK<br />
| SCLK<br />
| SCLK <br />
| SCLK<br />
|-<br />
| 14 (CS)<br />
| 21<br />
| 20 <br />
| 24<br />
| 33 <br />
| 26<br />
|-<br />
| 15<br />
| SCL<br />
| SCL <br />
| SCL <br />
| SCL <br />
| SCL<br />
|-<br />
| 16<br />
| SDA<br />
| SDA <br />
| SDA <br />
| SDA<br />
| SDA<br />
|-<br />
| 17 (PWM)<br />
| NC<br />
| NC <br />
| NC <br />
| 5 <br />
| 5 <br />
|-<br />
| 18 (PWM)<br />
| NC<br />
| NC <br />
| NC <br />
| 6<br />
| 6<br />
|-<br />
| 19 (PWM)<br />
| 23<br />
| 5 <br />
| 32<br />
| 23<br />
| 23<br />
|-<br />
| 20 (PWM)<br />
| 22<br />
| 6<br />
| 25<br />
| 22<br />
| 22<br />
|-<br />
| 21 (PWM)<br />
| NC<br />
| NC<br />
| NC<br />
| 32<br />
| 32<br />
|-<br />
| 22 (PWM)<br />
| NC<br />
| NC<br />
| NC<br />
| 25<br />
| 25<br />
|-<br />
| 23 (A)<br />
| NC<br />
| NC <br />
| NC <br />
| 16<br />
| 16<br />
|-<br />
| 24 (A)<br />
| NC<br />
| NC <br />
| NC <br />
| 17<br />
| 17<br />
|-<br />
| 25 (A)<br />
| NC<br />
| NC <br />
| NC <br />
| A10<br />
| A10<br />
|-<br />
| 26 (A)<br />
| NC<br />
| NC <br />
| NC <br />
| A11<br />
| A11<br />
|-<br />
| 27 (A)<br />
| A12<br />
| 16<br />
| 29<br />
| A12<br />
| A12<br />
|-<br />
| 28 (A)<br />
| A13<br />
| 17<br />
| 28<br />
| A13<br />
| A13<br />
|-<br />
| 29 (A)<br />
| A14<br />
| A10<br />
| 27<br />
| A14<br />
| A14<br />
|-<br />
| 30 (A)<br />
| 30<br />
| A11<br />
| 14<br />
| 30<br />
| 30<br />
|-<br />
| 31 (A)<br />
| NC<br />
| NC <br />
| NC <br />
| 29<br />
| 29<br />
|-<br />
| 32 (A)<br />
| NC<br />
| NC <br />
| NC <br />
| 28<br />
| 28<br />
|-<br />
| 33 (A)<br />
| NC<br />
| NC <br />
| NC <br />
| 27<br />
| 27<br />
|-<br />
| 34 (A)<br />
| NC<br />
| NC <br />
| NC <br />
| 14<br />
| 14<br />
|-<br />
| 35<br />
| +3.3V<br />
| +3.3V<br />
| +3.3V <br />
| +3.3V<br />
| +3.3V<br />
|-<br />
| 36<br />
| CD<br />
| CD <br />
| CD <br />
| CD<br />
| CD<br />
|-<br />
| 37<br />
| +5V<br />
| +5V<br />
| +5V<br />
| +5V<br />
| +5V<br />
|-<br />
| 38<br />
| +5V<br />
| +5V<br />
| +5V<br />
| +5V<br />
| +5V<br />
|-<br />
| 39<br />
| GND<br />
| GND<br />
| GND<br />
| GND<br />
| GND<br />
|-<br />
| 40<br />
| GND<br />
| GND<br />
| GND<br />
| GND<br />
| GND<br />
|}<br />
<br />
[[Category: High Altitude Balloons]][[Category: HABEES]]</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Gen_1_Architecture&diff=2953Gen 1 Architecture2017-08-23T23:17:01Z<p>Ksafin: /* Electrical Specification */</p>
<hr />
<div>{{HABEES-sidebar<br />
| header = Gen 1 Architecture<br />
| img link = File:oscar.JPG<br />
| designer = Kirill Safin<br />
| techline = Balloons Core Architecture<br />
| version = Generation I<br />
}}<br />
<br />
The '''Balloons Gen 1 Architecture''' was the first attempt within the Balloons Team at standardizing the form factor & electrical standards for standard-profile balloon avionics, power, and control systems. The architecture was introduced in Spring of 2016, and lasted until Spring of 2017, when it was replaced by [[Gen 2 Architecture | HONEY]], the Gen 2 Architecture.<br />
<br />
The first-ever architecture had two primary components -- the physical form factor, as well as the electrical standards. These will both be addressed individually.<br />
<br />
== Physical Form Factor ==<br />
The physical form factor of the Gen 1 Architecture was decided upon primarily based on the physical dimensions of the payload container, which, at the time of invention, was habhive. habhive, at the time, was a hexagonal payload container which had a standardized internal hexagonal surface area to fit HABEES boards. To maximize board area and conform to the habhive dimensioning, a 3/4 hexagonal shape was chosen. This allowed maximum utilization of the internal area, while the 1/4 hexagon that was cut off allowed wires & connections to be funneled throughout the height of the payload container.<br />
<br />
=== Benefits ===<br />
The decided form-factor fit very well into the habhive container, and effectively allowed inter-roping of internal boards and connections using the alloted 1/4 hexagonal spacing. The boards fit very snugly, and had sufficient space for the vast majority of electronics.<br />
<br />
=== Drawbacks ===<br />
One of the primary drawbacks of the form factor was it's strict adherence to the habhive spec, which, as a hexagon, was very specific and a very niche shape that would not be found outside of the habhive box. The hexagonal boards, outside of habhive, seemed strange and unintuitive in their shape. <br />
<br />
Further, while the spacing maximized surface area and provided a space to run wires, it was tight enough that reaching in and altering connections/moving devices was difficult with a fully assembled payload.<br />
<br />
== Electrical Specification ==<br />
The electrical specifications of the Gen 1 Architecture changed rapidly -- owing to the fact that it was the first ever balloons standardized architecture, and the needs, limitations, and wants of an architecture arose quickly as the architecture was implemented. The architecture evolved with each board that was added to it, and hence the specifications will be cataloged and described in that fashion.<br />
<br />
=== Oscar Spec ===<br />
[[File:oscar.JPG | right| thumb | <center> Oscar, the first Gen 1 Architecture board. </center>]]<br />
Oscar, the first Gen 1 Architecture compliant board, introduced a very simple and bare-bones electrical standard.<br />
<br />
Oscar only provided a 2-pin microfit connector for connection to a battery pack -- that is, Oscar conducted all power-regulation onboard, producing necessary voltages and handling pack protection circuitry. Oscar did, however, provide header pinouts for various signal and power lines -- including GND, 3.3V, 5V, raw pack, I2C, and SPI. This first electrical specification speculated that additional connections to the avionics would utilize jumper wires and these simple pinouts.<br />
<br />
=== Cookie Monster Spec ===<br />
[[File:cookiemonster.jpeg | right| thumb | <center> Cookie Monster introduced a discrete BMS, CAN, and downsized pinouts. </center>]]<br />
As the limitations and general simpleness of the Oscar Spec became apparent, many new additions and alterations were made to provide for a more scalable and robust architecture -- introduced in Cookie Monster.<br />
<br />
One of the key introductions with the Cookie Monster spec was the separation of power regulation and avionics. All power regulation was broken out onto a separate PCB -- the newly introduced BMS, Apple Turnover -- and the avionics, Cookie Monster, added a BMS connector including power & data pins. <br />
<br />
In addition to splitting controls & power into separate domains, Cookie Monster added an important system that would persist in balloons architecture to this day -- the CAN interface. Cookie Monster added two connectors for CAN -- one input and one output. This multi-master interface would allow for scaling the architecture to any number of boards, allowing multiple boards to be connected and interface easily. <br />
<br />
Cookie Monster did, however, retain the male header pinouts of Oscar, while downsizing them significantly (to 5 pins per protocol/voltage). This was still seen as a useful functionality to easily access the various signal nets and power nets.<br />
<br />
In introducing CAN, the Cookie Monster spec also introduced the first possibility for expansion -- [[Medusa]]. Medusa was a Gen 1 compliant board that communicated with Cookie Monster over CAN, and allowed the creation of small board-edge PCB's to expand the core system functionality. This was the first attempt of the Gen 1 Architecture to allow enhancing and expanding the system functionality past the core avionics platform.<br />
<br />
=== Elmo Spec ===<br />
[[File:elmo.jpeg | right| thumb | <center> Elmo split the BMS connectors. </center>]]<br />
The Elmo Spec maintained the introductions of the Cookie Monster spec, while splitting the size of the BMS connector into discrete data & power connectors.<br />
<br />
=== Issues ===<br />
There were many issues with the electrical spec of the Gen 1 Architecture, which arose over time. They are, primarily:<br />
* The wired CAN interface took up a lot of space and expensive shielded twisted-pair wires<br />
* The Medusa Expansion board didn't allow for making very large boards to expand functionality<br />
* The first BMS, Apple Turnover, didn't function<br />
* There was too much wiring all-together necessitated between boards<br />
<br />
=== Transition to HONEY ===<br />
The above issues, and a number of new considerations, resulted in the introduction of the HONEY standard (Gen 2 Architecture).<br />
<br />
The HONEY standard introduced the following changes & additions to the Gen 1 Architecture:<br />
* Stack-through format instead of by-wire format of interconnect.<br />
* 10x10cm "cubesat format" form-factor, over random hexagonal boards.<br />
* Stack-through CAN bus (two).<br />
* Stack-through Power bus.<br />
* Stack-through data bus.<br />
* Breakout boards to provide non-stack connections over a large distance.<br />
* Backwards compatibility between board iterations.<br />
* Core Software for communication between boards.<br />
<br />
<br />
[[Category: High Altitude Balloons]][[Category: HABEES]]</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Gen_1_Architecture&diff=2952Gen 1 Architecture2017-08-23T23:15:48Z<p>Ksafin: </p>
<hr />
<div>{{HABEES-sidebar<br />
| header = Gen 1 Architecture<br />
| img link = File:oscar.JPG<br />
| designer = Kirill Safin<br />
| techline = Balloons Core Architecture<br />
| version = Generation I<br />
}}<br />
<br />
The '''Balloons Gen 1 Architecture''' was the first attempt within the Balloons Team at standardizing the form factor & electrical standards for standard-profile balloon avionics, power, and control systems. The architecture was introduced in Spring of 2016, and lasted until Spring of 2017, when it was replaced by [[Gen 2 Architecture | HONEY]], the Gen 2 Architecture.<br />
<br />
The first-ever architecture had two primary components -- the physical form factor, as well as the electrical standards. These will both be addressed individually.<br />
<br />
== Physical Form Factor ==<br />
The physical form factor of the Gen 1 Architecture was decided upon primarily based on the physical dimensions of the payload container, which, at the time of invention, was habhive. habhive, at the time, was a hexagonal payload container which had a standardized internal hexagonal surface area to fit HABEES boards. To maximize board area and conform to the habhive dimensioning, a 3/4 hexagonal shape was chosen. This allowed maximum utilization of the internal area, while the 1/4 hexagon that was cut off allowed wires & connections to be funneled throughout the height of the payload container.<br />
<br />
=== Benefits ===<br />
The decided form-factor fit very well into the habhive container, and effectively allowed inter-roping of internal boards and connections using the alloted 1/4 hexagonal spacing. The boards fit very snugly, and had sufficient space for the vast majority of electronics.<br />
<br />
=== Drawbacks ===<br />
One of the primary drawbacks of the form factor was it's strict adherence to the habhive spec, which, as a hexagon, was very specific and a very niche shape that would not be found outside of the habhive box. The hexagonal boards, outside of habhive, seemed strange and unintuitive in their shape. <br />
<br />
Further, while the spacing maximized surface area and provided a space to run wires, it was tight enough that reaching in and altering connections/moving devices was difficult with a fully assembled payload.<br />
<br />
== Electrical Specification ==<br />
The electrical specifications of the Gen 1 Architecture changed rapidly -- owing to the fact that it was the first ever balloons standardized architecture, and the needs, limitations, and wants of an architecture arose quickly as the architecture was implemented. The architecture evolved with each board that was added to it, and hence the specifications will be cataloged and described in that fashion.<br />
<br />
=== Oscar Spec ===<br />
Oscar, the first Gen 1 Architecture compliant board, introduced a very simple and bare-bones electrical standard.<br />
<br />
Oscar only provided a 2-pin microfit connector for connection to a battery pack -- that is, Oscar conducted all power-regulation onboard, producing necessary voltages and handling pack protection circuitry. Oscar did, however, provide header pinouts for various signal and power lines -- including GND, 3.3V, 5V, raw pack, I2C, and SPI. This first electrical specification speculated that additional connections to the avionics would utilize jumper wires and these simple pinouts.<br />
<br />
=== Cookie Monster Spec ===<br />
As the limitations and general simpleness of the Oscar Spec became apparent, many new additions and alterations were made to provide for a more scalable and robust architecture -- introduced in Cookie Monster.<br />
<br />
One of the key introductions with the Cookie Monster spec was the separation of power regulation and avionics. All power regulation was broken out onto a separate PCB -- the newly introduced BMS, Apple Turnover -- and the avionics, Cookie Monster, added a BMS connector including power & data pins. <br />
<br />
In addition to splitting controls & power into separate domains, Cookie Monster added an important system that would persist in balloons architecture to this day -- the CAN interface. Cookie Monster added two connectors for CAN -- one input and one output. This multi-master interface would allow for scaling the architecture to any number of boards, allowing multiple boards to be connected and interface easily. <br />
<br />
Cookie Monster did, however, retain the male header pinouts of Oscar, while downsizing them significantly (to 5 pins per protocol/voltage). This was still seen as a useful functionality to easily access the various signal nets and power nets.<br />
<br />
In introducing CAN, the Cookie Monster spec also introduced the first possibility for expansion -- [[Medusa]]. Medusa was a Gen 1 compliant board that communicated with Cookie Monster over CAN, and allowed the creation of small board-edge PCB's to expand the core system functionality. This was the first attempt of the Gen 1 Architecture to allow enhancing and expanding the system functionality past the core avionics platform.<br />
<br />
=== Elmo Spec ===<br />
The Elmo Spec maintained the introductions of the Cookie Monster spec, while splitting the size of the BMS connector into discrete data & power connectors.<br />
<br />
=== Issues ===<br />
There were many issues with the electrical spec of the Gen 1 Architecture, which arose over time. They are, primarily:<br />
* The wired CAN interface took up a lot of space and expensive shielded twisted-pair wires<br />
* The Medusa Expansion board didn't allow for making very large boards to expand functionality<br />
* The first BMS, Apple Turnover, didn't function<br />
* There was too much wiring all-together necessitated between boards<br />
<br />
=== Transition to HONEY ===<br />
The above issues, and a number of new considerations, resulted in the introduction of the HONEY standard (Gen 2 Architecture).<br />
<br />
The HONEY standard introduced the following changes & additions to the Gen 1 Architecture:<br />
* Stack-through format instead of by-wire format of interconnect.<br />
* 10x10cm "cubesat format" form-factor, over random hexagonal boards.<br />
* Stack-through CAN bus (two).<br />
* Stack-through Power bus.<br />
* Stack-through data bus.<br />
* Breakout boards to provide non-stack connections over a large distance.<br />
* Backwards compatibility between board iterations.<br />
* Core Software for communication between boards.<br />
<br />
<br />
[[Category: High Altitude Balloons]][[Category: HABEES]]</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Balloon_Gen_1_BMS&diff=2951Balloon Gen 1 BMS2017-08-23T23:14:59Z<p>Ksafin: </p>
<hr />
<div>{{HABEES-sidebar<br />
| header = Apple Turnover<br />
| img link = File:appleturnover.png<br />
| designer = Kirill Safin<br />
| techline = Balloons Core Power<br />
| version = Generation I<br />
| name = Apple Turnover<br />
}}<br />
<br />
[[Category: High Altitude Balloons]][[Category: HABEES]]</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Balloon_Gen_1_BMS&diff=2950Balloon Gen 1 BMS2017-08-23T23:14:50Z<p>Ksafin: </p>
<hr />
<div>{{HABEES-sidebar<br />
| header = Apple Turnover<br />
| img link = File:appleturnover.PNG<br />
| designer = Kirill Safin<br />
| techline = Balloons Core Power<br />
| version = Generation I<br />
| name = Apple Turnover<br />
}}<br />
<br />
[[Category: High Altitude Balloons]][[Category: HABEES]]</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=File:Appleturnover.png&diff=2949File:Appleturnover.png2017-08-23T23:14:39Z<p>Ksafin: </p>
<hr />
<div></div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Balloon_Gen_2_Avionics&diff=2948Balloon Gen 2 Avionics2017-08-23T23:13:42Z<p>Ksafin: </p>
<hr />
<div>{{HABEES-sidebar<br />
| header = Cookie Monster<br />
| img link = File:cookiemonster.jpeg<br />
| designer = Kirill Safin<br />
| techline = Balloons Core Avionics<br />
| version = Generation II<br />
| name = Cookie Monster<br />
}}<br />
<br />
[[Category: High Altitude Balloons]][[Category: HABEES]]</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Balloons_Gen_3_Avionics&diff=2947Balloons Gen 3 Avionics2017-08-23T23:13:35Z<p>Ksafin: </p>
<hr />
<div>{{HABEES-sidebar<br />
| header = Elmo<br />
| img link = File:elmo.jpeg<br />
| designer = Kirill Safin<br />
| techline = Balloons Core Avionics<br />
| version = Generation III<br />
| name = Elmo<br />
}}<br />
<br />
[[Category: High Altitude Balloons]][[Category: HABEES]]</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=File:Elmo.jpeg&diff=2946File:Elmo.jpeg2017-08-23T23:13:20Z<p>Ksafin: </p>
<hr />
<div></div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=File:Cookiemonster.jpeg&diff=2945File:Cookiemonster.jpeg2017-08-23T23:12:51Z<p>Ksafin: </p>
<hr />
<div></div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Gen_1_Architecture&diff=2944Gen 1 Architecture2017-08-23T23:11:09Z<p>Ksafin: </p>
<hr />
<div>{{HABEES-sidebar<br />
| header = Gen 1 Architecture<br />
| img link = File:oscar.JPG<br />
| designer = Kirill Safin<br />
| techline = Balloons Core Architecture<br />
| version = Generation I<br />
}}<br />
<br />
The '''Balloons Gen 1 Architecture''' was the first attempt within the Balloons Team at standardizing the form factor & electrical standards for standard-profile balloon avionics, power, and control systems. The architecture was introduced in Spring of 2016, and lasted until Spring of 2017, when it was replaced by [[Gen 2 Architecture | HONEY]], the Gen 2 Architecture.<br />
<br />
The first-ever architecture had two primary components -- the physical form factor, as well as the electrical standards. These will both be addressed individually.<br />
<br />
== Physical Form Factor ==<br />
The physical form factor of the Gen 1 Architecture was decided upon primarily based on the physical dimensions of the payload container, which, at the time of invention, was habhive. habhive, at the time, was a hexagonal payload container which had a standardized internal hexagonal surface area to fit HABEES boards. To maximize board area and conform to the habhive dimensioning, a 3/4 hexagonal shape was chosen. This allowed maximum utilization of the internal area, while the 1/4 hexagon that was cut off allowed wires & connections to be funneled throughout the height of the payload container.<br />
<br />
=== Benefits ===<br />
The decided form-factor fit very well into the habhive container, and effectively allowed inter-roping of internal boards and connections using the alloted 1/4 hexagonal spacing. The boards fit very snugly, and had sufficient space for the vast majority of electronics.<br />
<br />
=== Drawbacks ===<br />
One of the primary drawbacks of the form factor was it's strict adherence to the habhive spec, which, as a hexagon, was very specific and a very niche shape that would not be found outside of the habhive box. The hexagonal boards, outside of habhive, seemed strange and unintuitive in their shape. <br />
<br />
Further, while the spacing maximized surface area and provided a space to run wires, it was tight enough that reaching in and altering connections/moving devices was difficult with a fully assembled payload.<br />
<br />
== Electrical Specification ==<br />
The electrical specifications of the Gen 1 Architecture changed rapidly -- owing to the fact that it was the first ever balloons standardized architecture, and the needs, limitations, and wants of an architecture arose quickly as the architecture was implemented. The architecture evolved with each board that was added to it, and hence the specifications will be cataloged and described in that fashion.<br />
<br />
=== Oscar Spec ===<br />
Oscar, the first Gen 1 Architecture compliant board, introduced a very simple and bare-bones electrical standard.<br />
<br />
Oscar only provided a 2-pin microfit connector for connection to a battery pack -- that is, Oscar conducted all power-regulation onboard, producing necessary voltages and handling pack protection circuitry. Oscar did, however, provide header pinouts for various signal and power lines -- including GND, 3.3V, 5V, raw pack, I2C, and SPI. This first electrical specification speculated that additional connections to the avionics would utilize jumper wires and these simple pinouts.<br />
<br />
=== Cookie Monster Spec ===<br />
As the limitations and general simpleness of the Oscar Spec became apparent, many new additions and alterations were made to provide for a more scalable and robust architecture -- introduced in Cookie Monster.<br />
<br />
One of the key introductions with the Cookie Monster spec was the separation of power regulation and avionics. All power regulation was broken out onto a separate PCB -- the newly introduced BMS, Apple Turnover -- and the avionics, Cookie Monster, added two connector inputs for BMS Power Input & BMS Data Input. These two connectors provided power and data analytics about the BMS, respectively.<br />
<br />
In addition to splitting controls & power into separate domains, Cookie Monster added an important system that would persist in balloons architecture to this day -- the CAN interface. Cookie Monster added two connectors for CAN -- one input and one output. This multi-master interface would allow for scaling the architecture to any number of boards, allowing multiple boards to be connected and interface easily. <br />
<br />
Cookie Monster did, however, retain the male header pinouts of Oscar, while downsizing them significantly (to 5 pins per protocol/voltage). This was still seen as a useful functionality to easily access the various signal nets and power nets.<br />
<br />
In introducing CAN, the Cookie Monster spec also introduced the first possibility for expansion -- [[Medusa]]. Medusa was a Gen 1 compliant board that communicated with Cookie Monster over CAN, and allowed the creation of small board-edge PCB's to expand the core system functionality. This was the first attempt of the Gen 1 Architecture to allow enhancing and expanding the system functionality past the core avionics platform.<br />
<br />
=== Elmo Spec ===<br />
The Elmo Spec maintained the introductions of the Cookie Monster spec, while decreasing the size of the BMS Data connector. <br />
<br />
=== Issues ===<br />
There were many issues with the electrical spec of the Gen 1 Architecture, which arose over time. They are, primarily:<br />
* The wired CAN interface took up a lot of space and expensive shielded twisted-pair wires<br />
* The Medusa Expansion board didn't allow for making very large boards to expand functionality<br />
* The first BMS, Apple Turnover, didn't function<br />
* There was too much wiring all-together necessitated between boards<br />
<br />
=== Transition to HONEY ===<br />
The above issues, and a number of new considerations, resulted in the introduction of the HONEY standard (Gen 2 Architecture).<br />
<br />
The HONEY standard introduced the following changes & additions to the Gen 1 Architecture:<br />
* Stack-through format instead of by-wire format of interconnect.<br />
* 10x10cm "cubesat format" form-factor, over random hexagonal boards.<br />
* Stack-through CAN bus (two).<br />
* Stack-through Power bus.<br />
* Stack-through data bus.<br />
* Breakout boards to provide non-stack connections over a large distance.<br />
* Backwards compatibility between board iterations.<br />
* Core Software for communication between boards.<br />
<br />
<br />
[[Category: High Altitude Balloons]][[Category: HABEES]]</div>Ksafinhttps://ssi-wiki.stanford.edu/w/index.php?title=Gen_1_Architecture&diff=2943Gen 1 Architecture2017-08-23T22:52:47Z<p>Ksafin: </p>
<hr />
<div>{{HABEES-sidebar<br />
| header = Gen 1 Architecture<br />
| img link = File:oscar.JPG<br />
| designer = Kirill Safin<br />
| techline = Balloons Core Architecture<br />
| version = Generation I<br />
}}<br />
<br />
The '''Balloons Gen 1 Architecture''' was the first attempt within the Balloons Team at standardizing the form factor & electrical standards for standard-profile balloon avionics, power, and control systems. The architecture was introduced in Spring of 2016, and lasted until Spring of 2017, when it was replaced by [[Gen 2 Architecture | HONEY]], the Gen 2 Architecture.<br />
<br />
The first-ever architecture had two primary components -- the physical form factor, as well as the electrical standards. These will both be addressed individually.<br />
<br />
[[Category: High Altitude Balloons]][[Category: HABEES]]</div>Ksafin