Jak efektywnie implementować protokoły przesyłania danych z modułami CC1000?
Pochwalcie się - CC1000
From: "Krzysztof" <krysss1981_at_nospam_poczta.onet.pl>
Subject: Pochwalcie się - CC1000
Date: Mon, 20 Mar 2006 14:14:56 +0100
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
From: AlexY <alexy_at_nospam_irc.-cut_this-.pl>
Subject: Re: Pochwalcie =?ISO-8859-2?Q?si=EA_-_CC1000?=
Date: Mon, 20 Mar 2006 23:17:29 +0100
Użytkownik Krzysztof napisał:
[..]
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.
[..]
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..
[..]
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/
From: "(vhdl_at_nospam_poczta.fm)" <vhdl_at_nospam_poczta.fm>
Subject: Re: Pochwalcie =?ISO-8859-2?Q?si=EA_-_CC1000?=
Date: Mon, 20 Mar 2006 23:23:39 +0100
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):
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
From: "Krzysztof" <krysss1981_at_nospam_poczta.onet.pl>
Subject: Re: Pochwalcie się - CC1000
Date: Tue, 21 Mar 2006 09:00:51 +0100
Użytkownik <vhdl_at_nospam_poczta.fm> napisał w wiadomości
news:dvna3k$jdq$1_at_nospam_achot.icm.edu.pl...
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):
Witam!
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
From: "(vhdl_at_nospam_poczta.fm)" <vhdl_at_nospam_poczta.fm>
Subject: Re: Pochwalcie =?ISO-8859-2?Q?si=EA_-_CC1000?=
Date: Tue, 21 Mar 2006 12:23:44 +0100
Od strony AVR jest to RS232 (poprzez układ FTDI232BM).
Z jakim zegarem pracuje Twój AVR? Zastanów się czy przerwania i
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.
czy kanał jest wolny (wykorzystując przetwornik A/C oraz
sygnał RSSI z układu CC1000.
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.
Być może słabym punktem jest tutaj przetwornik, który wprowadza pewne
opóźnienie
do algorytmu.
jaki przetwornik masz na myśli?
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
From: "Krzysztof" <krysss1981_at_nospam_poczta.onet.pl>
Subject: Re: Pochwalcie się - CC1000
Date: Tue, 21 Mar 2006 13:28:40 +0100
Użytkownik <vhdl_at_nospam_poczta.fm> napisał w wiadomości
news:dvonqh$2pf$1_at_nospam_achot.icm.edu.pl...
jaki przetwornik masz na myśli?
Przetwornik A/C
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?
Użyłem gotowych modułów. Kupiłem je w Kamami
Dokładnie tego modułu:
http://www.kamami.pl/?id_prod=6697
Podłączenie jest identyczne jak do Portu RS232.
Po zainstalowaniu sterowników otrzymuję nowy port COM,
który od strony PC obsługuje się jak zwykły RS232.
Zamierzasz napisać jeszcze aplikację na PC do sterowania Twoją siecią
radiową?
W najprostszym założeniu mogą to być tylko dwa moduły.
Chciałbym jednak zrobić sieć kilku takich urządzeń.
Aplikacja PC ma wysyłać dane do urządzenia, ustawiać odpowiednie prędkości
transmisji CC1000 oraz RS232, zmieniać częstotliwość itp.
From: "A.Grodecki" <ag.usun_to_at_nospam_modeltronik.com>
Subject: Re: Pochwalcie =?ISO-8859-2?Q?si=EA_-_CC1000?=
Date: Tue, 21 Mar 2006 14:32:29 +0100
Krzysztof napisał(a):
od strony PC obsługuje się jak zwykły RS232.
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."
From: "T.M.F." <tfrancuz_at_nospam_nospam.mp.pl>
Subject: Re: Pochwalcie =?ISO-8859-2?Q?si=EA_-_CC1000?=
Date: Tue, 21 Mar 2006 16:34:22 +0100
od strony PC obsługuje się jak zwykły RS232.
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?
Sam FTDI nie wprowadza istotnego opoznienia. Ale bardzo duze opoznienie
rzedu nawet 1ms(!) wprowadza sam driver, a wynika to ze specyfiki
transmisji po USB. Wiec tak naprawde wysylajac bajt z PC nie jestes w
stanie precyzyjnie okreslic kiedy pojawi sie on na wyjsciu z FTDI, co
najbolesniej widac w trybie bit-bang.
--
Inteligentny dom - http://idom.wizzard.one.pl
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz sie do projektu.
From: "A.Grodecki" <ag.usun_to_at_nospam_modeltronik.com>
Subject: Re: Pochwalcie =?ISO-8859-2?Q?si=EA_-_CC1000?=
Date: Tue, 21 Mar 2006 17:22:55 +0100
T.M.F. napisał(a):
Sam FTDI nie wprowadza istotnego opoznienia. Ale bardzo duze opoznienie
rzedu nawet 1ms(!) wprowadza sam driver, a wynika to ze specyfiki
transmisji po USB. Wiec tak naprawde wysylajac bajt z PC nie jestes w
stanie precyzyjnie okreslic kiedy pojawi sie on na wyjsciu z FTDI, co
najbolesniej widac w trybie bit-bang.
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."
From: "Krzysztof" <krysss1981_at_nospam_poczta.onet.pl>
Subject: Re: Pochwalcie się - CC1000
Date: Tue, 21 Mar 2006 13:35:37 +0100
Użytkownik <vhdl_at_nospam_poczta.fm> napisał w wiadomości
news:dvonqh$2pf$1_at_nospam_achot.icm.edu.pl...
Z jakim zegarem pracuje Twój AVR? Zastanów się czy przerwania i 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ę.
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
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.
Jeśli nie poradzę sobie inaczej, będę musiał zastosować jakiegoś master'a.
Możesz napisać jak dokładniej odbywa się to odpytywanie?
czy kanał jest wolny (wykorzystując przetwornik A/C oraz
sygnał RSSI z układu CC1000.
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.
Wprowadziłem losowość. W odpowiedzi dla p. A. Grodeckiego opisałem jak to
wygląda u mnie dokładniej.
Pozdrawiam
From: "A.Grodecki" <ag.usun_to_at_nospam_modeltronik.com>
Subject: Re: Pochwalcie =?ISO-8859-2?Q?si=EA_-_CC1000?=
Date: Tue, 21 Mar 2006 12:59:41 +0100
Krzysztof napisał(a):
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).
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."
From: "Krzysztof" <krysss1981_at_nospam_poczta.onet.pl>
Subject: Re: Pochwalcie się - CC1000
Date: Tue, 21 Mar 2006 13:23:20 +0100
Użytkownik "A.Grodecki" <ag.usun_to_at_nospam_modeltronik.com> napisał w wiadomości
news:dvop7h$sub$1_at_nospam_nemesis.news.tpi.pl...
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.
Właśnie zaprzątam sobie tym głowę cały czas. Kolizji unikam, stosując
algorytm CSMA/CA. Wygląda to w ten sposób, że nadajnik czeka na zwolnienie
kanału, po czym wybiera losowo odcinek czasu (p*q, gdzie p - liczba z
zkaresu 0-255,
q - pewien odcinek czasu uwzględniający czas propagacji sygnału, czasy
przełączania itd.),
po którym zaczyna nadawanie. Podczas oczekiwania na zakończenie tego odcinka
czasu,
urządzenie cały czas jest w trybie odbioru. Zatem, jeśli inne urządzenie
wylosowało czas krótszy,
wówczas ono pierwsze nadaje. To z dłuższym czasem czeka do następnego razu,
gdy kanał się zwolni.
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.
Niestety nie mogę się z tym zgodzić. Cytat ze strony Chipcon'a:
"First of all, the CC1000 is not designed to offer high accuracy on RSSI. It
is rather
ment to support RF carrier detection. Chipcon has done some testing of this
at
868 MHz, and in our measurements we found a total rise time in the region of
12us.
This time will of course vary somewhat with external components, input level
etc."
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.
To nie było odkładanie pracy na ostatnią chwilę. Tak jest czasem na
uczelniach, że wcześniej
nie ma czasu, szczególnie jeśli człowiek musi sam się utrzymywać...
Pozdrawiam
From: "A.Grodecki" <ag.usun_to_at_nospam_modeltronik.com>
Subject: Re: Pochwalcie =?ISO-8859-2?Q?si=EA_-_CC1000?=
Date: Tue, 21 Mar 2006 14:25:48 +0100
Krzysztof napisał(a):
urządzenie cały czas jest w trybie odbioru. Zatem, jeśli inne urządzenie
wylosowało czas krótszy,
wówczas ono pierwsze nadaje. To z dłuższym czasem czeka do następnego razu,
gdy kanał się zwolni.
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
detektora do sprawdzania zajętości jest na tyle nieskuteczna co i głupia.
Ono nie do tego służy.
Niestety nie mogę się z tym zgodzić. Cytat ze strony Chipcon'a:
"First of all, the CC1000 is not designed to offer high accuracy on RSSI. It
is rather
ment to support RF carrier detection. Chipcon has done some testing of this
at
868 MHz, and in our measurements we found a total rise time in the region of
12us.
This time will of course vary somewhat with external components, input level
etc."
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."
From: "Krzysztof" <krysss1981_at_nospam_poczta.onet.pl>
Subject: Re: Pochwalcie się - CC1000
Date: Tue, 21 Mar 2006 14:28:13 +0100
Użytkownik "A.Grodecki" <ag.usun_to_at_nospam_modeltronik.com> napisał w wiadomości
news:dvou6e$3i0$1_at_nospam_atlantis.news.tpi.pl...
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 :)
W tej chwili właśnie wykonuje próby z komparatorem analogowym.
Podjerzewam, że skończy sie na tym, iż dam jakieś urządzenie typu
master, które będzie kontrolowało transmisję.
Dzięki za odpowiedzi, pozdrawiam
From: "(vhdl_at_nospam_poczta.fm)" <vhdl_at_nospam_poczta.fm>
Subject: Re: Pochwalcie =?ISO-8859-2?Q?si=EA_-_CC1000?=
Date: Tue, 21 Mar 2006 14:38:44 +0100
Podjerzewam, że skończy sie na tym, iż dam jakieś urządzenie typu
master, które będzie kontrolowało transmisję.
Proponuję następujące rozwiązanie:
Master wysyła paczkę danych "NADAWAJ", która po poprawnym odebraniu
przez adresata i zdekodowaniu ustawia flagę "zezwól na nadawanie".
Pakiet należy zaopatrzyć w adres, aby nie odpowiedziały wszystkie
urządzenia.
Slave testuje flagę "zezwól na nadawanie" i gdy ma zezwolenie to nadaje
to co wczesniej buforował.
Paczka danych "NADAWAJ" rozsyłana przez Mastera może zostać zakłócona.
Należy rozważyć konieczność wysyłania kilkakrotnie tego komunikatu aż do
skutku.
From: "A.Grodecki" <ag.usun_to_at_nospam_modeltronik.com>
Subject: Re: Pochwalcie =?ISO-8859-2?Q?si=EA_-_CC1000?=
Date: Tue, 21 Mar 2006 15:00:14 +0100
(vhdl_at_nospam_poczta.fm) napisał(a):
Należy rozważyć konieczność wysyłania kilkakrotnie tego komunikatu aż do
skutku.
To mi przypomina stary dowcip komputerowy - Co myśleć o programie który
co chwilę wypluwa na ekran kolejną linię tekstu "jeszcze się nie
zawiesiłem" ?
)
P.S.
A słyszeliście ten dowcip z kregów ministerialnych?:
"Usprawniono wewnętrzną komunikację telefoniczną w Ministerstwie
Sprawiedliwości. Aby dodzwonić się bezpośrednio do ministra Ziobro,
wystarczy zacisnąć zero na klawiaturze"
--
Pozdrawiam,
A. Grodecki
"Wszystkie zwierzęta sa równe.
Ale te, które mają futerko w trzykolorowe pasy, są równiejsze."
From: "(vhdl_at_nospam_poczta.fm)" <vhdl_at_nospam_poczta.fm>
Subject: Re: Pochwalcie =?ISO-8859-2?Q?si=EA_-_CC1000?=
Date: Tue, 21 Mar 2006 14:55:10 +0100
Próba użycia napięcia z
detektora do sprawdzania zajętości jest na tyle nieskuteczna co i głupia.
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 :)
From: "A.Grodecki" <ag.usun_to_at_nospam_modeltronik.com>
Subject: Re: Pochwalcie =?ISO-8859-2?Q?si=EA_-_CC1000?=
Date: Tue, 21 Mar 2006 15:27:36 +0100
(vhdl_at_nospam_poczta.fm) napisał(a):
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?
A jakżeby inaczej.
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.
Nie wyłączenia, tylko zatrzaśnięcia wyniku. Detekcja poziomu odniesienia
jest niezbędna w KAŻDYM formacie przesyłanych danych i istnieje w
formie sprzętowej w każdym rodzaju odbiornika. Bo niby na podstawie
czego ma działać komparator - separator stanów logicznych???
--
Pozdrawiam,
A. Grodecki
"Wszystkie zwierzęta sa równe.
Ale te, które mają futerko w trzykolorowe pasy, są równiejsze."
From: "[g.d.]" <g_d.WYTNIJ_at_nospam_gazeta.pl>
Subject: =?ISO-8859-2?Q?Re:_Pochwalcie_si=EA_-_CC1000?=
Date: Tue, 21 Mar 2006 09:08:42 +0000 (UTC)
Krzysztof <krysss1981_at_nospam_poczta.onet.pl> napisał(a):
Przede wszystkim jednak to chyba moja ułomność i stres,
że braknie mi czasu do obrony.
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/
From: "Robert" <mojejapko_at_nospam_poczta.onet.pl>
Subject: Re: Pochwalcie się - CC1000
Date: Tue, 21 Mar 2006 16:31:30 +0100
Użytkownik "Krzysztof" <krysss1981_at_nospam_poczta.onet.pl> napisał w wiadomości
news:dvm9js$ik7$1_at_nospam_inews.gazeta.pl...
Witam!
Czy komuś udało się zastosować jakiś protokół przesyłania danych
w eterze używając tych modułów?
...
witam
Robilem bardzo podobny projekt na swoja prace inzynierska. Protokol
transmisji rozwiazalem tak ze po kazdej nadanej "paczce" danych drugi modem
odsyla potwierdzenie. Jezeli ten pierwszy nie dostaje potwierdzenia
odczekuje jakas losowa wartosc czasu i ponawia nadawanie do skutku. Losowa
wartosc dlatego ze gdy obydwa modemy zaczna "mowic" do siebie jednoczesnie
to znacznie zwieksza to prawdopodobienstwo ze ktorys modem zacznie odbierac
prawidlowe dane. Dodatkowo moze wystapic sytuacja w ktorej jeden modem
odbiera dane po czym odslyla potwierdzenie i z jakichs wzgledow
potwierdzenie nie zostanie odebrane przez modem nadawczy - wtedy modem nada
drugi raz to samo. Aby uniknac takich podwojnie odebranych ramek dodalem bit
parzystosci kazdej ramki. Prosty protokol i okazal sie byc nadzwyczaj
skuteczny;] przesylalem w ten sposob cale pliki jednoczesnie przez obydwa
modemy. Fakt ze wystapienie kolizji znacznie spowalnia transmisje ale nie
wplywalo to na poprawnosc odbioru danych. Jedyne czego im brakowalo to sum
kontrolnych bo czsem zdazaly sie przeklamane pojedyncze bity.
pozdrawiam
From: "Mariusz Bukowski" <mariusz_at_nospam_wmc.com.pl>
Subject: Re: Pochwalcie się - CC1000
Date: Tue, 21 Mar 2006 23:25:27 +0100
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
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
From: "(vhdl_at_nospam_poczta.fm)" <vhdl_at_nospam_poczta.fm>
Subject: Re: Pochwalcie =?ISO-8859-2?Q?si=EA_-_CC1000?=
Date: Sun, 26 Mar 2006 16:22:17 +0200
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
From: Adam Dybkowski <adybkows123_at_nospam_amwaw.edu.pl>
Subject: Re: Pochwalcie =?ISO-8859-2?Q?si=EA_-_CC1000?=
Date: Mon, 27 Mar 2006 00:18:51 +0200
(vhdl_at_nospam_poczta.fm) napisał(a):
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.
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.
From: "(vhdl_at_nospam_poczta.fm)" <vhdl_at_nospam_poczta.fm>
Subject: Re: Pochwalcie =?ISO-8859-2?Q?si=EA_-_CC1000?=
Date: Mon, 27 Mar 2006 21:25:45 +0200
Opowiem, jak się do CC1000 zabrać:
Producent udostępnił Development KIT oraz biblioteki. Przedstawiony
układ pełni rolę bezprzewodowego przedłużenia RS232. Dokumentacja jest
dostępna pod adresem
http://www.chipcon.com/index.cfm?kat_id=2&subkat_id=12&dok_id=14.
Następnie należy sciągnąć AN015 -- RF modem reference design.
Tam są źródła do AVR i PIC'a.
Wykorzystałem firmowe biblioteki i zaimplementowałem je na platformie
PIC18LF452. Programowanie w środowisku HI-TIDE.
Jeśli chodzi o implementację samego protokołu to po analizie programów
źródłowych łatwo zauważyć, że w programie głównym są funkcje
odpowiedzialne za "warstwę wyższą" systemu radiowego. Tutaj można się
rozpisać implementując potrzebne nam protokoły.
W procedurach obsługi przerwań zrealizowana jest obsługa warstwy
fizycznej "systemu radiowego". Ramka danych składa się z 4 bajtów
preambuły, 2 znaków UI1 i UI2, pola długość i pola danych.
Szczegóły są dobrze opisane w dokumentacji (m.in. AN015).
pozdrawiam
Janusz