Hello satellite, Kinéis’ device here!

Hello satellite, Kinéis’ device here!

Hello satellite, Kinéis’ device here!

Although in theory similar, the way the connected devices communicate with the Kinéis satellites is a bit more complicated than having a chat with your coworkers at the morning coffee break, and probably not the same content…


Each use case comes with its own features: physical environment of the device, specific amount of data to transmit or level of criticality of the data delivery time. To answer those different needs in the most efficient way, one can adapt and customize its transmission strategy.

What to transmit? Useful data from sensors (position from a GNSS receiver, temperature, pressure…), or user-specific messages. Message size depends on the precision required and the nature of the information to transmit. For example a 10m resolution GNSS location can typically occupy 8 bytes of data.
How to transmit? Messages are transmitted with a fixed repetition period, defined in accordance with the use case needs (amount of data to transmit, maximum age of the data…). To ensure a good reception considering the deployment constraints (transmission power, environment…), each message is usually repeated 3 to 5 times. Different transmission strategies exist, including data cycling and message interleaving, for a more efficient communication and thus an economy on battery consumption.
When to transmit? Kinéis relies on a constellation of polar low-earth orbit satellites that rotate at an impressive speed of nearly 8km/s around our planet, each satellite achieving global coverage in less than 12 hours. For a connected device, the communication is possible when a satellite passes above it, for a duration of up to 12 minutes depending on the maximum elevation reached by the satellite during the pass (passage angle in relation to the horizon).

4 types of transmission strategies are possible, depending on user needs and regulatory possibilities:

  • Transmission on satellite passes (standard situation): if the device knows its location (through a GNSS receiver for example) and the satellite orbit parameters, it is able to compute the satellite pass predictions thanks to an embedded algorithm. It can transmit only when a satellite passes overhead and thus optimize its transmission strategy.
  • Transmission on downlink reception: if the device has a receiver, it can listen periodically on the downlink and wait for a flag signaling the satellite availability before transmitting.
  • Interactive communication: forget the redundancy, here the device asks for acknowledgments from the satellites for all transmitted messages, allowing to retransmit every lost or wrong message. This strategy obviously requires a receiver and can complement either one of the previous.
  • Random periodic transmission: if the device is not aware of the satellite pass schedule and has no receiver, it can only transmit on a random basis. Some messages will not be received by the satellites, which is why an adapted repetition scheme is crucial in this scenario…


The satellites equipped with the downlink capability can transmit messages to the connected devices on Earth, including the acknowledgments mentioned above but also some useful information about the constellation for computation of the pass predictions and remote commands or messages.
What to receive?
Allcast messages: The satellites periodically broadcast useful information about the constellation, called “Allcast messages” and which are available for all devices: constellation status, orbit parameters for each satellite and UTC time.
The information from these allcast messages are necessary to compute the satellite pass predictions, but can be received by the device by other means (other connectivity systems, manual update…).
User messages: The satellites can transmit predefined messages for transceiver reconfiguration (change of transmission power, repetition period…) or custom messages for application-specific needs (sensor acquisition rate, configuration updates, textual messages…) to one or several terminals. In any case, the devices should be able to decode and interpret these messages.
How to receive? Allcast messages are transmitted permanently by the satellites, so the device only needs to listen whenever a satellite with an active downlink is passing.
A user message is addressed to one or several specific devices, so its transmission is simply triggered by an uplink message sent by this device.
When to receive? Considering the above, the receiver part of the terminal should be programmed with a specific duty cycle, depending on the downlink messages expected to be received and the satellite pass predictions.


An embedded algorithm is provided by Kinéis for the connected device to compute the satellite pass predictions. How does it work?
Input data: The device needs to know 3 things: its position, UTC date and time, and the orbit parameters for the satellites. The latter can be received via the downlink but also through other communication systems and have a validity period of up to 2-3 months. The first two are given by an embedded GNSS receiver, and a change of the device location by more than a few hundred kilometers triggers the need to recalculate the satellites passes.
Configuration settings: The algorithm can be customized with a few configuration settings to better determine optimal passage depending on use case constraints such as field elevation masks. Configuration includes: prediction begin and end dates, minimum elevation to consider, pass duration limitation or a time margin to take into account the possible shift of the embedded clock.
Output data: The algorithm gives the satellite pass list for the specified dates, but also the transceiver settings to apply depending on the capabilities of the satellites like downlink transmission or reception data rate

Defining the proper transmission strategy is a fine tuning task and will be the result of a compromise between amount of data to transmit, energy consumption and tolerance to failed transmissions considering the constraints introduced by the environment where the device is deployed. And all this for a fluid discussion, all around the globe!