pozostałe? należy skompilować samemu
ota_data
) plus samą aplikację. Nadaje się do pierwszego flashowania albo gdy układ/układ partycji się zmienił. Dzięki temu urządzenie prawie zawsze wstaje.
Dziwne, factory.bin nie resetuje node? Tak – to prawidłowe zachowanie i wynika z tego, jak Meshtastic buduje obraz firmware.factory.bin i jak działa bootloader ESP32: firmware.factory.bin jest "self-contained", zawiera bootloader, tabelę partycji, ota_data i samą aplikację pod odpowiednimi offsetami, ale nie zawsze ma pełny obraz całej pamięci flash – np. nie zawiera NVS (non-volatile storage, gdzie są ustawienia Meshtastica, kalibracja Wi-Fi, pary kluczy itp.). Dlatego wgrywając go wprost na 0x0, nadpisujesz bootloader+partitions+app, ale nie kasujesz całego flasha (NVS i inne partycje zostają, jeśli nie robisz erase_flash).
Dopisek FACTORY dotyczy kompletności obrazu a nie ustawień0x10000
). Działa tylko wtedy, gdy w pamięci jest już właściwy bootloader i zgodna tabela partycji (np. po wcześniejszym wgraniu "factory" lub przy aktualizacji OTA). Jeśli układ partycji/bootloader nie pasuje – node nie startuje albo wpada w boot-loop.
- FW+ wersja 27, bazowa wersja 2.7.9
- Storage & Forward (S&F): aktywne dostarczanie DM (wiadomości prywatnej, unicast, od-do) - celem jest zwiększenie skuteczności dostarczania wiadomości prywatnych w sieci.
- Serwer S&F przejmuje custody (przejęcie odpowiedzialności za dostarczenie) wiadomości prywatnej (DM), odsyła ACK do nadawcy i próbuje dostarczyć ją do węzła docelowego.
- Retry z nowym ID (tylko przy ponowieniach). Gdy dostarczenie nie powiedzie się przez deduplikację na kliencie (to samo (from,id)), serwer przy kolejnych próbach nadaje pakiet z nowym ID (treść pozostaje zaszyfrowana, źródło i metadane zachowane). Może to wpłynąć na korelację w statystykach, ale znacząco zwiększa skuteczność dostarczania.
- Handover między serwerami S&F: Jeśli po drodze jest inny serwer S&F, przejmie on custody i dalej spróbuje dostarczyć wiadomość (unikamy równoległych prób dzięki sygnałom custody).
- Broadcast bez custody. S&F nie "posiada" broadcastów; wykonuje co najwyżej pojedynczy, grzeczny re‑emit i udostępnia historię na żądanie.
- Poprzednio S&F działało wyłącznie pasywnie i "na żądanie"; teraz umożliwia aktywne, niezawodne (w miarę możliwości) dostarczanie DM w sieci.
- Rozwiązanie rozwojowe i eksperymentalne, wymaga dalszych testów i analizy.
- FW+ wersja 25, bazowa wersja 2.7.9
- Routing: zwiększony współczynnik uczenia się tras NextHop
- Routing: aktywne uczenie się tras podczas wyzwalania traceroute
- OnDemand: zabezpieczenie przed potencjalnym przepełnieniem bufora listy nodów
- FW+ wersja 24
- Routing: uczenie pasywne NextHop będzie brać pod uwagę tylko węzły bezpośrednie.
- Ograniczenie nadawania pozycji (skalowane), NodeInfo z 1h na 3h (bez skalowania), NeighborInfo dodatkowy czas skalowany. Musimy ograniczać broadcasty/flood gdzie to możliwe. Stawiamy na routing i unicasty.
- FW+ wersja 22
- Routing: dodano pasywne uczenie NextHop na podstawie traceroute (RouteDiscovery, sniff pasywny).
Nasz węzeł od teraz pasywnie analizuje trasy i ruch w sieci aby szybciej konwergować swoją tabelę routingu; mniej floodingu, szybsza konwergencja.
- OnDemand zwraca tabelę routingu NextHop do wglądu. Wejdź w detale węzłą, odnajdź "+ OnDemand" i zarequestuj tabelę routingu.
- NextHop posiada TTL (czas ważności trasy). Proaktywne odpytywanie węzłów (traceroute) o ekspansyjnym zakresie w przypadku gdy tabela NextHop jest przedawniona w znacznym
stopniu (np. brak ruchu w sieci, brak isotnych informacji o pakietach i sąsiadach). Pozwala to uniknąć problemów z dostarczaniem pakietów kierowanych do konkretnego węzła (problem pierwszej wiadomości).
- FW+ wersja 20
- Oportunistyczny flooding router; przystawka dla routingu opóźniająca rebroadcast pakietów zaleznie od SNR, liczby hopów, geolokalizacji oraz wielkości sieci.
Dotyczy tylko pakietów BROADCAST (publiczne, nie unicastowe tylko OD-DO). W skrócie: zamiast “wszyscy naraz”, mamy “kto ma sens, niech powtórzy pierwszy”. Włączona domyślnie.
Ocena skuteczności tego rozwiązania przyjdzie z czasem po zebraniu danych z eteru.
- Obsługa i konfiguracja dodana do APK+ w zakładce Firmware+ config
- Ograniczenia nadwania telemetrii, znaczne opóźnienia względem dużej sieci np. (telemetria: 50 nodów = 1h45min, 200 nodów = 13h) więcej
- Usprawiony Next-Hop routing: Pasywne DV‑ETX (Distance Vector + Expected Transmission Count) dla unicastów uczy się najlepszych tras na podstawie realnych dostaw (ACK/Reply) i jakości łącza (SNR->ETX).
Gdy trasa jest świeża i "pewna", unicast idzie jednym łańcuchem next‑hopów; gdy nie ma pewnej trasy, automatyczny fallback do floodingu zapewnia dostarczenie i jednocześnie "uczy" nową trasę. więcej
- FW+ wersja 18
- OnDemand, możliwość zwrócenia listy nodów o bezpośrednim połączeniu (DIRECT)(opcja zwrócenia wszystkich nodów pozostała)
- OnDemand, zwrócona lista nodów posiada od teraz informacje o geolokalizacji
- FW+ wersja 17
- OnDemand, zwracanie listy nodów o bezpośrednim połączeniu (DIRECT)
- Limiter telemetrii - ogranicza rebroadcast cudzej telemetrii do X pakietów na minutę. Przydatne gdy telemetria nadwana jest w zbyt dużej ilości lub oszczędzamy energię, ewentualnie eter. Opcja raczej dedykowana dla ROUTERA.(domyślnie wyłączony)
- Limiter pozycji - niektóre nody mogą nadawać pozycje zbyt często, co może obciążać sieć. Limiter ogranicza ilość rebroadcastowanych pozycji do X pakietów na minutę. Dotyczy tylko pozycji, które nie zmieniają się w czasie oraz są typu broadcast.
Wymiana pozycji (FROM->TO) lub nody będące w ruchu nie są ograniczane. Opcja raczej dedykowana dla ROUTERA. (domyślnie wyłączony)
- FW+ wersja 14
- Bazowa wersja 2.7.7
- Dodano wsparcie dla Seeed Xiao S3 i Station G2
- Moduł nadający status tekstowy węzła uwzględnia teraz skalowanie wielkości sieci. Im większa ilość nodów w zasięgu, tym dłuższe okna czasowe dla nadwania.
- Moduł nadająćy rozszerzoną telemetrię uwzglętnia także skalowanie wielkości sieci.
- FW+ wersja 13
- Od teraz moduł dokonujący odpowiedzi (wraz z SNR i RSSI) na słowo "ping" w zdaniu będzie reagował wyłącznie słowo na "pinger" lub "Pinger" (jako jedyny tekst w zapytaniu tekstowym).
- FW+ wersja 12
- Usunięto potencjalne problemy wgrywania FW+ na NRF.
- Z powodu bardzo małej ilości wolnej pamięci Flash dla np. RAK4631 usunięto feature ze zwracaniem listy nodów na polecnie "nodes". Funkcja ta pozostaje nadal w formie OnDemand (APK+).
- FW+ v11, scalenie z 2.6.3
- Naprawiono wariant NRF52 PROMICRO DIY TCXO (czarny ekran, błąd #3 LORA)
- Rewizja projektu, posprzątano ;)
- FW+ v10 i scalenie z 2.6.3
- onDemand Route Errors: Llista błedów routingu takich jak PKI_FAILED, TIMEOUT, NO_ROUTE, i innych wraz z liczbą ich wystąpień. Dane zbierane do restartu node.
- OnDemand Stats: licznik ilości pakietów nie przekazanych dalej z powodu hop-limit
- Wsparcie WiFI OTA od 2.6.2 dla ESP32
- Przejście na wersję wersję bazową 2.6. Aktualizacja z wersji 2.5 do 2.6 spowoduje częsciowy reset naszego node z pwodu innej struktury plików (klucze zostają zachowane). Wersja testowa, mogą pojawić się błędy. Wersja 2.5 nadal będzie możliwa do pobrania.
- Zwiększony limit nodów do 160 (eksperymentalnie, nie dotyczy to wyjątków takich jak rak4631, gdzie limit nadal pozostaje 80)
- Poprawki stabilności i optymalizacja, szczególnie dla urządzeń opartych o NRF (np. rak4631, t114 v2)
- Naprawiono problem zawieszania się node po zamianie ustawień FW+ poprzez BT
- Nowy protokół routingu NextHopRouter (mający dopiero wejść w oficjalnej wersji, w FW+ już jest). Zmniejsza liczbę retransmisji, buduje trasy w oparciu o ACK.
Nody są w stanie okreslić mniej-więcej trasę do noda ograniczając liczbę retransmisji "rozgłaszając wszystko wszędzie". W przypadku nodów, które nie posiadają
tego protokołu, system działa w trybie legacy, czyli FloodingRouterze po staremu. Skuteczność tego protokołu jest więc uzależniona od liczby nodów które
wspierają taki routing.
- Poprawka dla autorespondera, redirectora i polecenia "nodes", który mógł niepotrzebnie wykrywać wiadomości na kanale ogólnym
- AutoResponder - node może automatycznie odpowiadać na każdą wiadomość treścią jaką ustalimy. Dobre dla nodów zarządzalnych zdalnie. (APK+)
- AutoRedirect messages - mozliwość przekierowania każej odebranej wiadomości tekstowej przez node do innego node. (APK+)
- OnDemand, możliwość żądania statystyk (telemetry, local_stats i local_stats_extended) jako osobna struktura.
- OnDemand, wdrożono wersjonowanie FW+, możliwość żądania wersji FW+ na node począwszy od wersji 1
- OnDemand, dodano atrybut RX_BAD dla statystyk odczytu AirTime. Aktualnie obsługiwane pomiary w oknie 10 min to: RX, TX, RX_BAD
- Optymalizacje OnDemand, potencjalne poprawki związane z zapisywaniem zmian dla node (protobufs, ustawienia node)
- OnDemand, poprawki SNR dla zdalnej listy nodów, dodano obsługę liczby soków do struktury
- Nowe żądanie OnDemand - liczniki wykorzystania portów (telemetria, tekst, pozycja, inne). Zliczane od restartu urządzenia.
- Poprawki obsługi lokalnego żądania onDemand
- Nowe żądanie OnDemand - zwraca listę nodów węzła (ostatnia aktywnośc do 2h)
- Nowe żądanie OnDemand - simple ping, odpowiednik śledzenia trasy ale mniej obciążający mesh i szybszy
- Obsługa requestów na żądanie dla wybranych danych (rozwojowe). Można pobrać z APK+ historię statystyk RX w 40 pomiarach (6h pracy) z podziałem co 10 min (suma
odebranych)
- Nadawanie (local stats extended) średniej liczby odbieranych pakietów z godziny
- Nadawanie (local stats extended) ostatnich 6 pomiarów w interwałach 10 minutowych, sumy odebranych pakietów
- Poprawki nadawania telemetrii
- Możliwość ustawienia własnego ChUtil,AirUtilTx, polite util oraz non-polite. (polite - czyli przeważnie klient, pracuje w większych restrykcjach, np. do max
25% chutil/min, gdzie router może pracować nawet do 40%chutil/min, nie jest to warunek, niektóre pakiety są z zasady traktowane jako polite lub non-polite)
- Kolejne poprawki telemetrii
- Optymalizacja nadawania pakietów telemetrii lokalnej rozszerzonej, dłuższe okna czasowe pomiędzy pakietami
- Dodatkowa telemtria rozszerzona, nadawanie PSRAM free/total
- Drobne optymalizacje sprawdzania wolnego miejsca na flash
- BUG! Istotna poprawka związana z potwierdzeniem odebrania wiadomości i retransmisji, obsługa zwracanych błędów
- Więcej pakietów dla sniffera (np. admin, route)
- Polskie znaki dla wyświetlaczy e-ink (np. heltec wireless paper), thanks to andrzej137
- Nadwanie rozszerzonej telemetrii lokalnej over mesh, tzw. użycie CPU, dostępne miejsce na flash, dostępna pamięć ram
- Nowy protobuf (port 278), umożliwia nadawanie statusu opisowego węzła w stylu komunikatora.
- Zmieniono limity radiowe na mniej agresywne.
- Poprawki zarządzania kolejką pakietów dla sniffera. Poprawki wykrywania pakietów.
- Przetwarzanie nadchodzących pakietów neighborinfo, zawsze.
- Tryb routera zawsze przekazuje wszystko, a nie tylko CORE_PORTS (NodeInfo, Text, Position, Telemetry, Routing).
- Tekstowe polecenie "nodes" zwraca także ostatni czas kontaktu z węzłem.
- Wsparcie dla znaków OLED_PL.
- Poprawki nadwania telemetrii i jej detekcji na poziomie sniffera w aplikacji
- Rozróżnianie pakietów z telefonu od tych z meshu dla sniffera
- Przywrócono neighborinfo dla kanału głównego (co kilka godzin)
- Zoptymalizowane nadawanie lokalnej telemetrii, mniej pakietów
- Poprawianie pracy sniffera