diff --git a/docs/device_role/index.html b/docs/device_role/index.html index 8e9a333..dd0226c 100644 --- a/docs/device_role/index.html +++ b/docs/device_role/index.html @@ -3,13 +3,13 @@ Att välja rätt roll är avgörande för ett välfungerande meshnätverk. Om en enhet har fel roll märks det sällan för användaren själv, men det kan försämra nätverkets prestanda. Client CLIENT är standardrollen för Meshtastic och fungerar bäst i de flesta fall. Det är först när nätverket blir större som det blir viktigt att noggrant välja rätt roller.">

Enhetsroller i Meshtastic

Enhetsrollen i Meshtastic avgör hur en nod fungerar inom nätverket. Varje roll är optimerad för specifika användningsområden och påverkar hur meshnätverket fungerar.

Att välja rätt roll är avgörande för ett välfungerande meshnätverk. Om en enhet har fel roll märks det sällan för användaren själv, men det kan försämra nätverkets prestanda.

Client

CLIENT är standardrollen för Meshtastic och fungerar bäst i de flesta fall. Det är först när nätverket blir större som det blir viktigt att noggrant välja rätt roller.

En nod med rollen CLIENT deltar aktivt i meshnätverket och vidarebefordrar meddelanden enligt en algoritm. Förenklat innebär det att den nod som tar emot ett meddelande med svagast signal styrs att skicka det vidare. Om en CLIENT-nod hör ett meddelande men inte uppfattar att någon annan vidarebefordrar det, kommer den själv att skicka vidare.

I teorin innebär detta att noder längre bort oftast vidarebefordrar först. Men om en CLIENT-nod har dålig mottagning, exempelvis om den är placerad inomhus, kan den felaktigt sända vidare innan en mer optimalt placerad nod gör det. Detta kan leda till att nätverkets hopp förbrukas snabbare, vilket begränsar räckvidden.

Därför är det viktigt att CLIENT-noder i större meshnätverk placeras väl. I Stockholm bör de noder som har enhetsroll CLIENT vara noder placerade på balkonger och villahustak.

Client Mute

CLIENT_MUTE-rollen liknar CLIENT men med en viktig skillnad – den vidarebefordrar eller routar inga meddelanden. Detta gör den idealisk för större meshnätverk med hög nätverkstrafik, där extra routing kan orsaka överbelastning.

För de som har flera enheter på samma plats rekommenderas att max en enhet sätts som CLIENT medan resten får rollen CLIENT_MUTE för att minska onödig trafik och optimera nätverkets prestanda.

I Stockholm bör portabla noder och noder man har inomhus primärt vara CLIENT MUTE.

Router

ROUTER-rollen är designad för enheter som främst ska vidarebefordra meddelanden till andra enheter på meshet. Denna roll är ENDAST lämplig för stationära enheter placerade på extremt strategiska platser.

Routrar vidarebefordrar meddelanden från andra enheter direkt, medan andra noder väntar en liten stund innan de sänder. En strategiskt placerad ROUTER kan öka både räckvidden och stabiliteten i nätverket.

Routrar vidarebefordrar alltid, medan andra roller kan välja att inte vidarebefordra om de hör en granne vidarebefordra först.

För att optimera nätverkets prestanda och undvika kollisioner bör ROUTER-noder placeras så att så få noder som möjligt når mer än en ROUTER samtidigt. Detta då om ett meddelanden når flera routrar, så kommer de alla vidarebefordra meddelande samtidigt och störa ut varandra.

Router Late

ROUTER_LATE-rollen är lik ROUTER, den vidarebefordrar alla meddelanden, men den gör det under samma tidsfönster som CLIENT noder. Detta kan vara mycket användbart i områden där man når ut till meshen, men har svårt att ta emot alla meddelanden.

Repeater

REPEATER-rollen fungerar liknande ROUTER-rollen, men går ett steg längre genom att enbart vidarebefordra den meddelanden den tar emot. Den skickar inte ut några paket om sig själv, tex. nod-info.

Detta är en mycket effektiv roll. Men vi rekommenderar istället att använda ROUTER med optimerade inställningar, så att noden syns och registreras som en aktiv del av meshnätverket.

Senast ändrad February 26, 2025
\ No newline at end of file diff --git a/docs/index.xml b/docs/index.xml index 9ceb649..5868eae 100644 --- a/docs/index.xml +++ b/docs/index.xml @@ -22,7 +22,7 @@ <tr> <td>Max Hops</td> <td>4-5</td> - <td>Försök håll så lågt som möjligt</td> + <td>Försök hålla så lågt som möjligt</td> </tr> <tr> <td>Transmit Enabled</td> @@ -37,25 +37,25 @@ <tr> <td>OK to MQTT</td> <td>true</td> - <td>Kan stängas av föra att inte synas på karttjänsterna <sup id="fnref:2"><a href="#fn:2" class="footnote-ref" role="doc-noteref">2</a></sup></td> + <td>Kan stängas av för att inte synas på karttjänsterna <sup id="fnref:2"><a href="#fn:2" class="footnote-ref" role="doc-noteref">2</a></sup></td> </tr> </tbody> </table> <h3 id="max-hops">Max hops<a class="td-heading-self-link" href="#max-hops" aria-label="Heading self-link"></a></h3> -<p>Max hops anger i hur många led noder ska vidarebefordra ditt meddelande. Max hops sätts när paket sänds, en nod som vidarebefordrar ett paket minskar <em>max hops</em> med ett. Vad nodens som vidarebefordrar medelande har för max hopps påverkar inte.</p>Enhetsroller i Meshtastichttps://sthlm-mesh.se/docs/device_role/Mon, 01 Jan 0001 00:00:00 +0000https://sthlm-mesh.se/docs/device_role/<p>Enhetsrollen i Meshtastic avgör hur en nod fungerar inom nätverket. Varje roll är optimerad för specifika användningsområden och påverkar hur meshnätverket fungerar.</p> +<p>Max hops anger i hur många led noder ska vidarebefordra ditt meddelande. Max hops sätts när paket sänds, en nod som vidarebefordrar ett paket minskar <em>max hops</em> med ett. Vad noden som vidarebefordrar meddelandet har för max hops påverkar inte.</p>Enhetsroller i Meshtastichttps://sthlm-mesh.se/docs/device_role/Mon, 01 Jan 0001 00:00:00 +0000https://sthlm-mesh.se/docs/device_role/<p>Enhetsrollen i Meshtastic avgör hur en nod fungerar inom nätverket. Varje roll är optimerad för specifika användningsområden och påverkar hur meshnätverket fungerar.</p> <p>Att välja rätt roll är avgörande för ett välfungerande meshnätverk. Om en enhet har fel roll märks det sällan för användaren själv, men det kan försämra nätverkets prestanda.</p> <h2 id="client">Client<a class="td-heading-self-link" href="#client" aria-label="Heading self-link"></a></h2> <p><code>CLIENT</code> är <em>standardrollen</em> för Meshtastic och fungerar bäst i de flesta fall. Det är först när nätverket blir större som det blir viktigt att noggrant välja rätt roller.</p>Positionhttps://sthlm-mesh.se/docs/position/Mon, 01 Jan 0001 00:00:00 +0000https://sthlm-mesh.se/docs/position/<p>En nod kan dela sin position till alla andra noder över meshet. -Det gör det möjligt att se hur meshset sträcker sig geografiskt.</p> +Det gör det möjligt att se hur meshet sträcker sig geografiskt.</p> <p>För att dela position behövs antingen en GPS-modul eller en ansluten smartphone. -Alternativt så kan man sätta en <em>fixed location</em> där man själv anger koordinater, eller använder telefonens nuvarande position.</p> +Alternativt kan man sätta en <em>fixed location</em> där man själv anger koordinater eller använder telefonens nuvarande position.</p> <h2 id="position-precision">Position Precision<a class="td-heading-self-link" href="#position-precision" aria-label="Heading self-link"></a></h2> <p>Som standard kommer din nod inte dela med sig av sin exakta position. Den kommer skicka en position och en noggrannhet. Detta visar sig som en cirkel runt noden på karta, där din nod är någonstans inom den cirkeln.</p>MQTThttps://sthlm-mesh.se/docs/mqtt/Mon, 01 Jan 0001 00:00:00 +0000https://sthlm-mesh.se/docs/mqtt/<p>MQTT (Message Queuing Telemetry Transport) är ett protokoll för meddelandeöverföring som ofta används för IoT-kommunikation. Det är designat för att vara effektivt, även i nätverk med låg bandbredd eller hög latens.</p> <p>Vi använder MQTT för att kunna analysera meshet. Detta gör vi genom att enbart ha <em>uplink</em> igång. På så sätt kan vi tillhandahålla information om meshet som går att analysera med andra verktyg.</p> <p>Meshtastic har stöd för att använda MQTT för att <em>brygga</em> olika mesh-nätverk. I Stockholm har vi redan ett stort mesh, och MQTT-trafik skulle snabbt överbelasta meshet. -Därför har vi <em>downlink</em> avstängt samt <code>lora.ignore_mqtt</code> aktiverat.</p>Neighbor Infohttps://sthlm-mesh.se/docs/neighbor_info/Mon, 01 Jan 0001 00:00:00 +0000https://sthlm-mesh.se/docs/neighbor_info/<p><a href="https://meshtastic.org/docs/configuration/module/neighbor-info/">Neighbor Info modulen</a> samlar information om en nods grannar som den har direktkontakt med (0-hopp). Denna information kan sedan skickas över MQTT eller LoRa.</p> -<p>Informationen kan sedan visualiseras på karttjänster. Liam Cottles karta visar information om varje förbindelse. Utöver SNR visas även en terränggraf från <a href="HeyWhatsThat.com">HeyWhatsThat.com</a>.</p> +Därför har vi <em>downlink</em> avstängt samt <code>lora.ignore_mqtt</code> aktiverat.</p>Neighbor Infohttps://sthlm-mesh.se/docs/neighbor_info/Mon, 01 Jan 0001 00:00:00 +0000https://sthlm-mesh.se/docs/neighbor_info/<p><a href="https://meshtastic.org/docs/configuration/module/neighbor-info/">Neighbor Info-modulen</a> samlar information om en nods grannar som den har direktkontakt med (0-hopp). Denna information kan sedan skickas över MQTT eller LoRa.</p> +<p>Informationen kan sedan visualiseras på karttjänster. Liam Cottles karta visar information om varje förbindelse. Utöver SNR visas även en terränggraf från <a href="https://www.heywhatsthat.com">HeyWhatsThat.com</a>.</p> <figure> <img src="https://sthlm-mesh.se/images/docs/neighbors.png" width="400px" height="300px"/> diff --git a/docs/neighbor_info/index.html b/docs/neighbor_info/index.html index feb9b53..e5bde51 100644 --- a/docs/neighbor_info/index.html +++ b/docs/neighbor_info/index.html @@ -1,23 +1,23 @@ Neighbor Info | STHLM-MESH -

Neighbor Info

Neighbor Info modulen samlar information om en nods grannar som den har direktkontakt med (0-hopp). Denna information kan sedan skickas över MQTT eller LoRa.

Informationen kan sedan visualiseras på karttjänster. Liam Cottles karta visar information om varje förbindelse. Utöver SNR visas även en terränggraf från HeyWhatsThat.com.

Neighbor Info Konfiguration

Neighbor Info bör endast konfigureras på statiska noder, helst de som har kontakt med många andra noder. + Skapa dokumentationsfråga

Neighbor Info

Neighbor Info-modulen samlar information om en nods grannar som den har direktkontakt med (0-hopp). Denna information kan sedan skickas över MQTT eller LoRa.

Informationen kan sedan visualiseras på karttjänster. Liam Cottles karta visar information om varje förbindelse. Utöver SNR visas även en terränggraf från HeyWhatsThat.com.

Neighbor Info Konfiguration

Neighbor Info bör endast konfigureras på statiska noder, helst de som har kontakt med många andra noder. För portabla noder som flyttar sig blir Neighbor Info missvisande.

För noder med MQTT

För noder som har MQTT-uppkoppling kan modulen konfigureras enligt följande:


 neighbor_info:
     neighbor_info.enabled: True
     neighbor_info.transmit_over_lora: False
     neighbor_info.update_interval: 43200
-

För ROUTERS

Att skicka Neighbor Info över LoRa rekommenderas inte, eftersom det använder mycket bandbredd. +

För routrar

Att skicka Neighbor Info över LoRa rekommenderas inte, eftersom det använder mycket bandbredd. Men för vissa noder, särskilt routrar, kan det ändå vara intressant.

I senare versioner av firmware tillåts det inte att skicka Neighbor Info över standardkanaler, t.ex. LongFast. -Denna begränsning fungerar bättre i USA, där de olika kanalerna får sina egna frekvens-slotar. I EU spelar detta dock ingen roll.

För att kringgå denna begränsning måste man ta bort spärren i koden och själv kompilera sin firmware.

Senast ändrad February 23, 2025