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

Uniwersalny moduł dla sieci opartych o układy RFM22/23

tmf 12 Gru 2015 22:09 6801 21
  • Uniwersalny moduł dla sieci opartych o układy RFM22/23
    Witam, chciałbym Wam zaprezentować prostą konstrukcję, która znacznie ułatwia tworzenie i debuggowanie sieci opartych o moduły RFMxx (RFM22/23/63). Są to popularne moduły radiowe, dostępne w bardzo przyzwoitej cenie, oferujące sporo możliwości. Ktoś w czasie, gdy dostępne są tanie moduły WiFi mógłby zapytać, po co używać droższych modułów RFM? Odpowiedź jest prosta – moduły RFM w czasie nadawania pobierają max 28 mA (lub mniej, zależy od wybranej mocy nadajnika), a w czasie odbioru ok. 18 mA. Moduły WiFi potrafią pobierać nawet kilkaset mA (typowo 200 mA). Ta różnica ma olbrzymie znaczenie, jeśli budujemy urządzenia pracujące z ograniczonym dostępem do energii. Dodatkowo w przypadku modułów RFM możemy, co zresztą też jest wadą, stworzyć własny protokół wymiany danych, najlepiej dostosowany do potrzeb. Ale dość o wadach I zaletach obu rozwiązań, nie jest to artykuł porównujący oba rozwiązania.
    Założenia
    Kilka lat temu postanowiłem wzbogacić swoją instalację inteligentnego domu o komunikację radiową i po wielu przemyśleniach wybór padł na układy RFM22/23. Problem w tym, że układy tego typu oferują pewne wspomaganie sprzętowe dla wymiany danych, lecz nie implementują żadnych wyższych warstw OSI. W efekcie programista musi stworzyć własny protokół wymiany danych. A to z kolei jest trudne i wymaga godzin debuggowania. Aby ułatwić sobie życie, a jednocześnie zapewnić możliwość prostej komunikacji z urządzeniami wykorzystującymi te moduły z poziomu PCta, stworzyłem sobie prostą przejściówkę PC-USB-RFM. Ponieważ układ był projektowany kilka lat temu, a na rynku wtedy nie było za dużo procesorów z wbudowanym interfejsem USB, dlatego do komunikacji z PC użyłem popularnego układu FT232R. Jego zaletą jest prostota, wbudowany EEPROM (nie wymaga zewnętrznego jak FT232BL), dobra dokumentacja i bezproblemowość przetestowana przez dziesiątki tysięcy hobbystów, którzy go wykorzystali w swoich projektach.
    Oczywiście, gdybym dzisiaj projektował ten układ, wykorzystałbym najpewniej procesor z wbudowanym USB, np. którąś z XMEGA. Niemniej nawet dzisiaj wykorzystanie FT232 ma pewne zalety.
    Drugą strategiczną decyzją, jaką musiałem podjąć była decyzja o sposobie połączenia FT232 z RFM. RFM wykorzystuje interfejs SPI, czyli teoretycznie można spiąć oba układy bezpośrednio i komunikować się z wykorzystaniem trybu bit-bang układu FT. Takie rozwiązanie ma praktycznie tylko jedną zaletę – prostotę. Ma niestety kilka wad – przede wszystkim możemy zapomnieć o prostej komunikacji z RFM. Każde polecenie lub pakiet będzie musiał być rozkładany na ciąg sygnałów sterujących, przesyłanych przez FT232. Moim celem jednak było stworzenie układu dającego możliwość prostego odbioru i nadawania pakietów np. przy pomocy dowolnego terminala, najlepiej w postaci zbliżonej do poleceń AT. Drugi problem wynikający z bezpośredniego spięcia obu układów jest bardziej subtelny. Wszelkie odbierane dane wędrują do bufora układu FT i stamtąd do PC, skąd muszą być odebrane przez dedykowaną aplikację. Daje to spore opóźnienia i uniemożliwia szybką reakcję na zdarzenia w sieci, oraz reakcję autonomiczną. Musimy pamiętać, że systemy na PC to nie RTOSy i nie mamy żadnej gwarancji obsługi zdarzeń w określonym czasie… Do końca też nie wiedziałem jak wykorzystam tą płytkę, więc pewna uniwersalność też była dla mnie priorytetem. Stąd decyzja była jedna – pomiędzy FT232 a RFM muszę wpiąć jakiś MCU. Ponieważ wiele rzeczy związanych z transmisją sprzętowo robi układ RFM, moc obliczeniowa użytego procesora nie była krytyczna. Stąd też wybrałem dobrze sobie znane układy AVR, konkretniej ATMega162. Wybór o tyle dobry, że bez problemu, jeśli zajdzie potrzeba można dobrać procesor z 32 kB FLASH i wlutować go w miejsce ATMega162. Przy okazji użycia MCU, pojawiła się dodatkowa możliwość. Ponieważ użyty MCU posiada dwa porty USART, stąd jeden wykorzystałem do komunikacji z FT232, a drugi do realizacji opcjonalnego interfejsu RS485. Prezentowana płytka posiada miejsce do przylutowania transceivera MAX485 oraz opcjonalnych terminatorów oraz złącza magistrali RS485. Ponieważ tej opcji w praktyce nie wykorzystałem w zrealizowanym układzie pola te pozostały nie obsadzone.
    Użycie MCU wiąże się jednak z pewnym problemem – jakoś trzeba go zaprogramować. Tu jest kilka możliwości – można wyprowadzić złącze ISP, lecz nie jest to wygodne w małym układzie. Złącze zajmuje miejsce, trzeba zapewnić wygodny dostęp do niego, no i trzeba mieć programator. Druga opcja to bootloader. Jednak w warunkach amatorskich bootloader tylko pozornie rozwiązuje problem braku złącza ISP. Użyty procesor ma obudowę TQFP, a więc programowanie poza układem (w podstawce) jest problematyczne. Należałoby, więc bootloader wgrać w już przylutowany procesor, czyli i tak trzebaby jakoś wyprowadzić złącze ISP. Wykorzystałem więc trzecie rozwiązanie – układ FT232 posiada wystarczająco pinów IO, aby piny niewykorzystane do realizacji transmisji RS232-TTL wykorzystać do stworzenia programatora ISP. W dodatku rozwiązanie to jest wspierane np. przez popularny układ AVRDude i wiele innych programów. Dzięki temu po zbudowaniu układu nie musimy posiadać programatora – procesor możemy zaprogramować bezpośrednio przez USB przy pomocy praktycznie dowolnego programu. W swoim systemie wykorzystałem co prawda oprogramowanie napisane własnoręcznie w tym celu (zintegrowane z resztą systemu), ale oczywiście nie jest to wymagane.
    W efekcie uzyskałem prostą płytkę, o dużych możliwościach, z łatwo zmienialnym firmware.
    MCU zajmuje się translacją poleceń odbieranych z PC na postać zrozumiałą dla RFM23/RS485 i odwrotnie. Doskonale się to sprawdza przy debugowaniu sieci, a różne polecenia, typu włącz/wyłącz jakiś moduł, odczytaj temperaturę i inne realizowane przez sterowniki inteligentnego domu mogę wysyłać wprost z terminala używając zrozumiałych dla człowieka komend.
    Opis układu
    Przejdźmy do schematu elektrycznego. Całość zasilana jest z magistrali USB, co wymusiło sposób realizacji części elektrycznej (schemat poniżej).
    Uniwersalny moduł dla sieci opartych o układy RFM22/23
    Przede wszystkim napięcie na magistrali USB wynosi ok. 5V, natomiast moduły RFM23 wymagają napięcia 3,3V. Aby uniknąć konieczności zastosowania translatora poziomów pomiędzy MCU a RFM, postanowiłem zasilić MCU także napięciem 3,3V (użyty procesor przy tym napięciu osiąga wystarczającą maksymalną częstotliwość taktowania). Z kolei połączenie pomiędzy FT232 a MCU łatwo zrobić w domenie 3,3V, gdyż układ FT232 ma wyprowadzone napięcie VCCIO, służące do zasilania buforów IO tego układu. W efekcie może on pracować z różnymi napięciami zasilającymi bez konieczności stosowania konwerterów napięć (są one wbudowane w układ). Tu pojawia się mały problem – skąd brać napięcie 3,3V? FT232 ma wbudowany regulator napięcia, lecz jego wydajność (o ile pamiętam max 50 mA) jest niewystarczająca do zasilania MCU, modułu RFM23 i potencjalnie transceivera RS485. Stąd zdecydowałem się na dodatkowy stabilizator LDO (IC2). To prosta kostka, niewymagająca wielu elementów zewnętrznych (tylko dwa kondensatory ceramiczne), więc nie ma problemu. Aby być hiperzgodnym ze specyfikacją USB (w zakresie maksymalnego pobieranego prądu w stanie uśpienia) dodałem tranzystor P-MOSFET (Q1), sterowany z FT232. W przypadku uśpienia układu odcina on zasilanie układów w domenie 3,3V i LDO, w efekcie prąd pobierany przez układ jest zgodny ze standardem USB w tym trybie.
    Warto jeszcze przemyśleć taktowanie procesora. Ponieważ generatory wbudowane w procesor wg producenta nie gwarantują stabilności wystarczającej dla poprawnej pracy UART, procesor musi być taktowany z zewnątrz. Należałoby zastosować rezonator kwarcowy – to jednak komplikuje układ. No może nie komplikuje, ale wymaga dodania kwarcu i dwóch kondensatorów. Na szczęście projektanci układu FT232R przewidzieli możliwość wyprowadzenia zegara na jeden z pinów IO. Stąd na wejście XTAL1 procesora podałem zegar generowany przez FT232R (jego częstotliwość można programowo zmieniać). Zaoszczędziłem dzięki temu paru elementów, a procesor taktowany jest stabilnym zegarem, gwarantującym nie tylko poprawną transmisję pomiędzy FT232 i MCU, ale także pomiędzy MCU a magistralą RS485 (połączenie z RFM23 realizowane jest za pomocą synchronicznej magistrali SPI i nie wymaga ono stabilnego taktowania MCU).
    Transceiver RFM23 połączony jest z MCU przez interfejs SPI. Dodatkowo dodałem diody LED2 i LED3 sygnalizujące różne stany pracy układu. Są one sterowane przez MCU, wykorzystałem je do sygnalizacji nadawania i odbioru pakietu danych. Wbrew pozorom jest to bardzo pomocne przy debugowaniu sieci. Widać odbierane pakiety, a jeśli przełączę RFM23 w tryb promiscuous to widzę wszystkie pakiety w mojej sieci. LED1 sygnalizuje zasilanie układu (też bywa przydatne), dodatkowo na module RFM23 jest niebieska dioda sygnalizująca poprawność jego pracy i aktywność – również jest przydatna. Rezystory zostały dobrane tak, aby diody nie raziły, a ich świecenie dało się łatwo obserwować nawet po założeniu obudowy.
    PCB
    Jako, że nie lubię bawić się w domowy wyrób PCB, zleciłem jej wykonanie w firmie MERKAR – mam do nich niedaleko, robią przyzwoite płytki prototypowe, za przyzwoitą cenę. Ze względu na rozmiary (płytka musiała się zmieścić w określonej obudowie) zdecydowałem się na laminat dwustronny, z metalizacją otworów i soldermaską. Pierwotnie płytka jako narzędzie do debugowania miała nie mieć obudowy, więc pomyślałem, że zabezpieczenie wszystkiego soldermaską to dobry pomysł. Powiem szczerze, że czerwona soldermaska + złocenie (tu mnie poniosło, ale w sumie czemu nie zaszaleć, jeśli można) wygląda też optycznie fajnie. A jak powszechnie wiadomo estetyczne układy lepiej działają.
    Zastanawiałem się, czy antenę nie umieścić w postaci nadruku na PCB. Nie byłem jednak pewien uzyskanego zasięgu i moich potrzeb w tym zakresie, pomyślałem więc, że umieszczę tylko pole lutownicze i w finalnym układzie rolę anteny spełnia po prostu odpowiednio dobrany odcinek przewodu, umieszczonego w obudowie. W praktyce to rozwiązanie okazało się wystarczające.
    Pewną kwestią jest zastosowane gniazdo USB. Wcześniej stosowałem gniazda USB typu B (duże, kwadratowe gniazdo), lecz ich jakość i pewność połączenia jest marna. Wtyczka musi pewnie siedzieć w gnieździe, po jakimś czasie się wyrabia, a całość jest duża i toporna. Gniazda mikro-USB w czasie, kiedy projektowałem ten układ nie były jeszcze popularne, więc wybór padł na gniazdo mini-USB. Sprawdza się ono nieźle, jest małe (niskie), dzięki czemu całość mieści się w niewielkiej obudowie.
    Poniżej przedstawiam rysunek PCB i projekt w formacie brd (Eagle).
    Uniwersalny moduł dla sieci opartych o układy RFM22/23 Uniwersalny moduł dla sieci opartych o układy RFM22/23 Uniwersalny moduł dla sieci opartych o układy RFM22/23
    Uruchomienie
    Układ nie wymaga żadnego specjalnego uruchamiania. Ze względu na mały raster układu FT232 warto przez podpięciem całości pod USB sprawdzić czy nie ma zwarć pomiędzy pinami. Po wpięciu układu pod USB OS powinien wykryć układ FT232 i jeśli to Windows poprosić o sterowniki (Linuks ma je zazwyczaj wbudowane). Od tego momentu układ jest gotowy i oczekuje na zaprogramowanie.
    Należy jeszcze oczywiście wlutować antenę. Tak jak pisałem, wystarczający jest kawałek przewodu o długości zależnej od częstotliwości pracy modułu RFM23 (są dostępne na 433 i 868 MHz). Zasięg na takiej antenie spokojnie przekracza 100m (więcej nie testowałem). Jeśli zajdzie taka potrzeba antenę można stuningować – po prostu odcinamy kawałek anteny (po jeden do kilku milimetrów jednorazowo) obserwując moc odbieranego sygnału w drugim odbiorniku (rejestr RSSI). W ten sposób możemy dopasować antenę – nie jest to idealne rozwiązanie, ale proste i dostępne dla hobbysty.
    Należy tez pamiętać o przestawieniu fusebitów MCU (jeśli korzystamy z taktowania przez FT232) i konfiguracji samego układu FT232 programem MProg udostępnianym przez FTDI.
    Efekt
    Całość mieści się w małej, plastikowej, półprzezroczystej obudowie. Dzięki temu, że obudowa jest półprzezroczysta ładnie widać diody sygnalizujące pracę układu.
    Ku mojemu zaskoczeniu, układ ruszył od razu, okazało się, że wszystko jest ok i nie wymaga przeróbek. Całość w 100% spełniła moje oczekiwania, ułatwiając (a właściwie umożliwiając) mi napisanie własnego protokołu komunikacji i stworzenie własnej sieci opartej na modułach RFM22/23/63.
    Poniżej kilka zdjęć zmontowanego układu:
    Uniwersalny moduł dla sieci opartych o układy RFM22/23 Uniwersalny moduł dla sieci opartych o układy RFM22/23 Uniwersalny moduł dla sieci opartych o układy RFM22/23 Uniwersalny moduł dla sieci opartych o układy RFM22/23 Uniwersalny moduł dla sieci opartych o układy RFM22/23 Uniwersalny moduł dla sieci opartych o układy RFM22/23

  • #2 13 Gru 2015 06:58
    NOWY_UCZEŃ
    Poziom 12  

    Czy kolega mógłby udostępnić samą bibliotekę Eagle modułu RFM22 :)

  • #3 13 Gru 2015 09:50
    666w
    Poziom 9  

    Dzień dobry

    Z jakich bibliotek kolega korzystał? Własne czy z książek?

  • #4 13 Gru 2015 10:12
    tmf
    Moderator Mikrokontrolery Projektowanie

    NOWY_UCZEŃ napisał:
    Czy kolega mógłby udostępnić samą bibliotekę Eagle modułu RFM22 :)


    Mógłbym, biblioteka w załączeniu.

    666w napisał:
    Dzień dobry

    Z jakich bibliotek kolega korzystał? Własne czy z książek?


    Póki co jeszcze nie widziałem książki opisującej RFM, więc skazany jestem na własne.

  • #5 13 Gru 2015 11:06
    tmf
    Moderator Mikrokontrolery Projektowanie

    666w napisał:
    są np tutaj (RFM69 ,12, 70, 73)
    ...


    Proszę nie żartuj. Mówimy o obsłudze wyższych warstw OSI, a nie prostej komunikacji point-to-point. Takie funkcje to można w parę minut skrobnąć, a nawet tego nie trzeba, bo HopeRF udostępnia kody realizujące podstawową wymianę danych za darmo.
    Poza tym wskazane przez ciebie kody nie są publicznie dostępne, co za tym idzie niemożliwa jest ocena ich jakości przez szersze grono i niejasne są zasady ich licencjonowania - autor nie życzy sobie ich publikacji, w efekcie niemożliwe jest uzyskanie pomocy na tym forum.

  • #6 13 Gru 2015 12:21
    tatanka
    Poziom 19  

    Czy nie prościej było zastosować 2-3 szeregowo połączone diody zamiast stabilizatora :?:

  • #7 13 Gru 2015 12:27
    tmf
    Moderator Mikrokontrolery Projektowanie

    tatanka napisał:
    Czy nie prościej było zastosować 2-3 szeregowo połączone diody zamiast stabilizatora :?:


    IMHO takie rozwiązanie to partyzantka. Czasami takie rozwiązania się stosuje, lecz jaką to ma przewagę nad użyciem jak Bóg przykazał LDO? No i Uf mocno zależy od If, a w tym układzie pobierany prąd zmienia się w dużym zakresie (od kilku do nawet kilkuset mA jeśli wykorzystamy RS485).

  • #8 13 Gru 2015 12:40
    ShEvU_elektro
    Poziom 25  

    Bardzo fajne rozwiązanie :-)
    Sam mam kilka typów modułów w domu, które pracują na RFM22.
    Czy udało się koledze osiągnąć większe prędkości komunikacji pomiędzy modułami aniżeli 200kbps ?


    P.S Warto wspomnieć, że RFM22 oparte są o chip Si4432, oraz, że są również inne, tańsze moduły właśnie na tych chip-ach.

  • #9 13 Gru 2015 12:46
    tmf
    Moderator Mikrokontrolery Projektowanie

    Nie, nie próbowałem uzyskać więcej niż wynika ze specyfikacji. Dla moich potrzeb większe szybkości nie były potrzebne.

  • #10 13 Gru 2015 16:19
    sorry1
    Poziom 12  

    Podoba mi się, mimo że układ niewielkiej skali, przemyślany został każdy detal.
    Jedynie płytkę można było zrobić mniejszą o 1/3 obecnej, chyba że obudowa była wyznacznikiem wymiarów, to się nie czepiam.

    Czy mógłbyś powiedzieć coś więcej o całym projekcie, tzn inteligentny dom?

  • #11 13 Gru 2015 16:36
    tmf
    Moderator Mikrokontrolery Projektowanie

    @sorry1 Tak, celem było zmieszczenie się w obudowie, którą posiadałem. Ponieważ nie miałem mniejszej, PCB zostało dopasowane do tej, którą miałem (jest to bardzo popularna i tania obudowa).
    Co do reszty projektu - jest to sieć czujników i elementów wykonawczych komunikujących się między sobą czymś w stylu hybrydy RS485 i CAN (ze względu na cenę zastosowałem RS485, realizując inne funkcje CAN, m.in. multimaster programowo). A że trzeba iść z duchem czasu dodałem możliwość pracy elementów połączonych siecią radiową. Niewiele osób wie, ale na RFMxx można zbudować sieć przypominającą ZigBee (a nawet kompatybilną z nią) i korzystać ze wszystkich zalet tej sieci - przekazywanie danych przez węzły, tryby low-power, usypianie węzłów itd. W przypadku, gdy krytyczne jest niskie zużycie energii naprawdę można się tu wykazać. Oczywiście można kupić moduły ZigBee, lecz cena...
    Kiedyś cały idom prowadziłem jako projekt open source/hardware ale ze względu na niewielkie zainteresowanie i chęć pomocy innych. a także czas potrzebny na prowadzenie strony domowej projektu pomysł zarzuciłem.

  • #12 13 Gru 2015 16:58
    Damian_Max
    Poziom 14  

    Witam,
    jestem bardzo zainteresowany Pańskim projektem, szczególnie dwa fragmenty ostatniej wypowiedzi:

    Cytat:
    na RFMxx można zbudować sieć przypominającą ZigBee

    (mam taką świadomość) oraz:
    Cytat:
    Kiedyś cały idom prowadziłem jako projekt open source/hardware ale ze względu na niewielkie zainteresowanie i chęć pomocy innych. a także czas potrzebny na prowadzenie strony domowej projektu pomysł zarzuciłem.

    To mnie najbardziej zaciekawiło, ponieważ sam przymierzam się do budowy takiego systemu -- sieci czujników (rzadziej elementów wykonawczych) komunikujących się po sieci przewodowej protokołem rs232/485 uzupełniając bezprzewodową komunikacją na modułach RFMxx (także rozpatrywałem typ projektu opensource).

    Stąd pytanie, czy gdyby znalazły się darmowe siły przerobowe, to byłaby możliwość dołączenia się do całego projektu?

    Damian.

  • #13 14 Gru 2015 15:35
    GanzConrad
    Poziom 21  

    tmf napisał:
    Kiedyś cały idom prowadziłem jako projekt

    Czy to było to?
    _idom.wizzard.one.pl_ [link nieczynny, ponieważ projekt "umarł", a pytanie właśnie tego dotyczy ;-)]
    Z tego co pamiętam, ten projekt był oparty na 1-wire (przynajmniej na początku), ale nie pamiętam już na jakich MCU.

  • #14 14 Gru 2015 18:30
    nsvinc
    Poziom 34  

    Calkiem sensowny diwajs. 5 lat temu popelnilem bardzo podobny uklad, tyle ze na STM32F103RB, w ilosci 7 sztuk, do testowania implementacji pewnego protokolu. RFM22B to swietne moduly, nie maja tylu bledow co poprzednik, i nie wieszaja sie.
    Jednak ten procek tutaj, to bolaczka. stos sensownego protokolu sieciowego zamorduje biedna atmege dajac RTTI w setkach ms. Dla przykladu, moj protokol (wcale nie prosty) na wspomnianym ARMie dawal mi 800-1200us dla pustej ramki kontrolnej...
    No i brak DMA da sie we znaki przy duzych ramkach. Ale wciaz do testow sieci uklad jest OK.

  • #15 14 Gru 2015 19:21
    tmf
    Moderator Mikrokontrolery Projektowanie

    GanzConrad napisał:
    tmf napisał:
    Kiedyś cały idom prowadziłem jako projekt

    Czy to było to?
    _idom.wizzard.one.pl_ [link nieczynny, ponieważ projekt "umarł", a pytanie właśnie tego dotyczy ;-)]
    Z tego co pamiętam, ten projekt był oparty na 1-wire (przynajmniej na początku), ale nie pamiętam już na jakich MCU.


    Tak, to było to. Początkowo był to 1-wire, porem modyfikacja 1-wire z wykorzystaniem RS485 jako warstwy fizycznej i tak już zostało. Potem to obudowałem w multimaster i kontrolę przesyłu pakietów. Działa wyśmienicie, implementacja prosta i krótka (mieści sie w bootloaderze ATMegi). Początkowo zrobiłem stronę mając nadzieję na złapanie kilku pasjonatów systemów inteligentnych domów, niestety zainteresowania nie było, dokładniej było - mnóstwo chętnych na zakupienie gotowców. Gdybym z tego żył to bym się cieszył :)
    4 lata temu dodałem do tego obsługę sieci bezprzewodowej i stąd ten moduł.

  • #17 14 Gru 2015 19:37
    tmf
    Moderator Mikrokontrolery Projektowanie

    nsvinc napisał:
    Calkiem sensowny diwajs. 5 lat temu popelnilem bardzo podobny uklad, tyle ze na STM32F103RB, w ilosci 7 sztuk, do testowania implementacji pewnego protokolu. RFM22B to swietne moduly, nie maja tylu bledow co poprzednik, i nie wieszaja sie.
    Jednak ten procek tutaj, to bolaczka. stos sensownego protokolu sieciowego zamorduje biedna atmege dajac RTTI w setkach ms. Dla przykladu, moj protokol (wcale nie prosty) na wspomnianym ARMie dawal mi 800-1200us dla pustej ramki kontrolnej...
    No i brak DMA da sie we znaki przy duzych ramkach. Ale wciaz do testow sieci uklad jest OK.


    Nie jest tak źle. Atmega162 ma 1kB SRAM, większe mają 2 kB. Niby niewiele, ale moim celem było stworzenie i testowanie protokołu wymiany danych składającego się z ramek max 64 bajtowych, z możliwie małym narzutem, prostym, do implementacji w urządzeniach zasilanych bateryjnie. Poza tym tu ATMega pośredniczy tylko w nadawaniu/odbiorze takich pakietów i co najwyżej przesyła je do PC do programu współpracującego z siecią. Dla protokołu założenie było, że czas odpowiedzi jest nie dłuższy niż 10 ms (responsywność elementów wykonawczych). Biorąc pod uwagę, że RFM22/23 nadaje max 128 kbps, to w ciągu podanego przez ciebie czasu (1200 us) i tak zdąży nadać tylko jakieś 153 bity, czyli 19 bajtów. Ponieważ używany przeze mnie protokół ma niewielki narzut, to w tym czasie da się przesłać sensowną ramkę danych. Także ATMega tu zupełnie wystarcza. Gdyby chodziło o implementację TCP/IP to istotnie byłby problem z pamięcią.
    DMA przy tak wolnej transmisji też nie jest krytyczne - można jeśli ktoś się uprze zrobić wysyłanie kolejnych danych transakcyjnie w oparciu o przerwania. Sprawę mocno ułatwia, że RFM22/23 ma 64 bajtowe bufory odbiornika i nadajnika, więc procesor może wrzucić w nie kilka pakietów i w międzyczasie przetwarzać inne. Inną przydatną funkcją jest możliwość filtrowania pakietów przez RFM - ustawiasz maskę i MCU już nie odbiera pakietów nie przeznaczonych dla niego, więc duży ruch w sieci go nie zabije.

    Dodano po 2 [minuty]:

    dondu napisał:
    tmf napisał:
    Powiem szczerze, że czerwona soldermaska + złocenie (tu mnie poniosło, ale w sumie czemu nie zaszaleć, jeśli można) wygląda też optycznie fajnie.

    Ile zapłaciłeś za to złoto? :D


    Już nie pamiętam, ale dopłata była raczej symboliczna, bardziej boli wydłużenie czasu oczekiwania na płytki. Niemniej warto skorzystać - do złoconej płytki super się lutuje nawet po jakimś dłuższym czasie, czego nie można powiedzieć o cynowaniu, szczególnie chemicznym, po którym płytkę trzeba zlutować praktycznie natychmiast. Tylko nieco lepiej jest w przypadku cynowania galwanicznego.

    Dodano po 3 [minuty]:

    Damian_Max napisał:

    Cytat:
    Kiedyś cały idom prowadziłem jako projekt open source/hardware ale ze względu na niewielkie zainteresowanie i chęć pomocy innych. a także czas potrzebny na prowadzenie strony domowej projektu pomysł zarzuciłem.

    To mnie najbardziej zaciekawiło, ponieważ sam przymierzam się do budowy takiego systemu -- sieci czujników (rzadziej elementów wykonawczych) komunikujących się po sieci przewodowej protokołem rs232/485 uzupełniając bezprzewodową komunikacją na modułach RFMxx (także rozpatrywałem typ projektu opensource).

    Stąd pytanie, czy gdyby znalazły się darmowe siły przerobowe, to byłaby możliwość dołączenia się do całego projektu?

    Damian.


    Na razie trudno mi odpowiedzieć na to pytanie, bo mam natłok innych prac. Jakby sie zebrała większa grupka zapaleńców to można wrócić do tematu. Niestety moje doświadczenia są złe, bo albo pojawiają się osoby bez doświadczenia w projektowaniu takich rzeczy i porywają się z motyką na Słońce, co wiadomo jak się kończy, albo pasożyty, które po otrzymaniu materiałów już się nie odzywają :)

  • #18 16 Gru 2015 23:07
    gRRubasek
    Poziom 14  

    Zastanawia mnie wybór procesora. Czemu nie wziąłeś np 32u4 czy jeszcze lepiej xmegi z usb?
    Usb załatwione żadnych kombinacji . Mam na koncie układy z transceiverami RFM70 i świetnie to działa.

  • #19 17 Gru 2015 07:14
    Damian_Max
    Poziom 14  

    Cytat:
    Na razie trudno mi odpowiedzieć na to pytanie, bo mam natłok innych prac.

    To wspaniale, ponieważ tak naprawdę, chciałem zająć się tym tematem w lato (~za pół roku).
    Ja nie mam ogromnego doświadczenia, ale w porównaniu do motyki to mam już prototyp rakiety ;-).
    Czy się zbierze grupa zapaleńców hm.. (?), jest ktoś jeszcze chętny?

    Cytat:
    Zastanawia mnie wybór procesora. Czemu nie wziąłeś np 32u4 czy jeszcze lepiej xmegi z usb?
    Usb załatwione żadnych kombinacji . Mam na koncie układy z transceiverami RFM70 i świetnie to działa.


    Pytanie mam, czym jest 32u4? A czy to nie jest tak że xmegi to inna para kaloszy? Zakładając że autor programował AVR-y to to nie jest przesiadka taka sama jak na stm-y?
    Chyba ze względu na częstotliwość nośną RFM22 w porównaniu do RFM70 będzie nadawało na dalsze odległości.

  • #20 17 Gru 2015 12:40
    tmf
    Moderator Mikrokontrolery Projektowanie

    gRRubasek napisał:
    Zastanawia mnie wybór procesora. Czemu nie wziąłeś np 32u4 czy jeszcze lepiej xmegi z usb?
    Usb załatwione żadnych kombinacji . Mam na koncie układy z transceiverami RFM70 i świetnie to działa.


    Wyjaśnienie jest w pierwszym poście - układ powstał 4 lata temu. Nawet pisałem, że na dzisiaj wziąłbym XMEGA.

    Dodano po 2 [minuty]:

    Damian_Max napisał:

    Cytat:
    Zastanawia mnie wybór procesora. Czemu nie wziąłeś np 32u4 czy jeszcze lepiej xmegi z usb?
    Usb załatwione żadnych kombinacji . Mam na koncie układy z transceiverami RFM70 i świetnie to działa.


    Pytanie mam, czym jest 32u4? A czy to nie jest tak że xmegi to inna para kaloszy? Zakładając że autor programował AVR-y to to nie jest przesiadka taka sama jak na stm-y?
    Chyba ze względu na częstotliwość nośną RFM22 w porównaniu do RFM70 będzie nadawało na dalsze odległości.


    Myślę, że jako autor dwóch książek o programowaniu XMEGA dałbym radę :)
    RFM22/23 istotnie ma większy zasięg, z kolei RFM73 ma pewne dodatkowe ułatwienia w transmisji - m.in. automatyczne ack i ponowną wysyłkę pakietów w przypadku błędów. Inna sprawa, że taka funkcjonalność to parę dodatkowych linii kodu...

  • #21 17 Gru 2015 13:16
    nsvinc
    Poziom 34  

    ->tmf
    Wywnioskowałem, że stosujesz CSMA/CA. Jak Twój prosty protokół się sprawdzi w sieciach, które mają np. 100 nodów? Albo, co gorsza, w srodowisku gdzie kilka duże sieci pracują na tym samym kanale, niemal w tym samym miejscu?
    Nasuwa się, że zaimplementowałeś ponawianie po losowym czasie + CS?

    A jeśli to jest sieć czujników i układów wykonawczych, to czemu nie TDMA?

    tmf napisał:
    [...]i tak zdąży nadać tylko jakieś 153 bity, czyli 19 bajtów

    Właśnie, dlatego też pisałem o ramce kontrolnej, która służy do synchronizacji sieci, jest mała a więc trudniej ją zakłócić.
    tmf napisał:
    ustawiasz maskę i MCU już nie odbiera pakietów nie przeznaczonych dla niego, więc duży ruch w sieci go nie zabije.

    Wszystko pięknie dopóki protokół nie obsługuje forwardowania. Nody które to obsługują, muszą w setki us podjąć decyzję co zrobić z odebraną ramką - każdą ramką należącą do sieci.

    BTW, RFM22B/23B wyciąga do 256kbps. Im szybciej, tym lepiej - mniejsze prawdopodobienstwo, że w transmisję wetnie się pakiet nadawany przez obce urządzenie. Obecnie utrapieniem na 433 i 868 są podzielniki ciepła, które generują smieciowy ruch jednokierunkowy, o losowych porach...
    Cała transakcja powinna generalnie trwać jak najkrócej, bo ACK też można zakłócić - wtedy marnujemy nie dosyc że czas on-air tej transakcji, to jeszcze czas reakcji urządzenia docelowego.

  • #22 17 Gru 2015 17:33
    tmf
    Moderator Mikrokontrolery Projektowanie

    @nsvinc Tak, stosuję CSMA/CA, z losowym czasem CS (dokładniej nie do końca losowym bo zależnym od adresu noda, co redukuje prawdopodobieństwo konfliktu). Dlaczego nie TDMA? Pisałem ten protokół lata temu (4 lata temu implementowałem go na RFM23, a napisałem jakieś 8 lat temu i to były moje początki z sieciami). Poza tym to sieć do automatyki domowej - niewielki ruch, mała szansa na konflikty, nawet jeśli jest sporo urządzeń, krótkie pakiety. Na RFM zaimplementowałem też zmianę kanału, także przy zestawianiu połączenia dwa urządzenia mogą przejść na inny kanał, dzięki czemu inne urządzenia z sieci ich nie zakłócają - dodałem to tylko w jednym celu - żeby prosto zrobić transmisję głosu i video po sieci jeśli zajdzie taka potrzeba. Kanały też mogą się zmienić automatycznie, jeśli jakiś jest zaszumiony. Oczywiście masz rację, że node obsługujący forwardowanie to już inna zabawa i tu moc (a właściwie bufor na pakiety) przydaje się większy i ATMega162 już ma problem. Dokładniej ma, jeśli mamy dłuższe pakiety, przy pakietach kilkunastobajtowych ciągle dla niewielkiego ruchu nie ma problemu. A dla takch założeń projektowałem sieć.
    Swoją drogą to muszę przyznać, że napisanie takiego protokołu od podstaw sporo mnie nauczyło i było naprawdę ciekawym wyzwaniem.