The local transceiver can use the AT+SBDIX command to get the MTMSN and MT queued fields. MTMSN is a wrap-around counter for MT messages. MT queued tracks the number of MT messages waiting to be processed by the local transceiver.
MT queued field was used for Raye to deal with global pathfinding payloads > 270B.
Why I don't recommend these
The use of MT queued in Raye assumed that if there are multiple messages queued, all of them must be processed to get the data. This assumed that we would not need to worry about:
Partial transmission sequences where only part of the multi-message sequence is sent successfully. So if 2/3 message are sent successfully but message 3 fails and continues to fail, then the first two messages are interpreted as the complete set of data and can lead to failure on the boat.
The queue would not get backed up. If another sequence of messages starts transmitting before the last sequence is processed, then the new message would be considered part of the same sequence.
MOMSN and MTMSN do not tell us how many messages there are to reconstruct the complete data.
This solution would necessitate additional metadata in the data payload to be adequately robust, but we would still need to work with other limitations of these fields. Hence I would recommend 2:
2. Create a Wrapper Packet
Add a new protobuf type with the fields:
Start of packet sequence: boolean
End of packet sequence: boolean
Data (either sensor data or global waypoints)
So long as we ensure that a new packet sequence does not start before the previous one finishes transmitting (i.e. we can not raise the start of packet sequence flag before raising the end of packet sequence flag), then this is a low overhead solution. This wrapper packet takes at most 2 bytes per message (not sure of the details of the compression). We can expect the Iridium network to keep messages in order.
I recommend creating a new Payload protobuf type as follows:
uint32 id; // For our use case, this is always 8 bit
bytes data;
data is serialized Protobuf data, either Sensors or Global Waypoints
id is an unsigned 8 bit number such that:
0b1000_0000 + X = 128 + X, where X ( < 128) is the index of the final entry in a sequence, is the id for the last entry in a sequence.
An id of 0b1000_0000 indicates a sequence of one element (i.e. it's just a single message).
0 is the first element in a sequence, 1 is the next, etc...
Since data will always be a whole number of bytes, there is no point in making the id field smaller than 8 bits as we are billed per byte. This method allows a maximum sequence length of 128 entries, which is more than sufficient based on Raye only needing a max of 23.
This introduces a fixed overhead of 1B per message. In exchange, we guarantee that up to 127 messages in one sequence can be sent and received out of order without issues. However, we must ensure that new sequences cannot begin before a previous sequence finishes, otherwise invalid data will be sent.
Alternatively, we could reserve an extra bit for something like a reset flag to reset the sequence. If we go down this route, we would have the top 2 bits reserved for indicating special ids. This would give us 4 unique ids in total (end of sequence, reset, and two more available for the future), in exchange for lowering the max length to 68.
Purpose
Handle situations where we may need to transmit more data than possible at once.
Description
The satellite has a limit for how large of a payload can be sent. The limits are:
To account for this, I recommend a mechanism to split data across multiple payloads when necessary.
Potential Solutions
I have two ideas that split the payload across multiple messages (and recommend option 2):1. Use the Iridium's MOMSN and MTMSN or MT queued fields (not recommended).
Why I don't recommend these
2. Create a Wrapper Packet
I recommend creating a new
Payloadprotobuf type as follows:datais serialized Protobuf data, either Sensors or Global Waypointsidis an unsigned 8 bit number such that:0b1000_0000 + X = 128 + X, whereX ( < 128)is the index of the final entry in a sequence, is theidfor the last entry in a sequence.idof0b1000_0000indicates a sequence of one element (i.e. it's just a single message).Since
datawill always be a whole number of bytes, there is no point in making theidfield smaller than 8 bits as we are billed per byte. This method allows a maximum sequence length of 128 entries, which is more than sufficient based on Raye only needing a max of 23.This introduces a fixed overhead of 1B per message. In exchange, we guarantee that up to 127 messages in one sequence can be sent and received out of order without issues. However, we must ensure that new sequences cannot begin before a previous sequence finishes, otherwise invalid data will be sent.
Alternatively, we could reserve an extra bit for something like a reset flag to reset the sequence. If we go down this route, we would have the top 2 bits reserved for indicating special ids. This would give us 4 unique ids in total (end of sequence, reset, and two more available for the future), in exchange for lowering the max length to 68.
To implement this, changes need to be made to both the Local and Remote Transceiver. For the Local Transceiver, this encompasses step 9 and onwards in the Transmit Sensors Sequence: https://ubcsailbot.atlassian.net/wiki/spaces/prjt22/pages/1768882211/Local+Transceiver#Transmit-Sensors-Sequence For the Remote Transceiver, this encompasses step 3 to 9 in the Receive Sensors Sequence: https://ubcsailbot.atlassian.net/wiki/spaces/prjt22/pages/1814954153/Remote+Transciever#Receive-Sensors-Sequence
Resources