Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Kategoria: Kamery IP / Alarmy / Automatyka Bram
Montersi
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Bluetooth - przechowanie kilku adresów MAC w pamięci

Jakub17 12 Sie 2017 14:13 492 25
  • #1 12 Sie 2017 14:13
    Jakub17
    Poziom 6  

    Witam.

    Posiadam moduł BTM222, zaprogramowałem go komendami AT tak aby łączył się z urządzeniem którego adres MAC przechowuje w pamięci (bodajże za sprawą komendy ATD można tak zrobić). Niestety moduł jest w stanie przechowywać tylko jeden adres MAC. Czy ktoś zna jakieś moduły które mogą przechowywać kilka adresów MAC tak aby łączyły się z urządzeniem które aktualnie znajduje się w ich pobliżu i ma adres MAC taki sam jak zapisany w pamięci modułu?

  • #5 12 Sie 2017 16:42
    Jakub17
    Poziom 6  

    Tzn. z poziomu programu mikrokontroler wysle komende AT w celu wyszukania okolicznych urzadzen bluetooth a pozniej wysle kolejna komende w celu polaczenia sie z urzadzeniem o konkretnym adresie? Ggdzies czytalem ze lepiej nie programowac bluetooth z poziomu uC

  • #6 12 Sie 2017 17:34
    dondu
    Moderator Mikrokontrolery Projektowanie

    Komendy AT są po to, by ich używać.
    Dodatkowo należy postawić pytanie, z którym urządzeniem ma się połączyć mikrokontroler z BTM jeśli dwa będą w zasięgu?
    Algorytm wyszukiwania i łączenia zależy od możliwości modułu, a oprogramowujesz go w mikrokontrolerze.

  • #8 12 Sie 2017 20:28
    TvWidget
    Poziom 29  

    W BT2.1 trzeba pamiętać pary: MAC i klucz ustanowiony podczas parowania. Cześć modułów ma rozkazy do odczytanie/zapisane klucza. Tak więc nie jest konieczne aby moduł pamiętał potrzebne informacje. Może to robić uP.
    W BLE (BT.4.0) nie ma parowania i nie ma ograniczenia o jakim wspominasz. Co więcej jednocześnie można utrzymywać kilka połączeń z różnymi urządzeniami. Niewielkie ilości danych daje się przesyłać bez nawiązywania połączenia.

  • #9 12 Sie 2017 21:46
    Jakub17
    Poziom 6  

    Jeśli chodzi o BT 4.0 to moduł przesyła po prostu dane do urządzeń o adresach MAC które zostały wcześniej zapisane w jego pamięci, bez parowania tak jak mówisz? Z drugiej strony zależy mi aby w danej chwili przesyłało tylko 1 urządzenie bluetooth spośród tych których adres jest zapisany, które mogą być sparowane. Po prostu "kto pierwszy ten lepszy" byle było to jedno urządzenie na raz i z listy zapisanych adresów MAC

  • #10 12 Sie 2017 22:14
    TvWidget
    Poziom 29  

    Jakub17 napisał:
    Jeśli chodzi o BT 4.0 to moduł przesyła po prostu dane do urządzeń o adresach MAC które zostały wcześniej zapisane w jego pamięci, bez parowania tak jak mówisz?

    W BLE jedno z urządzeń "A" stale się rozgłasza (zwykle co 0.3 .. 10 sek.). Druga strona "B" odbiera te pakiety rozgłoszeniowe i np. przez UART przesyła je do uC. Taki pakiet zawiera adres MAC i ew. jakieś dodatkowe dane.
    uC wysyła do "B" rozkaz nawiązania połączenia z urządzeniem o określonym adresie MAC. "B" czeka na pakiet zawierający ten MAC. Jeśli go odbierze to w ciągu kilku mS nawiązywane jest połączenie.
    Moduł nie pamięta więc żadnych adresów MAC.

  • Pomocny post
    #12 13 Sie 2017 07:58
    TvWidget
    Poziom 29  

    Z formalnego punktu widzenia standard BT4.0 obejmuje wszytko co było w BT2.1 i kilka dodatków np. BLE. Potocznie moduły obsługujące BLE określa się jako BT4.0. Tylko niewielka ich część jest rzeczywiście "dual mode". Większość obsługuje wyłącznie BLE.

    Od strony sprzętowej każdy moduł BLE musi realizować co napisałem wcześniej. Rzeczywisty sposób działania określa jednak firmware jaki został wpisany do uP znajdującego się w module.
    Część modułów sprzedaje się bez żadnego programu. Ze względu na specyficzny sposób działania BLE sterowanie przy pomocy komend AT nie jest wygodne. Czasem się je implementuje ale wprowadza to wiele ograniczeń. W PC, tabletach itp. stosuje się moduły z uniwersalnym protokołem HCI (w praktyce umożliwia wszystko). Opis tego standardu to kilka tysięcy stron. Do pełnej obsługi BLE wystarczy jednak chyba tylko 8 prostych rozkazów HCI.

    Często sprzedaje się moduły z firmware dedykowanym do określonych zastosowań
    Takie najłatwiej użyć. Najczęściej nie jest potrzebny nawet zewnętrzny uP. Wszytko co potrzeba realizuje sam moduł.

  • #13 13 Sie 2017 18:38
    Jakub17
    Poziom 6  

    Czyli podsumowując:

    BLE (moja baza) rozsyła pakiety danych do różnych urządzeni bluetooth w okolicy (nie koniecznie w wersji BT 4.0, tak?). Te urządzenia w odpowiedzi na ten pakiet wysyłają swój adres MAC do modułu - bazy. Mikrokontroler może sprawdzić jakie adresy otrzymał przez moduł - bazę i wybrać z jakim adresem chce się połączyć. Wydaje rozkaz modułowi - bazie, ten wysyła rozkaz nawiązania połączenia z innym modułem - slavem. Jeśli slave odbierze ten rozkaz to zaistnieje połączenie, tak?

    Mówisz że stosowanie komend AT w BLE jest niewygodne, ale to znaczy że on w domyślnym trybie pracy rozsyła te pakiety danych do wszystkich urządzeń czy trzeba go jakoś zaprogramować?

    Nada się do tego taki moduł:

    https://botland.com.pl/moduly-bluetooth/4505-core51822-ic-test-board.html

    Albo taki z aliexpress:

    https://pl.aliexpress.com/item/AT-09-Android-...d7-4b2b-a29e-9e2349ea6a6c&transAbTest=ae803_1

  • #14 13 Sie 2017 20:02
    TvWidget
    Poziom 29  

    Nieco upraszczając urządzenia BLE dzielą się na dwie grupy:
    - rozgłaszające się (pobierają znikomo mało prądu)
    - skanujące (w czasie skanowania pobór prądu wzrasta do ~20mA jest to 1000 razy więcej niż potrzeba do rozgłaszania).

    Tylko urządzenie "skanujące" może nawiązać połączenie z rozgłaszającym się. Z tego co napisałeś wynika, że baza powinna pracować w trybie skanowania.

    Tak jak już wcześniej napisałem urządzenia rozgałszające wysyłają okresowo pakiet zawierający między innym adres MAC. Dodatkowo może on zawierać też inne dane np. identyfikator UUID, przyjazną nazwę, napięcie baterii, temperaturę, stan podłączonych czujników itp. W celu oszczędności energii dąży się do tego aby ten podstawowy pakiet rozgłoszeniowy był możliwe krótki.
    Skanowane może być pasywne lub aktywne. W tym drugim przypadku wymusza się na urządzeniu rozgłaszajacym wysłanie dodatkowych pakietów zawierających więcej informacji. Czyli jeśli nikt nie słucha to wysyłany jest tylko krótki pakiet. Jeśli ktoś skanuje to wysyłane jest więcej informacji.

    W BLE adresy MAC mogą być statyczne lub dynamiczne (ochrona prywatności). Tak więc nie w każdym przypadku daje się zidentyfikować urządzenie po adresie MAC. Do tego służy np. identyfikator UUID, nazwa lub inne dane. Do fizycznego nawiązywania połączenia zawsze jednak używa się adresu MAC.

    Rozkazy AT to wysłanie komendy i odpowiedź na nią. W przypadku BLE występują głównie asynchroniczne zdarzenia. Nie pasuje to do idei komunikacji rozkaz-odpowiedź. Zamienianie wielu parametrów na postać tekstową i odwrotnie nie jest też wygodne.

  • #15 13 Sie 2017 21:43
    Jakub17
    Poziom 6  

    TvWidget napisał:
    Nieco upraszczając urządzenia BLE dzielą się na dwie grupy:
    - rozgłaszające się (pobierają znikomo mało prądu)
    - skanujące (w czasie skanowania pobór prądu wzrasta do ~20mA jest to 1000 razy więcej niż potrzeba do rozgłaszania).

    Czyli de facto muszę kupić dwa różne moduły? Jeden do rozgłaszający a drugi skanujący czy ta funkcjonalność jest skupiona w jednym rodzaju modułu tylko wymaga odpowiedniego przeprogramowania? Czyli stary poczciwy HC05 w standardzie BT 2.0 da rade w roli rozgłaszającego? Gdzieś mi się obiło o uszy na forum że standard BT 4.0 jest kompatybilny wstecz ale nie wiem czy to prawdziwa informacja.


    TvWidget napisał:

    Rozkazy AT to wysłanie komendy i odpowiedź na nią. W przypadku BLE występują głównie asynchroniczne zdarzenia. Nie pasuje to do idei komunikacji rozkaz-odpowiedź. Zamienianie wielu parametrów na postać tekstową i odwrotnie nie jest też wygodne.


    To programowanie odbywa się normalnie przez terminal tak? Możesz podać jakieś konkretne modele modułów z których korzystałeś? Jestem kompletnie zielony w temacie a chciałbym zacząć od czegoś co najpierw mi zadziała w 100% żeby się w tym nie pogubić.
    Te moduły których liniki podesłałem będą ok?

    Jednak znalazłem tutaj coś, że można programować te moduły za pomocą komend AT

    https://docs.google.com/document/d/14mHWT3GhELCj-6yxsam0k5bjzazq8nnPoz4B_gYh04k/edit

  • #16 13 Sie 2017 23:19
    TvWidget
    Poziom 29  

    Standard BT4.0 jest kompatybilny w wstecz. Nie oznacza to jednak, że moduł BLE skomunikuje się z HC05.
    Tanie moduły to jedynie sprzęt. Nie mają żadnego firmware lub zawierają tylko jakiś testowy program. Czyli inaczej mówiąc kupujesz niezaprogramowany uP zwykle bez nadanego adresu MAC. Program musisz napisać we własnym zakresie. Wymaga to odpowiednich narzędzi, wiedzy itd. Zdecydowanie nie jest to zadanie dla początkującego elektronika.
    Są dostępne też moduły z dedykowanym firmware do jakiś konkretnych zastosowań. Często nie wymagają nawet zewnętrznego uP
    Napisz może co dokładnie chcesz zrobić na tych modułach BT.

  • #17 14 Sie 2017 08:06
    Jakub17
    Poziom 6  

    Mam napisany program do sterowania drzwiami za pomocą elektronicznego klucza (atmega8) który na zapytanie wysłane z bazy (atmega32,) wysyła zaszyfrowany ciąg znaków. Klucze w postaci ciagu znakow moga byc wgrywane przez karte SD. Mógłbym za pomocą tej karty wgrywać również adresy MAC. Wszystko działa, problem jedynie w tym - tak jak pisałem na początku tematu - że bluetooth w bazie przechowuje 2 adres MAC a chce zeby drzwi byly otwierane z jednego z kilku przypisanych do drzwi kluczy.

    No więc chyba jedynym rozwiązaniem jest użycie BLE i wgranie uprzednio do uP adresow MAC ktore beda porownywane z tym.co zeskanował BLE (mam nadzieje ze skanowanie trwa o wiele szybciej niz w BT 2.0 bo nie moge czekac kilku sekund) a nastepnie nawiązywane bedzie połaczenie z pierwszym pasujacym slavem. Musze tylko konkretnie wiedziec jakie modele BLE kupic, bo jako poczatkujacy wykonczyć mnie moze byle problem związany z brakiem komunikacji bo się na tym nie znam i spędze dlugie godziny na szukaniu problemow... Dlatego prosiłbym abyś mi coś polecił konkretnego do zakupu do tego zadania. Od tego mogłbym zacząć dalszą naukę

  • #18 14 Sie 2017 09:20
    TvWidget
    Poziom 29  

    W BLE nie ma czegoś takiego jak bezprzewodowy UART znany z BTM222. Wysyłanie/odbieranie danych polega na zapisie/odczycie danych do/z tzw. charakterystyki. Tych charakterystyk jest zwykle wiele. Każda ma swój unikalny identyfikator. Jest to coś podobnego do zestawu rejestrów procesora.
    Bezprzewodowy UART można jedynie emulować. Zapis do jakieś charakterystyki spowoduje wywołanie zdarzenia. W obsłudze tego zdarzenia będzie procedura powodująca wysłanie zapisanych znaków przez port UART.


    Chyba wysyłałem kiedyś na PW informacje o modułach BLE dedykowanych do automatycznego otwierania zamków.
    Działają one w nieuproszeniu tak:
    Klucz okresowo wysyła swój identyfikator.
    Zamek wykrywa obecność klucza w określonej odległości.
    Zamek nawiązuje połączenie z kluczem i wysyła do niego losowy ciąg.
    Klucz szyfruje ten ciąg przy pomocy algorytmu AES128 i odsyła wynik.
    Podobną operację szyfrowania przeprowadza zamek.
    Jeśli oba ciągi są zgodne to otwierane są drzwi. Zgodnie z podstawową zasadą bezpieczeństwa hasła używane do szyfrowania AES128 nie są przesyłane w żadnej postaci.

    Zwróć uwagę, że dedykowany firmware znajdujący np. w module pełniącym rolę klucza realizuje wszytko co potrzeba. Nie jest konieczny dodatkowy procesor. Oprogramowanie jest zoptymalizowane pod względem poboru prądu. Mała bateria CR2032 wystarczy na kilka miesięcy pracy.
    Zrealizowanie podobnej funkcjonalności modułach BLE emulujących bezprzewodowy UART
    i dodatkowym uP jest oczywiście możliwe. Nie osiągniesz jednak odpowiednio małego poboru prądu.

  • #19 14 Sie 2017 18:37
    Jakub17
    Poziom 6  

    TvWidget napisał:

    Zamek nawiązuje połączenie z kluczem i wysyła do niego losowy ciąg.
    Klucz szyfruje ten ciąg przy pomocy algorytmu AES128 i odsyła wynik.


    Zatrzymałem się na tym etapie. Masz jakieś przykładowy kod który wykonuje te czynności tzn. nawiązuje połączenie i wysyła dane. Jeżeli to nie jest przez UART to nie wiem jak to oprogramować w mikrokontrolerze.

    Druga sprawa:
    TvWidget napisał:

    Zwróć uwagę, że dedykowany firmware znajdujący np. w module pełniącym rolę klucza realizuje wszytko co potrzeba. Nie jest konieczny dodatkowy procesor.


    Czyli kupie po prostu moduł BLE i on będzie szyfrował automatycznie wysyłane dane. To moduł w "bazie" będzie umiał sam je zdekodować? Proszę podaj jakieś przykłady konkretnych popularnych modeli takich modułów.

    Dodano po 6 [godziny] 53 [minuty]:

    Coś poczytałem i dowiedziałem sie ze te charakterystyki obsluguje sie za pomoca jakis funkcji callback. Jak sie tego uzywa w BLE?

  • #20 14 Sie 2017 19:32
    TvWidget
    Poziom 29  

    Jakub17 napisał:

    Jeżeli to nie jest przez UART to nie wiem jak to oprogramować w mikrokontrolerze


    Załóżmy, że mamy moduł BLE użyty po stronie zamka sterowany przez UART komendami HCI.
    Najczęściej używane są następujące rozkazy:
    - włączenie skanowania
    - wyłączenie skanowania
    - żądanie nawiązania połączenia z urządzeniem o określonym adresie MAC
    - żądanie rozłączenia
    - żądanie odczytania charakterystyki lub deskryptora wg. UUID
    - żądanie odczytania charakterystyki lub deskryptora wg. uchwytu
    - żądanie zapisu charakterystyki lub deskryptora wg. uchwytu

    Najłatwiej zrozumieć jak działa BLE porównując to co jest widoczne od strony radiowej do struktury procesora.
    Procesor ma zwykle jakieś układy peryferyjne np. UART, PIO, I2C, DMA itp. Każdy taki element ma zestaw rejestrów. Dany rejestr można zapisać lub odczytać. Są też rejestry przeznaczone tylko do zapisu lub tylko do odczytu. Pisząc program posługujemy się zwykle symboliczną nazwą. Rejestr poza nazwą symboliczną ma też jakiś fizyczny adres.

    Od strony radiowej moduł rozgłaszający się udostępnia zestaw serwisów. Dany serwis zawiera zwykle jakieś charakterystyki. Serwisy i charakterystyki mają swoje identyfikatory UUID. Mają też fizyczne uchwyty
    Serwis w BLE można porównać do układu peryferyjnego, charakterystykę do rejestru, UUID do nazwy symbolicznej a uchwyt do fizycznego adresu.

    W przypadku modułu realizującego funkcjonalność bezprzewodowego klucza trzeba przez radio do określonej charakterystyki zapisać losowy ciąg (16 bajtów) a następnie odczytać wynik szyfrowania (16 bajtów).
    Konfiguracja modułu tzn. wpisane hasła, nadanie nazwy, określenie mocy nadajnika, częstotliwości rozgłaszania i wielu innych parametrów obywa się się przez BLE. Służy do tego specjalny program na PC.
    Interfejs UART tu nie jest używany.


    HCI to protokół binarny a nie znakowy jak w przypadku rozkazów AT.
    Poniżej przykład połaczenia z urządzeniem 0x00126f35607a i odczytanie charakterystyki 0x2a07 (TX_POWER_LEVEL).

    UART_TX: 010D20 19 5802 9001 00 00 7A60356F1200 00 0600 0600 0100 3C00 0000 0000
    01 -> (HCI packet indicator: CMD) -> (Core_V4.0.pdf: Volume 2 Part E, Section 5.4)
    0D20 -> 0x200D (HCI op_code 16 bitów: OCF:10 najmłodszych bitów OGF:6 najstarszych bitów) OCF: 0x0D oGF:0x08 -> HCI_LE_Create_Connection: (Core_V4.0.pdf: Volume 2 Part E, Section 7.8.12)
    19 -> 0x19=25 (HCI parameter total length: 25 bajtów)
    5802 -> 0x0258=600 (LE_Scan_Interval) -> Time = 600 * 0.625 msec = 375 msec
    9001 -> 0x0190=400 (LE_Scan_Window) -> Time = 400 * 0.625 msec = 250 msec
    00 -> 0x00 (Initiator_Filter_Policy) -> White list is not used to determine which advertiser to connect to. Peer_Address_Type and Peer_Address shall be used.
    00 -> 0x00 (Peer_Address_Type) -> Public Device Address
    7A60356F1200 -> 0x00126f35607a (Peer_Address)
    00 -> 0x00 (Own_Address_Type) -> Public Device Address
    0600 -> 0x0006=6 (Conn_Interval_Min) -> Time = 6 * 1.25 msec = 7.5 msec
    0600 -> 0x0006=6 (Conn_Interval_Max) -> Time = 6 * 1.25 msec = 7.5 msec
    0100 -> 0x0001=1 (Conn_Latency)
    3C00 -> 0x003C=60 (Supervision_Timeout) -> Time = 60 * 10 msec = 600 msec
    0000 -> 0x0000=0 (Minimum_CE_Length)
    0000 -> 0x0000=0 (Maximum_CE_Length)

    UART_RX: 040F0400010D20
    04 -> (HCI packet indicator: EVENT) -> (Core_V4.0.pdf: Volume 2 Part E, Section 5.4)
    0F -> event_code = 0x0f -> Command Status: (Core_V4.0.pdf: Volume 2 Part E, Section 7.7.15)
    04 -> 0x04=4 (HCI parameter total length=4)
    00 -> 0x00 (Status) -> Command currently in pending.
    01 -> 0x01 (Num_HCI_Command_Packet) -> The Number of HCI command packets which are allowed to be sent to the Controller from the Host.
    0D20 -> 0x200D (Command_Opcode) -> Opcode of the command which caused this event and is pending completion.

    UART_RX: 043E1301000C0000007A60356F1200060001003C0000
    04 -> (HCI packet indicator: EVENT) -> (Core_V4.0.pdf: Volume 2 Part E, Section 5.4)
    3E - event_code = 0x3e -> LE EVENT
    13 - 0x13=19 (HCI parameter total length=19)
    01000C0000007A60356F1200060001003C0000 -> event parameters:
    01 - Subevent_Code = 0x01 -> LE Create Connection Complete event
    00 - Status = 0x00 -> Connection successfully completed.
    0C00 - Connection_Handle = 0x000C -> Connection_Handle to be used to identify a connection between two Bluetooth devices. The Connection_Handle is used as an identifier for transmitting and receiving data.
    Trzeba koniecznie używać tej wartości przy dalszej komunikacji (Jest to identyfikator połączenia).
    00 - Role = 0x00 -> Connection is master
    00 - Peer_Address_Type = 0x00 -> Peer is using a Public Device Address
    7A60356F1200 - Peer_Address = 0x00126f35607a
    0600 - Conn_Interval = 0x0006=6 -> Time = 6 * 1.25 msec = 7.5 msec; Connection interval used on this connection.
    0100 - Conn_Latency = 0x0001=1 -> Connection latency for this connection.
    3C00 - Supervision_Timeout = 0x003C=60 -> Time = 60 * 10 msec = 600 msec; Connection supervision timeout.
    00 - Master_Clock_Accuracy = 0x00 -> 500 ppm

    UART_TX: 020C00 0700 08 0100 FFFF 072A
    02 -> (HCI packet indicator: ACL DATA) -> (Core_V4.0.pdf: Volume 2 Part E, Section 5.4)
    0C00 -> handle = 0x000C -> musi mieć taką samą wartość jak w LE Create Connection Complete event
    0700 -> length = 0x0007 -> Data Total Length = 7 bajtów
    08 0100 FFFF 072A -> Data:
    08 -> PDU Attribute Op Code = 0x08 -> Read By Type Request (Core_V4.0.pdf: Volume 3 Part F, Section 3.4.4.1)
    0100 -> Starting Handle = 0x0001
    FFFF -> Ending Handle = 0xFFFF
    072A -> Attribute Tybe (2 or 16 octet UUID) = 0x2A07

    Ponieważ nie znamy numeru uchwytu do charakterystyki 0x2A07 posługujemy się jej UUID.

    UART_RX: 020C0006000904290008AE
    02 -> (HCI packet indicator: ACL DATA) -> (Core_V4.0.pdf: Volume 2 Part E, Section 5.4)
    0C00 -> handle = 0x000C
    0600 -> length = 0x0006 -> Data Total Length = 6 bajtów
    0904290008AE -> Data:
    09 -> PDU Attribute Op Code = 0x09 -> Read By Type Response (Core_V4.0.pdf: Volume 3 Part F, Section 3.4.4.2)
    04 -> Length = 0x04
    2900 -> Attribute Handle = 0x0029 (uchwyt do charakterystyki; możemy go zapamiętać i używać np. przy zapisie tej charakterystyki)
    08AE -> Attribute Vale = 0xAE08 -> odczytana z charkterystyki wartość; w przypadku tej charakterystki (0x2A07) najstarszy bajt = 0xAE to RSSI

    UART_TX: 010604 03 0C00 16
    01 -> (HCI packet indicator: CMD) -> (Core_V4.0.pdf: Volume 2 Part E, Section 5.4)
    0604 -> 0x0406 (HCI op_code 16 bitów: OCF:10 najmłodszych bitów OGF:6 najstarszych bitów) OCF: 0x06 oGF:0x01 -> HCI_DISCONNECT: (Core_V4.0.pdf: Volume 2 Part E, Section 7.1.6)
    03 -> 0x03=03 (HCI parameter total length: 3 bajty)
    0C00 -> handle = 0x000C -> musi mieć taką samą wartość jak w LE Create Connection Complete event
    16 -> Reason = 0x16 -> powód rozłączenia połączenia (będzie przekazany drugiej stronie; nie obsługiwany)

    UART_RX: 040F0400010604
    04 -> (HCI packet indicator: EVENT) -> (Core_V4.0.pdf: Volume 2 Part E, Section 5.4)
    0F -> event_code = 0x0f -> Command Status: (Core_V4.0.pdf: Volume 2 Part E, Section 7.7.15)
    04 -> 0x04=4 (HCI parameter total length=4)
    00 -> 0x00 (Status) -> Command currently in pending.
    01 -> 0x01 (Num_HCI_Command_Packet) -> The Number of HCI command packets which are allowed to be sent to the Controller from the Host.
    0604 -> 0x0406 (Command_Opcode) -> Opcode of the command which caused this event and is pending completion.

    UART_RX: 040504000C0016
    04 -> (HCI packet indicator: EVENT) -> (Core_V4.0.pdf: Volume 2 Part E, Section 5.4)
    05 -> event_code = 0x05 -> Disconnection Complete: (Core_V4.0.pdf: Volume 2 Part E, Section 7.7.5)
    04 -> 0x04=4 (HCI parameter total length=4)
    00 -> 0x00 (Status) -> Disconnection has occured.
    0C00 -> Connection Handle = 0x000C
    16 -> Reason = 0x16

  • #21 15 Sie 2017 10:58
    Jakub17
    Poziom 6  

    1. http://www.martyncurrey.com/hm-10-bluetooth-4ble-modules/

    2. https://www.b4x.com/android/forum/threads/ble-hm-10-module-broadcasting-a-single-byte.65785/

    3. http://www.instructables.com/id/make-iBeacon/

    Tutaj to facet fajnie opisał no i z tego co mówisz to ja już idee rozumiem. Chodzi mi tylko teraz jak to zrealizować.
    Klucz elektroniczny (BLE pracujący w trybie Slave/Peripheral) rozgłasza rozgłasza. Tak jak w tym drugim poradniku wyżej mogę to ustawić w HM-10 za pomocą komendy AT+FLAG (w 3. jest to komenda "AT+DELO2" iBeacon broadcast-only (save power) - pewnie kwestia update'u firmware'u i dlatego komendy są różne). Czyli klucz nam się już rozgłasza. Z tego co wiem to ten moduł można modyfikować charakterystyki za pomocą komend AT, ale też nie trzeba bo inne komendy AT ustawią co trzeba w charakteystykach.

    BLE w bazie, przy zamku, pracuje w trybie Master/Central można to ustawić komendą AT+ROLE. Tylko nie wiem czy mam włączyć skanowanie też za pomocą komend czy on już automatycznie będzie odbierał pakiety rozgłoszone przez klucz elektroniczny. Bo jeżeli to komendą AT włącze skanowanie takie jak w BT 2.0 że bedę musiał czekać 10 s na jego zakończenie to nie o to mi chodzi... Chce żeby było tak jak mówiłeś. Pakiety mają być odbierane przez moduł a analizowane przez procesor a dopiero później nawiązywane połączenie z konkretnym modułem

  • #22 15 Sie 2017 11:42
    TvWidget
    Poziom 29  

    Wysłałem kiedyś na PW linki do modułów realizujące funkcję klucza i zamka. Nie wymagają one zewnętrznego uP. Wystarczy jedynie do wyjścia podłączyć rygiel. Rozumiem, że chcesz coś podobnego zbudować samemu.
    Zacznij od strony zamka. Tu sprawa jest stosunkowo prosta. Stworzenie klucza z funkcją autoryzacji będzie zdecydowanie trudniejsze. Proponuję na początek użyć coś gotowego.
    Włączenie skanowania w module zapewne spowoduje obieranie i przekazywanie do uP informacji o wszystkich odebranych ramkach. Będzie to trwało do chwili wyłączenia skanowania.

  • #23 15 Sie 2017 13:24
    Jakub17
    Poziom 6  

    Jak już pisałem na początku tematu, wszystko już zrobiłem - zarówno klucze elektroniczne z szyfrowowaniem jaki i całą centrale z ryglem, z czytnikiem kart pamięci do wgrywania nowych użtkowników, wszystko działa. Problemem jest tylko brak możliwości auto-połączenia dla jednego z kilku wybranych adresów MAC w BTM222. Moduł może się połączyć z jednym adresem MAC który zapiszemy do jego pamięci za pomocą komendy AT. Skanowanie w BTM222 w poszukiwaniu urządzeń trwa za długo, stąd moje poszukiwania alternatywnej metody. Skoro w BLE mogę przerwać skanowanie w każdej chwili nie musząc czekać na koniec operacji jak w BTM222 to jest nadzieja że uda mi się to wykorzystać.

  • #24 15 Sie 2017 17:27
    TvWidget
    Poziom 29  

    Jakub17 napisał:
    Problemem jest tylko brak możliwości auto-połączenia dla jednego z kilku wybranych adresów MAC w BTM222.

    Pamiętaj ...
    Wiele rozgłaszających się urządzeń BLE używa dynamicznych adresów MAC. Np. w systemie Android adres zmienia się automatycznie co kilka minut. Jeśli będziesz chciał wykorzystać smartfony jako klucze to musisz zrobić rozróżnianie użytkowników np. wg. UUID.
    W przypadku stałych adresów MAC podszycie się pod urządzenie o określonym adresie jest banalnie proste. Musisz przewidzieć jakąś dodatkową metodę autoryzacji.

  • #25 15 Sie 2017 18:00
    Jakub17
    Poziom 6  

    Ale już pisałem że metodą autoryzacji nie jest adres MAC tylko kod alfanumeryczny ktory wgrywam do programu przez plik znajdujacy sie na karcie SD, który to kod jest szyfrowany przez elektroniczny klucz (tutaj jest on wgrany na stałe) i wysyłany ddo bazy gdzie jest deszyfrowany i porownywany. Będe mial na uwadze dynamiczne adresy ale chyba w prostym i tanim HM-10 nie ma takich dynamicznych MACów.

  • #26 15 Sie 2017 18:29
    TvWidget
    Poziom 29  

    Do otwierania furtek i mniej ważnych zamków stosuje się inny mechanizm. Klucz nadaje zmienną ramkę zawierającą miedzy innymi czas i podpis cyfrowy. W takim przypadku nie trzeba nawiązywać połączenia z kluczem. Wystarczy po stronie zamka jedynie włączyć skanowanie analizować odbierane dane. Stopień bezpieczeństwa jest podobny do tego jaki zapewnia pilot do samochodu ze zmiennym kodem.

 Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME