In this article:
Message Queue
The message queue is the starting point for sending data on the Myriota Network. To transmit a message, add it to the queue using the ScheduleMessage() API.
Myriota’s communications technology allows large numbers of devices to transmit without complex handshaking. This helps deliver reliable communication while keeping device energy consumption low.
Once a message has been scheduled, the queue works with Myriota’s communication stack to manage when and how the message is transmitted. Messages are selected for transmission based on priority, which is influenced by the likelihood that a message has already been successfully received. Message age can affect priority, but it is only one part of the scheduler’s decision.
Message Queue Size
MessageBytesFree() reflects the available space for messages. It is updated each time a new message is added with ScheduleMessage(), or when the transmission of a message is complete. As of SDK 2.2.0, this API supports transmission of messages larger than the previous 20-byte limit, now offering messages from 20 to 1,500 bytes of user payload.
Additionally, MessageSlotsFree() reflects the number of free slots available in the scheduling queue, where a return value of 0 indicates that the queue is full. The total capacity of the queue is returned by the MessageSlotsMax() API, which currently returns 24. Please note that the MessageBytesFree() will return 3,800 bytes, and the additional 2300 bytes in the queue are reserved for future improvements.
If you continue to schedule messages once the queue is full, the Module copes with this by prematurely replacing the messages that have the highest likelihood of having been received successfully.
Overloading the queue may have the effect of reducing the target probability, resulting in a higher number of undelivered messages. Furthermore, each message has a maximum lifetime of 31 hours; if a message is not transmitted within this window, it will time out and the system will no longer attempt to send it.
Larger Messages
Myriota UltraLite devices, including FlexSense and the Myriota Module, are optimised for messages of up to 20 bytes. These messages are the most power-efficient and generally provide the best opportunity for fast delivery.
Larger messages are supported when your application needs to send additional sensor data, events, diagnostics, or metadata. To use larger messages, ensure your application is built with a supported SDK version:
| Device | Required SDK version |
|---|---|
| FlexSense | Flex SDK 2.3.0 or later |
| Myriota Module | Module SDK 2.1.0 or later |
Messages larger than 20 bytes are automatically encoded and split into smaller segments before transmission. The segments are transmitted across multiple satellite opportunities, with redundancy and retries included. The receiving system does not need every segment to be received, but it must receive enough valid segments to reconstruct the original message.
Larger messages require more transmissions than a 20-byte message. This can increase battery usage, use more queue capacity, require more satellite passes, and increase the time required for delivery. For expected latency and SLA details by message size, see Message Latency.
For best performance, use 20-byte messages where possible. Use larger messages when the additional data is valuable, and consider the impact on battery life, queue usage, delivery latency, and message success rate when choosing the message size.
How many messages can I schedule per day?
Whilst knowing how big, or how full the queue is can be useful, it may be more important to think of queue capacity in terms of how many messages you can schedule per day to meet a target latency.
The Myriota Network has two service types and the service limits are specified in the SLA.
At the time of writing these limits were 1,500B / day.
Scheduling no more than the daily rate with the ScheduleMessage() API, spread out across regular intervals, or using the BeforeSatelliteTransmit() API, will maximise the probability that all messages are successfully sent and delivered with minimal latency.
You are free to schedule more than the daily message rate, but doing so may overload the queue relative to the available capacity for transmission. You may see an increase in latency as a result and some messages may be not be delivered. See the Myriota Network Latency article for more details.
The recommended daily message rate will continue to increase as our service is optimised and improved.
Message Transmission
The Myriota Module uses stored Myriota Network Information, or network info, to predict when suitable satellites will pass overhead. This allows the Module to wake up for scheduled communication opportunities without continuous radio operation.
Network info can be programmed before deployment or updated by downlink after deployment to keep the Module synchronised with the Myriota constellation. For more information, see Network Info: Warm Start vs Cold Start.
During each transmission opportunity, the Module transmits as many queued messages as possible. Messages are selected by priority, which is based on the queue scheduler’s estimate of how likely each message has already been successfully received. A message may remain in the queue and be transmitted more than once until the target probability of successful reception has been reached.
This transmission behaviour helps minimise latency because newer messages are not required to wait for older messages to reach a minimum success threshold before being considered for transmission. It also improves delivery success by using redundant transmissions across satellite opportunities.
At present, MessageSlotsFree() only indicates how many queue slots are available for scheduling new messages. It does not confirm whether a specific message has been transmitted or delivered.
Message Queue Status
The MessageQueueStatus() API allows you to monitor the lifecycle of messages currently held in the message queue. Each message is referenced by the ID returned by the corresponding ScheduleMessage() call.
The API can report whether a message is waiting for transmission, actively being transmitted, fully transmitted from the device, or expired. A message expires if it is not transmitted within the 31-hour lifetime and is then removed from the queue.
To use this API effectively, call MessageSlotsMax() (currently 24) to determine the required size of the status array before calling MessageQueueStatus(). The function fills the array with the current status and ID of each queued message, and returns the number of entries written.
This visibility is useful for managing local storage, monitoring queued data, and deciding whether critical data should be scheduled again if a message reaches the expired state.
For implementation details, refer to the message queue example in the SDK.
Deleting from the Queue
It is not possible to remove a particular message from the queue.
Calling ScheduleMessage() when MessageBytesFree() or MessageSlotsFree() returns 0 will effectively replace a message in the queue.
The message replaced is typically that which has been in the queue for the longest time.
Message Arrival Order
A message may be transmitted more than once across different satellite passes to increase the probability of successful reception. If duplicate copies of the same message are received by the Myriota Network, Myriota Cloud removes the duplicates before forwarding the message to your Destination.
Messages are not guaranteed to be delivered in the same order they were scheduled. Delivery order can vary because messages are selected for transmission based on queue priority, satellite opportunities, and reception outcomes.
Myriota does not buffer messages to re-sequence them before delivery, as this would add latency. Myriota also does not add sequence numbers automatically, as this would use payload space that may not be required by all applications.
If your application depends on message order, or needs to detect missing messages, include a timestamp or sequence number in your payload. Your Destination can then use this information to re-order messages and identify gaps.