Wysokościomierz w liczniku rowerowym

[armand]

Trzeba sobie odpowiedzieć na pytanien co ma być w samolocie a co na ziemi.

 

Większość rozwiązań które liczą sobie coś na pokładzie wysyła na ziemię w paczkach informację o położeniu z GPS aktualnej prędkości względem wiatru wysokości, stanu zasilania i oczywiście cała masę innych informacji, równocześnie zapisując sobie w swojej pamięci (logger)

 

Do tego wszystkiego jedno albo dwa A/D też logowane i tu otwiera się cała masa możliwości dodawania czujników a to napięcia zasilania, prędkści obrotowej silnika, temperatury itd.

 

Ja bym nie zastanawiał się nad urządzeniem do transmisji - korzystamy z gotowych radiomodemów i tu oferowanie radiiomodemu jako opcja. Pozwoli to zarówno na wykorzystanie radiomodemów które już są w posiadaniu urzytkownika, wykorzystanie kanału zwrotnego z aparatur 2,4 GHz (w sumie w środku siedzą radiomodemy)

Powinno się mieścić w kanale danych o szerokości do 9600 bps to pozwala na dość duże odległości na tanich radiomodemach.

 

Do tego wszystkiego "sofcik" na lapatopa albo PDA tu budowanie wyspecjalizowanej stacji do wizualizacji wyników chyba jest bezcelowe.

 

Reasumując:

- prędkość

- wysokość

- przetwornik A/D do pomiaru jakiś wartości

- możliwość podłączenia odbiornika GPS

- logowanie w swojej pamięci

- możliwość podpięcia radiomodemu

 

Oczywiście, logowanie samej prędkości względem wiatru, i wysokości było by naprawdę interesujące o ile była by możliwośc podpiecia tego do radiomodemu aby mić to online.

[Pitlab]

Twoja sugestia Armand, brzmi bardzo rozsądnie. Myślę że to jest najbliższa aproksymacja docelowej funkcjonalności urządzenia. Trochę boję się tylko GPS, bo w obecnym kontrolerze nie mam drugiego UARTa - musiałbym to robić programowo a druga sprawa to kwestia analizy protokołu NMEA, ale z tym myślę że sobie poradzę.

[SCRUBBY]

LO/LA to skrót z j.ang. LONGITUDE i LATITUDE (czyli szerokość i długość geograficzna).

 

W latadla powinien być odbiornik GPS i moim zdaniem nadajnik np. 5 MHz do przesyłu danych do bazy (na ziemię). Na ziemi odbiornik 5MHz i laptop. Podłączenie odbiornika do laptoka poprzez RS-232 lub USB.

 

Kompas, to raczej wyświetlany kierunek do bazy w postaci strzałki. Zobacz tutaj i tutaj, jak działa wersja OFF-LINE (bez przesyłania danych na ziemię - jedynie z podglądem na wyświetlacz).

 

Transmisja danych na ziemię do logger'a jest niezbędna przy dalekich lotach (poza zasięg wzroku). W przypadku kraksy, GPS musi nadawać pozycję (LO/LA), by ekipa ratunkowa odnalazła model/samolot/latadło.

[armand]

Już 2,4GHz jest problematyczan a chcesz jeszcze podnieść częstotliwość - po co???

Nie potrzebny jest szeroki kanał transmisyjny i wchodzenie w kolejne GHz jest sporym utrudnieniem jeśli chcemy jakieś przyzwoite zasięgi mieć bez kierunkowych anten śledzących

 

Dla moich potrzeb pozycja z GPS jest mało potrzebna i tak latam w granicy wzroku a jeśli dalej to i tak na pokładzie mam już avionikę.

 

Najbardziej prędkość względem wiatru, wysokość, obroty silnika, nie latam elektrykami ale pobory pradu były by interesująsce (bycze serwa), napięcie zasilania. Prędkośc względem wiatru jest naprawdę interesująca, zmieniamy skoki śmigieł, czy geometrię płata ale nie znamy prędkości podejścia, przeciągnięcia tak naprawdę oceniamy na oko zmiany własciwości modelu, a warto by mieć wyniki które by jednoznacznie odpowiadały czy poprawiliśmy coś.

 

Wydaje mi się, że każdy z nas chciał by jak szybko i na jakiej wysokości latał - to znalazło by wielu nabywców przy rozsądnej cenie.

[SCRUBBY]

Witam,

Nie pisałem o GHz lecz o MHz... .

Poza tym latanie na krawędzi wzroku wymaga tylko loggera (może być pokładowy). Latanie poza granicą widoczności modelu wymaga przesyłania danych do bazy. Stąd dodatkowy TX dla danych z GPS.

[armand]

Upssss widziałem GHz a nie MHz - cóż lata lecą :wink:

Humm, a 5 Mhz jest publiczną częstotliwością??

Wypadało by pozstać na publicznych częstotliwościach.

[SCRUBBY]

Już gdzieś widziałem 5 MHz na przesył danych GPS... nie pamiętam gdzie. Co do freq. już szukam na stronach PARu.

[Mareq]

Od wielu lat to już nie jest PAR. Obecnie to się nazywa UKE. Niestety jakoś ostatnio szukałem u nich na stronie tabeli przeznaczeń częstotliwości i nie udało mi się znaleźć.

[armand]

SCRUBBY może to było 5Hz?? - częstość podawania pozycji przez lepsze moduły GPS

MAREQ - bo pewno oni są od regulowania a nie od informowania :wink:

[SCRUBBY]

5 Hz to pozycjonowanie GPSa' (nie internetowe). Nadawanie sygnału na ziemię miało być na 5MHz.

P.S. Czy przypadkiem przy Hz nie byłyby potrzebne dość długie anteny?

[Pitlab]

Pomijając kwestie prawne, częstotliwość 5MHz miała by bardzo małą przepustowość. O ile na 433MHz daje się przepchnąć max. 57 kB/s a w praktyce 19,2 kB/s to przy ~100 razy mniejszej częstotliwości można oczekiwać odpowiednio mniejszych transferów czyli rzędu 2,4kB/s. Do niekrytycznego czasowo GPS może być wystarczające, ale w naszym zastosowaniu może być za mało. Spróbujmy oszacować.

Na 1 kanał przypada 2 bajty, kanałów było by 6 (tyle mam wejść A/C w kontrolerze) + GPS. Łącznie 8 kanałów (tyle żeby zachować zgodność z obecnym formatem danych używanym w SA).

- wysokość

- prędkość

- napięcie

- temperatura

- wolny

- wolny

- dane z GPS (jeden z: LO / LA / wysokość / prędkość / czas, ze wskazaniem na LO/LA)

- dane z GPS j.w.

 

Ilość danych = 8*16B = 128B. Do tego narzut transmisyjny (bity start i stop) 128B * 10 bitów/bajt = 1280bitów/ramkę danych. W praktyce dojdzie jeszcze jakiś nagłówek itp.

Przesyłając to przy prędkości 19200 bps mamy 15 ramek na sekundę.

Przy 9600 bps mamy 7,5 ramki

Przy 2400 bps mamy 1,8 ramki

 

Wydaje mi się że prędkość rzędu 5-20 ramek na sekundę (9600-57600 bps) była by do zaakceptowania zarówno dla możliwości modemów jak i potrzeb awioniki.

[SCRUBBY]

W jednej paczce nie trzeba przepychać każdorazowo wszystkich informacji. Można co drugą, co trzecią, wieloramkę powtarzać rodzaj informacji.

[Pitlab]

W jednej paczce nie trzeba przepychać każdorazowo wszystkich informacji. Można co drugą, co trzecią, wieloramkę powtarzać rodzaj informacji.

Ma to sens w przypadku GPSa, gdzie aktualizację danych mamy nie cześciej niż co 200 ms (5 Hz). Może mieć jeszcze sens w przypadku wolnozmiennych danych niekrytycznych takch jak temperatura. Poza tym takie szatkowanie zaciemnia protokół i wymaga włożenia więcej pracy w jego dekodowanie.

Myślę że o ile nie ma jakichś specjalnych wymagań co do szybkości aktualizacji konkretnych zmiennych, to zostawił bym wszystko w jednym kawałku a tempo wysyłania danych regulowałbym prędkością transmisji. Im prościej tym lepiej. Pamiętajmy że nie ma ściśle określonej strony odbiorającej dane. Im będzie prościej tym urządzenie będzie łatwiejsze do użycia.

Ewentualnie można zastosować protokół typu: pytanie-odpowiedź, ale to wymaga bardziej złożonego protokołu (tak mam w wariometrze). W aplikacji współpracującej z modemem, lub komputerem pokładowym odpytującym on-line, najprościej będzie zrobić wysyłaną okresowo stałą ramkę typu: nagłówek + komplet danych + suma kontrolna + kilka bitów przerwy na synchronizację.

[SCRUBBY]

...najprościej będzie zrobić wysyłaną okresowo stałą ramkę typu: nagłówek + komplet danych + suma kontrolna + kilka bitów przerwy na synchronizację.

To brzmi doskonale. Jednak nie zajmowałbym się odpytywaniem GPS'a a raczej zrobił broadcast z modelu. Zwłaszcza, gdy tracimy nad modelem kontrolę i zwala się gdzieś 2...3 km dalej nikt nie będzie pamiętać o konieczności zachowania jakiejkolwiek procedury. Wtedy tylko logger i ostatnia znana pozycja ratują.

[Pitlab]

...najprościej będzie zrobić wysyłaną okresowo stałą ramkę typu: nagłówek + komplet danych + suma kontrolna + kilka bitów przerwy na synchronizację.

To brzmi doskonale. Jednak nie zajmowałbym się odpytywaniem GPS'a a raczej zrobił broadcast z modelu. Zwłaszcza, gdy tracimy nad modelem kontrolę i zwala się gdzieś 2...3 km dalej nikt nie będzie pamiętać o konieczności zachowania jakiejkolwiek procedury. Wtedy tylko logger i ostatnia znana pozycja ratują.

 

Właśnie chodziło mi o broadcast (ciągłe, okresowe nadawanie stałych ramek z danymi bez zapytania). Tak jest najprościej oprogramować urządzenie (mało istotne, bo ja sobie poradzę) oraz oprogramować stronę odbierającą i przetarzającą dane (istotne, bo to będą robili użytkownicy, więc im prościej tym lepiej).

[SCRUBBY]

Podrzucę znaleziony w sieci jakiś czas temu LINK do dokumentu dot. elektronicznego kompasu.