logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Rozproszony radiowy system pomiarowy

r06ert 15 Maj 2009 19:56 4894 16
  • #1 6534327
    r06ert
    Poziom 25  
    Witam!
    "Rozproszony radiowy system pomiarowy" - tak najprawdopodobniej będzie brzmieć tytuł mojej pracy magisterskiej. W założeniu będzie to system nadajników radiowych (sieć) w której węzły będą się ze sobą nawzajem komunikować w celu transmisji danych (rutingu). Całość ma przypominać w działaniu ZigBee, chociaż ma być znacznie prostsze. Smile

    Na razie jestem na etapie wczesnych przemyśleń i rozważań. Pierwszym problemem jaki mi się nasuwa to to w jaki sposób zrealizować dostęp do medium transmisyjnego? Tzn jak jeden nadajnik ma wykryć nadawanie danych drugiego znajdującego się w pobliżu tak aby nie zakłócić jego transmisji. Może zrobić spróbować zrobić to tak: przed transmisja danych węzeł będzie przez chwile nasłuchiwać czy któryś sąsiad nie nadaje? A może jakieś transiwery radiowe np cc1000 maja już coś podobnego wbudowane?

    Z góry dzięki za rady. Smile
    Pozdrawiam
  • #2 6536161
    DXFM
    Poziom 20  
    Ostatnio z kolegami robiliśmy system z wykorzystaniem 100 transceiverów RFM12B. Świetna zabawka! Brakuje mi w nich pomiaru poziomu sygnału w.cz. i jakiejś wbudowanej metody oczekiwania na transmisję z obniżonym poborem mocy, bo domyślnie w odbiorze ciągnie 10-15mA. Ale zajętość kanału bez problemu odczytuje się z rejestru statusowego. Posiada bufor fifo nadawczy i odbiorczy, wyjście przerwania, pracuje już od 2,2V. Producentem jest HopeRF. Aktualnie do kupienia w TME i Seguro po ok. 20zł za sztukę.
    Polecam.
    Rozproszony radiowy system pomiarowy
  • #3 6537107
    r06ert
    Poziom 25  
    Super sprawa :) Prawdę mówiąc nie wierzyłem że uda mi się zjechać poniżej 40zł za transiver. :) A czy to co robiliście jest gdzieś ogólnie dostępne? Chętnie przejrzałbym was projekt. :)
    Czy stosowaliście jakieś protokół rutingu? Czy może to był ruting statyczny albo węzeł "master" widział wszystkie slave-y? ;)
    Pozdrawiam :)
  • #4 6537179
    And!
    Admin grupy Projektowanie
    To ciekawy temat i w zależności od tego jak bardzo będziesz chciał system rozbudować można brać pod uwagę.

    -wykrywanie zajętości kanału przez dane (odrzucanie zakłóceń).
    -ramkowanie danych
    -określenie maksymalnego czasu nadawania
    -adresy urządzeń
    -zapamiętywanie adresów dostępnych w otoczeniu
    -rozgłaszanie swojego adresu
    -stała/zmienna/maksymalna długość ramki
    -crc lub inny sposób kontroli/korekcji błędów
    -numerowanie ramek
    -buforowanie komunikatów które należy przekazać dalej
    -potwierdzanie dotarcia pakietu do adresu docelowego
    -potwierdzanie dotarcia pakietu do węzła pośredniego
    -znakowanie ilości przeskoków dla pakietu danych
    -rozważenie zastosowania routingu wzorowanego na ofsp lub machanizmu wzorowanego na STP.
  • #5 6537259
    r06ert
    Poziom 25  
    Biorę pod uwagę te właśnie rzeczy. :) Przez chwile myślałem nawet nad stworzeniem coś jakby sieci IP ale wydaje mi się, że nie ma sensu aż tak tego komplikować.

    co do rutingu:

    Najprostszym rozwiązaniem byłoby na stałe określenie w każdym węźle następnego do którego miałby trafiać odebrane pakiety danych :) i tak aż do "ujścia" sieci systemu. Coś jakby ruting statyczny. Jednak nie chciałbym iść na łatwiznę ;) Myślałem właśnie o budowaniu w każdym węźle coś ala tablicy rutingu z wykorzystaniem jakiegoś protokołu wzorowanego na ospf czy rip właśnie. :)
  • Pomocny post
    #6 6540698
    DXFM
    Poziom 20  
    r06ert napisał:
    Czy stosowaliście jakieś protokół rutingu? Czy może to był ruting statyczny albo węzeł "master" widział wszystkie slave-y? ;)
    Pozdrawiam :)

    W zastosowanej aplikacji wymagana była tylko komunikacja wszystkich węzłów z jedną stacją bazową. Wszystkie węzły są odpytywane indywidualnie, a oprócz tego zaimplementowany jest broadcast grupowy. Tak więc kontrolerem jest jedynie baza, co znacznie upraszcza protokół i obsługa mieści się w ATtiny2313.

    Trochę wystraszyłem się opinii innych użytkowników tych modułów. Między innymi ktoś pisał, że moduły lubią "ciasnotę" i w pająku nie działają. Totalna bzdura, chyba że trafili na uszkodzone serie. Zarówno na płytce prototypowej jak i zaprojektowanej płytce działają znakomicie.

    Trochę czasu zajęło poprawienie biblioteki obsługi znalezionej w sieci, gdyż posiadała sporo błędów. Może coś już poprawili:
    https://www.das-labor.org/trac/browser/microcontroller/src-atmel/lib/rfm12
    I jeszcze przydatna strona, z której mam powyższy link:
    http://www.mikrocontroller.net/articles/AVR_RFM12#Hardware
  • #7 6542506
    r06ert
    Poziom 25  
    DXFM, dzięki. :)
  • #8 6631189
    marek_Łódź
    Poziom 36  
    DXFM napisał:
    W zastosowanej aplikacji wymagana była tylko komunikacja wszystkich węzłów z jedną stacją bazową. Wszystkie węzły są odpytywane indywidualnie, a oprócz tego zaimplementowany jest broadcast grupowy. Tak więc kontrolerem jest jedynie baza, co znacznie upraszcza protokół i obsługa mieści się w ATtiny2313.

    Trochę wystraszyłem się opinii innych użytkowników tych modułów. Między innymi ktoś pisał, że moduły lubią "ciasnotę" i w pająku nie działają. Totalna bzdura, chyba że trafili na uszkodzone serie. Zarówno na płytce prototypowej jak i zaprojektowanej płytce działają znakomicie.
    Jesteś w stanie oszacować zasięg dla tych modułów? Jakie anteny stosujecie?
  • #9 6721094
    r06ert
    Poziom 25  
    Uruchomiłem moduły, swietnie się sprawują. :) Teraz mam takie pytanie. Jak kazdy węzeł ma budowac tablice rutingu? Przejrzałem dokument RFC, ale nie znalazłem informacji nt jakichkolwiek algorytmów, a jedynie chyba że to zależy od programisty. :) Zna ktoś może jakis sprytny i mały algorytm?
  • Pomocny post
    #10 6723102
    And!
    Admin grupy Projektowanie
    Najprościej,
    niech każdy węzeł pamięta jakie moduły go otaczają
    (tablica modyfikowana dynamicznie, jeżeli jakiś węzeł nie jest słyszalny przez określony czas)
    1. Jeżeli pakiet który węzeł odebrał jest do niego przetwarza go
    2. Jeżeli jest adresowany do węzła który jest w jego otoczeniu wysyła go bezpośrednio do niego.
    3. Jeżeli pakiet nie jest do niego ani do węzłów które są w jego zasięgu, wysyła pakiet do węzłów w jego otoczeniu.
    4. Każdy pakiet ma pole TTL które na starcie ma wartość powiedzmy równą ilości węzłów, po przejściu przez dowolny węzeł wartość TTL jest zmniejszana przed przesłaniem, gdy osiągnie zero pakiet nie jest przesyłany.
    5. Niezawodność transmisji uzyskiwana jest w "wyższych warstwach" dzięki potwierdzeniom odbioru.

    To taki najprostszy, jednak mogący powodować zatory.

    Inna wersja bardziej skomplikowana, może być rozbudową powyższej.
    W pkt. 3. pakiet nie jest wysyłany do wszystkich tylko do węzła który jest wpisany jako trasa do punktu docelowego dla pakietu,
    jeżeli brak trasy do punktu docelowego realizowana jest wysyłka do wszystkich.

    Jak realizować taką tablicę routingu dla węzłów ?

    Jest wiele sposobów.
    Jeden z nich to zadeklarowanie n komórek pamięci każda z nich może zapisać liczbę n.
    n jest równe maksymalnej liczbie węzłów w sieci.
    Przyczym 0 jest zarezerwowane.
    Dostaliśmy pakiet adresowany do węzła k, czytamy zawartość z pod adresu k,
    jeżeli 0 wysyłamy do wszystkich
    jeżeli <>0 wysyłamy trasą przez węzeł którego numer zapisany jest w komórce.

    Jak wypełniać tabelę routingu ?

    Jest wiele spsobów,
    np. możemy wprowadzić specjalny pakiet wysyłany przez każdy z węzłów co pewien określony czas.
    I teraz pakiet propaguje się w sieci,
    pakiet zawiera numer węzła źródłowego,
    węzeł który go odbiera zapisuje sobie że trasa do węzła źródłowego,
    prowadzi trasa przez węzeł z którego nadszedł pakiet.
    A jak optymalizować trasy ?
    Śledząc wartość TTL, im trasa krótsza tym lepsza.

    To taki najprostrzy sposób na początek.
  • #11 6727155
    r06ert
    Poziom 25  
    Dzięki za podpowiedź. :)

    Zrobiłem to troszkę inaczej. :) W chwili włączenia wszystkie węzły milczą. Węzeł główny wysyła pakiecik i wszystkie które go odbiorą zapisują sobie jego adres oraz zostaja przyporządkowanie do strefy umownie nazwanej warstwą pierwszą. Potem węzły w warstwie pierwszej wysyłają "pakiet routingu" (czyli pakiet z informacją "hello, tutaj jestem" ;) ) i wszystkie następne które odebrą te pakiety przyporządkowane zostaną do warstwy drugiej oraz zapamiętają od kogo te pakiety otrzymały... itd. Relacja jest teraz taka, że węzeł z warstwy wyższej akceptuje pakiety rutingu warstwy niższej, ale nie odwrotnie. Wtedy każdy węzeł wskaże na kolejnego z warstwy niższej do którego pokieruje pakiet z danymi i tak aż do węzła głównego, a stąd już do komputera. Oczywiście pakiety rutingu muszą być wysyłane cyklicznie. Węzeł który nie otrzyma takiego pakietu przez dłuższy czas od węzłów warstwy niższej milczy i tylko nasłuchuje.

    Zastanawiam się teraz nad prostym sposobem dostępu do medium. Myślałem nad rozwiązaniem: że przed wysłaniem paczki obliczany jest losowo czas oczekiwania, po którym następuje nasłuch. Jeżeli jest cisza w eterze to nadaje, jeżeli nie to operacja powtarza się. :)

    Pozdrawiam :)

    EDIT:
    Gdzie moge znaleźć strukture rejestru statusu modułu RFM12? W nocie znalazłem tylko informacje jak odczytać ten rejestr, ale za co jaki bid odpowiada to już nie. Chcę mieć możliwość sprawdzania czy kanał radiowy jest wolny.
  • Pomocny post
    #12 6729804
    DXFM
    Poziom 20  
    r06ert napisał:

    Gdzie moge znaleźć strukture rejestru statusu modułu RFM12? W nocie znalazłem tylko informacje jak odczytać ten rejestr, ale za co jaki bid odpowiada to już nie. Chcę mieć możliwość sprawdzania czy kanał radiowy jest wolny.

    No to jeszcze raz zobacz na stronie 23.
  • #13 6764940
    r06ert
    Poziom 25  
    Dzięki. Dysponowałem chyba jakaś starą notą, gdzie rejestr ten nie był nigdzie opisany.
  • #14 6890142
    r06ert
    Poziom 25  
    Witam!
    Skorzystałem z kilku rad tutaj m.in co do wyboru modułów radiowych tak więc myślę że mogę się tutaj pochwalić tym co już zrobiłem. Kilka ogółów można znaleźć pod tym linkiem:
    http://robert.zdunek.enetia.pl/bezprzewodasiecsensoryczna.html
    .
    Jako że jest to prototyp, tak więc co mogłem to dawałem w montażu przewlekanym. ;)

    Teraz przyszedł czas na stworzenie przykładowej aplikacji na PCta. Chciałbym, aby m.in. aplikacja potrafiła "odtworzyć" na ekranie monitora coś jakby mapę sieci. Np. coś jak na rysunku poniżej.

    Rozproszony radiowy system pomiarowy

    Myślałem o C# pod VS2005. W związku z czym mam pytanie. Czy istnieje jakaś biblioteka, bądź jest coś podobnego zaimplementowane w VS? Czy jednak sam będę się musiał pobawić w rysowanie kółeczek i linii łączących je? ;)

    Jakby co program nie będzie zgadywać jak jest sieć skonfigurowana. ;) Dane będą pochodzić bezpośrednio z sieci w postaci adresów kolejnych węzłów przez które "skaczą" pakiety. :)

    Ponowie proszę o pomoc. Z góry dziękuję.
    Pozdrawiam.
  • Pomocny post
    #15 6893441
    And!
    Admin grupy Projektowanie
    Warto zainteresować się OpenGL lub biblioteką glut.dll
    Podobny problem miałem przy rysowaniu spektrogramu
    przy pomocy API,
    okazało się że OpenGL jest idealnym rozwiązaniem problemu.
    Na początek polecam np. to:
    NeHe
  • #17 6916537
    r06ert
    Poziom 25  
    Witam! Dzięki za pomoc, ale mam już gotowe urządzenia i nie oparte na protokole ZigBee, ale własnym. :) Jestem na etapie pisania pracy, badania możliwości węzłów i sieci, tak więc układów już raczej nie tknę. ;)

    Zdaje sobie sprawę że moje rozwiązanie ustępuje sieciom opartym na protokole ZigBee, jednak niemniej mam satysfakcje że chociaż trochę się pobawiłem - poprogramowałem i polutowałem sobie. ;)

    Pozdrawiam. :)
REKLAMA