LoRa Airtime, Duty Cycle & Battery Cost: Spreading Factor Planner

Compare SF7–SF12 airtime, bit rate, link gain, hourly duty budget and battery cost per message. Enter your regional limit and device currents; optionally estimate ALOHA overlap.

#airtime #ALOHA #battery life #duty cycle #LoRA #LoRaWAN #Meshtastic #spreading-factor

This LoRa airtime calculator helps engineers, students and radio enthusiasts compare spreading factor, message interval and battery demand before testing a design. It supports conventional SF7–SF12 packets for raw LoRa, LoRaWAN uplinks and custom mesh framing. The charts put LoRaWAN time on air beside nominal bit rate, illustrative link gain and battery cost, so the consequences of a slower radio setting are visible together.

Start with the packet interpretation. In raw mode, enter the entire byte count passed to the radio. The LoRaWAN option adds 13 bytes to the application data for a data frame without FOpts; custom mode lets you enter your own protocol overhead. Meshtastic users should include their actual mesh and encryption overhead rather than treating the text length as the radio payload. Then set bandwidth, coding-rate index, preamble, PHY header and payload CRC. Low data rate optimisation is selected automatically when symbol duration exceeds 16 ms.

The distinction between radio payload and application payload matters. With ten radio-payload bytes, 125 kHz bandwidth, coding rate 4/5, eight preamble symbols, explicit header and CRC, the calculated airtimes are 41.216 ms at SF7 and 991.232 ms at SF12. Ten application bytes in the modeled LoRaWAN frame instead become 23 radio bytes: approximately 61.7 ms and 1482.8 ms. The comparison keeps the same packet settings for every spreading factor.

For LoRa duty cycle planning, select a regional context, enter the limit that applies to your resource or sub-band, and enter the interval between transmission attempts. The default 1% is an example budget, not a regional rule selected by the tool. The timeline shows packet starts; the budget bar uses long-run average airtime. Whole packets per hour and a minimum mean interval help compare scenarios. Regional rules, dwell limits, channel plans, allowed payloads and operator policies must be checked separately against the rules in force.

Enter battery-side transmit and idle currents, usable capacity and a replacement price in your own currency. Extra charge per message can represent receive windows, sensing and wake-up activity. The results allocate idle consumption across messages and show a charge-limited lifetime. These estimates exclude automatic retries, relay traffic and battery self-discharge; use measured consumption and realistic derating before forecasting service life.

For spreading factor range and battery comparisons, receiver sensitivity is illustrative: the tool uses TTN values at 125 kHz and a noise-bandwidth correction. Relative distance assumes an unchanged link and your path-loss exponent; it does not predict kilometres of coverage. The optional ALOHA model estimates overlap among equal-packet, same-SF nodes on one channel. Capture, other interference and decoding failures require a fuller model or measurements. This is a planning tool, with sources reviewed on 27 October 2026.

How it is calculated

Airtime follows Semtech AN1200.13, LoRa Modem Designer’s Guide, Rev 1 (July 2013), section 4, with the explicit CRC flag shown in FAST-LoRa, equations (1)–(5), attached pages 4–5. The Semtech LoRa Calculator is a companion cross-check tool.

For bandwidth BB in hertz, Ts=2SF/BT_s=2^{SF}/B. Set DE=1DE=1 when Ts>16 msT_s>16\,\mathrm{ms}, otherwise zero (automatic in this planner; see Mobilefish tutorial 17, page 10). Programmed preamble npn_p contributes (np+4.25)Ts(n_p+4.25)T_s. With radio-payload length LL, implicit-header flag IHIH, CRC flag CC and coding-rate index CR=1…4CR=1\ldots4:

npay=8+max⁡[(CR+4)⌈8L−4SF+28+16C−20IH4(SF−2DE)⌉,0].n_{pay}=8+\max\left[(CR+4)\left\lceil\frac{8L-4SF+28+16C-20IH}{4(SF-2DE)}\right\rceil,0\right].

Total airtime is (np+4.25+npay)Ts(n_p+4.25+n_{pay})T_s. PHY header and CRC are handled here, so do not add them to the byte input.

Uncoded modulation rate is SF B/2SFSF\,B/2^{SF}. Multiplying by 4/(4+CR)4/(4+CR) gives a nominal coded information rate, before packet overhead and LDRO effects; it is not application throughput. The calculation sheet also divides entered data bits by packet airtime: radio-payload throughput (including protocol framing) in raw mode, application throughput in LoRaWAN/custom modes. The result text identifies which scope is active.

For entered duty fraction DD, the one-hour airtime budget is 3600D3600D seconds, whole packets per hour are ⌊3600D/Tair⌋\lfloor3600D/T_{air}\rfloor, and the minimum mean start interval is Tair/DT_{air}/D. The off-time equivalent is that interval minus airtime. These are budget identities, not a regulatory scheduler; average hourly use can differ from a particular window containing packet starts.

Battery-side charge is QTX=ITXTairQ_{TX}=I_{TX}T_{air} with explicit conversion to hours, and transmit energy is VQTXVQ_{TX} with charge converted to coulombs. Per-message charge adds the entered extra charge and idle current during the rest of the start-to-start interval. Usable capacity divided by mean current gives ideal life. Cost per attempted message is battery price times per-message charge divided by usable capacity. The cost chart uses 1000 messages for readable values.

Illustrative sensitivity starts from the TTN Spreading Factors values at 125 kHz. A 10log⁡10(B/125 kHz)10\log_{10}(B/125\,\mathrm{kHz}) correction assumes unchanged receiver noise figure and demodulation threshold (Semtech AN1200.13, section 2.2). Link gain relative to SF7 is converted to a distance ratio 10ΔS/(10n)10^{\Delta S/(10n)} using the log-distance relation in FAST-LoRa equation (7), attached page 5. This is a comparison model, not a radio specification.

The optional pure ALOHA overlap model is derived here: other-node Poisson arrival rate is (N−1)/Tmsg(N-1)/T_{msg} and the vulnerable interval is 2Tair2T_{air}. Therefore Poverlap=1−exp⁡[−2(N−1)Tair/Tmsg]P_{overlap}=1-\exp[-2(N-1)T_{air}/T_{msg}]. FAST-LoRa pages 5–6 motivate overlap modeling but include preamble tolerance and SIR/capture effects that this simplified estimate omits.

Assumptions

  • One transmission attempt per message; fixed packet settings, bandwidth and battery-side transmit current across the SF comparison. All charge and rated capacity refer to the same battery side and voltage. The 40 mA, 3.3 V, 2400 mAh and price defaults are illustrative scenarios, not component specifications or market prices.
  • LoRaWAN mode represents a nonempty uplink data frame with 13 protocol bytes: 1 MHDR + 7 minimum FHDR + 1 FPort + 4 MIC. It uses no FOpts, CR 4/5, explicit header, 8-symbol preamble and payload CRC. Use custom overhead for additional commands or mesh framing.
  • The 16 ms LDRO threshold is fixed by the stated model. Check the radio’s actual LDRO setting and supported bandwidths; do not compare a packet configured differently in firmware.
  • Battery extra charge is additional to the idle baseline and excludes the TX pulse already modeled. Add wake-up, receive, sensor and regulator effects using battery-side measurements. Cost is allocated per attempted message, including idle consumption at the requested interval; it is not cost per successfully delivered message.
  • TTN sensitivity values are typical educational values, not a guaranteed hardware curve. The BW correction assumes thermal-noise scaling; coding-rate effects, hardware offsets, temperature and implementation loss are not modeled. Relative distance assumes the same transmit power, antennas, propagation law and fade margin.
  • ALOHA uses equal packet airtimes, equal mean message intervals, independent Poisson starts, one frequency channel and one spreading factor. N includes the tagged node, so N=1 gives zero other-node overlap. All overlaps are treated as destructive; there is no capture or retransmission feedback.

Where it applies

Planning scope, sources reviewed 2026-10-27. Conventional LoRa SF7–SF12, coding-rate indices 1–4, 6–65535 programmed preamble symbols and up to 255 radio-payload bytes. Numeric bandwidth accepts 7.8–500 kHz for comparison; use a value actually supported by your hardware. SF5/SF6, FSK, LR-FHSS and device-specific packet variants are outside scope.

The selected region is context, not an automatic rule set. The entered duty percentage applies to one device sharing a single duty-budget resource, often a sub-band. The one-hour budget does not establish compliance. Check local rules, the standard in force and operator policy for the exact frequency, channel plan, allowed SF/BW, EIRP, dwell time, payload size, averaging period and any listen-before-talk or hopping requirements. A budget is still only a scenario when a region uses a different access rule. No legal limit or price is asserted by the defaults.

The hourly timeline starts a packet at time zero and samples at most 60 starts; tick widths are visual markers. The bar gives long-run mean use, including fractional messages per hour. Battery comparisons are blank where a packet exceeds the requested interval. A duty-budget warning does not automatically reduce your message rate or change the battery calculation.

Life is a constant-capacity, constant-current charge estimate, not a service-life guarantee. Battery pulse capability, voltage sag, cutoff, temperature, self-discharge, aging, joins, ACKs, retransmissions, relay traffic and other channel users need separate treatment. Short-packet ramp energy belongs in extra charge; ramp time is not added to on-air duration. Fixed-duty and Poisson collision views are separate idealisations. The ALOHA number is an overlap probability, not total packet-loss probability or a guarantee for Meshtastic or LoRaWAN.

Published checks distinguish 10 radio bytes (41 ms and 991 ms rounded in Mobilefish tutorial 17) from TTN’s current 10 application byte LoRaWAN example. No absolute range or installation design is provided.

References

  • Semtech, SX1272/3/6/7/8: LoRa Modem Designer’s Guide, AN1200.13, Rev 1, July 2013, sections 2 and 4. Open manufacturer document mirrored by Mouser: https://www.mouser.com/pdfdocs/semtech-lora-modem-design.pdf
  • Semtech, LoRa Calculator, accessed 2026-10-27: https://www.semtech.com/design-support/lora-calculator
  • The Things Network, Spreading Factors (data rate, sensitivity and battery-life discussion), accessed 2026-10-27: https://www.thethingsnetwork.org/docs/lorawan/spreading-factors/
  • The Things Network, Duty Cycle (resource/sub-band accounting and the distinction between regulatory and operator limits), accessed 2026-10-27: https://www.thethingsnetwork.org/docs/lorawan/duty-cycle/
  • The Things Network, LoRaWAN airtime calculator, 10-byte application-payload worked example, accessed 2026-10-27: https://www.thethingsnetwork.org/airtime-calculator
  • Acosta García et al., FAST-LoRa: An Efficient Simulation Framework for Evaluating LoRaWAN Networks and Transmission Parameter Strategies (2025), equations (1)–(12). arXiv:2507.23342, DOI: https://doi.org/10.48550/arXiv.2507.23342 ; open text: https://arxiv.org/abs/2507.23342
  • Mobilefish, LoRa/LoRaWAN Tutorial 17, v1.1.0, LoRa Packet Format, Time on Air and Adaptive Data Rate, pages 10–11 (LDRO and rounded 10-byte worked example): https://www.mobilefish.com/download/lora/lora_part17.pdf

Inputs

InputSymbolUnitDefault
Selected spreading factorSF9
Bandwidth
Use a bandwidth supported by your radio. The comparison holds bandwidth fixed.
BWkHz125
Payload interpretation
LoRaWAN uplink adds 13 bytes without FOpts. Raw LoRa uses the complete radio payload, including protocol headers. Custom/mesh adds your overhead below. PHY header and CRC are handled separately.
packet_modeLoRaWAN uplink
Data length (bytes)
Application bytes for LoRaWAN/custom; complete radio payload bytes for raw LoRa. Excludes the PHY header and PHY CRC.
L_app10
Protocol overhead (bytes)
Include all framing, mesh headers and encryption overhead inside the radio payload. PHY header and CRC are handled separately.
L_extra13
Coding-rate index (1 = 4/5, 4 = 4/8)CR1
Programmed preamble (symbols)
The formula adds the fixed 4.25-symbol tail.
N_pre8
PHY headerheader_modeExplicit header
PHY payload CRC enabledcrc_ontrue
Region / planning context
EU868: enter the applicable sub-band limit. US915, AU915 and AS923: verify country-specific channel, hopping and dwell rules. Region selection never sets or validates a legal limit; check current rules and operator policy.
regionEU868
Entered airtime limit (%)
1% is an illustrative input, not a claim about the selected region. This budget applies to one device and one shared duty-cycle resource/sub-band.
D_limit1
Interval between packet starts
One transmission attempt per message. Include retransmissions and relays separately; they are not added automatically.
T_msgs300
Path-loss exponent for relative range
Relative distance uses the TTN sensitivity difference and a log-distance model. Same power, antennas and fade margin; no absolute coverage prediction.
n_path3
Nominal battery-side voltageV_batV3.3
Battery-side current during transmit
Illustrative default, not a device specification. Enter measured battery-side current, including regulator loss and active electronics.
I_txmA40
Battery-side current between transmissions
Baseline outside TX; additional receive, sensor, wake-up and MCU charge goes below.
I_sleepmA0.01
Extra charge per message
Additional charge above the idle baseline for RX windows, wake-up, sensing and ramp time. Do not count the modeled transmit pulse again.
Q_extramA*h0.005
Rated battery capacityC_batmA*h2400
Usable capacity (%)
User allowance for cutoff, aging and conditions. All capacity and currents must refer to the same battery side.
U_bat80
Battery replacement price (your currency)
User-entered scenario price, as of your planning date; no market price or exchange rate is supplied.
price5
Evaluate ALOHA packet overlapaloha_onfalse
Nodes sharing this channel and SF (including yours)
Equal packet lengths and mean intervals; independent Poisson starts, one channel, no capture. This is an overlap estimate, not measured delivery reliability.
N_nodes100

Results

With the default inputs above, the calc gives:

ResultValue
Packet airtime205.824 ms
Whole packets/hour within entered airtime budget174
Requested airtime duty (%)0.0686
Minimum mean interval from entered budget20.582 s
Transmit energy per packet27.169 mJ
Total charge per message (TX + extra + idle)0.00812 mA·h
Battery cost per message (your currency)0.00002115
Ideal charge-limited battery life821 day
Illustrative receiver sensitivity-129 dBm
Illustrative distance multiplier vs SF71.58
Optional single-channel ALOHA overlapNot evaluated — enable ALOHA above
Throughput while transmittingApplication data: 388.7 bit/s

Checked against sources

Each case below was calculated by this calc and agrees with the value from its source (within the tolerance where one is shown).

Published 10-byte example: SF7 ≈ 41 ms

Source: Mobilefish LoRa/LoRaWAN Tutorial 17 v1.1.0, slide 11: 10 radio-payload bytes, BW 125 kHz, CR=1, preamble 8, explicit header and CRC enabled; rounded SF7 result 41 ms. This independently published example matches the ≈41 ms target in the brief; no LoRaWAN MAC overhead is added.

Inputs: Selected spreading factor = 7; Payload interpretation = Raw LoRa; the others as above.

ResultSourceThis calc
Packet airtime41 ± 0.5 ms41.216 ms

Published 10-byte example: SF12 ≈ 991 ms

Source: Mobilefish LoRa/LoRaWAN Tutorial 17 v1.1.0, slide 11, same 10-byte example, SF12 rounded airtime 991 ms. LDRO is enabled automatically because symbol time exceeds 16 ms (slide 10). The equation gives 991.232 ms; the tolerance covers publication rounding.

Inputs: Selected spreading factor = 12; Payload interpretation = Raw LoRa; the others as above.

ResultSourceThis calc
Packet airtime991 ms991.2 ms

TTN SF7 sensitivity and coded-rate example

Source: The Things Network, Spreading Factors, Receiver Sensitivity table (SF7: −123 dBm at 125 kHz), and Data rate table (SF7, CR index 1, 125 kHz: 5.5 kbit/s, rounded). https://www.thethingsnetwork.org/docs/lorawan/spreading-factors/ (accessed 2026-10-27).

Inputs: Selected spreading factor = 7; Payload interpretation = Raw LoRa; the others as above.

ResultSourceThis calc
Illustrative receiver sensitivity-123 dBm-123 dBm
Coded nominal information bit rate5,500 ± 50 bit/s5,469 bit/s

TTN SF12 sensitivity endpoint

Source: The Things Network, Spreading Factors, Receiver Sensitivity table: SF12, bandwidth 125 kHz, −137 dBm. https://www.thethingsnetwork.org/docs/lorawan/spreading-factors/ (accessed 2026-10-27).

Inputs: Selected spreading factor = 12; the others as above.

ResultSourceThis calc
Illustrative receiver sensitivity-137 dBm-137 dBm

TTN LoRaWAN 10 application bytes: SF7

Source: The Things Network LoRaWAN airtime calculator, current worked default: 10 application bytes become 23 radio-payload bytes; DR5 / SF7 / 125 kHz, 61.7 ms airtime and maximum 583 per hour under its entered 1% budget. https://www.thethingsnetwork.org/airtime-calculator (accessed 2026-10-27). Rounded published airtime is used, not a value generated by this tool.

Inputs: Selected spreading factor = 7; the others as above.

ResultSourceThis calc
Packet airtime61.7 ms61.696 ms
Whole packets/hour within entered airtime budget583583

TTN LoRaWAN 10 application bytes: SF12

Source: The Things Network LoRaWAN airtime calculator, All EU868 uplink data rates, 10-byte application payload: DR0 / SF12 / 125 kHz, 1.483 s airtime. Here that is 23 PHY payload bytes, with 13 bytes of MAC framing; this is a framing/airtime reference only, not a regional-approval test. https://www.thethingsnetwork.org/airtime-calculator (accessed 2026-10-27).

Inputs: Selected spreading factor = 12; the others as above.

ResultSourceThis calc
Packet airtime1,483 ms1,483 ms

Related Resources

Responses

Your email address will not be published. Required fields are marked *

L ading...