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

ZigBee BitCloud Meshnetic problemy

26 Sty 2009 12:30 10587 64
  • Poziom 23  
    Witam

    Chciałbym zacząć tutaj rozmowy dotyczące problemów ze stosem ZigBee BitCloud firmy Meshnetic.

    Korzystam ze stosu dostarczonego z ZigBit 900 Development Kit.

    Swój projekt opieram o przykład "lowpower". Węzły poprawnie logują się do sieci i bezproblemowo wysyłają wiadomości do koordynatora sieci.

    Moim problemem jest uruchomienie routerów ZigBee. Według specyfikacji routery po zalogowaniu do sieci powinny posredniczyć w przesyłaniu wiadomości bez jakiejkolwiek ingerencji w transmisję ze strony aplikacji. Za pośredniczenie powinien odpowiadać tylko stos ZigBee.

    Po skonfigurowaniu węzła jako router i poprawnym zalogowaniu się do sieci router "milczy". Odkręciłem antene z koordynatora i zostawiłem antene w routerze. Węzły nadal logują się do koordynatora. Jeśli oddale węzeł od koordynatora węzeł nie może zalogować się do sieci.

    Google niestety milczy, a dokumentacja jest na ten temat bardzo uboga.

    Jeśli ma ktoś doświadczenie w pracy ze stosem BitCloud to chętnie wymienię doświadczenia.

    Pozdrawiam

    Po kilku zmianach węzeł loguje się przez router (jako parentAddress dostaje adres routera). Pierwszy pakiet z danymi dochodzi do koordynatora, ten zwraca węzłowi jakieś dane konfiguracyjne. Węzeł po otrzymaniu konfiguracji wysyła dane pomiarowe i czeka na odpowiedź która z koordynatora nie nadchodzi... koordynator nie wywołuje również funkcji potwierdzającej wysłanie lub porażkę wysłania.
  • Sklep ECSYSTEM
  • Poziom 23  
    Witam

    Po kilku miesiącach pracy mogę podzielić się doświadczeniami ze stosem. Problem z logowaniem został rozwiązany przez wykorzystanie najnowszej wersji stosu 1.4.1 udostępnionej na stronie Atmela.

    W moim projekcie opartym o stos BitCloud nadal mam kilka problemów. Doszedłem do tego że dobrym zwyczajem jest odświeżanie wskaźników funkcji odpowiedzialnych za potwierdzenie wysłania pakietów i odebrania pakietów.

    Na przykład odświeżenie wskaźników odebrania pakietów dla dwóch endpointów

    endpointParams_1.APS_DataInd = APS_ShortInd;
    endpointParams_2.APS_DataInd = APS_PageInd;

    i odświeżenie wskaźnika potwierdzającego wysłanie pakietu:

    CoordReq.APS_DataConf = APS_CoordConf;

    Zauważyłem że po pewnym czasie nie otrzymywałem potwierdzeń i pakietów z węzłów mimo że stos dalej działał (odpowiadał na transmisję przez port szeregowy). Powyższe zabiegi polepszyły stabilność działania ale nie rozwiązały problemu do końca. Atmel odpowiedział: może się tak zdażyć przez "wycieki pamięci" ??.

    Osobom planującym projekt "lowpower" na tych układach przedstawiam wynik działania oryginalnego przykładowego programu "lowpower" ze stosu BitCloud (w programie wyłączyłem włączanie ledów podczas transmisji).

    ZigBee BitCloud Meshnetic problemy

    Na wykresie widać spadek napięcia na oporniku 10ohm. Zainteresowani mogą sobie policzyć jaki jest pobór prądu przy jednej transmisji. Uzyskanie 6uA w stanie uśpienia jest super wyczynem, ale podczas jednej transmisji jest zużywanej tyle energii że zbudowanie układu zasilanego bateryjnie jest dosyć nierealne. Wysłałem zapytanie do Atmela z przykładowymi czasami transmisji (rzędu 1ms włączając ACK) wyjętymi z datasheeta RF230 i tym wykresem.
    Otrzymałem odpowiedz:

    Cytat:
    RF230 chip is responsible for physical part of the transmission where
    acknowledgement is sent on one-hop link only. However lowpower application
    is written on top of ZigBee stack which has its own data exchange protocol.
    In this application end device requests acknowledgement from final
    destination node (that can be several hops away) and delivery of this
    acknowledgement is done using so called polling mechanism. This leads to
    1.5sec of awake interval on the end device.


    W chwili obecnej postanowiłem napisać własny protokół sieci w topologii TREE (transmisja tylko od enddev do coord i w drugą stronę, brak transmisji między enddev). Protokół postanowiłem oprzeć o warstwę MAC układów AT86RF2XX udostępnioną przez Atmela.

    Najlepiej było by wykorzystać układy ZigBit. Podłączyłem je do programatora SPI wg opisu w TYM temacie. Jednak nie mogę dogadać się z atmegą. Zastanawiam się czy układy nie są zablokowane fuse bitem [SPIEN=0]. Czy ktoś ma możliwość to sprawdzić JTAG'iem? Mój JTAG dopiero się składa.

    Oglądałem przebiegi z SPI na oscyloskopie i wygląda na to że nie działa CLK, jest ściągnięty cały czas do masy. Po odłącznieu linii CLK od układu przebieg zegarowy pojawia się więc to jest problem z modułu.

    ...................................................................................................

    Powyższe problemy z nieotrzymywaniem potwierdzeń były spowodowane problemami z samą transmisją z węzła nadrzędnego do enddev. Enddev wysyłał tylko jedno zapytanie o pakiet i jeśli go nie odebrał to pakiet zostawał dalej w węźle nadrzędnym jako indirect msg. Zmiany częstotliwości odpytywania (INDIRECT_POLL_RATE) na 40ms oraz timeoutu dla pakietów indirect (MAC_TRANSACTION_TIME) rozwiązało ten problem.

    Aktualnie układ (czujnik bezprzewodowy) pobiera 30uA podczas uśpienia oraz średni prąd przez sekundę (transmisja 2 pakiety między enddev-> coord oraz coord -> enddev) 10mA.

    Pozdrawiam
  • Sklep ECSYSTEM
  • Poziom 10  
    Witam. Jak wygląda sytuacja z zasięgiem układów?
  • Poziom 23  
    Witam,

    Na płytkach wykonanych nie do końca według dokumentacji (obecna masa pod układem ZigBit, długości ścieżek do symetryzatora i anteny inne), zasięg w budynku 3 stropy przy rssi na poziomie -80.. -90dBm oraz maksymalnej mocy nadajnika 11dBm.
    W terenie otwartym napewno kilkaset metrów.

    Polecam te moduły, trzeba się ich nauczyć, troche mailować z atmelem ale jak narazie jestem zadowolony.

    Napisanie własnego protokółu upadło, nie ma na to czasu.

    Pozdrawiam
  • Poziom 10  
    Nie opłacalne są dla mnie moduły ZigBit 900 jako Development Kit. Czy są gotowe moduły (same płytki bez obudowy najlepiej), które można wykorzystać przy pomocy serial Port, rs232, rj-45? Te moduły zigbit mają pracować jako modemy przemysłowe w terenie (hale, magazyny, niskie budynki) do terminali. Czy jest to lepsze rozwiązanie niż wi-fi, XBee?
  • Poziom 23  
    Ja znam tylko moduły "scalone" ZigBit.

    Wszystko zależy co chcesz transmitować, na jakie odległości, jakie zasilanie i czy ma to pracować w sieci. Jeśli nie ma być to sieć tylko terminale do odczytu jakiś danych to nie widze sensu stosowania żadnych z wymienionych układów. Wystarczą jakieś prostrze układy transmisji radiowej.
  • Użytkownik usunął konto  
  • Poziom 10  
    Wystarczy mi transfer 9600 bodów. Myślałem o wi-fi, ale zależy mi na zasięgu w terenie z pzreszkodami - niska zabudowa, niskie hale, magazyny, trochę też otwartej przestrzeni. I urządzenie ma pracować na baterii(akumulator).
  • Użytkownik usunął konto  
  • Poziom 23  
    olosie napisał:
    piti__: Ja wybrałem inną drogę. Napisałem do Atmela o udostępnienie źródeł SerialNet (standardowego softwaru na modułach zigbit) i po podpisaniu NDA dali mi te źródła i sobie dopisałem potrzebne rzeczy. Konfigurację robię poprzez komendy AT co jest bardzo wygodne.
    Jeśli chodzi o zasięg to mierzyłem w terenie zabudowanym i wynosił maksymalnie 900 metrów z antenami zewnętrznymi przy ustawionej mocy na maxa. W firmie miałem koordynatora a biegałem na około z enddevice.

    Co do pomocy ze strony atmela o stos BitCloud to jestem pozytywnie zaskoczony. Na każde pytanie odpowiadały osoby odpowiedzialne za pisanie stosu Vladimir Marchenko czy Ilya Bagrak z Meshneticsa.

    Czy mógłbyś przedstawić projekt płytki pod moduł ZigBit ? Zasięg to jest sprawa którą bym najchętniej poprawił. Napewno w terenie zasięg wynosi kilkaset metrów, ale gdzie tam do 6km jak pisze Meshnetics, a teraz Atmel. Jakie masz kondensatory przed symetryzatorem? W jednym pdf'ie było 100pF w innym 68pF. Czy pod modułem masz wylaną masę?

    olosie napisał:

    "wycieki pamięci" - wycieki mogą się zdarzyć tylko gdy dynamicznie przydzielasz pamięć, więc trochę naciągana ta odpowiedź Atmela. Za to może nastąpić przepełnienie stosu. Spróbuj pozamieniać funkcje, które wywołujesz jednokrotnie na inline, ograniczysz w ten sposób użycie stosu.

    Co do "wycieków pamieci" to już sobie poradziłem... nie przychodziły potwierdzenia wysłania pakietów ponieważ te siedziały jako indirect w węźle rodzicu węzła docelowego. Transmisja następowała dopiero przy następnym obudzeniu Enddev. Zwiększyłem częstotliwość odpytywania rodzica o pakiety oraz dodałem timeout dla wiadomości indirect i teraz nie zapycham bufora wyjściowego nieaktualnymi pakietami, które mogły czekać nawet kilkanaście minut.
  • Użytkownik usunął konto  
  • Poziom 23  
    olosie napisał:

    Coś mi tu nie pasuje.
    Napisałeś, że używasz stosu od "ZigBit 900 Development Kit" dla 900 MHz, a później piszesz o układach RF230, które są na 2,4 GHz. Może Twoje problemy wynikają z używania niewłaściwej wersji stosu?

    Stosuje ZigBit'y 900...wzmianka o RF230 to tylko przykład który przytoczyłem o szybkości wysylania pakietu. Na których modułach osiągnąłeś 900m... 2.4GHz ?
  • Użytkownik usunął konto  
  • Poziom 23  
    Takie zasięgi na 2.4GHz to jest sukces :) jakie masz ustawione wzmocnienie w stosie ? Ja działam na 11dBm, oczywiście przesadzenie z mocą prowadzi to niepotrzebnych odbić, interferencji i niekiedy jakość połączenia może być gorsza. Generalnie 2.4GHz powinien mieć słabsze osiągi w stosunku do pasma 900MHz, a precyzując układy ZigBit 900 pracują na 868MHz lub 915MHz. 868MHz (jeden kanał) jest dostępna dla ogólu. Jak skończę aktualny projekt na tych układach to zajmę się testami przy różnych antenach. Mam płytki meshbean 2 z meshneticsa z oryginalnymi antenami ale nie sprawdzałem dokładnie jakie mają zasięgi.

    Pozdrawiam
  • Użytkownik usunął konto  
  • Poziom 12  
    Zasięgi w otwartej przestrzeni to innymi słowy zasięgi uzyskiwane bez oddziaływania ziemi, czyli między szczytami gór. Jak macie krótkofalówki, np. PMR to możecie sprawdzić, że urządzenia 500mW ERIP (@446MHz), które w mieście dają realny zasięg fonii kilkuset metrów, między szczytami gór pociągną nawet 10km. Idąc tym tropem, przy transmisji cyfrowej, czułości radia -110dB (czy ile tam), antenach 3dBi (razem link 124dB), przy idealnej pogodzie, na 868MHz z drobną pomocą Bożą mogłoby się udać zrobić 6km. Na 2.4GHz zapomnijcie (tłumienie eteru wzrasta z kwadratem odległości i kwadratem częstotliwości).
  • Poziom 15  
    Mam takie dwa pytania odnośnie tych modułów ZigBee Meshneticsa:
    1. Czy jest gdzieś opisane, które piny mikrokontrolera są wyprowadzone na module? Jakoś nie moge znaleźć dokładniejszej dokumentacji po za tą skromną.
    2. Czy mikrokontroler poradzi sobie z jednoczesna komunikacją i dodatkowymi operacjamia sterowania i pomiaru?
  • Poziom 23  
    Witam,

    Można skorzystać z API oferowanego przez stos BitCloud i sterować po nazwach GPIO1...5 itd...
    Konkretnie jakie piny są wyprowadzone można dojść przeglądając plik gpio.h w stosie.

    Co do pomiaru itp to oczywiście że sobie poradzi. masz tam około 20kB na program. Musisz tylko przestrzegać zasad programowania w API stosu. Twoj krok programu musi się zmieścić w chyba 50ms. Jeśli nie ma na to szans to dzielisz swój program na kroki które są pokolei wykonywane z każdym wykonaniem funkcji APL_TaskHandler().

    Pozdrawiam
    Piotrek
  • Poziom 10  
    Witam, przepraszam, że może nie w temacie ale mam kłopot z zaprogramowaniem wejść ADC w modułach ZigBit. Podaję na wejście ADC 1 i ADC 2 sygnały w postaci analogowej (napięcie) i chciałbym je odebrać w koordynatorze. Czy ktoś ma może jakiś przykład wykorzystania tych wejść? Będę wdzięczny za pomoc.
  • Poziom 15  
    Czy kolega ma oprogramowany USART i komunikację pomiędzy koordynatorem a routerem/urządzeniem końcowym? Będzie to spore ułatwienie w dalszej pracy.

    *Edit
    Proponuję zajrzeć do dokumentacji, zwłaszcza do adc.h File Reference. Sam z ciekawości spróbuję sobie ten ADC obsłużyć.

    **Edit
    Tak na szybko
    Code:

    void ADC_init(void)
    {
       appADCDescriptor.resolution = RESOLUTION_8_BIT;
       appADCDescriptor.sampleRate = ADC_4800SPS;
       appADCDescriptor.voltageReference = AREF;
       appADCDescriptor.bufferPointer = &ADCBuffer;
       appADCDescriptor.selectionsAmount = 1;
       appADCDescriptor.callback = ADCCalback;
       
       HAL_OpenAdc(&appADCDescriptor);
       HAL_ReadAdc(HAL_ADC_CHANNEL0);
    }


    No i oczywiście w funkcji callback odczytujesz z bufora to co odczytał przetwornik.

    ***Edit
    Przed chwilką szukając czegoś dla własnych potrzeb w pliku pdf: BitCloud User Guide, sprawdziłem z ciekawości, czy obsługa ADC została w tej dokumentacji opisana. Rzeczywiście dokumentacja wspomina o przetworniku i w bardzo obrazowy sposób tłumaczy zasadę obsługi przy pomocy tego stosu. Proponuję zerknąć.
  • Użytkownik usunął konto  
  • Poziom 10  
    Witam ponownie, wszystko działa, zaprogramowałem moduły tak, żeby sprawdzały stany wejść ADC 1 i ADC 3. Problemy wystąpiły dwa. Mianowicie kanały przekłamują się nawzajem, tzn. gdy na kanale 1 jest wysokie napięcie jego szczątkowa wartość pojawia się na drugim i faluje. Drugi problem to gdy mam na wejściu ADC napięcie większe od 1,3 V to przetwornik zwraca wartość 1023 i stoi. Nawet gdy napięcie rośnie dalej do 2,5 V. To chyba chodzi o jego rozdzielczość? Jak mogę to zmienić i gdzie dopisać taki takie coś. Widziałem tam u kolegi w zapisie ustawianie jakiejś rozdzielczości ale nie wiem jak tego użyć w moim przypadku. Korzystam tylko z trzech funkcji ADC_open, get i close. Init widziałem w źródłach adc.c gdzieś w plikach na dysku.
  • Użytkownik usunął konto  
  • Poziom 10  
    olosie napisał:
    Norbert1985 napisał:
    Mianowicie kanały przekłamują się nawzajem, tzn. gdy na kanale 1 jest wysokie napięcie jego szczątkowa wartość pojawia się na drugim i faluje. Drugi problem to gdy mam na wejściu ADC napięcie większe od 1,3 V to przetwornik zwraca wartość 1023 i stoi. Nawet gdy napięcie rośnie dalej do 2,5 V.

    Podłączyłeś napięcie odniesienia do AVCC? O ile dobrze pamiętam do tam jest wewnętrzne źródło odniesienia 1,2V (piszę z pamięci), więc wygląda na to że układ działa zupełnie tak jak powinien.
    Jeśli jesteś na krańcu zakresu ADC i chcesz mierzyć większe napięcia to możesz zastosować zwykły dzielnik rezystancyjny, ale to zależy co chcesz mierzyć bo impedancja dzielnika jest mała i możesz obciążać źródło.


    Mam osobny układ, który podaje napięcie z zakresu 0-2,5V. Był on specjalnie tak zaprojektowany żeby dawać takie napięcia, gdyż sugerowałem się maksymalnym napięciem przyjmowanym przez wejście ADC. tam jest chyba napięcie zasialania pomniejszone o 0,3V. więc około 2,5V powinien przyjąć. A jeśli chodzi o dzielnik rezystancyjny to odpada. Nie można jakoś zmienić czegośc gdzieś, żeby mierzył te 2,5V?
  • Użytkownik usunął konto  
  • Poziom 10  
    olosie napisał:
    "Internal reference voltages of nominally 1.1V, 2.56V or AVCC are provided On-chip"
    Jesteś pewny że masz ustawione 2.56 jako napięcie odniesienia? Musisz ustawić bity REFS1 i REFS0 w rejestrze ADMUX. Wtedy będzie 2.56 V.


    Tego nie jestem pewny ale jak widać chyba jest ustawione na 1.1V. Jeszcze gdybyś mógł powiedzieć mi jak ustawić te bity REFS1 i REFS0 to byłbym wdzięczny :)
  • Poziom 15  
    Code:
    void appAdcInit(void)
    
    {
       appAdcDescriptor.resolution = RESOLUTION_8_BIT;
       appAdcDescriptor.sampleRate = ADC_4800SPS;
       appAdcDescriptor.bufferPointer = &AdcBuffor;
       appAdcDescriptor.selectionsAmount = 1;
       appAdcDescriptor.voltageReference = INTERNAL_2d56V;
       appAdcDescriptor.callback = adcCallback;

       HAL_OpenAdc(&appAdcDescriptor);
    }


    To jest mój kod inicjacji ADC, bo okazało się, że potrzebuję go używać :). Dodatkowo daj kondensator między piny AVREF a AGND i AGDN poącz z DGND w jednym punkcje całego układu, kilkadziesiąt nF, to co akurat masz pod ręką.

    *EDIT

    Code:
    HAL_AdcVoltageReference_t  { AREF  = (0 << 6), AVCC  = (1 << 6), INTERNAL_1d1V  = (2 << 6), INTERNAL_2d56V  = (3 << 6) }
    
        adc voltage reference More...


    Tu masz ustawienie bitów z dokumentacji. Zdecydowanie łatwiej robić to przy pomocy API i odwoływać się pól konkretnej struktury niż ręcznie ustawiać wartości bitów.
  • Użytkownik usunął konto  
  • Poziom 10  
    Dziękuję Panowie, pomoc z Waszej strony jest nieoceniona. Fachowcy w zasięgu ręki :) jeszcze raz dziękuję.
  • Poziom 15  
    Przy okazji czy ktoś próbował przesyłać paczki danych większe niż 14 bajtów? Mam strukturę w pliku *.h następującej konstrukcji:
    Code:

    #define     APP_MAX_PACKET_SIZE                  80
    ...
    typedef struct PACK
    {
         uint8_t header[APS_ASDU_OFFSET];                 
         uint8_t data[APP_MAX_PACKET_SIZE];                             
         uint8_t footer[APS_AFFIX_LENGTH - APS_ASDU_OFFSET];
    }    PACK AppMessage_t;
    END_PACK

    Na routerze w data wpisuję 20 znaków i wysyłam przez sieć do koordynatora. W 60% przypadków przechodzi cały pakiet 20 znaków, ale w 40% przypadków przesłane zostaje tylko 14 znaków. Czy ktoś miał problem z przesyłaniem dłuższych ciagów znaków? Dodam, że to co przyjdzie do koordynatora idzie potem do aplikacji napisanej w CVI i w CVI widzę utratę zawsze tej samej ilości bajtów.