700
edits
Changes
Jump to navigation
Jump to search
Line 55:
Line 55: − + − + − + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + − + − + − |Reserved − |Reserved − |Reserved − + − * '''High Priority''': The board receiving the request should cease all operation immediately and respond to the request before continuing.+ − * '''Low Priority''': The board receiving the request can wait to respond to the request until most convenient. + − * '''No Override''': The board receiving the request has no choice but to comply with the request sent -- it should not exert any effort attempting to question or combat the transmitting board. If this flag is low, a board receiving a request has the ability to ask the transmitting board for clarification or request a re-consideration. If this flag is high, the receiving board should execute the request regardless.+ − Flags are stacking, meaning multiple flags can be high. For example, a high high-priority flag and high no-override flag means a board not only must comply without question, but it should do so immediately prior to continuing any of its standard operations.+
→Gesture Specification
=== Header ===
=== Header ===
The Type frame, the first frame in a Gesture, is a 1 bit frame that determines whether a Gesture is a request from one board to another, or a response from one board from a prior request. This frame is a 0 for a request, and a 1 for a response.
The Header is a 1 byte frame that precedes the 7 byte data frame of each CAN Packet. This header provides critical data used by STINGR to re-assemble a fragmented conglomeration of CAN Packets back into one gesture. The Header is defined as mentioned above:
=== State Flags Frame ===
{| class="wikitable"
The 7 bits following the Type bit are the State Flag bits. This 7-bit frame allows transmitting boards to provide specialty signals to the receiving board. A low bit indicates a flag that isn't down, while a high bit indicates a raised flag. The current flags are as follows, from LSB to MSB.
| style="background-color: #4CC9FF;"|
Source (0 - 16) (4 bit)
| style="background-color: #8AFFDF;"|
IsInit (1 bit)
| style="background-color: #FFA6CE;"|
Parity (1 bit)
| style="background-color: #EDFF7A;"|
Message ID (2 bit)
| style="background-color: #AD6DF9;"|
Data (7 bytes)
|}
The '''Source''' field is a 4-bit field identifying the origin board of a message. Each board in the flight stack is given a unique identifier, 0-15, which serves to identify it to other boards during transmissions. The Avionics reserves the '0' identifier, and the '15' identifier is reserved for broadcast messages (further down on this page). This leaves 14 possible identifiers, allowing for a flight stack featuring 15 boards total. The identifiers for each board are established during boot-up of the flight stack by the avionics, and distributed to the boards. This "source identifier", while unique to a given flight stack configuration from boot-up, does not permeate between flights or flight stack configurations. That is to say, if a flight stack consists of an Avionics Board, BMS, and Radio board, their unique identifiers might respectively be assigned as 0, 1, and 2 on boot-up, but, on power cycle, could reset to 0, 2, 1. The source identifiers only exist in perpetuity while a flight stack remains powered.
The '''IsInit''' field is a 1-bit field identifying whether this message is an initialization message. If HIGH, STINGR will inspect the following 2 bytes for initialization information. If LOW, STINGR will consider the following two bytes to be part of the data payload.
The '''Parity''' field is an even parity bit used by STINGR to verify proper message transmission.
The '''Message ID''' field is a 2-bit field that indicates the ID of a given message -- that is, it uniquely identifies the gesture. If a board, say, the BMS, transmitted three gestures one after another, they would be given consecutive Message ID's of X, X+1, X+2, all mod 4, where X is the initial message ID. The first message by a board has a message ID of 0, the second 1, the fourth 0, and so on. The primary purpose of this field is to allow STINGR to request a re-transmit of a specific gesture if it was corrupted during transmission. If a gesture from the BMS with Message ID 2 was improperly received by the Avionics, it can request the BMS re-send the Gesture with Message ID 2. However, STINGR only stores the previous four messages that were transmitted (since the Message ID field only fits four values). Hence, if a board has transmitted four messages since the corrupted one, and then the corrupted one is re-requested, STINGR will respond with a re-transmit fault, and the corrupted transmit message will not be transmitted.
The '''Data''' field is a 7 byte frame that contains actual data specifying the gesture. This field can contain any information for generic messages, which are generally encoded with simple characters. However, if this is an initialization message, the first two bytes of the data frame will contain information needed by STINGR to re-assemble the gesture.
=== Initialization Packet ===
The initialization packet is the first packet sent out by a board to fully define the gesture it is about to transmit, allowing all other boards to re-construct the gesture once all CAN Packets are fully transmitted. The initialization packet looks as so:
{| class="wikitable"
| style="background-color: #4CC9FF;"|
Header (1 byte)
| style="background-color: #8AFFDF;"|
Destination Identifier (4 bits)
| style="background-color: #FFA6CE;"|
Flags (4 bits)
| style="background-color: #EDFF7A;"|
Message Length (in # Packets) (8 bits)
| style="background-color: #AD6DF9;"|
Data (5 bytes)
|}
The '''Header''' is defined in the previous section. For the initialization packet, most fields in the Header remain standard -- source is the 4-bit identifier of the sending board, the parity bit is even parity, the message ID is the message ID of the current gesture. The only thing that explicitly changes in the header for the initialization packet is the '''IsInit''' bit, which is HIGH for the initialization packet.
Following the header, the initialization packet provides two bytes of information as part of the data frame. This data is organized as such:
{| class="wikitable"
| style="background-color: #4CC9FF;"|
Destination (4 bits)
| style="background-color: #8AFFDF;"|
Flags (4 bits)
| style="background-color: #FFA6CE;"|
Length (8 bits)
| style="background-color: #EDFF7A;"|
Data (8 bytes)
|}
The reader should recognize that it is the first three frames -- Destination, Flags, and Length -- that are considered the initialization data, and that the subsequent 5 bytes of data are the beginning of the gesture data.
The '''Destination''' field is a 4-bit field that uniquely identifies the destination board. This is akin to the source identifier, in that you would specify the same identifier. For example, if the BMS transmitted a gesture, and it's identifier was 2, it would specify a source identifier of 2. Likewise, if the avionics were to send a message ''to'' the BMS, it would specify a ''destination identifier'' of 2. It should be noted that the identifier of "15" is reserved as the Broadcast Identifier. A destination of 15 specifies that the entire flight-stack is the recipient of a gesture, rather than any specific board.
The '''Flags''' field is a 4-bit field that consists of four unique flags that carry some auxiliary data pertinent to the message; they are as such:
{| class="wikitable"
{| class="wikitable"
|High Priority
|High Priority
|Low Priority
|Type
|No Override
|No Override
|Reserved
|Request ACK
|}
|}
The flags are defined as follows:
The '''High Priority''' Flag, if HIGH, indicates that the receiving board should respond to the gesture immediately or at next possible opportunity, as it is a high priority gesture.
The '''Type''' Flag, if HIGH, indicates that the gesture is a REQUEST, while a LOW bit indicates that the message is a RESPONSE.
The '''No Override''' Flag, if HIGH, indicates that a receiving board cannot override the received gesture. This flag is carefully managed by STINGR, and typically reserved for Avionics messages.
The '''Request ACK''' Flag, if HIGH, indicates that a receiving board should respond to the transmitting board with an ACK to indicate that it has successfully received and acknowledged a gesture.
The '''Length''' field is an 8-bit field that defines the number of subsequent CAN Packets, all of which define the current transmitting gesture. This field is used by STINGR to carefully monitor all incoming CAN traffic and reassemble gestures.
=== Source & Destination Identifiers ===
=== Source & Destination Identifiers ===