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

Alarm, czytnik RFID - komunikacja CAN

kolgreen 17 Jun 2015 14:38 7395 14
Optex
  • Alarm, czytnik RFID - komunikacja CAN

    Witam serdecznie forumowiczów.
    Chciałbym przedstawić projekt, który zajął mi dość sporo czasu.
    Urządzenie tworzyłem wiele miesięcy, zmieniałem trochę założenia, najpierw miała być klawiatura, skończyło się na kartach RFID. Zahaczyłem nawet o udane odtwarzanie nagranego dźwięku z pamięci mikrokontrolera.
    Na początku założenia były dość proste - stworzyć prosty system dozorujący nowo budowany obiekt. Chodziło o to, by powstało coś konkretnego za małe pieniądze. I choć znalazłaby się jakaś stara centralka, to zawsze miło stworzyć coś samemu.

    Urządzenia
    Alarm składa się z dwóch głównych urządzeń. Centrali oraz czytnika kart RFID.
    Oba urządzenia połączone są ze sobą czterema drutami. Z uwagi na to, że dedykowany kabel dla magistrali CAN jest przesadnie drogi, zastosowałem zwykłą skrętkę komputerową która jest stosunkowo tania. Jedna z par jest wykorzystana przez CAN, drugą parę przeznaczyłem na zasilanie, pozostałe można wykorzystać w przyszłości.

    Słów kilka o CAN
    Magistrala CAN jest dość popularna w przemyśle, stosuje się ją w samochodach, samolotach i chyba coraz częściej w budynkach (domy inteligentne). Jej niewątpliwą zaletą, jest to, że do dwóch kabli możemy podpiąć bardzo wiele urządzeń a prędkości dochodzące do 1 Mb/s na dystansie do 40 m są wystarczające do wspomnianych wcześniej zastosowań. Oczywiście odległość można zwiększać jednak prędkość spada 250 kbit/s mniej więcej co 250 m.
    Komunikacja między urządzeniami w sieci CAN daje sporo możliwości, pakiety mogą być adresowane dla konkretnych urządzeń oraz mogą otrzymać priorytety.

    W związku z powyższymi zaletami magistrali CAN, system alarmowy może współpracować z pozostałymi elementami sterującymi budynkiem (które planuje stworzyć w przyszłości).

    Centralka

    Alarm, czytnik RFID - komunikacja CAN

    Układ działa w oparciu o mikrokontroler PIC18F25K80 który posiada sprzętowy CAN (jednak potrzeby jest jeszcze MCP2551) i dość sporo pamięci. Na płycie centralki znajduje się również RTC (obecnie jeszcze niezaimplementowany) w układzie DS1307 (komunikacja po I2C). Z uwagi na to iż czujki działają pod napięciem 12V a mikrokontroler i CAN na 5V zastosowałem transoptory izolujące linie dozorujące.
    Syrena działająca również na 12V jest sterowana przez przekaźnik.
    Centralkę konfiguruje się poprzez podłączenie komputera do UART i poruszając się po menu wyświetlanym w dowolnym terminalu na komputerze konfiguruje się urządzenie.
    Są to puki co podstawowe funkcje, jak;
    - włączenie i wyłączenie linii, opóźnienie dla poszczególnych linii (po jakim czasie włączyć alarm od chwili naruszenia),
    - zarządzanie użytkownikami (kartami rfid),

    Czytnik RFID

    Alarm, czytnik RFID - komunikacja CAN Alarm, czytnik RFID - komunikacja CAN

    Czytników może być praktycznie dowolna liczba w systemie. W moim zastosowaniu wystarczy jednak jeden. Jest to układ zbudowany w oparciu o moduł RFID-RC522 który kontrolowany jest przez PIC18F25K80. Podobnie jak w centralce na płycie znajduje się również MCP2551. Oraz złącze dla trzech LED informujących o statusie systemu. Niestety sprawa z zasilaniem jest dość zagmatwana, z centralki "pobierane jest" 5V i z tym napięciem działa CAN, jednak układ RC522 wymaga 3,3V więc trzeba było zastosować kolejny stabilizator. By nie robić tylu przełączników między poziomami napięć, mikrokontroler również działa na 3,3V a 5V jest podane na MCP2551, tak by zachować standard napięć w magistrali CAN. Wystarczył zatem jeden dzielnik napięcia na sygnale wychodzącym z MCP2551 do mikrokontrolera.

    Czujki
    Poza możliwością użycia czujek typu NC i NO (wejścia centralki są w pełni konfigurowalne) możliwe jest użycie (wcześniej je trzeba będzie opracować) czujek podłączonych do magistrali CAN. Dzięki temu można będzie identyfikować dowolną czujkę a koniecznym będzie jedynie poprowadzenie tylko 4 drutów (2 na CAN i 2 na zasilanie).

    Z całą pewnością projekt jeszcze będę rozwijał i pewnie po Waszych uwagach będzie nad czym myśleć... Jednak wydaje mi się, że puki co stanowić on będzie dobrą platformę sprzętową, dla której będę udoskonalał oprogramowanie.

    Cool? Ranking DIY
    About Author
    kolgreen
    Level 16  
    Offline 
    kolgreen wrote 264 posts with rating 230, helped 11 times. Been with us since 2007 year.
  • Optex
  • #2
    Atreyu
    Level 22  
    Ponieważ schematu brak napisze tylko o podstawach. W centralce procesorowej linie parametryczne to podstawa a tu...

    Nie widać tu żadnych elementów zabezpieczających transoptor! Na biurku w warunkach warsztatowych na pewno działa to poprawnie. Po podpięciu 10m przewodu do czujki już widzę jak będziesz wymieniał kolejne transoptory. Przerabiałem dokładnie to samo z PC847 ;)

    Jeżeli wejścia transoptora zasilasz z 12V to po co pchasz w LED'a aż 10mA ? Procek tak mocno obciąża jego złącze C-E ? Sprawdź ile pobiera podwieszony port procka i dobierz prąd diody według datasheeta.

    Czy dałeś zabezpieczenie linii zasilającej czujki? jak nie to wystarczy zrobić na niej zwarcie i cały alarm leży :)

    Przekaźnik do sterowania syreny? Dwudziestoamperowy ? Czy ta syrena jest z silników od pralki frania, a może od młockarni ? Przecież tam by wystarczył zwykły bipolar do powiedzmy kilku amperów, powyżej FET mocy albo specjalizowany power switch. Poza tym jedna linia sygnalizatora akustycznego? Czemu nie ma osobnej linii do sygnalizatora optycznego?

    Jak rozumiem zasilasz to jakimś zasilaczem, dwudziestoamperowym ;) ? A jak zasilanie siądzie? Masz tam podpięty akumulator, jeżeli tak to jak rozwiązałeś jego ładowanie?

    Maciek.
  • Optex
  • #3
    Duch__
    Level 31  
    Jak wyżej. Gdzie zasilanie awaryjne na wypadek odcięcia zasilania, gdzie zabezpieczenie przeciwzwarciowe, a o liniach parametrycznych 2EOL/NC lub NO, ew. 3EOL/NC lub NO nie wspomnę. Co ci po sygnalizatorze, ściągam obudowę, może zawyje alarm bo będziesz miał linie sabotażową włączoną, ale robię zwarcie i alarm robi sssss..... i przechodzę do buszowania w twoim domu.

    W przypadku linii parametrycznej jesteś w stanie na dwóch żyłach zidentyfikować następujące zdarzenia:

    Dla 2EOL:
    1 - stan prawidłowy (linia nienaruszona)
    2 - stan alarmowy (linia naruszona)
    3 - stan zwarcia na linii
    4 - uszkodzenie przewodu

    Dla 3EOL:
    to co wyżej plus:
    5 - obsługa czujników z dwoma sensorami np. PIR + AM (detekcja zasłonięcia czujki)

    Jak z przeglądem zdarzeń? Jesteś w stanie odczytać która czujka wzbudziła alarm? Jeśli nie to życzę powodzenia jak ci zaczną walić alarmy i nie będziesz wstanie zlokalizować z której czujki.

    Gratuluję projektu, ale wymaga on dopracowania.
  • #4
    krzysztofh
    Level 29  
    Jeżeli ten projekt ma na celu ochronę określonego obiektu to pierwotny pomysł z klawiaturą był lepszym rozwiązaniem.
    Czytniki RFID są stosowane przede wszystkim w systemach kontroli dostępu, gdzie jest wielu użytkowników i ochrona obiektu.
    W przypadku alarmu domku jednorodzinnego najbezpieczniejszym rozwiązaniem jest uzbrajanie i rozbrajanie systemu z klawiatury. Pastylkę mogą Ci ukraść i łatwo dostać się do obiektu. To trochę tak jakby na karcie kredytowej napisać pin. Stosowanie do tego celu pilotów ma też ograniczone zastosowanie i nie powinno powodować załączania i wyłączania systemu, co najwyżej wywoływać zwłokę pozwalającą na rozbrojenie systemu w sytuacji kiedy konieczne jest naruszenie strefy chronionej przez rozbrojeniem systemu.
  • #5
    kolgreen
    Level 16  
    Panowie, dziękuję za ostre uwagi :).

    Faktycznie, biję się w piersi - zabezpieczenia przeciwzwarciowego brak.
    W następnej wersji muszę to naprawić.

    Tak, znam linie parametryczne i przyznam, że świadomie z nich zrezygnowałem.
    Linia parametryczna to trochę epoka kamienia łupanego moim zdaniem. W dodatku
    możliwy jest sabotaż. Główne nadzieje pokładam w CAN. Na upartego można cały budynek
    zrobić na czterech drutach. Ba, nawet różne strefy na tym samym kablu.
    Jak to w przypadku linii parametrycznych wygląda wiecie...
    W przypadku urządzeń na CAN mamy praktycznie dowolną ilość stanów a nie jak to ma miejsce w przypadku 3EOL (5 stanów). Dodatkowo dane otrzymane z czujek
    można użyć do sterowania oświetleniem, ogrzewaniem i wieloma innymi... Wszystko (na upartego) na jednym kablu.
    Co do zwarcia na CAN, czy też przerwaniu CAN. Rozwiązanie bardzo proste, czujki są "pingowane", brak odpowiedzi przy uzbrojonym alarmie skutkuje wiadomo czym.

    Co do zasilania. Ponieważ centralka będzie na szynie DIN razem z kilkoma innymi aparatami
    (switche, zasilanie itp.), ma tylko doprowadzenie zasilania. Całą resztą zajmują się inne urządzenia.


    Atreyu wrote:

    Przekaźnik do sterowania syreny? Dwudziestoamperowy ? Czy ta syrena jest z silników od pralki frania, a może od młockarni ? Przecież tam by wystarczył zwykły bipolar do powiedzmy kilku amperów, powyżej FET mocy albo specjalizowany power switch. Poza tym jedna linia sygnalizatora akustycznego?
    (...)
    Jak rozumiem zasilasz to jakimś zasilaczem, dwudziestoamperowym ;) ? A jak zasilanie siądzie? Masz tam podpięty akumulator, jeżeli tak to jak rozwiązałeś jego ładowanie?


    Kolego Maćku, szanuję za wiedzę, ale powyższy sarkazm potępiam. Tego typu posty tworzą niepotrzebnie (szeroko znany) "klimat" Elektrody.
    Zapewniam kolegę, że syrena nie jest z silnika od pralki marki "Frania", jednak posiadam kompresor i zestaw trąbek od tira. Zastanawiam się, czy owy przekaźnik wystarczy (podobnie jak i szerokość ścieżek) :D .

    Atreyu wrote:
    Czemu nie ma osobnej linii do sygnalizatora optycznego?

    Jest dodatkowe wyjście (PWM) - używałem nawet jako audio. Taki pre-alarm w postaci szczekającego psa. :D
    Swobodnie można podawać tam sygnał sterujący sygnalizatorem optycznym.
    Jednak podobnie jak i w przypadku czujek zastanawiam się nad CAN.

    Dodano po 7 [minuty]:

    krzysztofh wrote:
    Jeżeli ten projekt ma na celu ochronę określonego obiektu to pierwotny pomysł z klawiaturą był lepszym rozwiązaniem.
    Czytniki RFID są stosowane przede wszystkim w systemach kontroli dostępu, gdzie jest wielu użytkowników i ochrona obiektu.


    Zgadza się, ja jednak zdecydowałem się na RFID. Można oczywiście do systemu podłączyć klawiaturę w dowolnej chwili. Zrezygnowałem z kilku przyczyn;
    -czytnik ukryty pod elewacją jest bardziej estetyczny niż klawiatura,
    -nie znalazłem ładnej klawiatury w rozsądnej cenie,
    -trudno zrobić ładną klawiaturę, tanio,
    -nigdy nie używałem RFID w swoich konstrukcjach i chciałem go poznać.

    Dodano po 5 [minuty]:

    Duch__ wrote:

    Jak z przeglądem zdarzeń? Jesteś w stanie odczytać która czujka wzbudziła alarm? Jeśli nie to życzę powodzenia jak ci zaczną walić alarmy i nie będziesz wstanie zlokalizować z której czujki.


    Ten etap mam niezaimplementowany ale jest to oczywiście przewidziane.
    Ponieważ każde urządzenie pracujące na CAN może mieć swój unikalny adres (lub należeć do grupy urządzeń o tym samym adresie), jestem w stanie dokładnie określić
    która czujka wzbudziła alarm. W tym celu również znajduje się RTC, by zapisać
    dokładne dane o czasie.
    Dane będą odczytywane za pomocą komputera (mam most CAN-Ethernet)
    lub w przyszłości za pomocą jakiegoś ekranika sterującego resztą automatyki.

    Duch__ wrote:
    Gratuluję projektu, ale wymaga on dopracowania.

    Bardzo dziękuję, zgadza się.
  • #6
    Atreyu
    Level 22  
    kolgreen wrote:
    Faktycznie, biję się w piersi - zabezpieczenia przeciwzwarciowego brak.
    W następnej wersji muszę to naprawić.

    Proponuję wykonać porty zasilania zewnętrznych urządzeń (tyle portów ile urządzeń) z zabezpieczeniem zwarciowym lub alarmem sabotażowym w wypadku zwarcia (+ logowanie triggera błędu w logu centrali)

    kolgreen wrote:
    Co do zwarcia na CAN, czy też przerwaniu CAN. Rozwiązanie bardzo proste, czujki są "pingowane", brak odpowiedzi przy uzbrojonym alarmie skutkuje wiadomo czym.

    Co będzie jak intruz podepnie analizator interfejsu CAN w DOWOLNYM miejscu sieci? Czy nie będzie aby w stanie zasymulować odpowiedzi dowolnego czujnika? Przez magistrale CAN będzie to znacznie łatwiejsze niż przy analogowych liniach parametrycznych które idą do każdego czujnika :) Poza tym nie spotkałem w handlu czujek PIR CANBUS, musiał byś w każdą czujkę wstawiać swój układ enkodera CAN. Wydaje mi się że w tym wypadku CAN będzie piętą Achillesową tego rozwiązania.

    kolgreen wrote:
    Kolego Maćku, szanuję za wiedzę, ale powyższy sarkazm potępiam. Tego typu posty tworzą niepotrzebnie (szeroko znany) "klimat" Elektrody.
    Zapewniam kolegę, że syrena nie jest z silnika od pralki marki "Frania", jednak posiadam kompresor i zestaw trąbek od tira. Zastanawiam się, czy owy przekaźnik wystarczy (podobnie jak i szerokość ścieżek) .

    Faktycznie może przesadziłem, ale mnie poniosło. Nadal jednak uważam że przekaźnik jest anachronizmem który powinien być stosowany tylko w bardzo ograniczonej liczbie przypadków. Tak jak pisałem na tranzystorze można śmiało zrealizować f-cję włączania syrenki (bo, jak sądzę, w grę wchodzą współczesne piezosygnalizatory). Jak chcesz nowocześniejsze rozwiązanie to proponuję np. 4 porty (dwa alarmu akustycznego i dwa optycznego) sterowane poprzez specjalizowane przełączniki BTS117 Infieona.

    kolgreen wrote:
    ja jednak zdecydowałem się na RFID

    RFID ewentualnie mogło by być do zmiany statusu strefy instalacji szyfratora z natychmiastowej na zwłoczną i tylko w takim wypadku. Sam szyfrator "klawiaturowy" jest niezbędny.

    kolgreen wrote:
    Jest dodatkowe wyjście (PWM) - używałem nawet jako audio. Taki pre-alarm w postaci szczekającego psa.

    Pre-alarm w postaci buzzera na PCB alarmu jak już ;) Sygnalizator optyczny powinien być stosowany do sygnalizacji zadziałania alarmu lub naruszenia sabotażu po ustąpieniu alarmu akustycznego.

    Maciek.
  • #7
    Alpha
    Level 24  
    Atreyu wrote:

    Nie widać tu żadnych elementów zabezpieczających transoptor! Na biurku w warunkach warsztatowych na pewno działa to poprawnie. Po podpięciu 10m przewodu do czujki już widzę jak będziesz wymieniał kolejne transoptory. Przerabiałem dokładnie to samo z PC847 ;)
    Maciek.


    Zainteresował mnie Kolega tą uwagą. Można prosić o więcej informacji nt. przyczyn uszkodzeń oraz sposobów przeciwdziałania im?
  • #8
    Atreyu
    Level 22  
    Geneza uszkodzeń diod transoptorów w układach tego typu jest identyczna jak i w wypadku sterowania pracy przekaźnika poprzez półprzewodnik. Duża indukcyjność, którą jest pętla przewodu linii, po przerwaniu obwodu powoduje zaindukowanie się SEM o wektorze przeciwnym do kierunku przepływu prądu. Zaindukowane napięcie po rozwarciu linii z łatwością przekracza maksymalne napięcie wsteczne transoptora, które najczęściej wynosi kilka woltów. Najprostszy sposób eliminacji tego zjawiska jest praktycznie taki sam jak w wypadku przekaźnika: równolegle do emitera IR w transoptorze należy dołączyć w miarę szybką, spolaryzowaną zaporowo, diodę małej mocy.

    Osobiście bym jednak zalecał wykonanie takiego najprostszego portu nieco bardziej "ostrożnie" np. do każdego wypr. śrubowego podpinamy rezystory o oporności 1/2 wyliczonego ograniczenia prądu transoptora. Za nimi (równolegle do rezystorów dajemy kondensator ceramiczny 10nF/2kV, i równolegle do niego transil 30V. Na końcu wystarczy dioda np. 1N4148 równolegle do samego transoptora, oczywiście w polaryzacji zaporowej.
  • #9
    Sabre
    Level 18  
    Atreyu wrote:
    śrubowego podpinamy rezystory o oporności 1/2 wyliczonego ograniczenia prądu transoptora. Za nimi (równolegle do rezystorów dajemy kondensator ceramiczny 10nF/2kV, i równolegle do niego transil 30V. Na końcu wystarczy dioda np. 1N4148 równolegle do samego transoptora, oczywiście w polaryzacji zaporowej.


    Nie wiem jak autor wątku, ale ja z tego opisu, oprócz ostatniego zdania, nic nie zrozumiałem. Chyba najlepiej będzie jak narysujesz schemat, bo to co do czego ma być równolegle a co szeregowo to tylko obrazek może wyjaśnić. Pytam bo niedługo sam będę robił coś podobnego i chcę zabezpieczyć transoptor przed uszkodzeniem. Dlaczego napisałeś żeby dać rezystor wyliczony na 1/2 ograniczenia prądowego? I jak taki filtr będzie wpływał na przesył danych linią z prędkością około 800 kbps?
  • #10
    Atreyu
    Level 22  
    Sabre wrote:
    Dlaczego napisałeś żeby dać rezystor wyliczony na 1/2 ograniczenia prądowego?

    Przeczytaj raz jeszcze co powyżej napisałem.

    Atreyu wrote:
    do każdego wypr. śrubowego podpinamy rezystory o oporności 1/2 wyliczonego ograniczenia prądu transoptora

    Moja propozycja naprostszego obwodu wejściowego NC/NO:

    Alarm, czytnik RFID - komunikacja CAN

    Sabre wrote:
    I jak taki filtr będzie wpływał na przesył danych linią z prędkością około 800 kbps

    Tego nie jestem w stanie określić z powodu zbyt dużej liczby zmiennych które trzeba uwzględnić przy transferze danych. Na pewno dobór odpowiedniego transila oraz kondensatora będzie tu kluczowy. Moja propozycja dotyczyła klasycznych linii NC/NO ew. parametrycznych, ale te ostatnie przy zmianie transoptora na model z wyprowadzoną bazą tranzystora wykonawczego.

    Pozdrawiam. . .
  • #11
    Sabre
    Level 18  
    @Atreyu czytałem kilkukrotnie, ale nie widzę nigdzie w twoich postach wyjaśnienia tego. Osobiście dałbym rezystor dobrany na prąd nominalny diody, nie na minimalny prawidłowej pracy transoptora.
  • #12
    Atreyu
    Level 22  
    Dobra, wyjaśnienie łopatologiczne: dobieramy prąd diody nadawczej na podstawie obliczonego prądu C-E według charakterystyki z datasheet'a, dodajemy +10% na wszelki wypadek. Zakładamy że wyjdzie nam na przykład 5000Ω. Dzielimy wynik na pół i uzyskujemy 2500Ω. Dobieramy najbliższą wartość z najpopularniejszego obecnie szeregu E24 i mamy 2,4kΩ i DWA takie rezystory montujemy do zacisków liniowych jak na schemacie powyżej.
  • #13
    Sabre
    Level 18  
    W takim razie mnie to nie dotyczy, mam transoptor z wyjściem cyfrowym.
  • #14
    Ayost
    Level 12  
    Mógłbyś napisać coś więcej o odtwarzaniu nagranego dźwięku z pamięci mikrokontrolera?
  • #15
    kolgreen
    Level 16  
    Ayost wrote:
    Mógłbyś napisać coś więcej o odtwarzaniu nagranego dźwięku z pamięci mikrokontrolera?


    Była to dość prosta konstrukcja działająca w oparciu o PWM.
    Więcej informacji o tym rozwiązaniu znajdziesz w tym artykule.

    Generalnie sprowadziło się to do opracowania programu konwertującego plik WAV do wartości które można podać na PWM. Napisałem program w oparciu o kod opublikowanym w sierpniu 2007 roku przez João Figueiredo który konwertuje plik
    WAV wprost do postaci pliku nagłówkowego w języku C.

    Wygenerowany plik ma postać:
    Code: c
    Log in, to see the code

    Oczywiście tablica zwykle jest nieco większa, a nazwa zmiennej pokrywa się z nazwą pliku WAV.
    Program udostępniłem w postaci instalacyjnej paczki DEB dla systemu operacyjnego Linux Debian (bądź alternatywnie Ubuntu).

    W języku CCS dla mikrokontrolerów PIC kod funkcji "odtwarzającej" ma postać:
    Code: c
    Log in, to see the code


    Głośnik (a raczej wzmacniacz) był bezpośrednio podłączony do PWM. Działało, lecz
    oczywiście należałoby zastosować kondensator/filtry.

    Jest to dobre rozwiązanie dla prostych melodyjek ;), odtwarzanie kilku sekund mowy też jest możliwe (choć jakość odtwarzanego dźwięku jest dyskusyjna).