[komarkus]

X4R mam w dronie hexa z Naza M v2. Odbiornik kiedyś, na starym firmware, zbindowałem ze zworką na Ch2-Ch3, Naza dostawała kanały 1-8 po CPPM, a na Ch9 nadajnika miałem osobne bezpośrednie sterowanie podwoziem (poprzez zwykłe PWM - na odbiorniku kanał 2). Taka ciekawa właściwość tego odbiornika. Wszystko zgodnie z instrukcją X4R, działało to dobrze. Po aktualizacji odbiornika do ACCST 2.1.0 - Naza nie reaguje, nawet zwykły kanał podwozia nie działa. Zbindowałem (wielokrotnie) na nowo w różnych konfiguracjach. I tak:

- bindowanie zwykłe, bez zworki, kanały fizyczne 1-4 działają w PWM poprawnie, czyli raczej odbiornik sprzętowo sprawny

- bindowanie ze zworką w odbiorniku na Ch2-3, w trybie Ch1-8 w OpenTX Telem ON/OFF (bez znaczenia) - zwykłe kanały 1-4 działają w PWM  j.w., CPPM brak

- bindowanie ze zworką w odbiorniku na Ch2-3, w trybie Ch9-16 w OpenTX Telem ON/OFF (bez znaczenia) - CPPM brak, na kanale Ch2 odbiornika powinien być Ch9 z nadajnika, a jest Ch10.

Dzieją się jakieś cuda. Nie wygląda to na awarię sprzętu, raczej problem (lub inne działanie) firmware ACCST v2.1.0 odbiornika X4R (odbiornik dla pewności też przeflaszowałem). Nie działa to teraz zgodnie z instrukcją X4R.

Może coś ktoś słyszał w temacie. Dopuszczam własny babol. Jeśli ktoś ma niewykorzystany X4R i chciałby pomóc, to proszę o sprawdzenie:

odbiornik zbindować w trybie "CPPM (Ch1-8) + Ch9-11", czyli zworka na piny sygnałowe Ch2-Ch3 plus włączenie odbiornika z F/S. Po udanym bindowaniu, kanał 9  nadajnika (skonfigurowany np. na przełącznik) powinien pojawić się na fizycznym Ch2 odbiornika, a Ch10 nadajnika na fizycznym CH3 odbiornika. CPPM trzeba mieć na czym sprawdzić, więc pomińmy to.

Twierdzę, że firmware 2.1.0 w X4R nie ma funkcjonalności starego. Ktoś to obali? Może zrobiłem jakiś błąd logiczny/techniczny?

 

[komarkus]

Zrobiłem drugie podejście. Wykopałem odbiornik z drona. Po kolei posprawdzałem jeszcze raz wszystko. Po bindowaniu ze zworką na Ch2-Ch3, na kanale fizycznym Ch1 odbiornika powinien pojawić się CPPM, a jest zwykły kanał serwowy PWM (1-szy w trybie bindowania 1-8, 9-ty w trybie 9-16). Zworka nie ma znaczenia podczas bindowania. Jestem już prawie pewien, że firmware 2.1.0 po prostu nie obsługuje CPPM w odbiorniku X4R. Szkoda.

[MAK]

Sprawdzam to z FrSky.

[komarkus]

To super. Może zabrakło miejsca w pamieci procka.

Ilość sprawdzeń i testów pozwoliła mi na sformułowanie powyższych wniosków niemalże autorytatywnie. Ale babole się zdarzają.

Jest jeszcze możliwość, że OpenTX (v. 2.3.9) podczas bindowania czegoś nie uwzględnia, co może nie pozwalać/nakazywać odbiornikowi na użycie CPPM.

Można ten problem też przetestować niezależnie. Robota nie wymaga dużo czasu ani wiedzy.

[MAK]

Mam testowy firmware od FrSky. Wyślę Ci link na PM.

[komarkus]

Dron lata, wszystko działa!

MAK, jestem po raz kolejny mile zaskoczony Waszym szybkim, konkretnym i kompetentnym wsparciem technicznym klienta. Ja bardzo to cenię. Dziękuję! Nie odpuszczajcie!

[MAK]

Czasem nam się udaje ?.

Faktycznie może być już krucho z pamięcią w sprzęcie ACCST, bo jest oddzielny plik firmware z CPPM.

Czy działa to jak piszą w README?

Cytuj

This Package is for X4R/X4R SB ACCST v2.1.0 firmware with CPPM output update.

Bind with ch9-ch16 mode ,ch1 will output CPPM,ch2-ch4 will output ch9-ch11; Bind with ch1-ch8 mode, ch1-ch4 will output PWM signal for ch1-ch4.For X4R SB, ch4 will always output SBUS signal.

 

[komarkus]

13 minut temu, MAK napisał:

Czy działa to jak piszą w README?

Na ile to rozumiem, to wszystko się zgadza w zakresie CPPM i trzech zwykłych kanałów - działa tak jak było na starym firmware. Bindowałem ze zworką na Ch2-3 i w OTX wybrałem tryb "Ch9-16 Telem ON" - to dało sukces. W Readme nic nie piszą o zworce/jumperze, więc sprawdziłem. Firmware CPPM nie potrzebuje zworki, na fizycznym Ch1 odbiornika zawsze jest CPPM z kanałami 1-8,  i na kolejnych kanałach fizycznych Ch2-4 są kanały Ch9-11. Z tego wniosek, że teraz będą funkcjonowały dwa firmware, jedno dla czterech zwykłych kanałów PWM (1-4 lub 9-12) , drugie dla CPPM + 3 kanały PWM. Zabrakło miejsca w procku na firmware uniwersalne, jak było po staremu :)

[komarkus]

Sprawdziłem jeszcze jedno. Bindowanie firmware v. CPPM  w trybie Ch1-8 OTX - daje cztery standardowe kanały PWM. Więc? Nie potrzeba dwóch wersji firmware, ale z kolei aby uzyskać kanały 9-12 chyba jednak drugie firmware będzie potrzebne (o ile nie załatwi tego jakaś zworka).

[MAK]

Wg tego co piszą, bindowanie bez zworki, w trybie CH1-8, powinno dać czyste PWM (oczywiście z SBUS na porcie 4 dla wersji SB). Natomiast bindowanie w trybie CH9-16 powinno dać CPPM na porcie 1 i CH9-11 na pozostałych portach (CH9-10 + SBUS dla wersji SB). Zworki zbędne. Z tego co piszesz tak właśnie to działa.

Podoba mi się, że na portach po CPPM są kanały CH9+. Można bardziej naturalnie wykorzystać kanały CH1-8 na SBUS i na kanałach CH9+ załatwiać jakieś dodatkowe funkcjonalności.

 

[komarkus]

Potwierdzam za wyjątkiem SBUS, nie wykorzystuję, nie sprawdzałem.

8 minut temu, MAK napisał:

Podoba mi się, że na portach po CPPM są kanały CH9+.

Nie rozumiem. Po CPPM są kanały 1-8 na fizycznym Ch1 odbiornika.

[MAK]

23 minuty temu, komarkus napisał:

Nie rozumiem. Po CPPM są kanały 1-8 na fizycznym Ch1 odbiornika.

Sorry, chyba za bardzo uprościłem :). Chodziło mi o to, że po porcie 1 (na którym jest CPPM 1-8), są porty 2-4 z kanałami 9-11. W przeciwieństwie do sytuacji, gdy na portach 2-4 są – niejako zdublowane – kanały 1-3.

[komarkus]

2 godziny temu, MAK napisał:

W przeciwieństwie do sytuacji, gdy na portach 2-4 są – niejako zdublowane – kanały 1-3.

Takiej sytuacji nie zaznałem. Albo Ch1-4 w PWM na fizycznych Ch1-4, albo CPPM 1-8 + 9-11.Dublowania kanałów w żadnym przypadku nie spotkałem. Chyba myślimy o różnych rzeczach.