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

[AVR] Błędy transmisji między RFM12B Hope

kozi25 17 Gru 2009 01:19 3061 7
  • #1 7399734
    kozi25
    Poziom 10  
    Witam
    Męczę od kilku miesięcy (z przerwami) łączność między modułami RF. Transmisja przebiega prawie poprawnie, tzn. pomiędzy poprawnie odebrane bity wstawiane są ciągi zer. Nie znalazłem nic na ten temat na forum.

    Nadajnik:
    ATmega88, zegar: wewn. RC 8 MHz
    RFM12B, wersja 868 MHz, antena: drut lambda/2
    zasilanie:3,3 V (trafo daje 500 mA)
    interface: programowe SPI 16 bit
    program: asembler Atmela,
    wysyła w kółko pakiet danych, zwolnienie bufora sprawdza testując MSbit rejestru statusu, nie używa przerwań, dane do bufora ładuje komendą 0xB8XX (bez użycia pinu 6 - nFFS)

    Odbiornik:
    ATmega32, zegar: wewn. RC 8 MHz
    RFM12B, wersja 868 MHz, antena: drut lambda/2
    LCD graficzny z Nokii 7210/6100
    zasilanie: 5 V uC; 3,3 V moduł RF, LCD
    dopasowanie poziomów napięć na liniach danych za pomocą diod i rezystorów
    interface: programowe SPI 16 bit
    program: asembler Atmela,
    zapis FIFO po wykryciu synchronizacji, uC czeka na pakiet danych testując MSbit rejestru statusu, nie używa przerwań, dane z bufora czyta komendą 0x00XX (bez użycia pinu 6 - nFFS), wyświetla dane na LCD w postaci binarnej, czeka 2 s, czyści wyświetlacz i czeka na ponowną synchronizację

    Pakiet danych:
    - preambuła: 0xAA, 0xAA
    - synchro pattern: 0x2D, 0xD4
    - 16 B danych

    Do prędkości 19,2 kb/s działa bezbłędnie (testowałem na odl. do 11 m, przez dwie ściany, w ruchu, różne orientacje anten).
    Przy 38,4 kb/s już świruje. Po ok. 11 bitach danych wstawia paczkę 6 zer, trochę bitów danych, 6 zer, itd. Czasem pokaże dłuższy ciąg bez tych zbędnych zer. Nie ma tu znaczenia odległość (5 cm do 4m) przesyłane dane (1111..., 1010...). Przy wyższych prędkościach to trochę lepiej wygląda (przy max prędkości dla tych modułów czyli 115,2 kb/s wstawia tylko 3 zera w jednym miejscu, przy odl. do 11 m).

    Już nie mam pomysłu co to może być. To nie są jakieś duże prędkości, anteny leżą obok siebie. Moje SPI programowe powinno nadążyć z przesyłem z/do bufora do prędkości 130/160 kb/s, więc to raczej nie to. Próbowałem różnych konfiguracji modułów (częstotliwość f0, dewiacja, szerokość pasma odb. tryby pracy AFC, clock recovery, moc nadajnika, czułość odbiornika, poj. dołączanego kondensatora). Udało mi się tym tylko nieznacznie pogorszyć jakość transmisji - pojawiały się błędy. Chodziło mi już głowie nawet uszkodzenie RAMu więc przeniosłem tablicę bufora odbiorczego.

    Jeśli ktoś ma jakiś pomysł to proszę radę.
  • #2 7399906
    Ch.M.
    Poziom 27  
    Witaj
    Jedyne co przychodzi mi do głowy to różnica między częstotliwości kwarcu w nadajniku i odbiorniku. Jeśli masz czym to spróbuj je pomierzyć, ewentualnie zmienić kwarce na jakies pewne (zakładam, że obydwa urządzenia pracują w tej samej temperaturze).
    Pozdrawiam
  • #3 7400368
    kozi25
    Poziom 10  
    Obydwa moduły leżą obok siebie, więc temperatura ta sama. Nie mam czym zmierzyć i nie mogę wymienić kwarców, są za małe i nie przelutuję ich. Zresztą nie wiem czy bym takie dostał.

    Po za tym to chyba nie w tym rzecz. Te moduły mają funkcję Automatic Freqency Control, która dostraja częstotliwość odbiornika do częstotliwości nadajnika. Próbowałem ustawień zakresu przestrajania od min. do "no restriction".

    Zresztą różnica częstotliwości Tx i Rx nie objawia się tak skokowo przy zmianie bitrate i powoduje raczej pomijanie lub wstawianie jednego bitu (0 lub 1). A u mnie to jest zawsze ciąg kilku zer. Wygląda to raczej na błędną pracę AFC albo zatrzymanie pracy zegara w modułach. Tak mi się wydaje.

    Czy to może być wina uszkodzeń elektrostatycznych? Dużo mam tworzyw sztucznych wokół i często się elektryzuję. Jak dotykam np. klamki to iskry skaczą.
  • #4 7440299
    OlekM
    Poziom 17  
    Proponowałbym - w celu upewnienia się, czy wina nie leży po stronie zbyt wolnej obsługi SPI - puścić mikrokontroler z zewnętrznym kwarcem 16MHz.

    Zapewne nie będzie to wymagało wielu zmian w programie, a pozwoli zyskać dużą pewność, że problem nie leży w tym (dość prawdopodobnym) miejscu.
    (Chodzi mi oczywiście o procedury nadawania, gdzie w czasie transmisji jednego bajtu w eter należy: wykryć gotowość FIFO i wysłać do modułu "aż" dwa bajty - zatem efektywna prędkość transmisji jest dwukrotnie mniejsza).
  • #5 8200208
    kozi25
    Poziom 10  
    Witam
    Prędkość transmisji przeanalizowałem w symulatorze AVR Studio i była ok. Jednak żeby jeszcze przyśpieszyć napisałem funkcję przesyłającą dane bezpośrednio z/do bufora (bez użycia komend 0xB8XX/0x00XX).
    Rezonatory w końcu też wymieniłem (urywając przy okazji ścieżkę). I nadal nic.

    Ostatecznie kupiłem dwa nowe moduły. Wymieniłem tylko ten po stronie odbiornika wychodząc z założenia, że skoro błędne bity są ciągle wstawiane w tych samych miejscach po kilku bitach prawidłowych, uszkodzony nadajnik nie dałby rady wysłać bezbłędnie 16 bitów synchronizujących pakiet (wysyłane tak jak właściwe dane - przez bufor). Skoro odbiornik co dwie sekundy wyświetlał nowe dane, tzn. że synchro pattern był wysyłany prawidłowo, czyli nadajnik powinien być dobry.

    Po uruchomieniu wszystko zaczęło działać. Na najwyższej prędkości, zarówno z bezpośrednim dostępem do bufora (pin nFFS) jak i przez komendy 0xB8XX/0x00XX. Prawdopodobnie wszystkiemu winne było uszkodzenie elektrostatyczne.
    Niestety w 16 bajtowym pakiecie często przekłamuje pojedyncze bity (odl. 1 m), no ale ten typ tak już chyba ma.

    Dziękuję wszystkim za odpowiedzi
  • #6 8200264
    __Grzegorz__
    Poziom 30  
    Przy transmisjach radiowych trzeba stosować FEC.

    Przesyłanie danych na wprost nie jest profesjonalnym podejściem do sprawy.
  • #7 8200323
    kozi25
    Poziom 10  
    Cytat:
    Przy transmisjach radiowych trzeba stosować FEC.

    Przesyłanie danych na wprost nie jest profesjonalnym podejściem do sprawy.


    Tak, wiem. Tyle, że to miał być układ do testów łączności :).

    A na jeden metr to chyba powinno chyba dać radę bez błędów przesłać trochę dłuższy pakiet przy włączonej automatycznej korekcji częstotliwości i dużej liczbie przejść 0/1, 1/0 w strumieniu danych.
  • #8 8202188
    arturt134
    Poziom 27  
    Używałem tego samego układu i działał bezbłędnie. Mam tylko kilka uwag:
    - zwiększ preambułę do 4 bajtów 0xAA.
    - na koniec pakietu dodaj co najmniej 1, a najlepiej 2 lub 3 bajty "dummy"; ostatni z nich nie będzie przesłany w całości.
    - po włączeniu zasilania, przed inicjalizacją układu musisz poczekać aż jego POR się skończy - ja czekam 500ms.
    - do pakietu dodaj CRC, nawet prostą sumę wszystkich batów; jakiekolwiek zawsze będzie lepsze niż żadne.
    - wysyłaj każdy pakiet kilkakrotnie (o ile masz taką możliwość) lub stosuj transmisję z potwierdzaniem i powtórzeniami - zwiększasz swoje szanse na prawidłową komunikację.
REKLAMA