DShot w UAV

DShot jest cyfrowym protokołem wysyłającym z flight controllera do ESC 16-bitowe słowo sterujące. Słowo zawiera wartość throttle lub komendę specjalną, bit żądania telemetrii i 4-bitową sumę kontrolną. Każdy bit ma stały okres, a zero od jedynki odróżnia czas trwania aktywnej części impulsu. Timer oraz DMA mikrokontrolera nadal generują przebieg o różnych szerokościach, lecz odbiornik interpretuje kompletny ciąg bitów z kontrolą integralności — dlatego DShot nie jest analogowym PWM o większej częstotliwości.

Największą korzyścią w torze wykonawczym jest jednoznaczne kodowanie wartości i wykrywanie części błędów. Nie kalibruje się analogowych endpointów jak w klasycznym wejściu ESC. DShot nie rozwiązuje jednak problemów z zasilaniem, desynchronizacją komutacji, temperaturą, niezgodnym firmware ani błędnym uzbrojeniem. Poprawna suma kontrolna oznacza tylko, że ESC prawdopodobnie odebrał dane takie, jakie wysłał FC.

Spis treści#

• Miejsce DShot w torze napędu
• DShot a PWM, OneShot i Multishot
• Ramka 16-bitowa
• Pole throttle i komendy
• Bit telemetry request
• Checksum
• Kodowanie bitu
• DShot150, 300, 600 i 1200
• Czas ramki i rate aktualizacji
• Generowanie timerem i DMA
• Mapowanie timerów, kanałów i DMA
• Synchronizacja wielu silników
• Komendy specjalne
• Arming i stan zero
• Klasyczna telemetria na osobnym przewodzie
• Bidirectional DShot
• Odpowiedź eRPM
• eRPM a RPM mechaniczne
• Filtr RPM
• Extended DShot telemetry
• Failsafe i timeout ESC
• Warstwa elektryczna i EMC
• Implementacja nadajnika
• Implementacja odbioru bidirectional
• Diagnostyka oscyloskopem
• Plan testów
• Typowe błędy
• Kryteria odbioru
• Powiązane tematy
• Przypisy

Miejsce DShot w torze napędu#

DShot przenosi żądanie między mikserem aktuatorów w flight controllerze a firmware ESC. Nie steruje bezpośrednio fazami silnika. Po odebraniu ramki ESC wybiera komutację, częstotliwość PWM mostka, advance timing i ograniczenia prądu zgodnie z własnym algorytmem.

regulator osi
    ↓
control allocation / mixer
    ↓ żądanie silnika
arming + limity + failsafe
    ↓ wartość DShot
encoder 16 bit → timer/DMA → przewód → dekoder ESC
                                      ↓
                               komutacja MOSFET
                                      ↓
                                   silnik BLDC

Gdy silnik nie obraca się mimo poprawnych ramek, problem może leżeć w komutacji, przewodach fazowych, zasilaniu, ustawieniach ESC albo mechanice. Gdy ramki nie dochodzą, oscyloskop przy wejściu ESC rozstrzyga, czy zawodzi encoder, zasób timera czy warstwa elektryczna.

DShot jest zwykle używany w multirotorach, gdzie szybka i powtarzalna aktualizacja wielu silników ma bezpośredni wpływ na pętlę rate. W płatowcu może sterować napędem głównym, ale serwa powierzchni nadal korzystają z PWM, CAN lub innych interfejsów. Mieszanie protokołów trzeba uwzględnić w przydziale timerów.

DShot a PWM, OneShot i Multishot#

W klasycznym sygnale ESC jedna szerokość impulsu odpowiada wartości throttle. Zakłócenie przesuwające zbocze zmienia zmierzoną wartość bez możliwości sprawdzenia. OneShot i Multishot skracają impuls, lecz nadal kodują komendę jego czasem.

DShot wysyła 16 kolejnych komórek o stałym czasie bitu. W każdej komórce czas aktywny oznacza zero albo jeden. Odbiornik składa słowo i sprawdza checksum. Nie potrzebuje kalibracji minimum/maksimum na podstawie długości pojedynczego impulsu.

Checksum ma tylko cztery bity i nie wykrywa wszystkich możliwych wzorców błędów. DShot nie jest protokołem safety bus. W systemie o wyższej krytyczności potrzebne są dodatkowe monitorowanie prędkości, prądu i odpowiedzi napędu.

Ramka 16-bitowa#

Format podstawowy:

SSSSSSSSSSS T CCCC
└─ 11 bit ─┘ │ └4┘
 throttle/    │ checksum
 command      telemetry request

Encoder najpierw tworzy 12-bitową wartość:

payload12 = (value11 << 1) | telemetry_bit

Następnie wylicza cztery bity checksum i dołącza je jako najmłodsze bity:

frame16 = (payload12 << 4) | checksum4

Bity są wysyłane od najbardziej znaczącego. Wszystkie 16 komórek ma ten sam okres nominalny. Wartość zero i maksimum dają ramki tej samej długości; różni się tylko suma czasów aktywnego poziomu.

Przed kodowaniem wartość musi być ograniczona do 11 bitów. Przepełnienie lub znakowa liczba ujemna nie może wejść do przesunięcia. Warstwa aktuatora mapuje znormalizowane żądanie na dozwolony zakres, a encoder przyjmuje już zwalidowany uint16_t.

Pole throttle i komendy#

11 bitów daje wartości 0–2047. Konwencja DShot dzieli je:

Nie wolno liniowo mapować znormalizowanego gazu na 0–2047 i przypadkowo wysyłać wartości 1–47 podczas małej komendy. Dla zwykłego napędu dodatni throttle zaczyna się od 48. Wartość zero jest osobnym stanem, nie kolejnym punktem liniowej krzywej.

Przykład mapowania u ∈ [0,1]:

u <= 0       → 0
0 < u <= 1   → 48 + round(u · (2047 - 48))

W praktyce idle/minimum output może ustalać firmware FC, a ESC ma własne minimum stabilnej komutacji. Nie należy dobierać go wyłącznie z numeru DShot. Zbyt niskie obroty mogą prowadzić do zatrzymania/desync, a zbyt wysokie zwiększają ciąg w armed idle.

Dla napędu odwracalnego semantyka zależy od trybu 3D i konfiguracji ESC. Środek zakresu może rozdzielać kierunki, ale szczegółowa mapa ma pochodzić z dokumentacji firmware. Błędna konfiguracja może spowodować zmianę kierunku lub nieoczekiwany start.

Bit telemetry request#

Dwunasty bit payloadu historycznie żąda klasycznej telemetrii ESC przesyłanej osobnym przewodem. Nie oznacza bidirectional DShot eRPM: w trybie dwukierunkowym odpowiedź prędkości wraca po każdej ramce na tym samym przewodzie, a bit/semantyka checksum ulega odpowiedniej interpretacji.

Żądanie telemetrii powinno być harmonogramowane. Jeśli wiele ESC dzieli linię telemetryczną, jednoczesne odpowiedzi mogą kolidować, zależnie od topologii. FC może prosić kolejne ESC round-robin.

Ustawienie bitu w każdej ramce nie zwiększa użytecznej częstotliwości, jeśli osobny UART lub ESC nie nadąża. Tworzy zbędne obciążenie. Scheduler określa, które dane są potrzebne i z jaką częstotliwością.

Checksum#

Dla zwykłego DShot checksum jest XOR-em trzech 4-bitowych nibble payloadu:

static uint8_t dshot_checksum(uint16_t payload12)
{
    return (uint8_t)((payload12 ^ (payload12 >> 4) ^ (payload12 >> 8)) & 0x0FU);
}

Pełny encoder:

static uint16_t dshot_make_frame(uint16_t value, bool telemetry)
{
    value &= 0x07FFU;
    const uint16_t payload = (uint16_t)((value << 1) | (telemetry ? 1U : 0U));
    return (uint16_t)((payload << 4) | dshot_checksum(payload));
}

Maskowanie w przykładzie nie zastępuje walidacji zakresu. Produkcyjny interfejs powinien odrzucić value > 2047, bo ciche obcięcie może zamienić błąd na inną poprawną komendę.

W bidirectional DShot checksum ramki wysyłanej przez FC jest odwrócony:

checksum_bidir = ~(payload ^ payload>>4 ^ payload>>8) & 0x0F

To sygnalizuje ESC tryb dwukierunkowy razem z odwróconą polaryzacją przebiegu. Użycie zwykłego checksum przy odwróconej linii albo odwrotnie skutkuje odrzuceniem.

Cztery bity dają tylko 16 możliwych wartości. Prawdopodobieństwo przypadkowego przejścia całkowicie losowej ramki jest rzędu 1/16, choć rzeczywiste błędy nie są równomierne. Dlatego deadline, ciągłość i telemetria odpowiedzi pozostają potrzebne.

Kodowanie bitu#

Każdy bit ma stały nominalny okres Tbit. Jedynka utrzymuje poziom aktywny około 3/4 okresu, zero około 3/8 okresu. W dokumentacji Betaflight wartości są podawane tak, że czas aktywny jedynki jest dwukrotnie dłuższy niż zera.

bit 0:  ┌───┐_____
        │   │
        └───┴──────  stały okres

bit 1:  ┌──────┐__
        │      │
        └──────┴───  ten sam okres

ESC mierzy proporcję/czas aktywnego poziomu w komórce. Threshold powinien leżeć między nominalnym T0H i T1H. Generator FC tworzy tablicę wartości compare: jedna dla zera, druga dla jedynki. DMA podaje kolejno 16 wartości do CCR timera.

Polaryzacja normalnego DShot jest aktywna wysoko. Bidirectional używa odwróconego przebiegu dla ramki FC→ESC. Na oscyloskopie trzeba wiedzieć, który tryb jest wybrany; inaczej prawidłowy sygnał wygląda jak odwrócony błąd.

Po 16 bitach generator pozostawia stan nieaktywny przez wymagany czas. Bufor DMA często zawiera dodatkowe zera/reset slots, aby deterministycznie zakończyć transmisję.

DShot150, 300, 600 i 1200#

Liczba oznacza nominalny bitrate w kbit/s:

Wartości są nominalne. Firmware toleruje określony błąd, ale projekt powinien wygenerować timing bliski specyfikacji. DShot1200 nie jest powszechnie wspierany i krótszy czas nie zawsze daje korzyść: zwiększa wymagania elektryczne oraz zasobowe, a częstotliwość pętli może nie potrzebować takiego rate.

Dobiera się najwyższy wariant stabilny dla FC, ESC, przewodów i bidirectional telemetry, ale z marginesem. DShot300 jest często dobrym kompromisem dla dwukierunkowej odpowiedzi, DShot600 dla krótszej ramki na odpowiednim sprzęcie. Dokumentacja PX4 i Betaflight wskazuje wspierane warianty konkretnego firmware.

Czas ramki i rate aktualizacji#

Minimalny czas samej ramki to 16 / bitrate. Maksymalna częstotliwość aktualizacji jest mniejsza, ponieważ potrzeba przerwy, obsługi DMA, a w bidirectional także przełączenia linii i odpowiedzi ESC.

Dla jednostronnego DShot600 ramka trwa około 26,7 µs, więc czysto teoretycznie mieści się wiele tysięcy ramek/s. Nie znaczy to, że należy wysyłać throttle z takim rate. Nowa komenda powstaje w rytmie regulatora/miksera. Powtarzanie tej samej ramki zwiększa obciążenie bez nowej informacji.

Jeśli pętla PID działa 4 kHz, okres wynosi 250 µs. DShot300 zajmuje około 53 µs plus przerwa, więc jest możliwy. W bidirectional dochodzi około 30 µs przełączenia i odpowiedź, co zmniejsza margines. Betaflight wskazuje, że zwrot eRPM efektywnie ogranicza liczbę ramek i trzeba go uwzględnić przy wysokich PID rates.

Rate output powinien być całkowitym podziałem lub kontrolowanym harmonogramem pętli. Jeśli każda aktualizacja przesuwa się względem PID, powstaje jitter fazy. Timestamp publikacji miksera i start DMA należy logować w testach czasu rzeczywistego.

Generowanie timerem i DMA#

Najczęstszy wzorzec STM32:

1. timer ma okres odpowiadający jednemu bitowi;
2. kanał PWM generuje zbocze na początku komórki;
3. CCR określa T0H lub T1H;
4. DMA przy każdym update kopiuje kolejną wartość compare;
5. po 16 bitach dodatkowe elementy wymuszają stan idle;
6. przerwanie zakończenia oznacza gotowość kanału.

frame16 → encoder bitów → [CCR1, CCR2, ... CCR16, 0, 0]
                                 │
DMA request <── timer update ────┘
timer channel ─────────────────────> motor pin

Prescaler i ARR dobiera się tak, aby błąd okresu oraz compare był mały. Przykładowo timer 72 MHz dla DShot600 ma 120 taktów na bit; T1H około 90 taktów, T0H około 45. To wygodne całkowite wartości. Inny zegar może wymagać zaokrąglenia.

Rejestry preload zapobiegają zmianie compare w środku komórki. DMA musi być uruchomione przed startem timera, flagi wyczyszczone, a bufor niezmieniany do zakończenia transferu. Podwójne buforowanie pozwala przygotować następną ramkę równolegle.

Bitbang przez programowe GPIO może działać na określonych MCU, lecz musi spełnić timing pod obciążeniem i przy przerwaniach. Implementacje Betaflight mają wyspecjalizowane mechanizmy; własny flight controller powinien preferować sprzętowy timer/DMA, jeśli zasoby na to pozwalają.

Mapowanie timerów, kanałów i DMA#

Nie każdy pin silnika jest równoważny. DShot wymaga kanału timera, odpowiedniej funkcji alternate i ścieżki DMA lub wspieranego bitbang. Na STM32 mapowanie DMA zależy od rodziny i konkretnego timera; dwa kanały mogą konkurować o ten sam stream/request.

Manifest sprzętu powinien zawierać:

Konflikt może ujawnić się dopiero po włączeniu LED strip, kamery, SDIO, SPI DMA lub dodatkowego silnika. Testy konfiguracji zasobów muszą objąć kompletną funkcję płyty.

W bidirectional pin przełącza się z wyjścia timerowego na wejście capture/odczyt. Płyta musi to umożliwiać bez zewnętrznego bufora jednokierunkowego. Rezystor/driver na torze może uniemożliwić odpowiedź ESC mimo poprawnego DShot jednostronnego.

Synchronizacja wielu silników#

Wektor czterech lub większej liczby silników powstaje z jednego wyniku miksera. Wszystkie ramki powinny rozpocząć się w kontrolowanym oknie. Start kolejnych DMA sekwencyjnie przez CPU wprowadza małe przesunięcie; można użyć wspólnego triggera timerów, burst DMA albo ocenić, czy skew mieści się w budżecie.

Istotne jest, aby nie połączyć wartości z różnych iteracji. Schemat:

control allocation
    ↓ atomic motor vector + sequence
encode M1..Mn into inactive buffers
    ↓ validate all ready
common start / bounded skew
    ↓
DMA complete counters → output watchdog

Jeśli encoder jednego kanału zgłosi błąd, polityka nie powinna wysłać nowych danych do trzech silników i starej do czwartego bez jawnej analizy. Bezpieczniej odrzucić całą ramkę wektora lub przejść do zdefiniowanego stanu.

Telemetry return w bidirectional jest per silnik. Odbiornik musi przypisać odpowiedź do kanału, a okna nie mogą się nakładać. Równoległe osobne linie pozwalają odbierać jednocześnie; wspólne zasoby capture mogą wymagać sekwencji.

Komendy specjalne#

Wartości 1–47 są zarezerwowane dla komend, m.in. dźwięków beacon, kierunku obrotu, trybu 3D, zapisania ustawień lub telemetrii zależnie od firmware ESC. Dokładna tabela i wymagania powtórzeń pochodzą z aktualnej dokumentacji implementacji.

Komenda nie jest zwykłym throttle:

• wiele komend działa tylko przy zatrzymanym silniku;
• część wymaga wysłania określoną liczbę razy;
• między komendami wymagane są przerwy;
• zapis flash może trwać i nie powinien zachodzić w locie;
• beacon ma guard time przed ponownym uzbrojeniem;
• nie każdy ESC wspiera każdy numer.

API powinno używać enum nazwanych komend i maszyny stanów, nie przyjmować dowolnego numeru od aplikacji. Warstwa arming blokuje komendy konfiguracyjne podczas armed. Po komendzie kierunku trzeba zweryfikować faktyczne obroty bez śmigła.

Firmware Betaflight opóźnia uzbrojenie po komendzie beacon, aby nie rozpocząć napędu w niewłaściwym oknie. Podobne zależności muszą być częścią własnej implementacji.

Arming i stan zero#

Zero DShot oznacza stan bez napędu/disarmed w warstwie protokołu. ESC może wymagać serii zerowych ramek po starcie, aby rozpoznać DShot i wejść w gotowość. FC nie wysyła dodatniego throttle przed zakończeniem pre-arm checks.

Bezpieczna sekwencja:

1. GPIO ma nieaktywny stan sprzętowy podczas resetu;
2. timer/DMA inicjalizuje się z ramką zero;
3. FC wysyła stabilne zera przez wymagany czas;
4. potwierdza konfigurację silników, telemetrię i sensory;
5. przyjmuje jawne żądanie uzbrojenia;
6. dopiero wtedy mapuje idle/dodatnie wartości;
7. disarm natychmiast wraca do zera i utrzymuje je.

Niektóre ESC automatycznie wykrywają typ wejścia PWM/DShot. Błędny wolny przebieg podczas bootu może zostać rozpoznany jako servo input. Dedykowana konfiguracja input type jest bezpieczniejsza niż auto-detection, jeśli firmware ją oferuje.

Po watchdog reset FC wraca do zer, nie do ostatniej ramki. Zewnętrzny rezystor ustala linię idle. Wartość z niezainicjalizowanej pamięci nie może zostać zakodowana jako komenda.

Klasyczna telemetria na osobnym przewodzie#

ESC może wysyłać telemetry UART (np. napięcie, prąd, temperaturę, eRPM) osobną linią do FC. Bit telemetry request w DShot wskazuje żądanie odpowiedzi w odpowiednim schemacie. Format i sposób multipleksowania zależą od firmware ESC.

Zaletą oddzielnej linii jest brak konieczności szybkiego przełączania pinu silnika na wejście. Wadą są dodatkowe przewody i UART. W 4-in-1 ESC często istnieje wspólna linia telemetryczna, a FC odpytuje ESC kolejno.

Timestamp telemetrii jest ważny. Temperatura może być wolna, eRPM potrzebuje wyższego rate dla filtracji. CRC/checksum telemetrii sprawdza się niezależnie od DShot output. Brak odpowiedzi nie oznacza automatycznie zatrzymanego silnika; może zawieść tylko kanał zwrotny.

Bidirectional DShot#

Bidirectional DShot wykorzystuje ten sam przewód naprzemiennie. FC wysyła odwróconą ramkę, przełącza pin na wejście i po przerwie odbiera odpowiedź ESC z eRPM. ESC rozpoznaje tryb po polaryzacji/checksum i przechodzi z odbioru na nadawanie.

FC output:  [16-bit inverted DShot] ── guard/switch ──┐
                                                     │ ten sam przewód
FC input:   <──────────── eRPM response from ESC ────┘

Dokumentacja Betaflight podaje około 30 µs przerwy na przełączenie linii, DMA i timerów po ramce FC. Potem przychodzi odpowiedź. W efekcie cykl jest wyraźnie dłuższy niż jednostronny DShot, zwłaszcza przy DShot600/1200, gdzie stały guard dominuje.

Wymagania sprzętowe:

• pin musi obsługiwać wyjście i szybkie wejście;
• zewnętrzny driver nie może blokować kierunku ESC→FC;
• pull-up/down nie może zniekształcać odpowiedzi;
• timer/input capture lub szybki sampling musi zmierzyć impulsy;
• każda linia ma osobny stan i timeout;
• ESC firmware musi wspierać zgodny wariant bidirectional.

Betaflight dokumentuje wsparcie zależne od firmware ESC, m.in. BLHeli_32 i BLHeli_S z odpowiednim Bluejay; AM32 deklaruje bidirectional DShot. Zawsze sprawdza się wersję oraz target, bo nazwa rodziny nie gwarantuje ustawień.

Odpowiedź eRPM#

Odpowiedź nie jest kopią ramki FC. ESC koduje okres komutacji elektrycznej w kompaktowym słowie, a transmisja używa kodowania zapewniającego wystarczającą liczbę przejść do odzyskania zegara. Decoder mierzy długości impulsów/ciąg przejść, odtwarza bity, sprawdza integralność i przelicza wartość na okres eRPM.

Nie należy implementować dekodera na podstawie samego „to 16 bitów jak DShot”. Aktualna dokumentacja Betaflight opisuje GCR i strukturę odpowiedzi. Własny driver powinien bazować na zgodnej implementacji oraz wektorach z logic analyzer.

Wynik ma kilka stanów:

• poprawna odpowiedź i wartość okresu;
• poprawna odpowiedź oznaczająca zatrzymanie/overflow zgodnie z formatem;
• brak odpowiedzi;
• błąd dekodowania/GCR/checksum;
• odpowiedź poza oknem;
• wartość fizycznie niemożliwa.

Nie zastępuje się błędu wartością zero bez flagi, bo regulator/filtr nie odróżni zatrzymanego silnika od utraty telemetrii. Każdy silnik ma erpm_valid, timestamp i licznik jakości.

eRPM a RPM mechaniczne#

eRPM opisuje prędkość elektrycznych komutacji. Aby uzyskać obroty mechaniczne, trzeba znać liczbę par biegunów:

mechanical_RPM = electrical_RPM / pole_pairs
pole_pairs = motor_poles / 2

Silnik 14-biegunowy ma 7 par. Jeśli telemetria wskazuje 70 000 eRPM, mechanicznie jest to około 10 000 RPM. Pomylenie liczby biegunów z parami daje błąd dwukrotny.

Konfiguracja liczby biegunów jest per typ silnika. W platformie z różnymi silnikami/payloadem nie może być jedną przypadkową globalną stałą. Pomiar tachometrem optycznym na stanowisku weryfikuje przeliczenie.

Przy bardzo małej prędkości okres elektryczny jest długi, może przekroczyć zakres formatu lub timeout. Przy wysokiej prędkości kwantyzacja okresu wpływa na dokładność. Filtr powinien uwzględnić valid range i nie ekstrapolować bez ograniczeń.

Filtr RPM#

Bidirectional DShot dostarcza eRPM każdego silnika, co pozwala ustawiać notch filtry przy częstotliwości podstawowej i harmonicznych związanych z napędem. Betaflight używa tej informacji w RPM filtering.

Łańcuch:

eRPM response → validate → mechanical/electrical frequency
              → smoothing/prediction → notch center frequencies
              → gyro filtering → PID

Filtr nie może śledzić pojedynczej błędnej próbki. Wymaga kontroli szybkości zmiany, wieku i zakresu. Gdy telemetria znika, częstotliwość notch może być przez krótki czas utrzymana, następnie zamrożona lub zastąpiona bezpiecznym profilem statycznym. Polityka musi unikać nagłego wyłączenia całej ochrony drgań.

Liczba harmonicznych zwiększa koszt CPU i opóźnienie filtra. Dobiera się ją na podstawie spektrum Blackbox, nie maksymalnej dostępnej opcji. eRPM pokazuje źródło, ale rezonans ramy może występować przy innych częstotliwościach.

Weryfikacja porównuje ridge w spektrogramie żyroskopu ze zgłoszoną prędkością. Jeśli zależność ma błędny mnożnik, prawdopodobna jest zła liczba biegunów albo interpretacja eRPM.

Extended DShot telemetry#

Nowsze implementacje mogą kodować dodatkowe dane telemetryczne w odpowiedziach bidirectional, przeplatając eRPM z temperaturą, napięciem, prądem lub zdarzeniami zależnie od firmware. Betaflight ma mechanizmy Extended DShot Telemetry i wysyła komendę włączenia w odpowiednich warunkach.

Decoder musi rozpoznać typ wartości przed interpretacją. Nie wolno traktować każdej odpowiedzi jako okresu eRPM. Scheduler zachowuje wystarczającą częstotliwość próbek prędkości dla filtrów, a wolniejsze pola odświeża rzadziej.

Kompatybilność wymaga wspólnej wersji ESC i FC. Jeśli EDT nie jest wspierane, system powinien pozostać przy zwykłym eRPM bez błędnych wartości. Tryb i statystyki dekodera są widoczne w diagnostyce.

Dane temperatury/prądu z ESC są użyteczne, ale nie zastępują niezależnego pomiaru baterii tam, gdzie wymagany jest dokładny bilans energii. Częstotliwość i kalibracja zależą od hardware ESC.

Failsafe i timeout ESC#

ESC powinien zatrzymać napęd po utracie poprawnych ramek przez zdefiniowany czas. Flight controller powinien równocześnie wysyłać zero po disarm/failsafe. Te mechanizmy są warstwowe.

Scenariusze:

• FC działa i decyduje o disarm → natychmiastowe zera;
• driver DShot/DMA zawiesza się → output watchdog wyłącza timer lub wymusza zero;
• FC resetuje się → hardware pin idle, ESC timeout zatrzymuje silnik;
• przewód zostaje przerwany → ESC timeout;
• zakłócenia dają złe checksum → ESC odrzuca, a potem timeout;
• tylko telemetria return znika → throttle może nadal działać, FC degraduje filtr/zgłasza błąd.

Timeout ESC jest ustawieniem firmware i może różnić się dla pracującego/zatrzymanego silnika. Release notes AM32 pokazują, że polityka arming timeout zmienia się między wersjami, dlatego wartość trzeba weryfikować, nie zakładać.

FC monitoruje postęp DMA per kanał oraz numer ostatniej wysłanej sekwencji. Sam fakt, że timer działa, nie oznacza świeżego wyniku regulatora. Driver nie może nieskończenie powtarzać ostatniego dodatniego throttle po zatrzymaniu pętli.

Warstwa elektryczna i EMC#

DShot jest single-ended i zwykle pracuje poziomem 3,3 V. Na krótkiej wiązce FC–4-in-1 ESC ma dobry margines, ale DShot600 ma impulsy 625 ns dla zera, więc wolne zbocza i ringing są istotne.

Zasady:

• wspólna masa FC i ESC z kontrolowanym powrotem prądów;
• przewody sygnałowe krótkie, oddalone od faz silnika;
• mały rezystor szeregowy przy nadajniku, jeśli pomiar wskazuje ringing;
• ochrona ESD o małej pojemności;
• brak dużego kondensatora RC na linii;
• pomiar przy pełnym prądzie i wszystkich przetwornicach;
• dla bidirectional driver/pull nie może blokować odpowiedzi.

Nie należy prowadzić masy sondy oscyloskopowej do fazy silnika. DShot mierzy się względem masy logicznej na wejściu ESC. Fazy mostka mają wysokie dV/dt i wymagają odpowiednich sond różnicowych oraz procedur bezpieczeństwa.

Jeśli DShot150 działa, a DShot600 nie, przyczyna może być w zegarze/timerze, zboczach, przewodzie albo kompatybilności ESC. Obniżenie rate jest poprawną decyzją, jeśli spełnia latency i daje większy margines.

Implementacja nadajnika#

Encoder buduje pełny bufor przed startem DMA:

enum { DSHOT_BITS = 16, DSHOT_TRAILER = 2 };

bool dshot_encode(uint16_t value, bool telemetry,
                  uint16_t compare_zero, uint16_t compare_one,
                  uint16_t out[DSHOT_BITS + DSHOT_TRAILER])
{
    if (value > 2047U || out == NULL) return false;
    const uint16_t payload = (uint16_t)((value << 1) | telemetry);
    const uint16_t frame = (uint16_t)((payload << 4) | dshot_checksum(payload));

    for (unsigned i = 0; i < DSHOT_BITS; ++i) {
        const uint16_t mask = (uint16_t)(0x8000U >> i);
        out[i] = (frame & mask) ? compare_one : compare_zero;
    }
    out[16] = 0;
    out[17] = 0;
    return true;
}

W bidirectional używa się odwróconego checksum i właściwej polaryzacji. Konfiguracja timera, wartości compare i liczba trailer slots są zależne od drivera.

Warstwa wielokanałowa:

1. pobiera atomowy motor vector;
2. sprawdza armed/freshness/range;
3. koduje wszystkie kanały do nieaktywnego banku;
4. sprawdza gotowość poprzedniego DMA;
5. przełącza banki i startuje z bounded skew;
6. zapisuje sequence oraz timestamp;
7. po timeout DMA przechodzi do awarii, nie nadpisuje bufora.

Komenda specjalna korzysta z osobnej kolejki i maszyny stanów. Nie miesza się jej z normalnym mapperem throttle.

Implementacja odbioru bidirectional#

Po zakończeniu TX driver:

1. zatrzymuje output/DMA;
2. ustawia bezpieczny stan linii;
3. przełącza GPIO/timer na wejście;
4. rozpoczyna input capture lub sampling;
5. czeka w ograniczonym oknie;
6. zapisuje krawędzie/próbki do bufora DMA;
7. kończy przy pełnej odpowiedzi lub timeout;
8. dekoduje poza krytycznym ISR;
9. publikuje wartość z valid flag i timestampem;
10. przygotowuje linię do następnego TX.

Przełączenie musi być deterministyczne. Jeśli FC zbyt długo trzyma pin jako push-pull output, zderzy się z ESC nadającym odpowiedź. To może zniekształcić dane i powodować przepływ prądu między wyjściami. Guard time oraz kolejność rejestrów są krytyczne.

Input capture zapisuje czas kolejnych krawędzi. Decoder przelicza długości na symbole, odtwarza kod i sprawdza checksum. Timeout lub liczba krawędzi poza zakresem kończy próbę bez blokowania pętli.

Każdy silnik ma rolling quality:

valid_responses / requested_responses
decode_errors
timeouts
out_of_range_erpm
age_last_valid

Próg zdrowia nie powinien wymagać 100% w każdym oknie, ale utrata wielu odpowiedzi uruchamia degradację RPM filter i diagnostykę.

Diagnostyka oscyloskopem#

Pomiary jednostronne:

• okres bitu i rate;
• T0H i T1H;
• liczba 16 komórek;
• stan idle/trailer;
• zgodność ramki z żądaną wartością i checksum;
• skew między silnikami;
• poziomy, overshoot i ringing przy wejściu ESC;
• zachowanie boot, arm, disarm i watchdog reset.

Bidirectional dodatkowo:

• odwrócona polaryzacja TX;
• moment zwolnienia linii przez FC;
• około 30 µs guard zgodny z implementacją;
• odpowiedź ESC i jej amplituda;
• moment ponownego przejęcia linii;
• brak konfliktu push-pull;
• jakość przy DShot300/600 i wszystkich silnikach.

Logic analyzer może dekodować ramki, ale trzeba zweryfikować jego sample rate. Dla impulsu 0,625 µs przy DShot600 potrzeba znacznie więcej niż kilku MS/s, aby dokładnie ocenić szerokość. Oscyloskop ujawnia analogową jakość, której cyfrowy analyzer nie pokazuje.

Do testu wartości throttle usuwa się śmigła. Najbezpieczniejszy etap mierzy przebieg przy odłączonym zasilaniu mocy ESC lub z kontrolowanym stanowiskiem, zachowując referencję logiczną zgodnie z hardware. Późniejsze testy silnika wymagają osłony, mocowania i zdalnego odłączenia energii.

Plan testów#

Encoder#

• wartości 0, 1, 47, 48, 2047 oraz 2048 jako błąd;
• telemetry bit 0/1;
• niezależne wektory checksum normalnego i bidirectional;
• kolejność MSB-first;
• T0/T1 dla każdego wariantu rate;
• trailer i idle;
• komendy specjalne tylko przez dozwolone API.

Timer/DMA#

• clock tree i wartości PSC/ARR/CCR;
• wszystkie kanały jednocześnie;
• konflikt stream/request z SPI, LED, SD i sensorami;
• double buffer pod maksymalnym obciążeniem CPU;
• DMA timeout, error interrupt i odzyskanie;
• wspólny start oraz maksymalny skew;
• reset w każdym punkcie transferu.

ESC i napęd#

• macierz ESC target/firmware/DShot rate;
• start z zerowych ramek i arming delay;
• throttle ramp bez śmigieł, następnie na osłoniętym stanowisku;
• minimum stabilnej komutacji;
• zmiana obciążenia, temperatura i napięcie baterii;
• timeout po zatrzymaniu ramek;
• błędny checksum i zakłócona ramka;
• komendy kierunku/beacon tylko w stanie bezpiecznym.

Bidirectional#

• response quality per silnik;
• guard time i przełączenie GPIO;
• eRPM kontra tachometr dla znanej liczby biegunów;
• brak/CRC/decode error jako osobne stany;
• DShot300 i 600;
• pełny rate PID i telemetry;
• zanik odpowiedzi jednego ESC bez utraty pozostałych;
• polityka RPM filter fallback.

EMC i system#

• pełna moc napędu i przetwornic;
• VTX/radio na wszystkich dopuszczonych mocach;
• wiązka docelowa i temperatura;
• log gyro spectrum, eRPM i decode errors;
• brownout FC/ESC i niezależne restarty;
• pre-arm z niezgodnym rate/telemetry;
• disarm/failsafe przy zawieszeniu pętli sterowania.

Typowe błędy#

Kryteria odbioru#

DShot poprawia deterministyczność interfejsu FC–ESC, ale jego bezpieczna implementacja jest systemem czasu rzeczywistego: encoder, timer, DMA, pin, firmware ESC, timeout i telemetria muszą zachowywać spójne terminy. Najbardziej użyteczny test nie kończy się na tym, że silnik się obraca — mierzy dokładną ramkę, odpowiedź, prędkość, błędy i reakcję na zatrzymanie danych.

Powiązane tematy#

• PWM w UAV
• Dobór ESC
• Silnik BLDC — budowa, komutacja i punkt pracy
• Harmonogram czasu rzeczywistego flight controllera
• Diagnostyka logów i wibracji
• EMI/EMC w kontrolerze lotu
• Flight controller — jak działa
• Betaflight — architektura i ścieżka startowa

Przypisy#

1. Betaflight, DShot — protocol and bidirectional implementation details, https://betaflight.com/docs/development/API/Dshot (dostęp: 15 sierpnia 2026).
2. Betaflight, DSHOT guide, https://betaflight.com/docs/wiki/guides/current/Dshot (dostęp: 15 sierpnia 2026).
3. Betaflight, DShot RPM Filtering, https://www.betaflight.com/docs/wiki/guides/current/DSHOT-RPM-Filtering (dostęp: 15 sierpnia 2026).
4. Betaflight, ESC Firmware, https://betaflight.com/docs/wiki/getting-started/hardware/esc-firmware (dostęp: 15 sierpnia 2026).
5. PX4, DShot ESCs, https://docs.px4.io/main/en/peripherals/dshot (dostęp: 15 sierpnia 2026).
6. AM32, MultiRotor ESC firmware, https://github.com/AlkaMotors/AM32-MultiRotor-ESC-firmware (dostęp: 15 sierpnia 2026).
7. STMicroelectronics, AN4776: General-purpose timer cookbook for STM32 microcontrollers, https://www.st.com/resource/en/application_note/an4776-generalpurpose-timer-cookbook-for-stm32-microcontrollers-stmicroelectronics.pdf (dostęp: 15 sierpnia 2026).

Powiązane tematy

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.Dobór ESCESC jako przekształtnik mocy i element pętli wykonawczej: marginesy prądowe, chłodzenie, desync, DShot oraz telemetria RPM.Silnik BLDC — budowa, komutacja i punkt pracyTechniczny opis silnika bezszczotkowego stosowanego w UAV: geometria stojana i wirnika, sześciostopniowa komutacja, stałe KV/Ke/Kt, straty, ograniczenia cieplne i diagnostyka.Harmonogram czasu rzeczywistego flight controlleraProjekt harmonogramu od data-ready IMU do wyjścia aktuatorów: okresy, deadline, worst-case execution time, priorytety, blokowanie, DMA i pomiary schedulability.Diagnostyka logów i wibracjiPraktyczny proces diagnostyczny: synchronizacja czasu, setpoint kontra measurement, widmo drgań, saturacja i rozróżnianie awarii mechanicznej od problemu regulatora.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.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.Betaflight — architektura i ścieżka startowaProfil techniczny Betaflight jako stosu dla wielowirnikowców sterowanych ręcznie: harmonogram pętli, sensory, regulatory, mikser i diagnostyka.

Źródła z centralnego rejestru

1. Betaflight: DShot API [dokumentacja]
2. Betaflight: DShot protocol guide [dokumentacja projektu]
3. Betaflight: DShot RPM Filtering [dokumentacja projektu]
4. Betaflight: ESC firmware and bidirectional DShot compatibility [dokumentacja projektu]
5. PX4 Guide: DShot ESCs [dokumentacja projektu]
6. AM32 MultiRotor ESC firmware [repozytorium open source]
7. STMicroelectronics AN4776: General-purpose timer cookbook for STM32 microcontrollers [nota aplikacyjna producenta]
8. Sumit Sharma, „Drone Development from Concept to Flight” [książka]