Wysłany: 07 Sie 09 09:50 Radiowa transmisja danych, czyli robot zdalnie sterowany
Radiowa transmisja danych, czyli robot zdalnie sterowany (Wstęp)
Artykuł ten powstanie w kilku częściach, prawdopodobnie czterech, ale nigdy nic nie wiadomo.
W kolejnych częściach planuję opisać różne możliwości bezprzewodowej transmisji danych między urządzeniami (np. robotami).
Od razu uprzedzam, nie będę się zajmował ani Wi-Fi, ani Bluetooth. Jeśli kogoś stać na drogie moduły, ma możliwość używania TCP/IP, ten artykuł może przeczytać tylko po to, aby zobaczyć jak wiele problemów go ominęło.
Moim celem jest znalezienie taniego modułu, za pomocą którego możliwe będzie przesyłanie informacji między układami.
Jako przykład zastosowania niech posłuży robot. Pewnie każdy wymyśli wiele ciekawszych zastosowań komunikacji radiowej. Moje pomysły to:
zdalne sterowanie robotem (proszę się nie śmiać, na początek zawsze coś)
zdalne debugowanie pracy robota – czasem się przydaje
zbieranie informacji, np. o otoczeniu robota
wymiana informacji między robotami
Wracając jednak na ziemię, wypada najpierw sprawdzić, co można kupić za rozsądną cenę.
Postanowiłem zastosować gotowe moduły RF, ich wybór podyktowany był ceną oraz dostępnością:
Pierwsza para modułów zapewnia tylko jednokierunkową komunikację (simpleks). Moduł HM-T868S jest nadajnikiem, HM-R868S to odbiornik. Nie ma możliwości przesyłania danych w przeciwnym kierunku. Jednak cena modułów sprawia, że rozwiązanie jest warte przemyślenia. Ceny z TME (www.tme.pl):
HM-T868S – 12,13zł
HM-R868S – 16,96zł
Dodatkowym atutem jest bardzo prosty interfejs sterowania modułami, ale o tym dalej.
Kolejnym kandydatem na idealny moduł jest RFM12B/868D. Jego cena (również TME) wynosi: 22,94 zł. Nieco więcej niż poprzednio, ale ten moduł może pracować zarówno jako nadajnik jak lub odbiornik.
Trzecim i ostatnim opisywanym modułem jest CC1000PP-433. Dostępny jest na stronie www.mikroprocesor.pl, a jego cena wynosi 46,36zł.
Platforma testowa
Aby przetestować moduły niezbędne nam będą co najmniej dwa urządzenia, które będą się ze sobą komunikować. Do testów wykorzystałem dwie identyczne płytki (zaprojektowane pod moduł CC1000PP-433, ale pozostałe powinno być łatwiej podłączyć).
Płytki testowe wyposażone są w procesor Atmega8L – wynika to z konieczności zasilania modułów napięciem 3.3V (szczegóły w dalszej części).
Każda z płytek posiada 3 switch-e oraz 3 diody. Najprostsza wersja sterowania to zapalanie diody po naciśnięciu przycisku (na przeciwnym układzie oczywiście).
Dodatkowo układy mają wyprowadzone piny od UART-a, więc istnieje możliwość podłączenia płytek do portu szeregowego komputera przez układ typu max232. Stosuję takie rozwiązanie, aby nieco zaoszczędzić, układ max232 mam na oddzielnej płytce, a testową traktuję jako jednorazową.
Radiowa transmisja danych, czyli robot zdalnie sterowany cz.2 (moduły HM-T868S i HM-R868S)
Testowany zestaw składa się z modułu nadajnika HM-T868S oraz odbiornika HM-R868S. Pierwszym zaskoczeniem jest wielkość modułów, są bardzo małe. W komplecie dostajemy do nich odpowiednio przycięte przewody, służące jako anteny.
Kolejne zaskoczenie do liczba wyprowadzeń - nadajnik ma tylko 3 piny, odbiornik 4. Piny są rozmieszczone standardowo, co 2,54mm, więc bez problemu można moduły wpiąć do płytki testowej.
Więcej informacji o modułach jest na stronie producenta: http://www.hoperf.com/
Piny nadajnika to: GND, DATA, VCC. Odbiornika: GND, DATA, VCC, ENABLE.
Rozszyfrowanie oznaczeń nie sprawia problemów, jednak lepiej zapoznać się z krótkim datasheetem ze strony producenta.
Moduły powinny być zasilane napięciem 3V, jednak mogą pracować do 5,4V, więc podłączenie do AVR-a nie sprawi problemu.
Pin ENABLE odbiornika pozwala na wyłączenie modułu, gdy nie jest używany. Podanie na nim napięcia VCC uruchamia odbiornik. Nadajnik sam wykrywa brak danych i przechodzi w tryb uśpienia.
Okazuje się, że moduł jest maksymalnie prosty w obsłudze. Nie zapewnia żadnego protokołu komunikacji, to co podamy na pin DATA nadajnika zostanie wysłane i pojawi się na pinie DATA odbiornika.
Prosty test polegający na podłączeniu generatora do nadajnika i oscyloskopu do odbiornika potwierdza taki właśnie sposób działania modułów.
Prędkość transmisji zalecana przez producenta to 4800bps, maksimum 9600, co w dzisiejszych czasach nie oszałamia. Przy częstotliwości w okolicach 10kHz widoczne jest zniekształcenie sygnału, więc lepiej nie liczyć na maksymalną prędkość transmisji.
Prostota obsługi modułów ma swoje wady. Trzeba samemu obsłużyć protokół transmisji. Ja postanowiłem wykorzystać sprzętowy UART procesoraś.
Nadajnik połączyłem więc do pinu TXD w płytce nadajnika, odbiornik do pinu RXD płytki odbiornika. Pozostało dodać podciąg pinu ENABLE w odbiorniku (niech pracuje cały czas, nie oszczędzam prądu podczas testów) i podłączyć zasilanie.
W datasheecie producent sugeruje, aby pin ENABLE był nieaktywny podczas podłączania zasilania i aktywowany później. Okazało się to o tyle istotne, że inaczej odbiornik nie zawsze „wstaje”. Problem nie był duży – wystarczy podłączyć ENABLE do pinu procesora i programowo wystawiać 1 chwilę po uruchomieniu układu.
W poprzedniej części opisałem z czego składają się moje płytki testowe, teraz zamieszczam więcej informacji o nich.
Na schemacie jest procesor Atmega8, jednak użyłem Atmega8L – ze względu na zasilanie z 3V (będzie niezbędne dla modułu CC1000, o tym później).
Gniazdo RS232 to wyprowadzenia UART-a wraz z zasilaniem, P1 i P2 to gniazdo do podłączenia CC1000. Poza tym jest oczywiście gniazdo programatora, 3 diody i 3 switche do sterowania układem oraz stabilizator 3.3V.
Do obecnych testów można użyć uproszczonej wersji układu, przede wszystkim można użyć Attiny, ale miałem akurat atmege8, więc wykorzystałem co było pod ręką. Obecne testy przeprowadzałem na 5V (stabilizatory zalutuję później), więc zasilanie też można uprościć.
Jedno o czym warto pamiętać to dodanie rezonatora. Ja używam rezonatorów 4MHz. Próbowałem najpierw działać bez nich, niestety układy nie mogły się komunikować poprawnie. Wystarczył upalny dzień i generator RC jednego z układów przestawił się na tyle, że dane po RS232 nie były poprawne. Rezonator zapewnia dużo większą dokładność zegarów.
Program testowy
Pierwszą czynnością jest konfiguracja modułu UART do pracy. Ustawiłem prędkość na 2400bps. Piny od przełączników ustawiane są jako wejścia, piny od diód jako wyjścia.
Pętla główna odczytuje stan przełączników, jeśli któryś zostanie przyciśnięty, wysyła kod przycisku. Kodowanie jest bardzo proste i bazuje na znakach:
'A' – wciśnięty przycisk 1, 'B' – przycisk 2, 'C' – przycisk 3
Moduł odbiornika działa na przerwaniu i po odebraniu bajtu steruje diodami.
'A' – zapala diodę 1, 'B' – 2, 'C' -3
Są też kody gaszenia diód:
'a' – gasi diodę 1, 'b' – 2, 'c' – 3
Zarówno płytka nadajnika jak i odbiornika pracują na tym samym programie. Do testów wystarczy założyć zworkę na piny RXD i TXD – wtedy moduł komunikuje się sam ze sobą, naciskanie przycisków zapala odpowiednie diody.
Moduły podłączyłem następująco:
Nadajnik
GND – do pinu 1 (GND) gniazda JP4 (RS232)
DATA – do pinu 2 (TXD) gniazda JP4 (RS232)
VCC – do pinu 4 (VDD) gniazda JP4 (RS232)
Odbiornik
GND – do pinu 1 (GND) gniazda JP4 (RS232)
DATA – do pinu 3 (RXD) gniazda JP4 (RS232)
VCC – do pinu 4 (VDD) gniazda JP4 (RS232)
ENABLE – podciąg rezystorem do pinu VCC
Po sprawdzeniu połączeń i podłączeniu zasilania spotkało mnie pierwsze rozczarowanie.
Odbiornik odbiera straszne ilości „śmieci”. Natomiast dane z nadajnika lubią się „gubić”.
Aby poprawić działanie układu zmieniłem program:
1)po naciśnięciu przycisku program cyklicznie wysyła kod zapalania diody
2)gdy przyciski są zwolnione ciągle wysyła kody gaszenia diód
Takie zmiany pomogły – program działa bardzo ładnie.
Niestety śmieci, nadal pojawiają się na odbiorniku. Należałoby dodać filtrowanie danych w odbiorniku, jednak na potrzeby sterowania diodami program działa bardzo ładnie.
Testy pozwalają na podsumowanie, jakie są plusy i minusy układu:
Zalety:
1)Niska cena
2)Prostota działania (nawet procesor nie jest niezbędny, można zrobić radiowy włącznik, czy czujnik bez procesora)
3)Łatwe podłączenie
4)Możliwa praca z 5V
Wady:
1)Brak jakiegokolwiek protokołu transmisji
2)Zaśmiecony sygnał na odbiorniku
3)Konieczność wielokrotnego wysłania danych
Podsumowując układ dobrze nadaje się dla początkujących elektroników, którzy nie chcą zajmować się programowaniem obsługi skomplikowanego układu. Za jego pomocą można łatwo wykonać układ zdalnego sterowania np. robota. Można też odczytywać stan czujników lub urządzeń, np. mierzyć temperaturę w innym pokoju.
Radiowa transmisja danych, czyli robot zdalnie sterowany cz.3 (moduł CC1000PP-433)
Kolejny testowany moduł oparty jest na układzie CC1000. Opisywany moduł oraz więcej informacji o nim dostępne jest pod adresem http://www.shop.kristech....products_id=93. Polecam również przeczytać informację o zestawie uruchomieniowym do modułu: http://www.shop.kristech....roducts_id=203.
Do testowania transmisji niezbędne są dwa moduły. Oba podłączone zostały do płytek opisywanych poprzednio. Jako anteny wystarczają przewody o długości 16 cm.
Moduły nie mogą być zasilane napięciem wyższym niż 3,6V więc do pracy ze zwykłym AVR konieczne jest zastosowanie konwerterów napięcia. Ja dla uproszczenia wykorzystałem procesor Atmega8L oraz zasilanie niższym napięciem.
Układ CC1000 komunikuje się z procesorem za pomocą, aż dwóch interfejsów. Pierwszy wykorzystuje 3 linie (PALE, PDATA, PCLK) i służy do konfiguracji pracy modułu. Drugi używa 2 linii (DIO, DCLK) i zapewnia przesył transmitowanych danych.
W sumie potrzebne jest aż 5 linii procesora, z tego jedna obsługująca przerwanie (producent podaje sposób podłączenia wykorzystując mniejszą liczbę linii, ale sam poleca używanie 5 linii).
Skomplikowane podłączenie okazało się jednak tylko początkiem problemów.
Prawdziwym wyzwaniem okazało się przygotowanie programu do sterowania modułami.
Pierwszy krok to skonfigurowanie modułów. Producent układów dostarcza specjalny program, który pozwala na ustalenie wartości rejestrów – jest ich około 30! Gotowy program jest niewątpliwie ułatwieniem, jednak na początku już sama liczba jego opcji jest przytłaczająca. Program konfiguracyjny dostępny jest pod adresem http://focus.ti.com/docs/...tm-studio.html.
Ja postanowiłem wykorzystać przykłady dołączone do modułu uruchomieniowego. Zostały przygotowane dla procesora PIC, jednak o wiele łatwiej było przenieść program na AVR niż pisać program zupełnie od nowa.
Konfiguracja modułów do pracy jest do tego stopnia skomplikowana, że w sieci znaleźć można strony osób piszących prace magisterskie o konfiguracji układu CC1000.
Kolejnym wyzwaniem jest obsługa protokołu transmisji danych między CC1000, a procesorem. Podczas niej układ CC1000 generuje sygnał zegarowy (na linii DCLK), a procesor działa niejako jako slave i wysyła lub odbiera dane (na linii DIO).
Takie działanie ma duże plusy, procesor nie musi zajmować się synchronizacją zegarów, jednak zastosowany schemat transmisji wymaga obsługi przerwania o wysokim priorytecie (trzeba „zdąrzyć” odebrać lub wysłać dane) .
Na tym nie kończą się zadania które musi spełniać oprogramowanie procesora.
Pierwszy problem, który trzeba rozwiązać to wykrycie początku danych przez odbiornik.
Wykonuje się to w ten sposób, że nadajnik nadaje najpierw ciąg bajtów o wartości 0x55, tzw. preambułę. Po nim nadaje bajt o ustalonej wartości, następnie pakiet danych.
Program obsługujący obiornik używa tzw. rejestru przesuwnego do odbierania danych. Jeśli wykryje kod 0x55 lub 0xAA (0x55 przesunięty o 1 w lewo) zaczyna zliczać długość odczytanej preambuły i oczekuje na bajt o ustalonej wartości. Dopiero po odebraniu preambuły o minimalnej długości i bajtu specjalnego odbiornik zaczyna odbierać pakiet danych.
Protokół transmisji powinien być wyposażony jeszcze w co najmniej 3 elementy. Jeśli pakiety mogą być różnej długości trzeba dodać długość danych. Warto dodać do pakietu adres odbiornika (jeśli chcemy używać więcej niż 2 modułów). Konieczne jest również dodanie sumy kontrolnej, ponieważ podczas transmisji zdarzają się przekłamania danych.
Wszystko razem daje całkiem skomplikowany program. Pisanie go nie jest zadaniem dla początkujących programistów. W rezultacie można dostać bardzo sprawnie działający układ, jednak jest to skomplikowane zadanie. I nie wystarczy jeden wieczór na oprogramowanie takiej transmisji.
Zalety:
1)Układ zapewnia wysoką jakość transmisji
2)Pozwala na transmisję o prędkości do 76.8kb/s
3)Obsługuje kodowania Manchester oraz NRZ
4)W przypadku kodowania Manchester zapewnia weryfikację zgodności zegarów
5)Umożliwia transmisję dłuższych danych (według informacji z sieci działa dobrze z pakietami od długości do 64 bajtów)
Wady:
1)Wymaga zasilania 3.3V, piny nie tolerują 5V
2)Interfejs wymaga wielu pinów oraz szybkiego przerwania
3)Obsługa programowa jest bardzo skomplikowana
4)Procesor musi zajmować się głównie obsługą komunikacji
Podsumowując CC1000 to bardzo dobry układ. Jednak nie nadaje się dla początkujących, ani nawet średnio zaawansowanych elektroników. Wymaga skomplikowanego programu, wiedzy o protokołach transmisji, umiejętności pisania zaawansowanych programów.
Jednym słowem układ prawie idealny, niestety bardzo skomplikowany.
Na szczęście dostępny jest nowszy układ tego samego producenta – CC1100.
Układ ten zapewnia komunikację po SPI z procesorem, a jednocześnie sam wykonuje wszystkie skomplikowane funkcje wymagane przez CC1000, czyli:
wykrywanie początku danych (generowanie preambuły)
* obsługę pakietów
* generowanie sum kontrolnych
* obsługę adresów
I wiele funkcji, które w CC1000 musi realizować procesor.
Dostępne są moduły z tym układem http://www.propox.com/products/t_202.html?lang=pl.
W kolejnych częściach postaram się opisać ten układ.
Radiowa transmisja danych, czyli robot zdalnie sterowany cz.4 (moduły RFM12B/868D)
Ostatnie z testowanych modułów to para RFM12B. Oba pracują na częstotliwości 868MHz. Wyższa częstotliwość zmniejsza nieco zasięg komunikacji, ale w zamian anteny mogą być dwa razy krótsze.
Moduły łączą się z procesorem za pomocą interfejsu SPI. Dzięki temu łatwo jest oprogramować komunikację, czy to z wykorzystaniem sprzętowego interfejsu, czy programowego.
Moduły RFM12B produkowane są przez tego samego producenta co HM-T868S. Dodatkowe informacje o modułach oraz przykładowe kody dostępnie są na stronie: http://www.hoperf.com/ .
Testowane moduły są zasilane napięciem 3.3V i nie mogą pracować bezpośrednio z układami 5V. Ja rozwiązałem problem stosując układ Atmega8L i zasilanie niższym napięciem. Producent podaje informacje o modułach RFM12 (bez B), które mogą współpracować bezpośrednio z napięciami 5V – nie wiem gdzie są dostępne, ale dopasowanie napięć to duży atut modułów.
Na stronie producenta podany jest przykładowe program do testowania modułów. Niestety proste przepisanie programów nic nie daje – po pierwsze konfiguracja w nich przewiduje częstotliwość 433MHz, po drugie w programie są błędy.
Po przeczytaniu dokumentacji i zmianie ustawień 868MHz oraz poprawieniu błędów mi udało się uruchomić program który:
wysyła co sekundę pakiet danych
odbiornik ciągle nasłuchuje, po odebraniu poprawnych danych zapala diodę
Transmisja przebiegała bez problemów. Testowałem pakiety o długości od 16 do 256 bajtów. Moduły wykonują całą nieprzyjemną robotę, którą w przypadku CC1000 trzeba było robić programowo, czyli:
sam wykrywa preambułę danych
znajduje początek danych i rozpoznaje bajty startu ramki
odbiera i w wysyła dane dostarczone przez SPI
Podsumowując, uważam moduły za bardzo udane. Obsługa jest o wiele łatwiejsze niż CC1000, są tylko nieznacznie droższe od prostych modułów HM-T868S, zapewniają dwukierunkową komunikację.
Jako jedyną dostrzeżoną wadę mogę wymienić zasilanie napięciem 3.3V. Jednak zmiana na RFM12 powinno rozwiązać tę niedogodność.
Na elektrodzie spotkałem się z negatywnymi opiniami o tych modułach, jednak z moich doświadczeń wynika, że moduły te są godne polecenia.
Podsumowanie artykułu
Moduły HM-T868S / HM-R868S – dobry wybór dla początkujących, przesył jedynie krótkich pakietów danych, transmisja jednokierunkowa. Dobry wybór, aby wykonać zdalne sterowanie, czy zdalny odczyt danych z czujnika.
Moduły z układem CC1000 – układy raczej dla profesjonalistów. Skomplikowana obsługa, wymagają wielu linii procesora, wiedzy o transmisji radiowej, zajmują dużo czasu i pamięci procesora. Poza tym są drogie.
Moduły RFM12B – bardzo dobry wybór, aby zbudować modem radiowy. Są tanie, a zarazem skuteczne. Pozwalają na transmisję nawet całkiem długich pakietów. Uwzględniając w protokole transmisji adresu urządzeń można zrealizować komunikację więcej niż dwóch urządzeń.
Nie wiem czy tu można pisać ale napisze ;]
Jeżeli dobrze rozumiem do komunikowania się między sobą wystarczy tylko zakupić HM-T868S i HM-R868S ? Mam nadzieje ze tak choć podczas czytania artykułu pojawił się cień wątpliwości;]
Moduły HM-T868S i HM-R868S wystarczą do jednokierunkowej komunikacji. Czyli dane wysyłane są przez moduł HM-T868S (T od transmitter), a odbierane przez HM-R868S (R od receiver).
W ten sposób można np. zdalnie sterować robotem, albo odczytywać dane z czujnika znajdującego się w robocie.
Nie ma natomiast możliwości transmisji dwukierunkowej.
Napisz, co dokładniej chcesz zrobić, może uda się coś doradzić
Posty: 428 Pomógł: 16 razy Piwa: 29/8 Skąd: Katowice
Programuję w: Bascom / C
Wysłany: 15 Lut 10 06:54
I możemy skutecznie zmniejszyć zasięg przez zakłócanie się naszych modułów. Musiałoby działać to w half-duplexie. Chcąc mieć full duplex trzeba by użyć dwóch par na różne częstotliwości (np 868 i 433)
Jakby co to mam program w C. W bascomie nie programuję, ale pewnie jest jeszcze łatwiej - wystarczy w module podłączonym do HM-T868S wysłać dane na uart, a w podłączonym do HM-R868S odczytać.
Nie możesz pisać nowych tematów Nie możesz odpowiadać w tematach Nie możesz zmieniać swoich postów Nie możesz usuwać swoich postów Nie możesz głosować w ankietach Nie możesz załączać plików na tym forum Możesz ściągać załączniki na tym forum
FAQ
Szukaj
Mapa
Użytkownicy
Regulamin
Grupy
Rejestracja
Zaloguj
