Divako Divako
SolutionsUtilities & municipalities Housing & sub-metering Industry & buildings Streetlights & smart city Water networks & overflow Leak & anomaly detection Cost settlement & billing Allocation engine Invoicing & payments For property managers Billing & ERP exports Resident portal & apps Drive-By collection Topics
PlatformHardware Network Data Analyze Integrations Supported devices Security & data protection API & docs Platform status
Customers Resources About Log in Book a demo
Language
EN NO ET

Divako · LoRaWAN

How many devices fit one gateway cell?

Type in your fleet and read back the EU868 airtime it uses, whether every device stays inside the 1 % duty cycle, and what share of reports one coverage area can be expected to deliver. Everything runs in your browser; nothing is sent anywhere.

Book a demo How it is calculated

36s airtime one device may use per hour on the default EU868 sub-band (1 % duty cycle)
25× longer on air at SF12 than at SF7 for the same 20-byte message: 1 810 ms against 72 ms
e−2G the same-SF collision model behind every delivery figure on this page

Your fleet

Leave empty if everything sits within one gateway's reach. 30 km² is about 5 × 6 km.

What are the devices?
How sure do you need to be?

What one gateway cell delivers

About – of – devices get each report through; about – are lost to collisions. (–)

–Devices heard at least once an hour (hourly or faster reporting)
–One cell could carry up toDevices with this profile, at your target. The ceiling of a cell, not a count of your devices.
–Cells the traffic alone needsDevice count divided by what one cell carries. Gateways that hear the same devices share the same spectrum.

Assuming all devices are within one gateway's reach. Enter the area above if they are spread out.

Reports expected to arrive: –. Share of all scheduled uplinks received, same-SF collisions only.

Limiting factor:

1 % duty cycle:

SFDevicesAirtime per messageAirtime per device per hourLoad per channelDelivered
SF7
SF8
SF9
SF10
SF11
SF12

Estimate only. Random transmission timing, no retries, no downlinks, no external interference, no capture effect. Real networks differ; a pilot with RSSI and SNR readings replaces these presets. Counts frames received at the gateway radio; forwarding, backhaul and network-server losses are not included.

How it is calculated

Three formulas, all standard. The page applies them to your numbers; nothing is tuned to make Divako look good.

Assumptions

  • EU868, 125 kHz bandwidth, coding rate 4/5, 8-symbol preamble, CRC on, low-data-rate optimisation at SF11 and SF12.
  • 13 bytes of LoRaWAN framing on top of your application payload; no MAC commands piggy-backed.
  • Unconfirmed uplinks, spread randomly in time. No retries, no downlinks, no join traffic.
  • All devices share one gateway coverage area. Gateways that hear the same devices share the same spectrum.
  • Only same-SF collisions are counted. Different SFs are treated as fully separate, which is optimistic.
  • The 1 % duty cycle applies to the default sub-band shared by 868.1, 868.3 and 868.5 MHz: 36 seconds of airtime per hour per device.
  • Usable cell radius assumes an ordinary outdoor gateway with an omnidirectional antenna of a few dBi mounted about 15 m up, and devices allowed up to SF12. Open ground 3 km, town 1.5 km, basements 1 km, chambers under lids 0.7 km. A directional antenna, a taller mast or flat terrain reaches further; a pilot replaces these bands.

Airtime per message: Semtech LoRa modem formula from payload, SF, bandwidth and coding rate.

T = (8 + 4.25) × T_sym + N_payload × T_sym

Load per channel at one SF: devices × messages per hour × airtime ÷ (channels × 3600).

G = N × (60 / interval) × T ÷ (channels × 3600)

Delivered share at one SF: e^(−2 × load), the pure-ALOHA collision model.

P = e−2G

Airtime and ceilings for a 20-byte application payload
SFAirtimeMessages per device per hour at 1 %Messages per hour one 8-channel cell carries at 5 % load
SF772 ms50020 000
SF8134 ms26910 800
SF9247 ms1455 800
SF10453 ms793 200
SF11987 ms361 460
SF121 810 ms19795

What this page cannot tell you

Which SF each device actually lands at. That depends on where the gateway stands, what the meter sits under and how much margin the installer left. Run a pilot, read the SF distribution off the network server, then come back and type it into the custom mix.

Frequently asked

Why does adding a gateway not raise the numbers?

A second gateway that hears the same devices receives the same collisions. It adds coverage and reception diversity, not spectrum. Capacity grows when the second gateway serves devices the first one did not, which is what the 'separate coverage areas' figure counts.

What does 95 % report completeness mean in practice?

On average one scheduled uplink in twenty is lost to a same-SF collision. Devices that report hourly and keep a readings buffer recover most of those on the next uplink, which is why the 'heard at least once an hour' figure is higher.

Can I enter more than 51 bytes?

Not here. 51 bytes is the largest application payload SF12 allows in EU868. Devices at SF7 and SF8 can send up to 222 bytes and SF9 up to 115, but a calculator that let you mix those limits would silently break SF10 and above.

Do the presets come from real networks?

They are rounded shapes from municipal water-meter rollouts on Divako: a high mast over open ground pulls most devices to SF7 and SF8, a town centre spreads them out, and basements and chamber lids push a fifth of the fleet to SF11 and SF12. Your own distribution replaces them after a pilot.

Next step

Send us the device list. We sketch the gateways.

The calculator stops where coverage starts. With your addresses, meter positions and candidate masts we model link margin per device in the Divako network planner and return a placement with the SF mix it produces – in about 30 minutes.