Krótka odpowiedź: tylko częściowo. To przede wszystkim łączność alternatywna, która może wspierać działania w sytuacjach awaryjnych, ale nie zastąpi klasycznych kanałów awaryjnych.

Dlaczego nie jest to typowa łączność awaryjna: kanały awaryjne powinny być ciche, stale dostępne i o przewidywalnych, stabilnych trasach. Sieć mesh z natury jest oportunistyczna: zależy od liczby i zasilania węzłów, propagacji i ruchu w eterze. Bywa niestabilna, ma ograniczoną przepustowość i zasięg.

Do czego się nadaje: bardzo dobrze wspiera przesył danych (nie tylko krótkich tekstów), może działać jako uzupełnienie i zaplecze dla łączności awaryjnej.

Wniosek: traktuj to jako łączność alternatywną do przesyłu danych. W planach awaryjnych opieraj się na podstawowych, pewnych kanałach, a mesh wykorzystuj jako dodatkowe wsparcie. Sam projekt nie określał się jako łączność awaryjna, raczej jest to pomysł ludzi.

Aktualizacja z 2.5 do 2.6/2.7 może zresetować część ustawień. Klucze zostają zachowane. Szczegóły na stronie FW+.

Wejdź na pokój Matrix.

LOCAL_ONLY - Twój bedzie dokonywał przkazywania pakietów dalej tylko wtedy gdy:

1. znany jest FROM oraz TO danego pakietu
2. pakiet jest szyfrowany
3. pakiet nie jest publiczny, czyli nie jest to wiadomość typu broadcast jak NodeInfo czy wiadomość tekstowa na czacie ogólnym

Twój node bedzie nadal funkcjonował jak dytychczas, a sama konfiguracji dotyczy tylko przekazywania pakietów dalej (rebroadcast). Oznacza to, że odległe nody nie dokonają wymiany kluczy PKI (szyfrowania), nie zobaczą się, chyba, że dokonano to inną drogą lub wcześniej przed ustawieniam takiego trybu. Dane publiczne typu telemetria, pozycja, status opisowy i inne publiczne dane nie zostaną przekazane dalej. Lecz gdy nody wymieniły klucze PKI, to rozmowa prywatna (jak i inne kanały wymagajace szyfrowania FROM-TO) będzie możliwa.

---

KNOWN_ONLY - bardzo podobne do LOCAL_ONLY, lecz sprawdzane jest dodatkowo pole FROM węzła który przechodzi przez taki node. Node musi posiadać ten węzeł w swojej bazie lokalnej, czyli musiało dojść wcześniej do wymiany NodeInfo pomiędzy tymi węzłami gdy node był jeszcze w trybie ALL.

---

CORE_PORTNUMS_ONLY - działa jak ALL z ograniczeniem do portów CORE_PORTNUMS (NodeInfo, Text, Position, Telemetry, Routing). Wycina wszystkie inne porty (np. admin, private_app i inne). Może ograniczyć zakres przekazywania danych dalej. Nie zalecany gdy nie ma ważnego powodu.

FW+ pozwala na rozszerzenie możliwości swojego węzła. Można mianowicie:

1. Ustawić status tekstowy węzła który ndawany jest co jakiś czas, stały opis
2. Zmienić limity nadawania ChUtil
3. Wsparcie dla OnDemand requests czyli, zapytanie na żądanie o historie pakietów, statystyki węzła i jego sposób pracy, wykresy
4. Auto-Responder i Auto-Redirector dla automatycznych odpowiedzi i przekierowań
5. Sniffer, pozwala na przechwytywanie pakietów bez deszyfrowania, które są niepubliczne i nie są kierowane do nas. Usprawnia nadzorowanie
6. Możliwość zmiany pozycji węzła zdalnie
7. Możliwość podłączanie się do węzła w sposób standardowy po WiFi/BT gdy node jest w trybie managed
8. Wsparcie polskich znaków dla wyświetlaczy LCD/eInk
9. Nadawanie dodatkowych stastystyk węzła do sieci, historia nadwania sumaryczna, ostatnie 6 pomiarów w interwałach 10min
10. i inne :)

Tak, możesz używać APK+ bez FW+, ale nie będziesz miał dostępu do wszystkich funkcji FW+. Twój node jest transparentny pod tym względem, a dekodowaniem struktur zajmuje się sama aplikacja, nie Twój node. Natomiast jeżeli chesz mieć możliwość zmiany statusu opisowego swojego węzła, możliwość nadwania dodatkowych statystyk, zmiany parametrów pracy, obsługa rozszerzona sniffera i itp. swojego węzła to zmiana FW na FW+ jest wymagana.

Tak lecz nie jest to zalecane. Twój node może będzie ograniczony w konfiguracji, a np. włączenie sniffera może doprowadzić do nietypowego działania aplikacji.

Ilu specjalistów tyle rad i anten. Antene dobierasz do warunków i miejsca w którym jest węzeł. Nie ma anten uniwersalnych. Na początek zacząć warto od małej anteny, patyka, warto zbudować prostą antenę GP, która działa dosyć dobrze w arunkach miejskich. Duży pionowy dookólny bat o sporym zysku może okazać się gorszy niż prosta antena GP. Warto rozważyć kierunkowość i anteny panelowe (np. CYKLON 18dBi jeżli to antena łącząca odległe węzły). Jeżeli celujemy na propagacje lokalną to idziemy w anteny dookólne (np. coś z 868_Omni_antenna od Mikrotik). Warto rozważyć filtr pasmowy (callboost 868Mhz o niskich stratach). Niestety, sam temat anten to życiowe hobby :)

Krótka odpowiedź: w gęstych klastrach to zły kierunek.

W odludnych miejscach duże anteny o wysokim zysku i większa moc mogą mieć sens. Jednak w sieciach z wieloma węzłami lepiej budować gęstą siatkę krótkich i średnich połączeń. Ułatwia to tworzenie skutecznych tablic routingu (np. NextHop), gdzie wiadomo, przez kogo przekazać pakiet do celu.

Dlaczego „więcej” szkodzi:

• Zbyt duży zasięg powoduje więcej kolizji i zatkanie sieci; wszyscy dzielimy wąskie pasmo – jak w radiu CB.
• Wysoka moc i anteny o dużym zysku „zalewają” eter, pogarszając warunki pracy sąsiednich węzłów (gorszy SNR, więcej retransmisji).
• Masowe broadcasty (pozycja, telemetria) są kosztowne radiowo, bo słyszy je każdy. Preferuj unicast „od‑do”, który dobrze działa przy wsparciu routingu.

Rekomendacje:

• Budujmy wiele małych węzłów o niewielkim i średnim zasięgu oraz pojedyncze łącza dalekiego zasięgu (backbone) tam, gdzie naprawdę są potrzebne.
• Ograniczajmy broadcasty do minimum; stosujmy unicast tam, gdzie to możliwe.
• Dobierajmy moc i anteny z umiarem, do realnych warunków i potrzeb.

Gdy sieć będzie rosła, routing stanie się coraz lepszy. Umiar w mocy i antenach pomoże całej sieci działać stabilnie – przekonacie się o tym w praktyce.

W skrócie: stawiam na spójność i rozwój tego, co już działa.

Włożyłem bardzo dużo czasu i pracy w Meshtastic. Nie chcę promować alternatywnych, konkurencyjnych rozwiązań ani fragmentacji ekosystemu — na końcu wszyscy na tym tracimy. Lepiej poprawiać i udoskonalać to, co jest: przykładem jest FW+ i społeczność, która realnie pcha projekt do przodu.

Meshcore wprowadza dodatkowe podziały i nie jest zgodna z moją filozofią budowania jednej, interoperacyjnej sieci. Dlatego wybieram Meshtastic i aktywnie wspieram jej rozwój.

Objaw: brak nowego portu COM po podłączeniu płytki (TinyUSB/WinUSB).

Rozwiązanie (sterownik):

1. Otwórz Zadig (lub Menedżer urządzeń).
2. Znajdź urządzenie TinyUSB CDC (to Twój XIAO z Meshtastic).
3. Zmień sterownik z WinUSB na USB Serial (CDC ACM) / usbser:
   • W Zadig: Options → List All Devices → wybierz TinyUSB CDC.
   • W polu Driver wybierz usbserial i kliknij Replace Driver.
4. Odłącz i podłącz ponownie płytkę – powinien pojawić się port COM.

Alternatywnie: wgranie po UART (ESP‑Prog → XIAO):

• TXD0 (XIAO D6) ←→ RXD (ESP‑Prog) Program COM
• RXD0 (XIAO D7) ←→ TXD (ESP‑Prog) Program COM
• GND ↔ GND

Opcjonalne czyszczenie pamięci:

python -m esptool --chip esp32s3 -p COM7 erase_flash

Wgranie pełnego obrazu (zamień COM7 na swój port):

python -m esptool --chip esp32s3 -p COM7 --baud 460800 write_flash -z 0x0 firmware.factory.bin

Uwaga: COM7 to przykład; wybierz właściwy port COM widoczny w systemie.