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

AVR + moduły radiowe + transmisja UART = problem

Elektrooonik 27 Sie 2005 12:45 26383 74
  • #61
    sicio1
    Poziom 12  
    Cześć.
    Chodzi o pytanie Witoldinho "Co daje sterowanie average filter ? i przełączenie na manual?".

    Ja doczytałem dokumentację i mogę to sobie wyobrazić, ale nie chce namotać (jak we wcześniejszym poście, zbyt dużo skrótów myślowych :/).
    Nie mam układu, który to umożliwia więc też nie mogę sprawdzić, a w sumie jest do dość ciekawe.
    Oczywiste jest, że w "average filter" ustalany jest próg decyzyjny i czym większa ilość danych synchronizacyjnych/preambuły na początku tym lepiej się jego poziom ustali, będzie "dokładniejszy". Jak to kolega wcześniej napisał "biedny odbiornik musi skądś wiedzieć :]".
    Ale co dalej ..... ??
    Co się dzieje jak się przełącza na manuala ?? Transmisja się poprawia, czy pogarsza (z mojego punktu widzenia, co się dzieje z przepustowością, stopą błędów), jak wygląda praca jaką musi wykonać procesorek, bo z tego co rozumiem należy sterować kolejnym wejściem cc1000.

    Pozdrawiam PS.
  • Computer Controls
  • #62
    lbugiera
    Poziom 21  
    Czy jest lepiej niz przy automatycznym zamykaniu to nie wiem, bo nigdy automatu nie uzywałem. Od początku korzystałem z manuala. A zamykałem go przeprogramowując rejestr CAL. (chyba innej możliwości nie ma ... o ile dobrze pamiętam na chp_out , może sie pojawić informacja czy został zamknięty czy nie, ale nie można go z tego wyjscia zamykac ). Z doswiadczenia wiem, że preambuła to powinno byc minimum 8 pełnych (najlepiej 11-12) znaków i averaging filter powinien byc zamkniety przed odebraniem bajtu synchronizującego. Nadawałem 25 znaków preambuły, i po odebraniu 10 zamykałem averaging filter, później czekając na bajt synchronizujacy. Jesli wśród tego ciagu znaków preambuły, którys został zafałszowany to zmniejszałem licznik (jesli naliczyłem już 5 razy 0xAA i przychodzi np 0xAB to zmniejszam licznik odebranych 0xAA na 4, a zamykam gdy licznik =10). Dopiero wtedy udało sie uzyskać 3bł/MB (dokładniej 3 powtórzone pakiety TCP/IP na 1 Megabajt). Przy "złym" zamykaniu averaging filter miałe 30-100 bł/MB. Więc warto, go "dobrze" zamknąć.

    Co do zmykania AF raz a później "olewania" preambuły to jest to możliwe, ale są 2 zasadnicze problemy: 1. Można to stosować tylko do urządzeń będacyh cały czas w tej samej pozycji. 2. Ponieważ czas od przełącznia w tryb nadawania do momentu kiedy znaki sa nadawane poprawnie jest bardzo różny (z doświadczenia wiem, że to 5-13 znaków) i tu musisz to uwzględnić.

    Ja za każdym przełączeniem nadawałem preambułe 25 znaków. Ze względu na te "kaprysy" nadajnika no i to że chciałem odebrać 8-10 znaków preambuły.

    Pozdrowienia
    Boogie
  • #63
    GienekS
    Poziom 32  
    lbugiera napisał:
    Nie trzeba negować danych.

    Odnośnie negowania danych. W którym rejestrze i który bit jest za tą negację odpowiedzialny. Czy to się odbywa w trakcie nadawania czy iodbioru. Jakoś nie mogę tego się doczytać. Moduły mi ruszyły ale w negacji i dla czystej ciekawości chciałbym to wiedzieć skoro to tylko kwestia konfiguracji.
  • #64
    lbugiera
    Poziom 21  
    W datasheet'cie też nie widziałem tego napisanego wprost, ale skorzystaj ze smart studio, wygeneruj dwie konfiguracje różniące sie tylko negacją danych i zobacz co się zmieniło w wart. rejestrów. Konfiguracja tych modułów jest strasznie zamieszana więc możliwe, że to nie jeden bit trzeba zmienić. Ja zawsze generowałem wart. rej. za pomocą smart studio i wgrywałem przez terminal (atmel sam analizował plik)

    Pozdrowienia
    Boogie
  • Computer Controls
  • #65
    GienekS
    Poziom 32  
    Ale gdzie w SmartRF Studio jest te negacja ?
  • #66
    lbugiera
    Poziom 21  
    Musisz zaznaczyć Low LO (4,5 rząd od góry, zalezy jak liczyć :) ). Przeczytaj info dla tego rzędu z lewej.

    Powodzenia
    Boogie
  • #67
    GienekS
    Poziom 32  
    Faktycznie, zmiana dokonuje się w aż czterech rejestrach.
    Dzięki.
  • #68
    Witoldinho
    Poziom 14  
    ALe przy szukaniu preambuly i unikalnego znaku wychodzi na to ze jezeli sie liczba bajtów preambuły powinna byc nieparzytsa zeby sie przesuwało 10101 na 01010 to trafi i sie zsynchronizuje?? dobrze mysle
  • #69
    lbugiera
    Poziom 21  
    Synchronizacja ma wyglądac następująco: Przyjmijmy że używasz jako preambuły 0xAA. Wtedy ostatni bit preambuły to 0. W takim przypadku bajt synchronizujący to musi być liczba zaczynająca się równiez od bitu 0. Niech to będzie np 0x66. Wtedy szukaz preambuły (0xAA lub 0x55) jesłi jakiś znak nie jest preambuła to bierzesz go jako bajt synchronizujący. Rozpisując bitami 0xAA66 mamy 10101010;01100110. Dałem średnik pomiędzy dwoma bajtami co by było łatwiej zauważyc. Jesli przesunięcie wynosi 1 bit (a dokładniej w tym znaku który juz nie był preambuła jest 7 bitów z 0xAA i jeden bit 0x66) to otrzymamy liczbe 00110011 (0x33) i to jest dla nas sygnał, ze nastepne 7 bitów trzeba pominąc aby sie zsynchronizowac. Jesli przesuniecie wynosi 2 bity (licząc jak powyżej) to odbierzemy znak 10101001 (0xA9) i to oznacza, ze nastepne 6 bitów musi być zignorowane ... No i tak dalej. Jeśli odbierzesz 0x66 to oznacza, że żadnych bitów nie musisz ignorowac i że już jest zsynchronizowane. Po bajcie synchronizującym możesz sobie dac bajt sprawdzajacy. Poprawne odczytanie go będzie gwarancja że synchronizacja nastąpiła poprawnie.
    Następnei dajesz informacje ile jest bajtów w ramce (jesli masz zmienna długość ramki). Cała sprawe komplikują szumy i trzeb asobie powymyslac mechanizmy obrony przed nimi. Moim zdaniem lepiej ominąć jedna cała ramke niz odebrac z powodu szumów ramke przypadkową zawierajacą śmieci (moze sie zdarzyć tak, że pojawia sie "z nikąd" dwa znaki, z których jeden doprowadzi do poprawnej synchronizacji, a drugi będzi erówny sprawdzającemu i dalej już otrzymujemy smieci jako poprawna ramke). Najprostszym sposobem na to jest odebranie odpowiedniej liczby bajtów preambuły, zanim potraktuje się znak nie będący preambuła jako synchronizujący. Ten problem nie jest duży jeśli nadajnik naprawde nadaje. Ale jesli odbiornik szuka ramki, a nie ma źródła nadającego, to prawdopodobienstwo wystąpienia koło siebie kilku bajtów preambuły i 2 synchronizujących nie jest wcale takie małe (zaobserwowane doświadczalnie). Nalezy tez pamietać, ze oprócz 8 przypadków przy synchronizacji jest równiez 9 tzn "fałszywy alarm"

    Powodzenia
    Boogie
  • #70
    Witoldinho
    Poziom 14  
    dzieki za odp, jest troche zamotane ale zaczynam rozumiec,rzeczywiscie prazwdopodobienstwo wystapienia 0xaa i 0xcc jest dosc duze,zauwazylem obserwujac an015 ze nadajac 0xaa i odbierajac liczba 0xaa zmienia sie na 0x55 o ile nastepuje zmiana z 0 na 1 lub 1 na 0 ,wystapienie dwa razy 00 lub 11 powoduje zmiane liczby na inna i wiadomo ze preambula sie skonczyla i nalezy szukac synchronizacji
  • #71
    GienekS
    Poziom 32  
    Ja to robię inaczej. A mianowicie szukanie preambuły polega na odbieraniu kolejno po sobie zer i jedynek, jeżeli takiej kombinacji odbiorę więcej niż 70 to uważam że preambuła została odebrana i teraz czekam na wystąpienie bitu innego niż ten ciąg i traktuję go jako pierwszy bit mojej synchronizacji. Dalej odbieram tyle bitów ile wynosi mój pakiet poczym sprawdzam poprawność pakietu zaczynając oczywiście od znaków synchronizacji. Jak do tej pory działa mi to bezproblemowo.
  • #72
    marmur99
    Poziom 17  
    OK, ale na odbieranie bit po bicie można sobie pozwolić jeśli przesyłasz dane z prędkością 1-2 kbit/s. Jeśli interesują Cię prędkości rzędu 76.8 - 115.2 kbit/s to raczej w grę wchodzi odbieranie bajtów przez przerwanie. Inaczej procek nie będzie robił nic innego tylko odbierał kolejne bity.
    A jeżeli odbierasz bajty to sprawa synchronizacji się już trochę komplikuje bo musisz przeprowadzać korelacje tego, co przyszło ze znanymi i oczekiwanymi bajtami synchronizacji.

    Pozdrawiam,

    Marmur99
  • #73
    lbugiera
    Poziom 21  
    marmur99 napisał:
    OK, ale na odbieranie bit po bicie można sobie pozwolić jeśli przesyłasz dane z prędkością 1-2 kbit/s. Jeśli interesują Cię prędkości rzędu 76.8 - 115.2 kbit/s to raczej w grę wchodzi odbieranie bajtów przez przerwanie. Inaczej procek nie będzie robił nic innego tylko odbierał kolejne bity.
    A jeżeli odbierasz bajty to sprawa synchronizacji się już trochę komplikuje bo musisz przeprowadzać korelacje tego, co przyszło ze znanymi i oczekiwanymi bajtami synchronizacji.

    Pozdrawiam,

    Marmur99


    No to właśnie po to wogóle jest synchronizacja. To nie jest synchronizacja do bitów, tylko bajtów. Co do wydajności, to oczywiście lepiej stosować SPI. Jak chcemy zsynchronizować bajt, to według procedur podanych wyżej zatrzymujemy (resetujemy) SPI na te 1-7 bitów, w zalezności od potrzeb synchronizacji. I dalej z SPI wyciagamy już tylko "konkretne" bajty danych. Ale bez SPI też się da (chociaż nie polecam) bo jeśli damy kwarc 16mhz to przy prędkosci 76,8 kbit mamy ponad 200 cykli na jeden bit, co dla AVR'ów jest wartością sporą (oczywiście pod warunkiem, że programujemy w asemblerze). Ale wtedy jakieś kodowania/dekodowania odpadają. Ewentualnie buforowanie jeszcze by się moze zmiesciło.

    Pozdrowienia
    Boogie
  • #74
    GienekS
    Poziom 32  
    marmur99 napisał:
    OK, ale na odbieranie bit po bicie można sobie pozwolić jeśli przesyłasz dane z prędkością 1-2 kbit/s. Jeśli interesują Cię prędkości rzędu 76.8 - 115.2 kbit/s to raczej w grę wchodzi odbieranie bajtów przez przerwanie. Inaczej procek nie będzie robił nic innego tylko odbierał kolejne bity.
    A jeżeli odbierasz bajty to sprawa synchronizacji się już trochę komplikuje bo musisz przeprowadzać korelacje tego, co przyszło ze znanymi i oczekiwanymi bajtami synchronizacji.

    Pozdrawiam,

    Marmur99
    Ten odbiór bitowy i tak robię w przerwaniach aby jeszcze mieć czas na inne sprawy. Pracuję na 2,4kB
  • #75
    marcinus
    Poziom 13  
    Cze, chcialbym dołaczyc sie do dyskusji. Mam nadzieje ze temat jest jeszcze aktualny:D POlaczylem modul CC1000 z mikrokontrolerem LPC2114. Uklad konfuguruje nastepujaco:

    SetupCC1000PD();
    ResetCC1000();
    SetupCC1000All();


    // Pll_tx.bajt=0x48;


    // konfiguracja nadawania

    WakeUpCC1000ToTX(TX_CURRENT,Pll_tx.bajt);
    SetupCC1000TX(TX_CURRENT,Pll_tx.bajt);
    if (!CalibrateCC1000())
    write_text_XY("TCal_f",1,1);
    else write_text_XY("TCOK",1,7) ;


    //konfiguracja odbioru

    SetupCC1000RX(RXCurrent,0x60);
    if (!CalibrateCC1000())
    write_text_XY("kRNOK",2,1); //*/printf("kRNOK");
    else
    write_text_XY("kROK",2,7);//printf("kROK");
    for(t=0;t<0x7ffe;t++);

    Na pasmo 433 MHZ. Bez sygnalu nadawanego napiecie na vrssi wynosi 1073 mv, gdy wlacze modem nadawczy napiecie to skacze od 80 do 1040 mv.
    Napiecie na nadajniku sa nastepujace:
    nozka 10- 2,57
    nozka 11- 2,58

    Napiecia na odbiorniku:
    nozka 10- 2,60
    nozka 11 -2,60

    Poza tym uklad przy wylaczonym nadajniku odbiera smieci, co yb sie zgadzalo z wczesniejszymi postami. Ma ktos moze wycinek kodu jak nalezy odbierac breambule w przeraniu zewnetrznym zeby dostroic sie do sygnalu. Chyba zle rozumie, ale skoro uklad odbiera caly czas smieci to np implemenacja trybow redukcji mocy nie ma sensu?? DCLK jest podlaczone do przerwania zewnetrznego i odczytuje bit po bicie z zlini DIO. Dzieki za pomoc:)