Jak skutecznie wdrożyć protokół przesyłania danych z modułami CC1000?

Mon Mar 20, 2006 1:14 pm   

Witam!

Czy komuś udało się zastosować jakiś protokół przesyłania danych
w eterze używając tych modułów?

Ja już do głowy dostaję.
Najpierw udało mi się napisać program, który wysyłał dane,
odbiornik - wysyłał ramkę OK, lub NOK (jeśłi były błędy w transmisji).
Działało super - to co wysyłałem z jednej strony, zawsze po drugiej stronie
było odebrane. Wszystko było fajnie, jeśli nie nadawałem jednocześnie -
wówczas wszystko się sypało.

Zacząłem więc od drugiej strony -najpierw zająłem się dostępem
do kanału - jakoś działało, choć zdarzały się kolizje.

Gdy chciałem dodać do tego jakieś potwierdzenia, CRC itd,
znów wszystko zaczęło się sypać.

Dodam, że podstawy teoretyczne znam ale problem tkwi...
hmmm sam nie wiem gdzie, chyba w algorytmie i ułomności
CC1000 (np. zbyt długie przełączanie pomiędzy nad./odb..

Przede wszystkim jednak to chyba moja ułomność i stres,
że braknie mi czasu do obrony.

Może ktoś zna jakieś materiały, gdzie znajdę jakiś pomysł i ruszę
wreszcie do przodu?
Kurcze, jeszcze aplikacja na PC mnie czeka....

Z góry dziękuję za wszelki podpowiedzi!

Pozdrawiam

Mon Mar 20, 2006 10:17 pm   

Użytkownik Krzysztof napisał:
[..]


w listopadzie zeszlego roku poradzilem Ci zapoznanie sie z protokolem
AX25 uzywanym w packet radio, jak widze nie skozystales

--
AlexY
http://yisse.neostrada.pl/spam.txt
http://ldhp715.immt.pwr.wroc.pl/~sapi/sieci/netykieta/

Mon Mar 20, 2006 10:23 pm   

Witaj Krzysztof.
Istotnie transmisja przebiega bezproblemowo, jeśli jedno z urządzeń cały
czas odbiera a drugie jest nadajnikiem. Sam to sprwdziłem. Ale pamiętaj,
że w takim systemie, gdzie nadajnik i odbiornik pracują na jednej
czestotliwości nigdy nie będziesz mógł jednoczesnie nadawać i odbierać.
System duplex wymaga np dwóch częstotliwości. Ale o tym napewno wiesz.
Jeśli zamierzasz wysyłać dane w obie strony zastanów się, czy konieczne
jest, aby każdy z modułów zaczynał nadawać spontanicznie. Może wystarczy
zaimplementować transmisję na żądanie?
Ramkę utracisz również wtedy, gdy w takcie odbioru do anteny odbiornika
przeniknie zakłócenie.
Pamiętaj, że antena przy CC1000 w trakcie nadawania może oddziaływać na
linie sygnałowe procesora, którym zapewnie sterujesz CC1000. Ale to jest
już związane z implementacją hardware'ową.
Napisz więcej co konkretnie chcesz wykonać. W niedługim czasie zamierzam
wykonać badania w terenie, może coś Ci podpowiem ciekawego co może
uratować Cię "od dostawania do głowy".
Krzysztof napisał(a):

Tue Mar 21, 2006 8:00 am   

Użytkownik <vhdl@poczta.fm> napisał w wiadomości
news:dvna3k$jdq$1@achot.icm.edu.pl...

Chcę wykonać połączenie pomiędzy dwoma urządzeniami.
Każde z tych urządzeń połączone jest z komputerem, do którego
przesyła dane i z którego dane do wysłania pobiera.
Połączenie to wykorzystuje port USB komputera.
Od strony AVR jest to RS232 (poprzez układ FTDI232BM).
W momencie, kiedy urządzenie ma zapełniony bufor -
wysyła dane w eter, sprawdzając wcześniej przez określony czas
czy kanał jest wolny (wykorzystując przetwornik A/C oraz
sygnał RSSI z układu CC1000. Dlatego jest to transmisja
typu half duplex. Zdaję sobie sprawę, że na jednej częstotliwości
nie uzyskam full duplex. Do każdej ramki dodaję preambułe,
CRC, numer oraz typ ramki. Wszystko działa świetnie do momentu, gdy
nadaje tylko jedno z urządzeń.
Być może słabym punktem jest tutaj przetwornik, który wprowadza pewne
opóźnienie
do algorytmu.
Dodam, że obsługa CC1000 oraz USART'a jest wykonywana w przerwaniach.
Reszta warunków (przepełnienie buforów, sprawdzanie zajętości kanału)
wykonywana jest
w głównej pętli programu.
W momencie, gdybym chciał zaimplementować transmisję na żądanie, nie
uniknąłbym tych problemów.
Zawsze mogłoby dojść do kolizji ramek żądań, co przy jednoczesnym wysyłaniu
plików
z dwóch komputerów jest bardzo prawdopodobne.
Jeśli nie znajdę rozwiązania, wówczas będę musiał pomyśleć o stacji
centralnej, która
sterowała będzie transmisją wszystkich urządzeń znajdujących się w jej
otoczeniu ( coś na wzór ALOHA).

Pozdrawiam

Tue Mar 21, 2006 10:08 am   

Krzysztof <krysss1981@poczta.onet.pl> napisał(a):


Nauka nie zając, studia nie wyścigi ;-)

pozdro.
[g.d.]

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Tue Mar 21, 2006 12:23 pm   

wykonywane w nich procedury nie można skrócić.
Następnie sprawdź, jak długo jest liczona CRC i czy masz wydajny
algorytm. Jeśli CRC jest liczona "długo" a procesor jest wolny, to może
być problem.
W moim systemie przewidziałem wykorzystanie PICa, oraz transmisję z
wykorzystaniem RSa od strony PC z szybkością 19200 Baud. Taka szybkość
jest wystarczająca do aplikacji jaką wykorzystuję. Aby uniknąć gładko
problemu kolizji, w systemie pracuje urządzenie master, które steruje
transmisją. Urządzenie slave nigdy nie może nadawać, jesli nie zostanie
odpytane. Ale z tego co się orientuję Ty potrzebujesz aby ta sieć
radiowa działała szybciej, a proponowane przeze mnie rozwiązanie
zwiększa nadmiar informacji kontrolno sterujących w kanale radiowym. Nie
rokuje to niczego dobrego tymbardziej ze nie CC1000 nie rozwija zbyt
wysokich prędkości.



wprowadź losowość czasu rozpoczęcia nadawania w modułach. Jeśli
transmisja zakonczy sie porażką to po losowym czasie wysyłaj ponownie i
tak do skutku. Nie widzę innego rozwiązania.





Powiedz mi jak rozwiązałeś sprzętowo interfejs USB. Zakupiłeś gotowe
moduły z soyter.pl? Jak się nie mylę od strony mikrokontrolera
podłączenie jest identyczne jak do portu RS232 zgadza się? Czy po
zainstalowaniu softu do USB otrzymujesz kolejny port COM w systemie?

Zamierzasz napisać jeszcze aplikację na PC do sterowania Twoją siecią
radiową?

Podrawiam

Tue Mar 21, 2006 12:59 pm   

Krzysztof napisał(a):


Rozwiązań można wykombinować wiele, wystarczy logicznie pomyśleć.
Z tego co napisałeś nie zaprzątałeś sobie dotąd głowy rozwiązaniem
problemu kolizji. Założyłeś, że zdarzenie będzie nieczęste, czyli
"prawie niemożliwe", więc "jakoś to będzie". A to błąd. Jesli coś może
pójść źle, to pójdzie.
Jeśli nie masz arbitra kanału, będziesz musiał przekazywac uprawnienia
do transmisji z modułu na moduł, uwzgledniając wszystkie opóźnienia i
przypadki nietypowe i nie ma innego wyjścia. Próba użycia napięcia z
detektora do sprawdzania zajętości jest na tyle nieskuteczna co i
głupia. Ono nie do tego służy.

P.S.
Odkładanie pracy na ostatnią godzinę często trzeba odpokutować a
powstałe w ten sposób urządzenia zwykle nadają się do kosza albo
poważnej gruntownej przeróbki.

--

Pozdrawiam,

A. Grodecki

"Wszystkie zwierzęta sa równe.
Ale te, które mają futerko w trzykolorowe pasy, są równiejsze."

Tue Mar 21, 2006 1:35 pm   

Użytkownik <vhdl@poczta.fm> napisał w wiadomości
news:dvonqh$2pf$1@achot.icm.edu.pl...


AVR pracuje z zegarem 11059200 ale przeprojektuję układ na 5V.
Wtedy wykorzystam kwarc 16000000.
Sprawdzałem wszystkie czasy w AVR Studio. Wyszło mi, że wyrobię się
z transmisją radiową o prędkości do 19200 przy zegarze 11059200.
W każdym cyklu pomiędzy przerwaniami od CC1000 pozostaje mi
jeszcze czas na obsługę nadajnika i odbiornika UART'a oraz jeszcze trochę
cykli na program główny. W głównej pętli jednak nie ma zbyt wielu
instrukcji - sprawdzam tam tylko bufory itd. itp.


Aby uniknąć gładko

Jeśli nie poradzę sobie inaczej, będę musiał zastosować jakiegoś master'a.
Możesz napisać jak dokładniej odbywa się to odpytywanie?



Wprowadziłem losowość. W odpowiedzi dla p. A. Grodeckiego opisałem jak to
wygląda u mnie dokładniej.


Pozdrawiam

Tue Mar 21, 2006 2:25 pm   

Krzysztof napisał(a):


Ale opóźnienia w układzie czynią ten popularny prosty algorytm
nieskutecznym, chyba że już po rozpoczęciu transmisji sprawdzasz, czy
jednak kolizja nie nastąpiła. A z pojedynczym transciverem na stronie
takiej możliwości nie masz. Dlatego jedyna pewna metoda to przekazywanie
uprawnień a twój algorytm może być użyty do inicjalizacji systemu.
Chyba że okresowa utrata danych nie zagraża stabilności pracy systemu.

Próba użycia napięcia z

Masz rację, rzeczywiście myślałem że kondensator na tym pinie jest większy.
Ale to nie zmienia postaci rzeczy, jeśli obrabiasz ten sygnał
przetwornikiem. Jeśli chcesz aby praca przetwornika AD nie wprowadzała
groźnych opóźnień i nie obciążała bezsensownie procesora (ten
przetwornik powinien chodzić cały czas i z maksymalną prędkoscią),
lepiej jest zrobić detektor na wewnętrznym lub zewnętrznym komparatorze
i obsłużyć go przerwaniem.
Tak czy owak szybka detekcja zmian na tym pinie zmniejsza tylko
prawdopodobieństwo kolizji. Jak je ZUPEŁNIE wykluczyć napisałem Ci
wyżej. Rób co chcesz :)

--

Pozdrawiam,

A. Grodecki

"Wszystkie zwierzęta sa równe.
Ale te, które mają futerko w trzykolorowe pasy, są równiejsze."

Tue Mar 21, 2006 2:32 pm   

Krzysztof napisał(a):


Z ciekawości - jakie opóźnienie wprowadza FTDI232B. Czy wuplucie danej
po drugiej stronie nastepuje natychmiast po otrzymaniu pełnego bajtu,
czy to trwa jakiś "istotny" czas, dłuższy niż sam bajt?

--

Pozdrawiam,

A. Grodecki

"Wszystkie zwierzęta sa równe.
Ale te, które mają futerko w trzykolorowe pasy, są równiejsze."

Tue Mar 21, 2006 2:55 pm   

Próba użycia napięcia z




Sygnał RSSI przed detektorem będzie zawsze odwzorowywał to co odbierze
antena na danej częstotliwości? Czyli zakłócenie również będzie
powodowało zmiany amplitudy sygnału RSSI?

Ponadto zastanawiam się nad zasadą działania układu detektora w CC1000.
Kiedy włączony jest filtr uśredniający, daje on sygnał odniesienia dla
komparatora. Stan ten wymaga, aby kodowanie danych zerowało składową
stałą (Manchester). Odbiór danych NRZ wymaga wyłączenia filtra.
Jaki to jest detektor?? Gdzie znaleźć jego opis?

pozdrawiam

PS. Udanych kompilacji

Tue Mar 21, 2006 5:22 pm   

T.M.F. napisał(a):


No tego to się można było spodziewać. Ale to nie ból, ból to opóźnienia
jakie wprowadzają konwertery COM-ethernet (patrz mój dzisiejszy wątek).
Dzieki za info.

--

Pozdrawiam,

A. Grodecki

"Wszystkie zwierzęta sa równe.
Ale te, które mają futerko w trzykolorowe pasy, są równiejsze."

Tue Mar 21, 2006 11:25 pm   

Witam ,


Mozesz zdradzic jaki jest temat Twojej pracy ? Na czym dokladnie polega
problem ktory chcesz
rozwiazac ? Napisz cos wiecej a moze komus uda sie pomoc jakos inaczej to
rozwiazac.

W jednej z mojej aplikacji zrezygnowalem ze sprawdzania zajetosci
alu - cyklicznie odpytywalem
bufor (wysylalem dane do bufora) kolejne moduly (3) pracujac z
najszybsza predkoscia transmisji miedzy modulami .


Rozwaz takie rozwiazanie ... Chyba ze totalnie nie nadaje sie do Twojej
pracy.



Pozdrawiam,


Mariusz

Sun Mar 26, 2006 2:22 pm   

Witaj Krzysztof!
Udało Ci się coś nowego zaimplementować?
Ja mam aktualnie oprogramowany sterownik mikroprocesorowy z możliwością
zmiany mocy i szybkości transmisji oraz z protokołem transmisji na
żądanie.

Pozdrawiam

Janek

Sun Mar 26, 2006 10:18 pm   

(vhdl@poczta.fm) napisał(a):


No to nie chwalcie się tylko opublikujcie całe źródła w Sieci. Będzie z
pożytkiem dla większej społeczności walczącej ze scalakami Chipcona.

--
Adam Dybkowski
http://www.amwaw.edu.pl/~adybkows/

Uwaga: przed wysłaniem do mnie maila usuń "123" z adresu.