Um mergulho profundo nos Beacons de Eddystone (caso de uso do NINA B302 + Zephyr)
O objetivo deste BLOG é demonstrar como é possível utilizar utilizar o B302 como ADVERSTISING de uma URL. Foi utilizado ZEPHYR RTOS para programar o módulo U-BLOX NINA B302 soldado no BREAKOUT.
Sobre ZEPHYR RTOS, ver
https://zephy-platformio.blogspot.com/2020/03/nina-b112-zephyr-platformio.html
-Botão de RESET;
Sobre ZEPHYR RTOS, ver
https://zephy-platformio.blogspot.com/2020/03/nina-b112-zephyr-platformio.html
Adquirimos então os seguintes componentes
Montado ficou assim
O esquema elétrico é este
Algumas características do Kit
-Botão de RESET;
-Botão de Modo BOOTLOADER (W102);
-Plugável no PROTOBOARD;
-Acesso às várias GPIOS;
Com o Eddystone, você ainda pode criar funcionalidades semelhantes para incluir dois níveis de hierarquia. Isso inclui um Beacon ID de 16 bytes, composto por um namespace de 10 bytes e uma instância de 6 bytes.
O Eddystone fornece quatro tipos de quadros:
- Eddystone-UID : esse tipo é semelhante à configuração de UUID + Maior + Menor do iBeacon. Ele define um Beacon ID de 16 bytes composto por um namespace de 10 bytes e uma instância de 6 bytes. Por exemplo, o espaço para nome poderia definir o ID de um varejista nacional para suas lojas e a instância se referiria a cada loja exclusivamente.
- Eddystone-URL : esse tipo fornece uma maneira de transmitir um URL a ser descoberto por um dispositivo de scanner BLE, que por sua vez pode navegar até o URL e apresentar a página da Web ao usuário.
- Eddystone-TLM : esse tipo fornece informações de telemetria sobre o dispositivo, como nível da bateria, temperatura e um contador de pacotes anunciados.
- Eddystone-EID : esse tipo fornece uma estrutura para atingir um certo nível de segurança e privacidade de um dispositivo. EID significa ID Efêmero, que é um identificador que muda periodicamente a uma taxa determinada durante a fase de implantação, registrando-a em um serviço da web confiável.
NOTA: Embora o Google tenha praticamente abandonado o padrão Eddystone em smartphones (especificamente Android e Chrome), ele ainda pode servir como um bom formato para aplicativos em que você controla os dois lados (dispositivos de radiodifusão + dispositivos de scanner) e que não dependem do smartphone aplicativos. Também serve como um ótimo exercício para aprender mais sobre como os anúncios Bluetooth funcionam e como utilizá-los para seu próprio aplicativo.
Neste tutorial, focaremos nos tipos de quadro Eddystone-UID e Eddystone-URL .
Aqui está o que abordaremos hoje:
Dados de serviço
Eddystone-UID
Eddystone-URL
Eddystone-TLM e Eddystone-EID
Implementando Eddystone no NINA B302 usando Zephyr RTOS
Exemplo de Eddystone-UID
Formato Eddystone
A parte mostrada na figura acima é constante para todos os pacotes de anúncios do Eddystone, exceto para a parte de Dados do Serviço .
Os dados do anúncio seguem o formato Comprimento-Tipo-Valor (semelhante ao formato TLV popular ). O valor Comprimento indica o comprimento dos dados que incluem o Tipo e a Carga útil .
O padrão Eddystone utiliza o tipo de dados Anúncio de Dados de Serviço para enviar os dados para os dispositivos de scanner BLE. O iBeacon, por outro lado, utiliza o tipo de dados Anúncio de Dados do Fabricante.
Agora, vejamos a parte de dados de serviço, que inclui as informações que estamos interessados em analisar no final do receptor.
Dados de serviço
O formato da porção de dados de serviço depende do tipo de quadro usado (Eddystone-UID, Eddystone-URL, Eddystone-TLM ou Eddystone-EID).
Eddystone-UID
Como mencionamos anteriormente, esse tipo de quadro é usado de maneira semelhante ao iBeacon da Apple. Inclui o seguinte:
Ao usar esse tipo de quadro, podemos utilizar o namespace de 10 bytes para um ID exclusivo de nossa escolha (por exemplo, para indicar um identificador de loja específico) e, em seguida, usar o 6 bytes como uma identificação de um subconjunto do namespace (por exemplo, para identificar um corredor dentro da loja).
Notas:
- Esse tipo de quadro utiliza no máximo 31 bytes de dados de anúncio disponíveis em um pacote de anúncio BLE (primário).
- O campo Ranging Data é a potência Tx medida em 0 metros do transmissor (-100 dBm a +20 dBm).De acordo com a especificação Eddystone, a melhor maneira de determinar o valor a ser incluído nesse campo é medir o RSSI real em 1 metro e adicionar 41 dBm ao valor (com base na suposição de que 41 dBm é a perda de sinal que ocorre acima de 1 metro).
- Para obter mais informações e recomendações sobre a geração do ID do espaço para nome e da instância, consulte a especificação Eddystone aqui .
Nota importante : O valor da potência Tx usa um formato de complemento de dois para representar valores assinados. Para obter mais informações sobre esse cálculo, consulte a seção do artigo da Wikipedia sobre o complemento de dois: https://en.wikipedia.org/wiki/Two%27s_complement#Converting_to_two's_complement_representation
Eddystone-URL
O tipo de quadro Eddystone-URL é único e diferente do uso do Eddystone-UID ou do formato iBeacon da Apple. É usado para anunciar um URL para o scanner descobrir e analisar e, potencialmente, apontar para um navegador da Web.
Esse tipo de quadro é usado principalmente em aplicativos e implementações da " Physical Web ".
Como o comprimento máximo dos dados do anúncio BLE é de 31 bytes, isso limita os URLs que podem ser transmitidos usando esse tipo de quadro. No entanto, o formato fornece algum nível de codificação compactada para aproveitar ao máximo o espaço limitado disponível para os dados do anúncio.
Aqui está o formato usado para esse tipo de quadro:
O valor da potência Tx é representado da mesma maneira que descrevemos na seção Eddystone-UID acima.
O esquema de URL é definido da seguinte maneira:
- Diferentes prefixos para URLs são representados da seguinte maneira
- A parte principal do URL é incluída como uma sequência de caracteres. Por exemplo, "google" seria representado como uma sequência de 'g' 'o' 'o' 'g' 'l' 'e', que seria convertida em seus valores ASCII.
- Finalmente, a expansão do URL (por exemplo, .com / ou .com ) é representada da seguinte maneira:
Por exemplo, se quiséssemos representar "https://www.google.com/" com uma potência Tx de 0 dBm, a matriz de dados de serviço ficaria assim:
Tipo de quadro (URL) | Potência Tx | https: // www. | g | o | o | g | eu | e | .com / |
0x10 | 0x00 | 0x01 | 0x67 | 0x6f | 0x6f | 0x67 | 0x6c | 0x65 | 0x00 |
Eddystone-TLM e Eddystone-EID
Os quadros Eddystone-TLM são usados para transmitir dados de telemetria úteis para monitorar a saúde dos beacons em campo. Esse quadro não contém nenhum identificador, portanto é emparelhado com os quadros Eddystone-URL, Eddystone-UID ou Eddystone-EID.
Quando emparelhado com quadros EID, o pacote Eddystone-TLM é criptografado. Quando emparelhados com quadros de URL ou UID, no entanto, os pacotes TLM não são criptografados.
Para saber mais sobre esses tipos, consulte os seguintes links:
- Eddystone-EID specification
- Eddystone-TLM specification
- Unencrypted TLM specification
- Encrypted TLM specification
Implementando Eddystone no nRF52 usando Zephyr RTOS
Para a parte prática deste tutorial, usaremos:
- O breakout NINA B302
- Zephyr RTOS.
- Smartphone com um aplicativo de scanner BLE - usaremos o nRF Connect para iOS.
O Zephyr já fornece um exemplo de configuração de um anúncio Eddystone-URL, portanto, usaremos isso como nosso ponto de partida.
O exemplo está localizado em
<Zephyr root folder>/zephyr/samples/bluetooth/beacon
. Para criar o exemplo, navegue até a <Zephyr root folder>/zephyr/
pasta e compile no PLATFORMIO
Vamos dar uma olhada no código-fonte do exemplo gravá-lo e executá-lo na placa de desenvolvimento.
main.c
:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
| /* main.c - Application main entry point */ /* * Copyright (c) 2015-2016 Intel Corporation * * SPDX-License-Identifier: Apache-2.0 */ #include <zephyr/types.h> #include <stddef.h> #include <sys/printk.h> #include <sys/util.h> #include <bluetooth/bluetooth.h> #include <bluetooth/hci.h> #define DEVICE_NAME CONFIG_BT_DEVICE_NAME #define DEVICE_NAME_LEN (sizeof(DEVICE_NAME) - 1) /* * Set Advertisement data. Based on the Eddystone specification: * https://github.com/google/eddystone/blob/master/protocol-specification.md * https://github.com/google/eddystone/tree/master/eddystone-url */
static const struct bt_data ad[] = { BT_DATA_BYTES(BT_DATA_FLAGS, BT_LE_AD_NO_BREDR), BT_DATA_BYTES(BT_DATA_UUID16_ALL, 0xaa, 0xfe), BT_DATA_BYTES(BT_DATA_SVC_DATA16, 0xaa, 0xfe, /* Eddystone UUID */ 0x10, /* Eddystone-URL frame type */ 0x00, /* Calibrated Tx power at 0m */ 0x00, /* URL Scheme Prefix http://www. */ 'z', 'e', 'p', 'h', 'y', 'r', 'p', 'r', 'o', 'j', 'e', 'c', 't', 0x08) /* .org */ }; /* Set Scan Response data */
static const struct bt_data sd[] = { BT_DATA(BT_DATA_NAME_COMPLETE, DEVICE_NAME, DEVICE_NAME_LEN), };
static void bt_ready(int err) { if (err) { printk("Bluetooth init failed (err %d)\n", err); return; } printk("Bluetooth initialized\n"); /* Start advertising */
err = bt_le_adv_start(BT_LE_ADV_NCONN, ad, ARRAY_SIZE(ad), sd, ARRAY_SIZE(sd)); if (err) { printk("Advertising failed to start (err %d)\n", err); return; } printk("Beacon started\n"); }
void main(void) { int err; printk("Starting Beacon Demo\n"); /* Initialize the Bluetooth Subsystem */
err = bt_enable(bt_ready); if (err) { printk("Bluetooth init failed (err %d)\n", err); } }
|
Como você pode ver, o código é muito simples. Vamos alterar o URL para "https://www.google.com/" para corresponder ao nosso exemplo na seção anterior.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| /* * Set Advertisement data. Based on the Eddystone specification: * https://github.com/google/eddystone/blob/master/protocol-specification.md * https://github.com/google/eddystone/tree/master/eddystone-url */
static const struct bt_data ad[] = { BT_DATA_BYTES(BT_DATA_FLAGS, BT_LE_AD_NO_BREDR), BT_DATA_BYTES(BT_DATA_UUID16_ALL, 0xaa, 0xfe), BT_DATA_BYTES(BT_DATA_SVC_DATA16, 0xaa, 0xfe, /* Eddystone UUID */ 0x10, /* Eddystone-URL frame type */ 0x00, /* Calibrated Tx power at 0m */ 0x01, /* URL Scheme Prefix https://www. */ 'g', 'o', 'o', 'g', 'l', 'e', 0x00) /* .com/ */ };
|
Agora que fizemos algumas alterações, precisamos reconstruir o aplicativo, mais uma vez recompile.
Agora podemos executar o nRF Connect (iOS, Android ou Desktop) para confirmar as alterações:
Como você pode ver, o URL corresponde exatamente ao que atualizamos.
Além disso, o tipo detectado é " Web física " e o tipo de quadro é 0x10 (URL) . O nome do dispositivo " Farol de teste " é definido no arquivo
prj.conf
:
1
2
3
|
CONFIG_BT=y
CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_DEVICE_NAME="Test beacon"
|
Exemplo de Eddystone-UID
Vamos em frente e atualize o exemplo para transmitir um tipo de quadro UID em vez de URL:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
/* * Set Advertisement data. Based on the Eddystone specification: * https://github.com/google/eddystone/blob/master/protocol-specification.md * https://github.com/google/eddystone/tree/master/eddystone-url */
static const struct bt_data ad[] = { BT_DATA_BYTES(BT_DATA_FLAGS, BT_LE_AD_NO_BREDR), BT_DATA_BYTES(BT_DATA_UUID16_ALL, 0xaa, 0xfe), BT_DATA_BYTES(BT_DATA_SVC_DATA16, 0xaa, 0xfe, /* Eddystone UUID */ 0x00, /* Eddystone-UID frame type */ 0x00, /* Calibrated Tx power at 0m */ 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x080x09, /* 10-byte Namespace */ 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f) /* 6-byte Instance */ };
|
Como você pode ver, o tipo detectado é " Eddystone " e o tipo de quadro é 0x00 (UID) .
Código para o Platformio https://github.com/tcpipchip/ninab302-eddystone
Outras imagens
suporte@smartcore.com.br
Referências:
Código para o Platformio https://github.com/tcpipchip/ninab302-eddystone
Outras imagens
Dúvidas:
suporte@smartcore.com.br
Referências:
https://www.novelbits.io/eddystone-beacons-zephyr-nrf52/?utm_source=drip&utm_medium=email&utm_campaign=Developing+Eddystone+Beacons+%28nRF52+%2B+Zephyr%29&utm_content=Developing+Eddystone+Beacons+%28nRF52+%2B+Zephyr%29
https://www.u-blox.com/sites/default/files/NINA-B3_DataSheet_%28UBX-17052099%29.pdf
Sobre a SMARTCORE
https://www.u-blox.com/sites/default/files/NINA-B3_DataSheet_%28UBX-17052099%29.pdf
Sobre a SMARTCORE
A SmartCore fornece módulos para comunicação wireless, biometria, conectividade, rastreamento e automação.
Nosso portfólio inclui modem 2G/3G/4G/NB-IoT/Cat.M, satelital, módulos WiFi, Bluetooth, GNSS / GPS, Sigfox, LoRa, leitor de cartão, leitor QR code, mecanismo de impressão, mini-board PC, antena, pigtail, LCD, bateria, repetidor GPS e sensores.
Mais detalhes em www.smartcore.com.br