lora time on air calculator

LoRa Packet Airtime Calculator

Estimate packet transmission time using common Semtech LoRa PHY equations.

Auto enables DE when symbol duration is greater than 16 ms.

Why LoRa Time on Air Matters

In LoRa and LoRaWAN network design, time on air (ToA) is one of the most important practical metrics. It tells you how long a packet occupies the channel from preamble start to payload end. Longer airtime means more battery drain on end devices, lower network capacity, and increased risk of collisions.

If you are building smart metering, environmental sensing, asset tracking, or industrial telemetry, estimating airtime before deployment helps you avoid common scaling problems. This is especially important in unlicensed ISM bands where many devices share the same spectrum and regional duty-cycle regulations may apply.

LoRa Time on Air Formula (Used by This Calculator)

This calculator uses the standard LoRa packet duration equations:

Tsym = 2^SF / BW Tpreamble = (Npreamble + 4.25) * Tsym PayloadSymbNb = 8 + max( ceil( (8*PL - 4*SF + 28 + 16*CRC - 20*IH) / (4*(SF - 2*DE)) ) * (CR + 4), 0 ) Tpayload = PayloadSymbNb * Tsym ToA = Tpreamble + Tpayload

Where PL is payload length in bytes, IH is 0 for explicit header and 1 for implicit mode, CRC is 1 when enabled, and DE is low data rate optimization.

Parameter Guide

Spreading Factor (SF7 to SF12)

Higher SF increases sensitivity and range, but it dramatically increases airtime. A packet at SF12 can take many times longer than the same payload at SF7.

Bandwidth (BW)

Wider bandwidth reduces symbol duration and lowers airtime, but usually with reduced link budget. Narrow bandwidth improves sensitivity but increases packet duration.

Coding Rate (4/5 to 4/8)

Higher coding redundancy helps with robustness in noisy links, but adds overhead and increases ToA.

Preamble Length

The preamble allows receivers to detect and synchronize with incoming packets. Increasing preamble length may improve reliability in specific scenarios, but adds fixed airtime.

Header Mode and CRC

  • Explicit header carries payload metadata in the packet.
  • Implicit header assumes fixed packet settings known in advance.
  • CRC on improves integrity checking at the PHY level.

Design Tips for Lower Airtime

  • Use the lowest spreading factor that still gives reliable link performance.
  • Keep payloads compact (binary encoding, avoid verbose text formats).
  • Use larger packet intervals if near real-time delivery is not required.
  • Avoid unnecessary retries by improving link margin and gateway placement.
  • Review regional duty-cycle or dwell-time limits for your deployment area.

Practical Example

A 20-byte uplink at SF12, BW 125 kHz, CR 4/5, preamble 8, explicit header, and CRC enabled can take over one second of airtime. The same payload at SF7 may be only a few tens of milliseconds. That difference directly affects:

  • Battery life
  • Gateway channel occupancy
  • Total supported device count per gateway

Duty Cycle Planning

In many regions, a common planning reference is a 1% duty cycle per sub-band. That corresponds to 36 seconds of transmit time per hour. This calculator also gives a quick estimate of maximum packet count per hour and per day at 1% duty cycle.

Final Notes

This tool is intended for rapid engineering estimates and educational use. For production LoRaWAN systems, also consider MAC commands, confirmed uplinks, retransmissions, adaptive data rate behavior, join traffic, and regional PHY specifics.

🔗 Related Calculators