MeshCore en de Airtime-uitdaging

nl_NL	en-GB (hopefully)
Dit artikel is ontstaan uit de vele discussies in de MeshCore/Netwerk Architectuur Telegram groep en wat inzichten over “waar de pijn zit”. Waar kwamen de problemen met SF8 vandaan? Dat met in het achterhoofd dat in 2025 al eens de switch van SF11 naar SF8 is gedaan, omdat de dekking beter werd en meer snelheid gewenst was. De simpele waarheid is dat de mesh overbevolkt raakt, waardoor het geheel vol loopt en vast loopt. “Dunbevolkte” regio’s lijken daar vooralsnog minder last van te hebben. Toch, gezien de groei over de afgelopen maanden, is dat niet slechts een kwestie van tijd? En dat de mesh weer vol loopt ook. De repeaters schieten zo ongeveer als paddestoelen uit de grond. “Iedereen haar/zijn eigen repeater is tegelijkertijd een vloek en een zegen.” En om de spreekwoordelijke knuppel gelijk maar in het hoenderhok te gooien: alles had misschien zelfs op SF8 kunnen blijven werken, ook al is dat misschien in andere opzichten niet ideaal. Hieronder de waarom.	This article arose from the many discussions in the MeshCore/Network Architecture Telegram group and some insights into “where the pain lies.” Where did the problems with SF8 come from? Bearing in mind that the switch from SF11 to SF8 was already made in 2025 because coverage improved and more speed was desired. The simple truth is that the mesh is becoming overcrowded, causing the whole thing to become congested and freeze. “Sparsely populated” regions seem to suffer less from this for the time being. Yet, given the growth over the past few months, isn't that just a matter of time? And that the mesh will fill up again, too. Repeaters are practically springing up like mushrooms. “Everyone having their own repeater is both a curse and a blessing.” And to throw the proverbial cat among the pigeons right away: everything could perhaps have continued to work on SF8, even though that might not be ideal in other respects. Below is the why.
Een “potje” Airtime Afhankelijk van de ingestelde SF, is er voor berichten binnen een uur een beperkt aantal bits per seconde beschikbaar, ook afhankelijk van de lengte van de inhoud van dat bericht. Het hele pakket heeft aan preamble en headers al een bepaalde lengte, onafhankelijk van of je nu 1, of dat je 130 karakters verstuurt. Dat is de “overhead” die nodig is, om het geheel te laten werken. Een “Goedemorgen!” neemt dus door de overhead relatief gezien meer ruimte in dan bijvoorbeeld een “Goedemorgen, er is hier op de A2 richting Amsterdam een probleem.” Er passen dus meer korte berichten in een uur, dan langere berichten. Met repeaters binnen elkaars “hoorafstand”, betekent dat een niet aan te ontkomen hoeveelheid Airtime. Dit is zeg maar het “potje airtime”, waaruit door iedereen genomen kan worden. Dat zijn simpelweg de natuurkunde-wetten. In het medium Ether is een beperkte ruimte, in de tijd gezien en die kan dus maar 1x gebruikt worden. Dit levert dus ook beperkingen op voor MeshCore en wellicht sneller dan je denkt.	A “pot” of Airtime Depending on the configured SF, a limited number of bits per second is available for messages within an hour, also depending on the length of the message content. The entire packet already has a certain length consisting of preambles and headers, regardless of whether you send 1 or 130 characters. That is the “overhead” required to make the whole system work. A “Good morning!” therefore takes up relatively more space due to the overhead than, for example, a “Good morning, there is a problem here on the A2 towards Amsterdam.” Consequently, more short messages fit into an hour than longer ones. With repeaters within each other’s “hearing distance,” this means an unavoidable amount of Airtime. This is, so to speak, the “pool of airtime” from which everyone can take. These are simply the laws of physics. In the medium of Ether, there is limited space in terms of time, and it can therefore only be used once. This consequently also imposes limitations on MeshCore, and perhaps sooner than you think.
Voer voor rekenmeesters Er zijn diverse LoRa rekentools online beschikbaar, waar je je helemaal kunt uitleven op de exacte getallen. Niet alle tools lijken exact dezelfde antwoorden te kunnen geven, bijvoorbeeld omdat onze 62,5kHz bandbreedte kleiner is dan er door die tool ondersteund wordt. Er is een lijstje te maken, zie bijvoorbeeld: https://www.semtech.com/design-support/lora-calculator https://www.thethingsnetwork.org/airtime-calculator https://www.loratools.nl/#/airtime https://avbentem.github.io/airtime-calculator/ttn/eu868/120,28	Food for mathematicians There are various LoRa calculation tools available online, where you can really go wild with the exact numbers. Not all tools seem to be able to provide exactly the same answers, for example because our 62.5kHz bandwidth is smaller than what is supported by that tool. A list can be compiled; see, for example:
De praktijk Een “Goedemorgen!” op SF8 kost bijvoorbeeld 246,77 ms. Voordat een ander kan gaan zenden, na het horen van dit bericht, is er nog een kleine pauze, die een random tijd kent van tussen de 120 en 480ms*. Dit is wat ik ken als een "Inter Packet Gap", de tijd dat er niets op de "lijn"... ehh ether gezet wordt, om te controleren of er niet een ander is, die een bericht verstuurt. Zie ook de uitleg op: De techniek achter verzenden en ontvangen (Door: HvM) Semtech houdt overigens in hun calculator een default van 400ms aan. (*) Dit is even een rekenwaarde, het hele mechanisme is complexer.	In practice A “Good morning!” on SF8, for example, takes 246.77 ms. Before someone else can start transmitting after hearing this message, there is a short pause of random duration ranging from 120 to 480 ms (*). This is what I know as an "Inter Packet Gap," the time during which nothing is put on the "line"... uh... ether, to check if there isn't someone else sending a message. See also the explanation at: The technology behind sending and receiving (By: HvM). Incidentally, Semtech maintains a default of 400 ms in their calculator. (*) This is an assumed calculation value; the entire mechanism is more complex.
SF8 Laten we voor het gemak een gemiddelde nemen: 300ms. Dat betekent dat op SF8 die "Goedemorgen? dus 246,77+300=546,77ms inneemt van de beschikbare Airtime. In theorie passen er dan 3600 / 0,54677 = 6.584 van dat soort berichten in een uur.	SF8 Let's take an average for convenience: 300ms. That means that on SF8, that "Good morning?" takes up 246.77 + 300 = 546.77ms of the available airtime. In theory, 3,600 / 0.54677 = 6,584 of those messages fit into an hour.
SF7 Diezelfde “Goedemorgen!” op SF7 kost 139,76 + 300 = 439,76ms, dus passen er 3600/0,43976 = 8.186 van dat soort berichten in een uur. Een winst met een factor 8.186 / 6.584 = 1,243, die minder is dan je misschien zou verwachten, vanwege die pauze-tijd tussen twee berichten in. Zou die pauze-tijd (veel) minder zijn, neemt het aantal mogelijke berichten per uur sterk toe. Ga je uit van maar 120ms, ziet het plaatje er als volgt uit: SF8: 3600 / (0,24677 + 0,120) =9,815 berichten per uur. SF7: 3600 / (0,13976 + 0,120) =13.858 berichten per uur. Dan heeft SF7 een factor 1,41x de doorvoer van SF8.	SF7 That same “Good morning!” on SF7 costs 139.76 + 300 = 439.76ms, so 3,600 / 0.43976 = 8,186 of those types of messages fit into an hour. A gain of a factor of 8,186 / 6,584 = 1,243, which is less than you might expect due to that pause time between two messages. If that pause time were (much) shorter, the number of possible messages per hour would increase significantly. Assuming only 120ms, the picture looks like this: SF8: 3,600 / (0.24677 + 0.120) = 9,815 messages per hour. SF7: 3,600 / (0.13976 + 0.120) = 13,858 messages per hour. Then SF7 has a throughput factor of 1.41x that of SF8.
Groot bericht En hoe zit dat met een vol pakket, zo ook een Flood Advert? Dat maximale lengte is nu begrensd op 130 karakters. Laten we de gemiddelde wachttijd tot weer zenden op 300ms zetten, zoals voorheen. SF8: 3600 / (1,52 + 0,300) = 1.978 berichten per uur. SF7: 3600 / (0,909 + 0,300) = 2.977 berichten per uur. Nu loopt het verschil op naar een factor van 1,50x SF6 (voor de leuk): 3600 / (0,5525 + 0,300) = 4.222 berichten per uur.	Large message And what about a full packet, including a Flood Advert? That maximum length is now limited to 130 characters. Let's set the average waiting time until retransmitting to 300ms, as before. SF8: 3600 / (1.52 + 0.300) = 1,978 messages per hour. SF7: 3600 / (0.909 + 0.300) = 2,977 messages per hour. Now the difference increases to a factor of 1.50x. SF6 (just for fun): 3600 / (0.5525 + 0.300) = 4,222 messages per hour.
Dat lijkt nog steeds allemaal best, alleen moet dat wel uit dat “potje” Airtime komen en verdeeld worden over de aanwezige repeaters binnen “hoorafstand”. En daar is wat mee. Dan komen we bij de “Airtime-vretertjes”.	That still all seems fine, but it does have to come from that Airtime “pot” and be distributed among the available repeaters within “hearing distance”. And there is something about that. Then we come to the “Airtime hogs”.
De Airtime vretertjes Stel, je hebt 1 companion en 1 repeater. De companion verstuurt een bericht, wat opgevangen wordt door de repeater en herhaald. Dat is simpel zat. Maar: het versturen van dat bericht kost Airtime. En het herhalen door de repeater kost nóg een keer Airtime. Dus 1 bericht kost hier 2x Airtime.	The Airtime Eaters Suppose you have 1 companion and 1 repeater. The companion sends a message, which is received by the repeater and repeated. That is simple enough. But: sending that message costs Airtime. And repeating it by the repeater costs Airtime yet again. So 1 message costs 2x Airtime here.
+2 Stel dat we een tweede repeater toevoegen, dan zal ook die het bericht herhalen, waardoor er inmiddels 3x Airtime gebruikt wordt, voor dat ene bericht. Tot zover nog niets aan de hand. Zou de companion proberen een maximale hoeveelheid berichten binnen het uur te versturen, is de hoeveelheid die verstuurd KAN worden, inmiddels met een factor 3 gedaald. De beschikbare Airtime voor berichten moet immers nu met 3 apparaten gedeeld worden. Dit nog los van de verplichte duty-cycle van 10%.	+2 Suppose we add a second repeater; it will then also repeat the message, meaning that Airtime is now being used 3 times for that single message. So far, so good. If the companion were to attempt to send a maximum number of messages within the hour, the amount that CAN be sent would have dropped by a factor of 3. After all, the available Airtime for messages must now be shared among 3 devices. This is separate from the mandatory 10% duty cycle.
+3 Stel dat we nóg een repeater toevoegen. Met 3 repeaters en alles nog steeds lekker binnen elkaars “hoorafstand”. Nu wordt het spannend, want nu kan er meer gebeuren in het sturen en doorsturen van berichten. het scenario kan dan worden: Companion broadcasts (1x Airtime) Ontvangen door A en C A en C repeat; 1 zal de eerste zijn, bijv. A (2x Airtime) A wordt ontvangen door C en B C heeft het bericht al gezien en skipt het B repeats (1x Airtime) B wordt ontvangen door A en C, beiden skippen het repeaten, omdat ze het bericht al gezien hebben Het overslaan/skippen van het repeaten wordt behandeld door het hasSeen() mechanisme. Dit is een tabel met 128 regels die bijgehouden wordt en voorkomt dat in een korte tijd een repeater een bericht 2x repeat. Hier wordt 3x Airtime gebruikt voor 1 bericht. Zou ook hier de companion het maximale aantal berichten per uur versturen, houdt dat dus automatisch in dat het “potje Airtime” in hoog tempo leeg aan het raken is: de beschikbare ruimte voor unieke berichten wordt in principe 3x zo klein. Let wel: dat bereik en “hoorafstand” is ook afhankelijk van de antenne-hoogte (bijv. 10m), gebruikte antenne en dus de ERP. En dat kan toch gemakkelijk 5-10 km uit elkaar zijn, afhankelijk van de omgeving en haalbare Line Of-Sight.	+3 Let's say we add yet another repeater. With 3 repeaters and everything still nicely within each other's "hearing distance". Now it gets exciting, because now more can happen regarding the sending and forwarding of messages. The scenario could then be: Companion broadcasts (1x Airtime) Received by A and C A and C repeat; 1 will be the first, e.g. A (2x Airtime) A is received by C and B C has already seen the message and skips it B repeats (1x Airtime) B is received by A and C; both skip the repeating because they have already seen the message Skipping the repeating is handled by the hasSeen() mechanism. This is a table with 128 rows that is maintained and prevents a repeater from repeating a message twice in a short period of time. Here, 3x Airtime is used for 1 message. If the companion were to send the maximum number of messages per hour here as well, this automatically implies that the “Airtime pool” is running out rapidly: the available space for unique messages is, in principle, becoming 3 times smaller. Please note: that range and “hearing distance” also depend on the antenna height (e.g. 10m), the antenna used, and therefore the ERP. And that can easily be 5-10 km apart, depending on the environment and achievable Line Of-Sight.
+7 Nu is onze mesh een stuk groter, dus laten we dan kijken naar een situatie van een stapje groter, waarbij er 7 repeaters netjes bij elkaar staan; 1 in het midden en 6 er omheen. Allemaal bijvoorbeeld nog keurig in elkaars “hoorafstand”. Hier wordt het bericht van de Companion dus 7x herhaald, zodat er 8x Airtime gebruik wordt voor 1 bericht. Dat gaat wel hard met het delen van het potje Airtime.	+7 Now our mesh is quite a bit larger, so let's look at a situation a step up, where 7 repeaters are positioned neatly together; 1 in the middle and 6 around it. All, for example, still perfectly within each other's "hearing distance". Here, the Companion's message is therefore repeated 7 times, meaning Airtime is used 8 times for 1 message. That really adds up quickly when sharing the Airtime.
Buiten "hoorafstand" Hoe meer “neighbors” binnen “hoorafstand”, hoe erger dat kan worden. Het wordt niet heel veel beter als er van die 7 er 4 wel binnen “hoorafstand” zitten en 3 niet. Het mechanisme blijft in principe hetzelfde, alles wordt netjes gerepeat. Het vergroot alleen wel de kans op collisions bij die repeaters die net wel binnen "hoorafstand" zitten, versus de anderen die dat niet zitten. Bijvoorbeeld B en E kunnen elkaar niet direct horen, dus die kunnen tegelijkertijd gaan zenden. A zit in het midden en hoort beiden. Dat kan een probleem opleveren.	Outside of “hearing distance” The more “neighbors” within “hearing distance”, the worse it can get. It doesn't get much better if, of those 7, 4 are within “hearing distance” and 3 are not. The mechanism remains essentially the same; everything is repeated properly. However, it does increase the chance of collisions for those repeaters that are just within "hearing distance," compared to the others that are not. For example, B and E cannot hear each other directly, so they can start transmitting at the same time. A is in the middle and hears both. That can cause a problem.
+19 Plaats er nog een “ring” omheen en in principe is de chaos geboren. 19 repeaters, deels binnen “hoorafstand” en deels niet. En repeaten maar! De beschikbare Airtime slinkt waar je bij staat. In principe repeat iedere repeater een bericht van een companion en gaat het als flood over het netwerk. Hier worden er dan 20 repeats gedaan. Was het een "Goedemorgen!", dan is er al 20 x 0,54677 = 10,9 van de 3600 seconden verdwenen uit het potje Airtime. Met in mei 2026 landelijk al meer dan 3600 repeaters en de chaos wordt in beginsel alleen maar groter.	+19 Place another “ring” around it, and in principle, chaos is born. 19 repeaters, some within “hearing distance” and some not. And just keep repeating! The available Airtime dwindles before your very eyes. In principle, every repeater repeats a message from a companion, and it goes over the network as a flood. Here, 20 repeats are performed. If it was a "Good morning!", then 20 x 0.54677 = 10.9 of the 3600 seconds have already disappeared from the Airtime pool. With already more than 3600 repeaters nationwide by May 2026, the chaos is, in principle, only getting bigger.
“Atmospheric Conduits” Dit helpt echt. Of toch niet. Het maakt het wel leuk, ineens een bericht vanuit de UK of DE of… waar vandaan dan ook. Het zijn die toevalstreffers die een beetje extra charme aan de hobby geven. Het kan zonder verdere beperkingen zoals regions, alleen maar meer verkeer aan de lokale mesh toevoegen. Moet je dat willen? Eigenlijk is het een leuke DX verbinding die je niet of misschien niet zou willen missen. Dat hoeft ook niet, maar dan zou je de mesh en hoe je die gebruikt, iets anders moeten benaderen.	“Atmospheric Conduits” This really helps. Or maybe not. It does make it fun, though, suddenly a message from the UK or DE or… wherever. It are those lucky breaks that add a bit of extra charm to the hobby. Without further restrictions such as regions, it only adds more traffic to the local mesh. Is that something you should want? Actually, it is a nice DX connection that you might or wouldn't want to miss. You don't have to, but then you would have to have a different approach to the mesh and how you can use it.
Beperken van de chaos Door het hasSeen() mechanisme wordt het herhalen van herhalingen voorkomen. Is de tabel van 128 echter vol in korte tijd, door de hoeveelheid berichten en het door anderen repeaten in de tijd, kan de repeater op een goed moment het bericht weer als "nieuw" zien en weer repeaten. Dit hierboven kan beperkt worden door een goed ingestelde loop.detect, die op zijn beurt de hash van het pad bekijkt en bepaalt of er wel/niet nog een repeat mag plaatsvinden. Met veel repeaters, veel berichten en veel verschillende routes in de tijd, is het niet zo moeilijk om een netwerk voller te krijgen.	Limiting the chaos The hasSeen() mechanism prevents repeating. However, if the table of 128 fills up quickly due to the volume of messages and repeating by others over time, the repeater can, at an opportune moment, view the message as "new" again and repeat it once more. The above can be limited by a properly configured loop.detect, which in turn examines the hash of the path and determines whether or not another repeat is allowed. With many repeaters, many messages, and many different routes over time, it is not that difficult to make a network fuller.
Nog een tekortkoming van de loop.detect is, dat als deze te strikt staat, er berichten gemist kunnen worden op plekken waar je die extra repeat stiekem TOCH nodig hebt. In de mesh weet een repeater immers ook niet welke repeaters ten noorden, oosten, zuiden en westen van hem staan. Er is geen routing-mechanisme wat dat ondersteunt. Staat loop.detect strikt en er is altijd maar 1 repeat, dan kan het zijn dat een van de neighbors dus berichten kan missen en is het middel erger dan de kwaal. Dan vallen er wellicht alsnog gaten in het geheel, door het missen van die ene repeat, die noodzakelijk was om fouten/collisions te compenseren. Er zijn dus gevallen te over, waarbij 1x loop noodzaak kan worden, om het geheel te laten functioneren. Ten koste van de beschikbare Airtime. En da’s best naar, gezien de schaarste.	Another shortcoming of loop.detect is that if it is set too strictly, messages can be missed in places where you secretly DO need that extra repeat after all. In the mesh, after all, a repeater does not know which repeaters are located to the north, east, south, and west of it. There is no routing mechanism which supports that. If loop.detect is set strictly and there is always only 1 repeat, it is possible that one of the neighbors might miss messages, making the cure worse than the disease. In that case, gaps might still appear in the system due to the missing of that one repeat that was necessary to compensate for errors/collisions. So there are plenty of instances where a 1x loop may become necessary to make the whole thing function. At the expense of available airtime. And that is quite unfortunate, given the scarcity.
De "Super Repeater" Deze is tegelijkertijd een vloek en een zegen. De companion verstuurt een bericht. Deze wordt gerepeat door de hoog geplaatste repeater met een groot bereik. Het bericht van de companion bereikt een ver gelegen repeater dus snel. In de tussentijd wordt het bericht ook op de "normale" manier door het netwerk gerepeat.Als er veel berichten op het netwerk zijn, kan de hasSeen() buffer van die ver gelegen repeater al ververst zijn, voordat het oorspronkelijke bericht het via de "normale" route bereikt. Dan volgt alsnog een repeat. De loop.detect helpt niet in dit scenario.	The "Super Repeater" This is both a curse and a blessing. The companion sends a message. This is repeated by the high-mounted repeater with a large range. The companion's message therefore reaches a distant repeater quickly. In the meantime, the message is also repeated by the network in the "normal" way. If there are many messages on the network, the hasSeen() buffer of that distant repeater may already have been refreshed before the original message reaches it via the "normal" route. A repeat then follows anyway. loop.detect does not help in this scenario.
Er is overigens een hele uitgebreide uitleg rond tx.delay en int.thresh hier te vinden. Het zijn de andere essentiële parameters om in te stellen. Wil je maximaal resultaat? Zorg dan dat je instellingen optimaal zijn en wees ook in contact met de eigenaren van repeaters om je heen. N.B.: sommige regio’s/provincies zijn hier al echt serieus mee bezig. Inclusief een training/test om je eigen expertise-niveau te testen. Het is nog een "werk in uitvoering", dat wel. https://drenthenoodnetwerk.nl/MeshAcademy/course-hub.html	Incidentally, a very extensive explanation regarding tx.delay and int.thresh can be found here De_techniek_achter_verzenden_en_ontvangen_(Door:_HvM). These are the other essential parameters to configure. Do you want maximum results? Then ensure your settings are optimal and also stay in contact with the owners of repeaters around you. N.B.: some regions/provinces are already taking this very seriously. Including a training/test to assess your own level of expertise. It is still a "work in progress," though. https://drenthenoodnetwerk.nl/MeshAcademy/course-hub.html
Companions worden onderschat Wist je dat companions ook direct berichten kunnen ontvangen? Gewoon een bericht schrijven in een #-kanaal en als een andere companion binnen bereik is, wordt het bericht direct ontvangen, zonder tussenkomst van een repeater. Zou in het voorbeeld van hierboven, de 7 repeaters binnen “hoorafstand” allemaal companions zijn, kunnen er dus nog steeds berichten uitgewisseld worden. Met het voordeel dat een bericht slechts 1x Airtime kost, in plaats van 49x. Laat die even indalen. Probeer de potentie te zien. Als je het hebt over de mesh effectiever en efficiënter maken, ligt daar een enorme kans: Meer companions, minder repeaters. En wat repeaters/bridges in de moeilijke situaties. Dan is er in principe geen SF7 of zelfs SF6 nodig, om het (weer) snel te maken. En nog een leuke: die DX uit BE, DE of UK komt gewoon direct binnen op die, naar companion omgebouwde repeater. (Sorry guys)	Companions are underestimated Did you know that companions can also receive messages directly? Simply write a message in a #-channel, and if another companion is within range, the message is received immediately, without the intervention of a repeater. In the example above, if the 7 repeaters within “hearing distance” were all companions, messages could still be exchanged. With the advantage that a message costs only 1x Airtime, instead of 49x. Let that sink in for a moment. Try to see the potential. When it comes to making the mesh more effective and efficient, there is a huge opportunity there: More companions, fewer repeaters. And some repeaters/bridges in the difficult situations. Then basically, no SF7 or even SF6 is needed to make it fast (again). And another nice one: that DX from BE, DE, or the UK simply comes in directly on that repeater converted to a companion. (Sorry guys)
Verbonden of overmatig verbonden? Wat we in wezen hebben kunnen zien in de afgelopen -vele- maanden, is het volgende: Jij een repeater, je buurman een repeater, je andere buur 2 straten verderop een repeater etc., etc. De mesh is niet gewoon verbonden op diverse plaatsen, de mesh is over-verbonden in het kwadraat of erger. Teveel repeaters met veel teveel bereik, die Airtime elders simpelweg afsnoepen.	Connected or over-connected? What we have essentially been seeing over the past—many—months is the following: You a repeater, your neighbor a repeater, your other neighbor 2 streets away a repeater, etc., etc. The mesh is not just connected in various places; the mesh is over-connected squared, or worse. Too many repeaters with far too much range, simply stealing airtime elsewhere.
De hobby en de mesh Leuk en zo, jij ook je eigen repeater. Maar is het wel handig en de juiste route? Zijn er niet leukere dingen met meer companions te bedenken? Sterker nog: weer een extra repeater kan compleet averechts werken voor de mesh en uiteraard ook voor jezelf. Het “potje” Airtime is immers beperkt. De mesh loopt vol en “verbonden zijn” schiet zijn doel compleet voorbij. Om de knuppel in het hoenderhok te gooien: “Minder repeaters is meer beter!”. En ook: “Meer companions is meer beter!” Want onder de streep is het eigenlijk heel simpel: wij hebben met zijn allen in wezen de mogelijkheden binnen MeshCore onderschat. Ikzelf in aanvang ook. Het slim inzetten van alleen de echt benodigde repeaters en de rest van de nodes als een hele lading companions, is technisch en logisch gezien in wezen een veel beter antwoord op de problematiek. (Dit gaat wat weerstand oproepen...)	The hobby and the mesh Nice and all, you have your own repeater too. But is it really practical and the right path? Aren't there more fun things to think of involving more companions? In fact, yet another extra repeater can be completely counterproductive for the mesh and, of course, for yourself as well. After all, the "pool" of Airtime is limited. The mesh fills up and "being connected" completely misses its mark. To stir things up: "Fewer repeaters is more better!" And also: "More companions is more better!" Because the bottom line is actually very simple: we have all essentially underestimated the possibilities within MeshCore. As I did myself at the start, too. Smartly deploying only the truly necessary repeaters and the rest of the nodes as a whole load of companions is, technically and logically speaking, essentially a much better answer to the problem. (This is going to meet some resistance...)
Hoe dan? Hoog geplaatste repeaters/bridges zijn eigenlijk alleen nodig om groepen companions de mogelijkheid te bieden, om verder te kunnen komen dan die “hoorafstand”. De “Goedemorgen!” in #Public is dan in principe geen enkel probleem meer. Er kunnen 1000-en berichten in een uur hun doorgifte hebben, bij wijze van spreken. Zie de berekeningen hierboven. Er is dan ruimte zat. Plus dat er dan veel minder "Flood Adverts" rond hoeven te gaan. Een, twee of drie lokaal/centraal gunstig geplaatste repeaters, binnen bijvoorbeeld een straal van 10km kunnen dan al voldoende zijn. Die repeaters kunnen dan middels een brigde met een backbone koppelen. Die backbone bestaat dan weer uit hoog en gunstig geplaatste repeaters, met een groot bereik. Logisch gezien, kan dat dan de mesh weer gezond en snel maken.	How? High-mounted repeaters/bridges are actually only needed to offer groups of companions the possibility to reach further than that “hearing distance.” The “Good morning!” in #Public is then, in principle, no longer a problem at all. Thousands of messages can be transmitted in an hour, so to speak. See the calculations above. There is plenty of headroom then. Plus, far fewer “Flood Adverts” need to circulate. One, two, or three locally/centrally favorably placed repeaters, within a radius of 10 km for example, can already be sufficient. These repeaters can then connect to a backbone via a bridge. That backbone, in turn, consists of high-mounted and favorably placed repeaters with a large range. Logically speaking, this can make the mesh healthy and fast again.
De tegenwerpingen “Ja, maar ik heb die repeater op mijn dak nodig om met mijn companion in de woonkamer nog ergens te komen.” Snap ik. Heb ik nu ook. Om dezelfde reden. Zou ik mijn repeater op een gunstiger (hoger) gelegen plaats neer kunnen zetten, dan werd de huidige plaats van mijn repeater direct ingenomen door een companion met WiFi toegang (en webserver, het bestaat!). Dit omdat ik nu weet wat ik weet. En ik hoop dat dit weten overal doordringt. En dat er samenwerking ontstaat voor deze andere benadering.	The objections “Yes, but I need that repeater on my roof to get anywhere with my companion in the living room.” I get it. I have the same thing now. For the same reason. If I could place my repeater in a more favorable (higher) location, my repeater's current spot would immediately be taken over by a companion with WiFi access (and a web server, it exists!). This is because I now know what I know. And I hope that this knowledge permeates everywhere. And that cooperation emerges for this different approach.
Alternatieven Wel eens naar de mogelijkheid gekeken om je repeater op het dak companion te maken en met WiFi te verbinden? Er is inmiddels ook firmware voor een T-Deck en een Heltec `V4+Touch die hun eigen webserver kan draaien: https://github.com/dabeani/meshcoreterm Plus dat het technisch nog eens interessanter is qua mogelijkheden dan de basis repeater-firmware. Er zit heel veel meer aan functionaliteit in.	Alternatives Have you ever looked into the possibility of making your rooftop repeater a companion and connecting it to Wi-Fi? Firmware is now also available for a T-Deck and a Heltec V4+Touch that can run their own web server: https://github.com/dabeani/meshcoreterm Plus, technically it is even more interesting in terms of capabilities than the basic repeater firmware. It includes a lot more functionality.
Op de To-Do-lijst Een veld-test organiseren om te kijken of wat op kleine schaal al werkt, inderdaad ook op die grotere schaal ook werkt, dus in een gebied van een paar vierkante kilometer.	On the To-Do List Organize a field test to see if what already works on a small scale actually works on that larger scale as well, i.e., in an area of ​​a few square kilometers.

Gereed voor de feedback.

'73/Paul