Elektroda.pl
Elektroda.pl
X
Elektroda.pl
Advanced Search
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Pilot IR uniwersalny "inaczej" Olympus,Sony,RC5...

mirekk36 11 Nov 2008 16:02 45021 50
Altium Designer Computer Controls
Reply Cool? Ranking DIY | New topic
Notify about new articles
  • Pilot IR uniwersalny "inaczej" Olympus,Sony,RC5...
    Witam,

    Chciałbym przedstawić dzisiaj wprawdzie prosty ale ciekawy projekt, jest to jeden z pierwszych "klocków" pewnego większego projektu, który za jakiś czas jeszcze - mam nadzieję także tu zaprezentować.

    Poniższy pilot oparty jest na procesorku ATtiny2313 jak widać na fotkach. Obsługuje on w tej obudowie maksymalnie do 5 klawiszy, jednak można bardzo łatwo korzystając ze schematu i niedużej przeróbki oprogramowania przystosować go do własnych potrzeb i obsługi znacznie większej ilości klawiszy. Jest to mój pierwszy pilot wykonany tak od początku do końca i spełniający moje wymagania odnośnie małego poboru prądu podczas gdy nie pracuje - bo w trybie PowerDown pobiera tylko 6uA
    Pilot IR uniwersalny "inaczej" Olympus,Sony,RC5...
    przy zachowaniu z kolei odpowiednio wysokiego prądu do sterowania diody IR podczas nadawania tak aby uzyskać jak największy możliwy zasięg a na dodatek tak aby mógł bardzo długo pracować bez konieczności wymiany baterii. Jak widać zastosowałem wprawdzie mało typową baterię - jednak spokojnie można ją dostać (kupiłem gdzieś w necie) - ma sporą pojemność więc przy tej konstrukcji zapewne długo posłuży.
    Pilot IR uniwersalny "inaczej" Olympus,Sony,RC5...
    jak widać użyłem standardowej obudowy, którą też łatwo kupić gdziekolwiek w necie. W trakcie pracy pilota - ładnie "mruga" sobie niebieska dioda LED SMD

    Pilot IR uniwersalny "inaczej" Olympus,Sony,RC5...
    Jak widać powyżej na schemacie (prostym zresztą jak budowa cepa) zastosowałem metodę takiej obsługi klawiszy, że po wciśnięciu dowolnego podowuje on przerwanie do procka, które powoduje wybudzenie go ze stanu śpiączki klinicznej ;) ... następnie w procedurze obsługi przerwania zmieniane są kierunki pracy portów wszystkich klawiszy na wejściowe a pinu przerwania na wyjściowy - tak aby można było "odgadnąć", który klawisz jest wciśnięty, wyemitować wiązkę promieniowania podczerwonego ;) oraz ponownie zmienić kierunki portów i wprowadzić ponownie procesor w stan śpiączki.

    Pilot IR uniwersalny "inaczej" Olympus,Sony,RC5...
    Pilot IR uniwersalny "inaczej" Olympus,Sony,RC5...
    Pilot IR uniwersalny "inaczej" Olympus,Sony,RC5...

    Tytuł tematu brzmi - Uniwersalny "inaczej" ponieważ nie zrobiłem tak do końca może uniwersalnego pilota, który emituje kody w różnych standardach naraz - bo by kociokwik powstał ale ....

    .... ale jak widać na ostatnim zdjęciu powyżej - ładnie przygotowane jest złącze ISP do szybkiego, prostego i łatwego przeprogramowywania pilota - innymi słowy mówiąc szybko można wrzucić nowy wsad dzięki któremu pilocik może nadawać w dowolnym standardzie i to kody klawiszy jakich sobie życzymy. (wystarczy przytknąć 6cio pinowe złącze szpilkowe - bez żadnego lutowania)

    Całe oprogramowanie napisałem w nowym jak dla mnie języku C - dopiero się go uczę i poznaję a przy okazji korzystam z zawzięciem z jego dobrodziejstw. Pozwaliło mi to na napisanie na tyle uniwersalnie mojego programu do procka tak aby za pomocą jednego "przełącznika" programowego" przekompilować kod dla obsługi różnych pilotów. Na chwilę obecną mam dokładnie rozpracowane i działające sterowanie w standardach:

    RC5 (oczywiście to podstawa - włącznie ze ślicznie działającym bitem Toggle) , SONY (Sirc) , Samsung , teraz kończę JVC i RC6 ;)

    ale także to co było dla mnie najważniejsze - możliwość sterowania pilotem mojego ukochanego aparaciku OLYMPUS ..... działa prześlicznie ;)

    dzięki takiej konstrukcji już bez problemu mogę zaimplementować dzięki stronce www.lirc.org prawie dowolny standard - szybko łatwo i przyjemnie. Pracuję jeszcze nad możliwością większego sparametryzowania najważniejszych rzeczy tak aby można było:

    1. zmieścić w pilocie kodowanie w różnych standardach i przełączać je klawiszem
    2. zaoszczędzić miejsca na te różne kodowania
    3. docelowo tak - aby móc wpisać tylko sobie proste podstawowe dane z lirc.org jak, typ kodowania Biphase, space, pulse, długość header'a, ilości przesyłanych bitów itp i dzięki temu w przysłowiowe 5 sekund można będzie zrobić sobie dowolnego pilocika - do swojego urządzenia, aparatu fotograficznego itp itp

    koszty całości to płyteczka, procesor plus kilka elementów jak rezystory, kondesatory czy tranzystor - wszystko w SMD plus oczywiście kilka microswitchy. Do tego obudowa no i bateria.

    Od razu uprzedzę komentarze, że nie jest to może konstrukcja tańsza niż te które można uzyskać np na allegro - są tam przecież uniwersalne piloty do sterowania różnymi aparatami fotograficznymi za cenę od 20-40zł) - tu jednak - tak myślę przewagą jest to dla elektronika, że mogę sobie w dowolnej chwili zmienić parametry, zastosować do czegoś innego i mam wszystko pod kontrolą.

    Na pewno nieocenioną rzeczą przy budowie czegoś takiego jest możliwość nauczenia się wielu rzeczy nie tylko w osbłudze mikrokontrolerów ale i pisania oprogramowania wraz jego optymalizacją. Wprawdzie program zmieściłby mi się prawie w procesorku mniejszym jak ATtiny13 - bo zajmuje ok 1KB ale już wybrałem ten bo ma więcej wejść i łatwo mi go przystosowywać do tworzenia teraz już w dużej liczbie mnogiej pilotów do moich przeróżnych urządzeń.

    Programu nie będę publikował, pokażę tylko poniżej jak wygląda sposób przełączania kompilacji dla danego standardu - zaznaczone na żółto - poprostu zmienna IR_MODE = (zdefiniowana stała, która odpowiada za kompilację warunkową dla różnych wersji kodowania)

    poza nią - możemy jak widać dowolnie zdefiniować adres i komendę(klawisze) o ile są one rozróżnione w standardzie. Dzięki temu można sobie zrobić pilocika np RC5 generującego jakiś adres inny niż TV, VCR itp tak aby sterował jakieś nasze domowe urządzenie ale jednocześnie nie przełączał przypadkowo naszego telewizora który stoi obok a przypadkowo jest firmy Philips ;)

    Pilot IR uniwersalny "inaczej" Olympus,Sony,RC5...

    Cool? Ranking DIY
    About Author
    mirekk36
    Level 42  
    Offline 
    Ciekawy kurs VIDEO - EAGLE - zajrzyj na mój blog
    mirekk36.blogspot.com - VOLATILE ? to łatwe

    Has specialization in: programowanie: avr c, delphi pc, esp32, esp8266, Kursy ESP
    mirekk36 wrote 9195 posts with rating 2271, helped 964 times. Live in city Szczecin. Been with us since 2006 year.
  • Altium Designer Computer Controls
  • #2
    Stefan_2000
    Level 19  
    Quote:
    Jak widać zastosowałem wprawdzie mało typową baterię

    Bateryjka ma na obudowie napisane 6V, czyli ,,świeża'' ma pewnie więcej. ATtiny2313 ma ,,Maximum Operating Voltage'' równy 6V. Nie dzieje mu się krzywda?

    Jakiś czas temu poruszałem kwestię zasilania uProcka z akumulatora ,,żelowego'' 6V i rozwiązaniem było użycie stabilizatora ,,very low drop voltage''.

    Ogólnie projekt bardzo fajny ze względu na swoją uniwersalność.

    pozdrawiam
  • #3
    cukras
    Level 17  
    Witam, urządzono ładnie się prezentuje, ładnie zrobione. Gdzie robiłeś płytkę, lub jak ją zrobiłeś? Chętnie bym podejrzał program, bo też bawiłem się w robienie czegoś w rodzaju pilotów tyle, że tylko pracujących w RC5. Wstaw kod to może komuś sie przyda.
    pzdr
  • #4
    mirekk36
    Level 42  
    Stefan_2000 -> jak widać na schemacie - jest zastosowana zwykła dioda prostownicza D1, która obniżna napięcie z baterii o ok 0,6V - tak więc procek czuje się z tym jak w sam raz. A świeża nawet tego typu bateria ma o wiele więcej niższe napięcie niż świeżo naładowany akumulator żelowy. Jutro sprawdzę dokładnie ile mają świeżynki bo mam jeszcze kilka to napiszę bo teraz już nawet nie pamiętam ile miała jak mierzyłem po wyjeciu z opakowania.

    cukras -> płytkę zaprojektowałem w eagle a wykonałem ją w merkarze, kodu z pewnych względów nie mogę udostępnić ale jeśli ktoś będzie miał jakieś pytania to chętnie pomogę. Generalnie mogę powiedzieć, że program wykorzytuje wyjście OC0A związane z Timer0 procesora do generowania nośnej w zakresie od 35KHz do 40KHz w zależności od potrzeb standardu, natomiast Timer1 przy ustawionym preskalerze na 8 (dzięki czemu jedno jego "tiknięcie" odmierza 1us) służy do precyzyjnego dobierania potrzebnych opóźnień

    Dodano po 17 [minuty]:

    wader_669 -> u mnie akurat Timery nie działają w trakcie uśpienia, poprostu przed wejsciem w uśpienie wystawiam na piny klawiszy stan niski, wejście INT0 jest podciągnięte do VCC wewnętrznie i po zwarciu przez klawisz generowane jest przerwanie, które budzi procka, potem jak pisałem odwracam kierunki portów i po kolei badam który klawisz jest wciśnięty - ot cała filozofia - prosta ale skuteczna
    .... ooops kolega wader_669 zniknął ;)
  • #5
    lucas_mcs
    Level 22  
    Witam,
    Mam pytanie odnośnie "Olympusa"
    Chciałbym zrobić komunikację w drugą stronę - mam pilota od aparatu Olympus i chciałbym sterować nim lampkę RGB która kiedyś zrobiłem (projekt z elki).
    Czy możesz dać kod albo jakąś podpowiedź, czy też strony z których korzystałeś? (w jaki sposób zaimplementowałeś pilota Olympus w kodzie?)
    Masz jakąś prostą obsługę przypisywania kodów klawiszy np tak żeby tylko wkleić kod klawisza ze strony lirc.org i wybranie standardu kodowania i już?
    PS. Ewentualnie mam też drugi fajny mały pilocik AIWA RC-201, na stronie lirc jest akurat RC-202, ale myślę, że by pasowało
    Pozdrawiam
  • #6
    mirekk36
    Level 42  
    lucas_mcs -> odnośnie Olympusa to dokładnie tak zaprogramowałem czasy i bajty przesyłanych danych jak są podane na lirc'u - dla pilota RM-1. Jest to kodowanie typu space - tzn wartość bitu zależy od długości przerwy (stanu niskiego) bo stan wysoki w jednym bicie ma zawsze tę samą długość. Jak więc widać na lirc'u - trzeba tylko wygenerować Header skaładający się z impulsów o długości 8853us oraz 4489us , następnie trzeba przesłać tzw pre-data bits, czyli stałe paczki bitów (16) są podane na stronce tzn ich wartosci a po nich od razu trzeba wysłać także 16bitów kodu odpowiedniego klawisza - także podane na stronce dla konkretnych klawiszy pilota, na koniec mała przerwa. Jeśli chodzi o Olympusa to nie wymaga on dokładnego odmierzania z kolei odstępu pomiędzy paczkami danych aby aparat odebrał polecenie. To co jest najważniejsze tak jak w każdym innym standardzie IR to zachowanie bardzo precyzyjnych czasów poszczególnych impulsów i musi się udać. Dzięki temu - można spokojnie zrobić odbiornik i jak piszesz wykorzystać pilocik do lampki RGB - fajny pomysł bo nie trzeba budować jakiegoś specjalnego pilota ;)

    ... aha a nad taką obsługą sparametryzowaną, żeby tylko podać czasy z lirc'a właśnie pracuję ale to jeszcze potrwa i nie będzie aż tak uniwersalne bo jednak standardy bywają bardzo różnorakie ;) poza tymi 3 podstawowymi typami. Chodzi o to, że jakiś pilot może nadawać powiedzmy w standardzie SPACE czy PULSE , mieć jakieś własne długości czasów dla impulsów nieco różniące go od innych podobnych ale wymaga np jeszcze iluś tam krotnego przesłania tego samego kodu, albo jego zanegowanej wartości itp itp . Poza tym na lirc'u niektóre piloty nie są opisane poprzez podanie czasów impulsów tylko w tze trybie raw a to już b.ciężko sparametryzować w sposób uniwersalny. Jednak przecież zwykle naszym celem nie jest robienie tzw MASTER PILOTA - ojca ojców a zarazem dziadka wszystkich pilotów ;)
  • #8
    mirekk36
    Level 42  
    skynet_2 -> czy jest opis? - proszę, już jest:

    na lircu w opisie pilota, którego będziesz posiadał ;) można zobaczyć:

    Code: text Expand Select all Copy to clipboard
      name  Minolta_RC3
  bits            8              -----> ilość bitów w kodzie klawisza
  flags SPACE_ENC        -----> standard kodowania
  eps            25            --->
  aeps          100           ---> współczynnik wypełnienia nośnej 25/100 

  header       3872  1708
  one           527   436
  zero          527  1331
  ptrail        527
  pre_data_bits   24
  pre_data       0xD3AC7D
  gap          9052
  toggle_bit      0


      begin codes
          one_sec                  0x000000000000007F
          two_sec                  0x00000000000000FF
      end codes


    jak więc widać używane jest kodowanie typu SPACE ;)

    i teraz zaczynając od linijki

    header 3872 1708 - oznacza to, że na początku trzeba wyemitować header (nagłówek charakterystyczny dla danego pilota) w tym przypadku trzeba nadawać nośną powiedzmy 36KHz przez okres 3872 us a następnie zrobić przerwę przez 1708 us

    gdy już to wyemitujesz ;) to trza się zabrać za przesłanie kodów klawiszy pilota. Ale uwaga - widzisz tam powyżej coś takiego jak pre_data_bits 24 co oznacza, że bezpośrednio po headerze trzeba najpierw wyemitować przed kodem każdego klawisza stałą 24 bitową paczuszkę danych a dopiero po tym należy wyemitować 1dno bajtowy kod klawisza. W twoim przypadku te 24 bity mają wartość: pre_data 0xD3AC7D natomiast kody klawiszy (wygląda na to że pilot ma 2 klawisze)

    Code: text Expand Select all Copy to clipboard
          begin codes
          one_sec                  0x000000000000007F
          two_sec                  0x00000000000000FF
      end codes


    pierwszy ma wartość 0x7F a drugi 0xFF

    ok a teraz jak sobie poradzić z kodowaniem jednego bitu, otóż masz na to właśnie dokładny przepis. Trzeba tylko wiedzieć ile czasu zajmują dwa różne stany w trakcie emitowania jednego bitu. Jako, że jest to kodowanie typu SPACE to jak widać stan wysoki jest stały i wynosi zawsze w twoim przypadku 527us a zmienia się tylko czas stanu niskiego w zależności od bitu - czy JEDEN czy ZERO

    Code: text Expand Select all Copy to clipboard
      one           527   436
  zero          527  1331


    i tu znowu masz jak na dłoni podane. Jeśli masz zamiar wyemitować bit o wartości = JEDEN to musisz emitować nośną przez czas 527us i zrobić przerwę o czasie trwania 436us

    jeśli chcesz wyemitować bit o wartości ZERO to emitujesz nośną znowu przez czas 527us ale przerwa po nim już będzie wynosić 1331us

    Teraz tylko poskładać to do kupy - czyli już chyba wiesz? skoro pre data bits = 24 to masz jakby 3 bajty - 0xD3 , 0xAC , 0x7D - więc już widzisz jakie bity po kolei musisz emitować prawda? gdy je nadasz po headerze to wtedy zabierzesz się za wysłanie bitów znajdujących się w bajtach kodów klawiszy

    i UWAGA - na końcu gdy wystąpi przerwa po ostatnim nadanym bicie - musisz jeszcze wyemitować krótki sygnał (tzn nośną o długości 527us)
    Code: text Expand Select all Copy to clipboard
    ptrail        527


    w twoim przypadku akurat ptrail = czasowi stanu wysokiego w każdym bicie.

    i to koniec - tak złożona ramka dotrze do aparatu i zrobi co trzeba ;)
    pozdrawiam

    aha na początku wspomniałem , że nośną można do testów ustawić na 36kHz bo nie jest tu ona podana tylko jakie powinno być wypełnienie (a nośne też raczej nigdy nie bywają wyższe niż 45kHz, więc przedział do sprawdzenia jest niewielki). Wypełnieniem jednak nie trzeba sobie koniecznie głowy zawracać. Natomiast jeśli nie wiadomo jaka nośna a jest inna niż 36kHz to efekt może być tylko taki że zamiast zasięgu kilku-kilkunastu metrów będziesz miał nie więcej niż tych kilka metrów (co czasem i tak w zupełności wystarcza). Ale jest na to rada - ja też nie wiedziałem na jakiej nośnej nadaje Olympus więc dobierałem ją doświadczalnie - zwiększałem o 1kHz powyżej 36kHz i sprawdzałem maksymalny interesujący mnie zasięg. Okazało się, że przy 38kHz jest dla mnie on najbardziej zadowalający - choć nie ma tak naprawdę aż tak wielkich różnic ;)

    więc powodzenia - jak widzisz nie jest to takie trudne
  • Altium Designer Computer Controls
  • #9
    skynet_2
    Level 26  
    mirekk36 wrote:
    skynet_2 -> na lircu w opisie twojego pilota można zobaczyć:

    pilota którego nie posiadam :D

    Wszystko rozumiem, teraz spróbuje to uruchomić.

    Dzięki piękne
  • #10
    User removed account
    User removed account  
  • #11
    mirekk36
    Level 42  
    Rocket_93 -> typ obudowy to np w tme: ABS-11B/4 . Tak, jest od razu z otworkami na przyciski i z tą naklejką maskującą (tylko, że są 4 otworki więc piąty musiałem sam nawiercić ale to nie był żaden problem). Płytkę jak już wspominałem projektowałem sam w Eagle. Natomiast wykonanie zlecam najczęściej w merkar.pl tylko, że tam nie jest ostatnio najtaniej dla prototypów a do tego straszne opóźnienia terminów wykonania mają :(

    Z tym IR_MODE jest dokładnie tak jak napisałeś. Oczywiście, że można upchać ze 2 a nawet 3 standardy w jednym z tym, że zrobię to jeśli nie uda mi się zaimplemetować parametryzacji dla większej liczby pilotów i ich danych z lirc'a . A dokładnie myślałem o tym samym aby za pomocą kropeki cyny zwierać odpowiednie - wolne jeszcze piny SMD procka, które mogą posłużyć w trybie wejść jako jumperki ;)
  • #12
    sunok
    Level 14  
    W kwestii oszczędności i pewności działania zmienił bym połączenia diody IR oraz LED na połączenie szeregowe obu diod. Zaleta tego by była taka że potrzebujesz wtedy jednego rezystora (albo wcale - zależy jakie diody) i jeżeli świeci LED to wiadomo że przez diodę IR też prąd płynie... więc swego rodzaju kontrola diody IR. Jeden rezystor i mniej tracisz energii na rezystorach podczas świecenia ;)
  • #13
    mirekk36
    Level 42  
    sunok -> szeregowo to wypada jak już, łączyć dokładnie takie same diody LED albo IR. Ta jedna dioda LED jest niebieska i ma spory spadek napięcia, dioda IR ma mniejszy ale razem da to tyle, że napięcie potrzebne do wysterowania szczególnie gdy po jakimś czasie bateria osłabnie - nie wystarczy i o wiele szybciej pilot przestanie działać - więc to pierwszy MINUS proponowanego przez ciebie rozwiązania wg mnie oczywiście. Drugi bardziej poważny MINUS to taki, że dioda IR ze względu na potrzebę uzyskania dużego zasięgu musi być potraktowana o wiele większym prądem niż ta zwykła informacyjna dioda LED. Zwróć uwagę na wartości rezystorów. Dioda LED ma 100R natomiast dioda IR ma tylko 47R pomimo to, że ma o wiele mniejszy spadek napięcia niż niebieska dioda. Jak widzisz wartości te nie zostały dobrane przypadkowo. I zobaczyć można od razu na ich podstawie to , że dioda IR pracuje przy dużym prądzie w porównaniu do diody LED. Łącząc więc te diody szeregowo - nawet jeśli by starczyło napięcie zasilania to przy zbyt małym rezystorze spaliłaby się dioda LED szybko a przy zbyt dużym, takim żeby dioda LED się nie spaliła tylko ładnie świeciła - to z kolei dioda IR traktowana by była tak małym prądem, że zasięg zmalałby do może 1go metra ! ....

    w takim układzie jak jest obecnie i tak jest pełna kontrola działania sygnału nadawania. A nie widzę sensu jeszcze robienia dodatkowej kontroli działania diody IR bo:

    1. Jeśli nie będzie działać - to nie zadziała sterowane urządzenie
    2. Jeśli chcesz się przekonać czy działa tylko (bo przecież gołym okiem nie widać) to wystarczy, że spojrzysz na nią gdy ma świecić podczerwienią poprzez obiektyw dowolnego aparatu cyfrowego lub kamery - wtedy będzie na ekranie świeciła jak zwykła dioda LED
  • #14
    Dr.Vee
    VIP Meritorious for electroda.pl  
    Mirekk36: nie znałem bazy pilotów z lirc.org, dzięki za linka! Z tego co widać nie powinno być problemem podejście do problemu:

    1) zdefiniowanie (spakowanej) struktury danych opisującej kodowanie dla danego pilota
    2) opracowanie skryptu kompilującego dane lirc do struktury
    3) wpisanie struktury do pamieci programu
    4) przełączanie typu pilota "w locie"

    Oczywiście kod nie będzie najszybszy, ale za to wtedy dodawanie pilotów będzie "pestką".

    Pozdrawiam,
    Dr.Vee
  • #15
    mirekk36
    Level 42  
    Dr.Vee -> no właśnie o czymś takim myślę - tylko, że wiadomo mi to jeszcze wolno idzie bo się uczę C ;) ..... natomiast jak już wcześniej wspominałem nie będzie też tak prosto zrobić to dla kompletnie wszystkich pilotów bo jednak różnice w formatach tych struktur mogą być duże (co pilot to inne warunki nadawania - nie licząc tylko tych podstawowych informacji typu dane bitu ZERO czy JEDEN, ale różne rodzaje potwierdzeń, negacje na końcu) a co najgorsze - być może nie zobaczyłeś jeszcze, że dla niektórych pilotów podane są dane całkiem inaczej w trybie RAW .

    Ale i tak można zrobić np przy założeniu, że będą to piloty z kodowaniem SPACE i konwerować tylko wtedy gdy są podane czasy zborowo a nie w postaci RAW .... eeeh zakręcić się przy tym można i na końcu i tak odpowiedzieć sobie na pytanie czy koniecznie trzeba obsługiwać dla swoich potrzeb wszystkie typy pilotów na świecie ;)
  • #16
    grzeniu_pl
    Level 14  
    Dlaczego obciążenie (LEDy) jest po stronie emitera a nie kolektora ?
  • #17
    jonex21
    Level 11  
    Code: text Expand Select all Copy to clipboard
    header                 3872 1708
pre_data (1 of 3) D3   527 436  527 436  527 1331 527 436  527 1331 527 1331 527 436  527 1331   
pre_data (2 of 3) AC   527 436  527 1331 527 436  527 1331 527 436  527 436  527 1331 527 1331   
pre_data (3 of 3) 7D   527 1331 527 436  527 436  527 436  527 436  527 436  527 1331 527 436  
codes (one_sec)   7F   527 1331 527 436  527 436  527 436  527 436  527 436  527 436  527 436 
ptrail                 527

    Czy tak powinien wygladac kod jaki wysyla minolta po wcisnieciu one_sec (7F) bo czytajac opis nie jestem pewny :cry: do czego sluzy gap :?: Czy to jest czas 9052us po ktorym mozna nadac kolejna paczke :idea: THX :)
  • #18
    mirekk36
    Level 42  
    grzeniu_pl -> tak, to jest dobre pytanie ;) ... po prostu na początku projektowałem to z uzyciem tranzystora kluczującego NMOS FET 2N2007 a później zmieniłem jednak na zwykły PNP - ale zapomniałem przeżucić diod w obwód kolektora. ;) .... jednak nie załamałem się po otrzymaniu płytek bo w takiej konfiguracji też dobrze działa chociaż może być taka sytuacja, rozładowanie baterii i spadek napięcia na niej szybciej może wpłynać na pracę pilota. Z kolei pobór w stanie spoczynku tylko 6uA nie powoduje u mnie narazie strachu, że to wyczerpanie tak szybko nastąpi ;)

    jonex21 -> dokładnie tak powinien wyglądać kod - tylko sprawdź dokładnie pierwszą linijkę

    pre_data (1 of 3) D3 527 436 527 436 527 1331 527 436 527 1331 527 1331 527 436 527 1331

    bo wydaje mi się, że powinno być tak dla 0xD3

    pre_data (1 of 3) D3 527 436 527 436 527 1331 527 436 527 1331 527 1331 527 436 527 436

    w związku z powyższym sprawdź i inne linijki - ale dokładnie o to chodzi ;) jak to wyemitujesz to aparacik ożyje i zrobi co trzeba ;)

    odnośnie gap - też masz rację, że jest to czas jaki powinien wystąpić pomiędzy nadawanymi ramkami, ale liczony od początku nadawania ramki a nie od jej końca (przynajmniej ja z tym się spotkałem) Natomiast nie jest to bardzo istotny parametr jeśli odbiornik reaguje na pojedyńczą ramkę. Ważny jest natomiast wtedy gdy np odbiornik musi otrzymać więcej niż jedną ramkę aby zareagować. Dla przykładu mój telewizor SONY musi otrzymać co najmniej 2 ramki jedna po drugiej - żeby zareagował na klawisz i wtedy trzeba zastosować i odliczyć dokładny GAP (bo bez dokładnego GAP'a odbiornik uzna to za pomyłkę i też nic nie zrobi). Czasem inne odbiorniki potrzebują 3 lub więcej powtórzeń (repeat) ... teraz już chyba jaśniej ? prawda?

    czyli jeśli na lirc'u dla twojego aparatu i pilota nie ma linijki repeat która mówi ile razy ma być powtórzona ramka to gap jest niezbyt istotny i może być dowolny
  • #19
    Warhard
    Level 12  
    Kolego przede wszystkim gratulacje za projekt.
    Jednak ciekawi mnie inna kwestia - sprawa wewnętrznego rezonatora RC w tym procku. Z doświadczenia wiem że jest spory rozrzut generowanej częstotliwości rezonatorów wewnętrznych i sama kalibracja programowa nie ustawi nam idealnie częstotliwości... Chyba że nie jest aż tak istotna częstotliwość nośnej.


    Pozdrawiam Warhard
  • #20
    mirekk36
    Level 42  
    Warhard -> oczywiście, że jest spory rozrzut - ale z drugiej strony nie bywa aż tak wielki jak się nieraz wydaje. Wszystko zależy do czego używamy programu. Na 100% w tym konkretnym przypadku - pilotów IR - nie ma on wpływu na jakość pracy pilotów jeśli chodzi o generowanie częstotliwości nośnej - bo jak pisałem wcześniej - praktycznie wszystkie odbiorniki wysterujesz choćby tylko za pomocą 36kHz. Dodam, że nawet nie ustawiam bajtu kalibracyjnego. Również ten rozrzut nie wypływa mocno na niedokładność dobieranych opóźnień a jeśli nawet to trzeba wiedzieć, że twórcy standardów kodowania IR przewidzieli naprawdę spory zakres tolerancji dla tychże czasów.

    Ale już np dla transmisji RS232 szczególnie tych szybszych - przynajmniej dostrajanie batem kalibracyjnym miewa już ogromne znaczenie bo i tolerancja błędów jest mniejsza
  • #21
    Warhard
    Level 12  
    Dziękuje kolego mirekk36 za wyczerpującą odpowiedz.
    Szczerze mówiąc aż swędzą mnie paluszki by zabrać się zapisanie programu do tego pilocika :).

    Ze swojej strony dorzucił bym małe kondensatorki równolegle do każdego przycisku po 10n .

    Pozdrawiam serdecznie Warhard :)
  • #22
    mirekk36
    Level 42  
    Warhard -> a ja szczerze polecam zabawę z IR bo jak się już w to "wdepnie" to całkiem przyjemne ;)

    odnośnie kondensatorów przy switchach to zwykle w innych układach daję po 100nF ale tutaj w zasadzie okazują się być w ogóle nie potrzebne ponieważ - tak programowo jest robiona obróbka klawiszy, że można powiedzieć iż problem drgania styków jest rozwiązany w 120% programowo ;)
  • #23
    wader_669
    Level 28  
    masz jakies problemy jak wcisniesz 2 przyciski naraz?
  • #24
    mirekk36
    Level 42  
    wader_669 -> nie wiem czy mam jakieś problemy bo nigdy nie używam 2 przycisków jednocześnie i w ogóle tego nie brałem pod uwagę w założeniach do programu.

    w obecnej postaci pilot nie będzie reagował w jakiś odmienny sposób na 2 przyciski - bo to nie zostało oprogramowane. Zawsze najpierw wykona się funkcja przycisku który został pierwszy wciśnięty a po jego zwolnieniu zacznie dopiero działać ew drugi jeśli jeszcze jest wciskany.
  • #25
    lucas_mcs
    Level 22  
    Po dość długiej przerwie będe przymierzał się do wykonania tego odbiornika o którym pisałem wyżej..

    Mam jeszcze pytanie do ciebie mirekk36:
    Skąd mam wiedzieć po tych danych z lirc jakiej nośnej mam użyć, bo nie wiem jaki czujnik mam podłączyć TSOP1836, 38, 40 itp a nie mam ochoty zbytnio kupować wszystkich rodzajów i się zastanawiać który działa?

    Jest jakiś patent na obliczenie tej nośnej z danych od lirc?
  • #26
    mirekk36
    Level 42  
    lucas_mcs wrote:

    Jest jakiś patent na obliczenie tej nośnej z danych od lirc?


    nie ma patentu - ale za to jest jeden bardzo prosty , sprawdzony i pewny sposób ;)

    nie zastanawiaj się nad tą częstotliwością - tylko zakup typowy odbiornik na 36KHz - i gwarantuję ci głową, że na 1000% zadziała.

    A gdyby twoje urządzenia działały jednak na np nawet 43KHz to efekt uboczny będziesz miał co najwyżej taki, że zamiast odległości nie wiem np 7m - to będzie działał może na 3-4m - co zwykle i tak nie stanowi wielkiej różnicy. Jeśli jednak będzie stanowiło to dopiero wtedy kupisz sobie odbiornik na np 3-4kHz więszką częstotliwość i wypróbujesz czy zwiększy się zasięg. Jeśli się zwiększy i będzie cię to zadowalać już w pełni to jesteś w tzw domu

    pozdrówka
  • #27
    kacperb
    Level 1  
    Witam!

    Mam małą prośbę. Czy Mógłbyś umieścić dokładną specyfikację użytych elementów?
    Zwłaszcza typ zastosowanej diody nadawczej i tranzystora.

    Pozdrawiam
  • #28
    mirekk36
    Level 42  
    kacperb -> hmmm tranzystor - to najzwyklejszy pierwszy lepszy z brzegu tranzystor PNP jaki miałem pod ręką - kupiłem ich chyba ze 100szt w tme.pl

    jeśli chodzi o diodę IR - to także kupiłem w tme i jak tam zajrzysz to zobaczysz, że jest kilka diod specjalizowanych do nadawania w podczerwieni - mają takie charakterystyczne niebieskawe obudowy jak widać na fotkach. Teraz typu nie pamiętam - ale też nie dobierałem czegoś super specjalnego - ot zakupiłem pierwszy lepszy typ do IR.

    jeśli chodzi o diodę D1 - to jest to także jakaś najzwyklejsza dioda prostownicza ze spadkiem napięcia ok 0,6V ale na niewielkie napięcie - chyba max 50V bo po co większe w takim przypadku. Podobnie jak tranzystor jest w obudowie SMD i zakupiona w tme.

    co do diody LED to na pewno się nie wypowiem bo zwykle te woreczki z tme z symbolami gdzieś mi przepadają po zakupie niewielkich ilości i nie pamiętam później ;) .... ale zapewniam, że może być dowolna - a jej jasność świecenia dobierzesz za pomocą rezystorka R1

    pozdrawiam
  • #29
    Brutus_gsm
    Level 25  
    Mogę zapytać jak programowo realizujesz nadawanie rc5? Nigdzie nie mogę tego znaleźć, a staram się zrobić własny pilot rc5. Jeśli nie możesz pokazać kawałka kodu, to chociaż opisz jak to robisz. Za pomocą timerów, czy jak? Proszę o szybką odpowiedź ;)

    Ok już sobie poradziłem :D Już mam praktycznie gotowy kod obsługi rc5. Nie było w sumie tak trudno :D Problem mam tylko jeden. Wymontowałem diodę ze starego pilota i nawet jak podłączę ją bez rezystora bezpośrednio do zasilania to zasięg mam baardzo słaby, rzędu 5 cm. :/ Nośna 36kHz powinna się zgadzać w granicach błędu spowodowanego niestabilnością wewnętrznego kwarcu ATtiny2313.

    Juz problem sam rozwiązałem ;p Okazało się, że podczas wysyłania 1 jako ostatniego bitu nie wyłączałem podawania 36kHz na diodę i cały czas świeciła. Takie małe niedopatrzenie a tyle problemów mi narobiło ;)
  • #30
    kwesoly
    Level 15  
    Warhard wrote:
    Kolego przede wszystkim gratulacje za projekt.
    Jednak ciekawi mnie inna kwestia - sprawa wewnętrznego rezonatora RC w tym procku. Z doświadczenia wiem że jest spory rozrzut generowanej częstotliwości rezonatorów wewnętrznych i sama kalibracja programowa nie ustawi nam idealnie częstotliwości... Chyba że nie jest aż tak istotna częstotliwość nośnej.


    trochę odkopie temat, ale przy okazji uzupełnię.

    Format używany przez lirca jest opisany w jego dokumentacji:
    http://www.lirc.org/html/configure.html#lircrc_format

    Można się właśnie z niej (i z dokumentów pilotów) dowiedzieć, że piloty mają dośc duża tolerancję długości impulsów.

    częstotliwość nośnej nie jest sprawdzana w odbiorniku w sztywny sposób - to po prostu bardziej złożony filtr - w DS do scalonych odbiorników TSOP można zobaczyć krzywą pokazująca zależność czułości od częstotliwości nośnej.
Reply Cool? Ranking DIY | New topic
Notify about new articles
Popular Topics