CC1000 ile "bajtów charakterystycznych" po preambule

Witam!

Zrobiłem sobie mały eksperyment :). Nadaję przez CC1000 ramkę składającą się z następujących bajtów:

0xAA 0xAA 0xAA 0xAA 0xAA | 0xB6 | 0x73 0x74 0x61 0x72 0x74

Pierwsze 5 bajtów to bajty preambuły, koniecznej w tego typu transmisji. Następny bajt to tzw. bajt charakterystyczny. Umożliwia mi on bajtową synchronizację odbiornika z nadajnikiem. Dzięki niemu wiem, od którego miejsca znajdują się dane. Problem polega na tym, że gdy odłączyłem nadajnik, odbiornik nadal "myślał", że przychodzą dane bo wykrywał śmieci, wśród których znajdowały się między innymi bajty preambuły i bajt charakterystyczny. Pomyślałem sobie, że po dołożeniu drugiego bajtu charakterystycznego czyli

0x73, zmniejsze ryzyko identyfikacji śmieci jako faktyczne dane. W końcu to już jest małe prawdopodobieństwo, że trafi się bajt 0xB6 a zaraz po nim 0x73. Mniej więcej tyle, co (1/65535)/2 ???? - takie jest to prawdopodobieństwo (nie mówiąc już nawet o preambule, która też musi wcześniej wystąpić). Zapuściłem więc algorytm i okazało się, że już po 2 sekundach zdarzyła się taka sytuacja, że odbiornik odebrał po kolei te 2 bajty. Myślę sobie - kurcze niby małe prawdopodobieństwo ... no ale w totka też ludzie wygrywają :). W końcu wysyłam jakieś 1200 znaków na sekundę ( skąd te dwie sekundy??).

Dodałem więc trzeci bajt charakterystyczny, puściłem algorytm i czekałem, czekałem...5 minut. Znów wystąpiła sytuacja, że po sobie wystąpiły śmieci 0xB6 0x73 0x74.

Dodałem więc 4 bajt charakterystyczny i jak na razie filtruje on śmieci dobrze.

Ciekaw jestem ile bajtów wstawiają ludzie, którzy się na tym znają. !!! A może odpowiedni dobór wartości bajtów charakterystycznych coś tutaj może zmienić??

Z góry dziękuję za odpowiedź

Pozdrawiam

Reply to
Krzysztof
Loading thread data ...

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

Nie koniecznie sie na tym znam, ale zrobilem nastepującą ramke o stałej długości:

- preambula : 0xaa 0x55 0xaa 0x55,

- bajt identyfikacji (poznaje jaki nadajnik nadaje)

- X bajtów danych,

- "suma kontrolna" - napisałem w cudzysłowiu, bo to zwykła suma bajtów całej ramki z preambułą włącznie + 1

  1. W odebranym ciagu bitów szukam najpierw poprawnej preambuly
  2. Jeśli znajdzie , to dobieram całą ramke i licze "sume kontorlna"
  3. Identyfikuje na podstawie 5 bajtu CO nadaje.

W moim zastosowaniu, prędkość transmisji ma mniejsze znaczenie. Nie potrafie zmusic modułów do pracy z predkośćią > 9,6 . Pewnie moj program sie nie wyrabia :)

Piotr

Reply to
Piotr Nowakowski

Nie uważam się za fachowca, ale też to ćwiczyłem. U siebie zadowalające wyniki uzyskiwałem przy ok 20 bitach preambuły, tyle że miałem ograniczenia maksymalnego i minimalnego rozmiaru preambuły. Jeżeli chodzi o bajty charakterystyczne to był 1 stały bajt nagłówka, potrem adres nadawcy, odbiorcy, numer polecenia i ilość danych. W zasadzie tylko 1 typowy jak u Ciebie, ale sprawdzam poprawność wszystkich innych, więc łączna liczba bitów charakterystycznych to ok. 20 (pozostałe to zmienna informacja).

Reply to
PitLab

Użytkownik "PitLab" snipped-for-privacy@wp.pl napisał w wiadomości news:dsae11$8n6$ snipped-for-privacy@node1.news.atman.pl...

Rozumiem!

Czyli jeśli dołożę jeszcze jeden bajt charakterystyczny a na końcu dam CRC to na pewno uniknę identyfikacji szumu jako poprawnie nadawanych danych.

Reply to
Krzysztof

Polecam położyć zdecydowanie wiekszy nacisk na CRC niż na bajty charakterystyczne. Moim zdaniem są one po to aby stwierdzić gdzie zaczyna się ramka a kończy preambuła. Zwiększanie liczby bajtów charakterystycznych nie zwiększa Ci pewności transmisji a jedynie zmniejsza efektywne wykorzystanie medium. Zawsze może być przypadek że w prawidłowo odebranej ramce będziesz miał przekłamanie (wywołane zakłóceniem w eterze) gdzieś w nieweryfikowalnej cześci np w danych. CRC, najlepiej 16 bitowe wyłapie wszystkie problemy zarówno z fałszywymi jak i przekłamanymi ramkami. Jest uniwersalniejsze.

Reply to
PitLab

Nie zebym jakos sie bardzo znal, ale mysle, ze moglbys dodac cos w stylu CRC. Jakas naprostsza sume kontrolna. Pomoze :-)

Naglowek + ID + dane + CRC i bedzie cacy.

m.

Reply to
Martin Lukasik

No tak, ale jesli "pakiet" ma zalozmy 8 bitow, to nie wiem czy CRC 16bit to najciekawsza z opcji ;-)

m.

Reply to
Martin Lukasik

Co to jest pakiet? Ramka transmisyjna nawet pusta, czy z informacją typu "OK" (bez preambuły) u mnie zajmuje 4 -5 bajtów w zależności od implementacji protokołu, więc już jest z czego liczyć. Zresztą CRC16 można policzyć nawet z 1 bitu, jeżeli brakuje danych dostawia się zera. Radio to bardzo zaśmiecone medium. moim zdaniem 8 bitowe CRC, czy suma kontrolna to trochę za mało. Do połączeń przewodowych 8 bitów mi wystarcza, ale przy radiu o ile nie stanowi to problemu implementacyjnego to nie oszczędzal bym.

Reply to
PitLab

Użytkownik "PitLab" snipped-for-privacy@wp.pl napisał w wiadomości news:dsafsl$966$ snipped-for-privacy@node1.news.atman.pl...

Zgadzam się ale ważne też jest aby jak najszybciej odrzucić śmieci. W przypadku, gdy moja ramka składać się będzie z ok 70 bajtów, nie mogę pozwolić sobie aby dopiero po odebraniu całej ramki stwierdzać, że odbierałem śmieci. Jest to ważne z tego względu, że w połowie odbierania tej ramki z szumami zacząć może się ramka z danymi prawidłowymi, przez co mogę ją stracić. Może przesadzam ale w momencie gdy dane przesyłane są dość często sytuacja taka wydaje się prawdopodobna.

Reply to
Krzysztof

Może analizuj parametry czasowe? Szansa że przypadkowy szum będzie miał takie parametry jak prawidłowa transmisja bardzo szybko maleje w funkcji długości ramki. Po prostu odrzucasz ramkę jeżeli czas między kolejnymi bitami / bajtami jest większy niż pewna założona granica. Jak pisałem wcześniej, analizuję też pewne cześci protokołu np sprawdzam zakres takich parametrów jak ilość danych, adresy urzadzeń, numery poleceń itp. Jeżeli parametr jest spoza zakresu odrzucam ramkę i wram do fazy protokołu zajmującej się detekcją preambuły.

Moim zdaniem to bardzo długa ramka. Spróbuj zrobić test określający optymalną długość ramki w Twoich warunkach. Wysyłaj ustalony wzór np 0x01,

0x02, 0x03... o różnej długości (10, 20, 30... 100, 150, 200) bajtów i sprawdzaj jaka liczba ramek dotrze w całości, oczywiscie w warunkach zbliżonych do rzeczywistych. Im dłuższa ramka tym większa podatność na przekłamanie i ewentualna retransmisja zajmuje wiecej czasu. Z drugiej strony lepszy jest stosunek danych użytecznych do wszystkich danych przesyłanych w ramce. Wylicz przy jakiej długosci ramki masz największą przepustowość. Być może okaże się że efektywniej będzie przesyłać to w ramkach krótszych. Typowe zadanie optymalizacyjne ;-)

Tak czy inaczej musisz mieć protokół zapewniający pewność przesyłu danych. Jeżeli ramka nie dotarła trzeba ją retransmitować. U siebie potwierdzam prawidłowy odbiór każdej ramki. Jeżeli nie ma potwierdzenie odbioru, nadawca sam wysyła ponownie ramkę. Oczywiście liczba powtórek jest ograniczona protokołem. Jeżeli nie przejdzie pomimo iluś tam retransmisji zgłaszam błąd łącza. Można też numerować ramki. Jeżeli ostatnio przyszła ramka 55 a potem 57 to trzeba wysłać żądanie ponownego przysłania ramki 56. Takie rozwiązanie wymaga wiekszej ilości pamięci. Generalnie można wymyslić wiele metod zapewniających poprawną transmisję. Wiele zależy od aplikacji i nie ma uniwersalnych rozwiązań. Czasami warto poczytać jak się to robi w standardowych protokłach np ZigBee.

Reply to
PitLab

Naglowek + dane, z reguly.

Ale rownie dobrze moze zajmowac 2 bajty. Moze nawet 1.

Tak, ale chodzilo o to, ze wtedy wysylasz wiecej sum kontrolnych niz danych...

Zgadzam sie jak najbardziej :-)

m.

Reply to
Martin Lukasik

Tyle zajmuje _u mnie_ ze względu na jednolitość protokołu. Dzieki temu każda ramka ma taki sam nagłówek i protokół jest prostszy. Doszedłem do wniosku że ramka potwierdzająca przybycie "ważnej" ramki z danymi (niosąca tylko informację typu: jest OK) jest tak samo ważna jak potwierdzane dane i nie ma co oszczędzać na jej długości. Spróbuj zweryfikować poprawność ramki 1 bajtowej. To może przejść przy transmisji przewodowej, ale przy radiu moim zdaniem tak nie można.

W moich projektach komunikacja jest glównie typu master-slave. Urządzenie podrzędne może dostać polecenie + ewentualne dane i odpowiedzieć OK (lub ERR z kodem błędu), lub dostać polecenie wymagające odesłania danych. Doszedłem do wniosku że nie warto dawać krótszej ramki w przypadku gdy odpowiada tylko "OK", bo to za bardzo komplikuje protokół. Jest troszkę dłużej, ale prościej i zawsze tak samo. Takie podejscie ułatwia rozdzielanie poszczególnych "warstw sieciowych" protokołu. Są procedury:

- warstwy sprzętowej wysyłające i dobierające dane,

- warstwy protokołu, które mają odebrać i sprawdzić poprawność ramki.

- potem jest procedura analizująca dane w ramki i uruchamiająca poszczególne polecenia.

- na koniec są procedury wykonawcze konkretnych poleceń. Pierwsza warstwa chodzi w przerwaniach, pozostałe w petli głównej. Nowy projekt zwykle wymaga zmodyfikowania 1-2 warstw co istotnie przyspiesza czas pracy przy kolejnym projekcie.

Trudno. Tam gdzie potrzebna jest pewność przesłania informacji trzeba liczyć się z "kosztem" wysłania kilku dodatkowych bajtów.

Reply to
PitLab

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.