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

Bascom AVR - Dekodowanie części jawnej z układów HCS200/301

FastProject 24 Maj 2016 09:18 5007 40
  • #1 24 Maj 2016 09:18
    FastProject
    Poziom 28  

    Witam,
    chcę zrobić prostego pilota i odbiornik pilota z układami Microchipa.
    Aby nie ingerować w licencje Keelog chcę wykorzystać tylko część jawną wysyłaną przez te układy.

    Jak najlepiej zdekodować odczytać te bity w dowolnym procesorze AVR i programu napisanego w Bascom AVR.

    Przykładowa procedura była by super, ale i opis sposobu jak to zrobić za pomocą peryferii uP także pomogą w pisaniu oprogramowania dla odbiornika pilota. Odbiór będzie prawdopodobnie na układzie RFM83.

    Z góry dzięki za sugestie.

    0 29
  • Relpol
  • #2 24 Maj 2016 09:21
    BlueDraco
    Specjalista - Mikrokontrolery

    Sugestia: przydałoby się przerwanie timera z częstotliwością ok. 5..6 razy większą od częstotliwości strumienia bitów.

    0
  • #3 01 Cze 2016 11:12
    FastProject
    Poziom 28  

    Myślałem wstępnie, żeby wykorzystać przerwania zewnętrzne i mierzyć czasy impulsów paczki za pomocą timera?

    EDIT, mam na myśli przerwanie ICP od timera1, ale jeszcze nie wiem jak to ugryźć ;)

    0
  • #4 02 Cze 2016 01:35
    lukasixthm
    Poziom 23  

    Sygnał przychodzący podłączasz do dwóch wejść: INT0 i ICP1. Rejestry MCUCR i GICR konfigurujesz tak, żeby na zbocze narastające na wejściu INT0 timer startował, a na opadające na INT1 zatrzymywał się...

    0
  • #5 02 Cze 2016 07:42
    FastProject
    Poziom 28  

    Czy przerwanie int0 faktycznie jest potrzebne skoro icp1 można ustawić także na zbocza i przerwania w momencie jakiegoś zbocza? ?

    0
  • #6 02 Cze 2016 11:34
    373522
    Użytkownik usunął konto  
  • #7 02 Cze 2016 11:40
    FastProject
    Poziom 28  

    Wbrew pozorom dla Bascoma brak dokładnych przykładów opisujących (szukałem). Mało ludzi podejmuje się zrobić to Bascomie, ale ja już w nim trochę siedzę to nijako jestem zmuszony zrobić to właśnie w nim.

    Tak czy inaczej brak sensownych opisów i przykładów wiec chce zrobić sam od podstaw ale w porządnie wykorzystując metody czy peryferia które najlepiej sie do tego nadadzą.

    Czasy Baud to 400uS lub 200us (pozostanę przy czasach impulsu 400us).

    W tej dokumentacji: http://read.pudn.com/downloads42/sourcecode/embed/144285/keeloq/MCDEC/kelog642.pdf Znalazłem fajny opis:
    Bascom AVR - Dekodowanie części jawnej z układów HCS200/301
    Figure 2 shows the sampling points when sampling
    data. The first and last elements are used exclusively to
    verify the integrity of the received signal. The first element
    (sample point A) is always high, the second (sample
    point B) is the complement of the data bit being
    sent, and the final element (sample point C) is always
    low. Because the period between the low portion of a
    bit (sample point C) and the rising edge of the following
    bit (sample point X) can vary somewhat, the rising edge
    of the first element (sample point X) is used to resynchronize
    the receiving routine to each incoming bit.

    Pozdrawiam :)

    0
  • #8 02 Cze 2016 15:41
    373522
    Użytkownik usunął konto  
  • Pomocny post
    #9 08 Cze 2016 23:48
    WOBI
    Poziom 19  

    Robi się to prosto na wejściu ICP Atmegi, mierzysz czas pomiędzy kolejnymi zboczami, raz jest opadające, raz narastające itd.. potem to tylko interpretacja wyników, liczenie bitów i po odliczeniu 64 bitów z transmitowanych 66, bo dwa ostatnie dla uproszczenia procedury pomijasz. wyświetlasz na LCD lub wysyłasz po RS232 do komputera, a tam wyświetlasz w dowolnym terminalu/programie.
    Same procedury przerwań od ICP wyglądają tak:

    Kod: vbnet
    Zaloguj się, aby zobaczyć kod


    oczywiście deklaracje wyglądają tak dla transmisji 400us HCSa

    Kod: vbnet
    Zaloguj się, aby zobaczyć kod

    0
  • Relpol
  • #10 08 Cze 2016 23:59
    FastProject
    Poziom 28  

    Witam, dzięki za przykłady, na pewno się przydadzą.

    Ten kod po szybkim przejrzeniu to chyba podobna metoda jak przytoczona z dokumentacji AN642 Microchipa?

    0
  • #11 09 Cze 2016 00:12
    WOBI
    Poziom 19  

    Nota o której piszesz robi to inaczej. Nie wzorowałem się na niczym, sam ją wymyśliłem, potrzebowałem dekodować piloty stałokodowe oparte na SM5028 i keeloq HCS200/300/301. Przerwanie od ICP jest uniwersalne i świetnie nadaje się do takich celów.

    Jeśli chodzi o procedurę dekodowania części crypto to procedura w bascomie też jest prosta. Podam tylko samą pętelkę dla przykładu.

    Kod: vbnet
    Zaloguj się, aby zobaczyć kod

    0
  • #12 09 Cze 2016 08:27
    BlueDraco
    Specjalista - Mikrokontrolery

    Dodajmy, że kiedfy pilot nie nadaje, odbiornik odbiera śmieci i wystawia na wyjściu przebieg prostokątny, któego zbocza są dużo gęstsze niż podczas odbioru danych, a każde zbiocze będzie w takim przypadku generowało przerwanie. Dlatrego lepiej jest odbierać w przerwaniu timera, a nie używać przerwań od zboczy.

    0
  • #13 09 Cze 2016 08:35
    FastProject
    Poziom 28  

    Akurat w przypadku hcs jest dość długi bit startowy o znanej długości. Wystarczy więc zmierzyć jego długość +/- i dopiero po jego weryfikacji sprawdzić kolejne bity danych.

    0
  • #14 09 Cze 2016 09:54
    WOBI
    Poziom 19  

    Cytat:
    Dodajmy, że kiedfy pilot nie nadaje, odbiornik odbiera śmieci i wystawia na wyjściu przebieg prostokątny, któego zbocza są dużo gęstsze niż podczas odbioru danych, a każde zbiocze będzie w takim przypadku generowało przerwanie. Dlatrego lepiej jest odbierać w przerwaniu timera, a nie używać przerwań od zboczy.


    To jest oczywiste, ale.. odbiornik RF ma tez ograniczone pasmo do kilku kHz (można to sprawdzić w każdej nocie odbiornika) i nie są te zakłócenia takie częste, to rząd 50 do 100us, mogę pokazać to na zrzucie z oscyloskopu, odbiór w timerze też musisz używać przerwania, np. INTx do synchronizacji chociaż jednego ze zboczy, i te śmieci też zajmują procesor, śmieci zawsze będą i zawsze zajmą jakiś czas procesora, w przypadku timera jak proponujesz timer generuje przerwanie co 80us czyli porównywalnie jak przy ICP i zakłóceniach, na to samo wychodzi jeśli chodzi o zajętość procka.

    Moja procedura szybko sprawdza czy czas między zboczami mieści się 400us 800us 4ms i 10ms każde inne odstępstwo jest uznawane za błąd i wychodzi z przerwania, kasując zmienne i znaczniki, do tego przepełnienie timera powyżej 16ms kasuje też wszystko.

    Każda inna procedura też będzie to robić, nie zmienisz tego, nawet samplując tak jak w nocie AN tez zajmujesz czas procesora ;) wogle mam nie zajmować jego czasu? ;) przecież AVR wykonuje takie operacje bardzo szybko.

    Procedurę używam w większy programie z innymi timerami i innymi zadaniami i działa poprawnie.
    Dla mnie to nie jest żaden argument, jeśli używa się przerwania INT czy ICP do odbioru transmisji czy to po RF czy to po IR to zawsze będą zakłócenia i trzeba tak napisać procedurę przerwań by była jak najkrótsza, bo i tak ją trzeba obsługiwać, tego nie wyeliminujesz.

    Samplowanie timerem też zajmuje czas i jest obsługiwana przez przerwanie.

    Czy zajmę czas procesora ICP od zboczy w granicach 100us czy przerwaniem samplujacego Timera np co 80us to jedno i to samo.

    0
  • #15 09 Cze 2016 10:46
    BlueDraco
    Specjalista - Mikrokontrolery

    Przy odbiorze w przerwaniu timera mamy stałą częstotliwość przerwań, np. 5 kHz. Przy odbiorze z użyciem przerwania od zbocza mamy zmienną, nieokreśloną częstotliwość przerwań - ja oglądałem na oscyloskopie odstępy zboczy rzędu 20..50 us, czyli przy braku transmisji procesor spędza praktycznie cały czas w obsłudze przerwania od śmieci.

    0
  • #16 09 Cze 2016 11:09
    WOBI
    Poziom 19  

    Samplując tak jak piszesz timer generuje stałe przerwanie np co 100us więc co 100us procek i tak wchodzi do przerwania, ja używam odbiornika co generuje impulsy też co 100us, więcej nie wydoli bo takie ma pasmo przenoszenia, to jest założenie konstrukcyjne, a o tym często sie zapomina przy takich konstrukcjach.

    Transmisja moich bitów które chce odbierać, te najkrótsze maja 250us.
    Wychodzi taka sam zajętość obsługi przerwania, wiem że masz racje bo analizujesz to pod kątem jak by były impulsy bardzo krótkie, ale pamiętajmy że duże znaczenia ma sprzęt w tym przypadku odbiornik RF i jego pasmo przenoszenia lub można to ograniczyć przez filtr dolnoprzepustowy na wejściu ICP.

    Naprawdę robiłem testy i analizowałem to pod tym kątem, mi działa program dobrze spełnia swoje zadanie, dobrałem odbiornik właśnie tak by nie generował krótkich impulsów, nawet wstawiłem na początku przerwania i na końcu Toggle.bit i obserwowałem na oscyloskopie ile zajmuje czasu procedura i jak często jest obsługiwana i wiem oczy pisze i nie polemizuje tylko dla samego polemizowania, analizowałem to dokładnie bo tez tak jak Ty miałem wątpliwości co do zajętości procesora, okazało się inaczej i nie przejmuje się tym oczywiście pamiętam o sprzęcie by na ICP nie było krótkich impulsów, większość odbiorników spełnia te wymagania i tak też są projektowane bo transmisje z pilotów nie są za szybkie.

    Postaram się w miarę czasu pokazać to na zrzucie z oscyloskopu dla jednej procedury Timer i drugiej ICP, nie ma jak pokazać to jak działa w rzeczywistości.

    0
  • #17 13 Cze 2016 11:10
    FastProject
    Poziom 28  

    Dziękuję za pomoc. Tak przy okazji możecie polecić jakieś inne jak wspomniane układy za pomocą których można odebrać sygnał taki radiowy, lub zbudować moduł podobny do RFM83, ale o mniejszych rozmiarach?

    0
  • #18 20 Cze 2016 11:12
    WOBI
    Poziom 19  

    Najmniejsze odbiorniki jakie widziałem to AM RX1 Receiver Module, 433MHz Ref: QAM-RX1-433 lub Link

    Bascom AVR - Dekodowanie części jawnej z układów HCS200/301


    ostatnio pojawiło sie cos takiego od chinczyka 433MHZ Transmitter & Receiver Module SYN115 SYN480R ASK Wireless Module

    Bascom AVR - Dekodowanie części jawnej z układów HCS200/301

    0
  • #19 05 Lip 2016 08:58
    FastProject
    Poziom 28  

    Ciekawe te moduły, a ciekawsze, że można kupić nawet same układy SYN115 SYN480R znajdujące się w tych modułach.

    Testowałeś je?

    0
  • #20 06 Lip 2016 08:38
    FastProject
    Poziom 28  

    Pytanie do kolegi WOBI, czy ten kod uzywałeś taże do dekodowania innych pilotów.

    Chodzi mi o ten fragment:

    WOBI napisał:

    Kod: vbnet
    Zaloguj się, aby zobaczyć kod


    W Keeylog najpierw nadawany jest LSB (część kodowana), a tutaj po 12 bitach przerywasz odbiór kolejnych bitów?

    Jak to u Ciebie wyglądało?

    Już testuje program oparty na Twoim kodzie, pojawiła się jednak mała niedogodność. Mianowicie procesor nie odbiera pierwszej nadanej przez pilota ramki. Czyli jeśli nacisnę na stałe przycisk, to program rozpoznaje dopiero 2 ramkę danych od pilota. Pilot jest na 100% dobry bo testuję go z innym urządzeniem na takim samym module odbiorczym (RFM83CL).

    Zaobserwowałeś u siebie taką sytuację?

    0
  • #21 07 Lip 2016 14:01
    WOBI
    Poziom 19  

    Program ma znacznik Decode_keloq i jeśli jest równy zero to znaczy że jest ramka stałokodowa 12 bitowa i tylko wtedy jest przerywany odbiór, bo ich więcej nie będzie, a gdy jest ustawiony znacznik Decode_keloq na 1 to program liczy dalej do 64.

    Dodatkowo jest znacznik Startbit, jest on tylko ustawiany tak jak poniżej i jeśli jest ustawiony, to tylko wtedy jest zwiększany licznik Numerbitu i tylko wtedy jest on wstanie osiągnąć 12 czy 64. Startbit jest ustawiany tylko po prawidłowym starcie transmisji, czyli poprzedni bit był prawidłowy i obecnie była prawidłowa cisza 4ms lub 12ms, wtedy zaczyna się odbiór bitów.

    Jakiekolwiek odstępstwo od bitów transmisji 400us, ciszy 4ms, 12ms, kasuje Startbit i Numerbitu.

    Program rozpoznaje po długości ciszy i poprzednim bicie (ma go w pamięci) czy jest to HCS 200/300x Keeloq 64 bity, 4ms ciszy po bitach synchronizacji, czy 12 bitów cisza 10ms układu SM5028 odpowiednik HT12E i tylko dla tego układu dopiero druga ramka będzie odebrana prawidłowo.

    w tym fragmencie

    Kod: vbnet
    Zaloguj się, aby zobaczyć kod

    tu sa definicje czasów

    Kod: vbnet
    Zaloguj się, aby zobaczyć kod

    0
  • #22 07 Lip 2016 14:43
    FastProject
    Poziom 28  

    WOBI napisał:

    Jakiekolwiek odstępstwo od bitów transmisji 400us, ciszy 4ms, 12ms, kasuje Startbit i Numerbitu.

    Program rozpoznaje po długości ciszy czy jest to HCS 200/300x Keeloq 64 bity, 4ms ciszy po bitach synchronizacji, czy 12 bitów cisza 10ms układu SM5028 odpowiednik HT12E.


    No tego się po części domyśliłem, jednak dlaczego za każdym razem odbiera dopiero 2 ramkę danych z HCS301? Zaobserwowałeś u siebie taką sytuację? Jedyne istotne zmiany w porównaniu do Twojego kodu, to mam M88 (zmiana na Tifr1.icf1)...

    0
  • #23 07 Lip 2016 14:51
    WOBI
    Poziom 19  

    Nie patrzyłem na to, dla mnie nie ma to znaczenia, to tylko około 30ms opóźnienia, a i tak jak się naciska klawisz pilota, to HCS wysyła minimum 3 do 4 ramek, no chyba że są idealne nie przerywające klawisze i osoba bardzo szybko puszcza klawisz, ale nie spotkałem się z takim przypadkiem. Wręcz przeciwnie program powinien tak się przyjmuje, nawet w notach jest napisane o tym, że powinno się programowo przyjąć 3 dobre ramki po kolei by uznać transmisje za prawidłową.

    A jak rozpoznajesz że odbiera dopiero druga?

    Chyba że nie kasujesz flagi

    Kod: vbnet
    Zaloguj się, aby zobaczyć kod

    0
  • #24 07 Lip 2016 15:19
    FastProject
    Poziom 28  

    WOBI napisał:

    A jak rozpoznajesz że odbiera dopiero druga?

    Chyba że nie kasujesz flagi


    Flagę kasuje. Mam program autorstwa znajomego, który odbiera i wyświetla kody wysyłane przez piloty HCS200/300 itp.

    Kody trafiające z tego samego pilota pierwszą ramką załączają inne urządzenie współpracujące z tym programem. Niestety programu tego nie mogę udostępnić gdyż jest on serwisową częścią dużego bardziej rozbudowanego urządzenia komercyjnego.

    0
  • Pomocny post
    #25 07 Lip 2016 15:26
    WOBI
    Poziom 19  

    To trzeba zmienić priorytet z 12 bitów stałokodowego pilota na odbiór HCSa lub całkiem usunąć obsługę pilota 12 bitowego.

    może tak:

    Kod: vbnet
    Zaloguj się, aby zobaczyć kod


    lub tak sam HCS:

    Kod: vbnet
    Zaloguj się, aby zobaczyć kod

    0
  • #26 11 Lip 2016 09:13
    FastProject
    Poziom 28  

    WOBI napisał:
    To trzeba zmienić priorytet z 12 bitów stałokodowego pilota na odbiór HCSa lub całkiem usunąć obsługę pilota 12 bitowego.


    Zaproponowane zmiany nic nie zmieniły. Jak była obsługa 12bitów to procesor i tak rozpoznawał jaka to ramka za pomocą długości bitu startowego i dalej już "nie obsługiwał" części odpowiedzialnej za tą ramkę 12bit.

    0
  • Pomocny post
    #27 11 Lip 2016 14:56
    WOBI
    Poziom 19  

    FastProject napisał:

    Zaproponowane zmiany nic nie zmieniły. Jak była obsługa 12bitów to procesor i tak rozpoznawał jaka to ramka za pomocą długości bitu startowego i dalej już "nie obsługiwał" części odpowiedzialnej za tą ramkę 12bit.



    Sprawdziłem i odbiera normalnie zawsze pierwszą ramkę, załączam ekrany oscyloskopu, drugi kanał jest wyzwalany flagą po odebranej ramce 12/64 bitów

    Bascom AVR - Dekodowanie części jawnej z układów HCS200/301HCS300..jpg Download (142.36 kB)Bascom AVR - Dekodowanie części jawnej z układów HCS200/301HCS300..jpg Download (106.48 kB)

    i kolejne ramki, w trakcie drugiej puszczony przycisk, jest nie dokończona.
    Bascom AVR - Dekodowanie części jawnej z układów HCS200/301HCS300..jpg Download (66.93 kB) Bascom AVR - Dekodowanie części jawnej z układów HCS200/301HCS300..jpg Download (70.11 kB)

    0
  • #28 13 Lip 2016 09:23
    FastProject
    Poziom 28  

    Dzięki za oscylogramy. Zmusiło to i mnie do zbadania przebiegów na wyjściu modułu RFM83CL.

    Okazuje się, że przy pierwszej ramce poszczególne odbierane bity nie są dobrze rozpoznawane. Czasami nie rozróżnia 0/1 i na wyjściu modułu nie są ostre krawędzie prostokątu, a takie piki. Sprawdzone na 2 modułach RFM83CL (L=wersja niskonapięciowa 2,1-3,6V).

    Na szczęście dostałem moduł RFM83C (bez L/ 3,6-5,5V) i ten już poprawnie odbiera także pierwszą ramkę. Oba moduły zasilam z tego samego napięcia 3,3V.

    Wniosek jeden...moduły RFM83CL są jakieś niedorobione (zapewne kosztem tego, że działają przy niższym napięciu, bo już niby od 2,1V)

    Dziękuję za pomoc. Narazie temat zostawię otwarty, na jakieś ewentualne dalsze wnioski i spostrzeżenia.

    0
  • #29 13 Lip 2016 22:57
    kamyczek
    Poziom 34  

    Miałem ten sam problem z pierwszej paczki kawałek synchronizacji się gubi , widać odbiornik potrzebuje więcej czasu na dostrojenie demodulatora , ale jak dobrze napiszesz dekoder ,to będzie działał poprawnie , pierwsze 6-8 bitów to tylko synchronizacja dla dekodera zazwyczaj mają taką samą wartość w każdym bajcie i używana jest jedynie do dekodowania i synchronizacji dekodera odpowiedniego systemu kodowania . Ja bym tam użył odbiornika z rssi żeby wiedzieć co jest sygnałem a co śmieciami z powietrza (szumem)

    0
  • #30 25 Lip 2016 13:00
    FastProject
    Poziom 28  

    Próbowałem jeszcze w modułach RFM83CL podciągać pin DATA do 3,3V ale nic to nie dało.

    Próbuje teraz dodać obsługę 2 najstarszych bitów VLow i Repet, ale coś mi nie odbiera bitu 66.

    Tak zmodyfikowałem część odbiorczą:

    Kod: vbnet
    Zaloguj się, aby zobaczyć kod


    Program "nie dociera" jednak do 66 bitu...rozpoznaje 65 bitów tylko.
    Jakieś pomysły?

    0
  Szukaj w 5mln produktów