Module Payload Queue
Introduction
The module expects to be powered continuously. It is designed to minimise current draw by maximising time in the sleep state. The uninterrupted power is important for maintaining the internal time and schedule of satellite passes and using that information to transmit at the correct times.
The illustrations are not yet compatible with dark mode. Please use light mode.
Uplink Message Queue
Queueing and sending messages
The Astronode S message transmit queue has 8 slots available for messages. Each message can contain 1-160 bytes payload and optional geolocation data, see Uplink message.
The queue works in a First-In-First-Out (FIFO) manner:
With the Payload Enqueue Request command PLD_ER, a new message is stored on top of the queue:
With every other Payload Enqueue Request, a new message is stored on top of the queue, shifting older messages:
When all 8 slots contain a message, and the Payload Enqueue Request is called again, the new message will not be stored, and the Astronode S returns a BUFFER_FULL error :
On next contact with a satellite, messages are sent to the satellite by sending the oldest message first:
When loosing contact with the satellite, a message may have been sent partially only. The remaining parts of the message (fragments) stay in the queue until the next satellite contact:
Deleting queued messages
With the Dequeue Request command PLD_DR, the oldest message will be removed from the queue and deleted:
With the Free command PLD_FR, the entire queue will be cleared, and all contained messages deleted:
Downlink Command Queue
The Astronode S command receive queue has a single slot for either an 8byte or a 40byte command:
Once a command queued in the Astrocast Data Management is forwarded to the satellites, the Astronode S will receive the command the next time it transmits a message to a satellite.
The command is then available in the queue and the Command Available Bit set to 1 in the Event Register. The Bit can be checked with the Event Register Read Command EVT_RR. The Command Read Request CMD_RR will then return the received command:
As long as a device is not sending any message, it will not receive any command.
If the first command has not been cleared yet on receiving a second one, the first one will be discarded, and the second command placed in the queue:
Reading the Event Register and reading queued commands before sending messages can help avoid losing incoming commands
To clear the command queue, use the Command Clear Request command CMD_CR. The command will be removed from the queue and deleted:
Uplink payloads are acknowledged.
In the satellite context, acknowledgement confirms that the messages have been received by the satellite. There may be an addition delay in transmission from the satellite to the ground station, so once the acknowledgement is available on the module, there may be a delay in receiving it in the Astrocast portal.
In the Wi-Fi context, acknowledgement confirms that the message has been received by the Astrocast backend and should be available almost immediately in the Astrocast portal.
The event pin is used to notify the asset of a pending notification (acknowledgement available or module reset).
When an acknowledgement is available on the module, the module will set the event pin high. The asset may detect this and query which message has been acknowledged. Once the asset has queried the acknowledgement and confirmed it, the message life cycle on the module is complete and it is deleted.
It is also possible to set the module not to indicate acknowledgements. In this case, as soon as the ack is received by the module, the message is deleted.
Acknowledgments may be presented to the asset out of order. i.e. An older message may be acknowledged before a newer one, even though the asset would attempt to send the newer message first.