Optymalizacja sieci radiowej APRS
    sp6fig pisze:

      ebc41 pisze:

      http://ebc41.elektroda.eu/?p=1653
      Ten krótki artykuł powstał jako moje przemyślenia na problemy zapychającej się powoli sieci radiowej w APRSie.Jaką Wy macie opinie w temacie?


    Mateusz w twoim opracowaniu różnych systemów zabrakło protokołu regulującego
    dostępu użytkownika do usług sieci Packet Radio ...<b> protokół DAMA.</b>

    Jednak węzły Packet Radio to inny sposób korzystania z sieci PR niż APRS.
    I do APRS nie został wykorzystany protokół DAMA.

    W opracowaniu używasz określenia węzeł APRS chyba to jest mylne określenie dla DIGI APRS.
    Jedno DIGI APRS nie ma skomunikowania z innym, każde jest jednostką niezależną jedynie odbierającą
    informację i tą informacje ("jakby tylko odbija dalej") nadaje dalej w eter.
    To jest takie "laickie" tłumaczenie zasad pracy DIGI APRS.


    Przy okazji mam zapytanie czy ParaTNC w trybie KISS ?


Tak. pisząc węzeł APRS mam na myśli oczywiście digi, nie chciałem po prostu używać bez przerwy tych samych słów wesoły Problemem w APRSie jest też to, że ciężko by było zaimplementować taki protokół jak DAMA. Packet Radio to jednak nie był mesh. Userporty były osobno a backbone, czyli połączenia pomiędzy stacjami bazowymi (jak się one fachowo nazywały?) były osobno. Myślę teraz jak prosto rozwiązać ten problem, ale nie mam narazie 100% skutecznego pomysłu. Gdyby wszystkie urządzenia znały dokładny czas UTC, to można by próbować wdrożyć algorytm przydzielający czas nadawania na określoną sekundę minty. Pytanie tylko, co zrobić ze stacjami mobilnymi. Digi dość szybko zsynchronizują się ze sobą i dogadają się kto kiedy ma nadawać, ale co z poruszającą się stacją?

Z APRSem jest też inny problem, kiepskie możliwości wykrywania transmisji. Tzn. jeżeli stacja bracuje z normalnie załączoną blokadą szumów to OK, można przyjąć, że gdy ta jest otwarta oznacza to że kanał jest zajęty. Jak jednak wszyscy wiemy nie jest to najlepsze wyjście. Blokadę mogą otwierać również zakłócenia a ta może się sama z siebie zawiesić, czego sam niejednokrotnie doświadczyłem przy eksploatowaniu Baycoma i AGW Packet Engine.

Praca z permamentnie otwartą blokadą wymaga, aby DCD odbywało się na podstawie pracy samego modemu. To nie jest jednak tak oczywiste, na jakie wygląda. W transmisji HLDC używa się wprawdzie nagłówków i zakończeń transmisji w postaci ciągu sekwencji 0x7E, ale nie można ich używać do stwierdzenia początku i końca ramki, a jedynie do synchronizacji do prędkości bodowej. Puszczenie szumu białego z odbiornika na wejście dekodera (w moim przypadku na przetwornik analog-cyfra) powoduje powstanie losowego ciągu bitów, w którym 0x7E pojawia się bardzo ciężko, ze względu na dużą ilość jedynek. Po ostatnim 0x7E pojawia się od razu adres docelowy, który nawet w APRSie nie ma stałej wartości, tym bardziej jeżeli załączona jest kompresja Mic-E. Można oczywiście próbować wykrywać typowe ciągi typu APxxx-0 ale nie jest to elegancie i w pełni skuteczne rozwiązanie. Pierwszym polem, które zawsze przyjmuje zawsze tę samą wartość jest określenie typu enkapsulacji. W APRSie używa się wartości równej 0xF0, ponieważ w pakietach AX.25 nie przesyła się ani TCP/IP ani innego protokołu warstwy 3. Problem polega na tym, że występuje ono w połowie ramki, pomiędzy adresacją a payloadem, czyli pomiędzy znakiem i ścieżką a treścią ramki. Normalnie fakt odebrania ramki APRS stwierdza się na podstawie poprawności sumy kontrolnej, ale jak sami się domyślacie poprawną sumę kontrolną otrzymuje się z wszystkich danych, czyli już po fakcie.

Kiedyś Bartek SP8EET opowiedział mi o swoim pomyśle, aby na częstotliwości APRS zacząć używać CTCSS. To było by to! Wtedy można by spokojnie używać sygnału detekcji tonu jako zajętości kanału, bo wiadomo, że zakłócenia nie będą go generowały. Realność wprowadzenia tego pomysłu jest jednak zerowa.


Co do ParaTNC to nie wiem o co dokładnie chodziło z KISS ale odpowiadam, że obsługuję KISS i nawet domyślnie startuje w tym trybie wesoły


  PRZEJDŹ NA FORUM