Podczerwień: RC-5 - Dekodowanie sygnału

Autor: Dondu

Artykuł jest częścią cyklu: Podczerwień - Transmisja danych

Poznałeś już zasady dot. nadawania w podczerwieni w standardzie RC-5, czas więc poznać zasady dot. dekodowania sygnału odebranego z odbiornika podczerwieni.

Aby zrozumieć niniejszy artykuł powinieneś znać i rozumieć treść artykułu: RC-5 - Opis standardu

Jak dekodować sygnał standardu RC-5?

Na początku przypomnijmy sobie wygląd ramki nadawczej standardu RC-5:

Wyk. 1 - Przykład ramki nadawczej.

oraz informację podaną w art. wymienionym powyżej:

Ramka odbiorcza widziana przez mikrokontroler jest negacją powyższej ramki.

Skoro jest zanegowana, to wygląda tak:

Wyk. 2 - Ramka z wyk. 1 widziana na wyjściu odbiornika (wejściu mikrokontrolera). 

W ramce nadawczej (wykres nr 1) zaznaczone są  czarne pola , o których pisałem w poprzednim artykule. Jest to fala nośna o częstotliwości 36kHz. Gdyby wykres był narysowany w powiększeniu zobaczyłbyś tę falę.

Dlaczego w ramce odbiorczej  (wykres nr 2) nie widać fali nośnej, tylko ładny prostokątny sygnał?

Odbiornik, który używamy do odbioru sygnału podczerwieni, wykonuje za nas kolosalną pracę związaną z filtrowaniem sygnału z większości zakłóceń przy okazji zamieniając falę nośną na przebieg prostokątny.

W praktyce wygląda to tak:

Obróbka sygnału przez odbiornik podczerwieni.
Źródło: www.sbprojects.com

Na powyższej animacji ładnie widać negację sygnału oraz jego filtrowanie z fali nośnej. Nie sugeruj się ilością impulsów na powyższej animacji ponieważ nie jest ona zgodna ze standardem RC-5.

Gdybyśmy nie wykorzystywali scalonego odbiornika podczerwieni, a jedynie sam fototranzystor itp., to układ nasz musiałby wykonać właśnie takie przekształcenie pozbywając się przy okazji zakłóceń z różnych źródeł światła w tym dziennego i fluorescencyjnego. To nie jest proste i dlatego odbiorniki nieco kosztują.

---

Dekodowanie

Na początku przypomnimy sobie kilka istotnych informacji z poprzedniego artykułu:

W sygnale wyjściowym Manchester czas trwania zera lub jedynki:

• nigdy nie jest dłuższy niż czas trwania transmisji jednego bitu,
• nigdy nie jest krótszy niż połowa czasu trwania transmisji jednego bitu.

oraz dwie zasady:

Kodowanie Manchester - Zasada nr 1

Kodowanie Manchester - Zasada nr 2

Powyższe wykresy pokazują sygnał nadawany. Pamiętaj, że po stronie wyjścia odbiornika (czyli wejścia mikrokontrolera) otrzymujemy sygnał zanegowany.

---

Synchronizacja

Zanim pojawi się pierwsze zbocze sygnału, może trwać przerwa w nadawaniu dowolną ilość czasu:

Nasuwa się więc pytanie: Skąd mamy wiedzieć, że właśnie rozpoczął się pierwszy bit startu, skoro pierwsze zbocze opadające jest już w jego połowie?

Musimy więc przyjąć pewne zasady, które pozwolą nam zsynchronizować się z odbieranym sygnałem.

Standard RC-5 zawiera w sobie sygnał zegarowy synchronizujący transmisję, o czym pisałem w poprzednim artykule. Musimy jakoś ten sygnał odzyskać z odebranego sygnału z odbiornika. Jak to zrobić?

Popatrzmy na zasadę nr 2 pokazaną wyżej. Zasada ta, pozwoli nam wykorzystać do zsynchronizowania się z sygnałem.

Jak to odczytać?
Zauważ, że niektóre zmiany stanu sygnału (zbocza) występują na początku (końcu) bitu,

 a niektóre w jego połowie

Na szczęście wiemy, że z podstawowych założeń standardu RC-5 da się obliczyć (patrz poprzedni artykuł) czas trwania bitu oraz połowy bitu i wynoszą odpowiednio:

Stąd już prosta droga do synchronizacji pod warunkiem, że dokładnie w momencie wystąpienia każdego zbocza będziemy o tym wiedzieli. Potrzebujemy więc funkcji mikrokontrolera, która pozwoli nam na natychmiastową reakcję w momencie wystąpienia zbocza.

Wniosek 1:
Potrzebne nam są przerwania.

No dobrze, wiemy już że potrzebne są nam przerwania, ale odstępy między zboczami trwają 1778µs lub 889µs i w dodatku czasami zaczynają się w połowie bitu, a czasami na jego początku:

Co gorsza w pobliżu może nadawać inny pilot RC-5 i przerwania mogą się nałożyć skracając czasy ich wystąpienia. Może także nadawać inny pilot w innym niż RC-5 standardzie i możemy otrzymać z niego jeszcze inne czasy pomiędzy zboczami.

Jak to ogarnąć? Trzeba jakoś mierzyć te czasy.

Wniosek 2:
Potrzebny nam sprzętowy licznik czasu.

Podsumowując, jeżeli w momencie wystąpienia zbocza otrzymamy przerwanie, to istotnym dla nas będzie fakt, ile czasu upłynęło od poprzedniego przerwania, i że mogą wystąpić następujące przypadki:

1. czas bliski 1778µs,
2. czas bliski 889µs
3. czasy znacznie krótsze lub znacznie dłuższe od 2 i 3.

Popatrzmy jak przebiegałoby to na przykładzie naszej ramki. Moglibyśmy liczyć czas łączny od pierwszego zbocza opadającego:

Niestety, ale:

W algorytmie sumującym czasy od pierwszego zbocza opadającego bardzo szybko doprowadzimy do rozsynchronizowania się odbioru z nadawanym sygnałem.

Dlaczego tak się stanie?

Dlatego, że błędy w odmierzaniu czasów przez nadajnik (nie są przecież idealne) oraz odbiornik (np. nasze przerwanie wystąpiło w momencie obsługi innego i musi chwilkę zaczekać, niedokładność zegara, zmiana temperatury, itp.) są sumowane, przez co pod koniec odbioru ramki może znacznie zwiększyć się błąd sumaryczny, co w konsekwencji może prowadzić do utraty synchronizacji.

Innymi słowy patrząc na przykładowy wykres czasów sumarycznych (powyżej) zbocze, które według czasu nadajnika powinno wystąpić w okolicach 21.336µs, otrzymasz według odbiornika np. w 24.000µs. Nadajnik wysłał je więc jako połowa bitu 14, a odbiornik odbierze je jako koniec bitu 14 i w konsekwencji mamy błąd transmisji.

Co więc należy zrobić?

Wniosek 3:
Wykorzystać właściwości kodu Manchester i synchronizować się z każdym wykrytym zboczem sygnału.

Jak to zrobić?

Skoro z powodu możliwości rozsynchronizowania się odbioru nie możemy sumować czasu od pierwszego przerwania, to musimy zastąpić je pomiarem czasu od ostatniego przerwania:

oraz zliczać odebrane połowy bitów i całe bity. W ten sposób będziemy mogli dokładnie określić, w którym miejscu ramki odbiorczej w danym momencie (obsługiwanym przerwaniu od zbocza) jesteśmy.

Wniosek 4:
Potrzebne nam są programowe liczniki (zmienne) bitów i półbitów.

Podsumowując uchwycimy już każde zbocze sygnału i będziemy znali czas od poprzedniego zbocza, a mając w zmiennych licznik bitów i półbitów, nie rozsynchronizujemy się z nadawanym sygnałem.

---

Wartość bitu

Jak z sygnału wyciągnąć informację o tym, czy przesyłany bit jest jedynką, czy zerem?

Zasada nr 1 mówi, iż na początku bitu jego stan odpowiada jego wartości, wystarczyłoby więc odczytać stan pinu w momencie początku bitu. Nie zawsze jednak mamy przerwanie w momencie, gdy bit się rozpoczyna i w tym momencie przychodzi nam z pomocą zasada nr 2, czyli zmiana stanu bitu (wystąpienie zbocza) zawsze w połowie bitu:

W tym momencie powinniśmy więc określać wartość bitu.

Jak to zrobić? Przypomnijmy sobie, jak reprezentowane są bity od strony nadawania:

Sygnał wychodzący z pilota RC-5 dla logicznego zera oraz jedynki
Źródło: www.sbprojects.com

a pamiętając o zanegowaniu i filtracji fali nośnej przez odbiornik otrzymujemy po stronie wyjścia z odbiornika (np. podłączonego do pinu wejściowego mikrokontrolera):

Sygnał wychodzący z odbiornika podczerwieni
dla logicznego zera oraz jedynki.

Podsumowując:

Wniosek 5:
Gdy w sygnale wychodzącym z odbiornika w połowie bitu:

• występuje zbocze opadające, to bit ma wartość jeden,
• występuje zbocze narastające, to bit ma wartość zero.

---

Początek odbioru

Szczególnym przypadkiem jest początek dekodowania sygnału (pierwszy bit startu), gdy mamy bliżej nieokreślony czas w przerwie nadawania. Może on być strasznie długi, ale może być także niewiele dłuższy niż czas przesyłania jednego bitu, czyli 1778µs.

Niestety standard RC-5 nie określa parametru minimalnego czasu trwania ciszy przed pierwszym bitem startu.

Jak z tego wybrnąć?

Jednym z założeń standardu RC-5 jest fakt, że pilot dla przytrzymanego dłużej przycisku wysyła kolejne ramki co 114ms. To już daje nam pojęcie o tym, że nasz algorytm powinien czas przerwy nadawania przed pierwszym bitem startowym rozpoznawać jako nie dłuższy niż 114ms.

Czas przerwy oczywiście może być dłuższy i będzie takowy wtedy, gdy nie naciskamy przycisku. Istotne jest dla nas jednak to, że nasz algorytm nie może przyjmować, że przerwa musi mieć np. 200ms, bo nie będziemy w stanie odebrać kolejnych ramek wysyłanych przez pilota, gdy przez dłuższy czas jest naciśnięty przycisk.

No dobrze - mamy więc przedział czasu pomiędzy: 1778µs, a 114ms.

Przedział jest duży - jaki czas mam wybrać?

Super byłoby, gdybyśmy przyjmowali minimalny czas ciszy przed pierwszym bitem startu np. około 100ms. Jednakże tutaj trzeba brać pod uwagę, że piloty nie są super dokładnymi urządzeniami i w większości przypadków nie posiadają kwarców, które zapewniły, by im dużą dokładność utrzymania czasów wysyłanego sygnału. Podobnie z odbiornikiem - nie zawsze mikrokontroler korzysta z kwarcu.

Dlatego przyjęcie bezpiecznego progu np. 50ms, jest bardzo korzystne z punktu niezawodności pilota. Masz wtedy większą pewność, że pilot innego standardu nie zakłóci Twojej transmisji.

Ale jeżeli chcesz zaryzykować, możesz oczywiście przyjąć, że czas ciszy przed pierwszym bitem startu (zbocze opadające) jest niewiele dłuższy niż czas jednego bitu.

Pamiętaj jednak, że czas ten powinien być:

czyli:

Wniosek 6:
Algorytm odbiorczy powinien sprawdzać okres przerwy w sygnale przed pierwszym bitem startu przyjmując, że czas ten powinien być znacznie dłuższy od 1778µs, ale krótszy niż 114ms.

---

Odbiór poszczególnych bitów

W zasadzie wszystko w tej materii opisałem powyżej, więc tutaj wypunktuję, że:

• pilnujemy każdego zbocza poprzez przerwanie,
• odmierzamy czas od poprzedniego przerwania,
• ustalamy kiedy jest połowa bitu,
• w połowie bitu ustalamy jego wartość na podstawie kierunku zbocza sygnału,
• zapisujemy wartość bitu w zmiennej.

W tym miejscu należy zauważyć pewien wyjątek, który będzie miał wpływ na algorytm dekodowania sygnału w standardzie RC-5. Przyglądnij się tym fragmentom wykresu, gdzie czas pomiędzy zboczami równy jest 1778µs:

Czy widzisz pewną zależność?

Wniosek 7:
Jeżeli czas pomiędzy aktualnym i poprzednim przerwaniem wynosi 1778µs, to jesteśmy aktualnie w połowie bitu.

Takiej zależności nie ma w przypadku półbitów.

---

Koniec odbioru

Tutaj nie ma większych problemów.

Aby zakończyć odbiór korzystamy z jednego z założeń standardu RC-5, które mówi, że długość ramki ma 14 bitów:

Wniosek 8:
Aby zakończyć odbiór ramki danych, powinniśmy zliczać bity i zakończyć odbiór niezależnie od tego, czy sygnał nadal występuje, czy też nie.

Czy w takim układzie nie powstaje problem, że odczytamy fragment sygnału, który faktycznie pochodzi z pilota o innym standardzie?

Teoretycznie taka możliwość istnieje. Jednakże zabezpiecza nas przed tym:

• po części częstotliwość fali nośnej (różna dla różnych standardów),
• różne czasy pomiędzy zboczami

Tutaj możesz zobaczyć porównanie różnych standardów: 

Zestawienie parametrów różnych standardów
transmisji w podczerwieni.

Jest teoretycznie możliwy przypadek, w którym problem odczytania fragmentu sygnału pochodzącego z innego pilota wystąpi. Tym przypadkiem jest wykorzystanie standardu RC-5 do transmisji ramek dłuższych niż 14 bitów.

Nic nie stoi bowiem na przeszkodzie, by ktoś działający w zasięgu Twojego odbiornika opracował własny standard transmisji oparty o RC-5, ale zawierający np. 20 bitów. Niestety standard RC-5 nie zawiera żadnych zabezpieczeń w postaci np. bitu parzystości.

Aby zabezpieczyć się przed takim przypadkiem powinno się sprawdzać ciszę w sygnale po zakończeniu ostatniego 14-go bitu. Cisza ta powinna być znacznie dłuższa niż cały bit, czyli 1778µs. Niemniej jednak taki problem możesz spotkać co najwyżej na zawodach robotów :-)

---

Tolerancja

W niniejszym artykule zwracałem uwagę na fakt, iż zarówno nadajnik (pilot) jak i odbiornik nie są urządzeniami idealnymi. W szczególności dotyczy to pilotów, które często z powodu redukcji kosztów nie wykorzystują kwarców, co bezpośrednio wpływa na niedokładność odmierzania czasów w trakcie nadawania. Zmieniająca się temperatura, także ma istotny wpływ na końcowy efekt w postaci sygnału pilota. Podobnie w przypadku urządzeń odbiorczych, które także nie są idealne i podlegają tym samym problemom co pilot.

Co więcej pilot może na przykład skracać nieco czasy, a urządzenie odbiorcze oczekiwać dłuższych niż zgodne ze standardem. W ten sposób sumaryczny błąd się powiększa przez co łatwiej o błędy transmisji.

Jak temu zapobiec?

Należy wprowadzić parametr tolerancji, który będzie określał margines (+ i -) dla każdego bitu lub półbitu. W tak prosty sposób można uniknąć problemów z niepoprawnymi transmisjami.

Innymi słowy jeżeli przyjmiemy tolerancję np 250µs dla całego bitu, to nasz program dekodujący powinien rozpoznawać czas bitu (który standardowo trwa 1778µs) jako należący do przedziału:

a dla półbitu (standardowo 889µs):

Jeżeli tolerancja będzie zbyt duża, to czasy bitu i półbitu będą nachodzić na siebie, co uniemożliwi dekodowanie sygnału.

Dlatego program powinien wyłapać taką sytuację już na etapie kompilacji programu i zasygnalizować ją w postaci błędu lub co najmniej ostrzeżenia (warning).

Nie rozumiesz czegoś? Masz wątpliwości?

Nie wahaj się pytać za pomocą systemu komentarzy do artykułu.