Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Europejski lider sprzedaży techniki i elektroniki.
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

RFM22B - Brak komunikacji między TRX'ami

Jado_one 20 Cze 2014 21:13 1374 11
  • #1 20 Cze 2014 21:13
    Jado_one
    Poziom 22  

    Witam,

    Przysiadłem ostatnio nad uruchomieniem komunikacji między dwoma RFM22B-S2-860.
    Komunikacja SPI między RFM'ami, a mikrokontrolerami wydaje się prawidłowa - układy odpowiadają, zmieniają swoje parametry (np. zmiana funkcji GPIO, zmiana f-zegara wyjściowego), następuje inicjalizacja wysyłania pakietu, pojawia się przerwanie nIRQ, po wysłaniu pakietu, itp....Układy przechodzą w stany TX i RX (co mogę obserwować na GPIO_0 i GPIO_1 ustawionych jako wyjścia tych sygnałów (sterują wejściami RX i TX modułu).

    Moje wrażenie jest takie jakby układy po prostu fizycznie nie nadawały nośnej.
    Próbowałem "podsłuchiwać" czy coś z anten wychodzi za pomocą małego radyjka UKF - ale jakoś nic specjalnego nie słychać (bardziej słychać zakłócenia od transmisji I2C i SPI).
    Zastanawiam się czy miernik pola w.cz. dałby radę coś tu pokazać? (musiałbym go sobie zmajstrować).

    Płytki RFM22 są nalutowane na większe płytki z pinami (pod płytką modułów wylana masa), do których mogę podłaczać kabelki łączące moduły z mikrokontrolerami. Płytki mają dodane kondensatory 100uF i 100nF w zasilaniu. Antena z 8cm drutu przylutowana do płytki-matki.

    Scalaki zime - nie grzeją się (nie wiem jaka jest norma bo to moje pierwsze RFM'y).

    Jak sprawdzić, czy moduły faktycznie nadają?

    Konfiguracja modułów w/g przykładów z sieci, arkusza kalkulacyjnego, aplikacji dostarczanej przez SiliconLabs oraz datasheet'a i własnego kilkudniowego kombinowania.

    Robiłem podgląd RX na jednym z pinów GPIO - cały czas tam jakieś śmieci widać, ciągiem. Jeśli coś "nadaję" z drugiego nadajnika, nie widać tam żadnej róznicy - żadnej regularności, żadnej preambuły.... (o ile oczywiście dobrze rozumiem funkcję podglądu sygnału RX).
    Ki czort?

    Trochę mi się kończą pomysły - chyba najważniejsze teraz to sprawdzić czy jakaś nośna wychodzi z nadajników? Da się?

  • Pomocny post
    #2 20 Cze 2014 23:48
    alagner
    Poziom 25  

    Spróbuj jednym wystawić/wyłączyć nośną (na dłuższy czas), a drugim odczytać RSSI. Ew. sprawdź po poborze prądu. Nie wiem jak RFMy, ale np. moduły TI bardzo dokładnie trzymają się specyfikacji i patrząc na amperomierz można z dużą dokładnością określić co się właśnie z chipem dzieje.

  • #3 25 Cze 2014 17:59
    Jado_one
    Poziom 22  

    Zrobiłem tak jak mówiłeś.
    Ustawiłem scalak w tryb direct mode, asynchronous, z wejściem modulacji przez GPIO_2.
    Wysłałem komendę TX_on przez SPI, scalak przeszedł w tryb TX co mogłem obserwować mierząc stan wyjścia GPIO_1 ustawionego w tryb 'podglądu' stanu TX, oraz niezależnie, odczytując bajt statusowy (02h) scalaka, gdzie też widać było odp. dla stanu TX ustawione bity.
    Niestety scalak w tym trybie pobiera ok. 11.3 mA (w trybie RX - 20,3mA, a w trybie Tuned - 10,4mA), a powinien przy 17dBm jakie ustawiłem, pobierać ok 50+ mA @ 3,3V (przy pełnej mocy 20dBm powinien pokazać ponad 80mA w/g datasheetu).
    Coś jest więc nie tak z nadawaniem.

    Pytanie teraz co?

    Czy to jest kwestia sprzętowa? Może np. coś związanego ze sterowaniem wejściami RX i TX modułu? (chociaż ja podaję sygnały na te wejścia z GPIO_0/1 - w/g datasheetu).

    Czy może jest coś takiego w ustawieniach konfiguracyjnych, co powoduje blokadę generatora/układu nadawczego/itp?....

    Ewentualnie - trafiły się wadliwe układy, ale były kupowane w TME, nie na Allegro czy gdzieś od kogoś z drugiej ręki....

    Co tu można jeszcze sprawdzić?

    Dodano po 1 [godziny] 4 [minuty]:

    Jest mały postęp - dzięki głupiemu przypadkowi coś się dowiedziałem :-)

    Przewód zasilający Vdd idący do miernika celem pomiaru prądu zasilania, coś "nie zakontaktował" (jak to zwykle przy takich polączeniach bywa) i układ się zresetował - czyli przywrócił sobie defaultowe ustawienia. No i prąd nadawania wzrósł do 18mA.
    Zakomentowałem więc wszystko oprócz ustawiania mocy nadawczej i teraz prąd nadawania zgodnie z katalogiem wynosi 52mA @ 17dBm @ 3V3.

    A zatem coś w konfiguracji "chrzani" nadawanie - teraz będę mógł odkomentowywać poszczególne linie i dowiem się które to ustawienie (mam nadzieję ;-).

    Dodano po 2 [godziny] 40 [minuty]:

    No i sprawa jasna.
    Winny był rejestr nr 52, który w RFM22B nie występuje :-)
    (a przynajmniej oficjalnie nie).
    Korzystając jednak z konfiguracji znalezionych w sieci "nie wszystko ziarno udało mi się od plew oddzielić" i rejestr ten "został się" w mojej konfiguracji.
    Prawdopodobnie występował on w RFM22 - ale bez B na końcu.
    Tak więc - jakby ktoś w przyszłości miał problemy z nadawaniem, a korzystał z kodów znalezionych w sieci, to niech sprawdzi ów rejestr - czy czasem u niego nie występuje i nie bruździ ;-)
    Jak widać nadmiarowość czasem może przeszkadzać.

    Swoją drogą w RFM22B istnieje jeszcze jeden rejestr: 58h - według dokumentacji, też nie występujący, ale tym razem jest wymagany i używany - w arkuszu kalkulacyjnym obliczającym wartości rejestrów w RFM22B jest wyszczególniony.

    Tematu na razie nie zamykam, bo może ktoś będzie chciał się w tej materii jeszcze wypowiedzieć albo miał pytania.

    W każdym razie komunikacja między modułami ruszyła i teraz mogę skupić się na protokole transmisji, zamiast szukaniu "dziury w całym" :-)

    Dzięki za podpowiedź koledze Alagner - trochę mnie ona zmobilizowała do "grzebania w rejestrach", aby ustawić tryb direct i zrobić próbę z poborem prądu.
    A już chciałem kupować moduł telewizji DVB +DAB + FM na scalaku RTL'a, coby to przerobić na radio SDR i za pomocą tego sprawdzić co się dzieje na częstotliwości 860MHz ;-)

  • #4 27 Cze 2014 21:48
    Jado_one
    Poziom 22  

    Zastanawiam się nad jedną sprawą odnośnie komunikacji bezprzewodowej.
    Czy warto nadawać małymi mocami - takimi które pozwalają na poprawną komunikację (nie zwiększać ich ponad potrzebę), czy tez lepiej pracować blisko mocy maksymalnej cały czas?
    Chodzi o "wybicie się" ponad szum tła.
    Bo tzw. treshold sygnału RSSI można ustawić tuż ponad poziomem szumów i zakłóceń i wtedy będziemy mogli odbierać nawet słabe mocowo sygnały, ale róznica poziomów jest dosyć mała i mimo wszystko może sporadycznie dochodzić do wyzwalania RSSI treshold przez jakieś zakłócenia.
    Podniesienie poziomu treshold znacznie wyżej ponad poziom tła odcina zakłócenia, ale wtedy trzeba pracować większą mocą nadajnika, żeby nośna wyzwalała sygnał treshold RSSI.
    Zastanawiam się, czy warto się bawić tu w jakieś procedury "dostrajania" poziomu treshold do minimum ponad tło i dobieranie mocy nadawania - czy też odpuścić to sobie i dać mocny sygnał na stałe (i wysoki poziom odcięcia).

  • #5 28 Cze 2014 02:04
    alagner
    Poziom 25  

    Z moich doświadczeń: należy dobrać moc pod zasięg i zwyczajnie sprawdzić to na lotnisku czy innej dużej polanie a potem w warunkach docelowych. Większa moc raczej nie zaszkodzi, ale już przy zasilaniu bateryjnym należy uwzględniąć pobór prądu. A klocki zaczynają się dziać kiedy używamy dwóch różnych chipów w komunikacji dwukierunkowej, bo np. jeden może mocniej nadawać, ale mieć gorszą czułość, drugi odwrotnie. Wtedy dotrzemy do tych drugich, ale odpowiedzi i tak nie usłyszymy itd. Temat rzeka, polecam kombinować, nie ma tu jedynej słusznej drogi. No i pamiętaj o dobraniu anteny, to może zmienić naprawdę wiele.

  • #6 28 Cze 2014 12:16
    Jado_one
    Poziom 22  

    Ano temat rzeka.

    W moim konkretnym (i zapewne mało odkrywczym ;-)) przypadku chodzi o automatykę domową czyli sterowanie urządzeniami, odczytywaniu danych z czujników, itp...
    Urządzenia będą raczej na stałe wpięte do zasilania, więc o zużycie mocy nie muszę się martwić (no może gdybym chciał zrobić do tego jakiegoś bezprzewodowego pilota).
    Z tego co czytałem to i tak najwięcej mocy traci się w trybie RX (u mnie moduł pobiera ok 20mA w tym stanie - przy załączonym PLL), bo amperaż może mniejszy, ale czas trwania stanu zdecydowanie dłuższy.
    Dlatego stosuje się techniki usypiania z okresowym automatycznym wybudzaniem, żeby trochę prądu zaoszczędzić.

    Na razie widzę, że nawet na najmniejszej mocy (+1dBm) - jeszcze bez protokołu - układy widzą się w całym mieszkaniu. Mam zamiar jednak w protokole wprowadzić potwierdzenia poprawnego odbioru ramek (jako 'response') - i tak się zastanawiałem, czy dobrym pomysłem byłoby stopniowe zwiększanie mocy nadawania podczas kolejnych powtórek nadawcy - jeśli nie uzyskał on potwierdzenia.
    W sumie - mając już oprogramowany protokół - można by pomyśleć o rozkazach typu "ustalenie poziomu mocy nadawania i poziomu treshold" pomiędzy stacją bazową, a nodami.
    Może nawet w postaci rozkazu rozgłoszeniowego do wszystkich.
    Tyle, że ponieważ układy widzą się nawet na najmniejszej mocy - nie wiem czy to potrzebne :-)

    Tak a propos komunikacji z innymi modułami - RFM22B to już "ginący gatunek" (w sumie to na życzenie producenta, który wymusił wstrzymanie produkcji tego układu na rzecz jego następców), więc naturalną koleją rzeczy trzeba będzie myśleć o nowszej generacji nadajników. Mówiłeś o wymianie danych między modułami, ale chyba każdy z nich różni się na tyle, że nie da się ich bezpośrednio skomunikować (no chyba, że w trybie direct i za pomocą procesora emulować pakiet).

    Niektóre jak widziałem, mają nawet swoje gotowe protokoły transmisji (nRF2401+) - nie wiem (nie wczytywałem się aż tak bardzo w pdf'a) czy można je wyłączyć, czy są już na stałe.
    Zawsze można założyć jakąś bramkę w stacji bazowej pomiędzy różnymi podsieciami - ale to zmusza do "ciągnięcia" pakietów przez stację bazową (co nie zawsze musi być wadą).

    Jak sobie radzić ze zmieniającą się sytuacją na rynku modułów RF? Przeprojektowywać za każdym razem układy, program, itp?

  • #7 28 Cze 2014 13:30
    tmf
    Moderator Mikrokontrolery Projektowanie

    Co do mocy - jeśli nie ogranicza źródło zasilania to ew. warto ją redukować jeśli: nadajesz coś na pobliskim kanale (zmniejszenie przesłuchów), lub ten sam kanał musisz wykorzystać w nieznacznie oddalonych urządzeniach. Wtedy nie będą się one wzajemnie istotnie zakłócały. Ew. powodem może być konieczność certyfikacji urządzenia - mniejsza moc - mniejsze problemy. Weź też pod uwagę, że moc może zależeć od długości pakietu. Przy małej mocy krótkie pakiety moga być odbierane poprawnie, jednak dla zadanego prawdopodobieństwa błędu, związanego z użyta mocą, przy dłuższym pakiecie sumaryczne prawdopodobieństwo błędu może być nieakceptowalnie duże.
    Jeśli chodzi o interoperacyjność układów RFM - praktycznie wszystkie na poziomie transmisji są ze sobą kompatybilne. To znaczy, że zmusisz RFM22, czy 63 do odebrania pakietu nadanego przez RFM12. Ba, można je nawet tak skonfigurować, aby z pewnymi ograniczeniami były np. kompatybilne z protokołem ZigBee.
    A propos twoich problemów - układy RFM mają bogate rejestry stanu - jak masz jakiś z nimi problem to zacznij zawsze analizę od tych rejestrów - jest tam bardzo dokładna diagnoza, która pozwala się szybko zorientować w czym rzecz.

  • #8 28 Cze 2014 13:45
    tymon_x
    Poziom 30  

    Jado_one napisał:
    Tak a propos komunikacji z innymi modułami - RFM22B to już "ginący gatunek" (w sumie to na życzenie producenta, który wymusił wstrzymanie produkcji tego układu na rzecz jego następców), więc naturalną koleją rzeczy trzeba będzie myśleć o nowszej generacji nadajników. Mówiłeś o wymianie danych między modułami, ale chyba każdy z nich różni się na tyle, że nie da się ich bezpośrednio skomunikować (no chyba, że w trybie direct i za pomocą procesora emulować pakiet).

    Rozejrzyj się za transciever'ami kompatybilnymi z standardem IEEE 802.15.4. Normalizuje warstwę fizyczną i łącza danych. Sam standard jest zgodny z pasmem dla 868MHz (Europa), 900MHz (Stany) oraz 2.4GHz (globalnie). Dla pasm ISM 700/800/900 z IEEE802.15.4 ma w ofercie ATMEL:
    AT86RF212B - 700/800/900MHz
    AT86RF233 - 2.4GHz

    W Farnellu jest starsza wersją AT86RF212 bez literki B, różnice są dostepne w errata. Cena około 12zł. Dochodzi do tego jeszcze cena symetryzatora + filtr (1-2zł).

  • #9 28 Cze 2014 15:35
    Jado_one
    Poziom 22  

    Mówicie, że da rade skomunikować RFM22B z RFM69HW?
    No to brzmi pocieszająco :-)

    Ten scalak Atmela wygląda bardzo ciekawie - już się w nim zakochałem ;-)
    Ale tak na szybko nie udaje mi się namierzyć tego filtru i symetryzatora - gdzie to można kupić?

    W sumie to mogli by integrować takie features w mikrokontrolerach - zdaje się, że już były jakieś próby w tym względzie?
    Nie wiem tylko jak transmisja oddziaływała by na analogowe części mikrokontrolera - przetworniki A/C itp....

    Tak BTW: Jakieś zalecenia projektowe dla PCB z mikrokontrolerami i modułami RF na jednej płytce? Izolować, ekranować, etc? Antenę prowadzić kablem ekranowanym "w bezpieczne miejsce poza PCB"?

    Jakie jest zalecane złącze w.cz. dla anteny?
    Ścieżka do tego złącza powinna być chyba jak najkrótsza - dodaje się do długości anteny jak rozumiem.

    Czy zintegrowana antena w postaci zygzakowatej ścieżki na PCB jest dobrym pomysłem? Kwestia polaryzacji - chyba pionowa daje lepszy zasięg (dookólność)?

  • #10 28 Cze 2014 16:05
    tmf
    Moderator Mikrokontrolery Projektowanie

    Atmel ma serie zintegrowanych AVR z transceiverem RF. Resztę odpowiedzi znajdziesz w notach producentów - od zaleceń projektowych obwodów aż po implementacje protokołów.

  • #11 28 Cze 2014 16:56
    tymon_x
    Poziom 30  

    Jado_one napisał:
    Ten scalak Atmela wygląda bardzo ciekawie - już się w nim zakochałem ;-)
    Ale tak na szybko nie udaje mi się namierzyć tego filtru i symetryzatora - gdzie to można kupić?

    0900BL18B100E - symetryzator
    0868LP15A020E - filtr 868MHz
    Możesz zastosować antenę ceramiczną, zajmię mniejszą powierzchnię niż antena PCB dipol na 1/4 długości fali.

 Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME