700
edits
Changes
Jump to navigation
Jump to search
Line 17:
Line 17: − + Line 117:
Line 117: − + Line 164:
Line 164: + +
→Gesture Specification
As mentioned above, a Gesture consists of a series of CAN Packets -- these packets specify the source and destination of a gesture, some auxiliary data, and the primary data payload. STINGR manages CAN Packets, which are obfuscated from the end-user.
As mentioned above, a Gesture consists of a series of CAN Packets -- these packets specify the source and destination of a gesture, some auxiliary data, and the primary data payload. STINGR manages CAN Packets, which are obfuscated from the end-user.
More explicitly, a Gesture looks is comprised of an initialization CAN Packet, followed by up to 256 additional CAN Packets, each comprised of a 1 byte header and 7 byte data payload, for a total possible data length of 256 * 7 = 1,792 bytes. The initialization CAN Packet consists of the standard header, 2 bytes of additional information, and 5 bytes of data payload. Subsequent CAN Packets consist of the 1 byte header and up to 7 bytes of data. The general structure of this format is as such:
More explicitly, a Gesture looks is comprised of an initialization CAN Packet, followed by up to 256 additional CAN Packets, each comprised of a 1 byte header and 7 byte data payload, for a total possible data length of 256 * 7 = 1,792 bytes. The initialization CAN Packet consists of the standard header, 3 bytes of additional information, and 4 bytes of data payload. Subsequent CAN Packets consist of the 1 byte header and up to 7 bytes of data. The general structure of this format is as such:
{| class="wikitable"
{| class="wikitable"
|}
|}
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 reader should recognize that it is the first four frames -- Destination, Flags, Length, and Gesture Type -- that are considered the initialization data, and that the subsequent 4 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 '''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.
|00000111
|00000111
|}
|}
The blanket "0" type is for non-standardized gestures, which constitute a large part of board-to-board gestures. The rest of the Gesture Types specify standardized data requests or responses.
=== Source & Destination Identifiers ===
=== Source & Destination Identifiers ===