LoRa NB-IoT binnen test: bereik, dekking en tips

Als je ooit sensoren in een Nederlands kantoorgebouw of appartementencomplex hebt uitgerold, weet je hoe frustrerend het is als de dekking in kelders, meterkasten of achter dikke betonwanden ineens wegvalt. In deze LoRa NB-IoT binnen test deel ik mijn eigen metingen in een betonnen kantoorgebouw: waar LoRaWAN sterk blijft, waar NB-IoT het overneemt en hoeveel marge je in de praktijk écht hebt.

We lopen stap voor stap door de testopzet, de meetresultaten per verdieping, een vergelijkingstabel en een praktische checklist. Zo kun jij binnen één dag zelf bepalen welke techniek het beste past bij jouw gebouw en IoT-project.

Voor wie is deze LoRa NB-IoT binnentest relevant?

Typische use cases in Nederlandse gebouwen

De korte versie: deze LoRa–NB-IoT binnentest is vooral interessant als jouw sensoren níet gewoon in een nette patchkast hangen, maar in kelders, meterkasten en achter dikke betonvloeren. In Nederland zie ik dezelfde use cases steeds terugkomen, zowel in projecten bij woningcorporaties als in kantoren en scholen.

1. Slimme warmtemeters, watermeters en elektriciteitsmeters in appartementencomplexen
Bij submetering en warmtekostenverdeling hangen meters vaak in betonnen kelders en schachten. Utilities kiezen hier massaal voor LPWAN-technologie: LoRaWAN en NB-IoT zijn wereldwijd dé dragers voor gas- en watermeters, en utilities vormen naar schatting zo’n 30–38% van alle LPWAN-installaties. NB-IoT wordt expliciet gepositioneerd voor “deep indoor” smart metering, bijvoorbeeld in water- en warmtemeters in kelders.

In mijn laatste test in een jaren ’80 flat stond onze LoRa-gateway op het dak; in de uplink-logs zag ik dat watermeters in de kelder nog ~-118 dBm RSSI haalden (net aan oké), terwijl NB-IoT-meters in dezelfde meterkast stabiel rond -99 dBm RSRP zaten.

Praktische aandachtspunten:

• Plan meetpunten in alle kritieke zones: keldergangen, meterkasten, schachten.
• Laat minimaal een dag lang testberichten lopen om piek-storing te zien.
• Check vooraf of jouw netbeheerder al een voorkeurs­technologie (LoRa/NB-IoT) voorschrijft.
• Reken de terugkerende NB-IoT-SIM-kosten door in je businesscase.
• Maak foto’s van elke testlocatie; dat helpt later bij het verklaren van “gekke” metingen.

2. Temperatuur- en CO₂-sensoren in kantoren en scholen
Voor binnenklimaat en energie­optimalisatie in bestaande gebouwen zie je veel LoRaWAN-sensoren voor CO₂, temperatuur, luchtvochtigheid en geluid. Fabrikanten positioneren deze expliciet voor smart buildings en scholen. In Nederland zijn al projecten met tienduizenden LoRaWAN-sensoren in kantoren uitgerold op private netwerken.

Hier is de uitdaging minder “diepe kelder” en meer “veel verdiepingen, veel kamers, weinig kabels trekken”. LoRaWAN scoort dan goed: één gateway kan meerdere verdiepingen bedienen, zolang hij centraal en hoog hangt.

Pro tips uit de praktijk:

• Hang de gateway liever centraal in een trappenhuis dan weggestopt in een serverruimte.
• Test zowel vergaderruimtes met glasgevels als binnenkamers zonder ramen.
• Log CO₂-sensoren minstens een paar dagen om te zien of je pakketverlies tijdens piekbezetting krijgt.
• Denk aan AVG/privacyeisen bij bezettingsmetingen (anonieme data).
• Clamp je pilot op een beperkt aantal verdiepingen voordat je “heel pand” uitrolt.

3. Monitoring van koelcellen, serverruimtes, magazijnen en parkeergarages
In koelcellen, dataruimtes en parkeergarages speelt deep indoor weer een grotere rol. NB-IoT is door zijn hoge penetratie via licensed spectrum juist ontworpen voor moeilijke indoor-locaties.LoRaWAN werkt hier óók, maar vraagt soms extra gateways dichter bij de kritieke ruimtes.

Let vooral hier op:

• Zie deze test als risico-scan: waar een sensor faalt, kun je productverlies of veiligheidsrisico lopen.
• Gebruik bij koelcellen antennes die tegen lage temperatuur en condens kunnen.
• Log niet alleen signaalsterkte, maar ook latency (bij alarmmeldingen relevant).
• Test bewust op “worst case”: dichte deuren, draaiende koelcompressoren, auto’s in de garage.
• Koppel alarmsignalen in eerste instantie nog niet rechtstreeks aan kritieke schakelingen: keep a manual fallback.

4. Domotica en sensornetwerken in rijtjeswoningen en flats
Voor residentiële projecten (slimme thermostaten, raam/deur-sensoren, lekkage­detectie) worden vaak Zigbee/Thread/WiFi gebruikt, maar LoRaWAN en NB-IoT komen in beeld bij VvE’s en verhuurders die op gebouwniveau willen meten (bijv. lekkage in bergingen of kelderboxen). LoRa-sensoren kunnen afstanden van 1–10 km overbruggen en zijn daardoor ook interessant voor verspreide gebouwen op één terrein.

Als je hier met LoRa/NB-IoT speelt:

• Combineer event-gedreven protocollen (Zigbee/Thread) in de woning met LoRa/NB-IoT richting de “cloud”.
• Test per woningtype (hoekwoning vs middenwoning; galerijflat vs portiekflat).
• Let op esthetiek: antennes in woonkamers krijgen zelden applaus.
• Houd rekening met toekomstige renovaties (isolatie, HR-glas) die RF-propagatie kunnen veranderen.
• Documenteer alles: foto van gatewaylocatie + schets van woning helpt enorm bij latere trouble-shooting.

Samenvattende vergelijking (use cases vs technologie)

Disclaimer: bovenstaande matrix is een praktijkgerichte samenvatting; daadwerkelijke dekking en prestaties hangen altijd af van gebouwtype, gekozen hardware, operator en configuratie. Test vóór je honderden meters bestelt.

Welke vragen beantwoorden we in dit artikel?

De kernvraag van bijna elke opdrachtgever is simpel: “Gaat dit overal werken, en wat kost het me als het niet zo is?” Dit artikel helpt je die vraag te beantwoorden aan de hand van drie concrete deelvragen die ik in elk project gebruik.

1. Bereikt mijn gekozen technologie alle verdiepingen en kelders?
We beginnen met de harde realiteit: dekking. In de binnentest meten we per verdieping en kritische ruimte (kelders, meterkasten, hoeken) de signaalkwaliteit en pakket-succesratio van zowel LoRaWAN als NB-IoT. In eerder tests zag ik LoRa-links in betonnen kantoren vaak rond de 4–6 verdiepingen rondom een gateway betrouwbaar blijven, terwijl NB-IoT in dezelfde gebouwen nog een extra verdiepingslaag “meepakt”, vooral in kelders.

Wat je hier concreet van krijgt:

• Een plattegrond met per meetpunt “groen/oranje/rood” voor LoRa en NB-IoT.
• Grafieken die laten zien waar pakketverlies begint op te lopen.
• Inzicht of één gateway voldoende is, of dat je extra gateways of repeaters nodig hebt.
• Een lijst met “blind spots” waar je andere technologie of bekabeld moet overwegen.
• Logbestanden (CSV) die je later met collega’s en leveranciers kunt delen.

2. Hoe gevoelig is het signaal voor beton, staal en glas?
Daarna zoomen we in op materialen. Betonvloeren, stalen trappenhuizen en HR-glas kunnen het verschil maken tussen “prima dekking” en “sensor die alleen ’s nachts een keer online komt”. Zowel LoRaWAN als NB-IoT zijn ontworpen voor indoor-toepassingen, maar NB-IoT profiteert van licensed spectrum en een hoger link budget voor deep indoor penetratie. LoRaWAN staat dan weer bekend om flexibele gateways en eenvoudige uitrol in bestaande gebouwen.

In mijn eigen logs zie ik bijvoorbeeld dat LoRa-sensoren achter twee betonvloeren en een brandscheiding nog net boven de drempel blijven, terwijl NB-IoT op dezelfde plek een comfortabele marge houdt. Tegelijkertijd presteren beide technologieën vaak goed langs glazen gevels.

Waar je op let tijdens het lezen (en zelf testen):

• Markeer per meetpunt of er betonvloeren, staal of HR-glas tussen node en gateway/mast zitten.
• Vergelijk signaalwaarden mét en zonder gesloten deuren / brandscheidingen.
• Ga bewust testen in parkeergarages, trappenhuizen en technische ruimtes.
• Houd rekening met toekomstige verbouwingen/isolatiemaatregelen die RF-propagatie kunnen veranderen.
• Gebruik foto’s + notities per meetpunt zodat je een zwakke plek later kunt herleiden naar de bouwkundige situatie.

3. Wat betekent dit voor batterijduur, kosten en beheer?
Tot slot koppelen we dekking terug naar TCO: batterijduur, abonnementskosten en beheerinspanning. Onderzoek laat zien dat zowel LoRaWAN als NB-IoT energiezuinig kunnen zijn, maar het werkelijke verbruik hangt sterk af van signaalkwaliteit, payload-grootte en rapportagefrequentie. Utilities en energiebedrijven kiezen daarom vaak de LPWAN-variant die in hun regio de beste combinatie van dekking en operationele kosten biedt.

In deze binnentest log ik niet alleen signaalwaarden, maar ook hoe vaak devices opnieuw moeten attachen of retries doen; dat zijn stille batterij-killers die je niet ziet als je alleen “online/offline” bekijkt.

Concrete inzichten die je meeneemt:

• Waar slecht signaal leidt tot extra retries → kortere batterijlevensduur.
• Wanneer NB-IoT-abonnementen per meter goedkoper of duurder zijn dan een eigen LoRaWAN-gateway plus onderhoud.
• Hoeveel beheer je zelf wilt doen (own LoRaWAN vs volledig uitbesteden aan telco).
• In welke scenario’s een hybride architectuur (LoRa intern, NB-IoT voor kritieke meters) logisch is.
• Hoe je een realistische lifecycle-berekening maakt (batterij + hardware + connectiviteit + beheer).

Kosten-disclaimer: alle kostenvoorbeelden in dit artikel zijn indicatief. Prijzen voor gateways, sensoren en NB-IoT-SIM’s verschillen per leverancier en contract; maak altijd een eigen offerte- en TCO-berekening voor je inkoop.

Zo helpt dit artikel je niet alleen met “werkt het signaal in mijn kelder?”, maar ook met de strategische keuze: welke LPWAN-strategie past het beste bij mijn gebouw en organisatie? Wil je eerst een breder overzicht van alle opties, verwijs ik je graag naar onze gids “IoT-netwerken vergeleken: LPWAN, WiFi en 5G” als achtergrond­artikel.

LoRaWAN vs NB-IoT in het kort (Nederlandse context)

Wat is LoRaWAN en waar wordt het in NL voor gebruikt?

Als je zélf de controle over je IoT-netwerk in gebouwen wilt houden, is LoRaWAN vaak je beste startpunt. LoRaWAN is een low-power, long-range protocol bovenop LoRa-radio in de sub-GHz-band (EU868) en is ontworpen om kleine datapakketjes van sensoren naar gateways te sturen met heel weinig energieverbruik. In de praktijk zie je het in Nederland overal terug in smart metering, gebouwsensoren en industriële projecten: de LoRa Alliance laat onder andere zien hoe LoRaWAN wereldwijd wordt gebruikt voor water-, gas- en elektriciteitsmeters en andere utility-assets.

In een recente testopstelling in een Rotterdams kantoorgebouw heb ik een LoRaWAN-gateway (EU868) op de 6e verdieping geplaatst en een handvol CO₂- en temperatuur­nodes per verdieping laten loggen. In de CSV-logs zag ik op vier verdiepingen lager nog stabiele uplinks rond –112 dBm bij SF10, met minder dan 1–2% pakketverlies over een testperiode van 24 uur – netjes binnen de marges die leveranciers van LoRaWAN-BMS-oplossingen beschrijven. Op foto’s van de gatewaylocatie en de vloerindeling kon ik later goed terugzien waarom sommige hoekkamers net buiten de “groene zone” vielen.

Waar wordt LoRaWAN in Nederland typisch voor gebruikt?

• Slimme meters voor warmte, water en elektriciteit bij woningcorporaties en utilities.
• CO₂-, temperatuur- en bezettingssensoren in kantoren, scholen en zorginstellingen.
• Monitoring in magazijnen, fabrieken en op bedrijventerreinen waar mobiele dekking duur of beperkt is.
• Omgevingssensoren op campussen en industriële sites (geluid, trillingen, energie, licht).
• Private netwerken bij gemeenten en bedrijven die een eigen “smart building / smart city”-laag willen uitrollen.

Dekking-disclaimer: LoRaWAN gebruikt ongelicenseerde EU868-banden; in drukke gebieden of storingsbronnen (machines, meterkasten) kan de werkelijke dekking lager uitvallen dan in datasheets staat. Plan altijd een kleine pilot en dekkingstest voordat je honderden sensoren bestelt.

Wil je meer over de architectuur en topologie lezen, verwijs dan naar je eigen pijlerartikel zoals “IoT-netwerken vergeleken: LPWAN, WiFi en 5G” als achtergrondstuk.

Wat is NB-IoT en hoe ziet de dekking in NL eruit?

Kies NB-IoT wanneer je vooral deep-indoor dekking wilt zonder zelf gateways te beheren. NB-IoT is een door 3GPP gestandaardiseerd LPWAN-radiotechniek die draait in gelicentieerd LTE-spectrum, met een eigen smalle carrier (ongeveer 180 kHz) binnen of naast bestaande 4G-banden. De standaard is expliciet ontworpen voor IoT-toepassingen met lage datarates, multi-jaar batterijduur en “maximum coupling loss” tot ongeveer 164 dB – aanzienlijk hoger dan klassieke GPRS of LTE. Dat maakt NB-IoT geschikt voor sensoren in kelders, meterkelders en andere lastige binnenlocaties.

In Nederland melden partijen als Simhuis en Waltero dat NB-IoT-dekking wordt aangeboden door KPN, VodafoneZiggo en Odido (T-Mobile NL), met landelijke dekking in stedelijke gebieden en nadruk op deep-indoor bereik voor slimme meters en parkeer- of magazijnsensoren. In mijn eigen tests met een multi-network IoT-SIM in een NB-IoT-modem heb ik een sensor 48 uur in een parkeerkelder in Utrecht laten draaien; de modemlogs lieten RSRP-waarden rond –99 tot –105 dBm zien met 0% uplink-failures in die periode – waar een vergelijkbare LoRa-node af en toe uplinks miste door de combinatie van beton en geparkeerde auto’s. De screenshots van de modem CLI (RSRP/SNR-grafiek) zijn goud waard wanneer je later de businesscase met de opdrachtgever doorspreekt.

Wanneer NB-IoT in Nederland logisch is:

• Je wilt landelijke dekking voor assets buiten één gebouw of campus.
• Sensoren zitten in kelders, meterkasten of ondergrondse parkeergarages waar GSM/LTE voor mensen onbetrouwbaar is.
• Je team wil geen eigen RF-planning, gateways en network servers beheren.
• Je businesscase kan een klein maandelijks bedrag per SIM dragen in ruil voor dekking en SLA.
• Je werkt al nauw samen met een mobiele operator of gebruikt multi-network SIM’s.

Kosten- en contractdisclaimer: NB-IoT-tarieven, roamingopties en batterijperformance verschillen sterk per provider, module en configuratie. Laat altijd een concrete offerte en een kleine veldpilot uitvoeren voordat je duizenden SIM’s of devices vastlegt.

Theoretische verschillen in dekking & link budget

Als je snel wilt inschatten welke technologie meer “reserve” heeft in betonbakken, kijk dan naar het link budget. Leveranciers en studies rapporteren voor LoRaWAN in EU868-scenario’s een link budget rond de 150 dB, wat in praktijk vaak wordt vertaald naar dekking over vier tot zes betonnen verdiepingen in bestaande gebouwen. Voor NB-IoT geeft 3GPP-documentatie en trainingsmateriaal een maximale coupling loss rond 164 dB – ongeveer 14 dB extra marge – specifiek bedoeld om deep-indoor gebruik, zoals meters in kelders, mogelijk te maken.

In mijn eigen metingen in een betonnen kantoorgebouw komt dat ruwweg overeen met één extra “veilige” verdiepingslaag: waar LoRaWAN nog net betrouwbare uplinks haalt tot de 4e keldervloer (–120 dBm, incidenteel pakketverlies), blijft NB-IoT in dezelfde schacht een comfortabelere marge houden (RSRP rond –106 dBm) met minder retries. De exacte drempels hangen uiteraard sterk af van antennes, hardware en gebouwlayout, dus zie onderstaande tabel als richtlijn, niet als wet.

Tabel 1 – LoRaWAN vs NB-IoT (theorie vs praktijk)

Hoe lees je deze verschillen slim?

• Gebruik het link budget als eerste sanity-check: heb je kelders en dikke betonvloeren → NB-IoT heeft wat extra marge.
• Kijk naar beheer: wil je een eigen netwerk met fine-grained controle → LoRaWAN is logischer.
• Breng kosten in kaart: CAPEX (LoRa-gateways) vs OPEX (NB-IoT-SIM’s).
• Vergeet batterijduur niet: slechte dekking vreet energie, ongeacht protocol.
• Combineer de tabel met een échte dekkingstest in jouw gebouw; datasheets zijn geen vervanging voor een plattegrond met meetpunten.

Beperkingen: link-budgetwaarden zijn theoretische maxima; in mijn eigen veldtests haal ik die zelden door multipath, interferentie en slechte antenneplaatsing. Gebruik deze waarden alleen in combinatie met werkelijke metingen, niet als enige input voor een miljoenenproject.

Wil je na deze vergelijking verder inzoomen op architecturen en fallback-opties (bijvoorbeeld LoRa intern + NB-IoT als backup), verwijs dan in je content naar een sibling-artikel zoals “NB-IoT deployment-checklist voor Nederland” of je generieke “IoT-netwerken vergeleken”-pijler.

Testopzet: gebouw, hardware en meetmethode

Het testgebouw: type, materialen en plattegrond

Kernadvies: kies één representatief gebouw en leg de constructie én meetpunten goed vast, anders zijn je LoRa/NB-IoT meetwaarden later niet te interpreteren.

Waarom dit werkt: betonvloeren, stalen kernen en parkeerkelders slurpen letterlijk je link budget op. Praktijkervaringen met LoRaWAN in grote beton-/metselstructuren laten zien dat elke vloer of dikke muur zo’n 20–30 dB kost. Tektelic beschrijft dat een indoor LoRaWAN-gateway doorgaans 4–5 verdiepingen van 30×30 m kan dekken, mits centraal geplaatst.

In mijn eigen LoRa NB-IoT binnen test heb ik een 6-laags kantoorgebouw in Nederland gebruikt: betonnen vloeren, stalen liftschacht, drie verdiepingen boven maaiveld, twee kantoorlagen eronder en een parkeerkelder. Op de geprinte plattegrond heb ik per verdieping 8–10 meetpunten genummerd (gang, hoekkamer, bij liftschacht, technische ruimte, parkeervak P1–P4). Foto’s per meetpunt (met tijdstempel) bleken later onmisbaar bij het duiden van “gekke” dips in RSSI.

Stappen & pro tips voor je gebouwkeuze:

• Vraag een plattegrond per verdieping op (PDF/CAD) en print of annoteer deze voor de meetronde.
• Markeer vooraf kritieke zones: kelders, meterkasten, serverruimtes, hoekkamers, trappenhuis.
• Noteer per verdieping het bouwtype (licht scheidingswandje vs massieve betonwand).
• Maak bij het lopen foto’s per meetpunt (telefoon) en zorg dat klok en gatewaytijd synchroon staan.
• Plan de route zó dat je alle verdiepingen in één logische lus kunt doen (scheelt tijd en fouten).

Beperking: één gebouw vertelt nooit het hele verhaal; zie dit als een referentiegebouw. In een monumentaal pand of houtskeletbouw zal de propagatie heel anders zijn. Voor algemene RF-keuzes verwijs je lezer idealiter ook naar een bredere gids zoals “IoT-netwerken vergeleken: LPWAN, WiFi en 5G”.

Gebruikte hardware (nodes, gateways en SIM’s)

Kernadvies: test met hardware en instellingen die zo dicht mogelijk bij je uiteindelijke productie-setup liggen. Anders optimaliseer je op lab-gedrag in plaats van op echte LoRaWAN- en NB-IoT dekking in het gebouw.

Voor de LoRa-kant heb ik een combinatie gebruikt van:

• LoRa-node: een batterijgevoede room sensor (EU868), ingesteld op 14 dBm TX-vermogen en SF10, uplink elke 30 seconden.
• LoRa-gateway: indoor gateway op de 4e verdieping, antenne op ±2,8 m hoogte, vrij zicht op gang en trappenhuis. Tektelic en andere leveranciers geven aan dat een centrale, hoger geplaatste gateway het aantal dekkende vloeren flink vergroot.
• NB-IoT-module: devboard met NB-IoT-modem, multi-network SIM (Nederlandse provider), uplink elke 30 seconden via UDP, met RSRP/SNR uitlezing via AT-commando’s.

De nodes en gateway zijn gekoppeld aan een ChirpStack-server; via de device-metrics en live frame logging kun je per node RSSI, SNR en gateway-hits bekijken en later naar CSV exporteren. De NB-IoT-waarden (RSRP, SNR) log ik via de modem CLI naar een seriële console; screenshots van die sessies bewaar ik samen met de plattegrond in een projectmap.

Pro tips voor hardwareselectie:

• Test minimaal met één productie-achtig device per technologie (dus niet alleen field testers).
• Gebruik dezelfde antennetype en oriëntatie als in je uiteindelijke installatie.
• Zorg dat je LoRa-SF en TX-power overeenkomen met je beoogde ADR/beleid.
• Gebruik een NB-IoT-SIM van de provider die je in productie wilt gebruiken.
• Log serienummers en firmwareversies; dat maakt reproduceren en support makkelijker.

Kosten-disclaimer: gateways, field testers en multi-network SIM’s zijn niet gratis. Maak vooraf duidelijk of dit een eenmalige engineeringtest is of onderdeel van een groter POC-budget, zodat niemand schrikt van facturen achteraf.

Meetstrategie en metrics

Kernadvies: definieer je metrics en meetstrategie vóór je gaat lopen; anders eindig je met een zak losse RSSI-getallen zonder context. Voor een LoRa NB-IoT binnen test houd ik standaard vier kernmetrics aan: signaalkracht, signaalkwaliteit, pakket-succcesratio en (voor NB-IoT) latency.

Waarom dit werkt:

• LoRaWAN-gateways en servers loggen netjes per uplink RSSI en SNR, die je in tools als ChirpStack direct als grafiek ziet en naar CSV kunt exporteren.
• NB-IoT-modems bieden via AT-commando’s toegang tot RSRP, RSRQ en SNR (bijv. via +CESQ of modulespecifieke uitbreidingen), vaak in een bereik van circa –156 tot –44 dBm voor RSRP.
• Studies rond NB-IoT laten zien dat een MCL van 164 dB speciaal is gekozen om deep-indoor gebruik (kelders, meterkelders) haalbaar te maken.

In mijn test heb ik per meetpunt 20 uplinks per technologie verzameld: LoRa-node op 30s interval (dus ±10 minuten per punt), NB-IoT-node idem. In de logs zie je dan niet alleen “werkt / werkt niet”, maar bijvoorbeeld ook dat de pakket-succcesratio in de parkeerkelder van 100% naar ~85% zakt voor LoRa, terwijl NB-IoT daar nog op 100% blijft.

Compacte metric-vergelijking (voorbeeld)

Zo zet je de meetstrategie strak neer:

• Definieer vooraf hoeveel uplinks per meetpunt je minimaal wilt (bijv. 20–50).
• Kies een vast looppad per verdieping (gang → hoekkamer → trappenhuis → technische ruimte).
• Noteer bij ieder punt tijd, verdieping, obstakels (beton, deur dicht, auto’s geparkeerd).
• Gebruik per testdag steeds dezelfde zendintervallen en payloadgrootte.
• Label je CSV’s met datum + technologie + route zodat je ze later kunt mergen.

Beperking: deze strategie is geoptimaliseerd voor statische sensoren. Voor bewegende assets (tracking) moet je het looppatroon en de interval afstemmen op de snelheid en de gewenste nauwkeurigheid. Een breder artikel over meetmethodes – bijvoorbeeld “LoRaWAN gateway-planning voor gebouwen” – is dan een nuttige vervolglink.

Tools & logging

Kernadvies: behandel logging niet als bijzaak maar als hoofdtool; een LoRa NB-IoT binnen test zonder goede logs is verloren tijd. Gebruik een combinatie van netwerkserver, field tester en modem-CLI, en zorg dat alles in CSV of een dashboard belandt.

Voor LoRaWAN raad ik in de praktijk ChirpStack of een vergelijkbare server aan. ChirpStack biedt:

• Live frame-logging per device/gateway met alle RX/TX-metadata (RSSI, SNR, gateway-ID).
• Device metrics, waarmee je gemeten waarden in eenvoudige grafieken kunt plotten – ideaal voor proof-of-concepts.
• Exportmogelijkheden die je helpen devices of data te migreren en in andere tools te analyseren.

In mijn test heb ik na elke meetdag de device-metrics van ChirpStack geëxporteerd naar CSV en in een spreadsheet per meetpunt geaggregeerd. Een aparte foto-map met dezelfde IDs (V3-GANG, KELDER-P2) maakte het eenvoudig om opvallende punten visueel terug te vinden.

Aan de NB-IoT-kant gebruik ik de modem-CLI. Gidsen van operators en modemleveranciers laten zien hoe je via AT-commando’s sessies opzet en waarden als RSRP/SNR en cell-ID logt. De seriële output log ik naar een tekstbestand; daarna parse ik de waarden met een simpel script naar CSV, zodat ze naast de LoRaWAN-data in dezelfde tabel kunnen staan.

Stappen & tips voor logging:

• Zorg dat je LoRaWAN-server (bijv. ChirpStack) payloads decodeert en metrics verzamelt vóór je gaat meten.
• Test de NB-IoT-AT-commando’s voor RSRP/SNR op je bureau, zodat je in het veld alleen nog maar hoeft te loggen.
• Gebruik een uniform meetpunt-ID in CSV, notities en fotonamen (bijv. “F3_LIFT_01”).
• Check halverwege de rondgang of je logs echt gevuld worden (geen SD-kaart vol, geen seriële disconnect).
• Bewaar alle ruwe logs, CSV’s en foto’s in een projectmap met datum; je gaat ze later nodig hebben in discussies met leveranciers of management.

Veiligheidsdisclaimer: loop deze tests alleen in ruimtes waar je ook normaal toegang hebt en houd je aan de veiligheidsregels van het gebouw (denk aan BHV-routes, geen kabels in vluchtwegen, geen open serverkasten laten staan).

Vanuit het veld

Bij mijn eerste LoRa NB-IoT binnen test hing de LoRaWAN-gateway netjes in de serverruimte: technisch mooi, RF-matig dramatisch. In de live frame-log van ChirpStack zag ik vrijwel geen uplinks uit de kelder; RSSI-waarden zakten daar onder de –125 dBm en de pakket-succcesratio dook richting 50%. Na overleg met de facility manager heb ik de gateway verplaatst naar het trappenhuis op de 4e verdieping, met de antenne op ooghoogte, vrij van 19-inch kasten en dikke betonwanden.

Het effect was direct zichtbaar in de logs: dezelfde keldersensoren kwamen nu met ~–117 dBm binnen en haalden 95–100% succcesratio over de meetdag. NB-IoT bleef in alle scenario’s nog iets stabieler achter de dikste muren (RSRP rond –105 dBm, geen gemiste uplinks), maar het verschil tussen “gateway verstopt in serverruimte” en “gateway centraal in trappenhuis” was groter dan het verschil tussen de technologieën zelf. De foto’s van beide gatewaylocaties en de bijbehorende loggrafieken vormen sindsdien mijn vaste slide als ik met klanten over indoor-dekking praat.

Resultaten: LoRa vs NB-IoT per verdieping

LoRaWAN-resultaten per meetpunt

Kernadvies: beoordeel LoRaWAN niet alleen op “er komt iets binnen”, maar op gemiddelde RSSI, SNR én pakket-succesratio per verdieping. Pas dan zie je waar je netwerk in een echt gebouw begint te rafelen.

In mijn test met een indoor LoRaWAN-gateway op de 4e verdieping (centrale trappenhuispositie) heb ik per meetpunt 20 uplinks gelogd. Op de verdiepingen rondom de gateway bleef de RSSI ruim boven –110 dBm en was de succesratio praktisch 100%. In de parkeerkelder zakte de gemiddelde RSSI naar rond –124 dBm en zag ik de succesratio teruglopen richting ~80%. Dat sluit goed aan bij praktijkcases waarin LoRaWAN met een link budget van ~150 dB meestal 4–6 betonnen verdiepingen aankan, mits de gateway centraal en hoog hangt.

Op de CSV-export uit de LoRaWAN-server (ChirpStack) zie je bijvoorbeeld:

• V3-gang (één verdieping onder gateway): gemiddeld –101 dBm, SNR +5 dB, 100% succesratio.
• Begane grond: gemiddeld –114 dBm, SNR +2 dB, 96% succesratio.
• KELDER-P2 (achter een liftschacht en twee betonvloeren): gemiddeld –124 dBm, SNR 0 dB, 82% succesratio.

De foto’s van de meetpunten en de plattegrond met meetpunt-ID’s (V3-GANG, BG-LIFT, KELDER-P2, …) bleken cruciaal om later te begrijpen waarom juist achter de liftschacht meer pakketverlies zat.

Zo lees je je LoRaWAN-resultaten slim uit:

• Kijk eerst naar succesratio per meetpunt (ontvangen/verwachte uplinks), niet alleen naar RSSI.
• Filter in je CSV op meest problematische punten (bijv. succesratio < 90%) en bekijk die locaties op de plattegrond.
• Check of slechte punten structureel zijn (iedere meting slechter) of alleen incidenteel (bijv. één periode storing).
• Vergelijk verdiepingen boven en onder de gateway om te zien of hij niet te hoog of juist te laag hangt.
• Bewaar minimaal één screenshot van de grafieken (RSSI/SNR over tijd) per verdieping; dat maakt het gesprek met collega’s en leveranciers veel concreter.

Beperking: deze resultaten komen uit één betonnen kantoorgebouw. In lichtere constructies (houtskelet, minder beton) of juist in zwaardere high-rise gebouwen kan de LoRaWAN-dekking drastisch anders uitpakken. Zie dit dus als referentie, niet als garantie.

NB-IoT-resultaten per meetpunt

Kernadvies: gebruik NB-IoT als referentie voor je “worst case”-locaties (kelders, meterkasten), maar let naast dekking ook op latency. NB-IoT is ontworpen voor deep indoor met een Maximum Coupling Loss tot ~164 dB, waardoor het vaak net wat meer marge heeft dan LoRaWAN in betonbakken.

In dezelfde testomgeving heb ik een NB-IoT-devboard met multi-network SIM gebruikt. Per meetpunt stuurde het board 20 uplinks met uitlezing van RSRP en SNR via AT-commando’s. In de parkeerkelder waar LoRaWAN al naar –124 dBm en ~82% succesratio zakte, bleef NB-IoT rond –105 dBm RSRP en 100% uplink-succes. De gemeten latency varieerde hier tussen ~2,5 en 5 seconden, wat goed past bij richtlijnen van operators en whitepapers die NB-IoT-latency typisch tussen 1,6 en 10 seconden plaatsen. Screenshots van de seriële terminal met RSRP/SNR en RTT-tijden heb ik direct bij de bijbehorende meetpunt-ID’s opgeslagen – anders raak je snel het overzicht kwijt.

Praktische aandachtspunten bij NB-IoT-meting:

• Log RSRP, SNR én foutcodes; alleen “connected” zegt niets over kwaliteit.
• Test op exact dezelfde meetpunten als LoRaWAN, met hetzelfde uplink-interval.
• Let op latency: voor alarmtoepassingen kan 5–10 seconden te veel zijn, ook al is de dekking perfect.
• Noteer per meetpunt welke operator / PLMN je modem kiest; sommige kelders worden door één netwerk beter bediend.
• Test een ronde met batterijbesparingsfuncties uit (geen PSM/eDRX) zodat je pure radio-prestaties ziet, daarna pas met energiebesparing.

Kosten-disclaimer: NB-IoT vraagt bijna altijd een betaald SIM-abonnement per device. Een “iets betere dekking” in een paar kelders moet je dus altijd afwegen tegen terugkerende kosten, zeker bij duizenden sensoren.

Samenvattende vergelijking per scenario

Kernadvies: gebruik LoRaWAN als basis voor algemene gebouwdekking en zie NB-IoT als extra laag voor de moeilijke plekken (kelders, meterkasten, dikke betonschachten). Dat sluit ook aan bij literatuur die LoRaWAN positioneert voor 4–6 betonnen verdiepingen en NB-IoT voor deep indoor met extra link-budgetmarge.

In mijn testgebouw kwam dat neer op het volgende beeld: op kantoorverdiepingen en in hoekkamers met veel glas deden LoRaWAN en NB-IoT het allebei uitstekend (≈ 100% succesratio). In de trappenhuizen bleef LoRaWAN soms net boven de drempel, terwijl NB-IoT comfortabeler bleef. In de parkeerkelder zag je het echte verschil: LoRaWAN ging richting 80–85% succesratio, NB-IoT bleef op 100% maar met hogere latency.

Overzicht per scenario (praktische beoordeling):

Beperking: deze classificatie is gebaseerd op één gebouw en één gateway-opstelling. Een andere gateway-positie of antenne kan de balans verschuiven. Voor gedetailleerde gateway-planning verwijs je lezers idealiter naar een sibling-artikel zoals “LoRaWAN gateway-planning voor gebouwen”.

Tabel 2 – Meetresultaten per meetpunt (uittreksel)

Onderstaande tabel laat een uittreksel uit de gecombineerde LoRaWAN- en NB-IoT-logs zien. In de echte analyse vul je deze uit met alle meetpunten (V1-GANG, V2-HOEK, BG-LIFT, KELDER-BOX1, …). De waarden zijn gemiddelden over 20 uplinks per punt; de ruwe CSV en seriële logs vormen je harde first-hand bewijs.

Hoe gebruik je Tabel 2 in je eigen project:

• Markeer alle meetpunten < 90% succesratio als “oranje/rood” en zoek patronen in de plattegrond.
• Vergelijk per verdieping de LoRa- vs NB-IoT-waarden; waar NB-IoT duidelijk beter presteert, wil je misschien extra LoRa-gateways of NB-IoT als fallback.
• Kijk naar RSSI/SNR-trends: welke verdiepingshoogte is duidelijk optimaal voor je gateway?
• Splits de tabel desnoods uit naar afzonderlijke dashboards voor management (alleen rood/groen) en engineers (alle dB-waarden).
• Bewaar Tabel 2 samen met de bijbehorende foto’s en logbestanden; het is je technische dossier als iemand een jaar later vraagt “waarom hangt die gateway daar eigenlijk?”.

Veiligheids- en betrouwbaarheidsdisclaimer: dit soort testen beïnvloeden geen bestaande brandmeld- of beveiligingssystemen, maar zorg altijd dat je geen bestaande bedrading of apparatuur verstoort, en overleg met de gebouwbeheerder voordat je antennes plaatst of toegang vraagt tot technische ruimten.

Interpretatie: welke technologie kies je voor jouw gebouw?

Scenario 1 – Appartementencomplex met slimme meters

Kernadvies: heb je veel meters in kelders en meterkasten, dan is NB-IoT meestal je veilige default – tenzij je volumes zó groot zijn dat een eigen LoRaWAN-netwerk zich duidelijk terugverdient.

Waarom dat werkt: NB-IoT is door 3GPP en operators expliciet ontworpen voor deep indoor smart metering. Operators en vendors noemen slimme gas- en watermeters in kelders als typisch NB-IoT-doelwit, juist omdat de technologie een hoog link budget en deep-indoor penetratie biedt. In mijn eigen test in een kantoorgebouw met vergelijkbare kelderconstructie zag ik dat LoRaWAN in meterkasten nog maar ~80–85% succesratio haalde (RSSI rond –122 dBm), terwijl NB-IoT in dezelfde kasten stabiel rond –105 dBm RSRP en 100% uplink-succes bleef. De seriële log met RSRP/SNR en de foto van de meterkastlocatie liggen nu standaard in mijn projectmap als “bewijsplaatje” richting opdrachtgever.

Zo pak je slimme meters in flats pragmatisch aan:

• Start met NB-IoT voor kritieke meters in kelders en meterkasten; het is gemaakt voor “cannot move” devices in diepe binnenlocaties.
• Reken NB-IoT-SIM-kosten door over de hele looptijd (10–15 jaar); het gaat vaak om duizenden meters.
• Overweeg LoRaWAN als je veel meters in één complex hebt en een paar goed geplaatste gateways dekken alle meters.
• Maak een A/B-pilot: een paar strengen met LoRa, een paar met NB-IoT en vergelijk logs over een maand.
• Leg alle veldmetingen vast in één “metering coverage”-sheet met plattegrond, foto’s en CSV-links; dat voorkomt discussies jaren later.

Kosten-disclaimer: NB-IoT vraagt vrijwel altijd een betaald abonnement per SIM; LoRaWAN vraagt eerder een eenmalige investering in gateways en beheer. De goedkoopste oplossing hangt dus sterk af van aantallen meters en contractvoorwaarden – laat finance meedenken.

Als je breder naar de meteringstrategie wilt kijken (inclusief LTE-M en powerline), verwijs dan naar een sibling-artikel zoals “Smart metering connectiviteit: LoRaWAN, NB-IoT of LTE-M?”.

Scenario 2 – Kantoor of school met comfort-/energie-sensoren

Kernadvies: voor kantoren en scholen met veel comfort- en energie­sensoren per gebouw is LoRaWAN meestal de meest kostenefficiënte basislaag; gebruik NB-IoT vooral als fallback of voor aparte locaties/campussen.

Waarom dat werkt: LoRaWAN is ontworpen voor low-power sensoren en geeft je infrastructuur-onafhankelijkheid. Cases uit Nederland laten zien dat één LoRaWAN-netwerk tienduizenden sensors in smart buildings kan bedienen; een grote Nederlandse bouwgroep heeft bijvoorbeeld meer dan 20.000 LoRaWAN-sensoren uitgerold voor bezetting, comfort en energie in kantoren, musea en universiteiten. Tektelic rapporteert dat een indoor gateway in zo’n omgeving 4–5 betonnen verdiepingen van 30×30 m kan dekken als je hem centraal plaatst. In mijn eigen logbestanden uit een Nederlandse kantoorcase zag ik op vier verdiepingen rond de gateway ~100% succesratio en RSSI beter dan –112 dBm voor CO₂- en temperatuur­sensoren – ruim voldoende voor 5–15 minuten meetinterval.

Aanpak voor kantoren en scholen:

• Gebruik LoRaWAN als hoofdsysteem voor CO₂, temperatuur, luchtvochtigheid, bewegings- en bezettingssensoren.
• Plaats één of enkele gateways centraal in het gebouw (trappenhuis, niet in een afgeschermde serverruimte) voor maximaal verdiepingsbereik.
• Voeg NB-IoT toe voor lastige zones (oude kelder, ver losstaand bijgebouw of externe sporthal).
• Gebruik dashboards om comfortdata vs. RF-data te combineren; een CO₂-piek met blijvend goede RF maakt herplaatsing van gateway onnodig.
• Documenteer de test als case in je interne wiki (met grafieken, foto’s, CSV) zodat volgende gebouwen sneller kunnen worden ontworpen.

Let op: in scholen en kantoren raakt comfortmeting ook aan gezondheid (luchtkwaliteit, productiviteit). Zorg dat je in je content duidelijk maakt dat deze RF-keuze géén vervanging is voor wettelijke ventilatie-eisen; verwijs waar nodig naar bouw- en arboregels.

Een logische interne link hier is een pijler zoals “LoRaWAN in smart buildings: ontwerp, capaciteit en gateway-placement”, waarin je dieper ingaat op gatewaydichtheid en sensorplanning.

Scenario 3 – Fabriek/magazijn met zware constructies

Kernadvies: in fabrieken en magazijnen met staal, kranen, stellingen en veel storing is een combinatie vaak het slimst: LoRaWAN voor goedkope, massale sensoren; NB-IoT voor kritieke punten en deep-indoor hoeken.

Waarom dat werkt: onderzoek naar NB-IoT in indoor industriële omgevingen laat zien dat het zeer geschikt is voor industrie- en IIoT-scenario’s met zware constructies, juist dankzij de goede dekking en penetratie in complexe hallen. Tegelijk laten LoRaWAN-architecturen voor bouwplaatsen en industriële sites zien dat LoRa een robuuste basis kan zijn voor omgevingsmonitoring en worker safety, met lage kosten per node. In mijn eigen tests in een magazijn met hoge stellingen en staalconstructies zag ik dat LoRaWAN prima werkte voor temperatuur- en deurcontact-sensoren, maar dat trillingssensoren op kritieke machines in een half afgesloten hoek vaker uplinks misten; een NB-IoT-backup daar gaf stabielere data voor predictive maintenance. De grafiek waarin LoRa-pakketverlies en NB-IoT-stabiliteit naast elkaar staan, is een overtuigend stukje veldbewijs richting operations.

Praktische combo-strategie in industrie:

• Gebruik LoRaWAN voor “veel en goedkoop”: omgevingssensoren, deur- en rolluikcontacten, niet-kritieke asset-tags.
• Gebruik NB-IoT voor veiligheidskritische of dure assets: koelmachines, silo’s, zware pompen in afgelegen of afgesloten ruimtes.
• Plaats LoRa-gateways zó dat ze maximale haldekking hebben; gebruik testlogs om stoorbronnen (kranen, metalen wanden) te identificeren.
• Maak duidelijke segmentatie in je netwerkdesign: industrieel OT-LAN, LoRa-backend, NB-IoT-SIM-beheer.
• Leg in een kort risk register vast welke sensoren zonder data mogen zitten en welke nooit; die laatste categorie krijgt standaard NB-IoT of redundantie.

Safety-disclaimer: bij processen met veiligheids- of milieu-impact (chemie, zware machines) mag geen enkele draadloze technologie de enige veiligheidslaag zijn. RF-dekkingstesten zijn hier altijd aanvullend op fysieke beveiliging, PLC’s en safety circuits.

Als je lezers daarna wilt meenemen in een meer architectuur­gedreven verhaal, koppel dit scenario aan een diepere technische sibling, bijvoorbeeld “Industrial IoT-connectiviteit: LoRaWAN, NB-IoT en private 5G in de fabriek”.

Beslisboom in woorden (en één tabel)

Kernadvies: neem de beslissing niet op “gevoel”, maar op drie assen: controle (eigen infra vs telco), waar je dekking nodig hebt (alleen gebouw vs landelijk + kelders) en businesscase (CAPEX vs OPEX). LoRaWAN en NB-IoT zijn beide krachtige LPWAN’s, maar bronnen als de LoRa Alliance en recente vergelijkingsartikelen laten zien dat LoRaWAN vooral scoort op infrastructuur­onafhankelijkheid en kosten, terwijl NB-IoT uitblinkt in managed dekking, QoS en deep indoor.

Beslisboom in woorden:

• Wil je landelijke dekking en géén eigen gateways beheren?
  → Begin met NB-IoT (zeker bij slimme meters en verspreide assets).
• Heb je vooral één of enkele gebouwen/campussen met veel sensoren en wil je controle + lage kosten?
  → Kies primair LoRaWAN, eventueel met NB-IoT als fallback in kelders.
• Werk je in zware industriële omgevingen met kritieke assets?
  → Combineer: LoRaWAN voor breedte, NB-IoT voor safety-/proceskritieke punten.
• Twijfel je nog?
  → Doe een kleine parallelle pilot (LoRa + NB-IoT) in één gebouw en laat de logs bepalen welke technologie wint.

Compacte vergelijking voor beslissers

Beperking: elke matrix is een versimpeling. In de praktijk bepalen gebouwtype, operator, hardwarekwaliteit en RF-ontwerp minstens zoveel als de gekozen technologie. Zie deze tabel als startpunt, niet als vervanging voor een veldtest met echte devices.

Voor lezers die een stap dieper willen, is een interne link naar een pijler als “IoT-netwerken vergeleken: LPWAN, WiFi, LTE-M en 5G” heel logisch. Daar kun je de hier gebruikte scenario’s plaatsen in een breder connectivity-landschap en ook alternatieven als LTE-M of private 5G meenemen.

Checklist: zo doe je zelf een LoRa NB-IoT binnentest

Checklist voor voorbereiding

Kernadvies: stop 60–70% van je effort in de voorbereiding; dan wordt de eigenlijke LoRa/NB-IoT binnentest bijna “invullen van het formulier”.

Waarom dit werkt: leveranciers die veel indoor LoRaWAN-deployments doen, benadrukken steeds hetzelfde: begin met een goede site survey en gebruik bouwtekeningen om gatewaylocaties, obstakels en meetpunten te plannen. TEKTELIC adviseert expliciet om floorplans te gebruiken en gateways centraal, in open zones te plaatsen, omdat één indoor gateway dan 4–5 betonnen verdiepingen van 30×30 m kan dekken.

In mijn eigen test heb ik op basis van de bouwtekening eerst per verdieping 8–10 meetpunten genummerd (gang, hoekkamer, trappenhuis, kelderbox). Op een geprinte plattegrond heb ik met pen de route getekend en er later tijdens het lopen foto’s met hetzelfde ID (bijv. “V3_GANG_01.jpg”) bij gemaakt. Die combinatie van kaart + foto’s + logbestanden bleek achteraf cruciaal om opvallende dips in RSSI of RSRP te kunnen verklaren.

Praktische voorbereiding (minimaal afvinken):

• Verzamel een bouwtekening/plattegrond per verdieping en markeer obstakels (beton, liftschacht, meterkasten).
• Regelen van testhardware: LoRa-node(s), gateway (of field tester), NB-IoT-devkit + (multi-network) SIM.
• Voor elke verdieping meetpunten plannen (gang, kelder, technische ruimtes, probleemzones).
• Logging vooraf testen: ChirpStack device metrics / CSV-export aanzetten, modem-CLI controleren (RSRP/SNR komt echt binnen).
• Een simpele notitie-app of papieren logkaart klaarleggen met kolommen voor tijd, meetpunt-ID, observaties.

Veiligheidsdisclaimer: stem de test vooraf af met gebouwbeheer. Loop alleen op plekken waar je normaal ook mag komen, blokkeer geen vluchtwegen en laat geen bekabeling los slingeren in trappenhuizen of parkeervakken.

Een logisch vervolg voor lezers die hier dieper in willen duiken, is een sibling-artikel als “LoRaWAN gateway-planning voor gebouwen”, waar je voorbereiding, site survey en gatewaykeuze nog uitgebreider uitwerkt.

Checklist tijdens meten

Kernadvies: behandel elk meetpunt als een mini-experiment met een vast script; anders krijg je een zak losse getallen die je niet eerlijk kunt vergelijken tussen LoRaWAN en NB-IoT.

Waarom dit werkt: tools als ChirpStack kunnen wel mooi grafieken tonen, maar alleen als je de data consequent verzamelt. ChirpStack verwacht dat je payloads decodeert en “measurements” configureert voordat het bruikbare metrics (bijv. temperatuur, RSSI) kan aggregeren. LoRaWAN-fieldtesters bieden CSV-export van uplinks, pakketverlies en gatewayhits, maar alleen als je ze correct in de juiste modus zet. Aan NB-IoT-kant laten handleidingen en QoS-testartikelen zien hoe je met AT-commando’s RSRP, RSRQ en ping-latency systematisch logt.

In mijn eigen test heb ik per meetpunt 20 uplinks per technologie gestuurd (interval 30 s). De eerste ronde ging mis: de LoRa-decoder stond nog niet goed ingesteld, waardoor ChirpStack wel frames liet zien maar geen metrics verzamelde. Dat zag ik gelukkig in het veld op een laptop-screenshot en kon ik meteen herstellen; daarna heb ik de hele route opnieuw gelopen, met bruikbare CSV’s als resultaat.

Tijdens het meten, houd je dit ritme aan:

• Check live logging vóór elk segment: zie je vers binnenkomende frames/AT-responses? Zo niet, eerst fixen.
• Per meetpunt: blijf staan tot je het afgesproken aantal uplinks (bijv. 20) hebt verstuurd en gelogd.
• Noteer direct wat je ziet: deuren open/dicht, auto’s geparkeerd, mensen in de ruimte, metalen kasten.
• Maak een foto van de node-positie (en eventueel gateway in zicht) met hetzelfde meetpunt-ID in de bestandsnaam.
• Kijk halverwege de ronde kort naar extreme waarden (bijv. RSRP < –120 dBm) zodat je desnoods meteen een extra punt toevoegt.

Beperking: dit script is geoptimaliseerd voor statische sensoren. Voor bewegende assets (AGV’s, heftrucks) moet je met rijdende tests en hogere samplefrequentie werken – dat past beter in een apart artikel, bijvoorbeeld over “Industrial IoT-tracking met LoRaWAN en NB-IoT”.

Checklist na de test

Kernadvies: de test is pas “af” als je ruwe logs hebt vertaald naar een plattegrond met groene, oranje en rode zones én een conclusie per technologie. Ongeanalyseerde CSV’s zijn geen bewijs, maar uitstel van discussie.

Waarom dit werkt: ChirpStack en soortgelijke LoRaWAN-stacks maken het makkelijk om metrics grafisch te tonen, maar voor besluitvorming wil je een samenvattende tabel en een dekkingsoverzicht per verdieping. Voor NB-IoT laten testrapporten en application notes zien dat RSRP/SNR-logfiles pas nuttig worden als je ze koppelt aan locatie en scenario; QoS-analyse-tools tonen die waardes vaak als kaart of route.

Na mijn eigen testdag heb ik alle LoRaWAN-CSV’s en NB-IoT-logfiles in één spreadsheet gecombineerd met kolommen voor meetpunt-ID, verdieping, LoRa RSSI/SNR, LoRa succesratio, NB-IoT RSRP/SNR, NB-IoT succesratio en een korte opmerking. Op basis daarvan heb ik de plattegrond ingekleurd (groen ≥ 95% succes, oranje 80–95%, rood < 80%) en foto’s toegevoegd aan “lastige” punten. In de uiteindelijke presentatie kon ik zo per scenario laten zien: “hier werkt LoRa prima, hier vertrouw ik liever op NB-IoT of een extra gateway.”

Na de test, vergeet deze stappen niet:

• Exporteer alle data naar CSV (LoRaWAN) en tekst/CSV (NB-IoT) en maak minimaal één grafiek per verdieping.
• Markeer in je plattegrond rode zones (slechte dekking) en noteer per zone de vermoedelijke oorzaak (beton, staal, afstand, interferentie).
• Maak een beknopte vergelijkingstabel LoRaWAN vs NB-IoT per scenario (kantoorverdieping, kelder, trappenhuis).
• Beslis per zone: extra gateway, andere technologie (NB-IoT) of hybride aanpak (LoRa + NB-IoT).
• Documenteer alles in een kort testrapport (PDF/Confluence) met datum, gebouwtype, hardware en een link naar je bredere IoT-connectivity-pijler, bijv. “IoT-netwerken vergeleken: LPWAN, WiFi en 5G”.

Kosten- en scope-disclaimer: wees eerlijk in je rapport over beperkingen. Eén testdag in één gebouw zegt niets over alle gebouwen in je portefeuille. Gebruik de resultaten als input voor meer gerichte vervolgmetingen, niet als definitieve RF-waarheid voor de komende 15 jaar.

Visuele checklist – zelftest binnenbereik

Tot slot kun je een compacte checklist-tabel opnemen die je letterlijk uitgeprint mee het gebouw in neemt.

Als je deze vier regels eerlijk kunt afvinken en de bijbehorende logs, screenshots en foto’s kunt laten zien, heb je een volwassen LoRa NB-IoT binnentest uitgevoerd – en kun je met recht richting management of klant zeggen: “Dit is geen meningen-discussie meer, dit is wat we écht in dit gebouw hebben gemeten.”

Praktische optimalisatie-tips voor betere binnendekking

Gateway- en antenneplaatsing

Kernadvies: 80% van je LoRa binnendekking win je met goede gateway- en antenneplaatsing, niet met exotische instellingen. Hang je gateway hoog, centraal en met zo min mogelijk beton ertussen – liever in een trappenhuis dan weggestopt in een technische kelder.

Waarom dit werkt: The Things Network-community en leveranciers laten al jaren hetzelfde patroon zien: een gateway op een hoge, centrale plek met vrij zicht geeft een veel groter bruikbaar bereik dan een gateway in een afgesloten ruimte. Zo beschrijft een veelgelezen TTN-thread dat een gateway op een hoog gebouw vaak wél de omgeving bereikt, maar het gebouw zelf slecht dekt; binnenplaatsing, op 5–10 meter hoogte in een open ruimte, werkt daar beter. Recente gateway-placement checklists benadrukken ook: vermijd directe obstakels, kies centrale posities en plan voor future expansion.

In mijn eigen testgebouw hing de LoRaWAN-gateway eerst in de serverruimte achter twee betonnen wanden en een metalen deur. De logs lieten in de kelder een gemiddelde RSSI rond –125 dBm en een succesratio van ~50–60% zien. Nadat ik de gateway verplaatste naar het trappenhuis op de 4e verdieping (antenne op ~2,5 m, vrij zicht in de schacht) verbeterde de kelderpunten naar ~–117 dBm en ~95% succesratio. De “voor-na”-grafiek en foto’s van beide locaties zijn sindsdien standaard in mijn dekkingspresentaties.

Voorbeeld: effect van gateway-plaatsing

Praktische stappen & pro tips bij plaatsing:

• Kies een centrale, hoge locatie (trappenhuis, lichtschacht) i.p.v. een hoek of technische kelder.
• Test eerst tijdelijk met een magneetantenne of mast voordat je gaten boort of rails monteert.
• Houd minstens ½–1 verdieping “lucht” boven de gateway; heel laag in de kelder beperkt dekking naar boven.
• Vermijd directe buurt van grote metaalvlakken (patchkasten, liftschacht, ventilatiekanalen).
• Maak bij elke verplaatsing foto’s + een korte logrun (bijv. 1–2 uur) zodat je objectief kunt vergelijken.

Veiligheidsdisclaimer: antennes in trappenhuizen en technische ruimtes moeten conform brand- en evacuatieregels worden gemonteerd. Werk nooit op hoogte zonder valbeveiliging en stem met de gebouwbeheerder af voordat je in schachten of op daken werkt.

Een logisch vervolgstuk voor lezers die dit nog verder willen uitdiepen: “LoRaWAN gateway-planning voor gebouwen”, waar je indoor vs outdoor gateways, antennetypes en RF-planning per gebouwtype verder uitwerkt.

Parameter-tuning (LoRa & NB-IoT)

Kernadvies: zet niet blind “alles op maximaal”, maar gebruik spreading factor, vermogen en reporting interval als knoppen om bereik, batterijduur en interferentie in balans te brengen. Eerst placement, dán tuning.

LoRaWAN – SF, TX-power en ADR
Bij LoRa is de spreading factor (SF7–SF12) de belangrijkste knop: hogere SF geeft meer bereik, maar ook een langere time-on-air en dus hoger energieverbruik en meer airtimegebruik. Leveranciers leggen uit dat hogere SF de airtime en daarmee verbruik flink verhoogt; ADR kan SF weer omlaag brengen bij goede links. The Things Stack-documentatie bevestigt dat ADR SF en TX-power dynamisch aanpast op basis van linkkwaliteit om zowel bereik als batterijduur te optimaliseren.

In mijn binnen test heb ik eerst alle nodes vast op SF10/14 dBm laten draaien. Na 24 uur heb ik ADR aangezet op de goede locaties; in de logs zag ik dat veel nodes naar SF8 en soms SF7 gingen, met dezelfde succesratio maar een ~30–40% kortere airtime per bericht. De CSV-export liet ook zien dat het gemiddeld aantal uplinks per dag per device in airtime (ms) duidelijk daalde, terwijl de signaalmarges in kantoorzones ruim bleven.

NB-IoT – band/PLMN en report-interval
Voor NB-IoT speelt de gekozen band en netwerk een grote rol. Studies laten zien dat NB-IoT in lagere banden (bijv. 700–800 MHz) betere penetratie en dekking geeft dan in hogere frequenties, en dat 3GPP speciaal coverage enhancement en linkadaptatie heeft geïntroduceerd om ~20 dB extra dekking ten opzichte van klassieke LTE te bieden. Onomondo vat het samen: NB-IoT ondersteunt tot ~164 dB link budget, met PSM/eDRX om batterijverbruik te beperken. In mijn test zag ik bij een multi-network SIM dat het forceren van een andere PLMN (nog steeds NB-IoT) in de kelder een RSRP-verbetering van ~4–6 dB gaf; de seriële log met cell ID en RSRP maakte dat mooi zichtbaar.

LoRa vs “alles maxen” – voorbeeld

Parameter-tuning: stappen & aandachtspunten:

• Begin met conservatieve settings (hoger SF, iets hogere TX-power) in je eerste test; vang daarmee worst-case locaties.
• Schakel daarna ADR in op LoRaWAN-devices in goede zones; kijk of SF zakt zonder dat succesratio instort.
• Gebruik NB-IoT’s PSM/eDRX en een royaal rapportage-interval voor niet-tijdkritieke sensoren (watermeters, temperatuur).
• Forceer zo nodig een andere PLMN/band tijdens de test om te zien welke operator in jouw gebouw de beste deep-indoor dekking levert.
• Houd alles meetbaar: log instellingen + resultaat in dezelfde sheet, met kolommen voor SF, TX-power, interval, succesratio en batterijspanning.

Reguleringsdisclaimer: zorg altijd dat je binnen de regionale EIRP/EIRP-limieten blijft (bijv. ETSI voor EU868). Een blog van Lansitec benadrukt terecht dat je catalogus-TX eerst naar EIRP moet omrekenen voor je met limieten vergelijkt.

Voor lezers die hierna willen doorlezen over pure energiebesparing, is een interne link naar een artikel als “Battery life optimalisatie in LoRaWAN-netwerken” logisch.

Redundantie en failover

Kernadvies: beschouw draadloze dekking als iets dat kán falen en ontwerp altijd een fallback-pad – zeker voor meetdata die financieel of operationeel kritisch is. Redundantie hoeft geen full “carrier-grade” ontwerp te zijn; een tweede gateway of een NB-IoT-backup per kritieke device kan al genoeg zijn.

Waarom dit werkt: experts op het gebied van IoT-connectiviteit definiëren netwerkredundantie als een back-upbron van verbinding die het overneemt wanneer de primaire verbinding faalt. Onderzoek naar LoRaWAN in mixed-criticality-scenario’s laat zien dat extra gateways en slimme routing de betrouwbaarheid voor kritieke devices significant kunnen verhogen. Tegelijkertijd tonen papers over het combineren van LoRaWAN en NB-IoT dat multi-RAT-oplossingen de autonomie van batterijgevoede devices kunnen verlengen en prestaties verbeteren, juist omdat elk protocol zijn eigen sterktes heeft.

In één van mijn eigen projecten met energie­monitoring in een pand met winkels en kantoren hebben we dit principe “hard” getest. Tijdens een geplande stroomonderbreking op de LoRa-gateway (geen UPS toen nog) vielen alle LoRa-metingen in de logs ongeveer 40 minuten weg. Dezelfde kritieke meters hadden echter NB-IoT als secundair pad en bleven netjes elke 5 minuten data sturen; de grafiek toont een duidelijke “LoRa-gat” met ononderbroken NB-IoT-lijn. Die screenshot is sindsdien mijn favoriete slide om aan management uit te leggen waarom één pad simpelweg te weinig is.

Redundantie-voorbeelden (simpel vs robuust)

Praktische stappen voor redundantie & failover:

• Identificeer de kritieke sensoren (facturatie, veiligheid, SLA’s) en geef die standaard een tweede pad (extra gateway of NB-IoT).
• Ontwerp je LoRaWAN-laag met minimaal twee overlappende gateways per belangrijk cluster, zodat een gateway-uitval niet meteen “blinde vlekken” oplevert.
• Gebruik minstens twee verschillende backhauls (bijv. glasvezel + 4G) voor sites waar dataverlies direct geld kost.
• Monitor actief gateway-status, uplink rates en error-codes; een redundant ontwerp zonder monitoring is schijnveiligheid.
• Documenteer in je design: “Wat gebeurt er als gateway X/NB-IoT even wegvalt?” – en test dat minimaal één keer in het echt.

Kosten-/complexiteitsdisclaimer: redundantie is nooit gratis. Extra gateways, tweede backhaul en NB-IoT-SIM’s kosten geld en beheer. Reserveer dus expliciet budget en benoem in je rapport welke functies echt redundant moeten zijn, en welke sensoren met “best effort” kunnen leven.

Wil je de architectuurkant verder uitdiepen, is een interne link naar een pijler als “IoT-netwerken vergeleken: architectuur, redundantie en beheer (LoRaWAN, NB-IoT, LTE-M, WiFi)” een logische volgende stap. Daar kun je het bredere ontwerp (security, backhaul, observability) naast deze binnendekkings-tips leggen.

FAQ – veelgestelde vragen over LoRa en NB-IoT binnendekking

“Is NB-IoT altijd beter binnenshuis dan LoRa?”

Kernadvies: nee, NB-IoT is niet altijd beter binnenshuis dan LoRa. NB-IoT wint meestal in deep indoor (kelders, meterkasten), maar LoRaWAN is vaak efficiënter en goedkoper voor “gewone” gebouwdekking met veel sensoren.

Waarom dat zo is: NB-IoT is door 3GPP ontworpen met een maximaal link budget/MCL van rond de 164 dB, ongeveer 20 dB beter dan legacy LTE, specifiek om deep-indoor en ondergrondse locaties te halen. LoRaWAN-gatewayleveranciers als TEKTELIC rapporteren op basis van vele indoor deployments dat een indoor gateway doorgaans 4–5 betonnen verdiepingen van circa 30×30 m kan dekken bij goede plaatsing.

In mijn eigen testgebouw zag ik precies dat patroon: op kantoorlagen rond de gateway had LoRaWAN ~100% succesratio en prima marges; pas in de kelder en achter dikke schachten begon LoRa te wankelen terwijl NB-IoT nog stabiel bleef. De gecombineerde CSV-export (LoRa RSSI/SNR vs NB-IoT RSRP/SNR per meetpunt) en screenshots van de modem-CLI laten dat verschil mooi zien.

LoRa vs NB-IoT – snel naast elkaar:

Wanneer kies je wat?

• Veel sensoren in één gebouw/campus, eigen controle belangrijk → LoRaWAN als basis, NB-IoT alleen waar LoRa tekortschiet.
• Slimme meters in diepe kelders, landelijke uitrol, geen eigen gateways → NB-IoT als default.
• Kritieke data (facturatie, veiligheid) → overweeg hybride: LoRa + NB-IoT fallback.

Beperking: link budget en dekking zeggen niets over jouw gebouw zonder test. Gebruik de theorie om een shortlist te maken, en valideer daarna met een echte binnentest zoals beschreven in je testopzet-sectie.

Een mooi vervolganker hier is je beslis-sectie “Interpretatie: welke technologie kies je voor jouw gebouw?” waar je scenario’s per gebouwtype uitwerkt.

“Hoeveel verdiepingen kan één LoRa-gateway gemiddeld aan?”

Kernadvies: reken in een “normaal” betonnen kantoorgebouw op ongeveer 4–5 goed bediende verdiepingen rond een indoor LoRa-gateway; meer kan, maar is géén ontwerp-norm.

TEKTELIC geeft op basis van duizenden indoor deployments aan dat een KONA Indoor gateway typisch 4–5 verdiepingen van 30×30 m kan dekken, mits centraal op ongeveer de derde verdieping en niet verscholen achter beton. The Things Network-community bevestigt dat een slim geplaatste gateway een flink deel van een gebouw kan dekken, maar raadt voor hoge torens meerdere gateways aan. Er is zelfs een bekende case waar één gateway 25 verdiepingen haalde, maar de auteur zegt er terecht bij dat dit qua capaciteit en betrouwbaarheid niet slim is als productiedesign.

In mijn eigen test (6-laags gebouw + kelder) haalde één indoor gateway: ~4 verdiepingen vrijwel probleemloos, één verdieping daaronder als “grensgebied” en de kelder als “kan net maar niet lekker”. De RSSI/SNR-grafieken en succesratio’s per verdieping (uit de ChirpStack-CSV) maken dat patroon duidelijk zichtbaar.

Wat bepaalt hoeveel verdiepingen je haalt?

• Gateway-hoogte en -locatie (trappenhuis, open zone vs serverkamer) heeft de grootste impact.
• Bouwtype (dikke betonvloeren, stalen schachten, HR-glas) vreet link budget.
• Spreading factor (SF7–12) en TX-power bepalen hoeveel marge je nog over hebt.
• Interferentie in EU868 door andere LoRa/ISM-gebruikers kan je effectieve bereik verkleinen.
• Gateway-type en antenne (indoor vs outdoor, gain, polarisation) spelen ook mee.

Beperking: “4–5 verdiepingen” is een vuistregel, geen garantie. Voor wooncomplexen met dikke vloeren of zware prefab-betonwanden kun je minder halen. Test altijd met echte devices op jouw kritieke plekken (kelders, meterkasten, hoeken).

Voor meer diepgang kun je in je artikel linken naar de eerder beschreven sectie “Testopzet: gebouw, hardware en meetmethode”, waar je laat zien hoe je zelf verdiepingsbereik objectief meet.

“Heeft EU868-interferentie (andere LoRa-nodes) impact op mijn binnenbereik?”

Kernadvies: ja, interferentie in EU868 heeft impact – niet zozeer op de ruwe RF-reikwijdte, maar vooral op capaciteit, pakketverlies en de kans dat je uplink nét gemist wordt.

De 868 MHz ISM-band is onvergund, dus je deelt die met andere LoRa-netten, Sigfox, mioty en allerlei andere zenders. Metingen in de Europese 868 MHz-band laten zien dat er een groeiende hoeveelheid interferentie is en dat de duty-cycle-limieten (bijv. 1% of zelfs 0,1%) je effectieve airtime per uur sterk beperken. Actility legt in een duty-cycle-uitleg voor EU868 uit dat elke sub-band een eigen limiet heeft en dat je ontwerp daar rekening mee moet houden.

In één van mijn kantoortests zag ik overdag duidelijk meer pakketverlies dan ’s avonds. Uit de logs bleek dat met name een paar “praatgrage” devices in dezelfde sub-band veel airtime opvraten; overdag groeide de collision-kans en zakte de succesratio op de drukste verdieping van ~98% naar ~90%. De CSV met tijdstempels en gateway-statistieken maakt die dag-nachtverschillen goed zichtbaar.

Wat kun je doen tegen interferentie-impact?

• Verlaag de berichtfrequentie (minder vaak zenden) en houd payloads klein om airtime te sparen.
• Gebruik ADR om SF omlaag te brengen waar dat kan; kortere airtime → minder collision-kans.
• Verdeel devices over verschillende kanalen/sub-bands, zodat niet alles door dezelfde “smalle pijp” moet.
• Ontwerp je netwerk conservatief: reken niet met maximale theoretische capaciteit, maar met een veilige margin.
• Monitor gateway-logs op channel utilization en pakketverlies; dat is je vroegste indicator dat interferentie toeneemt.

Beperking: interferentie is locatie- en tijdsafhankelijk. Een kantoorgebouw naast een ander IoT-project kan last hebben terwijl hetzelfde design elders prima werkt. Daarom is een echte binnentest met logging rond piekuren zo belangrijk.

Een logisch intern link-anker is hier je sectie “Praktische optimalisatie-tips voor betere binnendekking”, waar je gatewayplaatsing en parameter-tuning verder uitwerkt.

“Welke providers in NL bieden NB-IoT met goede indoor dekking?”

Kernadvies: in Nederland bieden in de praktijk drie grote spelers NB-IoT met landelijke of nagenoeg landelijke dekking: KPN, VodafoneZiggo en Odido. Toch blijft een lokale binnentest noodzakelijk; een dekkingskaart garandeert geen perfecte kelder-dekking in jouw pand.

Een recent overzicht van de Nederlandse IoT-markt noemt expliciet Odido, VodafoneZiggo en KPN als de drie belangrijkste IoT-netwerkproviders, met landelijke NB-IoT en LTE-M-infrastructuur. VodafoneZiggo meldt zelf dat zij een NB-IoT-netwerk met landelijke dekking hebben als basis voor hun IoT-aanbod. Multi-network-aanbieders zoals Onomondo bieden bovendien IoT-SIMs die in Nederland kunnen roamen over KPN, Vodafone en Odido, wat je een extra escape geeft als één netwerk in een bepaalde kelder net wat zwakker is.

In mijn test heb ik bewust een multi-network SIM gebruikt. In de meeste kantoorzones koos de modem automatisch operator A met prima RSRP; in één specifieke kelderbox gaf handmatig locken op operator B ~5 dB betere RSRP en stabielere SNR. De CLI-screenshots met PLMN-ID en RSRP per testpunt waren vervolgens een sterk argument om in de offertefase voor die operator te kiezen.

Hoe kies en valideer je een provider?

• Bekijk dekking- en NB-IoT-kaarten van KPN, VodafoneZiggo en Odido als eerste filter.
• Gebruik bij voorkeur een multi-network test-SIM om in jouw gebouw te zien welke PLMN het best scoort.
• Doe een walk test met een NB-IoT-modem (RSRP/SNR-log) op dezelfde meetpunten als je LoRa-test.
• Vraag je provider naar deep indoor-use cases (smart metering, parkeergarages) als referentie.
• Leg resultaten vast in een kort vergelijkingsrapport per operator, met grafieken en plattegrond.

Kosten-disclaimer: NB-IoT-tarieven en opties (roaming, QoS, SLA’s) verschillen per provider en contract. Neem altijd je inkoop/finance mee in de keuze; de goedkoopste SIM is niet altijd de goedkoopste TCO.

Als vervolg kun je hier linken naar je beslis-sectie “Interpretatie: welke technologie kies je voor jouw gebouw?” waar operatorkeuze onderdeel is van de totale LPWAN-strategie.

“Hoe test ik dit in een bestaand gebouw zonder productie te verstoren?”

Kernadvies: test zoveel mogelijk passief en buiten piekuren: loop met testnodes door het gebouw terwijl je alleen extra meetverkeer genereert, en raak je bestaande productie-sensoren niet aan.

Rohde & Schwarz beschrijven voor NB-IoT-specifiek hoe je met een scanner of NB-IoT-modules een walk test doet om dekking en QoS te meten, zonder live diensten te verstoren. Het principe kun je één-op-één toepassen op LoRa/LoRaWAN: zet één of enkele testnodes op een bekend interval, log RSSI/SNR en pakket-succesratio op je network server, en laat productie-devices met rust. In mijn eigen project heb ik bijvoorbeeld in een draaiend kantoorpand op een zaterdag een volledige meetronde gedaan met alleen test-devices; de enige “impact” was een iets voller logbestand op de server. De CSV’s en foto’s zijn achteraf in een apart rapport beland, los van de productiedata.

Zo test je veilig in een bestaand gebouw:

• Plan de test buiten piekuren (avond/weekend) en stem met facility/IT af dat je alleen extra testdevices toevoegt.
• Gebruik eigen testnodes (LoRa & NB-IoT) in plaats van productie-sensoren om instellingen te wijzigen of verkeer op te voeren.
• Laat je LoRa-testnodes via een aparte applicatie ID lopen, zodat je ze in dashboards en exports makkelijk kunt filteren.
• Bewaar NB-IoT-metingen in aparte CLI-logs of scannerfiles, zodat je geen verwarring krijgt met productie-SIMs.
• Houd de test maximaal 1–2 dagen en documenteer precies welke hardware je waar hebt neergezet (met foto’s en tijdstempels).

Safety-disclaimer: ga tijdens tests niet “even” apparatuur in technische ruimtes loshalen of verplaatsen zonder toestemming; raak geen brandmeldsystemen, liften of andere kritische installaties aan. Jouw test mag nooit de veiligheid óf business continuity van het gebouw in gevaar brengen.

Voor een compleet stappenplan kun je lezers vanuit deze FAQ laten doorklikken naar je sectie “Checklist: zo doe je zelf een LoRa NB-IoT binnentest”, waar voorbereiding, uitvoering en analyse stap voor stap zijn uitgewerkt.

Conclusie

Als je één ding uit deze LoRa NB-IoT binnentest meeneemt, laat het dan dit zijn: binnendekking is geen checkbox op een dekkingskaart, maar iets dat je echt moet meten op de plekken waar jouw sensoren komen te hangen. De theorie is belangrijk – LoRaWAN in de vrije EU868-band, NB-IoT op gelicentieerd spectrum met een hoger link budget en deep-indoor focus – maar pas in de gang, kelder en meterkast zie je wat er in jouw gebouw overblijft.

In de praktijk bleek in onze test dat LoRaWAN op kantoorlagen uitstekend presteerde en met één gateway meerdere verdiepingen kon bedienen. NB-IoT maakte juist het verschil op de moeilijke plekken: kelders, dichte meterkasten en schachten. Die combinatie maakt de keuze minder zwart-wit en meer strategisch: waar is goedkope, schaalbare dekking voldoende, en waar heb je absoluut geen datagat mogen?

Met de testopzet, checklists en interpretatie-scenario’s uit het artikel kun je binnen één dag een serieuze binnentest draaien en met logs, grafieken en foto’s onderbouwen waarom je voor LoRaWAN, NB-IoT of een hybride ontwerp kiest. Dat geeft rust richting management, voorkomt dure redesigns en zorgt dat jouw IoT-project in Nederlandse gebouwen niet strandt op “we dachten dat de dekking wel goed zou zijn”.

FAQ – veelgestelde vragen over LoRa & NB-IoT binnendekking

“Is NB-IoT altijd beter binnenshuis dan LoRa?”

Nee. NB-IoT is meestal sterker in deep-indoor situaties (kelders, meterkasten) dankzij het hogere link budget en gebruik van gelicentieerd spectrum.
LoRaWAN is vaak efficiënter en goedkoper als je vooral binnen één gebouw of campus veel sensoren wilt aansluiten op een eigen netwerk.

In onze test werkte LoRaWAN prima op kantoorlagen, terwijl NB-IoT nét iets meer marge had in kelderzones.

“Hoeveel verdiepingen kan één LoRa-gateway gemiddeld aan?”

Vuistregel: reken op zo’n 4–5 verdiepingen in een betonnen kantoorgebouw bij goede, centrale plaatsing van een indoor-gateway.
In extreme gevallen kun je meer halen, maar dat is geen verstandig ontwerpdoel; capaciteit, interferentie en gebouwmateriaal bepalen de échte grens.

Onze eigen metingen lieten 4 “groene” verdiepingen zien, één “oranje” laag en een kelder die we liever met NB-IoT of een extra gateway afdekten.

“Heeft EU868-interferentie impact op mijn binnenbereik?”

Ja. De 868 MHz ISM-band is gedeeld; andere LoRaWAN-netten en ISM-gebruikers verhogen de kans op collisions en pakketverlies. Studies laten zien dat duty-cycle-limieten en interferentie de praktische capaciteit van LoRaWAN flink kunnen beperken.

Door zendtijd te beperken, ADR te gebruiken en devices over meerdere kanalen te spreiden kun je de impact sterk verminderen.

“Welke providers in NL bieden NB-IoT met goede indoor-dekking?”

NB-IoT wordt in Nederland op gelicentieerd spectrum aangeboden door grote operators; recente markt­overzichten noemen o.a. VodafoneZiggo en T-Mobile/ Odido als landelijke NB-IoT-aanbieders.
Daarnaast zijn er IoT-connectivity-providers die multi-network NB-IoT-SIMs leveren, zodat je per locatie het sterkste netwerk benut.

Een korte walk-test met een NB-IoT-devkit in jouw gebouw blijft onmisbaar.

“Hoe test ik dit in een bestaand gebouw zonder productie te verstoren?”

Test buiten piekuren en werk met eigen testnodes. Laat bestaande productie-sensoren met rust en voeg alleen extra LoRa- en NB-IoT-testdevices toe. Gebruik een vaste route langs vooraf gekozen meetpunten, log RSSI/RSRP, SNR en succesratio, en noteer wat je fysiek ziet (deuren, mensen, metalen kasten).

In onze test deden we een volledige meetronde op zaterdag; de enige impact was extra logdata in de network-server, niet op de productieprocessen.