Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Rozproszony system zbierania danych ZigBee

bryku13 12 Maj 2013 10:30 15222 20
  • Rozproszony system zbierania danych ZigBee
    Chciałbym przedstawić mój projekt bezprzewodowego systemu zbierania danych. Mój system jest kompatybilny z standardami IEEE 802.15.4, ZigBee i USB.
    W skład systemu wchodzą trzy moduły: moduł master oraz dwa moduły slave.
    Master systemu zarządza siecią bezprzewodową oraz komunikuje się z komputerem PC poprzez USB2.0 w klasie HID. Na komputerze uruchomiona jest aplikacja sterująca, która wyświetla otrzymane radiowo z modułów slave, dodatkowo wyświetla stan łączności w sieci oraz ma możliwość rejestracji pomiarów do pliku ".csv".
    Aplikacja sterująca wizualizuje dane pomiarowe odebrane od modułów oddalonych. Pomiary analogowe są przedstawione w postaci bargrafów.
    Dodatkowo zwizualizowana jest jakość połączenia radiowego oraz staus komunikacji z modułami slave. Użytkownik ma możliwość
    włączenia pomiarów w trybie on-line. Możliwe jest także sterowanie czterema wyjściami binarnymi w każdym module slave.
    Aplikacja sterująca napisana została w języku programowania C#. Jest kompatybilna z .NET Framework 3.5.

    Rozproszony system zbierania danych ZigBee

    Moduł master:

    Master systemu pełni rolę PAN Coordinator-a sieci bezprzewodowej. Komunikuje sie również poprzez USB2.0 z komputerem PC.
    Master systemu rozpoznawany jest przez komputer PC jako urządzenie klasy HID. Moduł zasilany jest z portu USB.
    W skład modułu mastera wchodzą mikrokontroler i moduł radiowy. Watchdog timer ustawiony na okres 2,048[s].

    Rozproszony system zbierania danych ZigBee


    Moduły slave:

    Zdaniem modułów slave jest wykonywanie pomiarów. Każdy z modułów dokonuje pomiaru dwóch wielkości analogowych z rozdzielczością 10 bitów,
    przetwarzanie odbywa się metodą kompensacji wagowej. Każdy moduł posiada dwa wejścia i cztery wyjścia cyfrowe.
    Urządzenie zasilane są napięciem 3,3VDC. Poziom maksymalny sygnałów logicznych i analogowych jest równy napięciu zasilania.
    Watchdog timer ustawiony na okres 2,048[s].

    Rozproszony system zbierania danych ZigBee

    Całość zamknięta w obudowach:

    Rozproszony system zbierania danych ZigBee

    Rozproszony system zbierania danych ZigBee

    Te same informacje można znaleźć tutaj:

    http://mbmaster.pl/elektronika-mikrokontrolery-projekty.html

    Fajne! Ranking DIY
    Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz kartę SD 64GB.
    O autorze
    bryku13
    Poziom 12  
    Offline 
    automatyk, elektronik, elektryk
    http://mbmaster.pl
    Specjalizuje się w: mikrokontrolery, plc, roboty przemysłowe
    bryku13 napisał 44 postów o ocenie 12, pomógł 5 razy. Mieszka w mieście Bielsko-Biała. Jest z nami od 2013 roku.
  • #2
    Kuniarz
    Moderator Projektowanie
    Całkiem ciekawie Ci to wyszło, zwłaszcza od strony software na PC. Trochę mało estetyki w wykonaniu płytek. Po pierwsze po co ta "przejściówka" do modułu radiowego, a po drugie jakby wszystko dać w SMD to byłoby o połowę mniejsze i zdecydowanie ładniejsze ;-)
  • #3
    bryku13
    Poziom 12  
    Masz rację w SMD to by to wyglądało zdecydowanie lepiej, ale chciałem sam wykonać płytki. Płytki to moja własna praca, fajnie się przy tym bawiłem i dużo się nauczyłem. Nie wspominam już nawet ile było ich wersji. W kwestii przejściówki chciałem zrobić system modułowy, pozostawiłem sobie możliwość podłączenia innego układu poprzez goldpiny.
  • #5
    bryku13
    Poziom 12  
    Mam inny projekt wykonany w SMD, też jeszcze prototyp.

    http://www.mbmaster.pl/elektronika-mikrokontrolery-projekty.html#PwmController

    Zamieszczony tutaj system będzie w SMD, to jest plan przyszłościowy. Największym wyzwaniem było zaprogramowanie go, w sumie trzy mikrokontrolery no i aplikacja pc. Nie wspominam już moim samodzielnym firmware pod USB. Projekt stracił z 50% z uwagi na wykonanie go metodą z ubiegłego wieku, ale w końcu to prototyp wykonywany pod presją czasu.
  • #6
    deus.ex.machina
    Poziom 32  
    Robiłeś ten projekt z jakimś konkretnym przeznaczeniem?

    Interesuje mnie czy analizowałeś odporność ZigBee na zakłócenia - głownie te od WiFi i BT ale również innych źródeł pracujących w pasmie ISM 2.4GHz.
  • #7
    Raphaw
    Poziom 20  
    Witam, niezmiernie interesujący projekt. Troszkę mało informacji na temat części sprzętowej. Jak wygląda obsługa protokołu Zigbee? czy zastosowano dedykowany moduł radiowy, czy protokół zaimplementowano programowo? Planujesz rozbudowę sieci? Czy moduły mogą pełnić funkcję routera?
    Pozdrawiam.
  • #8
    bryku13
    Poziom 12  
    Generalnie projekt został zrobiony jako moja praca dyplomowa na studiach, ciągle nad nim pracuje w miarę możliwości. Podczas prób, które przeprowadzałem WiFi było zawsze obecne jako zakłócenie, nie zauważyłem problemów. Przede wszystkim testy robione były w celu zmierzenia maksymalnego zasięgu, w zamkniętej przestrzeni magazynu osiągnąłem 46+/-0,5[m] przy wzajemnej widoczności anten i braku przeszkód.

    Dodano po 6 [minuty]:

    W kwestii sprzętu jeden moduł to mikrokontroler plus moduł radiowy. Moduł radiowy jest w pełni kompatybilny z standardem IEEE 802.15.4. Dwie najniższe warstwy ZigBee czerpie z IEEE 802.15.4. Reszta protokołu ZigBee w wersji minimalnej dopuszczalnej przez standard jest zaszyta w mikrokontrolerach. W obecnej konfiguracji sieć pracuje w topologii gwiazdy. Jest możliwa praca modułów jako routery, ale konieczna byłaby zmiana softu w mikrokontrolerach.
  • #9
    deus.ex.machina
    Poziom 32  
    Również robiłem szereg testów z Zigbee i niestety nie spełnił on pewnych wymagań dotyczących pracy w czasie rzeczywistym - stad moje pytanie o odporność twojej aplikacji na zakłócenia.

    Nie miałem okazji niestety sprawdzić tego: http://www.nanotron.com/EN/index.php ale po przeanalizowaniu specyfikacji i wstępnych analizach doszedłem do wniosku ze w środowisku przemysłowym raczej ZigBee większych szans nie ma.
    Niestety w międzyczasie projekt umarł i nawet nie ściągałem modułów z Nanotrona do testów.
  • #10
    bryku13
    Poziom 12  
    W kwestii wymagań dla systemu czasu rzeczywistego to chciałbym się spytać w których punktach pojawiły się problemy, może też je napotkam.
  • #11
    deus.ex.machina
    Poziom 32  
    Problemów jest wiele:

    Podczas kolizji (w danej chwili kanał jest zajęty) Zigbee z reguły używa funkcji autrepeat - jednak problemem jest czas w którym przychodzi pakiet i to czy pakiet faktycznie nie został odebrany czy może został odebrany ale potwierdzenie odebrania nie zostało poprawnie przyjęte przez transmitter - niestety trzeba mieć time stamp'y by jednoznacznie określić hierarchie pakietów (no a tu pojawia się problem synchronizacji czasu).

    Problemem są same algorytmy kontroli zajętości kanałów - większość transceiver'ów Zigbee ma programowy stos i związane z tym narzuty czasowe - znalazłem jeden stos Zigbee gdzie większość funkcji zrealizowana jest na poziomie hardware - takie układy robi firm GreenPeak.

    Najgorsze wg moich obserwacji gdy kanał zajęty jest w sposób losowy (zakłócenie z punktu widzenia Zigbee ma charakter losowy i krótkotrwały - np transmisja typu burst - większość transceiver'ów Zigbee się zwyczajnie wykłada na tym).

    To o czym mało kto pamięta to fakt ze alokacja kanałów dla Zigbee zoptymalizowana jest z punktu widzenia USA.
  • #12
    bvr
    Poziom 14  
    deus.ex.machina napisał:
    Problemów jest wiele:
    Podczas kolizji (w danej chwili kanał jest zajęty) Zigbee z reguły używa funkcji autrepeat - jednak problemem jest czas w którym przychodzi pakiet i to czy pakiet faktycznie nie został odebrany czy może został odebrany ale potwierdzenie odebrania nie zostało poprawnie przyjęte przez transmitter - niestety trzeba mieć time stamp'y by jednoznacznie określić hierarchie pakietów (no a tu pojawia się problem synchronizacji czasu).

    Problemem są same algorytmy kontroli zajętości kanałów - większość transceiver'ów Zigbee ma programowy stos i związane z tym narzuty czasowe - znalazłem jeden stos Zigbee gdzie większość funkcji zrealizowana jest na poziomie hardware - takie układy robi firm GreenPeak.

    Najgorsze wg moich obserwacji gdy kanał zajęty jest w sposób losowy (zakłócenie z punktu widzenia Zigbee ma charakter losowy i krótkotrwały - np transmisja typu burst - większość transceiver'ów Zigbee się zwyczajnie wykłada na tym).


    To prawda, że większość implementacji ZigBee jest programowa, ale nie zgodzę się z tym, że stanowi to problem. ZigBee jest standardem który definiuje stos począwszy od warstwy routingu. Warstwa PHY oraz MAC definiowana jest przez 802.15.4. Znam co najmniej 3 implementacje 802.15.4 w których warstwa MAC jest zaimplementowana programowo i nie stanowi to problemu.

    Problemy o których piszesz wynikają z użycia trybu non-beacon w warstwie MAC 802.15.4. W tym trybie stosowany jest algorytm CSMA/CA który powoduje niedeterministyczny czas dostępu do łącza.

    Rozwiązaniem jest użycie trybu beacon-enabled w którym wykorzystywane jest TDMA. Oznacza to, że każdy z węzłów ma swój slot przeznaczony do komunikacji co znacznie zmniejsza problem kolizji i eliminuje problem przejęcia łącza przez jeden z węzłów.

    Oczywiście nie ma róży bez kolców - tryb beacon-enabled wymaga utrzymywania przez sieć synchronizacji czasu, co wiąże się większym poborem energii przez węzeł.

    Nie zgodzę się, że potrzebujesz time-stamp, aby odrzucić zduplikowane pakiety. Wystarczy do tego numer sekwencyjny pakietu.

    Cytat:

    To o czym mało kto pamięta to fakt ze alokacja kanałów dla Zigbee zoptymalizowana jest z punktu widzenia USA.


    O ile mi wiadomo to zakres częstotliwości 2.4-2.5GHz w paśmie ISM jest identyczny na całym świecie.
  • #13
    mickpr
    Poziom 39  
    Na początek uznanie za pomysł projektu. Wykonanie nieco gorzej, ale początki są zawsze trudne i z upływem czasu wszystko staje się "lepsze".

    Mam do ciebie parę pytań:
    1. Mówisz, że zasięg sięga około 45 m. Realnie?. A w budynku (ściany itd..)
    2. Czy stosujesz jakieś zewnętrzne anteny, czy tylko tą zintegrowaną z modułem?
    3. Moduł to MRF24J40MA-I/RM ?
    4. Mówisz, że system obecnie działa w topologii gwiazdy (koordynator (master) + slave'y). Ile maksymalnie węzłów testowałeś?
    5. Jak częste są zapytania do poszczególnych modułów z "master'a" ?

    Co do propozycji - polecałbym dołożenie jakiegoś procka z Ethernetem (jeśli się trzymasz PIC - to np. PIC18F67J60/90) i podłączenie koordynatora do sieci. Daje to dużo większe możliwości niż podłączenie do PC.
    Osobiście w roli mastera używam LPC1768 - całkiem wydajny jak na to zastosowanie MCU.

    Jeśli chodzi o komunikację - myślę, że pomysł z "watchdogiem" jest w porządku, ale nie do końca.
    Moim zdaniem każdy z modułów "slave" powinien próbować skomunikować z master'em co jakiś czas, aby moduł master wiedział, że dany "slave" istnieje. Niekoniecznie musi się od razu resetować.
    Moduł master powinien posiadać bieżąco aktualizowaną tabelę "węzłów". Przy topologii gwiazdy jest to dość proste do zrobienia. Przy topologi 'mesh' - już nie tak proste.
    Sam męczę ostatnimi czasy RF z ST Microelectronic. Jednakże z powodów licencyjnych zostałem chwilowo ograniczony do sieci w topologii gwiazdy. Ma ona jedną główną wadę: konieczność stosowania wzmacniaczy (master musi mieć zasięg na każdy węzeł).
  • #14
    bryku13
    Poziom 12  
    Kolejno na pytania:
    1. W poście opisałem warunki i odległość - w zamkniętej przestrzeni magazynu osiągnąłem 46+/-0,5[m] przy wzajemnej widoczności anten i braku przeszkód. Wymiary magazynu z paletami produktów żywnościowych, które były w otoczeniu. Kubatura budynku D-S-W 40m-23m-11m. Wzajemną widoczność anten rozumiem jako anteny skierowane do siebie.

    2. Wykorzystane są anteny zaimplementowane w module.

    3. Dokładnie MRF24J40MA.

    4. Mam tylko trzy urządzenia, na tej liczbie przeprowadzałem testy i dalej prowadzę w miarę możliwości.

    5. Kod w masterze został zaprojektowany tak aby po uwzględnieniu wszystkich możliwych retransmisji w wymianie informacji każdy slave był odpytany dwa razy w ciągu sekundy.

    Nad koncepcją z Ethernetem pracuje, ale z wykorzystaniem ENC28J60.
  • #15
    deus.ex.machina
    Poziom 32  
    bvr napisał:

    To prawda, że większość implementacji ZigBee jest programowa, ale nie zgodzę się z tym, że stanowi to problem. ZigBee jest standardem który definiuje stos począwszy od warstwy routingu. Warstwa PHY oraz MAC definiowana jest przez 802.15.4. Znam co najmniej 3 implementacje 802.15.4 w których warstwa MAC jest zaimplementowana programowo i nie stanowi to problemu.


    No ja akurat widziałem jak Zigbee przestaje działać w obecności innych użytkowników 2.4GHz i niestety uważam ze to być może dobra technologia w jakichś niekrytycznych zastosowaniach - w środowisku przemysłowym lub tam gdzie nie możemy pozwolić sobie na niepewność komunikacji niestety się nie sprawdzi o ile nie zastosuje się specjalnych rozwiązań.

    Zresztą na ten temat istnieje już pewna pula dokumentów która wyraźnie stwierdza ze koegzystencja w 2.4GHz jest możliwa pod warunkiem tego ze każdy użytkownik będzie albo kooperował w zakresie zajętości pasma albo nie nadużywał czasu korzystania z niego.

    Implementacja stosu w sprzęcie jest krytyczna w sytuacji gdy nie ma pokojowej koegzystencji między różnymi użytkownikami pasma - czas reakcji jest wtedy krytyczny zwłaszcza kiedy operuje się w ściśle określonym budżecie mocy (zasilanie i moc wyjściowa).

    bvr napisał:

    Problemy o których piszesz wynikają z użycia trybu non-beacon w warstwie MAC 802.15.4. W tym trybie stosowany jest algorytm CSMA/CA który powoduje niedeterministyczny czas dostępu do łącza.

    Rozwiązaniem jest użycie trybu beacon-enabled w którym wykorzystywane jest TDMA. Oznacza to, że każdy z węzłów ma swój slot przeznaczony do komunikacji co znacznie zmniejsza problem kolizji i eliminuje problem przejęcia łącza przez jeden z węzłów.

    Oczywiście nie ma róży bez kolców - tryb beacon-enabled wymaga utrzymywania przez sieć synchronizacji czasu, co wiąże się większym poborem energii przez węzeł.


    Jeśli zasilanie nie jest problemem to nie ma przeciwwskazań by używać innych technologi - Zigbee zazwyczaj jest tam gdzie potrzeba pracować bateryjnie i mocami rzędu 0 - +6dBm max

    bvr napisał:

    Nie zgodzę się, że potrzebujesz time-stamp, aby odrzucić zduplikowane pakiety. Wystarczy do tego numer sekwencyjny pakietu.


    Cytat:

    To o czym mało kto pamięta to fakt ze alokacja kanałów dla Zigbee zoptymalizowana jest z punktu widzenia USA.


    O ile mi wiadomo to zakres częstotliwości 2.4-2.5GHz w paśmie ISM jest identyczny na całym świecie.


    2.4GHz ISM tak ale inaczej używany np w USA a np w Europie czy Japoni.
    Np. niektóre algorytmy wyboru kanału mogą preferować np zakłócenia (ich unikanie) typowe dla określonego regionu.
  • #16
    KwoiteK
    Poziom 16  
    Witam.

    W niedługim czasie mam w planach budowę podobnego systemu do monitorowania temperatur. Jak wygląda sprawa prądożerności? Co z zasilaniem z baterii? Czy ma Kolega jakieś doświadczenia?

    Pozdrawiam
  • #17
    deus.ex.machina
    Poziom 32  
    KwoiteK napisał:
    Witam.

    W niedługim czasie mam w planach budowę podobnego systemu do monitorowania temperatur. Jak wygląda sprawa prądożerności? Co z zasilaniem z baterii? Czy ma Kolega jakieś doświadczenia?


    Np GreenPeak (jeden z kilku testowanych przeze mnie i zdecydowanie najlepszy jak na razie choćby przez fakt posiadania jako jedna z pierwszych firm natywne antenna diversity) chwali się ze ich rozwiązanie używające baterii CR2032 może pracować non stop 10 lat jako pilot zdalnego sterowania - obawiam się ze to najlepszy rezultat i konkurencja oferuje znacznie mniej a czas życia baterii zależy od wielu czynników (np ilości kolizji).
  • #18
    KwoiteK
    Poziom 16  
    Cytat:
    może pracować non stop 10 lat

    Pilot jest w trybie lowpower, po naciśnięciu przycisku przechodzi do trybu "normalnego" poboru prądu, wysyła kod klawisza i ponownie usypia. W takim wypadku ma prawo pracować tyle lat.
    Natomiast w rozwiązaniu autora wątku urządzenia slave są odpytywane przez mastera więc cały czas musi być aktywny odbiór, a przez to i pobór prądu znacznie większy.
    Można również wysyłać informację od slave do master tylko zmianie wartości ADC, a w pozostałym czasie być w uśpieniu ale wtedy nie można odpytać slave.
    Jeśli dodamy do tego pobór prądu przez procesor to może okazać się, że musimy wymieniać baterie co tydzień i grzebać np w 20 czujnikach.
  • #19
    bryku13
    Poziom 12  
    W kwestii testów działania na bateriach, to nie miałem okazji go jeszcze przeprowadzić. W dokumentacji jest podany pobór prądu podczas nadawania i odbioru. Dokładnie
    - RX mode: 19 mA (typical)
    - TX mode: 23 mA (typical)
    - Sleep: 2 μA (typical)
    ale te dane dotyczą tylko i wyłącznie modułu radiowego, u mnie jest jeszcze mikrokontroler a więc dodatkowy pobór energii. Jak przeprowadzę testy warte wspomnienia to postaram się o nich napisać.
    W moim projekcie tryb sleep nie jest wykorzystany na chwilę obecną.
  • #20
    deus.ex.machina
    Poziom 32  
    KwoiteK napisał:
    Cytat:
    może pracować non stop 10 lat

    Pilot jest w trybie lowpower, po naciśnięciu przycisku przechodzi do trybu "normalnego" poboru prądu, wysyła kod klawisza i ponownie usypia. W takim wypadku ma prawo pracować tyle lat.
    Natomiast w rozwiązaniu autora wątku urządzenia slave są odpytywane przez mastera więc cały czas musi być aktywny odbiór, a przez to i pobór prądu znacznie większy.
    Można również wysyłać informację od slave do master tylko zmianie wartości ADC, a w pozostałym czasie być w uśpieniu ale wtedy nie można odpytać slave.
    Jeśli dodamy do tego pobór prądu przez procesor to może okazać się, że musimy wymieniać baterie co tydzień i grzebać np w 20 czujnikach.


    A to niekoniecznie, po pierwsze możemy wybudzać odbiornik co jakiś czas, po drugie akurat wiele firm oferuje dość agresywne możliwości oszczędzania energii (np zasilana jest wyłącznie część układu, korelator zrealizowany w sprzęcie wiec nie ma potrzeby budzenia całego uC - naprawdę jestem pod ogromnym wrażeniem tego jak zostało to rozwiązane przez GP gdzie uC wybudzany jest dopiero po odebraniu pakietu i np porównując to do TI czy NXP... no cóż - nie ma porównania - by było jasne - nie jestem pracownikiem GP, co więcej w tej chwili nie używamy Zigbee bo się po prostu nie sprawdził - to co pisze to wyłącznie wynik powiedzmy 2 lat weryfikacji tego co oferują firmy i standard na papierze z realiami życia w produkcie który ma WiFi i BT).
  • #21
    bryku13
    Poziom 12  
    Przeprowadziłem pierwsze testy długości działania systemu przy zasilaniu z baterii, chodzi tu oczywiście o moduły slave. Moduł master zasilany jest z portu USB. Schemat modułu:
    Rozproszony system zbierania danych ZigBee

    Test był przeprowadzony dla modułów slave (oba mają taką samą konstrukcję). Schemat modułu:
    Rozproszony system zbierania danych ZigBee

    Urządzenia slave zostały przygotowane pod uniwersalną możliwość zasilania, stąd stabilizator (jest on też zabezpieczeniem, ponieważ zasilanie modułu radiowego to max 3,6V). W trakcie uruchamiania urządzenia były zasilane z zasilaczy 5V, potem z trzech baterii LR6 połączonych oczywiście w szereg, daje to 4,5V. Zasilanie układów było też realizowane poprzez trzy akumulatorki 1,2V (tu stabilizator był już zbędny). Z uwagi na uniwersalność pojawiły się dodatkowe straty energii. Zamieściłem schemat aby można było oszacować pozostałem straty E.
    Każdy slave odpytywany dwa razy w sekundzie ( z uwzględnieniem retransmisji). W cyklu 1s zawarte są w slave-ie cztery obsługi przerwania (dwa razy transmisja plus dwa razy odbiór). Każde wejście w ISR wiąże się z uruchomieniem dwóch diod LED na 100ms (dodatkowy pobór E - docelowo zbędny), migające diody tylko z powodu serwisowego.

    No i w końcu najważniejsze, podczas testu układy zasilane były z baterii 3x1,5V (LR6). Czas działania to 42h, przy tak częstych transmisjach jak wspomniane wyżej. Wynik końcowy to ponad 300000 pomiarów z każdego modułu.

    Jak wspomniałem na samym początku system jest w żywym projektem i się ciągle rozwija.