SBUS

SBUS przenosi wiele kanałów sterowania RC jednym szeregowym przewodem sygnałowym. Zastępuje wiązkę osobnych impulsów PWM ramką zawierającą wartości kanałów oraz dwa jawne sygnały jakości: utratę pojedynczej ramki i aktywację failsafe odbiornika. W UAV jest najczęściej interfejsem między odbiornikiem radiowym a flight controllerem, ale rodzina S.BUS obejmuje także magistralę sterującą adresowanymi serwami i dekodery zamieniające kanały na klasyczne wyjścia.

Prostota warstwy danych nie oznacza dowolności elektrycznej. Klasyczny SBUS używa odwróconej logiki szeregowej, nietypowej dla popularnego terminala konfiguracji 100000 bit/s, 8E2. Flight controller potrzebuje wejścia z inwerterem, UART-u z programową inwersją albo zewnętrznego układu odwracającego. Podłączenie przewodu do przypadkowego RX i wybranie 115200 8N1 nie może zadziałać niezależnie od poprawności parsera.

Spis treści#

• Miejsce SBUS w torze RC
• S.BUS, SBUS i S.BUS2
• Warstwa fizyczna
• UART 100000 8E2
• Inwersja
• Ramka 25-bajtowa
• Pakowanie 16 kanałów
• Kanały 17 i 18
• Flaga frame lost
• Flaga failsafe
• Zakresy i skalowanie
• Parser strumieniowy
• Resynchronizacja
• Timeout i świeżość danych
• Mapowanie kanałów
• Wejście odbiornika i wyjście do serw
• Fast SBUS
• Porównanie z PWM i CRSF
• Integralność elektryczna
• Implementacja parsera
• Diagnostyka
• Plan testów
• Typowe błędy
• Kryteria odbioru
• Powiązane tematy
• Przypisy

Miejsce SBUS w torze RC#

SBUS nie jest radiowym interfejsem over-the-air. Radio może używać FASST, FASSTest, ACCST, ACCESS, ELRS albo innego łącza, a odbiornik dopiero na wyjściu tworzy SBUS. Te dwie warstwy mają osobne tempo, mechanizmy integralności i zachowanie po utracie pakietu.

drążki / przełączniki
        ↓
nadajnik RC ── łącze radiowe ── odbiornik
                                  ↓ SBUS
                           flight controller
                                  ↓
                      mixer / regulatory / failsafe
                                  ↓
                      PWM, DShot, CAN lub SBUS out

Wartość kanału odebrana w poprawnej ramce nie dowodzi, że powstała z nowego pakietu radiowego. Odbiornik może przez pewien czas powtarzać ostatnie pozycje i ustawiać flagę utraty ramki, a dopiero później aktywować swój failsafe. Flight controller musi interpretować flagi oraz własny czas od ostatniej poprawnej ramki, zamiast patrzeć wyłącznie na liczby kanałów.

Jeden szeregowy przewód upraszcza wiązkę i pozwala przenieść 16 kanałów przez jedno wejście. Jednocześnie tworzy wspólny punkt awarii: przerwanie przewodu, zła inwersja albo zajęty UART odbierają wszystkie kanały naraz. Wymagania bezpieczeństwa muszą obejmować tę zależność.

S.BUS, SBUS i S.BUS2#

Futaba zapisuje nazwę systemu jako S.BUS. W kodzie i konfiguracji flight controllerów zwykle występuje SBUS. S.BUS2 rozszerza ekosystem o urządzenia i telemetrię, ale nie należy zakładać pełnej elektrycznej ani funkcjonalnej zamienności każdego portu S.BUS i S.BUS2.

Instrukcje producenta rozróżniają porty oraz dopuszczalne urządzenia. Przykładowy dekoder Futaba SBD-3 zamienia S.BUS/S.BUS2 na trzy klasyczne kanały dla serw lub ESC, przy czym instrukcja określa sposób zasilania i ograniczenia połączeń. To pokazuje, że nazwa magistrali nie zastępuje instrukcji konkretnego odbiornika, serwa lub koncentratora.

W tym artykule „ramka SBUS” oznacza powszechnie implementowany 25-bajtowy strumień kanałów RC. Nie opisujemy tu pełnego protokołu urządzeń/telemetrii S.BUS2. Parser wejścia RC nie powinien samowolnie interpretować innych ramek na podstawie podobieństwa elektrycznego.

Warstwa fizyczna#

Typowa wiązka odbiornika zawiera zasilanie, masę i sygnał. Poziomy napięcia oraz dopuszczalne zasilanie trzeba odczytać z dokumentacji sprzętu. Określenie „SBUS” definiuje logikę interfejsu, ale nie gwarantuje, że dowolny pin jest odporny na 5 V albo że port autopilota zasila odbiornik.

Połączenie powinno określać:

• źródło napięcia odbiornika i jego budżet prądowy;
• wspólną referencję masy;
• pin SBUS OUT odbiornika i SBUS/RC IN flight controllera;
• obecność i kierunek inwertera;
• tolerancję poziomu wejścia FC;
• stan linii, gdy jedna strona jest wyłączona;
• prowadzenie przewodu względem ESC, faz silników i przetwornic.

Dedykowany pin SBUS IN często ma sprzętowy inwerter. Nie jest wtedy równoważny zwykłemu pinowi UART RX. Z kolei niektóre MCU F7/H7 potrafią odwracać polaryzację w UART, podczas gdy wiele płyt z F4 wymaga zewnętrznego inwertera lub dedykowanego wejścia. Liczy się schemat konkretnej płyty, nie tylko rodzina procesora.

UART 100000 8E2#

Klasyczny SBUS korzysta z parametrów:

8E2 oznacza osiem bitów danych, bit parzystości parzystej i dwa bity stopu. To 12 bitów czasu na przesłany bajt po uwzględnieniu bitu startu. Sama 25-bajtowa ramka zajmuje więc co najmniej:

t_wire = 25 · 12 / 100000 = 3 ms

Do tego dochodzi przerwa między ramkami. Prędkość 100 kbit/s i rozmiar ramki wyznaczają fizyczne minimum latency transportu. Gdy odbiornik wysyła ramki mniej więcej co 9–20 ms zależnie od trybu, opóźnienie całego toru obejmuje również radio, oczekiwanie na początek ramki, odbiór 25 bajtów i harmonogram FC.

UART musi rzeczywiście obsługiwać 100000 oraz parzystość. Błąd zegara nadajnika i odbiornika sumuje się. Pomiar analizatorem powinien sprawdzić szerokość bitu około 10 µs i stabilność zegara w temperaturze.

Inwersja#

W zwykłym UART linia spoczynkowa jest zazwyczaj wysoka, bit startu niski. Klasyczny SBUS odwraca tę logikę. Analizator skonfigurowany bez inwersji zobaczy pozornie błędne bajty, parzystość lub brak ramek.

Są cztery typowe rozwiązania:

1. dedykowane wejście SBUS z inwerterem na PCB;
2. sprzętowa inwersja wejścia UART w MCU;
3. zewnętrzna bramka/tranzystor odwracający;
4. nieodwrócone wyjście odbiornika, jeśli producent je jawnie udostępnia.

Nie wolno stosować dwóch inwersji. Odbiornik z wybranym inverted SBUS podłączony do dedykowanego inwertującego padu może w efekcie dać zwykłą polaryzację w miejscu, gdzie firmware ponownie oczekuje inwersji. Diagnozę zaczyna się od przebiegu elektrycznego i schematu toru.

Prosty inwerter tranzystorowy musi zapewnić poprawne progi, czas narastania i bezpieczny stan po wyłączeniu. Przy 100 kbit/s margines czasowy jest duży względem szybkiej logiki CMOS, lecz za duży rezystor podciągający i pojemność przewodu mogą znacząco spowolnić zbocze.

Ramka 25-bajtowa#

Powszechny format ma:

byte 0      header 0x0F
bytes 1–22  16 kanałów × 11 bitów = 176 bitów
byte 23     flagi: CH17, CH18, frame lost, failsafe
byte 24     footer/end byte

176 bitów kanałów dokładnie wypełnia 22 bajty. Wartości nie są wyrównane do granic bajtów, więc zwykłe rzutowanie bufora na tablicę uint16_t jest błędne i może zależeć od endianowości oraz wyrównania CPU.

Nagłówek 0x0F pomaga znaleźć początek, ale taki bajt może wystąpić w payloadzie kanałów. Parser nie może przyjąć, że każde 0x0F rozpoczyna ramkę. Potrzebuje długości, oczekiwanego bajtu końcowego/akceptowanych wariantów, poprawnej konfiguracji UART i kontroli czasu.

W implementacjach spotyka się różne dozwolone wartości stopki związane z wariantami systemu. Zamiast wpisywać jeden magiczny bajt z przypadkowego bloga, należy korzystać z listy jawnie wspieranej przez firmware i testować ją na sprzęcie docelowym. Nieznana stopka powinna odrzucić ramkę i zwiększyć licznik diagnostyczny.

Pakowanie 16 kanałów#

Kanały są ułożone kolejno, po 11 bitów, od najmniej znaczących bitów strumienia payloadu. Uniwersalny dekoder może wyciągać bity niezależnie od granic bajtów:

bit_offset(channel) = 11 · channel
value = (payload_as_bitstream >> bit_offset) & 0x07FF

W C nie należy budować 176-bitowej liczby. Można dla każdego kanału pobrać trzy sąsiednie bajty do 32-bitowego akumulatora, przesunąć o offset wewnątrz pierwszego bajtu i zamaskować 11 bitów. Przed dostępem trzeba zapewnić, że indeks nie wyjdzie poza 22-bajtowy payload.

static uint16_t sbus_channel(const uint8_t payload[22], unsigned ch)
{
    const unsigned bit = ch * 11U;
    const unsigned byte = bit >> 3;
    const unsigned shift = bit & 7U;

    uint32_t word = payload[byte];
    if (byte + 1U < 22U) word |= (uint32_t)payload[byte + 1U] << 8;
    if (byte + 2U < 22U) word |= (uint32_t)payload[byte + 2U] << 16;
    return (uint16_t)((word >> shift) & 0x07FFU);
}

To przykład edukacyjny. Produkcyjny parser najpierw waliduje całą ramkę i używa testów ze znanymi wektorami dla wszystkich kanałów, zwłaszcza tych przecinających granicę bajtu. Alternatywą jest jawna sekwencja przesunięć używana w dojrzałych firmware.

Nie należy używać bitfieldów C jako formatu transmisji między kompilatorami. Kolejność i upakowanie pól bitowych są zależne od implementacji. memcpy do struktury z uint16_t ch:11 może działać w jednym toolchainie i być nieprzenośne.

Kanały 17 i 18#

Dwa najmłodsze bity bajtu flag mogą przenosić cyfrowe kanały 17 i 18. Są binarne, nie 11-bitowe. Nie każdy odbiornik i nie każda konfiguracja je udostępnia. Flight controller powinien opisać, czy mapuje je na pełny zakres logiczny, oraz nie zakładać ich obecności bez testu.

Kanał cyfrowy nie jest dobrym miejscem dla funkcji wymagającej rozróżnienia wielu pozycji. Dla przełącznika bezpieczeństwa także trzeba rozważyć stan po utracie ramek: sama ostatnia wartość bitu nie zastępuje flagi failsafe ani lokalnej logiki uzbrojenia.

Flaga frame lost#

Bit frame lost informuje, że odbiornik nie uzyskał oczekiwanej nowej ramki z łącza radiowego. Dokładna polityka ustawiania zależy od odbiornika. Jest to wczesny sygnał pogarszania jakości, niekoniecznie natychmiastowy nakaz zakończenia lotu.

Flight controller powinien:

• rejestrować liczbę i serie utraconych ramek;
• nie traktować payloadu oznaczonego frame lost jak świeżej, pewnej komendy;
• utrzymywać osobny licznik poprawnych ramek;
• oceniać gęstość błędów w oknie czasowym;
• przejść zgodnie z maszyną failsafe po przekroczeniu własnego progu/deadline.

Pojedynczy lost frame może zostać ukryty przez utrzymanie ostatniej komendy przez jedną ramkę, ale seria jest istotna. Decyzja zależy od dynamiki platformy. Multirotor o szybkiej reakcji i ciężki płatowiec mają inne budżety, jednak w obu przypadkach próg musi być jawny i przetestowany.

Flaga failsafe#

Bit failsafe oznacza, że odbiornik aktywował swoją politykę po utracie łącza. Może jednocześnie wysyłać zaprogramowane pozycje kanałów, ostatnie wartości albo wartości zależne od modelu. Flight controller powinien ufać fladze jako zdarzeniu, nie zgadywać stanu wyłącznie z pozycji drążków.

Warstwy failsafe są niezależne:

1. radio wykrywa brak pakietów;
2. odbiornik ustawia flagi i ewentualnie wartości kanałów;
3. parser FC wykrywa flagę, błąd ramki lub timeout;
4. system sterowania wybiera stan awaryjny właściwy dla lotu;
5. wyjścia wykonawcze mają własny watchdog świeżości.

Ustawienie odbiornika „no pulses” może spowodować całkowity zanik ramek zamiast flagi. Dlatego timeout jest obowiązkowy nawet przy obsłudze bitu failsafe. Z kolei utrzymywanie poprawnych elektrycznie ramek z ostatnimi pozycjami nie może blokować failsafe FC, jeśli flaga jest ustawiona.

Stan po odzyskaniu łącza też wymaga reguły. Automatyczny powrót do ręcznego sterowania może wywołać skok, jeśli drążki są w innej pozycji. Maszyna stanów może wymagać określonej sekwencji, stabilnej liczby poprawnych ramek lub potwierdzenia operatora.

Zakresy i skalowanie#

Surowa wartość ma 11 bitów, czyli teoretycznie 0–2047. Typowy użyteczny zakres spotykany w kompatybilnych implementacjach jest węższy, często około 172–1811 dla standardowych limitów i okolice 992 dla środka. Nie jest to jednak uniwersalna kalibracja każdego nadajnika.

Parser powinien zachować surową wartość diagnostyczną, a osobna warstwa kalibracji mapować ją na jednostkę wewnętrzną:

u = (raw - raw_trim) / (raw_max - raw_trim)  dla raw ≥ trim
u = (raw - raw_trim) / (raw_trim - raw_min)  dla raw < trim

Następnie u ogranicza się do zdefiniowanego zakresu, stosuje deadband i expo w odpowiedniej warstwie. Nie wolno rozciągać każdego chwilowego minimum/maksimum adaptacyjnie, bo zakłócenie zmieni kalibrację w locie.

Kalibracja RC zapisuje obserwowane końce, środek oraz mapę kanałów dla konkretnego modelu nadajnika. Pre-arm checks wykrywają gaz poza bezpiecznym zakresem, niecentrowane osie i brak wymaganych przełączników.

Parser strumieniowy#

UART dostarcza strumień, nie gotowe ramki. Przerwanie lub DMA może zwrócić dowolną liczbę bajtów. Parser potrzebuje małego automatu:

SEARCH_HEADER → COLLECT_25 → VALIDATE → PUBLISH
      ↑              │           │
      └──────────────┴── reject/resync

W SEARCH_HEADER oczekuje 0x0F. Po znalezieniu zbiera dokładnie 25 bajtów z deadline krótszym niż odstęp między ramkami. VALIDATE sprawdza nagłówek, stopkę i błędy UART. Ponieważ klasyczny SBUS nie ma CRC w tej ramce kanałów, poprawna długość i bajty graniczne nie wykryją każdej korupcji payloadu. Tym ważniejsze są kontrola fizyczna, sanity checks i flagi odbiornika.

Publikacja musi być atomowa: wszystkie 16 kanałów, flagi i timestamp należą do jednej ramki. Pętla sterowania nie może zobaczyć połowy starych i połowy nowych kanałów. Można użyć podwójnego bufora lub krótkiej sekcji krytycznej do zamiany wskaźnika.

Każda opublikowana ramka otrzymuje:

• monotoniczny czas zakończenia odbioru;
• numer sekwencji lokalnej;
• surowe kanały;
• flagi frame-lost/failsafe;
• liczniki błędów UART i odrzuceń;
• identyfikator portu/źródła, jeśli jest redundancja.

Resynchronizacja#

Po utracie bajtu przesunięcie trwa do czasu znalezienia kolejnej prawidłowej granicy. Naiwne „wyczyść wszystko i czekaj na 0x0F” może omyłkowo zacząć wewnątrz payloadu. Lepsza strategia testuje kandydatów w buforze przesuwanym i akceptuje ramkę dopiero po zgodnej pozycji nagłówka oraz stopki, a następnie potwierdza następną ramką w spodziewanym oknie czasowym.

Przerwa czasowa jest dodatkowym separatorem. Jeśli odstęp między bajtami jest większy niż czas pełnej ramki albo ustalony próg, częściowy bufor można odrzucić. Próg opiera się na 100 kbit/s i zachowaniu odbiornika, nie na schedulerze aplikacji.

Błędy parity, framing i overrun pochodzą z UART. Ramkę zawierającą taki błąd należy odrzucić w całości. Zignorowanie flagi parity jest szczególnie złe, bo parzystość stanowi jedyny bit kontroli każdego bajtu w tym formacie.

Timeout i świeżość danych#

Timer sprzętowy odbioru powinien mierzyć czas od ostatniej poprawnej, nie-failsafe ramki albo od ostatniej ramki zależnie od stanu. Trzy zdarzenia są różne:

• brak jakichkolwiek bajtów;
• bajty przychodzą, ale ramki są niepoprawne;
• ramki są poprawne strukturalnie, lecz mają lost/failsafe.

Diagnostyka powinna je rozdzielić. Dla sterowania wszystkie mogą ostatecznie prowadzić do failsafe, ale sugerują inne przyczyny: przerwany przewód, złą konfigurację UART, zakłócenia albo utratę radia.

Deadline nie może być tak długi, że platforma długo wykonuje ostatnią komendę, ani tak krótki, że prawidłowa zmienność okresu generuje fałszywe alarmy. Wyznacza się go na podstawie zmierzonego najgorszego interwału ramek, czasu reakcji platformy i budżetu całego failsafe. Warto logować histogram interwałów.

Mapowanie kanałów#

Pozycja w ramce nie mówi, czy kanał jest roll, pitch, throttle, yaw czy przełącznikiem. Kolejność AETR, TAER i inne warianty zależą od nadajnika oraz konfiguracji. Mapowanie jest częścią profilu pojazdu.

Każda funkcja powinna mieć:

• indeks kanału SBUS;
• kalibrację min/trim/max;
• deadband i ewentualną krzywą;
• wymagany stan przy uzbrajaniu;
• zachowanie przy failsafe;
• nazwę i opis fizycznego przełącznika.

Po zmianie nadajnika lub model memory przeprowadza się test wszystkich osi i przełączników. Nie wystarcza obserwacja, że cztery słupki się poruszają. Należy potwierdzić znaki osi oraz to, że przełącznik trybu nie został zamieniony z uzbrojeniem.

Wejście odbiornika i wyjście do serw#

SBUS IN i SBUS OUT mają podobny format danych, ale inne role bezpieczeństwa. Na wejściu flight controller interpretuje intencję operatora. Na wyjściu może sterować adresowanymi serwami albo dekoderem PWM. W tym drugim przypadku awaria jednego przewodu wpływa na wiele aktuatorów.

Wyjście do serw wymaga przydzielenia kanału w każdym urządzeniu S.BUS. Zasilanie nadal płynie oddzielnym torem o odpowiednim przekroju. Magistrala danych nie dostarcza automatycznie energii wystarczającej dla wielu serw. Koncentratory i dekodery mają ograniczenia prądowe oraz zasady zasilania opisane przez producenta.

Flight controller nie powinien bezrefleksyjnie przekazywać wejściowej ramki na wyjście. Regulatory, mikser, limity mechaniczne, arming i failsafe muszą pozostać w torze. Funkcja „passthrough” jest osobnym trybem wymagającym analizy.

Fast SBUS#

Fast SBUS używa wyższej szybkości, spotykanej jako 200 kbit/s, i szybszego odświeżania. Nie jest bezpiecznie wykrywać go tylko dlatego, że parser nie widzi ramek przy 100 kbit/s. Firmware oraz sprzęt muszą jawnie wspierać tryb, właściwą szybkość i inwersję.

Wyższa prędkość skraca czas transmisji 25 bajtów z około 3 ms do około 1,5 ms, lecz nie gwarantuje dwukrotnie mniejszego end-to-end latency. Radio, scheduler odbiornika i pętla FC nadal wnoszą opóźnienie. Pomiar wykonuje się od zmiany wejścia nadajnika albo testowego generatora do publikacji kanału.

Mniejszy czas bitu zmniejsza margines dla wolnych zboczy, pojemności przewodu i błędu zegara. Układ, który „prawie działał” przy 100 kbit/s, może generować błędy przy 200 kbit/s.

Porównanie z PWM i CRSF#

SBUS jest dobry jako szeroko kompatybilny, jednokierunkowy transport kanałów. CRSF jest bogatszy i dwukierunkowy, lecz wymaga TX i RX oraz bardziej rozbudowanego parsera. PWM pozostaje użyteczny dla prostych, pojedynczych funkcji, ale skaluje się słabo.

Wybór nie powinien opierać się wyłącznie na nazwie radia. Współczesny odbiornik ExpressLRS może wystawiać CRSF, SBUS albo inne formaty. Jeśli FC obsługuje CRSF i potrzebna jest telemetria/statystyki, konwersja do SBUS usuwa część informacji.

Integralność elektryczna#

SBUS jest sygnałem single-ended. Zakłócenie odniesienia masy bezpośrednio zmienia margines progu. Wiązkę prowadzi się z przewodem masowym, z dala od faz silników i węzłów przełączających przetwornic. Przy długim odcinku warto rozważyć buforowanie i analizę alternatywnego interfejsu różnicowego.

Test EMC wykonuje się w warunkach największego prądu napędu, ruchu serw, transmisji wideo i nadajnika radiowego. Liczniki parity/framing/overrun są wtedy lepszą miarą niż subiektywne „kanały wyglądają stabilnie”.

Zasilanie odbiornika powinno mieć monitorowany zapas. Reset odbiornika wygląda dla FC jak zanik ramek, ale przyczyna leży w szynie. Log napięcia, czasu resetu i stanu SBUS pomaga odróżnić brownout od utraty RF.

Ochrona ESD oraz rezystor szeregowy przy wejściu mogą poprawić odporność, lecz pojemność zabezpieczenia nie może nadmiernie spowalniać zboczy. Weryfikuje się poziomy przy odbiorniku FC, nie tylko przy nadajniku.

Implementacja parsera#

Szkic bezpiecznej obsługi:

typedef struct {
    uint16_t channel[16];
    bool ch17;
    bool ch18;
    bool frame_lost;
    bool receiver_failsafe;
    uint32_t timestamp_us;
    uint32_t sequence;
} sbus_frame_t;

bool sbus_decode(const uint8_t raw[25], sbus_frame_t *out)
{
    if (raw == NULL || out == NULL || raw[0] != 0x0F || !valid_footer(raw[24])) {
        return false;
    }

    sbus_frame_t next = {0};
    for (unsigned i = 0; i < 16; ++i) {
        next.channel[i] = sbus_channel(&raw[1], i);
    }

    next.ch17 = (raw[23] & 0x01U) != 0;
    next.ch18 = (raw[23] & 0x02U) != 0;
    next.frame_lost = (raw[23] & 0x04U) != 0;
    next.receiver_failsafe = (raw[23] & 0x08U) != 0;
    next.timestamp_us = monotonic_us();
    next.sequence = next_sequence();
    *out = next;
    return true;
}

W rzeczywistym kodzie przypisanie *out musi być atomowe względem czytelnika, valid_footer() jawnie wymienia obsługiwane warianty, a warstwa UART przekazuje flagi błędów. Parser nie publikuje ramki po parity/framing error nawet wtedy, gdy nagłówek i stopka pasują.

Surowe dane przechowuje się krótko w ring bufferze diagnostycznym, z ograniczeniem rozmiaru. Dzięki temu można odtworzyć utratę synchronizacji bez ciągłego logowania wszystkich ramek w locie.

Diagnostyka#

Kolejność pomiarów:

1. sprawdzić napięcie odbiornika pod obciążeniem;
2. potwierdzić wspólną masę i właściwy pin;
3. zmierzyć polaryzację oraz czas bitu;
4. dekodować UART jako 100000 8E2 z inwersją;
5. potwierdzić 25 bajtów, nagłówek i stopkę;
6. obserwować surowe 11-bitowe kanały;
7. sprawdzić mapowanie i kalibrację;
8. wymusić kontrolowaną utratę RF i zmierzyć flagi/deadline;
9. powtórzyć przy aktywnym napędzie i nadajnikach pokładowych.

Przy braku danych najczęstszy jest problem elektryczny lub konfiguracja UART. Przy losowych wartościach — zła inwersja, parzystość, prędkość albo resynchronizacja. Przy stabilnych, lecz źle przypisanych osiach — mapowanie kanałów. Przy resetach podczas ruchu serw — zasilanie.

Log operacyjny powinien zawierać age_us, liczbę poprawnych ramek, lost, failsafe, parity, framing, overrun i resync. Sam RSSI z radia nie zastępuje tych liczników.

Plan testów#

Wektory parsera#

• wszystkie kanały równe minimum, środkowi i maksimum;
• każdy kanał osobno z wartością zawierającą różne bity;
• kanały przecinające granice bajtów;
• CH17/CH18 w każdej kombinacji;
• flagi lost i failsafe osobno oraz razem;
• błędny nagłówek, stopka i skrócona ramka;
• jeden usunięty lub dodany bajt i odzyskanie synchronizacji;
• błędy parity/framing przekazane przez UART.

Timing#

• histogram okresu ramek przez kilka minut;
• czas od końca ramki do publikacji;
• jitter przy maksymalnym obciążeniu CPU/DMA;
• deadline braku ramek i czas wejścia w failsafe;
• zachowanie po powrocie sygnału;
• wariant normalny i Fast SBUS, jeśli wspierany.

Hardware#

• minimalne/maksymalne napięcie odbiornika;
• temperatura, długi przewód i dodatkowa pojemność;
• reset FC, reset odbiornika i niezależne cykle zasilania;
• pełny prąd napędu i ruch wszystkich serw;
• ESD/EMI zgodnie z planem kwalifikacji platformy;
• podwójna inwersja i odłączona masa jako test negatywny.

Failsafe#

Testuje się co najmniej: wyłączenie nadajnika, zasłonięcie/odłączenie RF w kontrolowanym stanowisku, odłączenie przewodu SBUS, zwarcie linii do bezpiecznego poziomu przez ograniczenie prądu, zamrożenie parsera i reset odbiornika. Każdy przypadek ma oczekiwany stan oraz maksymalny czas reakcji.

Typowe błędy#

Kryteria odbioru#

Najważniejszą własnością bezpiecznego wejścia SBUS nie jest samo poprawne rozpakowanie 176 bitów. Jest nią jednoznaczne rozróżnienie świeżej komendy, powtórzonej lub utraconej ramki, aktywnego failsafe i całkowitego zaniku strumienia — oraz terminowe przekazanie tego stanu do maszyny sterowania lotem.

Powiązane tematy#

• Systemy RC dla UAV
• PWM w UAV
• CRSF
• UART w UAV
• Failsafe jako maszyna stanów
• Flight controller — jak działa
• EMI/EMC w kontrolerze lotu

Przypisy#

1. Futaba USA, Product Support — S.BUS technology, https://futabausa.com/product-support/ (dostęp: 15 sierpnia 2026).
2. Futaba, SBD-3 S.BUS/S.BUS2 Decoder — Instruction Manual, https://futabausa.com/wp-content/uploads/2021/12/1M23N37701_SBD-3_print.pdf (dostęp: 15 sierpnia 2026).
3. Bolder Flight Systems, SBUS library and protocol description, https://github.com/bolderflight/sbus (dostęp: 15 sierpnia 2026).
4. Betaflight, SBUS receiver implementation, https://github.com/betaflight/betaflight/blob/master/src/main/rx/sbus.c (dostęp: 15 sierpnia 2026).
5. ArduPilot, Radio Control Systems, https://ardupilot.org/copter/docs/common-rc-systems.html (dostęp: 15 sierpnia 2026).
6. ExpressLRS, Receiver Serial Protocols, https://www.expresslrs.org/software/serial-protocols/ (dostęp: 15 sierpnia 2026).

Powiązane tematy

Systemy RC dla UAVArchitektura nowoczesnego łącza RC: packet rate, opóźnienie, czułość, LQ/RSSI/SNR, telemetria i zachowanie po utracie ramek.PWM w UAVPWM w UAV od właściwego współczynnika wypełnienia i kodowania szerokością impulsu przez PSC/ARR/CCR, rozdzielczość oraz grupy timerów do mapowania wyjść, poziomów elektrycznych, stanów startowych, failsafe i pomiaru oscyloskopem lub input capture.CRSFCRSF jako pełnodupleksowy interfejs odbiornik–flight controller: framing, adresy i typy wiadomości, CRC-8, 16 kanałów pakowanych, link statistics, telemetria, urządzenia i parametry, parser odporny na błędy, budżet przepływności, failsafe oraz diagnostyka.UART i USART w UAVUART od bitu startu do parsera strumieniowego: tolerancja zegarów, oversampling, błędy framing/overrun, idle-line DMA, poziomy TTL i odróżnienie od RS‑232/RS‑485.Failsafe jako maszyna stanówFailsafe jako deterministyczny system decyzji: źródła faultów, persistence i hysteresis, priorytety reakcji, konflikty RC/GNSS/baterii, latch, recovery oraz macierz testowa.Flight controller — jak działaPrzekrojowa techniczna anatomia kontrolera lotu: sprzęt, domeny czasu, sensory, estymacja stanu, regulatory kaskadowe, alokacja sterowania, wyjścia, zasilanie, odporność na awarie, logowanie i uruchomienie platformy.EMI/EMC w kontrolerze lotuEMI/EMC flight controllera jako problem obwodów i pól: pętle di/dt, węzły dv/dt, powroty prądów, sprzężenia przewodzone i promieniowane, ochrona portów oraz plan testów przedzgodnościowych.

Źródła z centralnego rejestru

1. Futaba USA: S.BUS technology and product support [dokumentacja producenta]
2. Futaba SBD-3 S.BUS/S.BUS2 Decoder — instruction manual [instrukcja producenta]
3. Bolder Flight Systems: SBUS library and protocol description [repozytorium open source]
4. Betaflight: SBUS receiver implementation [repozytorium open source]
5. ArduPilot: Radio Control Systems and receiver protocols [dokumentacja projektu]
6. ExpressLRS: Receiver Serial Protocols [dokumentacja projektu]
7. Terry Kilby, Belinda Kilby, „Make: Drony dla początkujących” [książka]
8. Sumit Sharma, „Drone Development from Concept to Flight” [książka]