LoRa and LoRaWAN simulator-cum-emulator with CAD and capture effect in Python
Pith reviewed 2026-05-21 01:36 UTC · model grok-4.3
The pith
A Python discrete-event simulator for LoRaWAN reproduces the capture effect through a three-phase packet model and runs real STM32 firmware via CFFI redirection.
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
Core claim
The simulator is built on a custom asyncio-based simulation kernel, incorporates a three-phase packet delivery model to reproduce the capture effect, implements a full LoRaWAN 1.0.4 stack, and features a containerized system that cross-compiles real STM32 C firmware and redirects its HAL calls into the simulator using CFFI, all without requiring any external simulation framework or dependencies.
What carries the argument
The three-phase packet delivery model that reproduces the capture effect together with CFFI redirection of HAL calls from real STM32 firmware.
If this is right
- The simulator supports evaluation of all LoRaWAN device classes through its complete 1.0.4 stack implementation.
- Real STM32 firmware can be tested inside the simulation environment without physical radios.
- Users obtain the tool as a standard Python package that needs no external frameworks.
- Network scenarios involving the capture effect become directly observable in discrete-event runs.
Where Pith is reading between the lines
- The CFFI redirection pattern could be reused for other embedded wireless stacks that expose similar hardware-abstraction layers.
- Direct head-to-head runs against physical testbeds would reveal whether the three-phase model needs calibration for particular spreading factors or environments.
- Large-scale parameter sweeps that are impractical on hardware become feasible, potentially guiding deployment choices before any nodes are installed.
Load-bearing premise
The three-phase packet delivery model and CFFI redirection of hardware calls accurately capture real radio behavior and firmware timing without introducing simulation artifacts absent on physical hardware.
What would settle it
Run identical firmware on the simulator and on physical STM32 LoRa hardware under controlled overlapping transmissions of differing strengths, then compare measured packet delivery rates and timings.
Figures
read the original abstract
Existing LoRaWAN/LoRa simulators consist of large, complicated C++ codebases and often do not support all device classes. This paper presents the design of a simple to use, Python-based discrete-event simulator that addresses these gaps while also introducing a novel method for evaluating real device firmware in the simulator. The simulator is built on a custom asyncio-based simulation kernel, a three-phase packet delivery model that reproduces the capture effect, a full LoRaWAN 1.0.4 stack, and a containerized firmware system that cross-compiles real STM32 C firmware and redirects HAL calls into the simulator via CFFI. The simulator is distributed as a Python package via Github (https://github.com/MatthijsReyers/lora-simulator) and requires no external simulation framework or dependencies.
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The paper presents the design of a Python-based discrete-event simulator for LoRa and LoRaWAN networks. It uses a custom asyncio simulation kernel, a three-phase packet delivery model intended to reproduce the capture effect, a complete LoRaWAN 1.0.4 protocol stack, and a containerized cross-compilation setup that redirects STM32 HAL calls into the simulator via CFFI to allow evaluation of real C firmware. The simulator is released as a standalone Python package with no external dependencies.
Significance. If the models prove accurate, the work would supply a lightweight, dependency-free alternative to existing large C++ LoRa simulators and enable direct testing of production firmware inside a controlled simulation environment. The combination of CAD support, capture-effect modeling, and firmware emulation is a practical contribution for protocol and firmware evaluation studies.
major comments (2)
- [Packet delivery model] The central claim that the three-phase packet delivery model reproduces the capture effect rests on the architectural description alone. No quantitative comparison (e.g., packet success rates, collision outcomes, or CAD detection latency) against measurements from physical LoRa radios is provided, leaving the fidelity of the model unverified.
- [Firmware emulation system] The CFFI-based HAL redirection for real STM32 firmware is presented as faithfully emulating timing and radio behavior. Without side-by-side traces comparing simulator output (end-to-end timing, packet delivery under interference) to hardware execution, it is not demonstrated that the emulation introduces no artifacts absent from physical devices.
minor comments (2)
- [Abstract] The abstract states support for all device classes; the main text should explicitly enumerate which classes (A, B, C) are implemented and any limitations.
- [Introduction] A feature-comparison table against prior LoRa simulators would help readers quickly assess the claimed advantages in simplicity and firmware support.
Simulated Author's Rebuttal
We thank the referee for the constructive feedback on our manuscript. We address each major comment below and indicate the planned revisions to strengthen the presentation of our simulator's models and emulation capabilities.
read point-by-point responses
-
Referee: [Packet delivery model] The central claim that the three-phase packet delivery model reproduces the capture effect rests on the architectural description alone. No quantitative comparison (e.g., packet success rates, collision outcomes, or CAD detection latency) against measurements from physical LoRa radios is provided, leaving the fidelity of the model unverified.
Authors: We agree that the manuscript currently supports the claim of reproducing the capture effect primarily through the description of the three-phase packet delivery model. The model incorporates established LoRa physical-layer behaviors for preamble detection, payload demodulation, and interference handling. To address this, the revised manuscript will include a dedicated validation subsection with quantitative comparisons to physical LoRa radio measurements, reporting metrics such as packet success rates and collision outcomes under controlled interference conditions. revision: yes
-
Referee: [Firmware emulation system] The CFFI-based HAL redirection for real STM32 firmware is presented as faithfully emulating timing and radio behavior. Without side-by-side traces comparing simulator output (end-to-end timing, packet delivery under interference) to hardware execution, it is not demonstrated that the emulation introduces no artifacts absent from physical devices.
Authors: The emulation approach uses CFFI to redirect STM32 HAL calls and containerized cross-compilation to integrate real firmware. While the current text describes the architecture, we acknowledge that direct comparative traces would better demonstrate absence of simulation artifacts. In revision, we will add example side-by-side timing traces and packet delivery results from simulator runs versus equivalent hardware executions to illustrate the fidelity of the emulation for end-to-end scenarios. revision: yes
Circularity Check
No circularity in simulator design description
full rationale
The manuscript describes the architecture of a Python-based discrete-event LoRaWAN simulator, including an asyncio kernel, a three-phase packet delivery model, a LoRaWAN 1.0.4 stack, and CFFI-based redirection of STM32 HAL calls. No mathematical derivations, first-principles predictions, or fitted parameters are claimed. The central engineering claims concern implementation mechanisms rather than results that reduce to self-definition, self-citation load-bearing premises, or renaming of known patterns. The work is therefore self-contained as an artifact whose correctness is intended to be assessed against external hardware traces.
Axiom & Free-Parameter Ledger
axioms (2)
- domain assumption The three-phase packet delivery model accurately reproduces the capture effect observed in real LoRa radios.
- domain assumption CFFI redirection of STM32 HAL calls preserves firmware timing and behavior sufficiently for evaluation purposes.
Reference graph
Works this paper leans on
-
[1]
Semtech Acquires Wireless Long Range IP Provider Cycleo , journal =. 2012 , url =
work page 2012
-
[2]
A survey of LoRaWAN for IoT: From technology to application , author=. Sensors , volume=. 2018 , publisher=
work page 2018
-
[3]
LoRa scalability: A simulation model based on interference measurements , author=. Sensors , volume=. 2017 , publisher=
work page 2017
-
[4]
Experimental throughput models for LoRa networks with capture effect , author=. 2022 18th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob) , pages=. 2022 , organization=
work page 2022
-
[5]
Simulation of LoRa in NS-3: Improving LoRa Performance with CSMA , year=
To, Thanh-Hai and Duda, Andrzej , booktitle=. Simulation of LoRa in NS-3: Improving LoRa Performance with CSMA , year=
-
[6]
Comparison of LoRa Simulation Environments
Bouras, Christos and Gkamas, Apostolos and Katsampiris Salgado, Spyridon Aniceto and Kokkinos, Vasileios. Comparison of LoRa Simulation Environments. Advances on Broad-Band Wireless Computing, Communication and Applications. 2020
work page 2020
- [7]
-
[8]
Proceedings of the November 17-19, 1970, fall joint computer conference , pages=
The ALOHA system: Another alternative for computer communications , author=. Proceedings of the November 17-19, 1970, fall joint computer conference , pages=
work page 1970
-
[9]
Employing p-CSMA on a LoRa Network Simulator
Employing p-CSMA on a LoRa network simulator , author=. arXiv preprint arXiv:1805.12263 , year=
work page internal anchor Pith review Pith/arXiv arXiv
discussion (0)
Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.