Menu

Downlink Operation

In this article:

    The Myriota UltraLite Module is capable of both transmitting and receiving messages via the Myriota Network. The receive path is called the downlink.

    What is the downlink used for?

    The downlink is used for two main purposes:

    1. Myriota network updates: system messages sent by the Myriota Network
    2. Device Control: user messages sent from the Myriota Cloud

    Device Control uses the same Myriota Network downlink path that is already used to deliver network updates.

    Network updates

    Network updates are essential for keeping Myriota-enabled devices synchronised with the Myriota Network. These updates may include:

    • Current time information
    • Updates about new satellites in the Myriota constellation
    • Satellite orbital parameters and radio configuration
    • Communication channel updates
    • Regulatory permission updates
    • Security updates

    All Myriota-enabled devices must be capable of receiving these periodic network updates. Without downlink capability, a device may eventually lose track of the Myriota satellite constellation and may not be able to take advantage of improvements in Network capacity as existing assets are replaced and new assets come online.

    For this reason, downlink capability is mandatory for long-term deployments.

    Device Control

    Device Control allows you to send messages from the Myriota Cloud to a specified Myriota-enabled device in the field.

    Device Control messages can be used by your application to control or reconfigure a device. For example, your application may use a Device Control message to update application settings, change operating modes, or trigger an action on the device.

    Device Control is available in SDK 2.0.0 and later.

    What frequency is used for the downlink?

    Both Service 1 and Service 2 variants of the Myriota Module are downlink capable and receive downlink messages on the UHF band.

    Refer to the Service Types article for more information about the differences between Myriota Network Service 1 and Service 2.

    Refer to the Myriota Module Datasheet and Myriota Antenna Design Guide for detailed technical information about Module variants, downlink frequencies, and RF requirements.

    How does Device Control work?

    Device Control messages are delivered over the Myriota Network downlink.

    The typical flow is:

    1. A Device Control message is scheduled for a Myriota-enabled device using the Cloud API or Device Manager
    2. The message is queued in the Myriota Cloud
    3. The message is uploaded to the Myriota satellite constellation at the next available opportunity
    4. The message is downlinked from the constellation to the target device
    5. The user application on the device receives and processes the message

    How can I send a Device Control message?

    Device Control messages can be sent using either:

    Sending via Device Manager

    To send a Device Control message in Device Manager:

    1. Select the target device
    2. Click Send Control Message
    3. Enter a hexadecimal string, or upload a file containing the message
    4. Submit the message

    DeviceManager-DC1a.png

    Device Control messages can be up to 100 bytes.

    If uploading a file, the file must contain 100 bytes or less of raw data. Uploaded files are treated as raw bytes and converted to hexadecimal. If you need to send exact byte values, enter the hexadecimal string directly or upload a binary file containing the intended bytes.

    Sending via the Cloud API

    Device Control messages can also be created, listed, retrieved, and cancelled using the Device Control Cloud API.

    Use the API to:

    • List current and previous Device Control messages
    • Create a new Device Control message
    • Cancel a message while it is still pending
    • Retrieve details for a specific message

    Refer to the Cloud API documentation and SDK code examples for implementation details.

    How big can Device Control messages be?

    Device Control messages have a maximum size of 100 bytes.

    How often can I send Device Control messages?

    You can schedule one Device Control message per device per 24-hour period.

    How long does it take for a Device Control message to arrive?

    Device Control messages are not real-time messages.

    You can expect:

    • Median latency: approximately 24 hours
    • 90% latency: approximately 36 hours

    Actual delivery time may vary depending on satellite opportunities, device location, device receive performance, and environmental conditions.

    Does my device need to support downlink?

    Yes.

    All Myriota-enabled devices must support downlink for network updates. Devices that do not receive periodic network updates may eventually lose synchronisation with the Myriota Network.

    To use Device Control, the device must also have suitable receive performance and the user application must be updated to receive Device Control messages.

    What RX performance is required?

    The minimum RX Rate required for a device to be viable in the field is greater than 10%.

    This level is sufficient for receiving Myriota network updates, but it is not sufficient for Device Control.

    To use Device Control, the device must have a minimum RX success rate of 20%.

    If your device does not meet this criterion, Myriota can assist with improving receive performance. Alternatively, you can use a Myriota device with a known high-performing RX path, such as a FlexSense device, Developer Toolkit to begin testing Device Control in your application.

    How do I design a downlink-ready device?

    Refer to the Myriota Antenna Design Guide for RF and antenna design requirements.

    If you have already developed and Myriota-certified your own integrated device, it should already include a working RX path as part of its antenna system. However, Device Control requires stronger RX performance than the minimum required for basic network updates.

    Improving RX performance provides several benefits:

    • Devices can respond to network changes more quickly
    • Devices with better RX performance may require fewer downlink attempts to receive network updates
    • Receive performance can affect power consumption
    • Devices with stronger RX performance are better prepared for Device Control use cases

    If you need help reviewing or improving downlink performance, submit a support ticket.

    How do I check downlink performance?

    Device receive performance can be reviewed in Device Manager.

    RX Rate

    The RX Rate is available in the Devices table in Device Manager.

    To view it:

    1. Open Device Manager
    2. Locate the device in the Devices table
    3. Scroll to the RX Rate column

    If the RX Rate column is not visible, use the Configure columns option in the table header and enable the RX Rate column.

    By default, the RX Rate is a two-week rolling average of the percentage of downlink messages successfully received by the device. This information is derived from diagnostic messages transmitted periodically by each Myriota Module.

    RX Telemetry chart

    For a deeper view of receive performance over time, use the Device Telemetry chart.

    With the device selected in Device Manager, click Telemetry to view historical receive performance.

    When assessing receive performance, focus on the average trend rather than a single data point. RX performance can vary from day to day depending on satellite passes, deployment conditions, external noise, weather, and other transient environmental factors.

    How does my application receive Device Control messages?

    Your user application must use the SDK receive functionality to process Device Control messages.

    The SDK provides:

    • OnReceiveMessage
    • ReceiveMessage

    The receive example in the SDK demonstrates how to use these functions.

    In the example, the application:

    1. Waits for a Device Control message using OnReceiveMessage
    2. Recovers the message using ReceiveMessage
    3. Prints the received message as a hexadecimal string
    4. Schedules an uplink message containing receive timing information and the first 10 bytes of the received Device Control message

    This approach allows you to confirm that a Device Control message was received by the device by sending an acknowledgement back through the Myriota Network.

    How do I know if a Device Control message was received?

    Device Manager provides a Control Message History view for each device.

    This view includes:

    • ID: the Device Control message ID
    • Status: the current message status
    • Created: the time the message was created and uploaded to the Myriota Cloud
    • TransmitStart: the earliest expected transmission time from satellite to device
    • TransmitEnd: the latest expected transmission time from satellite to device

    The message status may include:

    • Pending: the message has been uploaded to the Myriota Cloud
    • Active: the message is in transit through the Myriota Network
    • Complete: the message has been transmitted to the target device

    A Complete status means the message has been transmitted to the device. It does not confirm that the device successfully received or processed the message.

    To confirm receipt, your application should send an uplink acknowledgement after receiving the Device Control message. The SDK receive example demonstrates one way to do this.

    Will Device Control affect battery life?

    Yes, but the impact is expected to be mild.

    Receiving Device Control messages requires the receiver to turn on more often. As a guide, using one Device Control message and one uplink message per day may increase Myriota Module energy consumption by approximately 10%.

    Actual battery impact will depend on your application, device configuration, message frequency, and deployment environment.

    Best practices for using Device Control

    When designing an application that uses Device Control:

    • Keep messages short and clearly defined
    • Include a command type or version field in your application message format
    • Design your application to handle delayed messages
    • Do not rely on Device Control for real-time control
    • Consider adding an acknowledgement uplink message after a control message is received
    • Validate RX performance before relying on Device Control in the field
    • Test the application in a location with a clear view of the sky
    • Design for the possibility that a message may not be received

    Related articles