Zanim...
Zanim...



Polskie Forum FPV

Forum modelarzy i pilotów FPV
Dzisiaj jest środa 17 paź 2018, 09:05


Strefa czasowa UTC+1godz.




Nowy temat Odpowiedz w temacie  [ Posty: 525 ]  Przejdź na stronę Poprzednia  1 ... 27, 28, 29, 30, 31, 32, 33 ... 35  Następna
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: 6540
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: 856
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: 6540
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: 856
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: 6540
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: 856
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: 6540
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: 856
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: 6540
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  
 
 Tytuł: Re: QCZEK LRS
Post: czwartek 19 lip 2018, 20:53 
Offline
Awatar użytkownika

Rejestracja: piątek 21 kwie 2017, 18:33
Posty: 44
Lokalizacja: Legnica
Planuję zastosować QCZEK LRS jako link pracujący z AP@OSD Pitlab@Zbig. Do tej pory jako link pracuje eLeReS. Mam zrobioną retransmisję z 2,4GHz na 433MHz. Tx eLeReS Max sterowany z odbiornika 2,4GHz sygnałem PPM. W celach testowych i poznawczych przygotowałem moduły LORA. Jako Tx moduł o mocy1W sterowany PPM z odbiornika 2,4GHz natomiast jako Rx moduł 100mW z wyjściem S-BUS do pracy z AP Pitlab@Zbig. Całość zagrała "od strzała". Jest jednak coś co mi się nie podoba. Tym czymś jest kultura pracy serw. W nadajniku uruchamiam tester serw który porusza wybranymi serwami w zakresie od -100% do +100% w czasie 3 sek. Po załączeniu testu serwa nie pracują płynnie tylko skokowo w takt mrugającej diody podpiętej do M0 Rx. Dla pokonania drogi od -100% do +100% serwo wykonuje około 25 kroków. Przeprogramowałem Rx tak aby można było podłączyć serwa bezpośrednio do M0, M1 lub AUX i w każdym przypadku serwo zachowuje się identycznie czyli porusza się skokowo. Z eLeReSem serwa pracują płynnie. Gdzie szukać przyczyny?



Ostatnio zmieniony niedziela 22 lip 2018, 00:19 przez Ryszard_I, łącznie zmieniany 4 razy

Na górę
 Wyświetl profil  
 
 Tytuł: Re: QCZEK LRS
Post: czwartek 19 lip 2018, 21:14 
Offline
Awatar użytkownika

Rejestracja: poniedziałek 28 sty 2013, 19:08
Posty: 805
Lokalizacja: lubelskie
Mozesz spróbować zmienic PPM w nadajniku na PXX lub SBUS co powinno poprawic nieco sytuacje ale cudów sie nie spodziewaj bo ten system tak ma , aczkolwiek mnie w to w locie w żaden sposob nie przeszkadza.

_________________
EASY STAR II 1800mm+KFC32FTB - RC:TaranisQ7-Frsky-100mW+Patch14dbi ,AV:500mW 5.8GHz+Patch 23dBi , Z-84(APM),QLRS-4SLion3500mAh-60kmUAV


Na górę
 Wyświetl profil  
 
 Tytuł: Re: QCZEK LRS
Post: czwartek 19 lip 2018, 22:13 
Offline
Awatar użytkownika

Rejestracja: piątek 21 kwie 2017, 18:33
Posty: 44
Lokalizacja: Legnica
Mój nadajnik to Graupner Hott. Graupner ma swój "S.BUS" pod nazwą SUMD (115200bit/s) i to nie zagra z QCZEK.


Na górę
 Wyświetl profil  
 
 Tytuł: Re: QCZEK LRS
Post: piątek 20 lip 2018, 21:44 
Offline
Awatar użytkownika

Rejestracja: poniedziałek 28 sty 2013, 19:08
Posty: 805
Lokalizacja: lubelskie
QLRS to system duzego zasiegu - najlepiej pod APM/PIXHAWK - gdzie autopilot zajmuje sie praca serw w 90% czasu w sposób płynny. Sterowanie na duzych odleglosciach/wysokosciach z aparatury nie wymaga sumie jakiejś dużej płynności - co innego przy lataniu akrobatycznym lub racerem.Ale jest tez tryb RACER - nie testowalem go osobiscie - podobno opoznienie i moze plynnosc jest tam lepsza.

_________________
EASY STAR II 1800mm+KFC32FTB - RC:TaranisQ7-Frsky-100mW+Patch14dbi ,AV:500mW 5.8GHz+Patch 23dBi , Z-84(APM),QLRS-4SLion3500mAh-60kmUAV


Na górę
 Wyświetl profil  
 
 Tytuł: Re: QCZEK LRS
Post: niedziela 22 lip 2018, 20:34 
Offline
Awatar użytkownika

Rejestracja: sobota 20 paź 2012, 04:53
Posty: 888
Lokalizacja: kujawsko-pomorskie
Dziś pierwsze testy trackera który pracuje z systemem QLRS, trzeba jeszcze delikatnie dopracować jego działanie. Komunikacja trackera z nadajnikiem przez bluetooth. Zapowiada się interesująco ;-) .


_________________
Optic 6 (expander 12ch), eleres mod, OSD Remzibi, Fox 800, AP eleres V2, sony 600, gopro 4 sliver, pixhawk


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

Strefa czasowa UTC+1godz.


Kto jest online

Użytkownicy przeglądający to forum: zbipok i 2 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.