Konwerter Radio -> eLeReS serial.

[miś]

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.

[pawelsky]

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.

Jasne. Zrobie 3 kanaly, s.bus, s.port na wejsciu i s.port na wyjsciu. Bedziemy mieli pelen obraz.

[miś]

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"...

[pawelsky]

Sorry że Cie tak męczę, ale lubię jak coś działa najlepiej jak się da, a nie "jakoś tam"...

Nie ma problemu, zrobie porownanie i dam znac.

[arek2081]

Miś, a czy w sofcie eleresa TX (sbus i sport) też możesz usunąć rssi albo przenieść tak żeby to się nie gryzło ?

[miś]

Mogę.

[pawelsky]

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)

test_old_timing.png (124.6 KiB) Przejrzano 8334 razy

Nowy soft testowy (ramka S.Port co 4 ramki S.Bus)

test_new_timing.png (113.52 KiB) Przejrzano 8334 razy

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)

test_old_gaps.png (111.64 KiB) Przejrzano 8334 razy

[arek2081]

Mogę.

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 telemetrii

[miś]

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.

[pawelsky]

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 :)

[miś]

Warto ? Na razie chyba nie jest to zbyt popularne... Jakie odbiorniki to obsługują ? Jakaś dokumentacja ?

[Docent]

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

[pawelsky]

Warto ?

Warto o tyle ze potrzebne Ci sa wtedy tylko tylko 2 seriale a nie trzy
No i masz pelna synchronizacje telemetrii, nie trzeba zadnych trickow stosowac.

W miedzyczasie zrobilem diagram pinoutu (v2.06)

Pinout dla wersji firmware v2.06

eleres_adapter_pinout_v206.png (616.74 KiB) Przejrzano 8117 razy

[miś]

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ć.

[pawelsky]

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ć.

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?