zamiennik dla XBee
Moderatorzy: moderatorzy2014, moderatorzy
-
- Posty: 746
- Rejestracja: czwartek 01 wrz 2011, 10:44
- Lokalizacja: Gdańsk
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.Rufio pisze:A może to problem tego adaptera do PC opartymi o CP2102 co to Sebastian wskazuje jako awaryjne?!
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.
Pozdrawiam, Sebastian
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 pisze:a czy w windowsie odpowiedni port com skonfigurowałeś na 57600/8/N/1/Xoff ? Powinno banglać w/g opisu kolegi z RCG...
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?
Z twojego linku:
Khmmm - właśnie - tu jest mowa o xxxiduino a nie o mikrokopterze....może jednak jest ból z nim...
a że przez rurkę o mniejszym fi jest ciężko...rurek Ci to mówi6.- 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.
Khmmm - właśnie - tu jest mowa o xxxiduino a nie o mikrokopterze....może jednak jest ból z nim...
infekcja FPV postępuje w zastraszającym tempie...
upsik Rurek o rurce - tak jak Ci mówiłem, mam do tego talent , sorki.Rurek pisze:Z twojego linku:a że przez rurkę o mniejszym fi jest ciężko...rurek Ci to mówi6.- 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.
Khmmm - właśnie - tu jest mowa o xxxiduino a nie o mikrokopterze....może jednak jest ból z nim...
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.
-
- Posty: 746
- Rejestracja: czwartek 01 wrz 2011, 10:44
- Lokalizacja: Gdańsk
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 pisze:Jakoś intuicyjnie czuję, że oba parametry powinny być równe. Bo jak to:
57600 ma być przepchane rurką o średnicy 19200?
Pozdrawiam, Sebastian
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ą?
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ą?
-
- Posty: 746
- Rejestracja: czwartek 01 wrz 2011, 10:44
- Lokalizacja: Gdańsk
No właśnie to jest ten sam przypadek co z wiadremRufio pisze:Wszystko pięknie z tym zlewem i kranem ale nie w przypadku, gdy kran leje wodę szybciej zlew jest w stanie się opróżnić.
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.Rufio pisze: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ą?
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.
Pozdrawiam, Sebastian
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?
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?
-
- Posty: 746
- Rejestracja: czwartek 01 wrz 2011, 10:44
- Lokalizacja: Gdańsk
Dokładnie tak.Rufio pisze: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.
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.Rufio pisze: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).
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.
Pozdrawiam, Sebastian
-
- Posty: 746
- Rejestracja: czwartek 01 wrz 2011, 10:44
- Lokalizacja: Gdańsk
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.
Pozdrawiam, Sebastian
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
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
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.
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.