Forum APRS Polska

Zaloguj się lub zarejestruj.

Zaloguj się podając nazwę użytkownika, hasło i długość sesji
Szukanie zaawansowane  

Aktualności:

Autor Wątek: FOApack - kiedy digi ?  (Przeczytany 25233 razy)

SQ2FOA

  • PG APRS
  • *
  • Offline Offline
  • Wiadomości: 69
    • http://sq2foa.republika.pl
FOApack - kiedy digi ?
« Odpowiedź #15 dnia: Marzec 01, 2005, 10:49:08 LOC »

1. Język
Pewnie że jest to możliwe, nawet na rosyjski tylko że trzeba by było generator znaków przebudować, ale jeśli chodzi o angielski to nie ma problemów. Gorzej z innymi językami, ale przy pomocy wszystkich krótkofalowców można zrobić dowolny.

2. DIGI
W specyfikacji AX25 jest tak, że gdy w ścieżce jest już * to wtedy nie jest dalej powtarzana. Moja koncepcja na początek jest taka: jeśli w ścieżce będzie RELAY to taką ścieżkę przerobię na MYCALLSIGN* i wypuszczę w eter. Ciekawe jak takie coś będzie działać?
Zapisane
Radosław Kamowski

SP6VWX

  • Administrator
  • *****
  • Offline Offline
  • Wiadomości: 886
  • Jutro to dziś - tylko że jutro. S. Mrożek
FOApack - kiedy digi ?
« Odpowiedź #16 dnia: Marzec 01, 2005, 21:35:44 LOC »

Radku,

1. Z niczego nie rezygnuj. Raz napisany i przetestowany soft to majątek. Przygotuj tylko projekt tak aby dało się skompilować z opcjami.
Prosty digi nie potrzebuje opcji mapy i wylicznia azymutu czy odległości.
Wyswietlacz też nie jest konieczny (chociaż fajnie mieć podgląd).

Pozdrawiam

Robert
Zapisane
Robert

SP3LYR

  • Administrator
  • *****
  • Offline Offline
  • Wiadomości: 2141
  • Teoretycznie, praktyka pokrywa się z teorią
    • o APRS po polsku
FOApack - kiedy digi ?
« Odpowiedź #17 dnia: Marzec 02, 2005, 00:12:50 LOC »

Cytat: "SQ2FOA"

W specyfikacji AX25 jest tak, że gdy w ścieżce jest już * to wtedy nie jest dalej powtarzana. Moja koncepcja na początek jest taka: jeśli w ścieżce będzie RELAY to taką ścieżkę przerobię na MYCALLSIGN* i wypuszczę w eter.


Radek,
tu chodzi o coś jeszcze bardziej inteligentnego, kiedy digi w FOA-Pack usłyszy RELAY,WIDEn-n a po chwili usłyszy tę samą ramkę, ale już powtórzoną, bo jest coś tam z * zamiast RELAY, np. SR3DPN*,WIDEn-n to jej nie powtarza. Dlatego potrzebna jest zwłoka, aby usłyszał, że regionalny już ją powtórzył i nie trzeba jej jeszcze raz puszczać w eter.
Zapisane
73
Andrzej SP3LYR

SQ2FOA

  • PG APRS
  • *
  • Offline Offline
  • Wiadomości: 69
    • http://sq2foa.republika.pl
FOApack - kiedy digi ?
« Odpowiedź #18 dnia: Marzec 02, 2005, 09:14:01 LOC »

no ale wtedy to będzie taki ułomny trochę DIGI bo jesli usłyszę ramkę RELAY to przygotuję nową ramkę do powtórzenia i będę miał zajęty jedyny bufor wyściowy. Jeśli przyjdzie druga ramka od innej stacji RELAY to już nie zostanie obsłużona bo bufor będzie zajęty. Po odczekaniu jakiegoś czasu jeśli nie przyjdzie powtórzenie od WIDE to wyśle ramke, a gdy przyjdzie ty bufor zwolnie. Gdy bufor jest zajęty to nie da się nic wysłać.
Być może jeden bufor da radę obsłużyć RELAY.
Zapisane
Radosław Kamowski

SP3LYR

  • Administrator
  • *****
  • Offline Offline
  • Wiadomości: 2141
  • Teoretycznie, praktyka pokrywa się z teorią
    • o APRS po polsku
FOApack - kiedy digi ?
« Odpowiedź #19 dnia: Marzec 06, 2005, 21:57:21 LOC »

Rozważałem różne opcje, ale wygląda na to, że trzeba wybrać albo rybki, albo akwarium. Z dwojga opcji chyba dla dobrej kondycji sieci APRS, lepiej wybrać przetrzymywanie na buforze jednej ramki. RELAY zawsze jest dodatkowym ogniwem, więc niekoniecznie następna ramka, nieuchwycona przez naszego RELAY z powodu zajętego bufora, nie będzie przechwycona przez regionalny digi, czy też wsparta przez inny pobliski RELAY.
Mam jednak jeszcze jedną sugestię odnośnie funkcjonowania FOA-Packa w sieci APRS. Mianowicie w przypadku pracy ze stałego QTH, czyli praca bez GPSa, warto zaimplementować "decay algorithm". Radkowi jest on znany, ponieważ był on wstawiony do nowego programu APRS, jednak dla zainteresowanych kilka słów.
Beacon z takim algorytmem jest wysyłany po włączeniu urządzenia lub po zmianie konfiguracji, w następujących odstępach: 2, 4, 8, 16, 32 sekund, 1, 2, 4, 8 minut. Jeśli usłyszy swój beacon powtórzony przez digi, to już nie ponawia jego emisji. Dalej przechodzi do normalnego trybu wysyłania beaconu. Normalny tryb może też być nieco inteligentny i oparty na długości własnej ścieżki. Jeśli ta opcja byłaby możliwa do implementacji w FOA-Pack, to powinna ona wyglądać tak, jak to jest np. w DOS-APRS autorstwa WB4APR, czy też w APRS-SCS. Kiedy ścieżka jest jednostopniowa (np. WIDE) beacon wysyłany jest co 10 minut, dwustopniowa (np. WIDE2-2) beacon wysyłany jest co 20 minut, trzystopniowa lub dłuższa - co 30 minut.
Natomiast odnośnie wysyłania message algorytm jest następujący: ponowienie po 8 sekundach, dalej po 24 i trzeci raz po 32. Chyba że dociera ack, to ponawianie jest zaniechane. A więc jeśli msg nie weszła na pobliski digi, to jest sensowne jej ponowienie po 8 sek., ale jeśli weszła, a dopiero na następnym stopniu powtarzania nie przedarła się, to ponowienie ma sens po 24 sekundach, bo 24+8 przekroczy czas powstrzymywania duplikatów na digi, który zwykle wynosi 30 sekund. Kolejna próba będzie po nastepnych 32 sekundach.
Trochę może to skomplikowanie wygląda, ale dotyczy to właściwie tylko pracy timera bez dodatkowych buforów.
Zapisane
73
Andrzej SP3LYR

SQ2FOA

  • PG APRS
  • *
  • Offline Offline
  • Wiadomości: 69
    • http://sq2foa.republika.pl
FOApack - kiedy digi ?
« Odpowiedź #20 dnia: Kwiecień 04, 2005, 08:45:13 LOC »

Zastanawiam się cały czas nad algorytmem do FOA-Packa który byłby DIGI WIDEn-N. Dodam nowy tryb pracy. Jak wielu kolegów sugerowało, byłoby zapotrzebowanie na takiego FOA-Packa i nawet wyświetlacza nie musiałby mieć, a co za tym idzie i klawiatury, odszedł by wtedy też MAX232.
Przy takim uproszczeniu mogę wykorzystać ogromny obszar pamięci zajmowany przez "listę stacji" (800 bajtów). Użyty byłby on wtedy do przechowywania ramek które należy powtórzyć, oraz te które przed chwilą zostały powtórzone. Procedury obsługi listy mogły by zostać bez zmian, tylko algorytm filtrujący byłby inny. Lista mieści 8 ramek. Załóżmy że ramka jest blokowana przed duplikatami przez 30s, oraz że odrzucam ramki które nie będą powtarzane (nie mają w ścieżce WIDE).

Przy takiej implementacyji proszę o pomysły jak ma działać taki FOA-DIGI. We FOA-Packu zostało jeszcze do zagospodarowania ok. 2400 słów kodu (dla niezorientowanych: cały program w TinyTrak 1.4 zajmuje 955 słów kodu)
Zapisane
Radosław Kamowski

SP6VWX

  • Administrator
  • *****
  • Offline Offline
  • Wiadomości: 886
  • Jutro to dziś - tylko że jutro. S. Mrożek
FOApack - kiedy digi ?
« Odpowiedź #21 dnia: Kwiecień 04, 2005, 23:01:10 LOC »

Radek,

Ja bym podzielił rzecz na etapy:
1. implementacja tylko algorytmu digi WIDE (lub inny alias) w formacie N-n (to niestety juz standard jest)
2. implementacja algorytmu (rozpoznawania) dowolnego aliasu (np. SP) z tablicy dozwolonych aliasów (a co sie ograniczać, POZ-poznań, WRO-wroclaw, itp. nigdy nie wiadomo co sie przyda)
3. implementacja bajerów jak ?DX, ?APRSD, itp
4. display, klawiatura nie sa konieczne ale MAX232 bym zostawił i wyrzucałbym na niego cały ruch digi (ot taki port nr 2), chocby dla celów debug'owania
5. implementacja portu nr 2 na COM'ie jako pełnoprawny port + jego obsługa (np. digi 1=2, 2=1, itp) co z podpietym PC (UIView) da nam fajny IGate

Ot takie moje marzenia.

Pozdrawiam

Robert
SP6VWX
Zapisane
Robert

SP3LYR

  • Administrator
  • *****
  • Offline Offline
  • Wiadomości: 2141
  • Teoretycznie, praktyka pokrywa się z teorią
    • o APRS po polsku
FOApack - kiedy digi ?
« Odpowiedź #22 dnia: Kwiecień 06, 2005, 06:47:58 LOC »

Radek, według ostatnich dyskusji na aprssig, to w przyszłości powinny być wyeliminowane ścieżki inne niż n-n, do tego stopnia, że proponowane jest zastąpienie RELAY poprzez WIDE1-1 lub SS1-1, więc tutaj projekt bez obsługi n-n nie miałby większego sensu dla celów regionalnego digi.
Myślę, że jako cel projektu FOA-Digi należałoby określić jego zastosowanie dla potrzeb digi regionalnego. Inne funkcje można później dodać jako gwizdawki i wodotryski. Nie będziemy tu wyważać otwartych drzwi, więc proponuję oprzeć się na funkcjach, które istnieją w oprogramowaniu Kantronicsa KPC3+ dla digi APRS, w programie UIDIGI, oraz programie javAPRSDigi. Zaimplementować to, co w nich jest dobre i najistotniejsze, bo możemy natrafić na ograniczenia w samej kości. Niestety nie wgryzałem się w szczegóły w DIGI_NED, więc proszę o uzupełnienia.

Ogólne funkcje do wpisania:
DigiCall - własny znak
TxDelay
Tu jeszcze mogą dojść PPersistence oraz SlotTime związane z AX.25

Funkcje dla obsługi powtarzanych ramek:
DigiMaxHops - maksymalna liczba stopni dla przekazywanych ramek biorąc pod uwagę wszystkie elementy ścieżki, proste i n-n
DigiDupeTime - czas powstrzymywania duplikatów (w razie ograniczeń kości można na stałe wpisać 30 sekund), powinno dotyczyć zarówno prostych aliasów, jak też n-n
DigiAliases - proste aliasy, na które digi ma reagować i powtarzać ramkę (miejsce przynajmniej na cztery aliasy)
DigiUIFlood - alias n-n, który jest przekazywany bez wstawiania znaku digi (tak, jak funkcjonuje WIDEn-n, czyli wpisywane byłoby tu WIDE bez dodawania n-n, bo to oczywiste)
DigiUITrace - alias n-n, który jest przekazywany ze wstawianiem znaku digi (stare TRACEn-n, aktualnie nasze SPn-n)
Jako opcje:
DigiCallSubstitution, zwykle ta funkcja i tak jest włączona, więc po prostu trzeba go zaprogramować, aby digi to zawsze czynił, czyli zamieniał proste aliasy na własny znak.
PreemptCalls - przechodzenie do miejsca w ścieżce z określonym znakiem, czy aliasem z pominięciem wcześniejszych aliasów
UIOnly - przekazywanie tylko ramek UI, to też bym dał jako coś wpisanego na stałe skoro digi ma być dla celów APRS
Na stałe też powinna być wpisana funkcja LoopSuppression, która będzie zapobiagała powtarzaniu ramek, które zostały wysłane przez digi (własnych beaconów, czyli z DigiCall), oraz ramek, które mają już do ścieżki wstawiony jego znak (powinien zadziałać tu timer DigiDupeTime, ale tak na wszelki wypadek).

Funkcje dla wysyłania własnego beaconu:
BeaconInterval - odstępy w wysyłaniu własnego beaconu
BeaconOffset - opóźnienie w wysyłaniu beaconu
BeaconText - dla wpisania lat/lon/symb i komentarza
BeaconPath - ścieżka dla beaconu
Te cztery powyższe funkcje należałoby dać jako trzy lub nawet cztery zestawy, aby można było częściej wysyłać beacon lokalnie, a z dłuzszymi ściezkami rzadziej. Czyli dodać do każdej funkcji cyfrę, aby Interval1 był dla Offset1, dla Text1 i Path1, oraz odpowiednio 2, 3 i 4.
Natomiast BeaconDestination powinno być na stałe wpisane jako APN... może APNF01 wydaje się wolne. http://www.aprs.pl/adres.htm#Wersja%20programu%20APRS
Jeśli FOA-Digi będzie miał dodatkowy port dla podłączenia danych ze stacji pogodowej, czy innych danych telemetrycznych, to trzeba dodać funkcje:
AuxInterval
AuxPath
I opcjonalnie AuxDestination

Uff, jak to zrobisz, to będziemy resztę szlifować.
Zapisane
73
Andrzej SP3LYR