Pochwalcie się - CC1000

Użytkownik Krzysztof napisał: [..]

[..] [..]

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

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):

Użytkownik snipped-for-privacy@poczta.fm napisał w wiadomości news:dvna3k$jdq$ snipped-for-privacy@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

Krzysztof snipped-for-privacy@poczta.onet.pl> napisał(a):

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

pozdro. [g.d.]

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.

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.

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

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.

Użytkownik "A.Grodecki" <ag.usun snipped-for-privacy@modeltronik.com napisał w wiadomości news:dvop7h$sub$ snipped-for-privacy@nemesis.news.tpi.pl...

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.

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."

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

Użytkownik snipped-for-privacy@poczta.fm napisał w wiadomości news:dvonqh$2pf$ snipped-for-privacy@achot.icm.edu.pl...

Przetwornik A/C

Użyłem gotowych modułów. Kupiłem je w Kamami Dokładnie tego modułu:

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.

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.

Użytkownik snipped-for-privacy@poczta.fm napisał w wiadomości news:dvonqh$2pf$ snipped-for-privacy@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

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 :)

Użytkownik "A.Grodecki" <ag.usun snipped-for-privacy@modeltronik.com napisał w wiadomości news:dvou6e$3i0$ snipped-for-privacy@atlantis.news.tpi.pl...

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

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?

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.

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 :)

( snipped-for-privacy@poczta.fm) napisał(a):

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"

( snipped-for-privacy@poczta.fm) napisał(a):

A jakżeby inaczej.

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???

Użytkownik "Krzysztof" snipped-for-privacy@poczta.onet.pl> napisał w wiadomości news:dvm9js$ik7$ snipped-for-privacy@inews.gazeta.pl...

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

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.

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.