Fast Long-Range Protocol (FLRP-burst)

LR2021  ·  Sub-GHz & 2.4 GHz

Overview

FLRP-burst (Fast Long-Range Protocol) is a high-throughput wireless transfer protocol built on top of FLRC (PHY layer). It pairs a LoRa® wake-up phase with a high-speed FLRC burst, optimized for the transfer of large files with no strong latency requirements. The current release supports point-to-point communication; one-to-many and many-to-one topologies are under development.

Why FLRP-burst?

As detailed in AN 1200.101, in order to maximize performance, FLRC usage must cope with two main requirements:

Each mitigation applied independently introduces trade-offs in sensitivity, data throughput, or BOM cost.

→ The proposed protocol-level approach embodied by FLRP-burst provides a holistic solution, maximizing data throughput and sensitivity with the lowest impact on BOM cost and energy efficiency

FLRP-burst resolves both at protocol level:

• One LoRa WOR exchange compensates the frequency offset so FLRC is aligned before the first bit
  → no TCXO required  ·  up to 4× tolerance at low data rates (±17.5 → ±71 ppm at 325 kbps)
• LoRa timing sync collapses the FLRC Rx window to minimum
  → wake-on-noise eliminated  ·  17% lower Rx power from fewer correlators
• LoRa periodic CAD enables always-on listening at as low as ~100 µA
  → not achievable with standalone FLRC continuous RX

Key capabilities

• Up to 1.7 Mbps effective payload baud rate @ 2.6 MHz FLRC PHY
• 1 km+ range at 1 Mbps (Sub-GHz/22 dBm)
• Adaptive link with up to 16 channel selection and automatic datarate adaptation
• Reliable delivery: per-burst ACK with selective retransmit over lossy links
• Optional AES-CMAC per-packet integrity, replacing the radio CRC
• Sub-GHz and 2.4 GHz frequency bands

Roles

Each device has a fixed session role (Slave or Initiator) and a per-exchange data direction (who transmits the payload).

Session roles

Data-direction roles (set per exchange)

Packet Transaction

Every FLRP-burst exchange follows the same four-phase sequence regardless of transfer direction. The slave does not stay in continuous RX; it periodically checks for a LoRa preamble and sleeps in between.

Getting Started

The quick-start below shows the minimal code needed to get a first integration running. Include smtc_flrp_api/smtc_flrp_api.h and link against the FLRP-burst library.

smtc_rac_init();

smtc_flrp_api_config_t cfg = {
    .dev_eui        = { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07 },
    .crypto_enabled = false,          /* true enables AES-CMAC MIC per packet */
    .freq_plan      = SMTC_FLRP_FREQ_865MHz,
    .crystal_error  = 20,             /* local oscillator accuracy in ppm     */
};

smtc_flrp_init( cfg, on_tx_done, on_rx_done, NULL );

smtc_flrp_radio_config_t radio = smtc_flrp_get_current_radio_config();
radio.flrc.tx_power_in_dbm      = 14;
radio.flrc.raw_bit_rate         = RAL_FLRC_RAW_BIT_RATE_2_600_MBPS;
smtc_flrp_set_new_radio_config( radio );

smtc_flrp_com_config_t com = {
    .com_mode             = SMTC_FLRP_BIDIRECTIONAL,
    .slave_dev_eui        = { 0x10, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07 },
    .filter_len           = 0,         /* EUI prefix bits for ONE_WAY broadcast */
    .link_adaptation_mode = SMTC_FLRP_LINK_ADAPTATION_FULLY_ENABLED,
};

/* Send data to slave */
smtc_flrp_initiate_transmission( tx_buf, tx_size, com );

/* Request data from slave */
smtc_flrp_initiate_reception( rx_buf, sizeof( rx_buf ), com );

while( 1 )
{
    if( smtc_flrp_call_run() )
        smtc_flrp_run_engine();
}

static uint8_t rx_buf[20 * 1024];

smtc_flrp_start_periodic_listening( rx_buf, sizeof( rx_buf ) );

smtc_flrp_slave_prepare_data_to_send( tx_buf, tx_size );
/* Clear with tx_size = 0 */

while( 1 )
{
    if( smtc_flrp_call_run() )
        smtc_flrp_run_engine();

    /* sleep / idle until next radio event */
}

void on_tx_done( const void* ctx, smtc_flrp_return_code_t status,
                 bool send_successful, uint8_t* dest_eui )
{
    if( status == SMTC_FLRP_RC_OK && send_successful )
        /* data delivered to dest_eui */
}

void on_rx_done( const void* ctx, smtc_flrp_return_code_t status,
                 uint32_t payload_size, uint8_t* src_eui,
                 smtc_flrp_rx_stats_t stats )
{
    if( status == SMTC_FLRP_RC_OK )
        /* rx_buf holds payload_size bytes from src_eui; stats has RSSI and burst PER */
}

Sample Projects

Two ready-to-run sample projects are available, covering both bare-metal and Zephyr environments. Each project supports both roles on a single binary; the active role is selected at compile time.

Bare-Metal

Repository: github.com/Lora-net/USP · Source: examples/main_examples/flrp_api_example/ · Board: NUCLEO-L476 + LR2021

Demonstrates periodic initiator-to-slave transfer (every 20 s by default) and on-demand transfer triggered by a button press on either device. Both roles listen for incoming transfers from the other side, so the example exercises the full bidirectional flow.

Zephyr

Repository: github.com/Lora-net/USP_Zephyr · Source: samples/usp/rac/flrp_api/ · Board: XIAO nRF54L15 + LoRa Plus EVK (LR2021)

Same behaviour as the bare-metal example: periodic and button-triggered transfers in both directions, ported to the Zephyr RTOS. Demonstrates integration with the Zephyr radio driver abstraction and west build system.

Power Profiler

The interactive power profiler below estimates the energy consumption of each node for a given FLRP-burst configuration. Adjust the TX interval, WOR preset, FLRC burst parameters, and idle/sleep current to see average current, energy per cycle, and a zoomed current waveform in real time.

In the typical FLRP-burst deployment, each node operates simultaneously as initiator and slave: it transmits data on its own schedule while sleeping between transmissions, and wakes up via periodic CAD whenever the other node initiates a transfer. Either node can start an exchange at any time; the initiated transfer takes priority over the idle/sleep cycle. This gives a fully bidirectional link with no dedicated polling master.

The WOR preset controls the trade-off between wake-up latency and receive duty cycle: a longer WOR preamble means the listening node can sleep longer between CAD pulses (lower power), but the initiator takes longer to wake the peer. The two nodes can use different presets independently, allowing an asymmetric design matched to the application.