MeshCore bracht op vrijdag 14 augustus 2026 firmware v1.17.1 uit, vijf dagen na v1.17.0. Het is een punt-release: geen nieuwe kijk op het mesh, maar reparaties van wat er in de vorige versie stuk ging of nooit goed heeft gewerkt. Eén bord bleek daarbij helemaal niet te zenden. Verder zijn er twee instellingen die je als repeaterbeheerder na het bijwerken zelf moet nalopen. Een dag later, op 15 augustus, verscheen versie 1.48.0 van de MeshCore-app. (Bron: release 1.17.1 en de releasepagina op GitHub.)
Waar je op moet letten
Vier punten, gesorteerd naar wat je in beheer hebt. De rest van dit bericht werkt ze uit.
- Repeater of room server met
flood.max.unscopedlager dan de standaard: het antwoord op een directe login kwam niet aan. Dat is nu opgelost, en de tijdelijke oplossing (die waarde optrekken) mag terug naar wat hij was. - Repeater met een front-end module: draai na het bijwerken
get radio.fem.rxgainenget radio.rxgain. MeshCore vraagt daar zelf om. - Repeater met
agc.reset.intervalaan: je ingestelde ontvangstversterking sprong periodiek terug naar de fabriekswaarde. Ook opgelost, en ook hier: controleer even wat er nu staat. - Heltec T096, T-Echo Lite, T-Echo Card, Heltec T1, MeshPocket, T-Beam Supreme S3, ProMicro, R1 Neo, Minewsemi: aan deze borden is iets veranderd. Bij de T096 werkte zenden helemaal niet.
(Bron: release 1.17.1, en per punt de bronnen hieronder.)
Waarom inloggen op een repeater soms mislukte
De grootste reparatie zit in het antwoord dat een repeater op een login terugstuurt. Daar gingen twee dingen tegelijk mis.
Het antwoord ging de verkeerde kant op
Log je vanuit de app in op een repeater die je al kent, dan gaat dat verzoek direct: langs het pad dat je app al heeft, en niet als flood over het hele netwerk. De repeater antwoordde daar toch op met een flood. Bij alle andere verzoeken gebruikte hij netjes het retourpad dat hij van je had opgeslagen, alleen bij inloggen niet. In de woorden van de melding: "The repeater ignores the return path it already has, for logins only."(Bron: PR #3106.)
Daar kwam een tweede probleem bovenop. In een direct verzoek zitten geen transportcodes, dus de repeater kon niet zien in welke regio de vraagsteller zat. Zijn antwoord ging daardoor ongescopet de lucht in: zonder regio, voor iedereen. (Bron: het commentaar in test_routing_policy.cpp, dat de bug regel voor regel vastlegt.)
Wat dat in de praktijk betekende
De repeaterinstelling flood.max.unscoped bepaalt hoeveel hops een pakket zonder regio nog mag maken. Standaard staat die op 64, dus wie er nooit aan gedraaid heeft merkte hier niets van. Maar MeshCore raadt in zijn eigen documentatie aan die waarde te verlagen als je geen region denyf * wilt gebruiken: dat houdt drukke buren uit je lokale regio. Staat hij op 0, dan gooit de eerste repeater zo'n ongescopet antwoord meteen weg. In de app zie je dan alleen dat inloggen niet lukt. Wie ertegenaan liep, hielp zichzelf door flood.max.unscoped op te trekken tot het aantal hops dat de verbinding nodig had. (Bron: flood.max.unscoped in de CLI-documentatie voor de standaardwaarde en de aanbeveling, en test_routing_policy.cpp voor de omweg.)
Diezelfde instelling raakt trouwens ook adverts. Kondigt een node zichzelf nog ongescopet aan, dan komt hij achter een repeater met flood.max.unscoped 0 niet verder dan zijn directe buren. Aan dat gedrag is in deze release niets veranderd; het staat er nu alleen zwart op wit bij. (Bron: test_routing_policy.cpp, test UnscopedAdvertIsAlsoDroppedAtHopZero.)
Hoe het nu werkt
De keuze zit sinds deze release in een apart bestandje, RoutingPolicy.h, met unittests eromheen. De repeater loopt vier mogelijkheden af, in deze volgorde:
- Kwam het verzoek als flood binnen, dan gaat er een pad-terugmelding terug.
- Kwam het direct binnen met een retourpad erin, dan antwoordt hij direct langs dat pad.
- Kwam het direct binnen zonder retourpad, maar heeft hij nog een pad voor die client liggen, dan gebruikt hij dat.
- Pas als er echt niets bekend is, wordt er geflood.
Moet hij in dat laatste geval flooden zonder de regio van de vraagsteller te kennen, dan pakt hij zijn eigen standaardregio in plaats van helemaal geen regio. (Bron: RoutingPolicy.h.)
Eén nuance, en die staat met zoveel woorden in de code: kwam het verzoek zelf ongescopet binnen, dan blijft het antwoord ook ongescopet. Dat was de keuze van de vraagsteller, en het antwoord alsnog in jouw regio duwen zou een pad breken dat nu werkt. (Bron: het commentaar bij RepliesUnscopedToAnUnscopedFloodEvenWhenADefaultScopeExists in test_routing_policy.cpp.)
Dit geldt voor de repeater én de room server: beide kregen dezelfde wijziging. (Bron: de vergelijking tussen v1.17.0 en v1.17.1, waarin simple_repeater/MyMesh.cpp en simple_room_server/MyMesh.cpp allebei worden aangepast.)
Twee instellingen om na te lopen op je repeater
MeshCore vraagt na het bijwerken zelf om één controle. Er is er nog een tweede, die ze niet apart noemen.
De ontvangstversterking kon terugspringen
Een repeater kan zijn ontvanger periodiek resetten, zodat de automatische versterkingsregeling niet vast komt te zitten. Dat regel je met agc.reset.interval, standaard uit. Stond hij bij jou aan, dan zette elke reset de boosted gain terug op de waarde die in de firmware is ingebakken. Niet op de waarde die jij met set rxgain had gekozen. Je instelling bleef gewoon in het geheugen staan, maar de radio deed iets anders. (Bron: release 1.17.1, punt #3158, en de wijziging in SX126xReset.h, waar de resetfunctie de huidige stand als argument meekrijgt in plaats van de compileerwaarde te gebruiken. De standaardwaarde van agc.reset.interval staat in de CLI-documentatie.)
Sinds 1.17.1 krijgt de reset de huidige stand mee, zowel bij de SX126x-familie als bij de LR11x0-chips. Draaide je met de AGC-reset aan, dan is dit het moment om get rxgain te draaien en te kijken of daar staat wat je verwacht.
radio.fem.rxgain en radio.rxgain
Sommige borden hebben een front-end module tussen de radio en de antenne, met een eigen ontvangstversterker. Die zet je met radio.fem.rxgain, los van de radio.rxgain van de radiochip zelf. Allebei kwamen ze in 1.17.0 in beeld. MeshCore schrijft er in de release notes van 1.17.1 zelf over: "Repeater admins will want to check that radio.fem.rxgain and radio.rxgain are configured to their liking after updating."(Bron: release 1.17.1, hoofdstuk Fixes and enhancements for devices with FEM.)
Meer versterking is niet vanzelf betere ontvangst: een versterker tilt behalve het signaal ook de ruis op. Meet het verschil dus voor je hem laat staan.
Nieuw: set radio.fem.txgain, voorlopig alleen op de Station G3
Naast de ontvangstkant kun je nu ook de zendkant van zo'n front-end module aansturen, met get/set radio.fem.txgain. Dat werkt voorlopig alleen op de Station G3, en pas nadat je daar de PA PL1-jumper hebt weggehaald. Daarna kiest on de hoge stand en off de lage. Welke twee vermogensniveaus je daarmee schakelt, hangt af van de PL2-jumper op het bord. Kan je bord er niets mee, dan krijg je Error: unsupported terug. (Bron: de commandobeschrijving in cli_commands.md, toegevoegd in deze release.)
Twee dingen om te weten. Het gekozen niveau gaat pas aan het begin van de eerstvolgende zending naar de hardware. Anders zou de voedingsrail van de eindtrap verspringen terwijl die op volle sterkte staat te zenden. get laat daarom zien wat jij hebt ingesteld, en dat kan tot de volgende zending vooruitlopen op wat de hardware werkelijk doet. (Bron: de broncode van LoRaFEMControl, waar het commentaar de reden erbij zet.)
En het tweede: MeshCore zegt er zelf bij dat je niveau en zendvermogen binnen je lokale limieten moet houden. Voor Nederland is dat in sub-band P maximaal 500 mW ERP. Die grens geldt voor wat er uiteindelijk de antenne uit gaat, dus inclusief de versterking van je FEM. Reken het na voor je de hoge stand kiest. (Bron: de commandobeschrijving hierboven, en Regelgeving sub-band P op Over MeshCore.)
Borden die niet deden wat ze moesten
Het grootste deel van deze release bestaat uit hardwarefixes, en bij één bord ging het mis op het meest basale punt: zenden.
De Heltec T096 zond niet
Op de Heltec T096 werkte zenden niet. De oorzaak bleek een pin die in de bordconfiguratie op -1 stond en daarmee buiten de pinnentabel wees. Daardoor werd de zend-inschakelpin van de front-end module niet meer aangestuurd. MeshCore beschrijft het zo: "It was causing the FEM's Tx enable pin to stop working."(Bron: release 1.17.1, hoofdstuk Heltec T096 Transmit issue fix, en de wijziging in variant.h.)
Diezelfde -1 werd op meer nRF52-borden gebruikt om een ongebruikte pin aan te duiden. Die zijn in één ronde allemaal nagelopen: Heltec T1, MeshPocket en LilyGo T-Echo Lite. (Bron: release 1.17.1, punt #3189, en de vergelijking tussen beide versies.)
T-Echo Lite en T-Echo Card: verkeerde TCXO-spanning
Bij de LilyGo T-Echo Lite zijn de pinnen gelijkgetrokken met het bijgewerkte schema van Lilygo. Daarnaast ging de voedingsspanning van de temperatuurgecompenseerde kristaloscillator van 1,8 naar 3,0 V. Die oscillator geeft de radio zijn frequentiereferentie, dus een verkeerde spanning daar merk je aan hoe goed je gehoord wordt. De T-Echo Card kreeg dezelfde correctie. (Bron: release 1.17.1, punten #3140 en #3185, en de bouwinstellingen van de T-Echo Lite.)
Verder aan de hardwarekant
Het schermprobleem op de T-Beam Supreme S3 komt doordat het I2C-adres van het SH1106-paneel per bordrevisie verschilt: 0x3C of 0x3D. De driver probeert nu allebei. Daaronder zat nog een tweede probleem. Antwoordde er helemaal geen paneel, dan sloeg de driver de initialisatie over, en liep de node daarna tegen een lege verwijzing aan. Die initialisatie draait nu hoe dan ook. (Bron: release 1.17.1, punt #3164, en het commentaar in SH1106Display.cpp.)
Verder is de pinnenkaart van de ProMicro opgeruimd, met de LoRa-pinnen nu in de bordconfiguratie. Bij de Muziworks R1 Neo en de Minewsemi-repeater zijn bouwfouten weggewerkt. (Bron: release 1.17.1, punten #3170 en #3142.)
Voor clients verandert er weinig
Heb je alleen een companion aan je telefoon hangen, dan zie je aan de firmwarekant nauwelijks iets. Op de bordfixes hierboven na.
De companion bewaart de FEM-instellingen niet meer
De companion-firmware slaat de twee FEM-instellingen niet meer op en leest ze ook niet meer in. De reden staat er in de code bij: op een companion kun je ze toch nog niet zetten. In de vorige versie ging er in die opslag bovendien iets mis, want de sleutel fem_rxgain hing aan de verkeerde variabele. Praktisch gevolg: een companion draait op de standaardwaarden voor de FEM, en daar valt voorlopig niets aan te veranderen. (Bron: release 1.17.1, punt #3203, en het commentaar in NodePrefs.h: "these cannot be set (yet) so don't load/save until we can. also, fem_rxgain WAS mapped to wrong JSON property previously".)
Onder de motorkap
Drie wijzigingen die je nergens ziet maar wel het vermelden waard zijn.
De LR2021, de radiochip die in 1.17.0 nieuw bijkwam, heeft nu een fatsoenlijke bezetdetectie. Hij kijkt naar de preambule-vlag én naar een geldige pakketkop, en ruimt die vlaggen zelf op als er te lang niets volgt: 66 ms voor een preambule, ruim 3,9 seconde voor een pakket. Het is dezelfde reparatie waar 1.17.0 om draaide, nu voor de nieuwe chip. Voorlopig gaat het om de MeshTracker X1 en de Meshnology W12. (Bron: release 1.17.1, punt #3146, en CustomLR2021.h.)
De CC310-hardwarecrypto op de nRF52-borden, ook nieuw in 1.17.0, werd bij elke versleutelbewerking aan- en weer uitgezet. Dat gebeurt nu één keer bij het opstarten en één keer bij het afsluiten. (Bron: release 1.17.1, punt #3154, en de wijzigingen in NRF52Board.cpp en Utils.cpp.)
De toevalsgenerator op nRF-borden combineert sinds deze release twee bronnen: de hardwaregenerator in de CC310 en de ruis die de radio oppikt. In 1.17.0 verving de CC310 de radioruis nog helemaal, nu vullen ze elkaar aan. (Bron: release 1.17.1, punt #3206, en RadioLibWrappers.h.)
Voor wie zelf bouwt: de ruisvloermelding in de debuguitvoer staat nu achter een eigen vlag, en het bouwscript kan alle KISS-modemvarianten in één keer bouwen. Dat is de variant die van je bord een kale LoRa-modem met KISS-koppeling maakt, in plaats van een mesh-node. (Bron: release 1.17.1, punten #3166 en #3148, en build.sh.)
De app: versie 1.48.0
De app staat los van de firmware en heeft zijn eigen versienummers. Deze uitgave bestaat uit veel kleine verbeteringen, waarvan er twee aansluiten op wat er in de firmware speelt.
Een bestaande sessie hervatten
Er zit nu een knop in om een bestaande sessie met een repeater te hervatten, in plaats van elke keer opnieuw in te loggen. Dat past op hoe de firmware het al doet: na een geslaagde login blijf je in de toegangslijst van de repeater staan, met je rechten erbij. Een nieuwe login is dus niet altijd nodig. Elke login die je overslaat is bovendien zendtijd die het netwerk niet kwijt is. (Bron: de releasenotities van versie 1.48.0 in de App Store, en handleLoginReq() in simple_repeater/MyMesh.cpp voor hoe de repeater een client onthoudt.)
Regio's van gevonden repeaters
Bij een gevonden repeater kun je nu zien in welke regio's die zit. Dat is dezelfde scoping waar het inlogverhaal hierboven over gaat. Het scheelt gokwerk als je je afvraagt waarom je berichten ergens wel of niet aankomen. Ook nieuw: bij het exporteren van een configuratie gaat de scope van een kanaal mee, en bij het importeren wordt die toegepast. (Bron: de releasenotities van versie 1.48.0.)
Verder in deze versie
Alle telemetrie staat voortaan op één pagina en de keuzelijst per telemetriekanaal is verdwenen; je kiest nu zelf welke secties je toont. Wijkt het gerapporteerde vermogen af van wat er uit spanning en stroom volgt, dan laat de app allebei de waarden zien. Verder kun je eerdere CLI-commando's opnieuw versturen via het lange-druk-menu, en contacten en kanalen als link naar het klembord kopiëren. De autocorrectie in het commandoveld staat uit, de internetkaart laadt sneller en groepslabels op de kaart korten grote aantallen af. (Bron: de releasenotities van versie 1.48.0.)
iOS eerst, Android erna
Versie 1.48.0 verscheen op 15 augustus 2026 in de App Store; Google Play noemt diezelfde versie met 15 augustus als bijwerkdatum. De vorige versie, 1.47.0, is van 10 juli. (Bron: de App Store-pagina en de Google Play-pagina van MeshCore.)
Wat er niet verandert
Aan het pakketformaat is niets aangepast, dus alles wat meeleest of doorvertaalt blijft werken. Ook aan de duty cycle verandert niets. De vernieuwde luister-voor-je-zendt uit 1.17.0 is nog steeds geen gecertificeerde LBT: de tweede helft van de Nederlandse uitzondering, springen tussen kanalen, heeft MeshCore niet. set dutycycle 10 blijft dus nodig. (Bron: de vergelijking tussen beide versies, waarin geen enkel bestand van de pakketopbouw wijzigt, en Regelgeving sub-band P op Over MeshCore.)
De overstap naar configuratie in JSON zat al in 1.17.0. Sla je die versie over en ga je van iets ouders meteen naar 1.17.1, lees dan eerst het bericht over 1.17.0: noteer je instellingen voor je begint.
Waar je de firmware en de app vindt
De links naar de nieuwste firmware voor companion, repeater en room server staan op MeshCore Software. De commando's uit dit bericht staan met uitleg op MeshCore CLI.
Bronnen
- Release 1.17.1, de officiële aankondiging op de MeshCore-blog, 14 augustus 2026
- Vergelijking v1.17.0 naar v1.17.1 op GitHub: 47 commits, 57 gewijzigde bestanden
- Releases op GitHub, met de images per bord en firmwaretype
- PR #3106, de melding en de oplossing van het inlogprobleem
- RoutingPolicy.h en test_routing_policy.cpp, de nieuwe routeringsregels met hun tests
- CLI-documentatie van MeshCore, voor
radio.fem.txgain,flood.max.unscopedenagc.reset.interval - Broncode van MeshCore op tag
repeater-v1.17.1, voor de punten die de release notes niet noemen - MeshCore in de App Store en op Google Play, voor de releasenotities en datums van app 1.48.0
- Onze eigen pagina's: MeshCore Software, Over MeshCore, MeshCore CLI en het bericht over 1.17.0
Meer nieuws
