Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

ATmega16 - Odbiór RC5 - za każdym razem inne dane

maly_elektronik 06 Sep 2013 09:33 1776 11
Fluke Kamera Termowizyjna
  • #1
    maly_elektronik
    Level 23  
    Witam,
    od jakiegoś czasu próbuję rozwiązać problem odbierania kodu RC5 przez avr'ka.
    Ponieważ nie jestem do końca pewny zbudowałem (a raczej zaprogramowałem) prosty nadajnik tego kodu.
    Tak wygląda kod odbiornika:
    Code: c
    Log in, to see the code


    a tak kod nadajnika (wiem że delay'e nie są zbyt dobrym rozwiązaniem jednak w tej sytuacji są wystarczające)
    Code: c
    Log in, to see the code


    Czy ktoś jest w stanie powiedzieć mi co jest nie tak?[/code]
  • Fluke Kamera Termowizyjna
  • Helpful post
    #2
    BlueDraco
    MCUs specialist
    Popatrz uważnie na kod nadajnika - nadajesz 14 impulsów z okresem ok. 3.6 ms. Czy o to chodziło?

    Zwykle sterowanie w podczerwieni działa na 38 kHz (lub coś podobnego) - u Ciebie jest ok. 270 Hz
  • #3
    maly_elektronik
    Level 23  
    Rzeczywiście w samym nadajniku zapomniałem o nośnej jednak przyczyną tego jest to iż zamiast diody i odbiornika podczerwieni do testów spiąłem ze sobą pin nadajnika i odbiornika (oczywiście uwspólniając zasilanie) :idea: Jednak zapomniałem o tym że w pętli mam 2 "bity" kodu więc wysyłam za dużo danych :)

    A czy sam kod odbiornika jest poprawny?
  • Fluke Kamera Termowizyjna
  • Helpful post
    #4
    piotrva
    VIP Meritorious for electroda.pl
    Pokaż jeszcze schemat odbiornika.
    Na pierwszy rzut oka w ogóle masz to jakoś dziwnie zrobione - poprzez polling pinu odbiorczego?
    Poszukaj w sieci - są bardzo dobre przykłady w oparciu o tryb Capture Timera1.
  • #5
    maly_elektronik
    Level 23  
    W sieci też spotkałem rozwiązania tego typu, że sprawdzany był stan pinu w przerwaniu od timera po wykryciu zbocza bitów startowych :)
    Możesz napisać jaśniej o co chodziło Ci z tym trybem CTC, wtedy będzie mi prościej to zaimplementować :)
  • #7
    maly_elektronik
    Level 23  
    Rozważałem taką opcję, jednak ICP posiada jedynie timer 16bitowy a niestety ten będzie pełnił rolę generatora PWM w finalnym układzie :(
  • #8
    piotrva
    VIP Meritorious for electroda.pl
    W takim razie rozwiąż to inaczej - skonfiguruj przerwanie zewnętrzne tak, aby było wyzwalane zmianą stanu i osiągnij ten efekt w ten sposób - polling pinu to w tym przypadku moim zdaniem nie jest najlepsze rozwiązanie.
  • #9
    maly_elektronik
    Level 23  
    Teraz zrobiłem według Twoich zaleceń:
    Przerwanie wywołuje zmiana stanu pinu INT0 na przeciwny, rusza timer który w równych odstępach czasu przepisuje wartość pcode (odpowiada stanowi pinu INT0) do CODE, który jest kodem "klawisza" przed zdekodowaniem modulacji MENCHESTER.
    Code: c
    Log in, to see the code


    Jednak w dalszym ciągu odebrane dane są niepoprawne (za każdym razem inne - nie używam jednak pilota z RC5 a jedynie układ który generuje prosty sygnał)
    Tak wygląda mój pilot:
    [Timer generuje przerwanie z częstotliwością ok 72kHz zmieniając stan pinu OC2 (przez co uzyskuje nośną 36kHz i odpowiedni wewnątrz przerwania wyliczam sobie co ile przerwań należy modulować nośną)]
    Code: c
    Log in, to see the code
  • #10
    BlueDraco
    MCUs specialist
    Przerwania z częstotliwością 72 kHz na AVR to zbytni optymizm. Zaprogramuj timer w tryb PWM na 38 kHz, w obsłudze przerwania odliczaj impulsy i włączaj/wyłączaj sterowanie diodą na kolejny okres - jeśli oprogramujes to przyzwoicie - masz szansę się wyrobić. Ustaw zegar procesora na min. 8 MHz (nie napisałeś, jaki masz ustawiony).
  • #11
    maly_elektronik
    Level 23  
    Pracuje na zewnwtrznym kwarcu 16MHz. Czyli jednak kod pilota jest niezbyt poprawny?

    Odświeżając temat:
    Tak wyglądają przebiegi (stany logiczne) diody nadawczej oraz odbiornika TSOP4836.
    [Pierwszy to sygnał z diody IRED natomiast drugi na odbiorniku]
    ATmega16 - Odbiór RC5 - za każdym razem inne dane
    Jak sprawdziłem w programie mój "pilot" nadaje poprawny kod wraz z poprawną nośną (ok 36kHz), jednak jak widać na załączonym zrzucie sygnał zaobserwowany na pinie odbiornika jest poprawny gdyny nie "szpilki" trwające ok. 27us.
    Co może być ich powodem? (układ podłączony wg zaleceń czyli rezystor do Vcc oraz kondensator na pinach zasilających TSOP)
  • #12
    maly_elektronik
    Level 23  
    Temat do zamknięcia.
    Po podpięciu innego odbiornika TSOP okazalo się ze te szpilki powstawały wyłącznie z winy wadliwego poprzednika.
    Dziękuje wszystkim za pomoc :)