Zanim...
Zanim...

Zanim...


Polskie Forum FPV

Forum modelarzy i pilotów FPV
Dzisiaj jest poniedziałek 16 lip 2018, 05:43


Strefa czasowa UTC+1godz.




Nowy temat Odpowiedz w temacie  [ Posty: 445 ]  Przejdź na stronę Poprzednia  1 ... 26, 27, 28, 29, 30
Autor Wiadomość
 Tytuł: Re: QCZEK LRS
Post: poniedziałek 09 lip 2018, 14:08 
Offline
Awatar użytkownika

Rejestracja: środa 19 mar 2014, 02:03
Posty: 6175
Lokalizacja: Polska
qczek pisze:
No nie do końca tak może być

Nie tylko moze ale i tak jest

qczek pisze:
bo załóżmy, że RX woła Physical ID przypisane do GPS physical ID 0x03, a ty mu na to walisz application id RPM 0x0003 no i jak on to ma łyknąć musi to olać i tyle...

Normalnie, lyka i tyle, nie ma sztywnego powiazania miedzu Phys i App ID, to tylko konwencja, umowa pozwalajaca uniknac konfliktow. Co wiecej PhysID mozesz w sensorze zmienic i miec np. 2 rozne VLSS z dwoma roznymi PhysID przesylajace te same AppID dotyczace stanu baterii.

qczek pisze:
Chce bez angażowania odczytu tego co się dzieje na s port wysyłać dane sensorów może być wolniej, nie ważne...

Nie ma takiej opcji, musisz sluchac tego co sie dzieje, nie mozesz slac danych na slepo bo bedziesz mial konflikty i zadna telemetria nie przejdzie. Najprosciej jakbys wybral sobie jedno nieuzywane jeszcze PhysID i odpowiadal tylko na nie.

qczek pisze:
Dokładnie, ale o Physiacl ID decyduje RX a o application ID ja, więc mogę sobie wysyłać.

Nie decyduje, tylko kolejno odpytuje kazde PhysID (a te ktore odpowiadaja odpytuje czesciej).

qczek pisze:
Ja rozumiem to tak, że np dla gpsów mamy zakres application ID 0x0830~0x083f, czyli 16 róznych urządzeń typu GPS, jak mu wyślę dane tylko z application ID 0x0830 to będzie widział jeden GPS.

To jak zostanie odczytany Application ID zalezy od implementacji. Taranis o ile pamietam odczytuje pelny zakres, ale musialbym sprawdzic. Inne implementacje moga ignorowac inne AppID niz pierwsze z zakresu, albo wszystkie traktowac jako jedno i to samo.

qczek pisze:
Pytanie jest takie, co się stanie jak on zapyta o variometr a dostanie dane gps ;)

To co napisalem Ci wczesniej.


Na górę
 Wyświetl profil  
 
 Tytuł: Re: QCZEK LRS
Post: poniedziałek 09 lip 2018, 14:18 
Offline
Awatar użytkownika

Rejestracja: wtorek 10 sty 2012, 19:04
Posty: 836
Lokalizacja: Zielonki/Kraków
pawelsky pisze:
To jak zostanie odczytany Application ID zalezy od implementacji.

No właśnie a powinno jednoznacznie od specyfikacji protokołu :)
Nie ważne dzięki wielkie za info poeksperymentuje,
Odnoszę wrażenie, że to physical ID ma znaczenie tylko takie, że reguluje dostęp urządzeń typu slave to magistrali... Master (RX) sobie zarządza szyną, i decyduje(wysyłając rożne physical ID) teraz ty dostajesz czas na odpowiedz, a teraz ty ....
Wiec biorąc pod uwagę, że będzie tylko jeden master i jeden slave, to wysyłając ramki bez przerwy, z wszystkimi które mi sa potrzebne application id transfer powinnien się odbywać ok pomijając te ramki, które będą kolidować z nadawaniem Mastera (wtedy suma kontrolna się nie zgodzi i już)...
Tak że czysto teoretycznie powinno być dobrze ;)


Na górę
 Wyświetl profil  
 
 Tytuł: Re: QCZEK LRS
Post: poniedziałek 09 lip 2018, 15:15 
Offline
Awatar użytkownika

Rejestracja: środa 19 mar 2014, 02:03
Posty: 6175
Lokalizacja: Polska
qczek pisze:
Odnoszę wrażenie, że to physical ID ma znaczenie tylko takie, że reguluje dostęp urządzeń typu slave to magistrali... Master (RX) sobie zarządza szyną, i decyduje(wysyłając rożne physical ID) teraz ty dostajesz czas na odpowiedz, a teraz ty ....

Dokladnie tak jest. Pamietaj rowniez ze niektore sensory wysylaja wiecej niz jedno AppID - np. GPS zeby przeslac wszystkie dane musi byc zawolany w sumie 7 razy.

qczek pisze:
Wiec biorąc pod uwagę, że będzie tylko jeden master i jeden slave

No nie do konca jeden slave, bo zawsze ktos moze podlaczyc jakies sensory do S.Porta i slaveow bedziesz mial wiecej

qczek pisze:
to wysyłając ramki bez przerwy, z wszystkimi które mi sa potrzebne application id transfer powinnien się odbywać ok pomijając te ramki, które będą kolidować z nadawaniem Mastera (wtedy suma kontrolna się nie zgodzi i już)...

Oj, tu bedziesz musial miec sporo szczescia zeby na slepo wstrzelic sie w odpowiedni moment, to moim zdaniem nie jest dobry pomysl.


Na górę
 Wyświetl profil  
 
 Tytuł: Re: QCZEK LRS
Post: poniedziałek 09 lip 2018, 15:19 
Offline
Awatar użytkownika

Rejestracja: wtorek 10 sty 2012, 19:04
Posty: 836
Lokalizacja: Zielonki/Kraków
pawelsky pisze:
No nie do konca jeden slave, bo zawsze ktos moze podlaczyc jakies sensory do S.Porta i slaveow bedziesz mial wiecej

Założenie mam takie, że sport jest używany do konwersji mavlinka do danych sport, czy to bezpośrednio do taranisa, czy to retransmisji przez jakiś odbiornik frsky, jeśli QLRS montujesz sobie na maszcie czy coś w tym stylu. Wtedy masz jeden slave jeden master... zobaczymy...


Na górę
 Wyświetl profil  
 
 Tytuł: Re: QCZEK LRS
Post: poniedziałek 09 lip 2018, 15:32 
Offline
Awatar użytkownika

Rejestracja: środa 19 mar 2014, 02:03
Posty: 6175
Lokalizacja: Polska
qczek pisze:
Założenie mam takie, że sport jest używany do konwersji mavlinka do danych sport, czy to bezpośrednio do taranisa, czy to retransmisji przez jakiś odbiornik frsky, jeśli QLRS montujesz sobie na maszcie czy coś w tym stylu. Wtedy masz jeden slave jeden master... zobaczymy...

Jesli przez konwersje mavlinka do S.Port rozumiesz to ze do QRXa wchodzi mavlink, a z QTXa wychodzi S.Port to zrobisz to bez problemu, bo sam sobie w pelni zarzadzasz transmisja. Nie mozesz jednak tego samego strumienia retransmitowac bo on juz zawiera polling 0x7E 0xXX ktory jest generowany przez odbiornik, co wiecej do tego samego odbiornika mozna podlaczyc dodatkowe sensory ktore potencjalnie moga kolidowac z tym co wysylasz.


Na górę
 Wyświetl profil  
 
 Tytuł: Re: QCZEK LRS
Post: poniedziałek 09 lip 2018, 15:37 
Offline
Awatar użytkownika

Rejestracja: wtorek 10 sty 2012, 19:04
Posty: 836
Lokalizacja: Zielonki/Kraków
pawelsky pisze:
qczek pisze:
Założenie mam takie, że sport jest używany do konwersji mavlinka do danych sport, czy to bezpośrednio do taranisa, czy to retransmisji przez jakiś odbiornik frsky, jeśli QLRS montujesz sobie na maszcie czy coś w tym stylu. Wtedy masz jeden slave jeden master... zobaczymy...

Jesli przez konwersje mavlinka do S.Port rozumiesz to ze do QRXa wchodzi mavlink, a z QTXa wychodzi S.Port to zrobisz to bez problemu, bo sam sobie w pelni zarzadzasz transmisja. Nie mozesz jednak tego samego strumienia retransmitowac bo on juz zawiera polling 0x7E 0xXX ktory jest generowany przez odbiornik, co wiecej do tego samego odbiornika mozna podlaczyc dodatkowe sensory ktore potencjalnie moga kolidowac z tym co wysylasz.


Dokładnie :) do QLRS RX wchodzi mavlink, z QLRS TX wychodzi mavlink + sport :). Przesyłanie gołego sporta jest nie możliwe, za mały mam transfer...
A jak to zadziała, to zrobię jeszcze że przy przesyłaniu danych raw typu LTM, LTM po stronie TX jest dekodowany dodatkowo to sport.


Na górę
 Wyświetl profil  
 
 Tytuł: Re: QCZEK LRS
Post: poniedziałek 09 lip 2018, 15:44 
Offline
Awatar użytkownika

Rejestracja: środa 19 mar 2014, 02:03
Posty: 6175
Lokalizacja: Polska
qczek pisze:
Dokładnie :) do QLRS RX wchodzi mavlink, z QLRS TX wychodzi mavlink + sport :).

No to takie cos Ci zadziala, ale do retransmisji to sie nie nadaje.


Na górę
 Wyświetl profil  
 
 Tytuł: Re: QCZEK LRS
Post: poniedziałek 09 lip 2018, 16:52 
Offline
Awatar użytkownika

Rejestracja: wtorek 10 sty 2012, 19:04
Posty: 836
Lokalizacja: Zielonki/Kraków
pawelsky pisze:
qczek pisze:
Dokładnie :) do QLRS RX wchodzi mavlink, z QLRS TX wychodzi mavlink + sport :).

No to takie cos Ci zadziala, ale do retransmisji to sie nie nadaje.
Czemu?


Na górę
 Wyświetl profil  
 
 Tytuł: Re: QCZEK LRS
Post: poniedziałek 09 lip 2018, 16:57 
Offline
Awatar użytkownika

Rejestracja: środa 19 mar 2014, 02:03
Posty: 6175
Lokalizacja: Polska
qczek pisze:
Czemu?

Z przyczyn o ktorych pisalem wczesniej - obecnosc bajtow pollingu (0x7E 0xXX) ktore duplikowalyby sie z tym co produkuje odbiornik oraz brak synchronizacji z polingiem odbiornika.


Na górę
 Wyświetl profil  
 
 Tytuł: Re: QCZEK LRS
Post: środa 11 lip 2018, 21:21 
Offline

Rejestracja: piątek 04 sie 2017, 12:50
Posty: 28
Lokalizacja: Warszawa
Witajcie,

Ja tak tylko chciałem zdać raport z lotów próbnych: ponad 10 km zasięgu na wysokości 60-100m AGL, za linią drzew, przy mocy 1W, RSSI chyba ok. 99%. Ograniczeniem była bateria, stary pakiet 3S 4Ah. Muszę jeszcze skonfigurować poprawnie, bo QGroundControl pokazywał 240% jakości sygnału. Akurat zawiesiła mi się karta pamięci i mam błąd odczytu flight loga. Genialne rozwiązanie ten QLRS :) Dzięki Qczku! W końcu tracąc wizję mam najważniejsze parametry modelu i się o niego nie boję. 1,5 W nadajnik Arkbird UHF dawał mi zasięg 1-5 km w zależności od jego humoru.. Ograniczeniem była bateria, stary pakiet 3S 4Ah.


Na górę
 Wyświetl profil  
 
Wyświetl posty nie starsze niż:  Sortuj wg  
Nowy temat Odpowiedz w temacie  [ Posty: 445 ]  Przejdź na stronę Poprzednia  1 ... 26, 27, 28, 29, 30

Strefa czasowa UTC+1godz.


Kto jest online

Użytkownicy przeglądający to forum: andrzej o, zbipok i 3 gości


Nie możesz tworzyć nowych tematów
Nie możesz odpowiadać w tematach
Nie możesz zmieniać swoich postów
Nie możesz usuwać swoich postów
Nie możesz dodawać załączników

Szukaj:
Przejdź do:  
Technologię dostarcza phpBB® Forum Software © phpBB Group

Strona korzysta z plików cookie w celu realizacji usług zgodnie z . Polityką prywatności
Możesz określić warunki przechowywania lub dostępu do cookie w Twojej przeglądarce lub konfiguracji usługi.