Paginaversie 1.6 · laatst bijgewerkt op 19-08-2026

In de wijk Stadspolders staat de allereerste MeshCore repeater van Dordrecht. Wat begon als een klein experiment groeit langzaam uit tot een echte stadsdekkende infrastructuur, inmiddels zijn er meerdere repeaters actief in Dordrecht en de Drechtsteden, en breidt het netwerk zich verder uit.

---

Repeater Instellingen voor Dordrecht Oost 🗼

De repeater draait in Narrow mode (62.5 kHz bandbreedte), de standaard instelling voor het Nederlandse MeshCore netwerk. Zorg dat je MeshCore app ook op Narrow mode staat om verbinding te maken.

Wat de firmware voor deze repeater betekent

Deze repeater draait sinds 14 augustus 2026 op v1.17.1, daarvoor sinds 9 augustus op v1.17.0. Het image heet Heltec_t096_repeater-v1.17.1.

v1.17.1 repareert een zendfout op precies dit bord

De release noemt de Heltec T096 deze keer wél bij naam, en niet voor een kleinigheid: "Heltec T096 Tx failure fixed (out of bounds PIN_SPI1_MISO)". In de bordbeschrijving stond een ongebruikte pin op -1. De firmware las die waarde alsnog op als plek in de pinnentabel en kwam daarmee buiten die tabel uit, waarna de stuurlijn die de KCT8103L in de zendstand zet het liet afweten. De reparatie is één regel: -1 werd 0. (Bron: release 1.17.1; broncode: PR #3188 in variants/heltec_t096/variant.h.)

Wat dat hier deed is aan het eigen verkeerslog te zien. Van alle doorgestuurde pakketten die deze repeater ontvangt, is bij een deel de eigen padhash al onderweg opgepikt: dat zijn berichten die hier langs zijn geweest, door een ander station zijn doorgegeven en weer terugkomen. Dat is dus een maat voor hoe goed anderen deze zender horen.

Bijna drie keer zoveel, terwijl het netwerk in diezelfde periode juist iets kleiner werd (van ruim 200 naar zo'n 150 actieve nodes per dag) en de padhashes van de andere grote repeaters in de regio nauwelijks van aandeel veranderden. Deze repeater stond vóór 15 augustus niet in de top vijf van meest voorkomende padhashes en staat er sindsdien wel in. Dat is een sterke aanwijzing dat de eindversterker weer meedoet, geen bewijs: uitgestraald vermogen is hier niet gemeten, alleen hoe vaak anderen het resultaat doorgeven.

Twee ontvangstversterkers om na te lopen

MeshCore vraagt repeaterbeheerders na deze update expliciet om radio.fem.rxgain en radio.rxgain te controleren, en daar is reden voor. In v1.17.0 hingen de opgeslagen sleutels fem_rxgain en rxgain allebei aan dezelfde interne variabele, waardoor de FEM-instelling niet bewaard werd zoals bedoeld. Dat is nu rechtgezet. Los daarvan zette een AGC-reset de RX boosted gain terug naar de waarde die in de firmware is meegebakken in plaats van naar wat jij had ingesteld; de opgeslagen instelling klopte dan nog wel, maar de radio deed iets anders. Dat raakt alleen wie agc.reset.interval heeft aangezet, want die staat standaard uit. Op deze repeater staan beide versterkers aan, wat op repeater-firmware ook de standaardwaarde is. (Bron: release 1.17.1; broncode: PR #3137 en PR #3158.)

Nieuw in deze release is ook set radio.fem.txgain, maar dat werkt alleen op de Station G3. Dit bord regelt alleen de ontvangstkant van zijn front-end module en antwoordt op dat commando met Error: unsupported. (Broncode: T096Board implementeert wel canControlLoRaFemLna(), niet canControlLoRaFemPaGain().)

Antwoorden sneuvelden bij een lage hoplimiet

Deze repeater knijpt ongescopet floodverkeer af op 3 hops (set flood.max.unscoped 3, zie hieronder). Precies dat soort instelling liep stuk op twee fouten die v1.17.1 herstelt. Een inlogverzoek dat rechtstreeks binnenkwam werd altijd met een flood beantwoord, ook als de repeater het pad terug allang kende; nu gaat dat antwoord direct over dat bekende pad. En een geflood antwoord waarvan de scope niet te bepalen was ging ongescopet de lucht in, waar het vervolgens tegen diezelfde krappe hoplimiet aanliep. Zo'n antwoord krijgt nu de thuisregio mee, hier nl-zh-dor, en telt dan tegen de ruimere limiet van 20 hops.

Het scherpst zag je dat bij flood.max.unscoped 0, waar het antwoord meteen bij de eerste repeater sneuvelde en inloggen in de app simpelweg niet lukte. Wie daarvoor de limiet had opgetrokken kan dat na deze update terugdraaien. De standaardwaarde is 64, dus een repeater waar niemand aan gedraaid heeft merkte hier niets van. (Broncode: PR #3106, chooseReplyRoute() en chooseReplyScope() in RoutingPolicy.h.)

Verder verbetert v1.17.1 op nRF52840-borden zoals dit de kwaliteit van de toevalsgenerator, die nu ruis uit de radio combineert met de hardwaregenerator van de CC310. (Broncode: PR #3206.)

Wat v1.17.0 al meebracht

• De ontvangstversterker werd instelbaar. Op de T096 zit een KCT8103L front-end module, en set radio.fem.rxgain <on|off> schakelt de ontvangstkant daarvan. Dat staat los van radio.rxgain, wat de boosted gain van de radiochip zelf regelt. (Broncode: variants/heltec_t096, LoRaFEMControl en T096Board::canControlLoRaFemLna().)
• Minder botsingen zonder iets in te stellen. De vernieuwde listen-before-talk werkt vanzelf; de losse set cad staat hier uit. Zie Listen before talk en hardware-CAD.
• Zuiniger in rust, wat voor een solar-node met accubackup het meest telt van alles.
• Snellere versleuteling. De nRF52840 gebruikt nu zijn CC310-hardware, wat rekenwerk scheelt en daarmee stroom.

Het overige werk in beide releases gaat over andere borden en radiochips (T114, T-Echo Lite en Card, T-Beam Supreme S3, ProMicro, R1 Neo, Station G3, de LR2021) en is hier niet van toepassing.

Waarom loop detection op moderate staat

Bij het doorsturen van een floodbericht kijkt de repeater hoe vaak zijn eigen hash al in het pad staat. Hoe vaak dat mag voordat hij het bericht laat vallen, hangt af van deze instelling én van de padhash-grootte:

Dit netwerk gebruikt hashes van 2 bytes. Op minimal is de drempel dan 2, en stuurt de repeater een bericht dat hij al eens heeft doorgestuurd dus nóg een keer de lucht in. Op 9 augustus 2026 is hier overgestapt op moderate, waarmee die drempel op 1 komt: elk bericht gaat hooguit één keer door deze repeater. Direct daarna halveerde het aandeel eigen zendingen in het gemeten kanaalverkeer, van 26% naar 14%.

Voor een netwerk met 2-byte hashes is strict overigens identiek aan moderate; het verschil tussen die twee bestaat alleen bij 1-byte hashes.

Kanalen in de Regio

In de Drechtsteden regio zijn de volgende MeshCore kanalen in gebruik:

Regions

De repeater is geconfigureerd met onderstaande regions. Berichten worden gefilterd op basis van scope, wie bewust lokaal communiceert bereikt alleen de repeaters in die regio, zonder het nationale netwerk te belasten.

Update 29 juli 2026, van weigeren naar knijpen

Sinds 12 juni draaide de repeater met region denyf *: flood-pakketten zonder region-scope werden helemaal niet doorgestuurd. Meten aan het eigen verkeer liet zien wat dat in de praktijk betekende, van 584 ontvangen ongescopete floods gaf de repeater er 2 door. Bijna de helft van het lokale floodverkeer liep hier dus dood.

Daarom staat de wildcard sinds vandaag weer open, maar begrensd:

region allowf *
set flood.max.unscoped 3

Een bericht zonder scope wordt nu nog 3 hops geholpen, genoeg om de buurt te bereiken, te weinig om landelijke ruis rond te pompen. De officiële CLI-documentatie noemt dit expliciet het alternatief voor region denyf *.

Wat dit betekent voor jou:

• Stuur je unscoped (de standaard in de meeste apps), dan komt je bericht via deze repeater nog drie hops verder in plaats van nergens.
• Een scope instellen blijft veruit het beste: gescopet verkeer dat bij de regions hieronder past gaat tot 20 hops mee.
• Wil je dat goed regelen, stel region-scoping in op zowel je repeater als je companion-app. De MeshCore Regio Generator genereert de benodigde region-commando's.

Tegelijk zijn er twee grenzen bijgezet: set flood.max 20 (92% van al het floodverkeer komt binnen met 20 hops of minder; de staart liep door tot 52 hops en bestaat vrijwel zeker uit rondzingende pakketten) en region denyf eu (in een etmaal kwam er geen enkel pakket op scope eu langs, terwijl elke toegestane region rekenwerk kost bij ieder pakket). Die region is inmiddels helemaal uit de configuratie verwijderd.

Filtering werkt uitsluitend op flood-pakketten. Directed verkeer met een bekend pad gaat er ongemoeid langs.

Let op: Regions zijn een relatief nieuwe functie in MeshCore. De naamgeving en hiërarchie zijn nog niet volledig gestandaardiseerd en kunnen in de toekomst wijzigen.

Dit is de region-boom zoals het commando region hem nu op deze repeater teruggeeft:

* F
 nl F
  nl-zh F
   nl-zh-dor^ F
    nl-zh-dor-stadspolders F
   nl-zh-pap F
   nl-zh-sld F
   nl-zh-drechtsteden F
  nl-dor F
  nl-nb F
   nl-nb-wkd F

De F achter een naam betekent dat flooding voor die scope is toegestaan, de ^ markeert de thuisregio (region home nl-zh-dor) en de bovenste regel is de wildcard * voor ongescopet verkeer. Uitgeschreven:

Alle toegestane regions gaan tot de algemene hoplimiet van 20 (set flood.max 20); zonder scope is dat 3 (set flood.max.unscoped 3) en voor adverts 8 (set flood.max.advert 8).

Die drie limieten stapelen: de firmware toetst een floodpakket aan alle drie en de strengste die van toepassing is wint. Een advert met een toegestane scope haalt hier dus 8 hops, maar een advert zonder scope komt niet verder dan 3, want dan telt de ongescopete limiet ook mee. Dat is iets om te weten als je node zichzelf ongescopet aankondigt: achter deze repeater is hij dan minder ver zichtbaar dan het getal 8 doet vermoeden. (Broncode: isFloodHopLimitExceeded() in RoutingPolicy.h, dat de drie drempels na elkaar toetst.)

De boomstructuur is vooral administratief: bij het filteren van pakketten kijkt de firmware niet naar de parent, maar vergelijkt hij de scope van het bericht exact met elke region in deze lijst. Wat je hierboven ziet staan wordt doorgestuurd, de rest niet, een bericht op scope nl-nh (Noord-Holland) of eu dropt deze repeater dus stil, ook al staan die "boven" of "naast" scopes die hij wél kent.

nl-zh-drechtsteden staat naast nl-zh-dor als aparte regio-aanduiding voor de hele Drechtsteden-samenwerking (Dordrecht, Sliedrecht, Papendrecht, Alblasserdam, Hendrik-Ido-Ambacht, Zwijndrecht). Wil je iemand in heel Drechtsteden bereiken, gebruik dan scope nl-zh-drechtsteden in je kanaalinstellingen.

Papendrecht (nl-zh-pap) en Sliedrecht (nl-zh-sld) zijn als buurregio's opgenomen omdat de repeater in Stadspolders (aan de rand van Dordrecht) ook deze gemeenten bestrijkt.

nl-dor is de kortere stadsregio-notatie zonder provincie ertussen, rechtstreeks onder nl. Omdat regions niets van elkaar erven zijn nl-dor en nl-zh-dor twee losse sleutels; de repeater kent ze allebei, zodat het niet uitmaakt welke van de twee schrijfwijzen je companion-app gebruikt.

Wat er niet meer in staat: eu (stond al op denyf omdat er in een etmaal meten geen enkel pakket op die scope langskwam, en is nu helemaal verwijderd, nl hangt daardoor rechtstreeks onder de wildcard), nl-zh-a2z (Oud-Alblas) en vr-vrzhz (Veiligheidsregio Zuid-Holland Zuid). Die laatste is eruit omdat DARES in juli 2026 desgevraagd liet weten dat MeshCore geen formele DARES-dienst is, niet als noodcommunicatiekanaal wordt ingezet, en dat er geen taak ligt om regiokenmerken in de standaard naamgeving op te nemen. Elke toegestane region kost de repeater bovendien rekenwerk bij ieder binnenkomend floodpakket, dus een korte lijst is ook een snellere lijst.

Gebruik de MeshCore Regio Generator om de region put en region allowf CLI-commando's voor jouw eigen repeater te genereren. Meer over het regions- en scopesysteem lees je op de Over MeshCore pagina.

Meer Informatie

• MeshCore Officiële Website
• Nederlandstalige Telegram groep
• MeshCore Net Forum
• MeshCore Discord Community
• The Switch, SF8 naar SF7(meshwiki.nl)

Direct Ontvangen Stations

QR Code: Drechtsteden Kanaal