How Fast Is LoRa Mesh? A Field Latency Test from Button Press to Delivery

Prepared by the ChatField Editorial Team. Evidence reviewed August 18, 2026.

When a buyer asks how fast LoRa mesh communication is, a supplier may quote a radio data rate. That number is not the same as the time between pressing a control and another person receiving usable audio, text or location information.

The complete delay can include phone processing, Bluetooth, message preparation, channel access, radio airtime, routing, acknowledgements, retries and recipient display. Different functions can have different success criteria.

This guide defines a procurement latency test without inventing a J25 or future-product result.

Short answer

There is no universal LoRa mesh latency. Measure the exact user action to the exact recipient outcome with production-representative hardware, app, firmware, radio configuration, topology and traffic load.

Report median, worst observed delay, failure and retry behavior. A fast quiet-room test does not prove the busiest field workflow.

Data rate is not end-to-end delay

Radio data rate describes how information is transmitted over part of the path. It does not include every queue, conversion, protocol header, acknowledgement or user-interface step.

Semtech explains that LoRa settings trade link budget, data rate and time on air. A setting that improves sensitivity can increase the time a packet occupies the channel.

The ChatField technology page helps buyers identify the current radio stage without reducing the entire workflow to one physical-layer number.

Draw the complete clock

Start the clock at a defined user action: pressing PTT, tapping send or requesting a location update. Stop it at a defined recipient event: intelligible audio starts, complete text is readable, or a location with an acceptable timestamp appears.

For current J25, include the phone, application, Bluetooth Low Energy link, J25 terminal, local LoRa path, recipient terminal and recipient phone.

The ChatField how-it-works page shows these stages in order.

Define PTT delay

For PTT, separately measure button-to-ready indication, button-to-first intelligible audio and end-of-speech completion. Record clipped first words, gaps, distortion and failed call setup.

Use a fixed spoken phrase and independent timestamps or recording equipment. Do not let testers guess whether a delay felt short.

Repeat one-to-one and supported group workflows because floor control and recipient count can change behavior.

Define text-message delay

For text, record send action, sender status, recipient display and acknowledgement. Use a fixed short message before testing longer payloads.

Distinguish queued, transmitted, delivered and read if the interface exposes those states. A checkmark has value only when its meaning is documented.

Repeat with one recipient, a group and a representative intermediate path.

Define location age

A location can be delivered quickly but already be old. Record when the position was measured, when it was transmitted and when it appeared for the recipient.

Define the maximum acceptable location age for the workflow. A moving vehicle or worker may require a different threshold from a static checkpoint.

The ChatField off-grid communication page describes local location-sharing context without claiming real-time tracking at an undocumented interval.

Measure direct and intermediate paths

Begin with a direct path at close range. Then repeat at real checkpoints and with every supported participating intermediate position.

Each forwarding step can add processing, airtime, contention or retry behavior. Do not multiply a single-hop distance or delay into an assumed multi-hop result.

Record the actual path if the product exposes it; otherwise label the topology as configured, not proven.

Test quiet and busy conditions

A single message on an idle channel is the baseline. Add the expected background location updates, group check-ins and concurrent PTT or text traffic.

Reproduce the busiest realistic minute. Record queue growth, delayed delivery, duplicate messages and failure indicators.

Capacity and latency are connected, but they are not the same metric: a network may accept many devices while failing the buyer's maximum-delay requirement.

Count retries and acknowledgements

A first transmission may fail and a retry may succeed. The final message can look normal while arriving too late for the operation.

Record attempt count, acknowledgement time, backoff and user-visible state. Test what happens after the retry limit.

Do not hide retry delay inside an average.

Compare payloads fairly

A short status code, free-form text, location record and audio segment do not occupy the same amount of airtime or processing. Test each supported function with a representative payload.

Do not compare a tiny LoRa packet with a cellular broadband transfer and conclude that the architectures have identical purposes. LoRa is designed for low-throughput, high-link-budget communication, not general broadband replacement.

Remove any payload not documented for the exact model.

Control phone and Bluetooth variables

Use the same approved phone models, operating-system versions, app build, permissions and background settings planned for deployment. Record whether the screen is locked and whether battery-saving rules are active.

Test Bluetooth disconnect and reconnection separately. A delayed phone-to-terminal handoff should not be mislabeled as radio latency.

The current J25 product page identifies Bluetooth Low Energy as part of the phone-paired architecture.

Control regional radio configuration

Frequency plan, bandwidth, spreading factor, coding, output, channel access and regulatory constraints can affect airtime and observed delay. Use the exact destination-market hardware and approved configuration.

ETSI short-range-device standards discuss duty cycle and channel occupation. U.S. operation follows applicable FCC rules and the model's equipment authorization.

Do not transfer a US915 latency result to EU868 without testing and compliance review.

Measure recovery, not only steady state

Restart a phone, terminal and supported intermediate device one at a time. Record time to pairing, group availability and first successful communication.

Move through a blocked route and record failure and recovery. Determine whether a queued message arrives, expires or duplicates after the path returns.

A responsive system in steady state may still have an unacceptable recovery delay.

Use percentiles and worst cases

Ten or twenty repetitions at each important checkpoint provide more information than one demonstration. Report each result, then calculate median and an appropriate high percentile only when the sample supports it.

Keep the worst result visible. Procurement teams should understand rare but operationally important delays.

Do not call a failed message infinite latency and then remove it from the dataset; report failure separately.

Define different pass limits by task

A stop-work instruction, PTT coordination, routine text check-in and periodic location update may need different limits. Set those thresholds before testing.

Include the action after a missed threshold: repeat, switch mode, move to a checkpoint, use another device or escalate through a separate channel.

Technology without a fallback procedure does not create reliable communication.

Latency test worksheet

• Exact phone, app, terminal and firmware
• Regional radio configuration and accessory
• User action that starts the clock
• Recipient event that stops the clock
• Direct and supported intermediate topology
• PTT first-audio and completion delay
• Text delivery and acknowledgement delay
• Location measurement age and display time
• Quiet baseline and busiest-minute traffic
• Retries, duplicates, failures and recovery
• Median, high percentile and worst result
• Task-specific pass and fallback threshold

Current J25 boundary

Current J25 specifications describe product features and radio evidence, but this article does not publish an undocumented universal PTT, text or location latency.

Use the ChatField procurement page to define a representative latency pilot. No timing result is assigned to an unconfirmed future crowdfunding product.

Sources reviewed

• Semtech AN1200.86: LoRa modulation, data rate and time-on-air tradeoffs
• Semtech LoRa Calculator: time-on-air variables
• LoRa Alliance: regional parameters, data rate and network efficiency context
• ETSI EN 300 220-1: short-range-device duty-cycle measurement context

Semtech, LoRa Alliance and ETSI do not endorse ChatField or its products. LoRaWAN publications are used only to explain general data-rate and airtime considerations, not as ChatField mesh performance evidence.