ok, sprawdzę i podeśle.qczek pisze: Dało by się, ale podeślij jakieś linki do tego mapowania, bo zamieszczone w wątku nie działają...
Krzysiek
Przy okazji zapytam, jak "Race Mode" ma się do "High data rate"?
Czy te tryby mogą ze sobą współdziałać ?
Moderatorzy: marbalon, moderatorzy2014, moderatorzy
ok, sprawdzę i podeśle.qczek pisze: Dało by się, ale podeślij jakieś linki do tego mapowania, bo zamieszczone w wątku nie działają...
Krzysiek
Tak mogą. Race Mode to użycie szerszego pasma i wtedy jest troszkę mniejszą czułość odbiornika ale za to szybciej dane idą w powietrzu. Natomiast high data rate wymusza częstsze przesyłanie ramek z telemetria kosztem ramek z danymi kanałów rc. To taki tryb eksperymentalny... Myślę że bez zmian w arduplane i ground station nie da się tego praktycznie wykorzystac do ładowania misji itp itd. W przypadku zgubienia pojedynczej ramki cały mesage mavlinka musi być przesyłana.... Może jak by ktoś napisał na arduino taka warstwę łącza danych co by potrafiła ogarnąć i przesłać ponownie tylko uszkodzone ramki...TomekMZ pisze:ok, sprawdzę i podeśle.qczek pisze: Dało by się, ale podeślij jakieś linki do tego mapowania, bo zamieszczone w wątku nie działają...
Krzysiek
Przy okazji zapytam, jak "Race Mode" ma się do "High data rate"?
Czy te tryby mogą ze sobą współdziałać ?
Umieściłem poprawne linki tam w wątku, tutaj też dam:qczek pisze:Dało by się, ale podeślij jakieś linki do tego mapowania, bo zamieszczone w wątku nie działają...TomekMZ pisze: Super wiadomość :) wielkie dzięki.
Od razu też zapytam, czy była by możliwość wprowadzenia modyfikacji
opisanych w tym wątku: https://github.com/krzysztofkuczek/QCZEK_LRS/issues/33
Dodanie tego uczyniłoby cały QCZEK LRS praktycznie idealnym.
Krzysiek
ok dzięki, zrobi się..TomekMZ pisze:Umieściłem poprawne linki tam w wątku, tutaj też dam:qczek pisze:Dało by się, ale podeślij jakieś linki do tego mapowania, bo zamieszczone w wątku nie działają...TomekMZ pisze: Super wiadomość :) wielkie dzięki.
Od razu też zapytam, czy była by możliwość wprowadzenia modyfikacji
opisanych w tym wątku: https://github.com/krzysztofkuczek/QCZEK_LRS/issues/33
Dodanie tego uczyniłoby cały QCZEK LRS praktycznie idealnym.
Krzysiek
https://github.com/iNavFlight/inav/blob ... lemetry.md
("Available SmartPort (S.Port) sensors")
https://github.com/iNavFlight/inav/blob ... /mavlink.c
(inavToArduCopterMap, inavToArduPlaneMap, APM_PLANE_MODE, APM_COPTER_MODE, ...)
Z tego co rozumiem, to musiałyby być osobne mapowania (inav i APM * typ modelu) do tego co S.Port obsługuje a więc i Lua.
Jednocześnie Tx przy odkodowywaniu enc. mavlinka, używał mapowania tylko na potrzeby statusów dla S.Port
ale na UART (np. do BT) przerzucałby je już tak jak dostał oryginalnie je od danego FC.
super, dzięki, to się wielu użytkowników ucieszy.qczek pisze:ok dzięki, zrobi się..
Ustawiam w radyjku PPM i dalej lipa.maxiiii pisze:Ustaw w radyjku PPM.
Nie zaznaczyles SerialRX na uarcie w zakladce Portsokruszek pisze:Ustawiam w radyjku PPM i dalej lipa.
Zaznaczam Serial RX na UART1 i dalej nic.pawelsky pisze:Nie zaznaczyles SerialRX na uarcie w zakladce Portsokruszek pisze:Ustawiam w radyjku PPM i dalej lipa.
Powinienes zaznaczyc na UART6okruszek pisze:Zaznaczam Serial RX na UART1 i dalej nic.
RX - dioda szybko miga/mruga.maxiiii pisze:Czy to jest "mruganie" szybkie ciągłe czy wolne przerywane? Czy możesz ustawić cppm na wyjściu odbiornika?
Ale nic nie podłączyłem pod UART6 więc po co aktywować.pawelsky pisze:Powinienes zaznaczyc na UART6okruszek pisze:Zaznaczam Serial RX na UART1 i dalej nic.
Bo SBUS jest podlaczony do UART6okruszek pisze:Ale nic nie podłączyłem pod UART6 więc po co aktywować.