Przejdź do głównej zawartości

RaspberryPi: odbiór informacji lokalizacyjnych oraz aktualnego czasu z modułu bezprzewodowego GPS (Bluetooth).

Kolega na swoim blogu wspomniał parę dni temu o synchronizacji zegara RaspberryPi z sygnałem czasu przekazywanym przez satelity systemu GPS (http://guzik.net.pl/blog/2013/03/mobilne-raspberry-pi/). Wystarczyło :-)
Bawiąc się "Mailną" zapomniałem (no jak mogłem???) właśnie przekształcić ją w komputerek-nawigację, choć może to zbyt mocne określenie. Chodzi o to, żeby RaspberryPi przekonać do współpracy z bezprzewodowym modułem GPS Nokia LD-3W. Z takiej współpracy mogą wyniknąć dwie korzyści (co najmniej):
  • ciągle aktualizowany odczyt informacji o lokalizacji;
  • synchronizacja zegara "Maliny" z czasem satelitarnym (poprzez ntp; RaspberryPi nie ma RTC z podtrzymaniem bateryjnym - jeśli ktoś chce, to kolega, będący autorem linkowanego wyżej bloga, opisał pokrótce, jak dodać taki sprzętowy zegar).
Mając współrzędne i masę innych, ciekawych informacji dotyczących położenia, puszczając wodze fantazji i dodając odrobinę kreatywności, można wręcz stworzyć sobie całkiem niezły komputer nawigacyjny (tym razem już nie przesadzam!). Kto wie, być może spróbuję podziałać w tym kierunku?
W każdym razie musimy zacząć od zgrania ze sobą RaspberryPi i LD-3W. Przede wszystkim musimy - oprócz modułu GPS - zaopatrzyć się w jakiś w miarę dobry "dongiel" Bluetooth na USB. Dlaczego ważna jest jakość i jak ją ocenić... Może po prostu zasugerujmy się źródłem (miejscem zakupu) i ceną. Problem jest właśnie w tym, że wiele modułów Bluetooth niezbyt jest elastycznych jeśli chodzi o pracę w dosyć skomplikowanych warunkach (bo będziemy czytać dane o lokalizacji i informacje o czasie, a to dla jednego z moich dongli, aukcyjnego, za parę złotych nabytego, okazało się ponad jego siły).
Dongla podłączamy do uruchomionej wcześniej "Mailny", mając na pokładzie jak najświeższą wersję Raspbiana. Najpierw sprawdzamy jednak, czy został zauważony przez system. Powinniśmy zobaczyć na liście nasze urządzenie - oczywiście rozpoznamy je po nazwie i z ogromną przyjemnością zauważymy informacje o trybie HCI:


Teraz musimy Raspbiana zaopatrzyć w oprogramowanie, które będzie nam niezbędnie potrzebne. O ile pakiet ntp jest najprawdopodobniej zainstalowany, to o resztę musimy zadbać sami. Doinstalujmy więc bluez (i pewnie od razu otrzymamy informację, że cała reszta narzędzi do obsługi Bluetooth zostanie dołożona; jeśli nie, to oczywiście wyszukujemy w np. aptitude wszystkie niezbędne składniki i doinstalowujemy), gpsd, gpsd-clients i python-gps (reszta pójdzie z automatu).
Mając wszystkie komponenty programowe w gotowości, zaczynamy właściwą zabawę. W sumie nie ma się co tutaj rozwodzić, ot po prostu:

  1. Sprawdzamy adres MAC naszego urządzenia:

    hcitool dev

  2. Wyszukujemy moduł GPS (musimy go włączyć i umieścić w zasięgu "Maliny", czyli maksymalnie do 10 metrów):

    hcitool scan

  3. Komenda z punktu 2. poda nam też nazwę urządzenia, więc bez problemu rozpoznamy nasz moduł GPS spośród wielu pozostających w zasięgu urządzeń. Mając adres MAC modułu GPS możemy sprawdzić, jakie usługi udostępnia, przede wszystkim zaś sprawdzić port BT, na którym moduł udostępnia łącze szeregowe (klasyczny RS):

    sdptool browse 11:22:33:44:55:66

    gdzie 11:22:itd. to adres MAC GPS-a.
    Niestety, w przypadku mojego modułu LD-3W komenda ta nie zwróciła żadnej informacji, dlatego też przyjąłem, że łącze szeregowe jest dostępne na porcie 1 (ok, wziąłem to z doświadczenia, które zdobyłem bawiąc się pisaniem programu pokazującego moje położenie na mapie...).
  4. Numer portu, jak również adres MAC i nazwa modułu przydadzą się nam podczas edycji pliku

    /etc/bluetooth/rfcomm.conf

    - musimy też zdecydować, czy port szeregowy dla urządzenia BT będzie tworzony manualnie, czy też automatycznie przy starcie systemu.
    Nie podaję tutaj przykładu konfiguracji - plik ten zawiera domyślne wartości z obszernymi wyjaśnieniami; wystarczy dosłownie wpisać w odpowiednie miejsca trzy wspomniane rzeczy, żeby wszystko elegancko hulało.
  5. Teraz rzecz chyba najważniejsza, czyli sparowanie ze sobą "Maliny" i modułu GPS. Po wpisaniu tych komend (tutaj trzeba sobie podwyższyć uprawnienia jeśli nie pracujemy na koncie roota):

    bluez-test-adapter discoverable on
    bluez-simple-agent hci0 11:22:33:44:55:66


    najpierw uczynimy naszą "Malinę" widoczną w przestrzeni Bluetooth, a następnie zostaniemy poproszeni o podanie PIN-u w celu uzyskania dostępu do modułu GPS. W przypadku mojej Nokii są to cztery zera, ale bywa różnie (RTFM!!!).
    11:22:itd. - to adres MAC modułu.
    Pamiętać należy, że po zmianie dongla Bluetooth, parowanie trzeba powtórzyć.
  6. Tworzymy port szeregowy do komunikacji z modułem:

    rfcomm bind rfcomm0

  7. ...i jeśli nic dziwnego się nam nie przytrafiło, to za pomocą klasycznej komendy testującej:

    cat /dev/rfcomm0

    możemy już pobierać dane z GPS w formacie NMEA (czyli średnio dla nas czytelne).
  8. Za pomocą polecenia:

    dpkg-reconfigure gpsd

    konfigurujemy demona gpsd, podając mu wspomniany w pkt. 7. port szeregowy jako źródło danych GPS oraz - dla potrzeb ntp - ekstra parametr "-n"; reszta propozycji konfiguracyjnych kreatora zostaje bez zmian.
  9. Zaglądając w manuala gpsd:

    man gpsd

    dowiadujemy się, jaki linie dopisać do pliku:

    /etc/ntp.conf

  10. Po tych zmianach przestrzeliwujemy demona gpsd, a następnie ntp. 
Wszystko powinno zacząć pięknie działać - czyli odczyty czasu:


oraz współrzędnych (i wielu innych, ciekawych informacji) - tutaj efekt komendy cgps -s:


Podsumowując zatem...


Okazuje się, że pogodzenie ze sobą RaspberryPi i bezprzewodowego modułu GPS nie jest specjalnie ciężkim wyzwaniem. Jak wspomniałem na wstępie, warto zainwestować w dobrej jakości dongla GPS.
Niestety, jest jeszcze jedna strona medalu... Otóż wszystko pięknie działa, jednak próba rebootowania "Maliny", czy wyłączenia, kończy się efektem "kernel panic" powodowanym przez podsystem Bluetooth (trzeba restartować wyłączając zasilanie - może da się z klawiatury, ale ja pracuję via ssh). Zresztą podobny efekt uzyskać można wyciągając dongla BT z gniazdka USB. Być może jest to problem używanych przeze mnie dongli (trzy różne egzemplarze, tylko przy jednym - tym dziadowskim - kilka razy mi się system nie sypnął), a być może kwestia zasilania urządzeń USB przez "Malinę", albo problem jądra systemu. W każdym razie da się to obejść ubijając ręcznie, przed restartem lub zatrzymaniem systemu, po kolei ntp, gpsd i bluetooth.

Zachęcam do eksperymentów i dzielenia się doświadczeniami :)

A, i jeszcze jedno: proszę pamiętać, że Bluetooth to "blutuf", nie "blutacz" ;D

Komentarze

Popularne posty z tego bloga

Niesamowicie prosty czujnik zmierzchowy.

Tym razem zero programowania, będzie natomiast nostalgiczno-wspomnieniowy układzik, lekko zmodyfikowany. Otóż kilka dni temu rozmawialiśmy w gronie znajomych o różnego rodzaju czujnikach zmierzchowych i czujnikach ruchu. Ponieważ należę do tych wariatów, co to hołdują jeszcze owej przestarzałej i kompletnie odrealnionej dziś zasadzie: "po co kupować, gdy można zrobić", stwierdziłem, że poskładam takie coś (czujnik zmierzchowy; sensor ruchu faktycznie lepiej nabyć, choćby ze względu na rozmiary ;)) i być może podłączę do jakiegoś mikrokontrolera. Przypomniało mi się też przy okazji, że znalazłem ostatnio w elektronicznych śmieciach stary fotorezystor (dla niewtajemniczonych: element zmieniający rezystancję, czyli opór elektryczny, pod wpływem działania strumienia światła) RPP130, jeden z kilku pozostałych po montowanych wieki temu układach tranzystorowych do zdalnego sterowania pracą urządzeń za pomocą latarki... No OK, nie było to specjalnie rozbudowane zdalne sterowanie ;)

Płytka prototypowa na bazie ESP8266 (ESP-01)

To nie jest kolejny artykuł traktujący od początku do... nieco dalej (bo na pewno nie do końca) o płytkach ESP8266 . Żeby się dowiedzieć, co to takiego, odwiedźcie proszę np. tę stronę (oraz wiele innych – poproście o pomoc Waszą ulubioną wyszukiwarkę): http://www.esp8266.com/wiki/doku.php?id=esp8266-module-family . No ale żeby nie było, ESP8266 to układ zawierający na pokładzie wydajny mikrokontroler z rdzeniem RISC-owym, taktowany zegarem 40MHz (wersja, o której jest ten wpis) lub 80MHz, 512KB pamięci flash i podsystem komunikacji przez sieć WiFi . Jest powszechnie wykorzystywany jako swego rodzaju karta sieciowa do połączeń bezprzewodowych naszych urządzeń IoT , które budujemy w zaciszu domowych laboratoriów (i nie tylko). Układ montowany jest na płytkach występujących w kilku wersjach, różniących się przede wszystkim liczbą wyprowadzeń uniwersalnych, czyli GPIO – im większa liczba, tym większe możliwości wykorzystania układu (więcej urządzeń peryferyjnych itp.). Są też pewne

Programowanie AVR cz.8: Przetwornik analogowo-cyfrowy oraz modulacja szerokości impulsu.

Dziś kolejny wgląd w wyposażenie mikrokontrolera ATmega48P - tym razem przyglądamy się wbudowanemu w układ przetwornikowi analogowo-cyfrowemu oraz - dostępnej również w modelach ATtiny - modulacji szerokości impulsu realizowanej przez timery. Artykuł ten jest w pewnym sensie wstępem do następnego, który pojawi się już wkrótce, a którego tematykę zdradziłem na końcu. Przetwornik A-C (skrót spotykany w anglojęzycznej literaturze to ADC od Analog to Digital Converter ) to układ pozwalający na zamianę wartości napięcia (elektrycznego sygnału analogowego ;-)) na liczbę. W przypadku mojej ATmegi przetwornik ma rozdzielczość 10-bitową, co oznacza, że wartość napięcia podawanego na wejście przetwornika może być po konwersji zapisana jako liczba z przedziału od 0 do 1023 (musimy użyć zmiennej word do zapamiętania tej liczby). Jeśli jesteśmy w posiadaniu mikrokontrolera w obudowie PDIP 28-wyprowadzeniowej, to mamy do dyspozycji sześć kanałów (niezależnych wejść) przetwornika A-C, przyporzą