MeshCore – LoRa Mesh Netwerk Dordrecht

Voor en door inwoners van Dordrecht

Gestopt
Vrijdag 10 Juli 04:25:0417°87%
Taal
Thema
LoRa Mesh-netwerk

MeshCore

Kleine radio's geven berichten aan elkaar door — zonder internet, simkaart of centrale server. Off-grid communicatie voor Dordrecht & de Drechtsteden.

MeshCore is een LoRa mesh-netwerk waarmee kleine radios berichten naar elkaar doorgeven — zonder internet, zonder simkaart, zonder centrale server. Nodes vormen automatisch een netwerk en kunnen berichten via tussenliggende nodes (repeaters) over grote afstanden sturen. Denk aan off-grid communicatie, noodhulp, outdoor activiteiten of gewoon experimenteren met mesh radio. Vergeleken met systemen zoals Meshtastic kiest MeshCore voor slim pad-gebaseerd routeren in plaats van flooding, wat resulteert in minder zendtijd en efficiënter gebruik van de beschikbare bandbreedte.

MeshCore is een veelzijdig, multiplatform systeem dat veilige, tekstgebaseerde communicatie mogelijk maakt via LoRa-radiohardware. Het is ontworpen voor toepassingen zoals off-grid communicatie, noodhulp en rampenherstel, outdoor activiteiten, tactische beveiliging (inclusief wetshandhaving en particuliere beveiliging) en IoT-sensornetwerken.

Hoe werkt MeshCore?

MeshCore maakt gebruik van LoRa (Long Range) technologie, een draadloos protocol dat lage vermogens en langeafstandscommunicatie combineert. Het creëert een gedecentraliseerd mesh-netwerk waarin apparaten (nodes) berichten kunnen verzenden en doorsturen naar andere nodes zonder afhankelijk te zijn van internet of mobiele netwerken. Het protocol zelf is volledig offline bruikbaar; aanvullende diensten zoals kaarten, node-directories en firmware-hosting zijn echter wel internetgebaseerd.

Routing Protocol

MeshCore gebruikt geen flooding voor normale point-to-point berichten. In plaats daarvan werkt het met een slim routeringssysteem dat routes leert. Nodes vinden de beste paden door het mesh-netwerk en slaan deze op voor directe verzending. Flooding wordt wel gebruikt voor specifieke gevallen zoals advertisements (nodeinfo, position updates) en berichten naar algemene kanalen die voor iedereen bedoeld zijn. Client apparaten (Companion Radio's) sturen pakketten niet door, om te voorkomen dat er ongewenste routes ontstaan. Het systeem kan worden ingesteld met een maximum aantal hops (intern tot 64 hops bij 1-byte pad-hashing, 32 hops bij de aanbevolen 2-byte modus) om het netwerk efficiënt te houden en overmatig verkeer tegen te gaan. In de praktijk liggen bruikbare limieten lager door timing en omgevingsruis.

Multi-Hop Packet Routing met Path Learning

MeshCore combineert twee technieken: flooding voor ontdekking en direct routing voor alle vervolgberichten. Dat maakt het fundamenteel efficiënter dan pure flooding-protocollen zoals oudere Meshtastic-versies, met name in grote netwerken met veel repeaters.

Stap 1 — Flood routing: eerste contact

Wanneer je een bericht stuurt naar iemand van wie je nog geen route kent — een nieuw contact, of na een netwerkwijziging — verzendt je companion het als een flood. Elk pakket dat via flooding verstuurd wordt, bevat een pad-sectie die aanvankelijk leeg is. Elke repeater die het pakket ontvangt, voegt een hash van zijn eigen publieke sleutel toe aan dat pad en stuurt het door. Zo bouwt het pakket onderweg automatisch een lijst op van alle repeaters die het gepasseerd heeft, en verspreidt het bericht zich als een golf door het netwerk — maximaal 64 hops bij 1-byte hashing, 32 hops bij 2-byte.

Flooding is robuust: het werkt ook als je geen enkel idee hebt van de topologie. De keerzijde is dat elke repeater in de buurt het pakket opnieuw uitzendt, wat airtime kost en congestie kan veroorzaken. Flooding wordt daarom bewust beperkt tot ontdekking en broadcast-achtige berichten (kanaalberichten, advertenties) — niet voor elk privébericht.

Stap 2 — Delivery report en path learning

Zodra de bestemming het bericht ontvangt, stuurt hij automatisch een delivery report terug. Dat rapport bevat het volledige pad dat het originele bericht heeft afgelegd: de geordende lijst van repeater-hashes. Het delivery report maakt de terugreis ook via flooding, zodat het de afzender bereikt ongeacht de netwerktopologie.

Jouw companion slaat dit pad nu op bij dat contact. Vanaf dit moment is er een werkende route bekend — en bij het volgende bericht naar dezelfde persoon hoeft er niet meer geflood te worden.

Stap 3 — Direct routing: alle vervolgberichten

Bij elk volgend bericht naar hetzelfde contact zet je companion het opgeslagen pad expliciet in het pakket. Elke repeater onderweg voert een simpele check uit:

Alleen de repeaters op de bekende route sturen het bericht door. Alle andere repeaters in de buurt negeren het pakket volledig. Het resultaat is een gericht bericht dat langs een vaste route reist zonder onnodige rebroadcasts — een fractie van de airtime van een flood.

Automatische fallback

Netwerken veranderen. Repeaters vallen uit, signaalcondities wijzigen. Als een direct bericht herhaaldelijk niet aankomt, valt de companion automatisch terug op flooding om een nieuw pad te ontdekken. Het oude, gebroken pad wordt vervangen zodra een nieuw delivery report arriveert.

Praktijkvoorbeeld

Jij → Repeater A → Repeater B → Repeater C → Doel
  1. Eerste bericht — flood. Het pakket passeert A, B en C. Het pad [A, B, C] wordt onderweg opgebouwd.
  2. Delivery report — het doel stuurt bevestiging terug met pad [A, B, C]. Jouw companion slaat de route op.
  3. Tweede bericht — direct routing. Het pakket bevat expliciet pad [A → B → C]. Alleen A, B en C sturen door. Alle andere repeaters doen niets.

Belangrijke details

De rol van regions in routing

Regions voegen een scope-filter toe bovenop de routeringslogica. Een repeater die een pakket ontvangt, voert twee onafhankelijke checks uit:

  1. Routeringscheck — ben ik de volgende hop op het pad? (of: is dit een flood die ik mag doorsturen?)
  2. Scope-check — past de regio-tag van dit pakket bij mijn geconfigureerde regions?

Beide checks moeten slagen voordat een repeater doorstuurt. Dit heeft verschillende gevolgen afhankelijk van het berichttype:

Flood-berichten (kanaalberichten, broadcasts)

Floods die een scope-tag dragen (bijv. nl-zh) worden alleen doorgestuurd door repeaters die die scope kennen én flooding er voor toestaan via region allowf. Een bericht op scope nl-zh-dor wordt doorgestuurd door elke repeater die nl-zh-dor in zijn config heeft — maar ook door repeaters die alleen nl-zh kennen, want de hiërarchie werkt naar boven: nl-zh-dor is een kind van nl-zh.

Vanaf 13 juni 2026 (Fase 8) geldt voor repeaters met region denyf *: floods zonder scope-tag worden stilzwijgend weggegooid. Een kanaalchat zonder ingestelde scope bereikt dan alleen nog repeaters die nog geen region denyf * hebben. Stel daarom in je app per kanaal een scope in, zodat je berichten de juiste repeaters bereiken.

Direct Messages (privéberichten)

DMs gebruiken altijd een wildcard scope — ze passeren alle regiogrenzen, ook na Fase 8. Path learning werkt ongewijzigd: de geleerde route wordt gevolgd ongeacht de region-configuratie van de tussenliggende repeaters. Dit is een bewuste ontwerpkeuze: point-to-point communicatie mag nooit geblokkeerd worden door regiofiltering.

Advertenties van repeaters

Een repeater taggett zijn eigen flood-advertenties met de scope uit region default (bijv. nl-zh). Andere repeaters sturen die advertentie alleen door als ze die scope kennen. Hoe breder de region default, hoe verder de advertentie reist — en hoe zichtbaarder de repeater is voor nodes die een route willen leren. Dit is precies waarom region default nl-zh beter is dan nl-zh-dor: naburige repeaters in Papendrecht of Sliedrecht kennen nl-zh, maar kennen nl-zh-dor niet per se.

Samenvatting

BerichttypeScope-filter actief?Region denyf effect
Kanaalberichten / broadcastsJa — scope bepaalt welke repeaters forwardenZonder scope: gedropt na Fase 8
Direct Messages (DM)Nee — altijd wildcardGeen effect
Repeater advertentiesJa — region default bepaalt reikwijdteZonder scope: gedropt na Fase 8

Regions en Scope

Vanaf MeshCore versie 1.10.0 is er een systeem van regions en scope beschikbaar, waarmee je kunt bepalen hoe ver een bericht zich verspreidt door het netwerk. Dit helpt netwerkoverlast te verminderen en berichten lokaal te houden wanneer dat gewenst is. In 2026 is de firmware verder doorontwikkeld; de nieuwste versie is v1.16.0 (6 juni 2026). Zie de GitHub releases pagina voor de meest actuele versie-informatie.

Let op: Regions zijn een experimentele functie in MeshCore. De naamgeving en hiërarchie zijn nog niet volledig gestandaardiseerd en kunnen in toekomstige updates veranderen. Check de MeshCore Discord voor de laatste stand van zaken.

Een region is een geografisch gebied dat je configureert op een repeater. Elke repeater kan tot 32 regions bevatten. In Nederland wordt de ISO 3166-2:NL standaard aangehouden voor naamgeving: nl voor nationaal, nl-zh voor Zuid-Holland, nl-nh voor Noord-Holland enzovoort. Alleen kleine letters, cijfers en koppeltekens zijn toegestaan.

Regions zijn hiërarchisch van grof naar fijn. De opbouw is:

eu                          ← Europa (continent)
nl                          ← land
nl-zh                       ← provincie (ISO 3166-2)
nl-zh-dor                   ← gemeente/stad (UN/LOCODE lowercase)
nl-zh-dor-stadspolders      ← wijk of sub-regio (vrij te kiezen)

Een repeater die nl-zh-dor-stadspolders kent, accepteert ook berichten op scope nl-zh-dor, nl-zh, nl en eu — de hiërarchie werkt naar boven toe automatisch door. Andersom geldt dat ook: wie scope nl-zh instelt bereikt alle repeaters in Zuid-Holland die nl-zh hebben geconfigureerd, ongeacht of ze ook wijkniveaus kennen.

Naast de stads- en wijkhiërarchie kunnen lokale communities eigen samenwerkingscodes toevoegen, zoals nl-zh-drechtsteden voor de Drechtsteden-regio. Die staat op hetzelfde niveau als nl-zh-dor (beiden kind van nl-zh), maar groepeert meerdere gemeenten. Wie scope nl-zh-drechtsteden gebruikt bereikt alle repeaters in Dordrecht, Sliedrecht, Papendrecht, Alblasserdam, Hendrik-Ido-Ambacht en Zwijndrecht die deze code kennen — ook al liggen die gemeenten elk in hun eigen LOCODE-tak.

De scope stel je in op je companion device, per kanaal en zelfs per bericht. Repeaters sturen standaard alles door (wildcard *), maar zodra je een scope instelt matcht de repeater alleen berichten die overeenkomen met zijn geconfigureerde regions. Dit is handig als je bewust lokaal wil communiceren zonder het hele netwerk te belasten.

In je companion app kun je per kanaal een region scope instellen. Stel je voor kanaal #dordrecht de scope in op nl-zh-dor, dan worden berichten op dat kanaal alleen doorgestuurd door repeaters die nl-zh-dor kennen — de conversatie blijft lokaal zolang de repeaters in de regio correct geconfigureerd zijn en flood is toegestaan voor die scope.

Directe berichten (DM's) kennen geen scope — die gebruiken altijd de wildcard en passeren alle regionsgrenzen, zodat point-to-point communicatie altijd werkt ongeacht de regio-indeling.

Regio-configuratie in Dordrecht en Drechtsteden

In en om Dordrecht zijn meerdere MeshCore-repeaters actief. De repeater in Dordrecht Oost (wijk Stadspolders) heeft de volgende region-configuratie:

region put eu
region put nl eu
region put nl-zh nl
region put nl-nb nl
region put nl-zh-dor nl-zh
region put nl-nb-wkd nl-nb
region put nl-zh-a2z nl-zh
region put nl-zh-pap nl-zh
region put nl-zh-sld nl-zh
region put vr-vrzhz nl
region put nl-zh-drechtsteden nl-zh
region put nl-zh-dor-stadspolders nl-zh-dor

region allowf eu
region allowf nl
region allowf nl-zh
region allowf nl-nb
region allowf nl-zh-dor
region allowf nl-nb-wkd
region allowf nl-zh-a2z
region allowf nl-zh-pap
region allowf nl-zh-sld
region allowf vr-vrzhz
region allowf nl-zh-drechtsteden
region allowf nl-zh-dor-stadspolders

region default nl-zh
region save

Deze configuratie dekt meerdere geografische lagen:

RegioCodeToelichting
EuropaeuContinentaal topniveau — nl is kind van eu
NederlandnlLandniveau
Zuid-Hollandnl-zhEigen provincie
Noord-Brabantnl-nbBuurprovincie direct over de rivier (Hollands Diep)
Dordrechtnl-zh-dorEigen gemeente
Papendrechtnl-zh-papNaburige gemeente in Zuid-Holland
Sliedrechtnl-zh-sldNaburige gemeente in Zuid-Holland
Oud-Alblasnl-zh-a2zNaburige gemeente in Zuid-Holland
Werkendamnl-nb-wkdNaburige gemeente in Noord-Brabant, over de Hollands Diep
VR Zuid-Holland Zuidvr-vrzhzVeiligheidsregio — voor DARES en noodcommunicatie
Drechtstedennl-zh-drechtstedenCommunity-regio die Dordrecht, Sliedrecht, Papendrecht, Alblasserdam, H-I-Ambacht en Zwijndrecht bundelt
Stadspoldersnl-zh-dor-stadspoldersWijk in Dordrecht Oost — lokaalste scope

region default nl-zh stelt Zuid Holland in als thuisregio voor advertenties van de repeater zelf. region save slaat de configuratie op — zonder dit verdwijnen alle instellingen bij een reboot.

MeshCore Regio Generator

Het handmatig invoeren van de juiste region put en region allowf commando's voor een repeater is foutgevoelig, zeker als je ook naburige steden wil opnemen. Op TechSpeeltuin is daarom een interactieve Regio Generator beschikbaar:

Veiligheidsregio's

Nederland is verdeeld in 25 veiligheidsregio's — samenwerkingsverbanden van gemeenten voor brandweer, GHOR en crisisbeheersing. In MeshCore worden deze regio's gebruikt als extra scope-laag voor DARES (Dutch Amateur Radio Emergency Service) en noodcommunicatie in het algemeen.

Een repeater die een veiligheidsregio in zijn configuratie heeft, stuurt berichten met die scope door — ook als die berichten van buiten de eigen gemeente of provincie komen. Dat is nuttig omdat veiligheidsregio's provinciegrenzen kunnen doorsnijden: vr-vrzhz (Zuid-Holland Zuid) omvat bijvoorbeeld Dordrecht, maar ook Gorinchem en gemeenten in Noord-Brabant die bestuurlijk bij deze regio horen.

Naamgeving en parent

Veiligheidsregio-codes beginnen met vr- gevolgd door de Brandbase-afkorting in kleine letters — zie de tabel hieronder. Als parent geldt altijd nl (landniveau), niet de provincie, omdat veiligheidsregio's geen subonderdeel zijn van één provincie.

region put vr-vrzhz nl
region allowf vr-vrzhz

Wanneer toevoegen?

Voeg de veiligheidsregio toe als je repeater in of nabij dat gebied staat. Zit je dicht bij een grens tussen twee veiligheidsregio's? Voeg dan ook de aangrenzende regio toe — zo bereik je ook noodnetwerkers aan de andere kant van die grens.

Alle 25 veiligheidsregio's

CodeNaamProvincie(s)
vr-hvdgGroningennl-gr
vr-vrfFrieslandnl-fr
vr-vrdDrenthenl-dr
vr-vrijIJssellandnl-ov
vr-vrtTwentenl-ov
vr-vnogNoord- en Oost-Gelderlandnl-ge
vr-vggmGelderland-Middennl-ge
vr-vrgzGelderland-Zuidnl-ge
vr-vruUtrechtnl-ut
vr-vrnhnNoord-Holland Noordnl-nh
vr-vrzwZaanstreek-Waterlandnl-nh
vr-vrkKennemerlandnl-nh
vr-vraaAmsterdam-Amstellandnl-nh
vr-vrgvGooi en Vechtstreeknl-nh / nl-ut
vr-vrhHaaglandennl-zh
vr-vrhmHollands Middennl-zh
vr-vrrRotterdam-Rijnmondnl-zh
vr-vrzhzZuid-Holland Zuidnl-zh
vr-vrzZeelandnl-ze
vr-vrmwbMidden- en West-Brabantnl-nb
vr-vrbnBrabant-Noordnl-nb
vr-vrbzoBrabant-Zuidoostnl-nb
vr-vrlnLimburg-Noordnl-li
vr-vrzlZuid-Limburgnl-li
vr-vrflFlevolandnl-fl

Regio Generator met automatische detectie

De Regio Generator detecteert je veiligheidsregio automatisch op basis van je GPS-locatie of geselecteerde stad, en toont ook de direct aangrenzende regio's gemarkeerd als Aangrenzend. Je kiest zelf welke je wilt opnemen — zo voeg je in één stap de juiste vr- codes toe aan je repeater-config.

Hardware & Firmware Types

Gebruikers kunnen MeshCore-firmware installeren op compatibele LoRa-hardware, zoals:

MeshCore biedt vier hoofdfirmware-types:

1. Companion Firmware

Verbindt met een externe client via BLE (standaard), USB Serial of WiFi TCP. Dit is de standaard voor de meeste gebruikers: de node doet alleen de radio-communicatie, terwijl de MeshCore mobiele app (Android/iOS) of web/desktop-app als interface dient. Er bestaan twee firmware-varianten: de gewone BLE+Serial build en een USB-Serial-only variant voor hardware zonder BLE-ondersteuning of bij aansluiting op een vaste computer.

2. Repeater Firmware

Breidt het netwerk uit door berichten automatisch door te sturen op basis van de embedded path-informatie. Werkt volledig autonoom — geen telefoon nodig. Stuurt periodiek flood-adverts (met instelbaar interval) om zichzelf bekend te maken, maar probeert airtime zo laag mogelijk te houden.

3. Room Server Firmware

Fungeert als een soort BBS (Bulletin Board System): slaat berichten op in rooms/kanalen zodat clients ze later kunnen ophalen (store-and-forward). Ondersteund op T-Deck en (vanaf app v1.38+) ook via BLE-companions en mobiele apps. Ondersteunt guest passwords, admin-rechten en QR-code toegang, en kan remote beheerd worden via een T-Deck of BLE-companion.

4. T-Deck Direct / Terminal Firmware

Maakt van een T-Deck een volledig standalone apparaat met terminal-achtige interface — directe messaging zonder smartphone-app. Handig voor fixed installaties of als backup. Sommige community-varianten (zoals MeshOS) bieden extra features zoals maps en remote admin, die soms een betaalde unlock-key vereisen.

Praktische opmerkingen: Repeater en Room Server firmware kunnen op dezelfde hardware draaien (je kiest bij het flashen). Companion + Repeater combinaties zijn technisch mogelijk, maar voor betere prestaties worden ze doorgaans op aparte hardware gedraaid. De web-flasher maakt het eenvoudig om het juiste firmwaretype te kiezen en te installeren.

Gebruikersinterface & Clients

Communicatie met het MeshCore-netwerk verloopt via verschillende clients en platforms:

Mobiele apps — De officiële Android- en iOS-app (gratis). Biedt chat, kanaalbeheer, node-kaart, path-visualisatie en experimentele instellingen. De meest gebruikte manier voor dagelijks gebruik.

Web client — Werkt in Chrome/Edge, ook offline zodra verbonden met een companion via BLE of WiFi. Handig als desktopinterface of als je geen app wil installeren. Beschikbaar via meshcore.io/client.html.

Seriële / Terminal console — Directe CLI-toegang via USB voor gevorderde configuratie van repeaters en room servers, troubleshooting en het instellen van regio's, TX power en firmware-parameters.

Standalone apparaten — De LilyGo T-Deck (en T-Deck Plus) functioneren als volledig zelfstandige terminals met eigen scherm, toetsenbord en MeshCore-firmware — app-vrij en zonder smartphone.

MQTT & automatisering — Via community-tools zoals LetsMesh of een eigen MQTT-bridge kun je MeshCore koppelen aan Home Assistant, Node-RED of eigen scripts. Hiermee zijn monitoring (repeater-status, signaalwaarden) en integraties mogelijk zonder zelf berichten te sturen over het radionetwerk.

Bekijk de MeshCore Software pagina voor een overzicht van actuele firmware-versies, apps en release-notes.

Bots en Geautomatiseerde Berichten

Waarom bots een probleem zijn

LoRa heeft van nature een extreem beperkte bandbreedte en strenge duty cycle-regels (sub-band P: ≤ 10% zendtijd per uur). Elke zending — ook een geautomatiseerde — kost airtime die anderen niet meer kunnen gebruiken. In een groeiend netwerk zoals het Nederlandse mesh leidt dit direct tot:

Bots die regelmatig berichten sturen — weerstations, quote-bots, ping-bots, periodieke status-updates — zijn om deze reden onwenselijk in gedeelde kanalen.

Wat is soms wél acceptabel?

Niet alle automatisering is per definitie problematisch. Toepassingen die zeer zelden zenden (intervallen van uren, niet minuten) en geen gedeelde kanalen vervuilen kunnen verantwoord zijn:

Region scoping als mitigerende factor

Region scoping biedt een belangrijk middel om de impact van geautomatiseerde berichten te beperken. Door een nauwe scope in te stellen — bijvoorbeeld nl-zh-dor voor Dordrecht of nl-zh voor Zuid-Holland — worden berichten alleen doorgestuurd door repeaters in dat gebied. Het verkeer blijft lokaal en cascadeert niet door het hele netwerk.

Dit maakt sommige toepassingen acceptabeler dan ze zonder scoping zouden zijn: een weerstation dat elk uur een update stuurt op scope nl-zh-dor belast alleen de lokale repeaters, niet het landelijke mesh. Hoe smaller de scope, hoe kleiner de impact.

Scoping is dan ook geen vrijbrief voor hoge zendfrequentie — de lokale duty cycle en airtime zijn net zo eindig als die van het grotere netwerk. Maar het is wél een relevante factor bij de afweging.

Praktische richtlijnen

Doel van MeshCore

Het doel van MeshCore is het bieden van een betrouwbare, veilige en efficiënte communicatieoplossing voor situaties waarin traditionele infrastructuur ontbreekt of onbetrouwbaar is. De missie is om een gedecentraliseerd mesh-radiosysteem te ontwikkelen dat toegankelijk is voor iedereen, met een sterke focus op beveiliging en lage energieconsumptie, ideaal voor batterij- of zonne-energiegevoede apparaten.

Belangrijke Kenmerken

MeshCore onderscheidt zich van andere LoRa-systemen op de volgende punten:

Gedecentraliseerd en robuust

Het MeshCore-protocol heeft geen centrale server of internet nodig; het netwerk is zelfherstellend en blijft functioneren, zelfs als nodes uitvallen. Veel tools rondom het ecosysteem (kaarten, dashboards, node-directories) zijn echter wél centraal gehost en vereisen internetverbinding.

Laag Energieverbruik

Ideaal voor apparaten op batterijen of zonne-energie, dankzij efficiënte LoRa-modulatie met SF7 en BW 62.5 kHz configuratie. Batterijen gaan dagen tot weken mee, ideaal voor noodsituaties.

Eenvoudig te Implementeren

Configureerbare Netwerk Parameters

Beveiliging & Encryptie

MeshCore implementeert een robuust tweelaagsysteem voor beveiliging:

Identiteit & Sleutelbeheer

Message Encryption

Privacy Features

Frequentiegebied en Configuratie (Nederland)

Nederland valt binnen de Europese regelgeving voor licentievrije SRD-banden (Short Range Devices). De band 863–870 MHz is opgedeeld in sub-banden met elk eigen limieten voor vermogen en duty cycle, vastgelegd in ETSI EN 300 220-2 Annex B:

Sub-bandFrequentiebereikMax. ERPMax. Duty CycleOpmerkingen
K863 – 865 MHz25 mW0,1%Zeer beperkt
L865 – 868 MHz25 mW1%Standaard voor veel LoRa
M868 – 868,6 MHz25 mW1%Vaak gebruikt (bijv. 868.1 / 868.3 / 868.5 MHz)
O868,6 – 868,7 MHz25 mW1%Alarm-toepassingen; niet voor general purpose LoRa
N868,7 – 869,2 MHz25 mW0,1%Zeer beperkt
P869,4 – 869,65 MHz500 mW10%Meest gebruikt in NL MeshCore (869.618 MHz) — hoogste duty cycle + hoger vermogen
Q869,7 – 870 MHz25 mW1%Beperkt

Duty cycle = percentage van de tijd dat je mag zenden (gemeten over 1 uur).
0,1% ≈ max. 86 sec/dag · 1% ≈ max. 864 sec/dag · 10% ≈ max. 8.640 sec/dag

Sub-band P is de NL-keuze voor MeshCore omdat het zowel het hoogste zendvermogen (500 mW ERP) als de ruimste duty cycle (10%) biedt, wat essentieel is voor een mesh-repeater die regelmatig doorgeeft.

Met een bandbreedte van 62,5 kHz (narrowband) passen er theoretisch 4 kanalen in de 250 kHz brede sub-band P:

KanaalBereikMiddenGebruik
1869,400 – 869,4625 MHz869,4313 MHz—
2869,4625 – 869,525 MHz869,4938 MHz—
3869,525 – 869,5875 MHz869,5563 MHz—
4869,5875 – 869,650 MHz869,6188 MHzNL MeshCore (869,618 MHz)

De Nederlandse community heeft kanaal 4 gekozen — het zit vrijwel exact op het theoretische midden van dat slot.

Nederlandse MeshCore Instellingen

Op 9 mei 2026 is de Nederlandse MeshCore-community overgestapt op een nieuw radiopreset. De huidige standaardinstellingen zijn:

Deze instellingen zijn de community-preset Netherlands (SF7/CR5) en vallen binnen sub-band P (869.4–869.65 MHz) volgens ETSI EN 300 220-2 V3.3.1 (2025-03) regelgeving. Zie de sectie The Change voor de volledige achtergrond en het verschil met de vorige preset.

Let op: niet alle repeaters zijn al omgeschakeld — en sommige willen dat (voorlopig) ook niet. Controleer altijd welke preset de repeaters in jouw buurt gebruiken voordat je zelf omschakelt. Een node op SF7 en een repeater op SF8 horen elkaar simpelweg niet. Kijk op Cornmeister.nl of MC Radar voor de actuele status van repeaters in jouw regio.

TX Delay

TX Delay bepaalt hoe lang een repeater wacht voordat hij een ontvangen packet opnieuw uitzendt. De waarde (in seconden) werkt als een basisfactor die vermenigvuldigd wordt met de time-on-air van het packet, waarna een willekeurige component wordt opgeteld. Die spreiding voorkomt dat meerdere repeaters tegelijk hetzelfde packet doorsturen en zo elkaars signaal blokkeren.

TX DelayWanneer gebruiken?Aandachtspunt
0Weinig repeaters, open gebied, lage dichtheidGrote kans op collisions bij meerdere repeaters
0.5Aanbevolen standaard — goede balans voor de meeste installatiesKans op botsing bij 4+ repeaters die elkaar goed horen
1.0Dichte opstelling: repeaters horen elkaar goed (hilltop, stadscentrum)Iets langzamere propagatie door het mesh
1.5Nog steeds veel dubbele packets ondanks 1.02–4+ seconden extra vertraging per hop
2.0+Extreme gevallen of bewust trage propagatieNetwerk voelt traag aan; zelden nodig

Praktische richtlijnen:

Samenvatting: weinig overlap? → 0 of 0.5 · normale situatie? → 0.5 · veel repeaters die elkaar goed horen? → 1.0 tot 1.5, bij voorkeur verschillend per repeater.

Troubleshooting — repeater wordt 'doof': SX1262-chips (Heltec, RAK) kunnen na verloop van tijd ophouden met ontvangen door AGC-drift. Stel in: set agc.reset.interval 4 (seconden; geldige waarden zijn veelvouden van 4: 4, 8, 12 …) om de AGC periodiek te resetten. Dit lost het meest voorkomende "repeater hoort niets meer"-probleem op.

Flood Advert Interval

Een repeater kondigt zichzelf periodiek aan via een flood advertisement — een pakket dat door het hele netwerk vloeit en andere nodes vertelt dat deze repeater bestaat en via welk pad hij bereikbaar is. Hoe vaker die advertentie verstuurd wordt, hoe meer airtime er verbruikt wordt, ook door alle repeaters die het pakket doorgeven.

In mei 2026 telt het Nederlandse netwerk meer dan 2.000 actieve repeaters (live kaart). Als die allemaal elke 3 uur adverteren, zijn dat ruim 650 flood adverts per uur — elk pakket reist door tientallen repeaters en wordt bij elke stap opnieuw uitgezonden. De beschikbare airtime is eindig; op drukke momenten is congestie dan geen uitzondering maar het gevolg. De Nederlandse community hanteert daarom een minimumrichtlijn van 50 uur voor het flood advert interval.

Er zijn twee aparte interval-instellingen:

InstellingBeschrijvingAanbevolen waarde
set flood.advert.intervalHoe vaak de repeater een flood advert verstuurt — reist door het hele netwerk50 uur
set zerohop.advert.intervalHoe vaak een zero-hop (direct) advert wordt verstuurd — alleen voor directe buren, reist niet door het mesh240 min (4 uur)

Zero-hop advertenties zijn minder belastend voor het netwerk omdat ze niet doorgegeven worden, maar ook zij tellen mee voor de lokale airtime. De waarde van 4 uur is een goede balans tussen zichtbaarheid voor directe buren en airtime-verbruik.

Praktische richtlijnen:

Samenvatting: gebruik set flood.advert.interval 50 en set zerohop.advert.interval 240 als standaard. Lagere waarden belasten het netwerk onnodig, zonder merkbaar voordeel voor de gebruiker.

Airtime Factor

De Airtime Factor bepaalt met welke wegingsfactor de repeater zijn eigen zendtijd berekent ten opzichte van de beschikbare duty cycle. De firmware houdt bij hoeveel tijd er al besteed is aan zenden (TX air time) en past het gedrag hierop aan — de airtime factor schaalt die berekening.

Concreet: bij factor 1.0 gebruikt de repeater de volledige toegewezen zendtijd als-is. Bij een lagere waarde wordt de berekende TX-tijd zwaarder meegeteld, waardoor de repeater eerder "vol" is en pakketten laat vallen om binnen de duty cycle te blijven. Bij een hogere waarde wordt minder streng bijgehouden — nuttig als je weet dat je repeater minder druk belast wordt dan de firmware inschat.

Airtime FactorEffectWanneer gebruiken?
< 1.0Conservatiever — repeater houdt meer marge aanDrukke locatie, veel naburige repeaters, wil zeker binnen duty cycle blijven
1.0Standaard — duty cycle wordt exact gevolgdVrijwel altijd de juiste keuze
> 1.0Toleranter — duty cycle-limiet wordt soepeler toegepastAlleen als je zeker weet dat de firmware de belasting stelselmatig overschat

Praktische richtlijnen:

Samenvatting:1.0 is de standaard en werkt in vrijwel alle situaties correct. Pas alleen aan als je de precieze impact begrijpt en de duty cycle actief monitort.

Loop Detection

In een mesh-netwerk kan een pakket in theorie blijven rondreizen: repeater A stuurt door naar B, B naar C, C stuurt het terug naar A. Loop detection voorkomt dit door een pakket te weigeren als de eigen hash al in het pad zit, of als het pad eerder al gezien is.

MeshCore biedt drie niveaus:

NiveauGedragWanneer gebruiken?
offGeen lusdetectie — pakketten worden altijd doorgestuurdNiet aanbevolen; leidt tot airtime-verspilling bij netwerklussen
minimalAanbevolen — weert pakketten waarvan de eigen hash al in het pad voorkomtGoede balans: voorkomt lussen, staat redundante paden toe
strictWeert ook pakketten die de repeater al eerder forwarde (recent-seen cache)Drukke omgeving met veel flooding; risico op verlies van legitieme pakketten

Bij minimal controleert de repeater uitsluitend of zijn eigen hash al in het pakket-pad staat. Staat hij er al in, dan is het pakket eerder via hem gelopen en wordt het gedropt. Bij strict wordt bovendien een recent-seen buffer bijgehouden van alle doorgegeven pakket-hashes — elk pakket dat al eens gezien is, wordt geweigerd, ook als het via een andere route binnenkomt.

Praktische richtlijnen:

Samenvatting:set loop.detect minimal voor vrijwel elke installatie. Schakel strict alleen in als minimal onvoldoende blijkt en je bewust de trade-off accepteert.

Multi-byte Path Hash (pad-hashing)

Elk pakket in MeshCore bevat een pad — een lijst van de repeaters die het bericht al gepasseerd heeft. Iedere repeater in dat pad wordt geïdentificeerd door een hash van zijn publieke sleutel. Hoe lang die hash is, bepaalt hoeveel repeaters uniek te onderscheiden zijn én hoeveel hops een pakket maximaal kan maken.

Het probleem met 1 byte (origineel)

In het originele protocol werd slechts 1 byte (8 bits) van de publieke sleutel gebruikt als repeater-ID. Dat levert maximaal 254 unieke ID's op (waarden 00 en FF zijn gereserveerd). In een klein netwerk is dat voldoende, maar naarmate het Nederlandse mesh groeide ontstond er een probleem: meerdere repeaters kunnen dezelfde eerste byte in hun publieke sleutel hebben. Het mesh stuurt pakketten gewoon door — forwarding werkt correct — maar analysetools zoals LetsMesh.net Analyzer en MeshMapper kunnen repeaters niet meer uniek identificeren. Padanalyse wordt onbetrouwbaar; het is puur een diagnostiek-probleem.

Multi-byte hashing (firmware v1.14+)

Vanaf firmware v1.14 kunnen repeaters en companion-apparaten pakketten versturen met een 2- of 3-byte pad-hash. De path-sectie van een LoRa-pakket heeft een maximale omvang van circa 64 bytes — een langere hash per repeater betekent dus minder hops mogelijk:

Hash-grootteUnieke IDsMax. hopsCLI-waarde (repeater)
1 byte (origineel)25464 hopsset path.hash.mode 0
2 bytes(aanbevolen)65.53432 hopsset path.hash.mode 1
3 bytes~16,7 miljoen21 hopsset path.hash.mode 2

Belangrijk:path.hash.mode bepaalt uitsluitend de hash-grootte van de eigen advertenties van de repeater. Het heeft geen invloed op welke pakketten de repeater doorstuurt — een repeater met v1.14+ stuurt altijd 1-, 2- én 3-byte pakketten door.

Waarom 2 bytes?

Backward compatibility

Repeaters met firmware ouder dan v1.14 verwerpen 2- en 3-byte pakketten stilzwijgend. Er zijn twee aparte instellingen:

Repeater — stel path.hash.mode 1 direct in via de CLI. Dit geldt alleen voor eigen advertenties en is altijd veilig:

set path.hash.mode 1

Companion (app) — de hash-grootte voor berichten en kanaalberichten stel je in via Instellingen → Experimentele Instellingen → Default Path Hash Size. Schakel dit pas om naar 2 bytes als de overgrote meerderheid van de repeaters in jouw regio op v1.14+ draait — pre-1.14 repeaters laten deze berichten anders stilzwijgend vallen.

De Nederlandse community heeft dit als onderdeel van The Change (9 mei 2026) opgenomen in de voorbereidingsstappen.

Regelgeving Sub-band P

Frequentiebereik: 869.4-869.65 MHz
Maximaal vermogen: 500 mW ERP (*) (+27 dBm)
Duty cycle: ≤ 10% of LBT + AFA (Listen Before Talk + Adaptive Frequency Agility)
Regulering: ETSI EN 300.220, RDI

Sub-band P biedt aanzienlijk hogere zendvermogens (500 mW ERP) vergeleken met de standaard sub-banden (25 mW), waardoor grotere dekking mogelijk is. Dit maakt het bijzonder geschikt voor repeater/gateway implementaties. De duty cycle van 10% is ruimer dan de 1% beperking voor andere sub-banden — maar het betekent ook dat je dit vermogen niet continu mag gebruiken. Bij intensief gebruik (hoge packet-frequentie of lange time-on-air) moet je de duty cycle actief bewaken om binnen de regelgeving te blijven.

Juridische Status Nederland

Het gebruik van 869.618 MHz is volledig legaal in Nederland en de EU, zolang wordt voldaan aan:

Nederlandse rechtsgrond

Licentievrij gebruik van de ISM-band (863–870 MHz) is in Nederland geregeld in het Besluit gebruik van frequentieruimte zonder vergunning 2015 en de bijbehorende Regeling gebruik van frequentieruimte zonder vergunning en zonder meldingsplicht 2015. Deze wetgeving vormt de juridische basis voor vergunningvrij zenden. Voor de technische eisen (zendvermogen, duty cycle, frequentiestabiliteit etc.) verwijzen zij naar de geharmoniseerde Europese norm ETSI EN 300 220-2 V3.3.1.

Rijksinspectie Digitale Infrastructuur (RDI)

De RDI is de toezichthouder. Zij handhaaft de regels en geeft praktische richtlijnen, maar is niet de rechtsgrond. Het recht om zonder vergunning te zenden ontleen je uitsluitend aan het Besluit en de Regeling, niet aan de RDI-richtlijnen.

Voor het gebruik van 869,618 MHz is dus geen vergunning of melding nodig, mits voldaan wordt aan de voorwaarden uit het Besluit/Regeling en ETSI EN 300 220.

Antennes en Effectief Uitgestraald Vermogen (ERP)

Het maximaal toegestane vermogen van 500 mW ERP (+27 dBm) op 869.618 MHz is niet hetzelfde als het zendvermogen van je apparaat. Het ERP wordt berekend volgens de formule:

ERP = Zendvermogen - Kabelverliezen + Antenne Gain

Antennetypes in de praktijk

Gain versus openingshoek

Antennegain is geen echte versterking — het is concentratie. Een antenne met hogere gain "knijpt" het stralingsveld samen in één richting, ten koste van de andere richtingen. Hoe hoger de gain, hoe smaller de bundel:

GainVerticale openingshoek (ca.)Typisch gebruik
0 – 2 dBi75° – 90°Handheld companion, korte afstanden
3 – 5 dBi45° – 60°Standaard repeater, stedelijk gebied
6 – 8 dBi20° – 35°Repeater op hoogte, vlak terrein
9 – 12 dBi10° – 18°Hilltop / lange afstand omni
13+ dBi (Yagi/panel)5° – 12°Punt-naar-punt verbinding

Een omnidirectionele antenne straalt in de horizontale vlak altijd 360° — maar de verticale openingshoek wordt smaller naarmate de gain toeneemt. Het stralingsveld lijkt op een frisbee: hoge gain = dunnere frisbee.

Wanneer welke antenne?

Lage gain omni (0–5 dBi) — gebruik bij:

Hoge gain omni (6–12 dBi) — gebruik bij:

Let op bij hoge gain omni op hoogte: hoe hoger de gain, hoe groter de kans dat nodes die dichtbij en laag staan buiten de bundel vallen. Een repeater op 30 meter hoogte met een 10 dBi antenne kan moeite hebben om een node op straatniveau op 100 meter afstand te bereiken — die valt in het "gat" recht onder de antenne.

Richtantenne / Yagi / panel (13+ dBi) — gebruik bij:

Keuzehulp: stel jezelf deze vragen

  1. Hoe hoog staat de repeater? Hoog geplaatst + vlak terrein → hogere gain omni is zinvol. Laag of in bebouwing → lage gain omni geeft betere algehele dekking.
  2. Waar bevinden de nodes zich? Rondom in alle richtingen → omni. Voornamelijk in één richting → richtantenne.
  3. Hoe dicht zijn de dichtstbijzijnde nodes? Nodes dicht in de buurt (< 500 m) + hoge gain → risico op "dode zone" onder de antenne. Kies dan lagere gain of kantel de antenne licht.
  4. Wat is het doel? Maximaal bereik in één richting → Yagi/panel. Zo veel mogelijk nodes in de omgeving bedienen → omni.
  5. Wat is het ERP-budget? Een 10 dBi antenne op een radio met 22 dBm zendvermogen zit al op de limiet van 27 dBm ERP. Hogere gain dwingt je het zendvermogen te verlagen.

Companion devices vs. repeaters

Companion devices (handheld, mobiel):

Repeaters (vast opgesteld):

Technische Parameters

De Nederlandse preset gebruikt BW 62.5 kHz (narrowband) — ongewijzigd vóór en na The Change. Wat wél verandert op 9 mei 2026 is de spreading factor en coding rate. Hieronder een directe vergelijking:

ParameterVóór 9 mei (SF8/CR8)Na 9 mei (SF7/CR5)Verschil
Spreading FactorSF8SF71 stap lager
Coding RateCR8 (4/8)CR5 (4/5)Minder redundantie
Bandbreedte62.5 kHz62.5 kHzOngewijzigd
Netto datarate~0.98 kbit/s~2.73 kbit/s2.8× sneller
Time-on-air (50-byte pakket)~510 ms~180 ms2.8× korter
Pakketten/uur (10% duty cycle)~700~2.0002.8× meer capaciteit
Ontvanggevoeligheid−132 dBm−129 dBm~3 dB minder gevoelig
Foutcorrectie overhead50%20%Minder robuust
Maximaal bereik (vrij veld)~100% (referentie)~85%Licht minder bereik

Wat betekent dit in de praktijk?

Spreading Factor — het hart van de wijziging

De spreading factor bepaalt hoeveel symbolen er per bit gebruikt worden. SF8 gebruikt 2⁸ = 256 chips per symbool, SF7 gebruikt 2⁷ = 128 chips. Die factor 2 is direct terug te zien in de time-on-air: een pakket op SF7 is ruwweg half zo lang in de lucht als op SF8. Elk pakket dat korter duurt, maakt meer ruimte voor andere pakketten op hetzelfde kanaal — precies wat een overbelast mesh nodig heeft.

Coding Rate — minder verpakking, meer inhoud

De coding rate bepaalt de verhouding tussen nuttige data en foutcorrectiebits. CR8 (4/8) voegt voor elke 4 databits 4 controlbits toe — 50% overhead, maximale bescherming. CR5 (4/5) voegt slechts 1 controlbit toe per 4 databits — 20% overhead. Dat scheelt 30% aan "verspilde" zendtijd per pakket. In een rustige, goed-opgezette mesh is de lagere foutcorrectie geen probleem: de kans op een bitfout is laag genoeg dat CR5 ruimschoots voldoet.

Gevoeligheid en bereik

Elke SF-stap omlaag kost circa ~3 dB ontvanggevoeligheid (bron: SX1262 datasheet en The Switch — meshwiki.nl). Dit vertaalt zich in een iets kleiner maximaal bereik onder marginale omstandigheden (~15% minder). In de praktijk is dit nauwelijks merkbaar: een goed geplaatste repeater op SF7 bereikt nog altijd dezelfde nodes als op SF8, omdat de meeste verbindingen ruim boven de minimale signaallimiet zitten. Het Nederlandse mesh kiest bewust voor capaciteit boven maximaal bereik.

Het netto effect: 2.8× meer ruimte in het netwerk

Kortere time-on-air + minder foutcorrectiebits samen leveren bijna drie keer zoveel beschikbare pakkettencapaciteit op binnen dezelfde 10% duty cycle. Dat lost het congestieprobleem structureel op.

Typisch bereik (ongewijzigd):

SituatieBereik
Open veld, line-of-sight, hoog geplaatst10+ km
Bebouwde omgeving / handheld1–5 km realistisch
Via repeater-ketenHonderden km (hop voor hop)

Licentie & Ontwikkeling

De MeshCore-firmware is open-source uitgebracht onder de MIT License, vrij te gebruiken, modificeren en distribueren. Niet alle apps en tools rondom het ecosysteem zijn volledig open source — sommige companion-apps en premium features zijn closed source of vereisen een licentie. Het project wordt actief ontwikkeld door de community, met discussies en ondersteuning beschikbaar via:

Sommige premium features (zoals ESP-NOW bridge licentie) zijn beschikbaar om de ontwikkeling van het project te financieren.

Aan de slag (video)

Volg ook zeker het kanaal van Andy Kirby voor meer informatie over MeshCore.

Achtergrond: Andy Kirby was een prominent lid van het MeshCore-team en maakte populaire instructievideo's. In april 2026 diende hij echter zonder medeweten van de rest van het team een trademark-aanvraag in voor de naam "MeshCore". Daarop besloot het kernteam zelfstandig verder te gaan onder meshcore.io. De technische inhoud van zijn video's is nog steeds bruikbaar, maar zijn site meshcore.co.uk valt niet onder het officiële project. Zie Projectsplit (april 2026) voor de volledige achtergrond.

ERP Calculator

ERP Calculator

of
m
dB
× 0.15 dB/stuk

⚡ Vermogen Calculator van dBm naar (m)W (en vice versa)

⇄

dB, dBi en dBm — wat is het verschil?

TermWat het isWanneer gebruik je het
dBDecibel — een relatieve verhoudingVerlies of versterking: "3 dB verlies = signaal gehalveerd"
dBmdB t.o.v. 1 milliwatt — absoluut vermogenZendvermogen: "20 dBm = 100 mW"
dBidB t.o.v. een isotrope stralerAntennegain: "5 dBi = antenne bundelt 3× meer dan een bolstraler"
dBddB t.o.v. een halve-golf dipoolAlternatieve gain-meting: 1 dBd = 2.15 dBi (dipool heeft zelf al 2.15 dBi gain)

Vuistregel voor dB (vermogen): dB is een verhouding, geen vaste hoeveelheid. Elke +3 dB verdubbelt het vermogen (×2) en elke −3 dB halveert het (÷2); +10 dB is 10× zoveel vermogen en −10 dB nog maar een tiende (÷10). Voorbeeld: +6 dB = ×4 (2× verdubbelen), −6 dB = ÷4.

Omdat dB een logaritmische schaal is, tel je dB-waarden op in plaats van te vermenigvuldigen. Dat is precies waarom de ERP-formule werkt met optellen en aftrekken:

ERP (dBm) = Zendvermogen (dBm) − Kabelverliezen (dB) + Antennegain (dBi)

Het maximaal toegestane vermogen van 500 mW ERP (+27 dBm) op 869.618 MHz is niet hetzelfde als het zendvermogen van je apparaat.

Uitleg van de componenten

Zendvermogen (TX Power)
Het vermogen dat je radio uitzendt, meestal instelbaar in de firmware. De meeste MeshCore-hardware (Heltec, RAK, LilyGO) zendt typisch tot max 22 dBm (158 mW), afhankelijk van het model.

Kabelverliezen
Verliezen in de coaxkabel tussen radio en antenne. Deze zijn afhankelijk van:

Antenne Gain

De "versterking" van de antenne ten opzichte van een isotrope antenne (dBi). Let op:

Praktijkvoorbeelden

Voorbeeld 1: Companion device met korte kabel

Voorbeeld 2: Repeater met richtantenne

Voorbeeld 3: Repeater met lange kabellengte

Belangrijke tips

  1. Minimaliseer kabelverliezen: Gebruik zo kort mogelijke kabel van goede kwaliteit
  2. Berekentools: Gebruik online dBm/mW calculators voor nauwkeurige berekeningen
  3. Meetapparatuur: Bij twijfel kun je het daadwerkelijke ERP laten meten door een specialist
  4. Veiligheidsmarge: Blijf liever onder de 27 dBm limiet om zeker binnen de wet te blijven
  5. Documentatie: Noteer je configuratie (zendvermogen, kabeltype/lengte, antenne) voor controles

Verantwoordelijkheid

Het is de verantwoordelijkheid van de gebruiker om ervoor te zorgen dat het totale uitgestraalde vermogen binnen de wettelijke limieten blijft. Bij controle door het RDI wordt het daadwerkelijk uitgestraalde vermogen gemeten, niet alleen het zendvermogen van het apparaat.

RSSI, SNR en Noise Floor

In MeshCore (en LoRa in het algemeen) zie je drie belangrijke waarden in logs, de app of de analyzer: RSSI, SNR en (soms impliciet) de noise floor. Hieronder een uitleg van wat ze betekenen, hoe je ze interpreteert en wat typische goede/slechte waarden zijn — gebaseerd op LoRa SX1262 chips met de Nederlandse narrow preset (BW 62.5 kHz / SF7).

RSSI (Received Signal Strength Indicator)

De absolute sterkte van het ontvangen signaal in dBm. Hoe dichter bij 0, hoe sterker; hoe meer negatief, hoe zwakker.

RSSISituatie
-50 tot -90 dBmSterk — lokaal, line-of-sight
-90 tot -110 dBmRedelijk — typisch op enkele kilometers
-110 tot -130 dBmZwak — grens van bereik, vaak nog decodeerbaar
onder -130 dBmTe zwak — packet loss, afhankelijk van SF

RSSI alleen zegt niet alles. Een signaal van -100 dBm kan prima werken bij weinig ruis, maar falen bij veel interferentie. Kijk altijd samen met SNR.

Noise Floor (ruisvloer)

Het niveau van achtergrondruis in dBm — thermische ruis plus interferentie van andere radios, WiFi, etc. MeshCore toont dit zelden direct, maar je ziet het indirect via RSSI en SNR.

OmgevingNoise floor
Buiten, rustig platteland-110 tot -125 dBm of lager
Stedelijk / met interferentie-95 tot -105 dBm

Narrow presets (BW 62.5 kHz) geven een lagere noise floor dan brede bandwidths — dit is een van de redenen waarom Nederland bewust voor 62.5 kHz heeft gekozen. LoRa kan signalen onder de noise floor nog decoderen (dat is het principe achter spread spectrum), maar hoe lager de ruis, hoe beter je zwakke signalen oppikt.

SNR (Signal-to-Noise Ratio)

Het verschil tussen het ontvangen signaal en de noise floor in dB. Positief = signaal sterker dan ruis (makkelijk decoderen). Negatief = signaal zwakker dan ruis — LoRa kan dit nog steeds aan, tot een limiet.

Formule:SNR ≈ RSSI − noise floor

SNRKwaliteit
+5 tot +12 dBUitstekend — dichtbij of heel schone band
-5 tot +5 dBGoed — betrouwbaar, normaal mesh gebruik
-10 tot -5 dBRedelijk — 90-100% packet delivery
-15 tot -10 dBZwak — packet loss begint, maar werkt vaak nog
-18 tot -20 dBZeer zwak — alleen haalbaar bij hoge SF (SF11/12)
onder -20 dBOnbruikbaar — SF7/SF8 haalt dit niet meer

Snelle vuistregels (Nederlandse narrow preset)

SituatieRSSISNRVerwachting
Zeer sterk / lokaal-60 .. -85 dBm+5 .. +12 dBPerfect, geen drops
Goed bereik-85 .. -105 dBm-5 .. +5 dBBetrouwbaar normaal gebruik
Matig / op limiet-105 .. -120 dBm-10 .. -5 dBNog oké, gevoelig bij beweging
Ver / fringe-115 .. -130 dBm-15 .. -10 dBWerkt, maar onbetrouwbaar
Extreem / noise floor+-125 .. -140 dBm-18 .. -22 dBVeel drops, alleen hoge SF
Ruis overheerstelke RSSI< -20 dBDecodering faalt

Praktische tips

Veelgestelde vragen (FAQ)

Wat is MeshCore?
MeshCore is een open-source LoRa mesh-netwerk voor tekstcommunicatie zonder internet of simkaart. Kleine radionodes geven berichten aan elkaar door via een zelf-organiserend netwerk.

Wat is het verschil tussen MeshCore en Meshtastic?
Beide gebruiken LoRa hardware, maar MeshCore kiest voor pad-gebaseerd routeren: nodes leren routes en sturen berichten direct door naar de bestemming. Meshtastic gebruikt flooding — elk bericht wordt door elke node doorgestuurd. MeshCore verbruikt daardoor minder zendtijd en veroorzaakt minder collisions in dichte netwerken. Zie Multi-Hop Packet Routing met Path Learning voor een gedetailleerde uitleg.

Hoe ver reikt een MeshCore node?
In open veld met line-of-sight en een hoog geplaatste node: 10+ km. In bebouwd gebied of handheld: realistisch 1–5 km. Via een keten van repeaters kunnen berichten honderden kilometers reizen. Zie Technische Parameters voor een bereiktabel per situatie.

Welke hardware heb ik nodig?
Populaire keuzes zijn de Heltec LoRa32 V3, LilyGo T-Deck (met scherm en toetsenbord), RAK Wireless (RAK4631) en Seeed Studio T1000-E. Voor de meeste gebruikers volstaat een companion node (~€20–50) in combinatie met de gratis mobiele app. Zie Hardware & Firmware Types voor een beschrijving van alle firmwaretypes.

Werkt MeshCore zonder internet?
Het protocol zelf werkt volledig offline — geen wifi, geen simkaart, geen server nodig. Aanvullende diensten zoals kaarten, node-directories en firmware-updates vereisen wel internet.

Heb ik een vergunning nodig?
Nee. In Nederland gebruik je 869.618 MHz (sub-band P), een licentievrije ISM-band. Je moet wel voldoen aan de ETSI-regels: maximaal 500 mW ERP en een duty cycle van ≤ 10%. Zie Juridische Status Nederland voor verdere details.

Werkt MeshCore samen met Meshtastic nodes?
Nee. MeshCore en Meshtastic gebruiken een ander packet-formaat en zijn niet onderling compatibel.

Hoe stel ik een repeater in?
Flash de repeater-firmware via de web flasher, verbind via USB serieel of BLE, en configureer via de CLI (set name, set tx.power, region put, etc.). Zie de MeshCore FAQ voor volledige instructies. Voor de NL-specifieke voorbereiding: The Change en de Regio Generator.

Mijn repeater ontvangt plotseling niets meer — wat nu?
Dit is een bekend probleem met SX1262-chips (Heltec, RAK). Stel in: set agc.reset.interval 4 (geldige waarden: veelvouden van 4) om de AGC periodiek te resetten. Herstart daarna de repeater. Zie ook TX Delay voor verdere troubleshooting-tips.

Hoe zit het met encryptie en privacy?
Direct Messages en private rooms zijn end-to-end versleuteld met AES-128 op basis van ECDH-sleuteluitwisseling — alleen de beoogde ontvanger kan het bericht lezen. Berichten in publieke kanalen zijn versleuteld met een gedeelde kanaalsleutel; iedereen met die sleutel kan meelezen. Je publieke sleutel is zichtbaar in het netwerk (de eerste bytes zijn je node-ID), maar de inhoud van berichten is altijd beschermd. Zie Beveiliging & Encryptie voor een volledig technisch overzicht.

Kan ik een eigen kanaal of room aanmaken?
Ja. Kanalen en rooms werken via een gedeelde sleutel (PSK — Pre-Shared Key). Je maakt een kanaal aan in de app, stelt een naam en sleutel in, en deelt die (via QR-code of handmatig) met de mensen die mee mogen doen. Je kunt een publiek kanaal (bekende sleutel voor iedereen) of een volledig privé kanaal maken. Room Servers slaan berichtgeschiedenis op zodat deelnemers berichten kunnen ophalen als ze offline waren. Zie Hardware & Firmware Types voor meer over Room Server firmware.

Wat kost het ongeveer?

Zie Hardware & Firmware Types voor een beschrijving van alle hardwarecategorieën.

Hoeveel repeaters zijn er in Nederland?
Het netwerk groeit snel. Begin 2026 waren er honderden actieve repeaters; in mei 2026 zijn dat er ruim 2.000 verspreid over Nederland, met de meeste dekking in de Randstad en stedelijke gebieden. Zie de live kaart op localmesh.nl of cornmeister.nl voor actuele dekking in jouw regio. Meer tools en community-links in Bronnen en community.

Projectsplit (april 2026)

MeshCore is mede geboren uit de nasleep van Cycloon Gabrielle (Nieuw-Zeeland, februari 2023). De orkaan verwoestte grote delen van het Noordereiland en legde veel communicatie-infrastructuur plat. Scott Powell (grondlegger, firmware en protocol) en Liam Cottle (Nieuw-Zeeland, web- en mobiele clients) werkten vanuit die noodcommunicatiebehoefte samen aan een robuust, volledig offline mesh-netwerk dat zonder simkaart of internet toch berichten kon doorsturen. Dat experiment groeide uit tot MeshCore. (Bronnen: Wikipedia — MeshCore en het NZ Herald-portret van de ontwikkelaar.)

In april 2026 vond een openbare scheiding plaats binnen het MeshCore-project. Het kernteam — Scott Powell (grondlegger, firmware), Liam Cottle (clients/app), Recrof (kaart en flasher), FDLamotte (Python-tooling en STM32) en Oltaco (bootloader) — maakte bekend dat teamlid Andy Kirby op 29 maart 2026 zonder medeweten van de rest van het team een trademark-aanvraag had ingediend voor de naam "MeshCore". Andy beheerde ook de domeinnaam meshcore.co.uk, die hij bij de split onder zijn eigen beheer hield. (Bron: The Split — blog.meshcore.io.)

Het kernteam besloot zelfstandig verder te gaan en startte opnieuw onder meshcore.io als officieel thuis van het project. Het project telt inmiddels meer dan 38.000 actieve nodes en ruim 100.000 app-gebruikers wereldwijd.

Wat is meshcore.co.uk?
meshcore.co.uk is de voormalige projectsite, nu in beheer van Andy Kirby. Deze site valt niet onder het officiële project en wordt niet onderhouden door het kernteam.

De officiële kanalen zijn:

Lees de volledige achtergrond in de officiële blogpost: The Split — blog.meshcore.io

The Change — 9 mei 2026

Op 9 mei 2026 schakelt de Nederlandse MeshCore-community gezamenlijk over naar een nieuw radiopreset: SF7 / CR5. Deze gemeenschappelijke omschakeling staat bekend als The Change. (Bron: The Switch — meshwiki.nl; het testweekend was 6–8 maart 2026.)

Waarom is deze overstap nodig?

Het Dutch MeshCore mesh is in 2025–2026 explosief gegroeid en daardoor zwaar overbelast geraakt. Netwerkcongesti zorgt voor pakketverlies, vertraagde berichten en onbetrouwbare communicatie voor iedereen. Community-tests tijdens het testweekend van 6–8 maart 2026 bevestigden dat overstappen naar SF7 de netwerkcapaciteit significant vergroot: een kortere time-on-air per pakket betekent meer ruimte voor alle deelnemers op dezelfde frequentie.

Lees de achtergrond en testresultaten in de officiële documenten:

Wat verandert er?

Alleen de spreading factor en coding rate wijzigen — frequentie en bandbreedte blijven gelijk:

ParameterVóór 9 meiVanaf 9 mei
Spreading FactorSF8SF7
Coding RateCR8 (4/8)CR5 (4/5)
Frequentie869.618 MHz869.618 MHz
Bandbreedte62.5 kHz62.5 kHz
Vereiste firmware—v1.15+

Belangrijk: Op de schakeldag moet iedereen tegelijk overschakelen. Nodes die na 9 mei nog op SF8 draaien zijn niet meer compatibel met het netwerk.

Voor repeater beheerders

Stappen 1–6 kunnen voor de schakeldag worden uitgevoerd op je eigen tempo. Stap 7 voer je uit op 9 mei zelf.

Vóór 9 mei — voorbereiding:

  1. Firmware updaten naar v1.15+ — vereist voor correcte regioscoping en betrouwbaar werken van region denyf * (Fase 8, 13 juni). Update zowel de repeater-firmware als je companion app. (Basis-regiofiltering bestaat sinds repeater v1.10.0, maar is pas vanaf v1.15.0 betrouwbaar bruikbaar — zie region filtering en default scope.)

  2. Advert interval aanpassen — stel het flood advert interval in op minimaal 50 uur. Zero-hop advertenties: 240 minuten (4 uur). Te frequente advertenties zijn een van de hoofdoorzaken van congestie. Controleer via mc-radar.woodwar.com/mesh-health of je node in de probleemlijst staat.

  3. Bots en scripts stoppen — controleer en stop geautomatiseerde integraties zoals Home Assistant, eigen scripts of auto-reply bots in gedeelde kanalen zoals #test.

  4. Regioscoping configureren — voeg regiocodes toe aan je repeater. Gebruik de Regio Generator op TechSpeeltuin of een andere community-tool. Stel ook de standaard regio in op je companion app. Voeg region denyf * hier nog niet toe — dat is Fase 8 op 13 juni.

  5. Multi-byte pad inschakelen — schakel 2-byte pad-hashing in voor betere netwerkzichtbaarheid:

    set path.hash.mode 1

  6. Lusdetectie en duty cycle instellen:

    set loop.detect minimal
set dutycycle 10

    loop.detect minimal weert flood-pakketten die door het mesh lussen. dutycycle 10 handhaaft de wettelijk verplichte 10% zendtijdlimiet.

Op 9 mei — schakeldag:

  1. Netherlands radio preset toepassen — open de repeater-instellingen in de MeshCore app en selecteer de preset Netherlands. Dit configureert SF7 / CR5 / 869.618 MHz / 62.5 kHz automatisch. Controleer daarna of je je buren kunt horen op de nieuwe instellingen.

Voor clients (companion gebruikers)

Als gebruiker zonder repeater is je voorbereiding eenvoudiger, maar ook jij moet omschakelen op 9 mei — anders ben je na die dag niet meer compatibel met het netwerk.

Vóór 9 mei:

Op 9 mei — schakeldag:

Regio Doorsturing — 13 juni 2026

Ongeveer een maand na de SF7-omschakeling volgt Fase 8: strikte regio-doorsturing. Op 13 juni 2026 schakelen repeater-beheerders hun repeater in om pakketten zonder regiotag te weigeren. (Bron: The Switch — meshwiki.nl.)

Wat verandert er?

Tot en met 12 juni stuurt elke repeater alle pakketten door — ook pakketten zonder regio, die zo potentieel door heel Europa reizen en congestie veroorzaken. Vanaf 13 juni geldt: een pakket zonder regiotag wordt door correct geconfigureerde repeaters stilletjes weggegooid.

Dit wordt ingesteld met één commando op je repeater:

region denyf *
region save

Via de UI: ga naar Regio's Beheren → optie Pakketten zonder regio → stel in op Flood weigeren.

Waarom?

Door strikte doorsturing ontstaan logisch gescheiden regionale zones. Congestie of problemen in Noord-Holland cascaderen niet meer naar Zeeland of Limburg. Advertenties blijven beperkt tot hun eigen regio. Het resultaat is een stabieler en betrouwbaarder netwerk voor de hele community.

Strikte doorsturing blokkeert uitsluitend pakketten zonder regiotag — het voorkomt geen communicatie met naburige provincies, heel Nederland of andere EU-landen. Zolang scope correct is ingesteld, werkt communicatie over regiogrenzen gewoon door.

Belangrijk: Voer region denyf *niet vóór 13 juni uit. Een te vroeg geconfigureerde repeater weigert berichten van nodes die regioscoping nog niet hebben ingesteld, wat onnodige communicatiestoringen veroorzaakt.

Voor repeater beheerders

Controleer vóór 13 juni:

Op 13 juni — één commando:

region denyf *
region save

Voor clients (companion gebruikers)

Als client hoef je op 13 juni niets te wijzigen aan je radio-instellingen. Maar let op: als je kanalen geen scope hebben, worden jouw pakketten na 13 juni niet meer doorgestuurd door correct geconfigureerde repeaters.

Controleer vóór 13 juni:

Zo niet: stel dit in via Experimentele Instellingen in de app. Zie de referentielijst van publieke kanalen voor aanbevolen scopes per kanaal.

Regio Generator al klaar

De Regio Generator op TechSpeeltuin is al voorbereid op Fase 8. De gegenereerde CLI-commando's bevatten de volledige regioconfiguratie inclusief de region denyf * opdracht die je op 13 juni kunt toepassen. Genereer je configuratie alvast, zodat je op 13 juni direct klaar bent.

DTIS — Distributed Text Infrastructure System

DTIS (Distributed Text Infrastructure System) is een publiek maatschappelijk samenwerkingsverband — van overheden, kennisinstellingen, partners en sponsoren — dat zich richt op de ontwikkeling, uitbreiding en duurzame borging van autonome communicatie-infrastructuur op basis van MeshCore. De technische uitvoering ligt bij SkyLab en SkyNet IoT. Waar de meeste MeshCore-gebruikers zelf een node of repeater beheren, bouwt DTIS aan een professionele, vaste infrastructuur van autonome solar-repeater stations die onafhankelijk van internet en mobiele netwerken opereren.

Waarom DTIS?

Nederland — en Europa breder — is kwetsbaar voor communicatiestoringen door geopolitieke spanningen, cyberaanvallen, netwerkoverlast en stroomstoringen. DTIS positioneert MeshCore als aanvullende infrastructuur voor korte tekstcommunicatie die operationeel blijft wanneer reguliere netwerken uitvallen. De nadruk ligt op vaste, betrouwbare stations in plaats van mobiele gebruikers-devices, wat een stabielere en beter voorspelbare communicatielaag oplevert.

Aanpak en partners

Het samenwerkingsverband brengt overheden, kennisinstellingen, maatschappelijke organisaties en technische partners samen. Technische uitvoering en operationele ondersteuning liggen bij SkyLab en SkyNet IoT. Deelname is mogelijk via het beschikbaar stellen van locaties voor repeater-stations, technische ontwikkeling of sponsoring.

De infrastructuur is publiek toegankelijk — geen abonnementen, geen kosten — en biedt end-to-end versleutelde tekstcommunicatie (AES-128) op dezelfde LoRa-frequenties als het Nederlandse MeshCore-netwerk.

Kaart en locaties

Op dtis.io/map en dtis.io/locaties zijn de actieve en geplande repeater-stations te vinden. DTIS en de bredere community-netwerken (zoals LocalMesh.nl en het vrijwilligersnetwerk) vullen elkaar aan: DTIS levert de vaste ruggegraat, de community de dekking in de haarvaten.

Bronnen en community

TechSpeeltuin:

Officiële bronnen:

Nederlandse community sites:

Community chat en forums:

Live
Laden...
© 2024–2026 · Ownbrew Framework