FrSky - ramka cppm 18ms, wyimaginowany problem?

[qczek]

Cześć,
Mam takie pytanie, bo w sieci znalazłem wiele postów na temat nie możliwości użycia więcej niż 6 kanałów w odbiornikach z wyjściem cppm i ramce 18ms, jakoby brak synchronizacji był jakimś problemem. Przed momentem dorobiłem do swojego FC odczyt cppm i działa dla 8 kanałów nawet po więcej niż 2000ms na każdy.

Wygląda to tak:

Odczyty kanałów



Sygnał z analizatora, specjalnie dałem gaz na trochę mniej żeby widzieć co gdzie jest, niemniej działa na dowolnych wartościach. 8 kanał jest ustawiony na 125%...



Algorytm jest taki, że albo jest synch i jest powyżej 3000 albo jak go nie ma, to przecież wiadomo, że po 8 kanałach jest synch, a potem jest od nowa 1,2,3,4... i tak dalej.
Proste jak konstrukcja cepa, albo jak nie czaje jakiś innych zagrożeń....
Po godzinie pracy bez synchronizacji jest nadal ok...

Pozdrawiam
Krzysiek

[miś]

Tak będzie jeśli FC ma na sztywno ustaloną ilość kanałów. Ale jeśli robi autodetekcję, to już nie zadziała jeśli nie będzie przerwy synchronizacyjnej - i tu znów zależy to od FC jaka jest minimalny czas przerwy aby została wykryta. Niektóre FC wymagają ponad 3ms.

[qczek]

Dzięki za odpowiedz,
Ilość kanałów mam ustawianą parametrem, więc jest ok. Zresztą autodetekcje także można zrobić tylko przy włączaniu FC, wtedy kiedy obie wajchy są na środku, wtedy nie ma obawy, że będzie za krótka przerwa...
W sumie to problem jest z jakimiś tam FC nie za dobrze napisanymi, niż z FrSky ;)
Pozdrawiam
Krzysiek

[bluuu]

wszystko powinno byc ok jezeli na kanale 8 nie bedziesz przekraczal 2000

[qczek]

wszystko powinno byc ok jezeli na kanale 8 nie bedziesz przekraczal 2000

Raczej to nie ma znaczenia, ważne żeby żaden kanał nie przekroczył długości impulsu sunchronizacyjnego czyli 3ms.

[bluuu]

ale wazna jest jeszcze dlugosc calej ramki

[miś]

No, przy długości ramki 18ms, ustawiając na 8 kanałach po 2ms dostajemy 16ms, i przerwę synchronizującą też 2ms, czyli nie do odróżnienia od impulsu kanału. Ale wystarczy żeby dowolne dwa kanały były na środku i już się problem rozwiązuje.

[qczek]

Panowie,
Przecież mamy do czynienia z aparaturą cyfrową, która sama tworzy ramkę i ma w dupie tak naprawdę to jak wygląda ramka po stronie nadajnika. RX dostaje dane liczbowe i na ich podstawie tworzy przebieg wyjściowy. Projektanci musieli by być kompletnymi amatorami, żeby to zrypać.

Zrobiłem mały test
ustawiłem limity i wagi na 125 procent na wszystkie kanały, czyli kanały powinny być na 125% czyli 1000+1250=2250.
Jak widać, oprogramowanie RX wprowadza ograniczenie do jakiś 2150 pewnie..., wszytko działa ok przy takim wystarowaniu, mogę zmienić każdy z kanałów i reaguje poprawnie....


Teraz jak wygląda ramka, nadal 18ms
Przerwa synchronizacyjna jest bardzo mała


Natomiast kanały są ograniczone ale ok.


Nie ma możliwości, żeby kanały się zlały, każdy kanał ma po prostu generowane zbocze narastające i opadające i tyle, niezależnie od jego wartości....

Pozdrawiam
Krzysiek

[miś]

Projektanci musieli by być kompletnymi amatorami, żeby to zrypać.

I w przypadku FrSky niestety, ale dali du.. , znaczy popisali się
Weź FC które rozpoznaje ilość kanałów PPM na podstawie przerwy synchronizacyjnej która powinna być dłuższa niż 3ms... W tym przypadku zgłupieje. I nie będzie to wina FC ale zdup...ego protokołu w FrSky.
Jestem pewien że MK i MWC nie dadzą rady z opanowaniem tego cuda. Jak z resztą FC - nie wiem.

[qczek]

Projektanci musieli by być kompletnymi amatorami, żeby to zrypać.

I w przypadku FrSky niestety, ale dali du.. , znaczy popisali się
Weź FC które rozpoznaje ilość kanałów PPM na podstawie przerwy synchronizacyjnej która powinna być dłuższa niż 3ms... W tym przypadku zgłupieje. I nie będzie to wina FC ale zdup...ego protokołu w FrSky.
Jestem pewien że MK i MWC nie dadzą rady z opanowaniem tego cuda. Jak z resztą FC - nie wiem.

Ja mam wrażenie, że to jednak programiści MK czy MWC dali dupy :). Przerwa 3ms, o zaszłość z przed lat, która umożliwia dekodowanie sygnału za pomocą rejestru przesuwającego. Jak ktoś w 21 wieku używa procesora, to dodanie 1 linijki kodu raczej nie jest problemem, pod warunkiem, że widzi się konieczność jej dodania ;). Z całym szacunkiem dla programistów tych projektów, ale zakładanie że sygnał będzie taki jak podaje specyfikacja, jest chyba nie najlepsze, jak tak podchodzą do tematu, to może okazać się, że jak by przez zakłócenia pojawił się jakiś dodatkowy pik (coś jak 9 kanał) to okaże się, że np przekroczą indeks jakiejś tabeli wewnętrznej, bo założyli że będzie max 8 kanałów a jak jest więcej to dupa i to nie ich wina ;).
Nieważne zresztą to tylko filozofowanie, każdy robi jak chce, w każdym razie mi działa ok :)
Pozdrawiam
Krzysiek

[Royce]

Na stronie FRSky można pobrać firmware CPPM 27ms m.in. do D8R-XP i D4R-II .
http://www.frsky-rc.com/download.asp

Czy to powinno załatwić problem ? Czy oprócz długości ramki w apce trzeba przestawić coś jeszcze ?

[miś]

jak by przez zakłócenia pojawił się jakiś dodatkowy pik (coś jak 9 kanał) to okaże się, że np przekroczą indeks jakiejś tabeli wewnętrznej,

No to już byłby szczyt głupoty. Tablice są na 12 kanałów, bo tyle w PPM'ie może być bez problemu wysyłane no i przekroczenie indexu blokuje zapis do tablicy, a po wykryciu przerwy >3ms index jest zerowany i zaczyna się wszystko od początku.
Pamiętaj że PPM może mieć dowolną ilość kanałów. Mam aparature co generuje 6 kanałowy PPM, są 8,9 11,12... Jeśli ma być plug and play to musi być autorozpoznanie ilości kanałów na podstawie przerwy synchronizacyjnej. Po to ona została wymyślona.
Z tego co widzę to Ty tutaj operujesz zaszłością mówiącą o tym że w PPM powinno być 8 kanałów i nic więcej.

[qczek]

Ilość kanałów może być dowolna, tak samo jak długość synchronizacji, pod warunkiem, że przynajmniej raz na początku długość synchronizacji będzie 2 razy pod żad większa niż długość najdłuższego impulsu :)
Plug and play, można zrobić albo nie sprytnie i cały czas szukać synchronizacji, albo tak jak pisałem, na samym początku gdy wajchy nie są na max'a policzyć ile jest kanałów i dać sobie już z tym spokój :).

Pozdrawiam
Krzysiek