LEGO B3AC0N

Com os updates recentes ao kernel do ev3dev e a inclusão do módulo btusb [a meu pedido, modéstia à parte] já é possível utilizar dongles Bluetooth 4.0 com o LEGO EV3.

Enquanto não me chegam às mãos beacons e outros dispositivos BT 4.0 para testar, o único aparelho que tenho é um telemóvel Android que infelizmente apenas “consome” serviços. Bem, demos-lhe qualquer coisa para consumir: um beacon – não posso dizer iBeacon porque é trademark da Apple… mas é a mesma coisa: um «farol» que pode servir para marcar presença, orientação, medição de distâncias, fornecimento personalizado de informação…

A implementação é muito fácil, está quase tudo no post “piBeacon – DIY Beacon with a Raspberry Pi” da Adafruit.

Claro que primeiro é necessário um dongle Bluetooth 4.0 como este (qualquer um que funcione num Raspberry Pi a correr Raspbian deverá funcionar também com o EV3 a correr ev3dev).

É necessário também uma versão recente do ev3dev (baseado em Debian jessie, com kernel  3.16.1-1 ou superior, neste momento estou a usar a 3.16.1-2). Quem já tiver instalado a versão pre-release (ev3dev-jessie-2014-07-12) que à data é a mais recente disponível para download, basta

apt-get update
apt-get dist-upgrade
apt-get install linux-image-3.16.1-2

Para confirmar que temos o dongle a funcionar usamos o comando hciconfig:

root@ev3dev:~# hciconfig -a
hci1:    Type: BR/EDR  Bus: UART
    BD Address: 00:17:EC:02:91:B7  ACL MTU: 1021:4  SCO MTU: 180:4
    UP RUNNING PSCAN
    RX bytes:563 acl:0 sco:0 events:27 errors:0
    TX bytes:879 acl:0 sco:0 commands:27 errors:0
    Features: 0xff 0xff 0x2d 0xfe 0x9b 0xff 0x79 0x83
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
    Link policy: RSWITCH HOLD SNIFF PARK
    Link mode: SLAVE ACCEPT
    Name: 'ev3dev-0'
    Class: 0x000000
    Service Classes: Unspecified
    Device Class: Miscellaneous,
    HCI Version: 2.1 (0x4)  Revision: 0x0
    LMP Version: 2.1 (0x4)  Subversion: 0x191f
    Manufacturer: Texas Instruments Inc. (13)

hci0:    Type: BR/EDR  Bus: USB
    BD Address: 00:1A:7D:DA:71:13  ACL MTU: 310:10  SCO MTU: 64:8
    UP RUNNING PSCAN
    RX bytes:25008 acl:0 sco:0 events:1215 errors:0
    TX bytes:2486 acl:0 sco:0 commands:159 errors:0
    Features: 0xff 0xff 0x8f 0xfe 0xdb 0xff 0x5b 0x87
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
    Link policy: RSWITCH HOLD SNIFF PARK
    Link mode: SLAVE ACCEPT
    Name: 'ev3dev #1'
    Class: 0x000000
    Service Classes: Unspecified
    Device Class: Miscellaneous,
    HCI Version: 4.0 (0x6)  Revision: 0x22bb
    LMP Version: 4.0 (0x6)  Subversion: 0x22bb
    Manufacturer: Cambridge Silicon Radio (10)

Temos 2 dispositivos Bluetooth: hci1 (UART) que é o nativo (interno) do EV3, ainda 2.0 e que por isso de pouco serve; e hci0 (USB) que é o nosso.

Podemos ver na informação acima que hci0 já está em estado “UP RUNNING” apesar de na maioria dos artigos que encontrei referirem sempre ser necessário activá-lo

hciconfig hci0 up

Inicialmente hci0 não está a anunciar-se em modo Low Energy pelo que é necessário ativar esse modo. Além disso o artigo em que me inspirei refer ser conveniente desactivar a procura de outros dispositivos por poder interferir e apesar de achar isso estranho para este exemplo mal não faz por isso

hciconfig hci0 leadv
hciconfig hci0 noscan

Resta apenas configurar hci0 para funcionar se anunciar como beacon e fingir ser da Apple:

root@ev3dev:~# hcitool -i hci0 cmd 0x08 0x0008 1E 02 01 1A 1A FF 4C 00 02 15 E2 0A 39 F4 73 F5 4B C4 A1 2F 17 D1 AD 07 A9 61 00 00 00 00 C8 00
< HCI Command: ogf 0x08, ocf 0x0008, plen 32
  1E 02 01 1A 1A FF 4C 00 02 15 E2 0A 39 F4 73 F5 4B C4 A1 2F
  17 D1 AD 07 A9 61 00 00 00 00 C8 00
> HCI Event: 0x0e plen 4
  01 08 20 00

Se no nosso Android instalarmos uma aplicação como a “Bluetooth LE Scan” (e o telemóvel/tablet tiver BT 4.0 e Android 4.3 ou superior) após um SCAN encontramos o nosso Beacon:

ev3dev #1
MAC: 00:1A:7D:DA:71:13
Updated: 2014-09-12 17:46:50
RSSI: -60.0db / -60.0 dB
UUID: ....
Major:   0     Minor:  0
Tx Power: -56  Distance: 1.64m
Descriptor: NEAR

A precisão deixa um pouco a desejar: vários SCAN consecutivos deram valores entre 1m [NEAR] e 7m [FAR] quando o telemóvel estava a cerca de 1m40 do dongle.

Podemos ajustar um pouco mudando um valor de referência Tx Power enviado pelo Beacon no penúltimo byte do comando hcitool (“C8” acima) que corresponde ao valor RSSI medido em laboratória a distâncias de um metro, escrito em complemento para 2 (C8 = -56 portanto corresponde a uma medição de RSSI de -56 dB a um metro)

Seguem algures valores próximos de -56 dB:

-54 dB = CA
-55 dB = C9
-56 dB = C8
-57 dB = C7
-58 dB = C6
-59 dB = C5

Portanto se colocarmos o dispositivo Android a exactamente um metro do dongle USB, o valor RSSI medido será o nosso valor ideal de Tx Power.

Infelizmente obtive valores entre -55 e -63 dB (com o EV3 alimentado por carregador para garantir uma alimentação constante) por isso fiquei na mesma. Após algumas experiências com algumas medições a várias distâncias fiquei-me por -57 dB = C7, pareceu-me o menos flutuante.

hcitool -i hci0 cmd 0x08 0x0008 1E 02 01 1A 1A FF 4C 00 02 15 E2 0A 39 F4 73 F5 4B C4 A1 2F 17 D1 AD 07 A9 61 00 00 00 00 C7 00

Quando tiver um Beacon a sério vou poder calibrar melhor este meu EV3 B3AC0N (e até pode ser que a flutuação seja do software, vou procurar outras aplicações semelhantes).

Falta agora o inverso: utilizar hci0 para encontrar outros Beacons. Ou talvez outros B3AC0Ns.

Nota: podemos não fingir ser Apple, substituindo 4C 00 pelo Company ID de outro fabricante (infelizmente a LEGO não aparece) como por exemplo ​FE 00 (reserved)… só que deixa de ser reconhecido como um Beacon.