How Many Devices Can a LoRa Mesh Network Support? A Buyer’s Capacity Test

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

Procurement buyers often ask how many devices a LoRa mesh network can support. A supplier may answer with a registration limit, but that number does not prove that the same users can communicate at once, over the same route, with acceptable delay.

Capacity depends on the exact protocol, radio configuration, payload, acknowledgement rules, retry behavior, regional spectrum requirements, topology and user activity. A network that lists 100 identities may still fail a 20-person operational workflow if too many messages compete for airtime.

This guide turns a maximum-device claim into a repeatable acceptance test.

Short answer

There is no universal LoRa mesh device limit. Ask the manufacturer to separate registered users, paired phones, active terminals, simultaneous senders, recipients, participating intermediate nodes and service spares.

Then reproduce the busiest five minutes of the real operation. Capacity is acceptable only when required traffic arrives within the buyer's defined time and the network recovers from collisions, missed acknowledgements and node loss.

LoRa does not define the mesh limit

LoRa is a physical-layer modulation technology. It does not define ChatField's application groups, message queue, identity model, routing logic or supported number of participating terminals.

LoRaWAN is a separate protocol and network architecture. Its published capacity guidance can teach buyers that airtime, data rate, acknowledgements and device behavior matter, but it cannot prove the capacity of a different mesh implementation.

The ChatField technology overview should be used for the current product path, not replaced with a LoRaWAN diagram.

Define six different counts

First, count enrolled identities that can exist in the application. Second, count phones that can be paired. Third, count powered terminals present in the field. Fourth, count terminals expected to transmit during a busy interval. Fifth, count recipients for each group message. Sixth, count any supported intermediate terminals carrying other users' traffic.

Add service spares separately. A storage or enrollment maximum does not demonstrate operational capacity.

The existing question of how many people need equipment is different from how much simultaneous traffic the deployed system can handle.

Define the busiest operating minute

Ask supervisors to describe the most demanding realistic event: shift check-in, evacuation, route change, lost-worker alert, weather warning or multiple crews arriving at a checkpoint.

Write the exact sequence. For example, one supervisor sends a group instruction, twelve users acknowledge, three users report locations and two users use PTT within sixty seconds.

Do not test only one sender and one receiver if the purchase decision concerns a larger group.

Measure airtime, not only payload size

A radio packet occupies the channel for a period called time on air. Semtech's LoRa technical material explains that settings that increase link budget can also increase time on air. More time on air can reduce how much competing traffic fits into the same interval.

Protocol headers, addressing, acknowledgements, routing information and error protection add overhead beyond the user's visible words.

Record the configured message and observed transaction; do not estimate capacity from text-character count alone.

Separate PTT, text and location traffic

Different functions can produce different packet patterns and user expectations. A PTT exchange may be sensitive to setup and audio delay. A short text may tolerate more delay but require delivery acknowledgement. Location updates can become frequent background traffic.

The ChatField off-grid communication page identifies current buyer-facing functions without claiming that they all share one capacity value.

Test each function alone, then combine them in the expected priority order.

Test simultaneous senders

Start with one sender, then add users in controlled steps. Synchronize a test burst only when it represents a real event. Record successful delivery, duplicate delivery, delay, missing information and user-visible error.

Two radio transmissions can interfere even when both devices operate normally. LoRa settings, channels, received power and implementation behavior affect the result.

Do not describe a laboratory receiver capability as completed application delivery.

Count acknowledgement and retry traffic

Acknowledgements can improve certainty but also consume channel time. Retries can recover a missed message while adding more traffic during congestion.

Record the retry limit, backoff behavior, duplicate suppression and what the user sees. A network that retries indefinitely can appear reliable in a quiet test while becoming slow or unstable under load.

Define when the procedure switches to a shorter message, scheduled check-in or another channel.

Include participating intermediate paths

If a supported intermediate node forwards traffic, it may transmit information that originated elsewhere. That forwarding work belongs in the capacity test.

Build direct and representative supported relay paths. Place the nodes where the operation expects them, then repeat the busy-minute script. Turn one intermediate terminal off and record re-route or failure behavior.

The ChatField workflow page helps buyers draw sender, intermediate position and recipient without promising unlimited hops.

Test group and one-to-one delivery

A one-to-one message and a group message may use different addressing, acknowledgement and retry logic. Define how many recipients must receive the instruction and whether the sender can identify missing members.

Record the last recipient's delivery time, not only the first. A group result is incomplete when one critical role did not receive it.

Repeat after changing group membership and replacing a phone.

Account for regional radio rules

Destination markets can impose different frequency, power, channel-access, dwell-time or duty-cycle conditions. ETSI short-range-device standards discuss duty-cycle measurement, while U.S. operation follows the applicable FCC rules and equipment authorization.

Do not transfer a capacity test between US915 and EU868 configurations without reviewing the exact regional implementation. A higher message rate in one configuration is not permission to use it elsewhere.

The J25 specifications identify current model evidence; the buyer still needs destination-specific review.

Define acceptable delay and loss

Capacity is not a binary connected or disconnected state. Set a maximum delivery time and acceptable failure rate for each workflow. A routine status may tolerate delay that a stop-work instruction cannot.

Require timestamps from the sender and every relevant recipient. Note marginal results and repeated attempts.

Do not average away a severe worst-case delay at the most important checkpoint.

Test movement and topology change

Users move, vehicles turn, buildings block paths and participating devices lose power. Repeat the capacity script while representative users change positions.

Record whether the network discovers a supported path, how long that takes and which queued messages survive. A stationary table test is only a baseline.

Use the current J25 product page to keep the phone-paired terminal workflow visible during field testing.

Capacity test matrix

• One sender and one recipient baseline
• Expected normal number of active users
• Peak simultaneous sender count
• One-to-one and group messages
• PTT, text and location tested separately
• Mixed traffic in the defined priority order
• Acknowledgement and retry behavior
• Direct and supported intermediate paths
• Normal and worst representative route positions
• Phone replacement, restart and rejoin
• Regional hardware and radio configuration
• Pass, marginal and fail thresholds

Questions for a campaign or supplier

• What exactly does the published device count measure?
• How many users were actively transmitting in the test?
• Which message types and payloads were mixed?
• How were group recipients acknowledged?
• What retries and backoff occurred?
• Were intermediate nodes carrying forwarded traffic?
• Which regional configuration was tested?
• What were the worst delivery time and loss result?
• Can the buyer reproduce the script with production hardware?

Current ChatField boundary

ChatField does not publish a universal capacity number merely from the term LoRa mesh. Current J25 procurement should use the exact hardware, app, firmware, supported topology and target-region configuration.

Use the ChatField procurement page to define a representative group test. No capacity, group-size or simultaneous-user value is assigned here to an unconfirmed future crowdfunding model.

Sources reviewed

• Semtech AN1200.86: LoRa physical-layer and time-on-air factors
• Semtech LoRa Calculator: time-on-air and radio-design variables
• LoRa Alliance 2026 white paper: LoRaWAN capacity optimization
• ETSI EN 300 220-1: short-range-device duty-cycle and measurement context

Semtech, LoRa Alliance and ETSI do not endorse ChatField or its products. LoRaWAN capacity material is cited only for general airtime and network-behavior context and does not prove ChatField mesh capacity.