When telecommands are uplinked to the satellite, telemetry is downlinked to the ground station, and messages are passed across different subsystems onboard the spacecraft, they are transmitted and received in a stream of bytes. 1’s and 0’s combined to somehow form a unique message. The purpose of this page is to document how we structure our byte streams within the data fields of CSP packets. It will highlight what each byte represents and how telecommands/telemetry are encoded/decoded. This will hopefully prove useful to the teams responsible for communications with the ground (the Firmware side of it, of course) and the team working on the software aspect of the ground station. In the future, the information on this page will be codified into an official command protocol specification document, similar to what HERON has.
Note: When uplinking and downlinking data, the CSP packet only represents the payload data. There will be additional information (Headers, CRC) on the frame that will need to be accounted for by the ground station team. For the Firmware team, it looks like the SRS-4 Transceiver can extract the CSP packet from the frame or build the frame around the CSP packet, leaving them with just encoding/decoding the data field within the CSP packet.
The telecommands, the acknowledgements (ACKs), and responses are strongly based off of the HERON protocol. The response packet will be sent down any time a command is received by the ground station. If the command requires data to be downlinked, then that data will exist in the Data Field. Otherwise, that data field will be empty and the response packet will just indicate if the command was executed successfully. Heads up, the numbers in the brackets represent the bytes associated with the data fields (I don’t wanna spend that much time figuring out how to put the numbers along the top of the box, bare with me here when we codify this into a word doc it’ll look much better)
| Command ID (0-1) | Opcode (2) | Arg 1 (3-6) | Arg 2 (7-10) | Arg 3 (11-14) | Arg 4 (15-18) | Timestamp (19) | Password (20-23) |
|---|
Command ID - The Command ID is a unique 16-bit character (with a MSB of 0) that associates each command uplinked with an identifier. The value is essentially a value; every time a command is uplinked to the satellite, the Command ID associated with the message will be one higher than the last command. Hence, multiple telecommands with the same opcode can be differentiated when the satellite is sending an acknowledgement and a response. The Command ID will be tracked by flight software onboard FINCH, and sending a telecommand with a Command ID of 0 will simply reset that counter.
Opcode - Opcode is the hexadecimal number that specifies which operation is to be performed.
Args 1 ~ Args 4 - These fields are reserved for any arguments that are associated with the commands. There are 4 distinct fields as a maximum of four arguments are needed based on the commands we have established so far. If an argument field is not needed, it will be left blank. A command table is included in flight software that will allow the Command Service to understand how many arguments it needs to look for.
Timestamp - ****Each command should be time-tagged, giving flight software an indication of when that command needs to be executed. If the command must be executed immediately, the timestamp field shall be 0. Note: The Timestamp field size of 1 byte is not the final decision. This value is subject to change based on RTC Driver & Time Library Integration.
Password - Currently, it is understood that commands are not permitted to be encrypted (This understand is likely to change as os 11/18/2023 based on HERON’s current issues. The SRS-4 Transceiver provides encryption and decryption functionality that can be leveraged if needed). Given that we don’t want anybody else commanding our satellite, a secret 32-bit password will be included at the end of each command that will identify to the satellite that the command was uplinked by us. The password will not be documented anywhere publicly, either on Notion or Github.
| Command ID (0-1) | ACK Status (2) |
|---|
Command ID - The Command ID will contain the unique 16-bit value associated with the command that the ACK is reporting about. For example, if the satellite wants to acknowledge that it has successfully received the second command that was uplinked, then the command ID in the ACK packet will be 0x02.
ACK Status - The immediate response to the uplinked telecommand, indicates whether the command was accepted or rejected by the RF handler. The table below indicates what each byte value represents.
| ACK Status | Meaning |
|---|---|
| 0x00 | OK |
| 0x01 | Reset current Command ID |
| 0x02 | Invalid encoded format |
| 0x03 | Invalid length |
| 0x04 | Invalid checksum |
| 0x05 | Invalid decoded format |
| 0x06 | Invalid Command ID |
| 0x07 | Decremented Command ID |
| 0x08 | Repeated Command ID |
| 0x09 | Invalid opcode |
| 0x0B | Full command queue |
| Command ID | (0x1 << 15) (0-1) | Response Status (2) | Data (length depends on opcode) | | --- | --- | --- |
Command ID - The Command ID will contain the unique 16-bit value associated with the command that the response it is too (with an MSB of 1). For example, if the satellite wants to acknowledge that it has successfully received the second command that was uplinked, then