Protokół RC5 to jeden z najbardziej rozpowszechnionych standardów zdalnego sterowania IR w elektronice konsumenckiej.
Opracowany przez Philips w latach 80., wykorzystuje kodowanie manchesterskie i nośną 36 kHz do przesyłu 14‑bitowych ramek, które niosą adres urządzenia i polecenie.
Kodowanie manchesterskie wymusza przejście w środku każdego bitu, dzięki czemu odbiornik łatwo się synchronizuje i rekonstruuje dane nawet przy niedokładnych zegarach.
Historyczne pochodzenie i znaczenie protokołu RC5
RC5 powstał jako próba standaryzacji transmisji IR między urządzeniami różnych producentów. Nazwa „Remote Control 5” wskazuje na piąte podejście Philipsa do systemu zdalnego sterowania.
Standard szybko przyjął się w Europie, gdzie wielu producentów elektroniki wdrożyło go w pilotach i odbiornikach.
Uniwersalność i kompatybilność RC5 pozwoliły użytkownikom sterować wieloma urządzeniami jednym pilotem, co znacząco poprawiło doświadczenie obsługi.
Mimo nowszych rozwiązań (RC6, inne), RC5 pozostaje powszechny w starszych urządzeniach i wciąż trafia do wielu nowych produktów audio‑wideo.
Wybór częstotliwości 36 kHz był celowy: unika zakłóceń pochodzących od telewizorów CRT oraz sieci 50/60 Hz, a jednocześnie jest prosty do generowania i detekcji.
Architektura ramki protokołu RC5
Struktura logiczna 14-bitowej ramki
RC5 zawsze przesyła 14 bitów w stałej kolejności. Poniższa tabela porządkuje strukturę ramki i funkcje poszczególnych pól:
| Pole | Liczba bitów | Wartość/zakres | Rola |
|---|---|---|---|
| Start S1 | 1 | zwykle 1 | inicjalizacja i stabilizacja AGC odbiornika |
| Start S2 / Ext | 1 | zwykle 1 (w RC5X: rozszerzenie komendy) | drugi bit startowy lub rozszerzenie pola polecenia |
| Toggle (T) | 1 | 0/1 | odróżnia kolejne naciśnięcia od przytrzymania |
| Adres (A4..A0) | 5 | 0–31 | wybór grupy/typu urządzenia |
| Polecenie (C5..C0) | 6 | 0–63 | konkretna funkcja/akcja |
| Razem | 14 | — | pełna ramka RC5 |
Dla szybkiego przypomnienia kluczowych funkcji pól ramki:
- dwa bity startowe stabilizują tor odbiorczy i ustawiają AGC,
- bit przełączania toggle zmienia się przy każdym nowym naciśnięciu, pozostaje stały podczas przytrzymania,
- pole adresu wskazuje docelowy typ urządzenia w obrębie 32 grup,
- sześć bitów polecenia zapewnia 64 komendy na adres.
Podczas przytrzymania przycisku pilot wysyła kolejne identyczne ramki co ok. 114 ms, ale bit toggle nie zmienia się do momentu ponownego naciśnięcia.
Rozszerzony format RC5X
Kiedy 64 komendy okazały się niewystarczające, wprowadzono RC5X, w którym drugi bit startowy przenosi dodatkową informację o poleceniu (zanegowany bit D6).
RC5X podwaja pulę poleceń do 128 na urządzenie, zachowując zgodność wsteczną z odbiornikami obsługującymi standardowe RC5.
Kodowanie manchesterskie – fundament transmisji RC5
Zasady kodowania bifazowego
Każdy bit w RC5 ma czas trwania 1,778 ms i dzieli się na dwie połówki po 889 µs. Przejście w środku bitu koduje jego wartość: „1” to zbocze niskie→wysokie, „0” to wysokie→niskie.
Każdy bit zawiera przejście, więc sygnał jest samosynchronizujący i nie potrzebuje osobnego zegara.
W praktyce połowa bitu to impuls nośnej 36 kHz (burst), a druga połowa – przerwa, zgodnie z regułami Manchester.
Właściwości kodu Manchester w RC5
Najważniejsze zalety kodowania Manchester można streścić następująco:
- samoczynna synchronizacja – stałe przejścia w środku bitu dostrajają zegar odbiornika;
- brak składowej stałej – równy czas poziomów minimalizuje dryft i wrażliwość na DC;
- odporność amplitudowa – informacja przenoszona jest przez kierunek przejścia, nie przez amplitudę;
- deterministyczne granice bitów – ułatwiają separację półbitu i pełnego bitu w dekoderze.
Parametry czasowe i częstotliwości w RC5
Okres bitu i jego komponenty
Jednostkowe zależności czasowe wynikają bezpośrednio z nośnej 36 kHz i liczby cykli w półbicie.
Półbit trwa 32 cykle nośnej (ok. 889 µs), a pełny bit 64 cykle (ok. 1,778 ms).
Współczynnik wypełnienia nośnej wynosi zwykle 25%, co ogranicza pobór mocy diody IR i emisję ciepła.
Poniższa tabela podsumowuje kluczowe wartości czasowe i częstotliwościowe:
| Parametr | Wartość nominalna | Uwagi |
|---|---|---|
| Częstotliwość nośnej | 36 kHz | typowo dla RC5 (np. TSOP1736) |
| Okres cyklu nośnej | 27,778 µs | 1 / 36 000 |
| Półbit | 889 µs | 32 cykle nośnej |
| Bit | 1,778 ms | 64 cykle nośnej |
| Długość ramki (14 bitów) | 24,892 ms | 14 × 1,778 ms |
| Przerwa między ramkami (idle) | ~88,9 ms | ok. 50 bitów |
| Okres powtarzania | ~113,8 ms | ramka + idle (ok. 64 bity) |
| Duty cycle nośnej | ~25% | ~6,944 µs włączone na cykl |
W praktyce tolerancje dekoderów wynoszą zwykle ±10–15%, co zapewnia stabilną pracę mimo niedokładnych zegarów i opóźnień.
Częstotliwość nośna i modulacja
Częstotliwość nośna 36 kHz i jej zastosowanie
Transmisja polega na włączaniu/wyłączaniu nośnej 36 kHz zgodnie z kodem Manchester. Podczas „mark” dioda IR emituje światło modulowane, podczas „space” milczy.
Typowy odbiornik IR (np. TSOP1736, TSOP12xx) raportuje stan niski (0) przy odbiorze nośnej i stan wysoki (1) przy jej braku. Ten sygnał odwrócony należy uwzględnić w dekoderze.
36 kHz minimalizuje kolizje z zakłóceniami 50/60 Hz i harmonicznymi, a jednocześnie pozostaje łatwe do obsługi układowo.
Proces dekodowania sygnału RC5
Algorytmy dekodowania oparte na maszynach stanów
Najpewniejszym podejściem jest automat skończony, który klasyfikuje zdarzenia czasowe i prowadzi przez kolejne fazy dekodowania.
Typowy zestaw stanów można ująć następująco:
- start1 – oczekiwanie na pierwszy bit startowy,
- mid1 – przejście w połowie bitu 1 (1→0),
- mid0 – przejście w połowie bitu 0 (0→1),
- start0 – przejście między bitami (wyznaczenie granic).
Zdarzenia klasyfikuje się jako „krótkie” (~889 µs) lub „długie” (~1,778 ms); wszystko poza zakresem inicjuje reset automatu.
Poniżej przykład fragmentu automatu (C‑like) dla ilustrowania logiki przejść:
if (current_state == STATE_START1 && event == SHORT_SPACE) {
emit_bit(1);
current_state = STATE_MID1;
} else if (current_state == STATE_MID1 && event == SHORT_PULSE) {
emit_bit(0);
current_state = STATE_START0;
} else {
// Błąd – reset automatu
current_state = STATE_START1;
}
Synchronizacja czasowa w odbiorze
Resynchronizacja przy każdym zboczu ogranicza kumulację błędów pomiaru czasu. Zamiast mierzyć od początku ramki, dekoder analizuje interwały między kolejnymi przejściami.
Uśrednianie kilku pomiarów dodatkowo poprawia rozstrzyganie, czy zdarzenie odpowiada półbitowi czy całemu bitowi.
Sprzętowa i programowa implementacja dekodera RC5
Podejście sprzętowe z użyciem układów cyfrowych
Implementacja sprzętowa zwykle składa się z czterech bloków:
- detektora zboczy – generuje impuls przy każdej zmianie stanu na wyjściu odbiornika IR,
- licznika czasowego – mierzy interwały między zboczami (np. zasięg do ~3,5 ms),
- automatu sekwencyjnego – implementuje logikę RC5 i reguły tolerancji,
- rejestru przesuwnego – gromadzi i porządkuje odebrane bity do 14‑bitowej ramki.
Ustawienie progu rozróżnienia na ok. 3/4 bitu (~1,33 ms) ułatwia klasyfikację półbitu vs bitu.
W MCU (AVR, PIC) często stosuje się timery i przerwania okresowe do próbkowania i pomiaru czasów.
Implementacja oprogramowania w mikrokontrolerach
Najwygodniej podłączyć odbiornik IR do pinu z przerwaniami zewnętrznymi (zbocza narastające i opadające).
Timer konfiguruje się tak, by przerwanie wywoływane było co ok. 1/8 półbitu (~111 µs), co zwiększa precyzję pomiarów.
Procedura przerwania zapisuje stemple czasu i porównuje je, klasyfikując zdarzenia jako półbit (889 ± 200 µs) lub bit (1778 ± 200 µs), a odchyłki traktuje jako błąd.
Po zebraniu 14 bitów dekoder dzieli słowo na: starty, toggle, adres i polecenie, a następnie przekazuje wynik do logiki aplikacyjnej.
Adresowanie urządzeń i kody poleceń
Standardowe alokacje adresów RC5
RC5 definiuje 32 adresy (5 bitów), lecz globalnej, oficjalnej tabeli przypisań nie opublikowano. Praktyka wykształciła jednak pewne wzorce:
| Kategoria | Przykładowy adres | Uwagi |
|---|---|---|
| TV | 0–1 | najczęściej spotykane dla telewizorów |
| VCR | 5 | magnetowidy i rejestratory wideo |
| Audio | 16–30 | amplitunery, wzmacniacze, odtwarzacze |
| SAT/Tuner | 10–11 | różnice zależne od producenta |
| CD/Media | 20–23 | często w obrębie grupy audio |
Standardowe kody poleceń dla różnych typów urządzeń
Kody komend bywają dobrze udokumentowane. Poniższa tabela gromadzi często używane przykłady:
| Funkcja | Kod (dec) | Uwagi |
|---|---|---|
| Cyfry 0–9 | 0–9 | wybór kanału/pozycji |
| Głośniej | 16 | volume up |
| Ciszej | 17 | volume down |
| Wyciszenie | 12 | mute |
| Kanał + / − | 32 / 33 | channel up / down (typowo TV) |
| Play | 53 | VCR/odtwarzacze |
| Stop | 54 | VCR/odtwarzacze |
| Record | 55 | magnetowidy, rejestratory |
RC5X rozszerza pulę do 128 poleceń na pojedynczy adres, co jest kluczowe w rozbudowanych systemach AV i Smart TV.
Zaawansowane zagadnienia dekodowania RC5
Obsługa błędów i tolerancja czasowa
W praktyce dekodery stosują szerokie okna czasowe: „krótki” zwykle między ~444 a 1333 µs, „długi” między ~1334 a 2222 µs.
Szerokie tolerancje umożliwiają poprawne dekodowanie mimo błędów zegara, temperatury i opóźnień ISR.
Odróżnianie RC5 od innych protokołów podczerwieni
Identyfikację wspiera analiza czasowa. RC5 to stałe 14 bitów × 1,778 ms i cisza ~88,9 ms. NEC ma długi lead‑in (~9 ms), potem ~4,5 ms przerwy i kodowanie odległością (pulse‑distance). RC6 jest podobny do RC5 w części zasad, lecz ma inną strukturę nagłówków.
Porównanie RC5 z innymi protokołami podczerwieni
Dla szybkiego porównania najpopularniejszych protokołów IR warto zestawić ich kluczowe cechy:
| Protokół | Kodowanie | Długość ramki | Sygnał wstępny | Nośna (typowa) | Uwagi |
|---|---|---|---|---|---|
| RC5 | Manchester (bifazowe) | 14 bitów | brak długiego lead‑in | 36 kHz | tolerancyjny czasowo, toggle bit |
| NEC | pulse distance | 32 bity | ~9 ms + ~4,5 ms | 38 kHz | większa elastyczność, wrażliwszy na timing |
| RC6 | złożone (Manchester‑like) | zmienna | specyficzny nagłówek | 36–40 kHz | następca RC5, większe możliwości |
| SIRC (Sony) | pulse width | 12 bitów (warianty 15/20) | krótkie inicjalizacje | ~40 kHz | szybszy, skromniejsze adresowanie |
Praktyczne zastosowania i wdrażania
Transkodery RC5 i konwersja protokołów
Transkodery konwertujące RC5 ↔ inne formaty (np. SIRC) umożliwiają sterowanie urządzeń różnych marek jednym pilotem.
Typowa konstrukcja obejmuje odbiornik IR, MCU z wieloprotokołowym dekoderem, pamięć EEPROM z mapami konwersji oraz nadajnik IR.
Uniwersalne systemy sterowania domem
Moduł RC5 można zintegrować z systemem przez RS‑232, Ethernet lub Wi‑Fi. Mikrokontroler dekoduje adres/komendę i wyzwala akcje automatyki.
Zaawansowane metody testowania i diagnostyki
Pomiary oscyloskopowe sygnałów RC5
Oscyloskop ujawnia charakterystyczne „bursty” 36 kHz i przejścia w połowie bitów. Przy podstawie 500 µs/działkę dobrze widać półbity ~889 µs.
Wyjście odbiornika IR jest odwrócone względem emisji diody: obecność nośnej = „0”, brak nośnej = „1”.
Analizatory protokołu podczerwieni
Wiele przyrządów automatycznie dekoduje RC5 i prezentuje ramki (np. Address, Command, Toggle), co znacząco przyspiesza debugowanie i weryfikację.
Tolerancja i odporność na błędy
RC5 jest naturalnie odporny dzięki Manchester, resynchronizacji przy zboczach i szerokim tolerancjom.
Powtarzanie ramki co ok. 113,8 ms maskuje pojedyncze błędy transmisji i stabilizuje działanie w trudnych warunkach.
Wyzwania w implementacji i powszechne błędy
Problemy z zegarem i taktowaniem
Niedokładne oscylatory (np. ±5% przy 1 MHz) wprowadzają błędy rzędu kilkunastu mikrosekund. Lepszy zegar (kwarc) lub silna resynchronizacja na zboczach ogranicza wpływ dryfu.
Problemy z przerwaniami i priorytetami
Opóźnienia ISR przy półbicie ~889 µs bywają krytyczne. Pomaga wysoki priorytet przerwania lub sprzętowe pomiary (FPGA/układy logiczne).
Zagadnienia optyczne i elektromagnetyczne
Słaba dioda IR, światło słoneczne czy promienniki zwiększają szum. Warto odseparować odbiornik od źródeł zakłóceń i celować pilotem w okno odbiornika.
Przyszłość RC5 i ewolucja protokołów podczerwieni
Choć Wi‑Fi i Bluetooth oferują mniejsze opóźnienia i większą przepustowość, RC5 pozostaje ekonomicznym i niezawodnym wyborem dla prostych, tanich urządzeń AV.
Nowsze protokoły (np. RC6) bywają wdrażane równolegle, często z zachowaniem zgodności z RC5, co ułatwia migrację i serwis.