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

Nad/Odb 433MHz - kod Manchester - porównania/ranking

mirekk36 06 Lut 2010 19:11 35237 48
  • #31
    mirekk36
    Poziom 42  
    piotr411 --> bardzo chciałbym się mylić w sprawie tego kompletu z mojego 3go miejsca ;) ....

    Anteny stosowałem dokładnie takie same jak do pozostałych czyli ćwierć-falowe (drucik o długości 16,5cm). Zasilanie dla nad i odb = +5V

    I powiem tak - widać było że fizyczny zasięg był, nawet z odłączonymi antenami dawała sobie radę jakaś transmisja. Ale właśnie jakaś .... bo jak się rozpisywałem na oscylu widać było, że sygnał jest co jakiś czas szatkowany. Tzn widać ładny sygnał z nadajnika ale co chwilkę jakieś szpile wskakują i znikają. Dokładnie tak samo jak przy wyłączony nadajniku - wtedy sam odbiornik zamiast mieć na wyjsciu jakiś szum - to ma jak to określiłem 'trzaski" zo kilkadziesiąd ms jakieś szpile przypadkowe o naróżniejszej szerokości się pojawiają. I pewnie bym nie pisał że są zaraz takie najgorsze gdyby to tylko u mnie tak się działo ale i inni opisywali podobne silne zakłócenia w tych komplecikach. Reasumując mój ranking wcale nie jest obiektywny - opiera się tylko na moich doświadczeniach i akurat z tych kompletów nic nie potrafiłem sensowego wykrzesać - ale przez te zakłócenia - bo sygnał nadawany i to ładny się pojawiał.

    Jeśli możesz jeszcze jakieś konkrety opisać ? jeśli sam coś z nimi robiłeś i miałeś w pełni pozytywne doświadczenia to chętnie posłucham i skorzystam z porad jeśli tylko okaże się, że coś pomogą.
  • OptexOptex
  • #32
    piotr411
    Poziom 22  
    Odbiornik RX433Mhz zasilasz 5V, Nadajnik TX433N 7V-16V
    przy 5V miałeś mniej niż 9mW
    przy 16V masz 180mW
    przy małym "Tuningu" można generować moc 3W
    ale za takie pomysły zraz zostanę zlinczowany przez
    fachowców od W.Cz


    przy mocy ją dysponuje TX433,
    antena ją stosujesz na 90% uszkodzi TX'a
    warunkiem poprawnego działania wszystkich nadajników ASK
    jest nadawanie "nośnej"

    Jak juz pisaem najlepszym zestawem jest TX433N i odbiornik Aurel RX-4MM5

    Anteny GP idealnie nadaja sie od sterowania bram
  • #33
    mirekk36
    Poziom 42  
    ciekawe rzeczy piszesz, szczególnie z tym zasilaniem nadajnika, rzeczywiście mam takie małe bateryjki na 12V więc popróbuję ale....

    piotr411 napisał:

    przy mocy ją dysponuje TX433,
    antena ją stosujesz na 90% uszkodzi TX'a
    warunkiem poprawnego działania wszystkich nadajników ASK
    jest nadawanie "nośnej"


    a możesz dokładniej opisać jak sobie zrobić dokładnie taką antenę jak trzeba żeby nie uszkodzić? i żeby dobrze nadawał? Bo wiesz dla ciebie skoro dobrze się znasz na antenach to jak rzucisz Yagi czy GP to wiesz co to jest ale ja nie za bardzo ;) przynajmniej na razie

    piotr411 napisał:

    Jak juz pisaem najlepszym zestawem jest TX433N i odbiornik Aurel RX-4MM5


    No takiego odbiornika Aurela akurat nie posiadam - ale czy to nie świadczy że może właśnie coś jest nie tak z tym odbiornikiem Vellmana ??
  • #34
    BoskiDialer
    Poziom 34  
    Cofając się trochę z tematem:
    master_pablo napisał:
    Trzeba ustawic UART w tryb 8n1 (8 bitow danych, brak bitu parzystosci, 1 bit stopu) i wysylac kazdy bajt na trzy razy. Bit startu ma wartosc 0, a wiec bit wysylany po nim musi miec wartosc 1, a bit stopu ma wartosc 1, wiec bit wysylany przed nim musi miec wartosc 0. [...]A wiec chcac wyslac 5Ah=0101 1010b wysylamy kolejno:
    CCh=1100 1100b (wysylamy 0101 1010)
    [...]

    O ile pamiętam, UART wysyła dane zaczynając od LSB, więc jak już, to bit 0 powinien być ustawiony (jako ten postępujący po starcie), natomiast bit 7 skasowany (jako poprzedzający stop).
  • #35
    zgierzman
    Poziom 26  
    Napisałeś:
    mirekk36 napisał:
    No tu już sytuacja była dużo dużo lepsza bo z pełną odpowiedzialnością mogę powiedzieć, że transmisję RS232 może nie najszybszą bo tylko 4800bps można na tym spokojnie uzyskać

    oraz:
    mirekk36 napisał:
    DŁUGOŚĆ BITU 200us

    Oba cytaty odnoszą się do tego samego modułu.

    Dla szybkości 4800bps długość jednego bitu wynosi z grubsza 200µs, w obu przypadkach trzeba filtrować błędne dane. Wygląda więc na to, że prędkość transmisji nie poprawi się w żaden sposób. Można tylko schodzić w dół dla gorszych modułów.
    Jaki masz procent błędnych ramek/bajtów przy korzystaniu ze sprzętowego UARTa, a jaki w przypadku softwarowego rozwiązania transmisji dla podobnych prędkości?
    Zgaduję, że w połowie tych 200µs otwierasz sobie okno w którym oczekujesz zmiany stanu. Jak szerokie jest to okno?
  • #36
    mirekk36
    Poziom 42  
    zgierzman --> gdy pisałem o długości bitu 200us to w ogóle nie miałem na myśli długości bitu w ramce RS232. W ogóle w tych testach dałem sobie spokój z RS232. Wykonałem własny protokół transmisji, który wywodzi się z RC5. Jednak u mnie właśnie długość bitu to 200uS i dokładnie z taką długością ładnie działa ale ta moja transmisja. U mnie jest tak, że jedna ramka składa się z:

    1-go bitu toggle
    5-ciu bitów adresu
    8-miu bitów komendy

    Odstęp między ramkami musi być ok 400us a każda ramka poprzedona jedną ramką synchronizacyjną

    nazewnictwo przypadkowo zbierzne z RC5 ;)

    ale tak to właśnie działa i dzięki temu po drugiej stronie otrzymuję 100% poprawnych ramek z właściwymi danymi.

    Jak to odbieram? - wykorzystuję do tego wejście ICP od Timera1 i w tym przerwaniu dokonuję pomiarów czasów poszczególnych bitów od razu je dekodując ale też na tym etapie (że tak powiem sprzętowo) filtrując ew uszkodzone ramki.

    Cały mechanizm sprawuje się świetnie i dzięki temu mogę zrobić sobie na dowolnym kompleciku coś w rodzaju pilota IR ale z większymi możliwościami a do tego mogę dokonywać prostej transmisji niewielkich ilości danych. Niewielkich bo duże ilości mijają się z celem ze względu na czas.

    Tak czy owak użycie przerwań do odbioru ramek to super pomysł bo działa to niezależnie od programu głównego i to dobrze ;)
  • OptexOptex
  • #37
    zgierzman
    Poziom 26  
    mirekk36 napisał:
    zgierzman --> gdy pisałem o długości bitu 200us to w ogóle nie miałem na myśli długości bitu w ramce RS232. W ogóle w tych testach dałem sobie spokój z RS232. Wykonałem własny protokół transmisji, który wywodzi się z RC5. Jednak u mnie właśnie długość bitu to 200uS i dokładnie z taką długością ładnie działa ale ta moja transmisja.

    Tak, rozumiem to, ale nie mogłem się powstrzymać przed szybkim policzeniem i porównaniem. No i wyszło mi, że czas transmisji jednego bitu ok 200µs odpowiada z grubsza 4800bps.
    mirekk36 napisał:
    ale tak to właśnie działa i dzięki temu po drugiej stronie otrzymuję 100% poprawnych ramek z właściwymi danymi.

    I tu ujawnia się przewaga nad wykorzystaniem tego, co pierwsze przychodzi na myśl, czyli sprzętowego UARTa. Możesz oszacować jaki procent danych był błędny kiedy eksperymentowałeś z UARTem?
    mirekk36 napisał:
    Jak to odbieram? - wykorzystuję do tego wejście ICP od Timera1 i w tym przerwaniu dokonuję pomiarów czasów poszczególnych bitów od razu je dekodując ale też na tym etapie (że tak powiem sprzętowo) filtrując ew uszkodzone ramki.

    Potrafię to sobie wyobrazić, ale chętnie dowiedziałbym się jak ty zrealizowałeś ten algorytm. Mierzysz czas trwania jedynki i zera na wejściu (wymaga to ciągłego przestawiania sposobu wyzwalania ze zbocza opadającego na wznoszące i na odwrót), czy masz jakiegoś pomysła na odtworzenie danych tylko z pomiarów jednego stanu? Możesz ze szczegółami to opisać?
    Pytałem też o "tolerancję" - jeśli jakiś stan ma mieć np 100µs, czy 200µs, to przecież nigdy nie ma z dokładnością do jednego cyklu zegara. Musi być jakiś margines bezpieczeństwa, takie okno... Jak jest szerokie? 1%, 10%...?
  • #38
    mirekk36
    Poziom 42  
    zgierzman --> no, wg mnie nie za bardzo da radę coś takiego porównać nawet z grubsza z 4800bps.

    Jak pisałem przy zastosowaniu sprzętowego czy programowego ale UART'a procent błędów strasznie się zwiększał - jaki był ? nie pamiętam ale b.duży. Tyle że wcale to nie wskazuje na wyższość nad UART'em --- bo po prostu UART nie przewiduje kodowania danych jak np Manchester - a to z kolei powoduje pewną nadmiarowość przesyłanych danych itp.

    Odnośnie dekodowania. Pisałem gdzieś wcześniej i podawałem link do opisu kodowania bifazowego. Ja tak jak pisałem używam przerwania ICP a w przerwaniu:

    1. mierzę czas pomiędzy każdym opadającym i rosnącym zboczem dzięki czemu mierzę dokładnie czas w tym przypadku połówki każdego bitu. Dzięki temu mogę sobie spokojnie założyć, że tolerancja może być aż 20% !!! i nadal wszystko będzie dobrze!!!

    2. aby mierzyć czas pomiędzy każdym zboczem oczywiście w procedurze obsługi tego przerwania co chwilę zmieniam stan wykrywanego zbocza na przeciwny - co za problem?

    Nie wiem więc po co miałbym przy takiej możliwości kombinować wykrywanie tylko jednego stanu? po co sobie życie utrudniać i kod zarazem?

    Oczywiście tą samą metodą w przypadku dekodowania podczerwieni dokonuję sprawdzania kodów przylatujących nie tylko w RC5 przy równej dłgości połówek bitów. Ale także dekoduję standardy SIRC(SONY) czyli SPACE albo PULSE. Wszystko tak samo za pomocą tego jedynego przerwanka ;)
  • #39
    Gigantor
    Poziom 18  
    Ja robilem transmisję danych na modułach TLX2401 (2,4GHz). Maksymalna prędkość transmisji danych - 115200bps, z dynamicznym scramblingiem i możliwą pojedynczą retransmisją uszkodzonej ramki (dł. danych 1024 bajty, przy max. prędkości). Zasięg niewielki, do 100m, ale za to antenka nie wystaje.
  • #40
    kazkowicz
    Poziom 14  
    mirekk36 napisał:

    1. mierzę czas pomiędzy każdym opadającym i rosnącym zboczem dzięki czemu mierzę dokładnie czas w tym przypadku połówki każdego bitu. Dzięki temu mogę sobie spokojnie założyć, że tolerancja może być aż 20% !!! i nadal wszystko będzie dobrze!!!

    2. aby mierzyć czas pomiędzy każdym zboczem oczywiście w procedurze obsługi tego przerwania co chwilę zmieniam stan wykrywanego zbocza na przeciwny - co za problem?


    Witam,

    Jeżeli to rzeczywiście twój sposób na unikanie zakłóceń, to już zupełnie nic nie rozumiem, chyba że świadomie wprowadzasz nas w błąd, by ukryć prawdziwy algorytm. Każdy przypadkowy trzask w odbiorniku (pojedyncze H-L-H lub L-H-L) podczas odmierzania czasu trwania bitu spowoduje błędny odczyt nie tylko tego, ale również kolejnych bitów. Sprzętowy USART AVR próbkuje każdy bit 16 razy, z czego trzy próbki są używane do określenia stanu odbieranego bitu (decyduje większość). Zatem przypadkowy trzask podczas odbioru bitu musi zakłócić dwa kluczowe próbkowania, żeby wystąpiło przekłamanie danego bitu - a i tak odbiór pozostałych bitów może być pomyślny. Jedynym problemem z USART potencjalnie jest (na ile rozumiem jego działanie) pojedyncza synchronizacja na początku bitu startu, która inicjuje skewencję odbioru całego bajtu (ramki). Zakłócenie będące w stanie zasymulować bit startu (nadal jednak musi ono "oszukać" mechanizm wielokrotnego próbkowania bitu) spowoduje odbiór całego przypadkowego bajtu (ramki). W USART dostępny jest jednak bit błędu parzystości PE i bit błędu ramki FE (nieprawidłowy bit stopu), które pomogą odrzucić błędne bajty. Oczywiście nieszczęśliwy zbieg okoliczności (wystąpienie fałszywego bitu startu) na krócej niż czas trwania bajtu (ramki) przed właściwą transmisją uniemożliwi prawidłowy odbiór, ale takie same (lub nawet większe) zagrożenia widzę w twojej metodzie. Ciekawe jakie wyniki przyniosłoby wykorzystanie wspomnianych bitów USART PE/FE, o których nic nie wspomniałeś. Dla małych prędkości transmisji można również napisać procedurę odbiornika, która będzie próbkować każdy bit dokładniej i lepiej, niż sprzętowy USART, za to po stronie nadawczej mamy zero problemów. Manchester sprawdzał się w systemach, gdzie nie mogło być składowej stałej i występowały wahania prędkości transmisji (np. wczytywanie programów z kasety), zbocze w środku bitu pomagało synchronizować zegar odbiornika i nawet dla długich ciągów zer lub jedynek nadal był sygnał AC. Inne niż RC5/6 systemy zdalnego sterowania w podczerwieni niekoniecznie używają Manchestera, polegając raczej na zależnościach czasowych...
  • #41
    mirekk36
    Poziom 42  
    kazkowicz napisał:

    Jeżeli to rzeczywiście twój sposób na unikanie zakłóceń, to już zupełnie nic nie rozumiem, chyba że świadomie wprowadzasz nas w błąd, by ukryć prawdziwy algorytm. Każdy przypadkowy trzask w odbiorniku (pojedyncze H-L-H lub L-H-L) podczas odmierzania czasu trwania bitu spowoduje błędny odczyt nie tylko tego, ale również kolejnych bitów. ...


    Sorki, ale co ty za bajki tu opowiadasz o jakimś świadomym wprowadzaniu w błąd albo ukrywaniu algorytmu???? Chyba jasno napisałem, że programu, jak zwykle zresztą nie udostępniam, więc tylko ogólnie opisałem co po kolei robię. Jeśli nie możesz sobie tego wyobrazić, napisać, zrobić - to dopytaj a nie zarzucaj wprowadzanie w błąd - bo u mnie to działa i to rewelacyjnie.

    Pewnie, że "trzask" spowoduje błędny odczyt czyli u mnie zostanie wygenerowana tzw BAD_FRAME (zła ramka), która nie zostanie dalej przekazana do analizy. A po takim "trzasku" nie będą analizowane kolejne bity tej ramki. Więc nie wiem o co ci chodzi.

    Jeśli płodzisz jakiś konkretny program i masz z czymś konkretnym problem to napisz - postaram się pomóc - no chyba że chciałeś się troszkę tylko nagadać i to jakby nie na temat - to proszę ;)
  • #42
    kazkowicz
    Poziom 14  
    Cytat:
    mirekk36
    Pewnie, że "trzask" spowoduje błędny odczyt czyli u mnie zostanie wygenerowana tzw BAD_FRAME (zła ramka), która nie zostanie dalej przekazana do analizy. A po takim "trzasku" nie będą analizowane kolejne bity tej ramki. Więc nie wiem o co ci chodzi.


    Czyli podsumowując pojedyncze zakłócenie powoduje utratę całego bajtu danych. W porównaniu ze sprzętowym USART wygląda to słabo. Chodzi mi właśnie o ten brak odporności na najmniejsze, pojedyncze zakłócenie transmisji. 100% braku odporności na zakłócenia podczas przesyłania bajtu. Plus dwa razy szersze pasmo kodowania Manchester, kolejny powód wzrostu zakłóceń (szersze pasmo sygnału odbieranego).

    Twoje rozwiązanie u ciebie się sprawdza, jednak chyba czasem warto rozważyć inne opcje.
  • #43
    mirekk36
    Poziom 42  
    kazkowicz --> człowieku, zastanów się gdzieś ty tu widział w tym temacie jakieś opinie, że sygnał kodowany bifazowo jest lepszy czy gorszy od RS232 ??? Sorry ale chyba w ogóle nie rozumiesz co to jest i do czego służy kodowanie Machester. Ciężko więc nawet z tobą dyskutować.

    a reasumując na poważnie to nie robiłem kodowania bifazowego, szczególnie dla kompletów Arel'a dlatego żeby było lepiej niż przy wykorzystaniu RS232 ale dlatego, że te komplety z transmisją RS232 w ogóle praktycznie nie działają a jak już cokolwiek to może przy prędkościach 100 bodów jesl w ogóle. Jeśli nie rozumiesz dlaczego nie działa na nich transmisja RS232 z twoją kontolą parzystości itp .... to nic już na to nie poradzę. Proponuję więc zamiast wypisywać tu takie teorie spiskowe dziejów, weź się w garść i wypróbuj to w praktyce - to gwarantuję że szybko zaskoczysz po co w ogóle stworzono różnego rodzaju kodowania sygnałów i dlaczego je się stosuje w pewnych sytuacjach zamiast prostej transmisji RS232. Inaczej nie mamy dalej o czym mówić.
  • #44
    kazkowicz
    Poziom 14  
    A zatem zobaczmy, jakie są problemy z wykorzystaniem standardowego USART. Zrobiłem prosty nadajnik, wysyłający co sekundę dwa bajty - bajt nagłówka, 0X55, i bajt zwiększany po każdej transmisji. Nadajnik, zbudowany ze zdezelowanego pilota do bramy na TDK5100, pracuje z modulacją ASK z teoretyczną mocą 3mW. Szybkość transmisji 2400 bitów/s. Dane z wyjścia TXD przed podaniem na nadajnik są zanegowane. Odbiornik RX-4MM5 (AM) podłączyłem wprost do portu szeregowego komputera i do wejścia karty dźwiękowej. Gdyby w tym miejscu był mikroprocesor, to trzeba by ponownie zanegować sygnał. Nagrałem odebraną transmisję jako plik (załącznik mp3), szczegóły pokazałem na obrazkach (to nie oscyloskop, płynięcie składowej stałej spowodowane jest przez kondensator na wejściu karty) i jednocześnie przechwyciłem dane z portu szeregowego do pliku doc. Jak widać, cztery z pięciu wysłanych w czasie nagrania par bajtów zostały odebrane poprawnie, mimo że w powietrzu sporo się działo. Tło (trzaski) pochodzą najprawdopodobniej z komputera i telewizora, słychać też transmisje innych systemów. Odbiornik ma -3dB pasmo p.cz. 300kHz, zatem odbiera kilka kanałów rownocześnie. Port szeregowy komputera interpretuje napięcie 0 lub ujemne jako H, zaś napięcie ponad 3V jako L, to powinno ułatwić "czytanie" przebiegów. Pokazałem szczegóły zakłócenia ramki numer 4 (przekłamany jeden bit drugiego bajtu). Twój sposób odbioru też by się na to złapał. Tuż przed prawidłowo odebranym bajtem nagłówka 0X55 widać złośliwe zakłócenie tuż przed właściwym bitem startu, które zgodnie z twoim opisem uniemożliwi prawidłowy odbiór, a port szeregowy dał radę odebrać tansmisję - szpilka była za wąska i została sprzętowo zignorowana, u ciebie wykrywanie zbocza dałoby się nabrać. Nie wiem czy tylko dla mnie jest oczywiste, że kodowanie Manchester nic tu nie poprawia, a wręcz w zależności od praktycznej realizacji procedury odbioru może tylko pogorszyć sprawę. Chętnie porozmawiam o faktach, a nie mitach. Dla mnie fakt jest jeden - przde wszystkim na początku transmisji trzeba stosować jakiś nagłówek, aby system odbierający wiedział, które dane są dla niego. Pojedynczy bajt, jak u mnie, to ciągle za mało. wypadałoby dać dwa lub trzy - 0X55 lub 0XAA lub ich mix, są fajne, bo to naprzemienne ciągi zer i jedynek, trudne do podrobienia przez zakłócenia. Jedyna korzyść z zastosowania kodowania podobnego do RC5 u ciebie to właśnie wprowadzenie pewnego rodzaju nagłówka i tylko w tym upatruję poprawy wyników, o której pisałeś. Czy zaś jest to Manchester, czy NRZ jak u mnie, to ma już mniejsze znaczenie.
  • #45
    mirekk36
    Poziom 42  
    kazkowicz napisał:
    Nie wiem czy tylko dla mnie jest oczywiste, że kodowanie Manchester nic tu nie poprawia, a wręcz w zależności od praktycznej realizacji procedury odbioru może tylko pogorszyć sprawę. Chętnie porozmawiam o faktach, a nie mitach. Dla mnie fakt jest jeden - przde wszystkim na początku transmisji trzeba stosować jakiś nagłówek, aby system odbierający wiedział, które dane są dla niego. Pojedynczy bajt, jak u mnie, to ciągle za mało. wypadałoby dać dwa lub trzy - 0X55 lub 0XAA lub ich mix, są fajne, bo to naprzemienne ciągi zer i jedynek, trudne do podrobienia przez zakłócenia. Jedyna korzyść z zastosowania kodowania podobnego do RC5 u ciebie to właśnie wprowadzenie pewnego rodzaju nagłówka i tylko w tym upatruję poprawy wyników, o której pisałeś. Czy zaś jest to Manchester, czy NRZ jak u mnie, to ma już mniejsze znaczenie.


    Po pierwsze to chyba wiesz że RC5 jest równoznaczne z kodowaniem Manchester. Piszę o tym bo ty raz twierdzisz, że to nic nie pomaga a wręcz przeszkadza i że ja tworzę jakieś mity, a później piszesz że ew dzięki wprowadzeniu przeze mnie RC5 upatrujesz jakichś tam korzyści.

    Po pierwsze nikogo na siłę nie chcę do niczego przekonywać. A wyników swoich testów na swoich parach opisanych kompletów jestem pewien na 100%.

    Generalnie pisałem o tym, że takie komplety jak te firmy Aurel - praktycznie w ogóle nawet w 1% nie dają się wykorzystać do prostej transmisji RS232 i to z kilku względów nie tylko zakłóceń. W przypadku Telecontrolli występowały właśnie takie zakłócenia o jakich ty piszesz - czyli trzeba było robić dobrą softarową kontrolę ramek żeby nie łapać baboli czasem a zwiększanie zasięgu ponad 10m w pomieszczeniach zamkniętych drastycznie zwiększało poziom zakłóceń transmiji RS232. Jednak udawało się na niedużych odległościach mieć w miarę sprawny transfer na poziomie 4800 a nawet w porywach 9600 więc teoretycznie gdyby nie zasięg to nie byłoby tak źle.

    Niestety nie będę po raz kolejny polemizował na temat czy kodowanie Manchester i tego typu sposoby coś dają czy nie w celu poprawy transmisji a w zasadzie pewności przekazywanych informacji - bo jest to sprawa oczywista i trzeba troszkę poczytać o co tu chodzi a nie domyślać się na bazie doświadczeń. I zaznaczam, że wcale nie chodzi tu o zwiększenie prędkości nadawania - bo poprzez zastosowanie choćby kodowania Manchester zmniejszamy ją dosyć mocno. Ale nie to się liczy - w tym przypadku - przynajmniej dla mnie. Liczy się natomiast to, że nadal przy zadowalającej prędkości mam pewną i sprawną transmisję a dzięki zastosowaniu kodowania Manchester (RC5) choć mocno przerobionego RC5 - to mam niejako sprzętowo na przerwaniach zapewnioną kontrolę i odrzucanie ew złych ramek.

    Ale tak jak pisałeś - podstawa to nadawanie przed wysłaniem paczki 2 bajtów danych z moim przypadku - to nadanie przed nimi tak na prawdę dwóch bajtów , hmmm takiej rozbiegówki, które mają tylko ustabilizować tor nadawania nadajnika i odbiornika. Tak więc dzieki tym dwóm bajtom nagłówka na pewno prędkość jeszcze spada. Ale dlatego szczegółowo opisałem czasy jakie udało mi się uzyskać na poszczególnych kompletach różnych firm, żeby pokazać, że jednak te prędkości nie są takie złe do przesyłania niewielkich informacji w krótkim czasie - jeśli chodzi o typowe piloty zdalnego sterowania. Co więcej - dzięki takiemu jak moje rozwiązaniu transmisji - mogę ją spokojnie zastosować do wysyłania większych paczek informacji bo tak przygotowałem sobie procedury nadawcze i odbiorcze. A że wszystko jeśli chodzi o odbiornik działa na przerwaniach to jest na prawdę efekt miodzio. A co najważniejsze jak mówiłem - takie np AUREL'e w końcu działają w pełni sił .

    Na dodatek jedne i drugie mają na prawdę przy takiej transmisji duży zasięg o czym już wyraźnie na początku tematu pisałem i nie kłamałem ani nic nie wymyślałem.
  • #46
    witold50
    Poziom 10  
    Postanowiłem podzielić się z kolegami swoimi spostrzeżeniami . Podobnie jak kolega "Mirek36" nabyłem kilka typów i zacząłem eksperymenty ? Strasznie się podnieciłem kompletem Telelecotrolli i wszechstronnie go przebadałem ale; na początku był zachwyt . Duże zasięg (rs232) pewny sygnał itd. Jednak kiedy wyłączy się nadajnik pakują się różne śmieci i pomimo bariery w postaci określonych 2 bajtów dostają się bez problemu do procesora. Ponadto w moim przypadku występuje duży deficyt prądu i jest problem z on i off . Ponadto układy te generują stan wysoki przez określony krótki czas i ustawienie prędkości na 4800 Kbit/sec dopiero umożliwiło transmisję bez błędów . Natomiast opisane przez kolegę "Piotra411" Rx i TX 433 Vellmana są naprawdę ciekawe .Nadajnik z zasady jest wyłączony jak dostanie + włącza się i trzyma tyle ile się chce . Możliwa jest zatem transmisja z dowolnie niska prędkością . Do odbioru zastosowałem sugerowany kwarcowy odbiornik AM .Zasięg jest naprawdę spory .Jak nadajnik nie pracuje na ekranie są ostatnie ramki . Tylko jedna uwaga Nie jestem super fachowcem z tej branży , ale musiałem zastosować odwrócenie fazy tzn tranzystor w TX i RX . W takim przypadku przy bezczynności nadajnik jest wyłączony a RX podaje stan wysoki . Dziwi mnie że kol. "Piotr411" o tym nie wspomniał . Niebawem wezmę się za anteny np. kierunkowe i podzielę się swoimi wynikami .
  • #47
    kazkowicz
    Poziom 14  
    Witam,

    Nie wiem czy dobrze cię zrozumiałem, zatem wybacz jeżeli próbuję tłumaczyć rzeczy dla ciebie oczywiste, wtedy być może skorzysta ktoś inny.

    Co do wyboru modulacji, to zapewne użycie FSK (FM) zapewni mniejsze zakłócenia niż ASK (AM), czyli zmniejszy się prawdopodobieństwo błędnego odbioru. Ja miałem akurat pod ręką odbiornik AM i taki został użyty do testów. W sprawdzanym przeze mnie odbiorniku RX-4MM5 (z modulacją AM) ARW jest tak szybka, że przy 2400 bodów napięcie ARW praktycznie odwzorowuje poszczególne odbierane bity, zatem stosowanie nagłówka transmisji nie uodporni tego odbiornika na zakłócenia. Gdy nasz nadajnik w danej chwili akurat nie nadaje (ASK - kluczowanie nośnej, jest ona włączana i wyłączana w takt bitów), odbiornik błyskawicznie wraca do maksymalnej czułości, wystawiając system na wszelkie zakłócenia. Być może dla 4800 bodów byłoby nieco lepiej, jednak znacznie lepiej powinno być dla modułów z modulacją FSK. Gdy nadajnik FSK transmituje dane, nośna jest obecna cały czas. W trakcie naszej transmisji odbiornik pracuje z czułością mniejszą niż maksymalna, czyli jest w tym czasie bardziej odporny na obce sygnały.

    Uwaga - niektóre nadajniki FSK zaczynają nadawanie dopiero po kilku milisekundach od pierwszej zmiany L -> H na wejściu danych, czyli mogą przekłamywać pierwszy nadawany bajt!

    Co do nagłówka: jest to rodzaj hasła dla mikroprocesora. Ma poinformować go o rozpoczęciu przeznaczonej dla niego transmisji. Jak każde hasło, musi być trudne do podrobienia w danych warunkach, czyli najlepiej używać kombinacji bajtów rzadko odbieranych przez odbiornik w wyniku zakłóceń czy też transmisji innych systemów. Oczywiście im dłuższe hasło tym lepiej, ale trzeba zachować rozsądek - 10 bajtów nagłówka(hasła) do zabezpieczenia transmisji jednego bajtu danych może być przesadą, chyba że z jakiegoś powodu zależy nam na maksymalnym zabezpieczeniu transmisji (np. włączanie/wyłączanie systemu alarmowego). Mikroprocesor musi najpierw oczekiwać na nadejście ważnego hasła, aby po nim zacząć odbierać/interpretować dane. Trzeba też ustalić sposób zakończenia transmisji. Ponownie może to być jakiś ciąg bajtów, który nigdy nie pojawia się w przesyłanych danych, lub po prostu wybieramy stałą długość ramki - np. dwa bajty nagłówka i cztery bajty danych.

    Ustalmy hipotetyczne hasło na 0X55 0XAA (równie dobrze możemy użyć innych, rzadko odbieranych z "eteru" bajtów - u mnie 0XFF nie jest dobrym pomysłem). Zatem procesor w spoczynku czeka na bajt 0X55, a dopóki go nie odbierze, to ignoruje nadchodzące dane. Odebranie bajtu 0X55 powoduje, że procesor oczekuje na drugi bajt hasła, 0XAA. Poprawne odebranie drugiego bajtu hasła inicjuje odbiór kolejnych czterech bajtów, które uznajemy za nasze dane. Jeżeli jednak po bajcie 0X55 pojawi się coś innego, niż 0XAA, to należy zignorować odebrane dwa bajty i powrócić do oczekiwania na 0X55.

    Kolejny problem to zabezpieczenie od przekłamanych pojedynczych bitów danych. Jeżeli nasz hipotetyczny system to rodzaj zdalnego sterowania z ograniczoną ilością poleceń, to procesor odbierający dane przed wykonaniem polecenia może sprawdzać czy odebrane polecenie znajduje się na liście legalnych komend. Gorzej, gdy mamy przesyłać dowolne dane. Tu z pomocą przychodzą sprzętowe zabezpieczenia USART - ja używam ATMEGA i są tam dwa. Po pierwsze, bit FE - Frame Error, pojawi się gdy bit stopu danego bajtu nie był prawidłowy - dyskwalifikuje odebrany bajt - trzeba zignorować całą ramkę. Sprawdzanie bitu FE, jeżeli chcemy go używać, musi robić nasz program.

    Po drugie, bit parzystości, oblicza go nadajnik i informuje czy liczba jedynek w wysyłanym bajcie danych jest parzysta czy nie. Oczywiście należy odpowiednio skonfigurować USART aby bit parzystości był wysyłany i odbierany, nadal jednak nasz program musi sprawdzać czy nie ma błędu parzystości PE, Parity Error. Bit parzystości może sygnalizować parzystość parzystą lub nieparzystą, zależnie od naszych potrzeb. Warto chwilę pomyśleć jaka nam zapewni lepszą wykrywalność błędów. Ja do pierwszych prób wybrałem (zapewne podświadomie, bo dla mnie parzyste lepiej się kojarzy) parzystość parzystą, czyli bit parzystości ma wartość 1 gdy ilość jedynek w bajcie jest parzysta. Weźmy jednak częste u mnie zakłócenie w postaci pojedynczego impulsu na wyjściu odbiornika (AM). Taki impuls, jeżeli ma odpowiedni czas trwania, zainicjuje odbiór bajtu. Jeżeli po tym impulsie będzie cisza, to USART odbierze osiem jedynek, czyli parzyście, bit parzystości równy 1 i bit stopu (też 1). Wybierając parzystość parzystą ma wtedy bit parzystości = 1 (czyli na wyjściu odbiornika 0). Zatem taki wybór spowoduje oszukanie USART, bo bit parzystości będzie teoretycznie prawidłowy! Wystarczy jednak wybrać parzystość nieparzystą, aby wyłapać taki przypadek jako błąd parzystości i odrzucić bajt jako fałszywy. Na poniższym rysunku pokazuję jak powinno to wyglądać na liniach TXD/RXD. Nie sugeruję jednak, że jest to jedyny słuszny wybór, w innych przypadkach może on zawieść - zależy np. jakie są typowe zakłócenia w danej okolicy i jaka jest szybkość transmisji. Każdy powinien przeprowadzić odpowiednie rozważania dla swojego układu. Tak czy owak, kontrola parzystości pozwala ZMNIEJSZYĆ prawdopodobieństwo błędu, choć do końca nie zabezpiecza przed przekłamaniami.

    Nad/Odb 433MHz - kod Manchester - porównania/ranking

    Kolejnym mechanizmem poprawiającym skuteczność transmisji może być np. wielokrotne nadawanie pojedynczej paczki danych, co zwiększa szanse na czysty odbiór przynajmniej jednej z nich. Wszystko zależy od konkretnego zastosowania.

    Odwrócenie fazy dla większości prostych nadajników ASK i FSK jest konieczne, ponieważ stanem spoczynkowym na linii TXD jest H, czyli bez inwersji nadajnik taki byłby włączony cały czas, a wyłączany tylko podczas trwania bitów o stanie L - czyli bit startu i niektóre bity danych. Aby w takiej sytuacji drugi mikroprocesor poprawnie odebrał transmisję, na wyjściu odbiornika trzeba sygnał odwrócić ponownie - linia RXD oczekuje stanu spoczynkowego H, zaś zazwyczaj odbiornik bez sygnału ma na wyjściu stan L. Uwaga - druga inwersja nie będzie potrzebna przy bezpośrednim dołączeniu wyjścia odbiornika do portu szeregowego komputera - ten używa logiki ujemnej.
  • #48
    skwarag
    Poziom 11  
    Witam.
    Trochę odgrzeję temat.
    Zrobiłem transmisję na układach telecotrolli RT4 i RR10. I mam problem z zasięgiem. Dobrze chodzi jeśli wszystko leży obok siebie jednak już 0,5m odległości i przestaje działać. Koduję dane kodem Manchester jednak nie zmienia to zasięgu. Czy problem może tkwić w w typach układów?
    Jak można zwiększyć zasięg bez konieczności wymiany modułów?
    Anteną czy może jakiś wzmacniacz?
    Pozdrawiam.
  • #49
    shadoweyes
    Poziom 20  
    Zasięg można zwiększyć dodając antenę z ok. 15cm drutu. Ale może być możliwość, że częstotliwości odbiornika i nadajnika się nieznacznie różnią co powoduje przy oddalaniu się odbiornika od nadajnika zanik sygnału. Wzmacniacza nie polecam.