zamiennik dla XBee

[Rurek]

Zassałem tę aplikację do ustawiania....rzeczywiście max to 57600
Co do komunikacji z MKtolls - a czy w windowsie odpowiedni port com skonfigurowałeś na 57600/8/N/1/Xoff ? Powinno banglać w/g opisu kolegi z RCG...

[breweryhills]

A może to problem tego adaptera do PC opartymi o CP2102 co to Sebastian wskazuje jako awaryjne?!

Nie, to nie wina CP. CP działa OK, jeśli działa. Jak się zepsuje to nie działa wcale Natomiast obstawiam że nie wyrabiają się z rzeczywistą, użyteczną przepustowością. Normą u producentów takich modułów RF jest to, że podają prędkość transmisji RF brutto. Czyli prędkość z jaką nadawane są wszystkie dane, nie tylko te "użyteczne", zwane po angielsku "payload" ale i reszta - preambuła, suma kontrolna, adresy i cała reszta służąca kontroli transmisji.

Być może w MK Toolu jest możliwość zwiększenia odstępu pomiędzy pakietami, nie wiem. Nie mam teraz jak sprawdzić. Zmniejszenie częstotliwości pakietów na pewno by pomogło.

[Rufio]

a czy w windowsie odpowiedni port com skonfigurowałeś na 57600/8/N/1/Xoff ? Powinno banglać w/g opisu kolegi z RCG...

Ręki nie dam sobie odciąć, ale jestem przekonany, że COMa co do "bitów na sek" ustawiłem na 57600 (właściwie to nie widziałem różnicy choć może przy 9600 nieco szybciej się "zatykał").
Rurek, daj tego linka do RCG (chyba że to w tym moim linku jest a ja nie doczytałem).

Sebastian, może jest tak jak piszesz.
Jakoś intuicyjnie czuję, że oba parametry powinny być równe. Bo jak to:
57600 ma być przepchane rurką o średnicy 19200?

[Rurek]

Z twojego linku:

6.- Change "RF TRx rate" to 19200bps and "Serial Rate" to 57600bps. then press Write, "write succeed¡" must appears.

7.- Make the same to the other wireless module.

8.- Connect the copter wireless module, like that:

MODULE--------------------SEEDUINO/FLYDUINO/ARDUINO/BLACK VORTEX
TX----------------------------RX3 Serial #3 port
RX----------------------------TX3 Serial #3 port
VCC--------------------3.3v TO 5V VCC PIN
GND--------------------------GND PIN.

9.- In the Apm, take care to change the the bauds to 57600bps, and put the wireless module COM.
10.- Push connect and.................. It Workssssssssssssssssssssssssss.

a że przez rurkę o mniejszym fi jest ciężko...rurek Ci to mówi

Khmmm - właśnie - tu jest mowa o xxxiduino a nie o mikrokopterze....może jednak jest ból z nim...

[Rufio]

Z twojego linku:

6.- Change "RF TRx rate" to 19200bps and "Serial Rate" to 57600bps. then press Write, "write succeed¡" must appears.

7.- Make the same to the other wireless module.

8.- Connect the copter wireless module, like that:

MODULE--------------------SEEDUINO/FLYDUINO/ARDUINO/BLACK VORTEX
TX----------------------------RX3 Serial #3 port
RX----------------------------TX3 Serial #3 port
VCC--------------------3.3v TO 5V VCC PIN
GND--------------------------GND PIN.

9.- In the Apm, take care to change the the bauds to 57600bps, and put the wireless module COM.
10.- Push connect and.................. It Workssssssssssssssssssssssssss.

a że przez rurkę o mniejszym fi jest ciężko...rurek Ci to mówi

Khmmm - właśnie - tu jest mowa o xxxiduino a nie o mikrokopterze....może jednak jest ból z nim...

upsik Rurek o rurce - tak jak Ci mówiłem, mam do tego talent , sorki.

Wszystkie punkty zrobiłem jak napisane, z tym że w 8ym nie podłączałem
MODULE--------------------SEEDUINO/FLYDUINO/ARDUINO/BLACK VORTEX
bo niby do czego.
O parametrach COM nic nie wyczytałem i tylko intuicyjnie COMa przestawiłem na 57600, resztę zostawiłem domyślnie i wyjdzie na 57600/8/N/1/Xoff.

[breweryhills]

Jakoś intuicyjnie czuję, że oba parametry powinny być równe. Bo jak to:
57600 ma być przepchane rurką o średnicy 19200?

Nie muszą być równe. W module RF masz bufor, który potrafi przyjąć więcej danych niż jest w stanie w danej chwili przepchać. Wyobraź sobie zlewozmywak kuchenny - gdy odkręcisz kran to woda leci i spływa na bieżąco. Oznacza to że przepływność krany nie jest większa niż przepływność rury idącej do kanalizy. Możesz jednak jednym ruchem wlać wiadro wody do zlewozmywaka. Jeżeli ilość wlanej wody nie jest większa niż pojemność zlewozmywaka, to woda się nie przeleje ale trzeba będzie troszkę poczekać zanim spłynie. To jest właśnie ten bufor. Jeśli jednak nie poczekasz aż cała woda spłynie i wlejesz kolejne wiadro, to nadmiar wody wyleje się ze zlewozmywaka - to jest właśnie przepełnienie bufora.

[Rufio]

Wszystko pięknie z tym zlewem i kranem ale nie w przypadku, gdy kran leje wodę szybciej zlew jest w stanie się opróżnić.
Rozumiem, że te 19200 na transmisję to po prostu za "cienka rura odpływowa".
To jak interpretować Baud rate dla COMa (Serial rate) - w Arduino jeśli nadaję z prędkością x to w terminalu też musi być X bo inaczej krzaczory wychodzą?

[breweryhills]

Wszystko pięknie z tym zlewem i kranem ale nie w przypadku, gdy kran leje wodę szybciej zlew jest w stanie się opróżnić.

No właśnie to jest ten sam przypadek co z wiadrem

Rozumiem, że te 19200 na transmisję to po prostu za "cienka rura odpływowa".
To jak interpretować Baud rate dla COMa (Serial rate) - w Arduino jeśli nadaję z prędkością x to w terminalu też musi być X bo inaczej krzaczory wychodzą?

Musisz w module RF ustawić tą samą prędkość co w Arduino. Przy czym nie ma znaczenia ustawienie jej we właściwościach portu w menadżerze - te ustawienia są brane pod uwagę tylko wtedy, gdy aplikacja otwiera port ale nie konfiguruje go a tak się obecnie nie robi - każdy program ma swoje opcje ustawień portu, które w momencie jego otwarcia nadpisują te z właściwości portu w systemie.

Nie znam Arduino, więc nie wiem czy można ograniczyć częstotliwość ramek. Bo poza prędkością "baud rate" to właśnie rzeczywista ilość bajtów na sekundę ma tu znaczenie. No i najprawdopodobniej tu jest pies pogrzebany - na początku działa, bo moduł RF ma pusty bufor do którego może przyjmować czekające na nadawanie ramki z Arduino. W miarę jednak jak Arduino wysyła więcej danych niż moduł RF przepycha, ten bufor stopniowo się zapełnia aż dochodzi do przepełnienia i zerwania transmisji. Po restarcie znowu działa przez chwilkę itd.

[Rufio]

kurna muszę to zrozumieć a z materiałów w necie średnio mi to idzie.
Rozumiem to na chwilę obecną w ten sposób:
1. FC (czy Arduino) otwiera port do komunikacji "z prędkością" np. 9600bps.
2. Aby odbiorca rozumiał co jest mu wysyłane też musi komunikować się "z prędkością" 9600.
Inaczej będzie czytał śmieci tzn. przy ustawieniu 19600 będzie 2 razy za często sięgał po transmitowane dane.
Wyobrażam sobie, że nadawca jak i odbiorca muszą nadawać na tej samej "częstotliwości" czy inaczej pisząc, muszą gadać tym samym "językiem" - inaczej się nie dogadają (polski-polski albo wszyscy jeździmy prawą stroną).
Teraz do tego dochodzi przesłanie danych od nadawcy do odbiorcy. Czyli jeśli FC produkuje dane szybciej niż moduł RF jest w stanie poprawnie wysłać to dochodzi do "korka" aż nikt nie może się ruszyć (tj. zerwanie połączenia).

Jeśli dobrze to interpretuję, to przed zakupem modułów nie mogłem wiedzieć że parametry transmisji są za słabe, bo nie wiedziałem ile tych pakietów jest produkowanych.

Dobrze to rozumiem?

[breweryhills]

kurna muszę to zrozumieć a z materiałów w necie średnio mi to idzie.
Rozumiem to na chwilę obecną w ten sposób:
1. FC (czy Arduino) otwiera port do komunikacji "z prędkością" np. 9600bps.
2. Aby odbiorca rozumiał co jest mu wysyłane też musi komunikować się "z prędkością" 9600.
Inaczej będzie czytał śmieci tzn. przy ustawieniu 19600 będzie 2 razy za często sięgał po transmitowane dane.

Dokładnie tak.

Teraz do tego dochodzi przesłanie danych od nadawcy do odbiorcy. Czyli jeśli FC produkuje dane szybciej niż moduł RF jest w stanie poprawnie wysłać to dochodzi do "korka" aż nikt nie może się ruszyć (tj. zerwanie połączenia).

Tak jak piszesz. Moduł RF może od strony komputera lub koptera obsługiwać większą szybkość transmisji niż ta, z jaką komunikuje się z drugim modułem RF. Czyli to tak jakby oferował więcej niż może. Po co to ? Ano często jest tak, że potrzebujemy z dużą prędkością wysyłać małe ilości danych, pomiędzy nadawaniem których są relatywnie duże przerwy. Na przykład mam otwarty port na prędkości 57600 którym przesyłam paczki po 20 bajtów każda, z przerwą jednej dziesiątej sekundy. Teraz troszkę matematyki. Przyjmijmy że na wysłanie jednego bajtu potrzebujemy 10 bitów. Tak więc mnożymy - 10 bitów, razy 20 bajtów, razy 10 paczek w sekundę - wychodzi 2000 bitów na sekundę. Podczas gdy my mamy 57600. Widać jasno że przy takiej transmisji nie wykorzystujemy możliwości łącza, bo teoretycznie wystarczyłoby łącze o prędkości 2400 bit/s.

To dlatego w tanich modułach radiowych często stosuje się taki zabieg, że prędkość portu szeregowego może być wyższa od rzeczywistej prędkości z jaką nadawane są dane po radiu. Natomiast wybierając moduł do konkretnego zastosowania zawsze należy wziąć pod uwagę dwie rzeczy - efektywną prędkość łącza radiowego oraz rozmiar bufora.

Dlaczego ten rozmiar bufora jest ważny ? Ano weźmy przykład powyższy, ale zmodyfikujmy go nieco. Zamiast wysyłać dziesięć paczek równo co jedną dziesiątą sekundy, wyślijmy jednorazowo całe 200 bajtów na sekundę. Nadal średnia przepustowość to jedyne 2000 bitów. Tyle że jeżeli wielkość bufora w module RF to na przykład 64 bajty, to po zapełnieniu tego bufora reszta danych zostanie utracona i w efekcie w eter pójdzie tylko część danych.

[breweryhills]

Jako przykład podam jeszcze moduł Radiotronixa który używany jest w MK. Prędkość portu UART w tym module to 115kbit/s, ale przepływność po radiu to ~76kbit/s (w trybie szerokopasmowym), czyli prawie dwa razy mniej. Poza tym trzeba też uwzględnić że przepływność po radiu zakłada brak zakłóceń i innych przeszkód, które mogą drastycznie obniżyć rzeczywistą prędkość transferu.

[Rufio]

Dzięki Sebastian za wyjaśnienie.

Zrobię jeszcze test dla MWii - zobaczymy ile ten przesyła danych na sekundę i zobaczę co z tym APC220 zrobić, może komuś innemu się przydadzą bardziej.
Kurna a taki przyzwoity zasięg podobno mają (1km).

[Rufio]

Jakoś do dalszych testów zapał mi przysiadł, ale w międzyczasie znalazło mi się takie "cuś"
SI4432.
Wygląda jakby więcej to mogło, ale chyba trzeba do tego trochę klocków podokładać?
Panowie co myślicie?

[qczek]

Witam Panowie,
Używam modułu APC220 do własnego projektu (przesyłanie komunikatów Mavlink'a) i największy problem tego produktu jest to, że on przy stałym transferze w jedną stronę "przytyka" się z odbiorem. Mam go ustawionego na 19200 air, 9600 uart i jak zapodaje mu wysyłanie komunikatu około 30 bytów z f=10Hz to nie jest w stanie nic odebrać....
Przy 5Hz jest lepiej, ale też nie idealnie..

Zresztą w specyfikacji jest napisane że jest to semi-duplex cokolwiek to dokładnie znaczy :). On chyba dopiero jak nie ma co wysyłać, to przełącza się na odbiór a to chwile trwa.......

Jeśli miało by to być użyteczne to należało by zrobić jakąś warstwę transportową....

Szukam teraz czegoś lepszego w dobrej cenie :)
Pozdrawiam
Krzysiek

[Rufio]

No i w końcu się przemogłem i podpiąłem APC220 do MWii.
Musiałem wprowadzić zmianę w sofcie MWii polegającą na obniżenie parametru SERIAL_COM_SPEED do 57600.

Działa bez problemu

Czyli podsumowując:
- dla MK za wolne (nie jest w stanie przepchać danych - zatyka)
- dla MWii działa bez problemu (z alternatywnym GUI MultiWiiWinGUI, w którym można zmienić parametr dla COMa).

Zasięgu jeszcze nie badałem ale to i tak rewelka w stosunku do podpinania kabla do FC.