QCZEK LRS

Autorskie projekty naszych użytkowników

Moderatorzy: marbalon, moderatorzy2014, moderatorzy

Awatar użytkownika
pawelsky
Posty: 9749
Rejestracja: środa 19 mar 2014, 02:03
Lokalizacja: Polska
Kontakt:

Re: QCZEK LRS

Post autor: pawelsky »

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.
Awatar użytkownika
qczek
Posty: 954
Rejestracja: wtorek 10 sty 2012, 19:04
Lokalizacja: Zielonki/Kraków

Re: QCZEK LRS

Post autor: qczek »

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 ;)
Awatar użytkownika
pawelsky
Posty: 9749
Rejestracja: środa 19 mar 2014, 02:03
Lokalizacja: Polska
Kontakt:

Re: QCZEK LRS

Post autor: pawelsky »

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.
Awatar użytkownika
qczek
Posty: 954
Rejestracja: wtorek 10 sty 2012, 19:04
Lokalizacja: Zielonki/Kraków

Re: QCZEK LRS

Post autor: qczek »

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...
Awatar użytkownika
pawelsky
Posty: 9749
Rejestracja: środa 19 mar 2014, 02:03
Lokalizacja: Polska
Kontakt:

Re: QCZEK LRS

Post autor: pawelsky »

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.
Awatar użytkownika
qczek
Posty: 954
Rejestracja: wtorek 10 sty 2012, 19:04
Lokalizacja: Zielonki/Kraków

Re: QCZEK LRS

Post autor: qczek »

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.
Awatar użytkownika
pawelsky
Posty: 9749
Rejestracja: środa 19 mar 2014, 02:03
Lokalizacja: Polska
Kontakt:

Re: QCZEK LRS

Post autor: pawelsky »

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.
Awatar użytkownika
qczek
Posty: 954
Rejestracja: wtorek 10 sty 2012, 19:04
Lokalizacja: Zielonki/Kraków

Re: QCZEK LRS

Post autor: qczek »

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?
Awatar użytkownika
pawelsky
Posty: 9749
Rejestracja: środa 19 mar 2014, 02:03
Lokalizacja: Polska
Kontakt:

Re: QCZEK LRS

Post autor: pawelsky »

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.
Barnaba
Posty: 28
Rejestracja: piątek 04 sie 2017, 12:50
Lokalizacja: Warszawa

Re: QCZEK LRS

Post autor: Barnaba »

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.
Awatar użytkownika
Ryszard_I
Posty: 79
Rejestracja: piątek 21 kwie 2017, 18:33
Lokalizacja: Legnica

Re: QCZEK LRS

Post autor: Ryszard_I »

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.
Awatar użytkownika
kolsek345
Posty: 825
Rejestracja: poniedziałek 28 sty 2013, 19:08
Lokalizacja: lubelskie

Re: QCZEK LRS

Post autor: kolsek345 »

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
Awatar użytkownika
Ryszard_I
Posty: 79
Rejestracja: piątek 21 kwie 2017, 18:33
Lokalizacja: Legnica

Re: QCZEK LRS

Post autor: Ryszard_I »

Mój nadajnik to Graupner Hott. Graupner ma swój "S.BUS" pod nazwą SUMD (115200bit/s) i to nie zagra z QCZEK.
Awatar użytkownika
kolsek345
Posty: 825
Rejestracja: poniedziałek 28 sty 2013, 19:08
Lokalizacja: lubelskie

Re: QCZEK LRS

Post autor: kolsek345 »

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
Awatar użytkownika
arek2081
Posty: 1054
Rejestracja: sobota 20 paź 2012, 04:53
Lokalizacja: kujawsko-pomorskie

Re: QCZEK LRS

Post autor: arek2081 »

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
ODPOWIEDZ