Vysvetlení SBUS, S.Port, F.Port

SBUS, S.port, F.Port
Uživatelský avatar
Jan Urbánek
Administrátor fóra
Příspěvky: 830
Registrován: ned 21. dub 2019 17:30:13

Vysvetlení SBUS, S.Port, F.Port

Příspěvek od Jan Urbánek »

SBUS
jedna se o protokol pro seriovy prenos kanalu. Rozsah kanalu je 16.
Kazde zarizeni ktere umi SBUS ma svoje vlastni ID tedy identifikator na jaky kanal posloucha. Tzn pokud nastavime treba servo ktere umi SBUS na ID 3 bude poslouchat co pro nej prijde pod kanalem 3. Takto mohou byt zpojeny serva paralelne a kazde si vezme to co pro nej v dane komunikaci prichazi.
SBUS se bezne rozvadi 3 pinovym kabelem, signal, napajeni a zem. Pri pouziti silnejsich serv hrozi moznost pretizeni rozvodu, je tedy dobre napajeni posilovat. Pro prenos dat staci pouze signal a zem.
SBUS take obsahuje informace (flags) ktere rikaji jestli byl dany ramec dat ziskan ze zdravych a v poradku prijatych dat nebo z poskozenych. Podle toho muzou nektere zarizeni jako ridici jednotky dronu tyto ramce ignortovat aby nedoslo k prijeti vadnych dat.
SBUS pouziva nekolik firem Futaba, FrSky, Corona i kdyz je snaha udrzet protokol mezi sebou kompatibilni jsou tam drobe odlisnosti ale nikoli pro chod ale pro programovani serv atp.

S.Port
Tento protokol vyvinulo FrSky a jedna se o telemetricky protokol. Byl uveden v roce 2013 a nekolikrat aktualizovan jak se pridaval pocet senzoru atp.
Protokol se pouziva pro pripojeni senzoru aby odesilali zpet do prijimace namerene hodnoty. Tento protokol je seriovy a kazde zarizeni ma svoje vlastni ID pod kterym zasila informace. OpenTX nebo jiny system dane informace dekoduje a ukaze nam jako vysku, napeti atp. Rychlost posilani dat je od 100ms po 1s a lze u nekterych cidel tuto ruychlost zmenit pomoci aplikace FreeLink. Je vsak vhodne strizlive rozhodnout ktera data potrebujete rychle s obnovou 100ms a ktera nejsou tak dulezita aby nedoslo k prehlceni.
Tento protokol je obousmerny, lze tak pomoci nej i pripojene zarizeni nastavovat. Toto zname z nastavovani stabilizaci SxR a SRx, popripade umime nastavovat videovysilace (vykon, frekvenci), napeti BEC v Neuronu atp. K tomuto ucelu lze pouzit budto FreeLink nebo LUA skripty v radiu.


F.Port
Tento protokol by vyvinut ve verzi 1 ve spolupraci FrSky a tymem BetaFlight. Jedna se o slouceni protokolu SBUS a S.Port a vsech jejich vlastnosti. Hojne je nyni vyuzivan pro pripojeni prijimacu k ridicim deskam dronu protoze pomoci jednoho signalniho dratu a zeme dron jak ridite tak z nej dostavate telemtricka data a jeste jej muzete i nastavovat.
F.Port 2.0 je prepracovana verze a dovoluje i aktualizaci FW. Tento novy protokol nyni podporuji i nova serva Xact ktera lze pres tento protkol nastavovat.
Vsechny prijimace Archer a TD budou podporovat tento protokol.

Uživatelský avatar
ellet
Příspěvky: 351
Registrován: úte 14. kvě 2019 17:37:26
Bydliště: Vysočina

Re: Vysvetlení SBUS, S.Port, F.Port

Příspěvek od ellet »

Hezky napsáno. Podle tohoto odkazu je už ale S.Bus od FrSky zase chudší. :(, alespoň v ACCST V2.

Uživatelský avatar
Jan Urbánek
Administrátor fóra
Příspěvky: 830
Registrován: ned 21. dub 2019 17:30:13

Re: Vysvetlení SBUS, S.Port, F.Port

Příspěvek od Jan Urbánek »

Chudsi? jen se filtruje jeden flag pro to aby FC neblbly.

Uživatelský avatar
ellet
Příspěvky: 351
Registrován: úte 14. kvě 2019 17:37:26
Bydliště: Vysočina

Re: Vysvetlení SBUS, S.Port, F.Port

Příspěvek od ellet »

Pod pokličku nevidím, nenapadá mě ale žádný důvod k "filtrování " FL bitu. Buď byl paket sestaven z korektně přijatých dat, nebo nebyl. Nemůžu teď funkci tohoto bitu ověřit a budu rád za každou bližší informaci.
Tuším, že prostě "filtruje" krátkodobé výpadky. To je ale zkreslení významu bitu, mělo by to být ošetřeno, pokud je to třeba, na straně zařízení, které bit využívá. Nebo je to jinak?

Edit: Tak jsem orientačně ověřil, že FL nějak funguje. Práh posunutí chybové hodnoty ale neodhadnu (možná, až se budu nudit, pomocí dalších čidel,
pokud tomu tak je i u ACCESS, možná, alespoň orientačně, provnáním hodnoty VFR a senzoru Tanango).

Uživatelský avatar
Jan Urbánek
Administrátor fóra
Příspěvky: 830
Registrován: ned 21. dub 2019 17:30:13

Re: Vysvetlení SBUS, S.Port, F.Port

Příspěvek od Jan Urbánek »

Jestli si vzpominam dobre tak to bylo tak ze pokud byl nastaven rezim 8k tzn 1 frame tak se nefiltrovalo, pokud byl nastaven rezim 16k tzn 2framy tak se filtrovalo tak ze se pri jednom vypadku vzal predesly frame a ten 2 frame se oznacil jako za OK s tim ze toto se mohlo opakovat jen 3x.
Tzn u 16k prenosu se rekonstruovalo jen 3x 18ms a pak uz se to zahlasilo jako vadny. Kdyz se totiz do FC posilalo 16k tzn 2x frame a i kdyz u dronu se ridi max 6k a doslo k poruseni framu 9-16 byl cely 2frame oznacen za vadny, FC deska byla v slabsim signalu prehlcena vadnymi flags.
Z globalniho pohledu mam za 1s priblizne 100 frame po 9ms (1-8k) a nebo vice jak 50 2framu pro 1-16k tak 3 vypadle framy z 50 zaznamena jen FC nikoli uzivatel krom toho framy za sebou je neco jineho nez spatne framy postupne.
Je to bezdratovy prenos 100% linka je jen otazka rekneme 50m pak uz se objevuji ztracene pakety a je to bezne.
Hledani kazdeho vadneho framu u bezdratoveho prenosu je tak spise Obsedantně-kompulzivní porucha, bez urazky :lol:

Uživatelský avatar
ellet
Příspěvky: 351
Registrován: úte 14. kvě 2019 17:37:26
Bydliště: Vysočina

Re: Vysvetlení SBUS, S.Port, F.Port

Příspěvek od ellet »

Tohle vysvětlení se mně líbí. Nějaký tu a tam ztracený paket je samozřejmě bezvýznamný. Po pravdě jsem něco takovýho tušil, ale nevěděl, to potom člověka napadnou i jiné důvody. Díky za reakci. :D
(V každém případě z toho vyplývá, že Tanango bude ukazovat nesmysly, protože záleží na uspořádání vadných paketů a nemá smysl údaj s čímkoli porovnávat)

Uživatelský avatar
Jan Urbánek
Administrátor fóra
Příspěvky: 830
Registrován: ned 21. dub 2019 17:30:13

Re: Vysvetlení SBUS, S.Port, F.Port

Příspěvek od Jan Urbánek »

Kuprikladu v ACCESS je VFR coz je analyza prijatych paketu a ukazuje % kvality z poslednich 100 paketu, to same je u toho ACCST jen nevim presne pomer ale bylo to podobne ze se nezmi opakovat do 100 paketu 3x

Odpovědět

Zpět na „Ostatní“