-
Notifications
You must be signed in to change notification settings - Fork 6
Selecting the best Sigfox messages parameters
A Sigfox message can be sent in various ways depending on the targeted use case and the expected power consumption profile.
There are two mains parameters which can be adjusted by the device application: the number of frames replicas per message and the bitrate.
One Sigfox uplink message can be composed of 1, 2 or 3 repetitions transporting the same user payload. This parameter, often abbreviated to N, selects the radio diversity of the message:
- Frequency diversity: every single frame is sent at a random frequency, improving robustness against radio interferers in the shared ISM band.
- Time diversity: every single frame is sent one after the other at different timestamps (with a configurable delay from 0 to 2 seconds).
- Also we need to highlight that spatial diversity (not device dependant but more linked to the base stations network which bring coverage) is important and add robustness in message success rate.
The more frames per message, the more diversity and thus the more chance of reception by the network. But the more frames per message, the higher power consumption for a same message.
| ✅ | ❌ | |
|---|---|---|
| N=1 | Low power consumption | Lower transmission success rate |
| N=2 | Trade-off | Trade-off |
| N=3 | Higher transmission success rate | Higher power consumption |
In the new open source library, you can either choose the SINGLE_FRAME option (fixed N=1 mode which also saves memory footprint) or dynamically select the number of frame when sending a message.
- Fixed single frame
In sigfox_ep_flags.h file:
#define SINGLE_FRAME- Dynamic number of frames
In sigfox_ep_flags.h file:
//#define SINGLE_FRAMEIn your application:
// Local variables.
SIGFOX_EP_API_status_t ep_api_status = SIGFOX_EP_API_SUCCESS;
SIGFOX_EP_API_application_message_t application_message;
// Select parameters.
...
application_message.common_parameters.number_of_frames = 3;
...
// Send message.
ep_api_status = SIGFOX_EP_API_send_application_message(&application_message);Tip
In a same device application, you can adjust the number of frames dynamically, depending on the power source level or the data criticality.
Warning
This section only applies to radio configuration zones which support both bitrates (RC1, RC3, RC5, RC6 and RC7). In RC2 and RC4 zones, the 600 bps remains the only supported bit rate.
When dual bit rate is supported by the network, the device can either transmit uplink messages at 100 bps or 600 bps bitrate.
The 100 bps leads to a narrower signal and thus to the highest reception sensitivity on the base station side. However, the signal lasts longer, leading to an higher power consumption.
The 600 bps leads to a wider signal and thus to a lower reception sensitivity for the same RF output power (~8dB of budget link penalty in comparison to the 100 bps). However, the signal is very short and uses 6 times less energy compared to 100bps. Even if it is not easy to highlight on the field, some experimentations have also shown that a higher bitrate brings a little improvement in a mobility situation (when the device is moving while transmitting). Another benefit of the shortness of the radio burst, the transmission is less sensitive to the oscillator drift, which is a common issue on slow radio signals.
| ✅ | ❌ | |
|---|---|---|
| 100 bps | Best quality of reception (highest link budget) | Higher power consumption and more sensitive to oscillator drift |
| 600 bps | Low power consumption, less sensitive to oscillator drift and slight improvement in mobility | Lower quality of reception (8dB less in budget link) |
In the new open source library, you can either choose a fixed bitrate or select it dynamically when sending a message.
- Fixed bitrate
In sigfox_ep_flags.h file:
#define UL_BIT_RATE_BPS 100- Dynamic bitrate
In sigfox_ep_flags.h file:
//#define UL_BIT_RATE_BPSIn your application:
// Local variables.
SIGFOX_EP_API_status_t ep_api_status = SIGFOX_EP_API_SUCCESS;
SIGFOX_EP_API_application_message_t application_message;
// Select parameters.
...
application_message.common_parameters.ul_bit_rate = SIGFOX_UL_BIT_RATE_100BPS;
...
// Send message.
ep_api_status = SIGFOX_EP_API_send_application_message(&application_message);Tip
If both bitrates have been implemented in the radio driver (RF_API) of a same device application, you can adjust the bitrate dynamically depending on the power source level or the data criticality.
Let's take a practical example of a solar GPS tracker which periodically sends a geolocation message (device position read from GPS) and a monitoring message (solar panel and battery voltages).
We can imagine the following message parameters depending on the message and the battery level:
| Message | Data criticality | Battery well charged | Low battery condition |
|---|---|---|---|
| Geolocation | N=3 / 100 bps | N=3 / 600 bps | |
| Monitoring | ✅ Low | N=3 / 600 bps | N=1 / 600 bps |
Let's take another example of a low cost asset tracker which has to update regularly its position during the mobility phase, and one time a day during storage. Such device can benefit from a dual bitrate capability:
- In a mobility condition, using the 600 bps to be able to update its position on a regular basis (thanks to Atlas Native geolocation for instance) with a reduced power consumption.
- In a storage condition, the update periodicity of the data is not critical, as the asset is not moving, but it's really important to receive the information (monitoring, presence, etc..) and locate the asset, so the device could use 100 bps one time a day in order to have more link budget margin to reach the network infrastructure even if it is stored in deep underground.
| Message | Periodicity | Message parameters |
|---|---|---|
| Periodic location update during mobility | every 30 minutes | N=1 or N=3 / 600 bps |
| Storage | 1 time a day | N=1 or N=3 / 100 bps |
In this way we can benefit from both bitrates, one more dedicated to energy saving, slight radio transmission improvement in mobility, and reactivity when the asset arrives in some specifically covered area; the second when the reactivity or position update is not key when asset is stored for long term, but we wants to have the best possible visibility on the asset position and/or monitoring.
This is another example which could be interesting for some devices deployed on the field in great coverage area. Since the device can dynamically adapt the number of transmission and the bitrate used in uplink transmissions, the solution provider can adapt the device behavior regarding the real coverage of the device, in order to reduce the power consumption and thus extend the device lifetime.
There are different ways to configure the device:
- by device configuration in production.
- at the device installation by local configuration.
- remotely with downlink messages.
As an example, after a first observation period of 10 to 20 messages, if the LQI (Link Quality Indicator) is excellent during most of the messages, the solution provider could choose to move from 100 bps to 600 bps for some particular messages. The solution provider could also develop its own indicator based on message success rate or any other parameter.
Warning
Since a Sigfox device operates in a shared ISM band, the LQI or any radio indicator could vary a lot over time, even in a fixed installation. So whatever the reconfiguration strategy, it is very important to keep at least 1 periodic message with maximum budget link, and make the device robust against configuration data loss if it is sent by downlink (fallback to default).
As an example, we could imagine the following patterns:
- Default device configuration at installation:
| Message | Periodicity | Message parameters |
|---|---|---|
| Meter index | 2 times a day | N=3 / 100 bps |
| Alarm water leakage | 1 per month | N=3 / 100 bps |
| Reconfiguration message (with last meter index) | 1 per month | N=3 / 100 bps |
In this default configuration, the device sends 64 uplink messages (62 meter indexes + 2 service messages) at 100 bps per month.
- Device configuration after excellent LQI for 20 messages:
| Message | Periodicity | Message parameters |
|---|---|---|
| Meter index | 2 times a day | N=3 / 600 bps |
| Alarm water leakage | 1 per month | N=3 / 100 bps |
| Reconfiguration message (with last meter index) | 1 per month | N=3 / 100 bps |
In this new configuration, the device sends 62 uplink messages at 600 bps (meter indexes) and 2 uplink messages at 100 bps (service messages) per month, leading to gain of 5.8 on the power consumption.
Thanks to this strategy, on these devices covered with a lot of margin, the solution provider could optimize the power consumption, and thus highly increase the device lifetime while keeping some particular service messages with maximum budget link and service quality. If there is an evolution of the coverage locally, or in abscence of downlink reconfiguration message, device could recover automatically to default mode at 100 bps to benefit from the maximum link budget.
Also, the solution provider could decide in the same way to change device output power (for instance, from class 0U to class 1U), as well as the number of frames per messages (N=1, 2 or 3).