The LR-FHSS Frames Dataset

This dataset contains the data from two distinct experimental setups: one in an urban scenario within different environments (ranging from direct to obstructed line-of-sight conditions) and another in an aerial scenario using balloon platforms, providing clear line-of-sight.

This dual approach allows us to assess LR-FHSS performance under varied signal propagation conditions and identify optimal deployment conditions.

The ballon dataset contains 2033 frames sent by 4 end devices during stratospheric balloons flights on May 24th, 2024. Frames were collected for 2 hours and 28 minutes.

The urban dataset contains 1132272 frames sent by 5 devices from May to October 2024.

This archive contains mainly the raw data. The files used for analysis and more are available on the public LR-FHSS dataset github page

Long Range Balloons Experiment

End Devices

We used 4 LR-FHSS devices dispatched aboard three stratospheric balloons gondolas

| Device Id | Balloon Id | DevAddr | DevEUI | | --------- | ---------- | ------- | ------ | | 1 | 1 | 260B5A7A | 70B3D57ED0066609 | | 2 | 2 | 260BAE81 | 70B3D57ED0066806 | | 3 | 2 | 260B9030 | 70B3D57ED0066805 | | 4 | 3 | 260B83C4 | 70B3D57ED0066804 |

The end devices are four LR1120 development kits, from Semtech, runing a modified version of the LR-FHSS application sample code found in the Lora-net repository.

Remark: the devices were initially registered in ABP mode on TheThingsNetwork EU. However, for our experiments, we used a private instance of Chirpstack v4.7 deployed on a Microsoft Azure virtual machine.

Gateway

The gateway we used was a Wirnet iBTS Compact gateway from Kerlink, running a custom LR-FHSS enabled firmware provided by semtech. The gateway was running a custom LR-FHSS enabled firmware provided by Semtech.

Ballon Dataset

The dataset is available in the dataset.json file. The gps data of the balloons is avaiable in the raw_irma_log folder. It is used by the notebook to compute the estimated_lat_lon_alt field. The computation is done in the irma_nacelle_position_parser file, and is simply a linear interpolation of the positions over time.

Fields

• rx_timestamp_ms: the milisecond timestamp of frame reception
• dev_addr: address of the device who sent the frame
• frame_counter: frame counter, counts from 0 on the first frame sent
• coding_rate: coding rate of the payload fragments, for our experiment, it takes only two values: CR_2_6 and CR_4_6 for a coding rate of respectively 1/3 and 2/3
• channel_width: the channel bandwidth, in hz, either 137000 or 336000
• data_rate: The corresponding LoRa data rate, for LR-FHSS, it goes from DR8 to DR11
• tx_power_dbm: Tx power of the frame, goes from 0 to 16 dBm.
• rssi_dbm: Received signal intensity, in dBm
• balloon_id: Id of the ballon that sent the frame, goes from 1 to 3
• estimated_lat_lon_alt: Estimated position of the ballon when the end device sent the frame. The position is computed from the GPS positions sent by the meteo sondes M20 installed aboard the gondolas

The values are directly avaliable from the gateway logs, except for: - the data_rate, which is infered from the coding_rate and channel_width. - the balloon_id, infered from the dev_addr - the estimated_lat_lon_alt, infered from the rx_timestamp_ms and the logs from the IRMA gps tracker on the balloons.

Flights

A detailed explanation of the aim of the flights and modules installed on board is available on the Thingsat repository. There are also pictures.

Urban Experiment

Gateway

Identical to the balloon experiment, the gateway we used was a Wirnet iBTS Compact gateway from Kerlink, running a custom LR-FHSS enabled firmware provided by semtech. The gateway was running a custom LR-FHSS enabled firmware provided by Semtech.

Urban Dataset

The data is available in the raw data folder. It contains the .data and .gpx files. Theses files contain the raw data received from the gateway during the experiments, these files are necessary if:

• You want to recalculate the with different configurations.
• Generate different pictures in the bicycles rides.

The raw data totals 1132272 frames.

You can find examples of generated figures from this data in the Figure folder of the github repository as well as the code used to generate tem in the Analysis folder

Naming format, content of the data files and devices

The files have a .data extension, this extension is arbitrary and was chosen by the intern (Marcos Rojas Mardones)

They only saved data from the 5 devices that belonged to the experiments.

The naming format of the files is the same as in the Processed directory, this means that the velo files are made in July and the number represent the date, patches2 and 5 are the 'official ones', patches 3 and 4 are contained inside patches5.

The rest of the names simply indicate the day on which that file was created and when it started recording data, the data that finishes or has some 'DRSeker' counted every frame received, independent of the origin, with these files it was possible to know which DR and frequency channels were the most used.

All the .data files are csv-like files and should be analyzed as such.

The format of the .csv files is as follows:

|DevEUI| DR | Date and time | payload |Frequency|RSSI (S)|Frequency Offset| SNR|channel S| |-----------|-----------|-----------|-----------|-----------|-----------|-----------|-----------|-----------| |...|...|...|...|...|...|...|...|...|

The relationship between DevEUI and Device ID is as follows: * 1b24ff2: Device 1 * 2b24ff2: Device 2 * 3b24ff2: Device 3 * 4b24ff2: Device 4 * 5b24ff2: Device 5

Naming format and content of the gpx files

The gpx files contains the data from gps information on the bicycle rides (positions and times). There's a 2 hours offset between the hour in the gpx files and the real time on france This means that you should add 2 hours to every hour in the gpx file.

The gpx file say the day and month of the measurement, if they had an extra '_nigth' means that the measurement was done in the afternoon For details for the exact time check each gpx file.

The '_modify' files are modify version of the gpx file to cut the route until the maximun communication achieved.

Authors

• Marcos Rojas Mardones
• Florent Dobler
• Léo Cordier
• Didier Donsez
• Juan Faire
• Oana Iova

Citation

Marcos Rojas Mardones, Florent Dobler, Léo Cordier, Didier Donsez, Juan Faire, Oana Iova, "The LR-FHSS frames dataset", 2025, https://doi.org/10.18709/perscido.2025.04.ds421