Problemy z testami lacznosci

[ioioio]

Poprzez kopiowanie konfiguracji przed rozdaniem. Na razie wszystkie sa moje i sa u mnie na polce i je testuje wyrywkowo w trakcie wyjazdow w teren.

To mały obszar tylko obsłużysz.

[StaCh47]

Zgadza sie, dlatego mam przygotowane stacje z lepszymi antenami i panelami slonecznymi jako stacje bazowe ale na razie nie mam gdzie ich rozmiescic poza WRW2, ktora jest na Zoliborzu 15 km ode mnie. Poza tym na razie mam problem ze skonfigurowaniem zdalnego dostepu do konfiguracji w wersji oprogramowania 2.5.20 mimo podania klucza administracyjnego w 2 stacjach. To blokuje mi mozliwosc przeniesienia WRW3 na komin kilkanascie metrow wyzej.

[ioioio]

Zgadza sie, dlatego mam przygotowane stacje z lepszymi antenami i panelami slonecznymi jako stacje bazowe ale na razie nie mam gdzie ich rozmiescic poza WRW2, ktora jest na Zoliborzu 15 km ode mnie. Poza tym na razie mam problem ze skonfigurowaniem zdalnego dostepu do konfiguracji w wersji oprogramowania 2.5.20 mimo podania klucza administracyjnego w 2 stacjach. To blokuje mi mozliwosc przeniesienia WRW3 na komin kilkanascie metrow wyzej.

Nie bardzo rozumiem. Nie widzę w tym korzystania z istniejącej infrastruktury co jest moim zdaniem kluczowe.

[StaCh47]

W zasadzie wlasnie nie ma kluczowej struktury o czym pisalem. Wiekszosc stacji pracuje dorywczo i zmienila kodowanie. Oczywiscie jest kilka stacji dzialajacych calodobowo ale wiekszosc ma kiepskie lokalizacje i stad maly zasieg. W krytycznej sytuacji bede musial wybrac lokalizacje dla grupy i wtedy rozmiescic stale stacje z panelami i rozdac ruchome. Gdym mial stacje stala WRW3 na kominie to w okolicy mam 2 pasma lesne z pofaldowanym terenem tylko trzeba by zorganizowac jakies tymczasowe schronienia.

[Pietrow]

Hmmm... Przyznam, ze ponizszy post nieco nastawil moja psychike w strone osoby jego autora. Spedzilem nieco czasu w delegacji w dosc odleglej strefie czasowej. Ale obecnie jestem juz (z)wrocony. Odpiszmy zatem coby walor informacyjny z tej postowni jakis uczynic.

Optymalizacja pod kątem zużycia pasma/energii zamiast zasięgu.

Szanowny... Ty optymalizujesz (znaczy "minimalizujesz") zuzycie energii przez noda LoRa. Rozumiem Twoj cel. Moj cel jest inny i bede wdzieczny, jesli pozwolisz mi przy nim pozostac. Dziekuje.

Meshtastic jako taki nie jest ani lokalny ani rozległy. Zależy jak się go użyje.

I tak, i nie. Systemy meshowe nie grzesza optymalnym uzyciem pasma. W moim wpisie chodzilo o to, ze liczba rozgloszen rosnie lawinowo wraz z iloscia nodow w sieci. Szczegolnie w przypadku rozsylania rozgloszen z duza iloscia hopow. A co za tym idzie - proby postawienia sieci laczacej wiele miast koncza sie tym, ze w miescie A fruwaja rozgloszenia z miasta B. No i konczy sie "czas antenowy". A potem miasto takie jak Wroclaw podejmuje decyzje, by z LongFast przejsc na MediumFast - co z jednej strony skraca czas emisji datagramow, ale z drugiej strony zabiera kilka cennych dB z bilansu lacza antenowego - co moze skutkowac utrata lacznosci miedzy miastami A i B. Osobiscie odczuwam lekkie rozbawienie obserwujac to gonienie wlasnego ogonka w zabawie w wiecej - szybciej - slabiej - mniej. Fajna karuzela zachowan.

Zwykłe powiększanie ilości stacji. Burza rozpoczyna się jak nie wiadomo gdzie stacja jest, w tym jak nadaje do wszystkich.

Hmmm... Wybacz, ale nie zrozumialem Twojego napisania. Sugerujesz, ze duza ilosc nodow o ustalonej lokalizacji nie spowoduje burzy rozgloszen? No OK. Nie wiem na jakiej podstawie tak twierdzisz, ale nie odmawiam Ci prawa do Twoich wlasnych twierdzen.

Pewnie zwykle jest, ale bez tego wiadomości po prostu nie przejdą. Taka ilość przeskoków to naprawdę nic w prawdziwych sieciach. Wystarczy dowolny tracerout na przypadkowy host w internecie.

Oj, Szanowny... Ale nie mieszaj mi tu tematow, prosze. Rozmawiamy o sieci mesh z silnie ograniczonym dostepem do medium transmisyjnego. Tutaj nod, ktory wyransmitowal datagram z ustawionymi 7 hopami spowoduje, ze 5 czy 6 nod w kolejnosci sluchania zrobi retransmisje tego datagramu - nawet wtedy, gdy adresat znalazl sie na 1 czy 2 hopie. I kazda taka retransmisja zuzyje medium transmisyjne.
Polecenie traceroute / tracert (nie "tracerout" jak napisales) protokolu ICMP nie zrobi smietnika, poniewaz routery sieciowe znaja adresacje obslugiwane przez swoich sasiadow (tabela routingu sie to-to nazywa) i taki tracert'owy pakiet nie bedzie przez router wyslany na jego wszystkie porty wychodzace, a jedynie na port, na ktorym router wedle swojej wiedzy spodziewa sie znalesc pule adresowa w ktorej znajduje sie adresat. Czy sugerujesz, ze LoRa jest tak samo szpryciachna? Jesli tak, to prosze o jakis link do zrodla wiedzy - chetnie sie doucze. Dziekuje.

No ale ... to masz realne testy a nie optymistyczne.

A! Czyli Ty do testow nie uzywalbys wydzielonego srodowiska testowego? Nawet w sytuacji, gdy masz pewnosc, ze z powodu zasmiecenia pasma radiowego ruchem lokalnym test dalekosiezny w tym samym pasmie czestotliwosci nie ma prawa sie udac? Dziwne podejscie. Ale znow - jest to Twoje podejscie i masz do niego calkowite prawo. Mnie pozwol jednak na testowanie w srodowisku nie obarczonym zakloceniami.

Dobra, ale to testujecie jedno połączenie punkt-punkt a sieci w tym mesh są po to są dało się wykorzystać wiele połączeń punkt-punkt do łączności na większe dystanse.

I znow - masz racje i racji nie masz. Mylnie zakladasz, ze skoro probuje uzyc LoRa (czy to pod Meshtastikiem czy pod MeshCore), to stawiam siec meshowa. A od kiedy to uzyte medium definiuje typ sieci? Zauwazylem, ze siegasz po analogie ethernetowe, wiec popatrz na to w taki sposob: na Ethernecie moge rozsylac ramki broadcastowe, ale moge tez wolac unicastem tylko MAC interesujacego mnie adresata. I w jednym i w drugim przypadku dzialam na golym Ethernecie. A skutki mam jakby nieco odmienne Proponuje zrozumienie, ze siec 1:1 jest szczegolnym przypadkiem sieci 1:n czy n:1. Twierdzenie, ze uzywajac narzedzi meshowych musze zbudowac siec meshowa uwazam za bledne z natury.
W moim przypadku motywacja jest taka, by nie miec zaleznosci do urzadzen, na ktore nie mam wplywu. Chodzi o to, by w sytuacji SHTF moc wlasnymi zasobami zapewnic sobie minimum lacznosci. Nie moge liczyc na wezel postawiony zabawkowo przez jakiegos uczniaka, ktory wylaczy wezel gdy znudzi mu sie temat. Mam nadzieje, ze teraz i motywacja i przyjety sposob wykonania nie budza juz watpliwosci.

Przy czym jest jeszcze problem zdolności radiowych urządzeń, że urządzenia muszą się wzajemnie widzieć. Stacja która nadaje z dużą mocą niekoniecznie będzie w stanie odebrać stację o małej mocy, która jej odpowiada.

Alez to jest oczywista oczywistosc. I nie twierdze, ze w naszym przypadku testowym mamy asymetrie budzetu lacza radiowego. Po obu stronach sa konkretne anteny panelowe z dobrze ustawionymi azymutami (elewacje sobie odpuscilismy - anteny nadaja poziomo, a roznica w wysokosciach npm nodow miesci sie w aperturze anten).
Inna rzecz, ze dla polaczen LoRa na duze dystansy spora zaleta byloby rozdzielenie toru nadawczego i odbiorczego. Wtedy na torach nadawczych zakladamy wysokosprawne anteny, a na torach odbiorczych uzywamy anten o mniejszej czulosci. Dostajemy dzieki temu poprawe SNR. Tylko ze dostepne moduly radiowe maja niestety wspolne zlacze antenowe dla nadajnika i odbiornika.

Pisałem tutaj w innym miejscu o tym, że brakuje w Meshtasticu pracy z wieloma interfejsami i dynamicznej zmiany parametrów połączenia. Nie da się tak całkiem pogodzić ruchu lokalnego z ruchem odległym.

Wiesz... Dynamiczna zmiana kodowania to nie jest rzecz prosta w sytuacji, gdy sluchajace siebie nody nie wiedza o takiej zmianie i nie za bardzo maja jak sie o niej poinformowac. Jasne, mozna kombinowac z losowym skakaniem po modulacjach do skutku, ale to wymaga, by odbiornik i nadajnik maly rozne okresy takich zmian (inaczej maleje prawdopodobienstwo, ze sie losowo spotkaja na takiej samej modulacji). No i rosylanie testowych datagramow tez zajmie czas w powietrzu. Wybacz, ale to nie jest takie proste.
W telefonii komorkowej modulacje zmieniane sa przez terminal na polecenie stacji bazowej (Ty tam! Samsung Kowalskiego! Estymaty kanalu radiowego w twoja strone mam slabe, zaklocenia spore, w kilku podzakresach czestotliwosci wogole giniesz mi w zakloceniach, wiec jak nastepnym razem bedziesz robil uplink, to nie uzywaj podzakresu czestotliwosci xx-yy, a na pozostalych czestotliwosciach kanalu radiowego nadawaj do mnie w QAM64 a nie w QAM1024. Wykonac!). Ale to dziala tez w druga strone - terminal podaje stacji bazowej swoje estymaty kanalu radiowego i stacha bazowa wie, jak najlepiej dosiegnac takiego terminala. W LoRa nie ma jednostek zarzadzajacych ruchem, wiec postulowane przez Ciebie zmiany modulacji w locie robia sie tematem na ksiazke zyczen.

Czyli na wszystkich węzłach gdzie potencjalnie te ruchome obiekty mogą znajdować się trzeba te kanały zdefiniować. Jak chcesz to zrobić?

Chwilunia! Albo nie doczytalem czegos i ustrojstwach LoRa, albo czegos nie rozumiem. Albo jedno i drugie jednoczesnie...
Czy nie jest tak, ze nod przekaze dalej dowolna wiadomosc z dowolnego kanalu? Nod musi zrozumiec naglowek (a ten szyfrowany nie jest), natomiast dane z datagramu moze przepchnac dalej bez koniecznosci ich dekodowania. Czy wezly uczestniczace w forwardowaniu wiadomosci faktycznie musza znac i nazwe kanalu i jego szyfrowanie zeby przekazac wiadomosc? Serio-serio?

No... To sie wypisalem. Tylko prosze burzy nie robic.

[ioioio]

Hmmm... Przyznam, ze ponizszy post nieco nastawil moja psychike w strone osoby jego autora. Spedzilem nieco czasu w delegacji w dosc odleglej strefie czasowej. Ale obecnie jestem juz (z)wrocony. Odpiszmy zatem coby walor informacyjny z tej postowni jakis uczynic.

Optymalizacja pod kątem zużycia pasma/energii zamiast zasięgu.

Szanowny... Ty optymalizujesz (znaczy "minimalizujesz") zuzycie energii przez noda LoRa. Rozumiem Twoj cel. Moj cel jest inny i bede wdzieczny, jesli pozwolisz mi przy nim pozostac. Dziekuje.

No to właśnie pisałem, że nie ma coś się dziwić, że ktoś optymalizuje. A co ja robię to w tej dyskusji nie ma żadnego znaczenia. Żenujące są takie personalne wypowiedzi.

Meshtastic jako taki nie jest ani lokalny ani rozległy. Zależy jak się go użyje.

I tak, i nie. Systemy meshowe nie grzesza optymalnym uzyciem pasma. W moim wpisie chodzilo o to, ze liczba rozgloszen rosnie lawinowo wraz z iloscia nodow w sieci. Szczegolnie w przypadku rozsylania rozgloszen z duza iloscia hopow. A co za tym idzie - proby postawienia sieci laczacej wiele miast koncza sie tym, ze w miescie A fruwaja rozgloszenia z miasta B. No i konczy sie "czas antenowy". A potem miasto takie jak Wroclaw podejmuje decyzje, by z LongFast przejsc na MediumFast - co z jednej strony skraca czas emisji datagramow, ale z drugiej strony zabiera kilka cennych dB z bilansu lacza antenowego - co moze skutkowac utrata lacznosci miedzy miastami A i B. Osobiscie odczuwam lekkie rozbawienie obserwujac to gonienie wlasnego ogonka w zabawie w wiecej - szybciej - slabiej - mniej. Fajna karuzela zachowan.

To jest tylko słabość Meshtastica, że nie zapewnia wielu interfejsów z różnymi ustawieniami. Różne ustawienia tak czy siak można zrobić i nie tylko o to chodzi jaki zasięg jest tylko w jakich warunkach.

Zwykłe powiększanie ilości stacji. Burza rozpoczyna się jak nie wiadomo gdzie stacja jest, w tym jak nadaje do wszystkich.

Hmmm... Wybacz, ale nie zrozumialem Twojego napisania. Sugerujesz, ze duza ilosc nodow o ustalonej lokalizacji nie spowoduje burzy rozgloszen? No OK. Nie wiem na jakiej podstawie tak twierdzisz, ale nie odmawiam Ci prawa do Twoich wlasnych twierdzen.

Na podstawie tego, co wiadomo o protokole, że od 2.6 jednak próbuje zbierać informacje o ruchu i kierować pakiety do odpowiedniego węzła a nie wszystkich co oczywiście nie jest możliwe, jak takich informacji nie ma.

Pewnie zwykle jest, ale bez tego wiadomości po prostu nie przejdą. Taka ilość przeskoków to naprawdę nic w prawdziwych sieciach. Wystarczy dowolny tracerout na przypadkowy host w internecie.

Oj, Szanowny... Ale nie mieszaj mi tu tematow, prosze. Rozmawiamy o sieci mesh z silnie ograniczonym dostepem do medium transmisyjnego. Tutaj nod, ktory wyransmitowal datagram z ustawionymi 7 hopami spowoduje, ze 5 czy 6 nod w kolejnosci sluchania zrobi retransmisje tego datagramu - nawet wtedy, gdy adresat znalazl sie na 1 czy 2 hopie.

Jak znalazł się wcześniej to znalazł i nie dotrze do 5 czy 6. No chyba, że jednak nie znalazł się i jakoś jednak dotarł.

I kazda taka retransmisja zuzyje medium transmisyjne.
Polecenie traceroute / tracert (nie "tracerout" jak napisales) protokolu ICMP nie zrobi smietnika, poniewaz routery sieciowe znaja adresacje obslugiwane przez swoich sasiadow (tabela routingu sie to-to nazywa) i taki tracert'owy pakiet nie bedzie przez router wyslany na jego wszystkie porty wychodzace, a jedynie na port, na ktorym router wedle swojej wiedzy spodziewa sie znalesc pule adresowa w ktorej znajduje sie adresat. Czy sugerujesz, ze LoRa jest tak samo szpryciachna? Jesli tak, to prosze o jakis link do zrodla wiedzy - chetnie sie doucze. Dziekuje.

1. LoRa to nieco powyżej medium transmisyjnego ISM. Po prostu przesyłanie do kogoś innego w eterze techniką chirp. Ktoś sobie odbierze albo nie odbierze. Nie ma żadnego przesyłania dalej.
2. To fizyczne połączenie za pomocą LoRa wykorzystuje się do realizacji różnych usług między innymi mesh. Z dobrze znanych to LoRaWAN, APRS, Meshtastic czy Meshcore.
3. Opis protokołu Meshtastic znajduje się witrynie projektu https://meshtastic.org/docs/overview/mesh-algo/

No ale ... to masz realne testy a nie optymistyczne.

A! Czyli Ty do testow nie uzywalbys wydzielonego srodowiska testowego? Nawet w sytuacji, gdy masz pewnosc, ze z powodu zasmiecenia pasma radiowego ruchem lokalnym test dalekosiezny w tym samym pasmie czestotliwosci nie ma prawa sie udac? Dziwne podejscie. Ale znow - jest to Twoje podejscie i masz do niego calkowite prawo. Mnie pozwol jednak na testowanie w srodowisku nie obarczonym zakloceniami.

No ale co konkretnie dla Was wnosi testowanie Meshtastica w wyizolowanym i zupełnie niezakłóconym środowisku jak w realnych nigdy tak nie będzie. Ktoś naciśnie dzwonek przy bramie i się zakłóci bo niby czemu nie.

Dobra, ale to testujecie jedno połączenie punkt-punkt a sieci w tym mesh są po to są dało się wykorzystać wiele połączeń punkt-punkt do łączności na większe dystanse.

I znow - masz racje i racji nie masz. Mylnie zakladasz, ze skoro probuje uzyc LoRa (czy to pod Meshtastikiem czy pod MeshCore), to stawiam siec meshowa. A od kiedy to uzyte medium definiuje tym sieci? Lubisz analogie ethernetowe, wiec popatrz na to w taki sposob: na Ethernecie moge rozsylac ramki broadcastowe, ale moge tez wolac unicastem tylko MAC interesujacego mnie adresata. I w jednym i w drugim przypadku dzialam na golym Ethernecie. A skutki mam jakby nieco odmienne Proponuje zrozumienie, ze siec 1:1 jest szczegolnym przypadkiem sieci 1:n czy n:1. Twierdzenie, ze uzywajac narzedzi meshowych musze zbudowac siec meshowa uwazam za bledne z natury.

Ja niczego nie zakładam. Napisałem tylko to, co ma miejsce w Waszych testach. Narzekasz na to, że ktoś robi w twojej okolicy mesh gdy sam chcesz nie-mesh.

Przy czym jest jeszcze problem zdolności radiowych urządzeń, że urządzenia muszą się wzajemnie widzieć. Stacja która nadaje z dużą mocą niekoniecznie będzie w stanie odebrać stację o małej mocy, która jej odpowiada.

Alez to jest oczywista oczywistosc. I nie twierdze, ze w naszym przypadku testowym mamy asymetrie budzetu lacza radiowego. Po obu stronach sa konkretne anteny panelowe z dobrze ustawionymi azymutami (elewacje sobie odpuscilismy - anteny nadaja poziomo, a roznica w wysokosciach npm nodow miesci sie w aperturze anten).

Pisałem tutaj w innym miejscu o tym, że brakuje w Meshtasticu pracy z wieloma interfejsami i dynamicznej zmiany parametrów połączenia. Nie da się tak całkiem pogodzić ruchu lokalnego z ruchem odległym.

Wiesz... Dynamiczna zmiana kodowania to nie jest rzecz prosta w sytuacji, gdy sluchajace siebie nody nie wiedza o takiej zmianie i nie za bardzo maja jak sie o niej poinformowac. Jasne, mozna kombinowac z losowym skakaniem po modulacjach do skutku, ale to wymaga, by odbiornik i nadajnik maly rozne okresy takich zmian (inaczej maleje prawdopodobienstwo, ze sie losowo spotkaja na takiej samej modulacji). No i rosylanie testowych datagramow tez zajmie czas w powietrzu. Wybacz, ale to nie jest takie proste.

Jaki problem rozszerzyć NodeInfo by informacje były szerzej dostępne. A przemiatanie to zupełny banał, robimy to ręcznie.

W telefonii komorkowej modulacje zmieniane sa przez terminal na polecenie stacji bazowej (Ty tam! Samsung Kowalskiego! Estymaty kanalu radiowego w twoja strone mam slabe, zaklocenia spore, w kilku podzakresach czestotliwosci wogole giniesz mi w zakloceniach, wiec jak nastepnym razem bedziesz robil uplink, to nie uzywaj podzakresu czestotliwosci xx-yy, a na pozostalych czestotliwosciach kanalu radiowego nadawaj do mnie w QAM64 a nie w QAM1024. Wykonac!). Ale to dziala tez w druga strone - terminal podaje stacji bazowej swoje estymaty kanalu radiowego i stacha bazowa wie, jak najlepiej dosiegnac takiego terminala. W LoRa nie ma jednostek zarzadzajacych ruchem, wiec postulowane przez Ciebie zmiany modulacji w locie robia sie tematem na ksiazke zyczen.

To jest tylko kwestia braku wielu interfejsów a nie tego czy ktoś zarządza.

Czyli na wszystkich węzłach gdzie potencjalnie te ruchome obiekty mogą znajdować się trzeba te kanały zdefiniować. Jak chcesz to zrobić?

Chwilunia! Albo nie doczytalem czegos i ustrojstwach LoRa, albo czegos nie rozumiem. Albo jedno i drugie jednoczesnie...
Czy nie jest tak, ze nod przekaze dalej dowolna wiadomosc z dowolnego kanalu? Nod musi zrozumiec naglowek (a ten szyfrowany nie jest), natomiast dane z datagramu moze przepchnac dalej bez koniecznosci ich dekodowania. Czy wezly uczestniczace w forwardowaniu wiadomosci faktycznie musza znac i nazwe kanalu i jego szyfrowanie zeby przekazac wiadomosc? Serio-serio?

No... To sie wypisalem. Tylko prosze burzy nie robic.

W nieszyfrowanym nagłówku jest channel_hash.

[Pietrow]

No to właśnie pisałem, że nie ma coś się dziwić, że ktoś optymalizuje. A co ja robię to w tej dyskusji nie ma żadnego znaczenia. Żenujące są takie personalne wypowiedzi.

Otoz wlasnie napisales cos, czego nie umialem dowiazac do kontekstu dialogu.
Co do personalnych wypowiedzi - nie masz Ty przypadkiem na imie Slawek? Bo mam tu lokalnie takiego jednego Meshtasticowego Slawka, ktory mocno przeczulony personalnie jest

To jest tylko słabość Meshtastica, że nie zapewnia wielu interfejsów z różnymi ustawieniami. Różne ustawienia tak czy siak można zrobić i nie tylko o to chodzi jaki zasięg jest tylko w jakich warunkach.

Ale wiesz, ze powtarzasz tekst? Wiesz, prawda?

Na podstawie tego, co wiadomo o protokole, że od 2.6 jednak próbuje zbierać informacje o ruchu i kierować pakiety do odpowiedniego węzła a nie wszystkich co oczywiście nie jest możliwe, jak takich informacji nie ma.

Znow zagubil sie kontekst. Co z tego, ze sciezke do adresata mozna zoptymalizowac i "zamrozic" jak w Meshcore, kiedy kazdy przekazany przez posrednika datagram zajmuje czas tego samego interfejsu radiowego? Analogiem teleinformatycznym jest "extender WiFi", ktory sprawia, ze po tym samym pasmie WiFi informacja przesylana jest podwojnie. Raz ze zrodla do extendera, i drugi raz z ekstendera do docelowego adresata (co oznacza, ze i pierwotne zrodlo ten sygnal slyszy, dzialajace w WiFi algorytmy Listen Before Talk przyblokowuja innym uzytkownikom mozliwosc uzytkowania pasma radiowego, gdyz "idzie transmisja" - coz, ze duplikat, wazne, ze idzie. I tak na marginesie: celowo upraszczam temat. Jesli ktos zechce poznac mechanizmy pracy sieci WiFi, to wezmie sobie ktoras ze specek 802.11 i sie z nimi zapozna u zrodla.

Jak znalazł się wcześniej to znalazł i nie dotrze do 5 czy 6. No chyba, że jednak nie znalazł się i jakoś jednak dotarł.

Cos mam wrazenie, ze nody posredniczace niekoniecznie wiedza, czy dany datagram znalazl juz adresata. Nie jest aby tak, ze nod zobaczy na biezacy stan HopLimit i jesli nie zero - zrobi forwarda? Chyba, ze nody analizuja ruch pod katem zaslyszanych ACKow - to jednak spowodowaloby znaczne opoznienia na forwardzie (odebralem, zbuforuje na x sekund, poslucham czy ktos nadal ACKa na nadawce zbuforowanego pakietu, jesli nie, to po x sekundach robie forwarda - malo optymalne by to bylo).

1. LoRa to nieco powyżej medium transmisyjnego ISM. Po prostu przesyłanie do kogoś innego w eterze techniką chirp. Ktoś sobie odbierze albo nie odbierze. Nie ma żadnego przesyłania dalej.

Hmmm... Mam wrazenie, ze mylisz warstwy modelu ISO/OSI. Owszem, na warstwie transportowej masz glupiutki transport z modulacja CHIRP. Tyle, ze pietro wyzej siedzi warstwa protokolu, ktora naklada naglowki i formaty. A nad nia siedzi z kolei warstwa aplikacji - i tu nam rezyduje przykladowo Meshtastic. Zastanawia mnie, ktora z tych warstw odpowiada za forwardy. Prosiloby sie, zeby zrobila to warstwa protokolu. Calkiem mozliwe jednak, ze robi to dopiero warstwa aplikacji.

2. To fizyczne połączenie za pomocą LoRa wykorzystuje się do realizacji różnych usług między innymi mesh. Z dobrze znanych to LoRaWAN, APRS, Meshtastic czy Meshcore.

Zaiste. To nie byla informacja nowa. Stos protokolow tudziez nadmieniony wyzej model ISO/OSI wchodza nam do gry.

3. Opis protokołu Meshtastic znajduje się witrynie projektu https://meshtastic.org/docs/overview/mesh-algo/

Dziekuje. Wiem, bywalem, czytywalem. Byc moze nawet cos tam udalo mi sie zrozumiec.

No ale co konkretnie dla Was wnosi testowanie Meshtastica w wyizolowanym i zupełnie niezakłóconym środowisku jak w realnych nigdy tak nie będzie. Ktoś naciśnie dzwonek przy bramie i się zakłóci bo niby czemu nie.

Widzisz... Dzwonek u bramy zakloci moze i lokalnie. Zakloci, bo jakas iskierkowa delta Diraca rozpyli sie na nieskonczone spektrum rozkladu Fourierowskiego. Ale zrobi to krociutko i z tym poradzi sobie warstwa protokolu Meshtasticowego (Spread Factor + Coding Rate na spolke).
A ja, jak juz napisalem, daze do stabilnego linku prywatnego miedzy dwoma miejscowosciami. Tu niski poziom zaklocen ma znaczenie. I zeby nie bylo dalszych nieporozumien - ja po zakonczeniu testow nie zamierzam wracac na czestotliwosci ogolnie przyjete i sprawdzac, czy w zakloconym otoczeniu tez uda mi sie nawiazac lacznosc. Zamierzam pozostac sobie z daleka od calego tego balaganu. Bo tenze balagan jakos mnie nie bawi.

Ja niczego nie zakładam. Napisałem tylko to, co ma miejsce w Waszych testach. Narzekasz na to, że ktoś robi w twojej okolicy mesh gdy sam chcesz nie-mesh.

No to juz znasz moje cele.
Nawiasem mowiac - nie narzekam, ze ktos w mojej okolicy robi mesha. Ubolewam, ze ludzie robia to glupio i antyoptymalnie mnazac liczbe widzianych lokalnie nodow oraz wykrecajac w konfiguracji maksymalne liczby hopow. Telemetria tez nie pomaga. Ale skoro komus takdobrze, to dobrze mu tak. Marzenie o calej Polsce spietej w dzialajaca siec mesh to mzonka. To sie nie uda. To sie zapcha. Bo meshowe sieci nie sa przeznaczone do takich zabaw. Niemniej nie zamierzam nikomu bronic tychze zabaw. Niechaj sie ten eksperyment rozwija. Na wnioski przyjdzie czas. A ja po prostu ide sobie na bok zeby zabawy ludkow mi nie przeszkadzaly oraz zebym ja nie przeszkadzal zabawom innych.

Jaki problem rozszerzyć NodeInfo by informacje były szerzej dostępne. A przemiatanie to zupełny banał, robimy to ręcznie.

Jakos tak odnosze dziwne wrazenie, ze nie do konca przemyslales te wypowiedz. Tu znow klaniaja sie warstwy modelu ISO/OSI. Zobacz prosze: zmieniasz modulacje (zawezasz pasmo, zmieniasz SF, zmieniasz CR). No i nawet dodajesz sobie informacje o uzytych parametrach w NodeInfo. Tyle, ze NodeInfo odbiera warstwa aplikacji, a demodulacje robi warstwa transportowa ponizej warstwy protokolu. Jesli transport nie bedzie wiedzial jak cos odebrac, to nie odbierze. I warstwa protokolu nie dostanie informacji. A dalej i warstwa aplikacji zobaczy ladne okragle NIC.
Ale ze moze chcialbys wysylac informacje z wyprzedzeniem? "Teraz jeszcze moduluje tak, ale za minute bede nadawal z inna modulacja"? No to przemysl, jak zgrac wszystkie nody (bo mozesz potrzebowac przeciez jakiegos hopa, a posrednik musi jednak na transporcie zrozumiec co dostal). No i te rozne interfejsy... Czy chodzi Ci o to, zeby LoRa jednoczesnie umiala pracowac na kanale 250kHz, 125kHz, 62.5kHz z kilkoma roznymi SFami i na roznych czestotliwosciach srodkowych? Pomysl zacny, ale matematycznie ciezki do wykonania na jednym odbiorniku. Znaczy: da sie! Tylko trzeba (pisze tylko o odbiorniku) wysamplowac wejscie, a probki IQ dostarczyc do kilku niezaleznych modulow przetwarzania, z ktorych kazdy zrobi Fouriera dla innych parametrow. Bardzo fajny pomysl. Tylko ze moduly LoRa sa nieco za glupiutkie. Moze Panowie Chinczycy wejda kiedys w moduly z kilkoma sciezkami przetwarzania. Ciekawe jak to wplynie na cene modulow?

To jest tylko kwestia braku wielu interfejsów a nie tego czy ktoś zarządza.

Popatrz wyzej, prosze. Temat wydaje Ci sie trywialny. Przeanalizuj go nieco powazniej, to byc moze zrozumiesz, ze wielosc interfejsow nie jest tematem trywialnym technicznie. Temat zarzadzania natomiast powoduje, ze ruch danych robi sie przewidywalnie sterowalny. Oczywiscie w sieciach meshowych nie ma administratora. Kazdy nod balagani sobie po swojemu. I... Czyz nie to stanowi najpowazniejszy mankament sieci mesh?

W nieszyfrowanym nagłówku jest channel_hash.

Zle sie wyrazilem. Masz hash dla kanalu. Ale tak czy siak nie zdekodujesz ciala wiadomosci do wyforwardowania, bo ono jest zakodowane glebiej kluczami publicznymi i prywatnymi oryginalnego nadawcy i docelowego odbiorcy (poza kanalem rozgloszeniowym, gdzie wszystko leci z jawnym kluczem). To, ze nod nie potrafi odszyfrowac ciala wiadomosci, nie przeszkadza nodowi w zrobieniu forwarda takiej wiadomosci. Datagram to datagram. W naglowku dekrementujemy FlagLimit we flagach, za zmienionym naglowkiem wysylamy zaszyfrowane cialo, ktore dla nas jest niezrozumiale. I tyle.

Pozdrawiam i zycze dobrej nocy.

[ioioio]

No to właśnie pisałem, że nie ma coś się dziwić, że ktoś optymalizuje. A co ja robię to w tej dyskusji nie ma żadnego znaczenia. Żenujące są takie personalne wypowiedzi.

Otoz wlasnie napisales cos, czego nie umialem dowiazac do kontekstu dialogu.
Co do personalnych wypowiedzi - nie masz Ty przypadkiem na imie Slawek? Bo mam tu lokalnie takiego jednego Meshtasticowego Slawka, ktory mocno przeczulony personalnie jest

Zasady elementarnej kultury.

To jest tylko słabość Meshtastica, że nie zapewnia wielu interfejsów z różnymi ustawieniami. Różne ustawienia tak czy siak można zrobić i nie tylko o to chodzi jaki zasięg jest tylko w jakich warunkach.

Ale wiesz, ze powtarzasz tekst? Wiesz, prawda?

Na podstawie tego, co wiadomo o protokole, że od 2.6 jednak próbuje zbierać informacje o ruchu i kierować pakiety do odpowiedniego węzła a nie wszystkich co oczywiście nie jest możliwe, jak takich informacji nie ma.

Znow zagubil sie kontekst. Co z tego, ze sciezke do adresata mozna zoptymalizowac i "zamrozic" jak w Meshcore, kiedy kazdy przekazany przez posrednika datagram zajmuje czas tego samego interfejsu radiowego?

No i?

Analogiem teleinformatycznym jest "extender WiFi", ktory sprawia, ze po tym samym pasmie WiFi informacja przesylana jest podwojnie. Raz ze zrodla do extendera, i drugi raz z ekstendera do docelowego adresata (co oznacza, ze i pierwotne zrodlo ten sygnal slyszy, dzialajace w WiFi algorytmy Listen Before Talk przyblokowuja innym uzytkownikom mozliwosc uzytkowania pasma radiowego, gdyz "idzie transmisja" - coz, ze duplikat, wazne, ze idzie. I tak na marginesie: celowo upraszczam temat. Jesli ktos zechce poznac mechanizmy pracy sieci WiFi, to wezmie sobie ktoras ze specek 802.11 i sie z nimi zapozna u zrodla.

Jak znalazł się wcześniej to znalazł i nie dotrze do 5 czy 6. No chyba, że jednak nie znalazł się i jakoś jednak dotarł.

Cos mam wrazenie, ze nody posredniczace niekoniecznie wiedza, czy dany datagram znalazl juz adresata. Nie jest aby tak, ze nod zobaczy na biezacy stan HopLimit i jesli nie zero - zrobi forwarda? Chyba, ze nody analizuja ruch pod katem zaslyszanych ACKow - to jednak spowodowaloby znaczne opoznienia na forwardzie (odebralem, zbuforuje na x sekund, poslucham czy ktos nadal ACKa na nadawce zbuforowanego pakietu, jesli nie, to po x sekundach robie forwarda - malo optymalne by to bylo).

Ale jakie 'pośredniczące'? Węzeł do którego jest adresowany wie, że do niego jest adresowany i dalej nie przesyła. Może poprzednie nie wiedziały gdzie wysłać i wysyłały wszędzie i inną ścieżką z pominięciem docelowego doszlo do tych 'za', ale nie po kolei tak, jak sugerowałeś i o ile to były węzły, które nie widziały się.

1. LoRa to nieco powyżej medium transmisyjnego ISM. Po prostu przesyłanie do kogoś innego w eterze techniką chirp. Ktoś sobie odbierze albo nie odbierze. Nie ma żadnego przesyłania dalej.

Hmmm... Mam wrazenie, ze mylisz warstwy modelu ISO/OSI. Owszem, na warstwie transportowej masz glupiutki transport z modulacja CHIRP. Tyle, ze pietro wyzej siedzi warstwa protokolu, ktora naklada naglowki i formaty. A nad nia siedzi z kolei warstwa aplikacji - i tu nam rezyduje przykladowo Meshtastic. Zastanawia mnie, ktora z tych warstw odpowiada za forwardy. Prosiloby sie, zeby zrobila to warstwa protokolu. Calkiem mozliwe jednak, ze robi to dopiero warstwa aplikacji.

Meshtastic to wszystko powyżej warstwy fizycznej.

2. To fizyczne połączenie za pomocą LoRa wykorzystuje się do realizacji różnych usług między innymi mesh. Z dobrze znanych to LoRaWAN, APRS, Meshtastic czy Meshcore.

Zaiste. To nie byla informacja nowa. Stos protokolow tudziez nadmieniony wyzej model ISO/OSI wchodza nam do gry.

3. Opis protokołu Meshtastic znajduje się witrynie projektu https://meshtastic.org/docs/overview/mesh-algo/

Dziekuje. Wiem, bywalem, czytywalem. Byc moze nawet cos tam udalo mi sie zrozumiec.

Polecam fragment o 'next hop'.

No ale co konkretnie dla Was wnosi testowanie Meshtastica w wyizolowanym i zupełnie niezakłóconym środowisku jak w realnych nigdy tak nie będzie. Ktoś naciśnie dzwonek przy bramie i się zakłóci bo niby czemu nie.

Widzisz... Dzwonek u bramy zakloci moze i lokalnie. Zakloci, bo jakas iskierkowa delta Diraca rozpyli sie na nieskonczone spektrum rozkladu Fourierowskiego. Ale zrobi to krociutko i z tym poradzi sobie warstwa protokolu Meshtasticowego (Spread Factor + Coding Rate na spolke).
A ja, jak juz napisalem, daze do stabilnego linku prywatnego miedzy dwoma miejscowosciami. Tu niski poziom zaklocen ma znaczenie. I zeby nie bylo dalszych nieporozumien - ja po zakonczeniu testow nie zamierzam wracac na czestotliwosci ogolnie przyjete i sprawdzac, czy w zakloconym otoczeniu tez uda mi sie nawiazac lacznosc. Zamierzam pozostac sobie z daleka od calego tego balaganu. Bo tenze balagan jakos mnie nie bawi.

Jakich komentarzy spodziewałeś się wysyłając na forum poświęcone jednej z implementacji mesh?

Ja niczego nie zakładam. Napisałem tylko to, co ma miejsce w Waszych testach. Narzekasz na to, że ktoś robi w twojej okolicy mesh gdy sam chcesz nie-mesh.

No to juz znasz moje cele.
Nawiasem mowiac - nie narzekam, ze ktos w mojej okolicy robi mesha. Ubolewam, ze ludzie robia to glupio i antyoptymalnie mnazac liczbe widzianych lokalnie nodow oraz wykrecajac w konfiguracji maksymalne liczby hopow.

Już pisałem, bez 7 przesków nie da się zrobić połączenia to jak ich nie ustawiać. Inne implementacje mesh takie jak Meshcore czy Reticulum mają większy limit a może i wartość domyślną.

Telemetria tez nie pomaga. Ale skoro komus takdobrze, to dobrze mu tak.

Można filtrować jak komuś nie pasuje. Zdaje się możliwe na tym alternatywnym FW+.

Marzenie o calej Polsce spietej w dzialajaca siec mesh to mzonka. To sie nie uda.

Już jest południe Polski.

To sie zapcha. Bo meshowe sieci nie sa przeznaczone do takich zabaw.

Wskaźniki nie pokazują by było zapchane. Ale niekoniecznie jest pełne pokrycie. Z pełnym i telemetrią by się pewnie zapchało.

Niemniej nie zamierzam nikomu bronic tychze zabaw. Niechaj sie ten eksperyment rozwija. Na wnioski przyjdzie czas. A ja po prostu ide sobie na bok zeby zabawy ludkow mi nie przeszkadzaly oraz zebym ja nie przeszkadzal zabawom innych.

Jaki problem rozszerzyć NodeInfo by informacje były szerzej dostępne. A przemiatanie to zupełny banał, robimy to ręcznie.

Jakos tak odnosze dziwne wrazenie, ze nie do konca przemyslales te wypowiedz.

A Ty przemyślałeś i nie umiesz zaproponować prostych rozwiązań.

Tu znow klaniaja sie warstwy modelu ISO/OSI. Zobacz prosze: zmieniasz modulacje (zawezasz pasmo, zmieniasz SF, zmieniasz CR). No i nawet dodajesz sobie informacje o uzytych parametrach w NodeInfo. Tyle, ze NodeInfo odbiera warstwa aplikacji, a demodulacje robi warstwa transportowa ponizej warstwy protokolu. Jesli transport nie bedzie wiedzial jak cos odebrac, to nie odbierze. I warstwa protokolu nie dostanie informacji. A dalej i warstwa aplikacji zobaczy ladne okragle NIC.
Ale ze moze chcialbys wysylac informacje z wyprzedzeniem? "Teraz jeszcze moduluje tak, ale za minute bede nadawal z inna modulacja"? No to przemysl, jak zgrac wszystkie nody (bo mozesz potrzebowac przeciez jakiegos hopa, a posrednik musi jednak na transporcie zrozumiec co dostal).

No i dostaje i rozumie. Jak nie rozumie to tak, jak teraz ja przestawię stację ręcznie a on się o tym nie dowie i poszuka innej ścieżki. Może i tam jest jakaś kwestia, że gdzieś niżej czegoś nie widać, ale tak czy siak, jakoś to się da zrobić.

No i te rozne interfejsy... Czy chodzi Ci o to, zeby LoRa jednoczesnie umiala pracowac na kanale 250kHz, 125kHz, 62.5kHz z kilkoma roznymi SFami i na roznych czestotliwosciach srodkowych? Pomysl zacny, ale matematycznie ciezki do wykonania na jednym odbiorniku. Znaczy: da sie! Tylko trzeba (pisze tylko o odbiorniku) wysamplowac wejscie, a probki IQ dostarczyc do kilku niezaleznych modulow przetwarzania, z ktorych kazdy zrobi Fouriera dla innych parametrow. Bardzo fajny pomysl. Tylko ze moduly LoRa sa nieco za glupiutkie. Moze Panowie Chinczycy wejda kiedys w moduly z kilkoma sciezkami przetwarzania. Ciekawe jak to wplynie na cene modulow?

Normalnie, możesz mieć moduł z jednym prockiem i wieloma trasnceiverami LoRa. By móc każdy transceiver ustawić inaczej. Swego czasu kupowałem je za 5zł. Ostatnio jak mi ktoś zarzucił, że droższe to faktycznie nie widziałem tak tanich, ale nadal relatywnie tanie są i wystarczyłyby 2 by mieć np 2 częstotliwości. Poza tym jakieś gotowce są. A tak to właściwie tych dwóch częstotliwości nie da się zrobić bez zewnętrznego przekazywania pakietów.

To jest tylko kwestia braku wielu interfejsów a nie tego czy ktoś zarządza.

Popatrz wyzej, prosze. Temat wydaje Ci sie trywialny. Przeanalizuj go nieco powazniej, to byc moze zrozumiesz, ze wielosc interfejsow nie jest tematem trywialnym technicznie. Temat zarzadzania natomiast powoduje, ze ruch danych robi sie przewidywalnie sterowalny. Oczywiscie w sieciach meshowych nie ma administratora. Kazdy nod balagani sobie po swojemu. I... Czyz nie to stanowi najpowazniejszy mankament sieci mesh?

Proste kanały są proste, nie-proste nie.

W nieszyfrowanym nagłówku jest channel_hash.

Zle sie wyrazilem. Masz hash dla kanalu. Ale tak czy siak nie zdekodujesz ciala wiadomosci do wyforwardowania, bo ono jest zakodowane glebiej kluczami publicznymi i prywatnymi oryginalnego nadawcy i docelowego odbiorcy (poza kanalem rozgloszeniowym, gdzie wszystko leci z jawnym kluczem). To, ze nod nie potrafi odszyfrowac ciala wiadomosci, nie przeszkadza nodowi w zrobieniu forwarda takiej wiadomosci. Datagram to datagram. W naglowku dekrementujemy FlagLimit we flagach, za zmienionym naglowkiem wysylamy zaszyfrowane cialo, ktore dla nas jest niezrozumiale. I tyle.

Nie wiem czy źle się wyraziłeś, ale chyba nie sugerujesz, że kolega ma podszywać się pod kanał główny 'by przechodziło'. To i tak niekoniecznie zadziała bo telegramy mogą być rozszyfrowywane dla werfykacji. Nie wiem jakie jest ustawienie donyślne.
Natomiast kolega może sobie przesyłać wiadomości bezpośrednie na znanym kanale np głównym do każdego odbiorcy z osobna, one w miarę możliwości pójdą 'ścieżką' a nie 'do wszystkich', ale samodzielnie a nie, że Meshtastic to zrobi. Stąd zapytałem jak właściwie kolega chce to grupowe rozsyłanie zrobić.

Pozdrawiam i zycze dobrej nocy.

Na razie.

[Pietrow]

Szanowny Slawku
Pozwol, ze wycofam sie z dalszej dyskusji. Ten watek w moim mniemaniu odszedl zbyt daleko od swojego podstawowego tematu.

Twoja ogromna wiedza ekspercka jest widoczna niemal na kazdym kroku dyskusji. Chyle glowe. Mozesz poczuc sie jak tematyczny guru jesli tylko masz taka potrzebe.

Daj prosze znac, gdy przystapisz do praktycznej realizacji Twoich wieloportowych rozwiazan. Chetnie pomoge w testach, o ile nie jestem ku temu "zbyt cienki w uszach". Twoje koncepcje maja wiele kuszacych aspektow, lecz mocno obawiam sie, ze rzeczywistosc znaczaco je zweryfikuje w fazie praktycznej realizacji. Mysle, ze musisz dojsc do tego etapu, by zdac sobie sprawe z tego, co stanie Ci na drodze w realizacji koncepcji.
Podobnie ma sie rzecz z usieciowieniem calej Polski - musisz po prostu zobaczyc jak siec rozlegla umiera w sytuacji kryzysowej pod natlokiem ilosci uzytkownikow i przy ograniczonej pojemnosci medium transmisyjnego. Nie umiem Ci tego wytlumaczyc w sposob dla Ciebie akceptowalny.

Z mojej strony dyskusje zakonczylem bedac w stanie przytloczenia Twoja wiedza. Mam nadzieje, ze jestes zadowolony.

Pozdrawiam serdecznie
(ekhem... Wlasnie ta postulowana przez Ciebie elementarna kultura nie pozwala mi tu rzucic zdawkowego "Czesc" i zamknac drzwi)

PS: Ah! Oczywiscie nie krepuj sie, jesli masz ochote cos tu jeszcze dopisac, wyjsc z dyskusji z ostatnim slowem, blysnac na pozegnanie wiedza albo zmieszac dyskutanta z gleba. Smialo! Ja juz zakonczylem. Cokolwiek dopiszesz - bedzie ostatnie w dyskusji.
Mam tez nadzieje, ze nie czujesz sie urazony. U Ciebie o osobiste urazy jest dosc latwo, a ja absolutnie i w najmniejszym nawet stopnio nie mialem zamiaru Ciebie urazic. Jesli jednak urazony sie poczules, to skladam niniejszym moje gorace przeprosiny i blagam o to, bys nie pielegnowal w sobie tej urazy.

[StaCh47]

Z tej dyskusji mozna wyciagnac pewne ogolne wnioski. Po pierwsze Meshtastic to nie jest i nigdy nie bedzie ethernet ze wzgledu na:
-zbyt male moce obliczeniowe stacji co ma swoja zalete, ze bierze malo pradu
-brak protokolu wykrywajacego zajetosc medium i procedury back-off
-brak protokolow routingu pakietow
Nie zgadzam sie z wnioskiem, ze do dalekiej lacznosci potrzebne jest wiele stacji posredniczacych, wiecej niz 3, z kilku powodow:
-moje wlasne testy zasiegow przedstawione na forum temu przecza
-brak stalych stacji posredniczacych z wlasciwym protokolem rozpowszechniania a stacje ruchome pojawiaja sie i znikaja
Stacja domyslnie retransmituje rowniez datagramy z innych niz Meshtastic aplikacji ale ja mam to wylaczone w konfiguracji. Nadal uwazam, ze jesli jest za duzo stacji w trybie CLIENT to moze nastapic zapchanie medium niezaleznie czy to LongFast, MediumFast czy ShortFast bo wszystkie korzystaja z tej samej czestotliwosci.
Stacje nie majace znaczenia "strategicznego" dla sieci powinny moim zdaniem pracowac w trybie CLIENT_MUTE.
Dla testow lacznosci punkt-punkt Kolego Pietrow wystarczy zmienic czestotliwosc zeby sie odciac od ruchu lokalnego. Jak widac z dzialalnosci bota Meszek stacje dekoduja wiadomosci jesli znaja klucz a jesli klucz jest nieznany to nie moga zdekodowac wiadomosci ale prawdopodobnie moga je przeslac dalej. To nie jest tak, ze jak ktos ustawi dla wiadomosci HOP 7 to jesli stacja docelowa znajdzie sie jako trzecia to na niej zakonczy sie retransmisja. Niestety transmisja pojdzie dalej az dotrze do wszystkich stacji w zasiegu dla ktorych liczba HOP = 0. Dopiero wtedy zakonczy sie rozpowszechnianie tej wiadomosci.
Rowniez nie jest tak, ze jesli sa 2 stacje miejscowosci A i B, ktore sa polaczone, to po tych miejscowosciach beda hulac pakiety z obu miast bowiem kazda stacja niezaleznie od trybu (poza CLIENT_MUTE) przekazujac pakiet zmniejsza HOP o 1 (choc czytalem o HOP =0,5?).
Kolego Pietrow prosze sie odnosic do argumentow a nie do osoby, ktora ukrywa sie pod nickiem a z ktorej niektorymi pogladami rowniez sie nie zgadzam.