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

Graficzny dekoder pilotów IR [AVR -> PC] sprawdź pilota

mirekk36 18 Paź 2010 22:43 77503 126
  • #31
    mirekk36
    Poziom 42  
    Naimad_86 --> proszę cię, uwierz mi - kwarc nie ma tu żadnego znaczenia. Jak widzisz ja zrobiłem taki układ na wewn oscylatorze i pokazuje parametry czasowe jak brzytwa co do 1us. Więc tak na prawdę wszystko zależy od programu i sposobu wykorzystania/oprogramowania procka.

    Czujnik podczerwieni może być z najgorszego demontażu on także sam z siebie nie rozszerzy ci impulsów na wyjściu. Musisz gdzieś mieć problem w sofcie który tworzysz.
  • PCBway
  • #32
    mirekk36
    Poziom 42  
    UWAGA! Właśnie w trakcie pojawiła się nowsza wersja tego układu, schemat już jest zaktualizowany, tym razem mamy możliwość skorzystania także z NADAJNIKA IR testowanego - odebranego kodu z pilota - w podczerwieni. Wystarczy w tym celu podłączyć także linię RxD mikrokontrolera oraz diodę nadawczą IR do wyprowadzenia PB3 ! W programie jest już klawisz pozwalający na emisję testowo odebranego kodu pilota. Działa wyśmienicie.

    Graficzny dekoder pilotów IR [AVR -> PC] sprawdź pilota Graficzny dekoder pilotów IR [AVR -> PC] sprawdź pilota

    Działa rewelacyjnie, dzięki za podrzucenie pomysłu - to się nazywa konstruktywna dyskusja ;)
  • #33
    janusz182
    Poziom 14  
    Witam, bardzo zainteresował mnie projekt, tym bardziej, że stoję przed koniecznością nauki mikrokontrolera kodów pilota od klimatyzacji, a nie wiem nawet na jakiej nośnej one działają, mam więc pytanie do autora projektu, czy udało się okiełznać przebiegi takowych pilotów....

    pozdrawiam
  • #34
    mirekk36
    Poziom 42  
    janusz182 napisał:
    Witam, bardzo zainteresował mnie projekt, tym bardziej, że stoję przed koniecznością nauki mikrokontrolera kodów pilota od klimatyzacji, a nie wiem nawet na jakiej nośnej one działają, mam więc pytanie do autora projektu, czy udało się okiełznać przebiegi takowych pilotów....

    pozdrawiam


    Nie ma znaczenia jaki pilot jeśli nadaje w podczerwieni, to na pewno uda ci się go tym sposobem przechwycić ;)
  • PCBway
  • #35
    gk58
    Poziom 9  
    Bardzo fajny projekt. Spróbowałem rozkodować sygnały RC5 klawiszy 1, 2 i 3 wg opisu protokołu z wikipedii.

    NIE WYSZŁO

    Robiłem to tak:
    Graficzny dekoder pilotów IR [AVR -> PC] sprawdź pilota
  • #36
    mirekk36
    Poziom 42  
    gk58 --> pobierz sobie najnowszą wersję programu, która właśnie zeszła z patelni, jeszcze ciepła ;) .... będziesz tam miał m.in nową opcję: NEGACJA Wykresu. Wtedy zobaczysz to po stronie odbiornika także i może łatwiej będzie ci przeanalizować dlaczego pokazane tu kody są poprawne ;)

    Graficzny dekoder pilotów IR [AVR -> PC] sprawdź pilota

    Graficzny dekoder pilotów IR [AVR -> PC] sprawdź pilota
  • #37
    pini0
    Poziom 14  
    Witam :
    a może tak dodać 2 przyciski do u-procesora
    zapisz odebrany kod do EPROM
    emituj odebrany kod
    szybciej będzie można sprawdzić czy ten kod działa + pilot uniwersalny
  • #38
    gk58
    Poziom 9  
    Dziękuje za nowe ekrany.

    Wg opisu RC-5 na wikipedii ramka powinna mieć 14 bitów a ta tutaj ma 13. Hm.

    Graficzny dekoder pilotów IR [AVR -> PC] sprawdź pilota

    Mimo wszystko to fajny jest ten twój analizator.
  • #39
    mirekk36
    Poziom 42  
    Ależ ma 14 bitów, tylko troszkę źle analizujesz start ramki ;) zaczyna się ciut wcześniej niż zaznaczyłeś. Chodzi o pierwszy bit startu. Przesuń wszystko w lewo troszkę i zacznie ci się zgadzać z wikipedią ;)

    Zauważ, że na tym wykresie nie zobaczysz nigdy pierwszego półbitu - pierwszego bitu startu. Mój program zawsze reaguje dekodując nową ramkę na zbocze opadające. Stąd ten problem w widoczności całości. Teraz jaśniej ? ;)

    Dodano po 20 [minuty]:

    Tak sobie teraz aż z ciekawości wertuję szufladę z pilotami, których analizę odkładałem "na zaś". Teraz nadeszło właśnie to "na zaś" ;) .... i proszę bardzo taki pilocik ładny od karty TV do komputera PC o nazwie AVerMedia ;)

    Ślicznie się dekodują jego kody i ślicznie retransmitowana jest ramka

    Graficzny dekoder pilotów IR [AVR -> PC] sprawdź pilota
    Graficzny dekoder pilotów IR [AVR -> PC] sprawdź pilota

    Dodano po 5 [minuty]:

    Ale proszę bardzo, kiedyś sam zbudowałem sobie pilocika do aparatu fotograficznego Olympus,

    https://www.elektroda.pl/rtvforum/viewtopic.php?t=1139494&highlight=

    którym robię także te fotki. I teraz pięknie się dekoduje a jednocześnie retransmitowane kody ładnie sterują aparatem ;)

    Graficzny dekoder pilotów IR [AVR -> PC] sprawdź pilota

    Tak więc możliwości są naprawdę hmmm dosyć spore teraz ;)
  • #40
    pkris74
    Poziom 12  
    No proszę jaki szybki mirku jesteś. Mi się swojego czasu marzyło takie coś uczę mikrokontroler kodów jednego pilota a innym pilotem aktywuję wysyłanie tych komend. Ale niestety za cienki jestem, bo w bascomie to nie bardzo szło zrobić a o c nie ma co nawet mówić.
  • #41
    michal090608
    Poziom 2  
    Pomysl jak i wykonanie swietne! :)
    Ale niestety musze sie przyczepic do pewnych Twoich wypowiedzi...Chyba dwukrotnie stwierdziles, ze pomiar czasow jest co do us, niestety jest to stwierdzenie bardzo bledne biorac pod uwage ze uzyles wewnetrznego generatora RC, ktorego max. czestotliwosc to 8MHz +/- 3% lub jesli go skalibrowales to +/- 1%. W pierwszym przypadku max blad przy impulsie 1000us to az 30us a w drugim to 10us, dodatkowo przy 8MHz max rozdzielczosc to 0,125 us czyli troche troche za malo zeby zgodnie ze sztuka mierzyc z dokladnoscia do 1us (rozdzielczosc powinna byc minimum o rzad wieksza). Oczywiscie rozumiem, ze w przypadku Twojego urzadzenia to nie ma najmniejszego znaczenia i urzadzenie w 120% spelnia swoje zadanie, ale wg mnie wszelkie wypowiedzi techniczne poprostu powinny byc precyzyjne zeby mlodych elektronikow nie wprowadzac w blad. Podobnie stwierdzenie ze "kwarc nie ma zadnego znaczenia" tez nie jest prawdziwe, kazdy element ma jakas tolerancje, wiem ze w tym przypadku tolerancja produkowanych kwarcow rzedu 20 - 50 ppm jest pomijalna, ale kazdy "klocek" w projekcie mniej lub bardziej nalezy brac pod uwage.

    Pozdrawiam,
    Michal
  • #42
    mirekk36
    Poziom 42  
    michal090608 -> czyżbyś był kolejnym zwolennikiem teorii spiskowej panującej wśród początkujących, wyrażanej prostym stwierdzeniem, że "wewnętrzny oscylator jest mniej dokładny od kwarcu i dlatego lepiej zastosować zawsze kwarc zamiast wewn. oscylatora" ????

    Jeśli tak to gratuluję. A teraz słowo wyjaśnienia chociaż rzadko dyskutuję z kimś kto lubi się czepiać zamiast właśnie dopytać czy podyskutować. Nikogo nie wprowadzam w błąd! Pomiary są dokonywane z rozdzielczością co do 1us. Nigdzie się nie wyraziłem i nie określiłem tolerancji tego pomiaru - bo jest ona w przypadku takiego projektu w aspekcie użycia wewnętrznego oscylatora oraz długości mierzonych odcinków dla sygnałów kodowanych w podczerwieni W OGÓLE ISTOTNA !!! Dlatego każdy kto użyje tego projektu na wewn oscylatorze i bez żadnej kalibracji będzie miał podobny a w zasadzie taki sam rezultat wyjściowy jakim jest prawidłowa retransmisja ramki, która bez najmniejszych problemów zostanie rozpoznana przez urządzenie. Jeśli uważasz, że jest inaczej panie czepialski to zadaj sobie odrobinę trudu i spróbuj wyjaśnić jaka będzie różnica z punktu widzenia funkcjonalności takiego układu zakładając, że pomiar jest robiony z dokładnością do 1us (+/- nawet 5%)!!! I nie mydlij tu oczu sorki, ale dziecinnym stwierdzeniem, że wiesz że układ spełnia w 120% moje oczekiwania ale źle działa.

    Podkreślę jeszcze raz - zastosowanie kwarcu do pracy z takimi sygnałami nie ma ŻADNEGO ZNACZENIA. Zatem zdecydowanie lepiej użyć wewnętrznego oscylatora niż dodawać zewnętrzny kwarc. Jeśli nie wiesz dlaczego to dopytaj - wtedy odpowiem, zamiast się czepiać. Albo opisz swoje teorie, których chętnie tu posłucham.

    michal090608 napisał:
    ...., ale kazdy "klocek" w projekcie mniej lub bardziej nalezy brac pod uwage.


    Tak tylko trzeba dokładnie sobie zdawać sprawę w oparciu o jakie kryteria korzystać z zewnętrznego kwarca a kiedy wystarczy zwykły wewn. oscylator. Ty niestety tego nie wiesz stosując się zapewne do w/w teorii o "mniejszej dokładności wewn. oscyla" przez co ludziom np. zegarek zrobiony programowo późni się o ileś tam sekund na godzinę. OOO jej jaka zgroza - od razu polecę po kwarc i nigdy nie użyję już wewn. oscylatora bo jest mało dokładny a do tego będę wszędzie głosił prawdę objawioną żeby nikt go nie włączał. Po czym zdziwię się, że kurczę ale na kwarcu także zegarek źle chodzi - może w troszkę dłuższym okresie ale także niedokładnie. I co w wtedy???? To ja ci powiem co wtedy - jeszcze kilka prób z durną mega synchronizacją budowanego zegarka, żeby w końcu i tak wylądował w szufladzie. Mowa tu oczywiście o amatorskich projektach żebyś zaraz nie przywoływał nie wiadomo jakich zegarów itd.

    Reasumując, w tym projekcie nawet nie zadawałem sobie trudu z kalibrowaniem wewn. oscylatora bo to niepotrzebne. A procent błędu mógłby być jeszcze większy niż twoje wspomniane 3% a i tak nie wpłynęłoby to na istotną dla pomiarów różnicę. Możesz sobie zatem założyć, że pomiar jest co do 1us z tolerancją nawet 5%. Chesz mniejszej ??? to zastosuj kwarca albo jeszcze jakieś inne bardziej precyzyjne i samokalibrujące się źródło taktowania nawet w zależności od temperatury otoczenia i innych czynników. Nawet takie za 1000$ Zrób to i porównaj wyniki. Okaże się, wtedy (jeśli dobrze napiszesz program oczywiście), że twój układ jak i mój będą na tyle precyzyjnie dokonywać odczytów i retransmitować ramkę, że w żadnym z tych dwóch przypadków nie będzie ani jednego błędu dla każdego porównywanego pilota. Wtedy może coś, gdzieś tam ci zaświta w końcu odnośnie jednego z kryteriów doboru kwarca zamiast wewn. oscylatora lub odwrotnie. Jest jeszcze oczywiście wiele innych powodów ale nie będę się tu rozpisywał. Z uwagi na powyższe także jest nieistotny fakt, że rozdzielczość 0,125us jest brana tutaj pod uwagę a nie o rząd większa. A szczególnie w tym projekcie nie ma to znaczenia - bo chyba mało albo w ogóle nie wiesz nic na temat metod odzyskiwania sygnału zegarowego i dopuszczalnych tolerancji w systemach kodowania np sygnałów podczerwieni. Poczytaj sobie o kodowaniu bifazowym (Manchester) to może coś ci się wyjaśni. A na drugi raz dopytaj zamiast się czepiać - to i dyskusja będzie o ton niższa i przyjemniejsza ok? (Ja oczywiście przepraszam jeśli cię uraziłem czymkolwiek w tej swojej wypowiedzi - no ale troszkę sam sprowokowałeś taką dyskusję)
  • #43
    michal090608
    Poziom 2  
    Widze, ze masz problemy z przyjmowaniem krytki. Po pierwsze nigdzie nie napisalem ze Twoj uklad zle dziala, wrecz przeciwnie. Zwrocilem jedynie uwage na Twoje wypowiedzi odnosnie pomiaru jak "brzytwa" co do us. Po drugie nigdzie nie napisalem zeby zastosowac kwarc w Twoim projekcie, sam napisalem ze w Twoim ukladzie to nie ma znaczenia (rowniez blad 3%).
    Cytat:

    michal090608 -> czyżbyś był kolejnym zwolennikiem teorii spiskowej panującej wśród początkujących, wyrażanej prostym stwierdzeniem, że "wewnętrzny oscylator jest mniej dokładny od kwarcu i dlatego lepiej zastosować zawsze kwarc zamiast wewn. oscylatora" ????


    To ja gratuluje jesli twierdzisz, ze tak nie jest, przytocze jeszcze raz RC skalibrowany = 1%, kwarc = 50ppm (kiepski kwarc), napisze Ci w procentach zebys zrozumial kwarc = 0,005 % ...uprzedze Twoja odpowiedz i napisze, ze w Twoim projekcie to nie ma znaczenia zeby nie obrazic Twojej dumy.

    Cytat:

    Podkreślę jeszcze raz - zastosowanie kwarcu do pracy z takimi sygnałami nie ma ŻADNEGO ZNACZENIA. Zatem zdecydowanie lepiej użyć wewnętrznego oscylatora niż dodawać zewnętrzny kwarc. Jeśli nie wiesz dlaczego to dopytaj - wtedy odpowiem, zamiast się czepiać. Albo opisz swoje teorie, których chętnie tu posłucham.


    Moja teoria jest taka, ze ogolne stwierdzenie, ze kwarc nie ma znaczenia w pomiarze jest bledne, a tak wlasnie wynikalo z Twojej wypowiedzi. A z tego co widac to nie ma co Cie o nic dopytywac a bron boze poprawiac bo reagujesz histerycznie kiedy ktos osmieli powiedziec cos co nie do konca jest po Twojej mysli. I to Ty kolego wprowadzasz niemily ton do dyskusji, reszte Twojego niepotrzebnego wywodu pozostawie bez komentarza.
  • #44
    gk58
    Poziom 9  
    Autor wypomina komuś znajomość kodowania Manchester, a chwilę wcześniej radził mi "przesuwać się o półbitu w lewo". Coś jest nie tak w tych wykresach. Pierwsze zrzuty pokazują, wg mnie, takie same przebiegi RC5 dla klawisza 1 i 2.

    Graficzny dekoder pilotów IR [AVR -> PC] sprawdź pilota

    Tu siedzi jakiś robaczek (bug).

    Dobrze, że autor z nami dyskutuje, można się czegoś nauczyć, przecież błąd może być po mojej stronie. Gdy oglądałem kiedyś projekt zegara, na załączonym filmie, widać było jak sekundy przeskakują z 48 na 50 ale to nikomu nie przeszkadzało https://www.elektroda.pl/rtvforum/topic1633264.html.
  • #45
    mirekk36
    Poziom 42  
    gk58 --> faktycznie wtedy dostrzegłeś to czego ja nawet nie dostrzegłem - a przyczyną to było to, że na szybko zorganizowałem w mało szczęśliwy sposób odczyt z układu RTC co 800ms w pętli głównej zamiast w oparciu o przerwania. No i przez to była wtopa na filmiku, Oj ale chyba nie do mojego zegara link podałeś albo o w ogóle inny wątek ci chodziło.

    Nie oznacza, to że tym razem udało ci się mnie złapać na "robaczku" chociaż wcale bym się nie obraził gdybyś coś wykrył - co jest nie tak. Ale przynajmniej ty w porównaniu do poprzednika bierzesz w tym czynny udział i dociekasz szczegółów.

    Ok w takim razie ja tobie teraz pokażę dwa obrazki. Jeden reprezentuje sporny dla ciebie kod klawisza 1 a drugi kod klawisza 2, a później objaśnię ci jeszcze raz o co chodzi i dlaczego wspomniałem o przesunięciu o pół bitu obrazka w wyobraźni.

    Graficzny dekoder pilotów IR [AVR -> PC] sprawdź pilota

    Graficzny dekoder pilotów IR [AVR -> PC] sprawdź pilota

    Już chyba też tłumaczyłem wcześniej dlaczego wspomniałem abyś w głowie przesunął czy wręcz dorysował sobie pół bitu z przodu i czasem z tyłu wykresu. Z lewej strony w przypadku RC5 będzie zawsze brakować na wykresie pół bitu (a nie chcę go "sztucznie dorysowywać" bo to ma być program uniwersalny więc nie będę wymyślał czasu dla takiego sztucznego pół bitu o zawsze wysokim poziomie logicznym.

    Oznaczyłem ci WYRAŹNIE fioletowymi liczbami od 1 do 14 dokładnie każdy bit ramki, niebieskie kreski rozdzielają bity RC5 i tu popełniasz błąd w swojej analizie. Pamiętaj - na początku procedura zawsze startuje od badania zbocza opadającego, zatem nie jestem w stanie zmierzyć pół pierwszego bitu startu i go zaprezentować na wykresie. Ale dorysowałem go ręcznie na rysunku grubą czerwoną krechą OK ? Podobnie na końcu postąpiłem, gdy bit kończy się półbitem w stanie wysokim - przecież po nim nadal będzie stan wysoki na wyjściu odbiornika - zatem moje procedury w procku rozpoznają już koniec ramki i nie pokażą długości tego pół bitu na końcu w przypadku KLAWISZA 2 !!!

    Możesz uznać to za błąd wykresu czy pomiaru, który dokonuję ale jak się głębiej zastanowisz to ten fakt nie jest już aż tak istotny z punktu widzenia możliwości odzyskania tych półbitów na drodze programowej podczas retransmisji ramki bo jak widzisz (jeśli testowałeś to w moim układzie) zawsze zadziała prawidłowo i wyemituje poprawną pełną ramkę wraz z tymi brakującymi półbitami na wykresie.

    Nie wiem czy jasno to wytłumaczyłem, jeśli nie to dopytaj i nie dąsaj się, że komuś wypominam jakiś Manchester. A co to ma znaczyć? ktoś może wejść i się czepiać a jak ja się przyczepię to wielka obraza? Nie - to dziecinada! i z takimi nie mam zamiaru dyskutować w takim razie więcej.

    Dla mnie dyskusja może być nawet ostra ale na jakieś argumenty - np takie jak ty przedstawiasz i analizujesz - ja wtedy mogę śmiało się bronić. I zdaję sobie sprawę dobrze z tego , że ja również mogę nie mieć racji.

    Dodano po 6 [minuty]:

    Jeszcze dla lepszej przejrzystości dokładniejszy opis poszczególnych bitów

    Graficzny dekoder pilotów IR [AVR -> PC] sprawdź pilota
  • #46
    seba_x
    Poziom 31  
    Mam pytanie : czy możesz zrobić opcję w programie która pokazywałaby jaki standard kodowania został odebrany np. rc5 , rc6 , sony lub inne ?
  • #47
    mirekk36
    Poziom 42  
    seba_x --> do tego potrzebna byłaby jakaś baza pilotów albo "ręczne" jej stworzenie na bazie np lirc.org/remotes. Jak tam spojrzysz to zobaczysz ile tam jest tego wszystkiego ;)

    Ale tak się składa, że dostaję sporo maili także w tej sprawie, więc może się okazać, że uda mi się to za jakiś czas także wdrożyć. A jest jeszcze kilka innych ciekawych pomysłów o których jeszcze za jakiś czas tu opowiem ;)
  • #48
    gk58
    Poziom 9  
    Na ostatnich ekranach wszystko się zgadza. Przebiegi miodzio.

    Podsumowując: Interpretacja wykresów z dekodera nie była jednoznaczna, szkoda, że trzeba mieć " w pamięci" dodatkowe zbocza na początku i/lub na końcu.

    Przeszliśmy tu długą drogę ... tak długą, że nawet sygnał klawisza 2 ewoluował (zob. przedostatni bit ramki).
    Graficzny dekoder pilotów IR [AVR -> PC] sprawdź pilota

    Super fajne narzędzie. Można się bawić nim aż do ostatniego klawisza na pilocie.
    Cześć.
  • #49
    mirekk36
    Poziom 42  
    gk58 --> Żaden klawisz 2 nie ewoluował, jednak widzę, że błąd popełniasz przy dekodowaniu bitu toogle. Przecież jego wartość zmienia się przy każdym naciśnięciu klawisza, więc pomijam go w ogóle w tłumaczeniu bo myślałem że wiesz o tym. Źle to dekodujesz - poniżesz pokazuję ci jak powinieneś zestawić sobie te dwa przebiegi:

    Graficzny dekoder pilotów IR [AVR -> PC] sprawdź pilota

    A ty przesunąłeś sobie w lewo żeby ci się zgadzał początkowy szeroki impuls. Tymczasem ja akurat zrzuciłem ekran z przeciwną wartością bitu Toogle i to cię zgubiło - bo widzę, że masz jeszcze trochę problem z jego dekodowaniem

    Dodano po 1 [minuty]:

    Dlatego wyraźnie zaznaczyłem ci w poprzednim poście na ostatnim rysunku właśnie sam BIT TOOGLE na pomarańczowo.
  • #50
    xPatryk
    Poziom 15  
    Odbiegając na chwilę od tematu, postanowiłem dzisiaj zbudować odbiornik sygnałów IR do automatyki domowej, ale ze względu na ograniczoną przepustowość medium komunikacyjnego, zastanawia mnie czy z punktu widzenia funkcjonalności (tolerancja czasów), możliwym jest stosowanie 8 bitowych zmiennych zamiast 16.

    Pozdrawiam,
    Patryk
  • #51
    mirekk36
    Poziom 42  
    xPatryk --> pewnie, że możliwe jeśli zamierzasz zrobić to dla jednego ściśle określonego standardu. Kwestia dobrania timera 8-bitowego i jego preskalera tak aby mierzyć właśnie te określone szerokości impulsów. Wtedy aby odzyskiwać ramkę wystarczy posługiwać się tymi 8-bitowymi odczytanymi wartościami timera. Będą one bardzo precyzyjne bo będą przeznaczone dla określonej częstotliwości.

    W tym projekcie z uwagi na to, że muszę mierzyć i odzyskiwać najróżniejsze szerokości impulsów od kilku us do lilkunastu tys us - to i takie 16-bitowe wartości stosuję.

    Sprawdź więc sobie takim właśnie układem jaki masz pilot tzn jaki on daje przebieg i dokładne czasy impulsów dzięki czemu spokojnie tak dobierzesz ustawienia Timera 8-bitowego żeby tak samo precyzyjnie mierzył je w tym konkretnym zakresie.

    A z ciekawości to co ta łącze że nie można przesłać dwóch 8 bitowych ramek i złączyć je 2 jedną 16bitową ?
  • #52
    xPatryk
    Poziom 15  
    Zależy mi na uzyskaniu szeroko rozumianej kompatybilności z różnymi pilotami, od tych do TV, przez miniaturowe do oświetlenia, etc...

    Kwestia ograniczenia możliwości transmisyjnych wynika z faktu, iż jest ono współdzielone z innymi urządzeniami (magistrala RS485, prędkość transmisji 33,6 kbps) a dane numeryczne kodowane są przez dwa znaki szesnastkowo (znaki specjalne stosowane są dla sterowania transmisją, więc nie mogą zostać wykorzystane).

    Daje to konieczność przesłania na żądanie mastera (moduły są odpytywane) powiedzmy 100 x 4 znaków oraz ich sumy kontrolnej, co zmuszałoby do zwiększenia "okienek" czasowych na retransmisję przewidzianych w opracowanym protokole.
  • #53
    pawel129
    Poziom 16  
    jaka prędkość wewnętrznego oscylatora musi być ustawiona w fuse bitach ? I jaka prędkość i parametry portu szeregowego kompa do odbioru danych ?
  • #54
    mirekk36
    Poziom 42  
    pawel129 napisał:
    jaka prędkość wewnętrznego oscylatora musi być ustawiona w fuse bitach ? I jaka prędkość i parametry portu szeregowego kompa do odbioru danych ?


    O prędkości taktowania to już chyba pisałem, ale przypomnę oczywiście:

    1. Wewn. oscylator 8MHz
    2. Prędkość transmisji RS232 to 38400

    O tym drugim rzeczywiście jakoś zapomniałem chyba wspomnieć, przepraszam.
  • #55
    mirekk36
    Poziom 42  
    No to powstały nowe i chyba bardzo fajne/przydatne opcje (teraz jest tzw. full wypas) ;)

    Graficzny dekoder pilotów IR [AVR -> PC] sprawdź pilota

    1. Można zapisywać graficzny obraz ramki podczerwieni
    2. Można zapisywać ramkę jako plik tekstowy, który zawiera poszczególne czasy !!!
    3. Można odczytywać ramkę z pliku tekstowego.

    4. Można wyemitować ramkę wczytaną tylko z pliku (nie musi być wcześniej odebrana do mikrokontrolera)


    Daje to możliwość zapisania do pliku *.TXT dowolnej własnej ramki, wprowadzonej ot tak "z ręki". Można zatem sobie tym narzędziem przetestować czy pilot opisany na www.lirc.org/remotes ma poprawnie opisany format ramki i czy będzie sterował naszym urządzeniem, do którego nie mamy pilota.

    Np posiadasz jakiś aparat fotograficzny Nikon czy Olympus czy Canon - ale nie masz pilota. Szukasz sobie w necie także na powyższej stronce opisu standardu i jak wygląda ramka, sam tworzysz plik *.TXT podając czasy dla odpowiedniego kodu/ramki i testujesz czy działa. Jeśli działa - to już możesz spokojnie sam sobie zrobić pilocika na AVR'ku

    Poniżej przykład jak wyglądają zapisane tekstowo ramki - prosto jak drut, po prostu po kolei lecą czasy impulsów podane w mikrosekundach ;)

    Pierwszy parametr na górze, musi przybierać zawsze wartość 0 lub 1. Nie reprezentuje on wartości czasu żadnego impulsu w ramce tylko mówi o tym jak ją przedstawić na wykresie:

    0 - jak w nadajniku
    1 - jak w odbiorniku

    Obojętnie jednak jak będzie przedstawiony wykres to i tak ramka zostanie wyemitowana prawidłowo z mikrokontrolera ;)

    Graficzny dekoder pilotów IR [AVR -> PC] sprawdź pilota

    Działa wszystko SUPER ;)

    A tutaj przykład własnej ramki po łatwym zmodyfikowaniu pliku tekstowego czy utworzeniu go na nowo:
    Graficzny dekoder pilotów IR [AVR -> PC] sprawdź pilota
  • #56
    pawel129
    Poziom 16  
    a czy na tsop4836 będzie to działać? Bo niby skleiłem układ, wg najnowszego schematu, ale coś nie chce latać :/
    Czy potrzebne są jakieś dodatkowe sterowniki, czy wystarczy podłączyć do COMa i program widzi połączenie od razu ?
    Jakie dokładnie muszą być ustawienia portu COM w komputerze ?
  • #57
    mirekk36
    Poziom 42  
    pawel129 --> z tym TSOP4836 to nawet bez mrugnięcia oka powinno działać bez najmniejszego problemu, ale spróbuj uruchamiać to po kolei mniejszymi kroczkami żeby zobaczyć gdzie leży błąd:

    1. na początku podłącz do wyjścia TSOP'a przez jakiś rezystor samą zwykłą diodę LED i sprawdź czy miga w trakcie gdy nadajesz pilotem - będziesz miał pewność na 100000% że sam TSOP ci działa i dobrze go podłączyłeś (że nie pomyliłeś np wyprowadzeń)

    2. gdy już zadziała to przede wszystkim napisz czy stosujesz procek ATmega8 i czy przestawiłeś fusebity na wewn. oscylator 8MHz bo bez tego też będzie problem

    3. gdy już ustawisz fusebity to wtedy sprawdź sobie czy działa ci przejściówka RS232 (napisz czego używasz? MAX232 czy jakiejść USB/RS232) - tak czy inaczej zewrzyj na jej piny Rx oraz Tx od strony procka (procka na chwilę wyjmij z układu) i sprawdź w terminalu czy wraca ci echo ok ?

    4. gdy echo będzie ok, gdy fusebity będą ustawione ok - to wtedy podłącz procka do przejściówki (na krzyż oczywiście) i gdy będziesz nadawał pilotem to podłącz się terminalem na początku na prędkości 38400 , 8 n 1

    W terminalu powinny pojawiać się serie liczb z procesora, jeśli się nie będą pojawiać to daj znać - coś nadal jest nie tak gdzieś w poprzednich krokach/połączeniach - pomyślimy i na pewno pomogę ci to uruchomić

    5. gdy już zaskoczy to w terminalu to wtedy - można odpalić śmiało już program na PC i także powinno wszystko działać

    Wprawdzie jeszcze nie wrzuciłem najświeższej wersji wsadu i programu ale już to robię więc za jakąś chwilę zassaj najnowsze wersjie, które na końcu opisałem ok?


    i daj znać po kolei co i jak? ;)

    Dodano po 4 [minuty]:

    jeśli stosujesz zwykły port COM1 i przejściówkę MAX232 to nie są potrzebne żadne sterowniki, ale jeśli wykorzystujesz jakąś przejściówkę USB/RS232 to na pewno potrzebne są jakieś sterowniki do tej przejściówki, które musisz mieć w zestawie. One dopiero spowodują że w systemie pojawi ci się jakiś nowy port COM i to jego trzeba będzie wybrać w terminalu do testów albo już w programie na PC
  • #58
    pawel129
    Poziom 16  
    użyłem do testów przejściówki USB-RS232.

    1. dioda mruga pięknie.
    2. ATmega8L-8PU, fusebity ustawiłem tylko "Int. RC Osc. 8 MHz; Start-up time: 6 CK + 4 ms"
    3. echo działa
    4.niestety - cisza

    nie wiem co jest, procek zaprogramowany, zweryfikowany, schemat miliard razy sprawdzony...
    :(
  • #59
    mirekk36
    Poziom 42  
    Kurczę - a masz pod ręką cokolwiek (jakiś język/kompilator), żeby samemu wpisać sobie kawałek kodu żeby procek wysyłał powiedzmy co sekundę tylko jakiś napis na terminal? - żeby zobaczyć czy nadaje coś ????

    Dodano po 1 [minuty]:

    możesz pokazać jakąś fotkę jak masz to wszystko połączone?

    hmmm najważniejsze do uruchomienia tego etapu to podpięcie nogi TxD z procka do przejściówki RS232 oraz wyjścia z TSOP na wejście ICP procka. Oczywiście koniecznie trzeba dać ten rezystor podciągający 10k do VCC na linii do ICP.

    No ja biorę ten wsad, który można zassać z netu programuję procka (już nawet drugiego wziąłem) i ładnie w terminalu się pokazuje co trzeba.

    Dodano po 17 [minuty]:

    jak chcesz to napisz w jakim języku programujesz to napiszę ci taki najprostszy test do sprawdzenia łączności z RS232.
  • #60
    pawel129
    Poziom 16  
    układ raczej działa prawidłowo, zrobiłem mały eksperyment: do wyjścia TxD procka podłączyłem diodę przez rezystor,aby monitorować transmisję. Dioda miga gdy odbiornik przyjmuje ramkę IR z pilota.

    Natomiast do podłączenia z COM użyłem wcześniej max232 i lipa. Teraz używam chińskiej przejściówki USB-RS232, bez MAX'a. Czy max232 też musi pośredniczyć ?