Konwerter Radio -> eLeReS serial.
Moderatorzy: marbalon, moderatorzy2014, moderatorzy
Re: Konwerter Radio -> eLeReS serial.
A możesz jeszcze podpiąć analizator pomiędzy konwerter i odbiornik ? Dwa kanały, jeden do s.bus drugi do s.port. I zaobserwować korelację czasową ramek. Ramka s.port wysyłana jest w kilkadziesiąt - kilkaset mikrosekund po zakończeniu odbioru paczki s.bus. I tylko wtedy. Zobacz kiedy pojawiają sie pollingi.
Nie wiem jak odbiornik frsky śle s.bus... Co 9 czy co 18ms. Bo jak co 9ms to telemetria powinna wychodzić z konwertera co drugą ramkę s.bus, a przy 18ms po każdej ramce s.bus.
Tak patrze na te wyniki i wygląda to jakbym za dużo danych próbował wypchnąć, i część jest odrzucana. Prawie zawsze przechodzi 10-11 sensorów. Może pchanie tego co ramkę to za dużo ? Może trzeba co drugą ramkę s.bus wypychać telemetrię ? Spróbuję jutro zrobić jeszcze jedną testówkę która będzie wysyłać s.porta dwa razy rzadziej.
Nie wiem jak odbiornik frsky śle s.bus... Co 9 czy co 18ms. Bo jak co 9ms to telemetria powinna wychodzić z konwertera co drugą ramkę s.bus, a przy 18ms po każdej ramce s.bus.
Tak patrze na te wyniki i wygląda to jakbym za dużo danych próbował wypchnąć, i część jest odrzucana. Prawie zawsze przechodzi 10-11 sensorów. Może pchanie tego co ramkę to za dużo ? Może trzeba co drugą ramkę s.bus wypychać telemetrię ? Spróbuję jutro zrobić jeszcze jedną testówkę która będzie wysyłać s.porta dwa razy rzadziej.
Pzdr. -----MIŚ-----
Re: Konwerter Radio -> eLeReS serial.
Jasne. Zrobie 3 kanaly, s.bus, s.port na wejsciu i s.port na wyjsciu. Bedziemy mieli pelen obraz.miś pisze:A możesz jeszcze podpiąć analizator pomiędzy konwerter i odbiornik ? Dwa kanały, jeden do s.bus drugi do s.port. I zaobserwować korelację czasową ramek.
Re: Konwerter Radio -> eLeReS serial.
Ok, na PW wrzuciłem Ci jeszcze drugą wersję testową, która wysyła telemetrię 2x wolniej. Zobacz czy dalej będzie przechodzić za każdym razem 10-11 komunikatów czy wszystkie. Sorry że Cie tak męczę, ale lubię jak coś działa najlepiej jak się da, a nie "jakoś tam"...
Pzdr. -----MIŚ-----
Re: Konwerter Radio -> eLeReS serial.
Nie ma problemu, zrobie porownanie i dam znac.miś pisze:Sorry że Cie tak męczę, ale lubię jak coś działa najlepiej jak się da, a nie "jakoś tam"...
Re: Konwerter Radio -> eLeReS serial.
Miś, a czy w sofcie eleresa TX (sbus i sport) też możesz usunąć rssi albo przenieść tak żeby to się nie gryzło ?
Optic 6 (expander 12ch), eleres mod, OSD Remzibi, Fox 800, AP eleres V2, sony 600, gopro 4 sliver, pixhawk
Re: Konwerter Radio -> eLeReS serial.
Wyniki testow na szybko na obrazkach (kanaly opisane na obrazkach, gdyby byly watpliwosci - daj znac)
Stary soft (ramka S.Port co dwie ramki S.Bus) Nowy soft testowy (ramka S.Port co 4 ramki S.Bus) Wprawdzie w nowym sofcie wychodzi na to ze przechodzi wiekszosc ramek (musze to jeszcze dokladnie sprawdzic - EDIT: sprawdzilem, przechodza wszystkie, z wyjatkiem przerw spowodowanych problemami opisanymi ponizej - https://pastebin.com/fwrzUnYs), to duzo czesciej wystepuje komunikat "Sensor lost". Mysle ze wynika to z tego ze potrzeba 800ms na pelny obrot petli po wszystkich sensorach. Jesli jedna ramka sie zgubi wtedy jest juz ponad sekunda, a Taranis jak nie widzi tak dlugo sensora to go uznaje za zgubionego. Nie pamietam jaki jest timeout, musze sprawdzic w zrodlach OpenTX.
EDIT: Sprawdzilem, timeout jest znacznie wiekszy niz sekunda, wiec problem nie w tym. Ale mam inna teorie. W protokole S.Port ramki wysylane sa co 12ms. Z tego 4ms to maks czas na wyslanie pollingu i przelaczenie sie na odbior. Kolejne maks 4ms to odbior i potem 4ms ciszy przed nastepna ramka. Przyjrzalem sie danym i wychodzi mi na to ze zanik sensorow nastepuje wtedy, gdy wysylanie ramki przez konwerter wpadnie w okres ciszy powyzej 8ms. Tak sie pechowo sklada ze odstep miedzy 4 ramkami S.Bus to 36 milisekund czyli wielokrotnosc 12ms. Jak trafimy z wysylaniem w okolice okresu ciszy to jest duza szansa ze kompletnie utracimy dane. Pozostalbym zatem przy wysylaniu co 2 ramki S.Bus (albo moze nawet co trzy zeby bylo nieparzyscie). Wtedy owszem, czasem bedziemy nakladac sie na polling i tracic dane, ale bedzie to sytuacja przejsciowa.
Jesli chodzi o przerwy, to gdy wystepuja zamiera komunikacja adapter-eLeReS (dioda na eLeReSie zapala sie na chwile na czerwono). Ponizej obrazek na ktorym widac kilka dziur (podobnie jest na obu wersjach testowych)
Stary soft (ramka S.Port co dwie ramki S.Bus) Nowy soft testowy (ramka S.Port co 4 ramki S.Bus) Wprawdzie w nowym sofcie wychodzi na to ze przechodzi wiekszosc ramek (musze to jeszcze dokladnie sprawdzic - EDIT: sprawdzilem, przechodza wszystkie, z wyjatkiem przerw spowodowanych problemami opisanymi ponizej - https://pastebin.com/fwrzUnYs), to duzo czesciej wystepuje komunikat "Sensor lost". Mysle ze wynika to z tego ze potrzeba 800ms na pelny obrot petli po wszystkich sensorach. Jesli jedna ramka sie zgubi wtedy jest juz ponad sekunda, a Taranis jak nie widzi tak dlugo sensora to go uznaje za zgubionego. Nie pamietam jaki jest timeout, musze sprawdzic w zrodlach OpenTX.
EDIT: Sprawdzilem, timeout jest znacznie wiekszy niz sekunda, wiec problem nie w tym. Ale mam inna teorie. W protokole S.Port ramki wysylane sa co 12ms. Z tego 4ms to maks czas na wyslanie pollingu i przelaczenie sie na odbior. Kolejne maks 4ms to odbior i potem 4ms ciszy przed nastepna ramka. Przyjrzalem sie danym i wychodzi mi na to ze zanik sensorow nastepuje wtedy, gdy wysylanie ramki przez konwerter wpadnie w okres ciszy powyzej 8ms. Tak sie pechowo sklada ze odstep miedzy 4 ramkami S.Bus to 36 milisekund czyli wielokrotnosc 12ms. Jak trafimy z wysylaniem w okolice okresu ciszy to jest duza szansa ze kompletnie utracimy dane. Pozostalbym zatem przy wysylaniu co 2 ramki S.Bus (albo moze nawet co trzy zeby bylo nieparzyscie). Wtedy owszem, czasem bedziemy nakladac sie na polling i tracic dane, ale bedzie to sytuacja przejsciowa.
Jesli chodzi o przerwy, to gdy wystepuja zamiera komunikacja adapter-eLeReS (dioda na eLeReSie zapala sie na chwile na czerwono). Ponizej obrazek na ktorym widac kilka dziur (podobnie jest na obu wersjach testowych)
Re: Konwerter Radio -> eLeReS serial.
Jeśli możesz to zrobić w nowej wersji to będzie super, wreszcie można będzie zapisywać logi w taranisie, aktualnie zrezygnowałem z tego bo trochę irytujące jest ciągle słuchanie informacji o zaniku telemetriimiś pisze:Mogę.
Optic 6 (expander 12ch), eleres mod, OSD Remzibi, Fox 800, AP eleres V2, sony 600, gopro 4 sliver, pixhawk
Re: Konwerter Radio -> eLeReS serial.
Dzięki pomocy PawelSky udało się doprowadzić telemetrię S.PORT do prawie ideału. Dzięki Paweł !
Do pobrania jest Soft Konwertera eLeReS v 2.06
Wybór rodzaju telemetrii:
-Telemetria FrSky-D : D3 niepodłączone, lub S.PORT : D3 do masy
-Telemetria S.PORT poprzez odbiornik FrSky : D4 niepodłączone, lub prosto do aparatury : D4 do masy
Nie daję jeszcze na pierwszą stronę bo wymaga weryfikacji czy jednostki są prawidłowe (głównie prędkość - powinna być w km/h).
EDIT.
Przepraszam, wysłałem zły plik. Proszę o ponowne pobranie wersji 2.06 . Plik hex powinien być z datą 31.07
Dodatkowo informacja że bez podłączonego GPS'a do RX, nie ma w telemetrii S.PORT informacji o czujnikach należących do GPS. Jest tylko ilość SAT, ale nie leci HDOP, pozycja, prędkość, wysokość, kurs. Tak samo jak nie ma czujnika ciśnienia to nie leci wysokość z baro i vario.
Do pobrania jest Soft Konwertera eLeReS v 2.06
Wybór rodzaju telemetrii:
-Telemetria FrSky-D : D3 niepodłączone, lub S.PORT : D3 do masy
-Telemetria S.PORT poprzez odbiornik FrSky : D4 niepodłączone, lub prosto do aparatury : D4 do masy
Nie daję jeszcze na pierwszą stronę bo wymaga weryfikacji czy jednostki są prawidłowe (głównie prędkość - powinna być w km/h).
EDIT.
Przepraszam, wysłałem zły plik. Proszę o ponowne pobranie wersji 2.06 . Plik hex powinien być z datą 31.07
Dodatkowo informacja że bez podłączonego GPS'a do RX, nie ma w telemetrii S.PORT informacji o czujnikach należących do GPS. Jest tylko ilość SAT, ale nie leci HDOP, pozycja, prędkość, wysokość, kurs. Tak samo jak nie ma czujnika ciśnienia to nie leci wysokość z baro i vario.
Pzdr. -----MIŚ-----
Re: Konwerter Radio -> eLeReS serial.
Jak juz mamy tak ladnie dzialajacy S.Port w konwerterze, to moze by sie pokusic o implementacje F.Porta? Rozwiazalby sie problem synchronizacji, a dane i telemetria bieglyby sobie jednym kabelkiem :)
Re: Konwerter Radio -> eLeReS serial.
Warto ? Na razie chyba nie jest to zbyt popularne... Jakie odbiorniki to obsługują ? Jakaś dokumentacja ?
Pzdr. -----MIŚ-----
Re: Konwerter Radio -> eLeReS serial.
Jeżeli chodzi o odbiorniki to jest lista obsługiwanych:
FrSky RXSR, X4R, X4R-SB, XSR, XSR-M, R9M Slim, R9M Slim+, R9Mmini
osobiście sprawdziłem działanie F.Port z odbiornikami R9Mini i XSR i wszystko działa.
Co do dokumentacji to można znaleźć opis protokołu tutaj protokół F.Port
FrSky RXSR, X4R, X4R-SB, XSR, XSR-M, R9M Slim, R9M Slim+, R9Mmini
osobiście sprawdziłem działanie F.Port z odbiornikami R9Mini i XSR i wszystko działa.
Co do dokumentacji to można znaleźć opis protokołu tutaj protokół F.Port
Pozdrawiam Krzysiek
---------------------------------------------------------------
QAV-250, Martian II, GEPRC-AX215, QAV-R 220, ARMATTAN CHAMELEON, T-Rex 500
Zapraszam na bloga
---------------------------------------------------------------
QAV-250, Martian II, GEPRC-AX215, QAV-R 220, ARMATTAN CHAMELEON, T-Rex 500
Zapraszam na bloga
Re: Konwerter Radio -> eLeReS serial.
Warto o tyle ze potrzebne Ci sa wtedy tylko tylko 2 seriale a nie trzymiś pisze:Warto ?
No i masz pelna synchronizacje telemetrii, nie trzeba zadnych trickow stosowac.
W miedzyczasie zrobilem diagram pinoutu (v2.06)
Ostatnio zmieniony poniedziałek 06 sie 2018, 00:08 przez pawelsky, łącznie zmieniany 2 razy.
Re: Konwerter Radio -> eLeReS serial.
Jedynym argumentem jest synchronizacja. Co do uartów to i tak softuarty pisane są na piechotę, część w assemblerze, bo inaczej nie dało by się tego wszystkiego połączonego razem opanować.
Pzdr. -----MIŚ-----
Re: Konwerter Radio -> eLeReS serial.
I jeszcze jedna sugestia - moze by przeniesc konfiguracje S.Porta z D3/D4 na nieuzywane piny (D12? A0? A1?) zeby nie zajmowac BIN10 i BIN11?miś pisze:Jedynym argumentem jest synchronizacja. Co do uartów to i tak softuarty pisane są na piechotę, część w assemblerze, bo inaczej nie dało by się tego wszystkiego połączonego razem opanować.