Вы находитесь на странице: 1из 13

Bluetooth para Dummies: Establecer conexin con SDP

Este post es una continuacin de nuestro esfuerzo para mejorar host USB 2.0
para la biblioteca Arduino haciendo especial hincapi en el perfil SPP Bluetooth
y capacidad de Luminardo para iniciar la conexin a un hardware Bluetooth
SPP-conscientes remoto. La ltima vez que se ha descrito lo que tuvo que ser
cambiado en la biblioteca para que Luminardo para iniciar el emparejamiento
de secuencia. Hoy vamos a avanzar ms all y descubrir lo que ms tiene que
hacer. Pero antes de proceder primero que necesitamos hacer para algunas
preparaciones para asegurarnos de que tenemos las herramientas y la
documentacin a la mano. Tenga en cuenta que este post no establece una
meta para hacer una completa gua Bluetooth, es ms bien un ejemplo que
demostrates dnde empezar y cmo aprender con el fin de resolver un
problema relacionado con la pila BT.

En primer lugar, necesitaramos especificacin principal Bluetooth. Suena


obvio, pero por extrao que parezca, no es como sencillo como parece: hay
varias especificaciones bsicas con nmeros de versin que van desde 2,0
hasta 4,1 por no hablar de 'adendas' numerosas especificaciones. Una breve
investigacin revela que la biblioteca est construida alrededor rev.4.0 y la
ubicacin documento apropiado estara aqu. Dos documentos ms seran
tambin muy tiles: SPP Especificacin Ver.1.2 y GSM 07.10 Especificacin.

En segundo lugar, tener un sistema real de trabajo (por ejemplo, dos


dispositivos Bluetooth SPP-aware) como punto de referencia puede simplificar
significativamente el proceso de aprendizaje como todos los documentos antes
mencionados son muy difciles de leer y an ms difcil de comprender. Ser
capaz de ver el intercambio de datos real es una necesidad. El uso de un PC
con sistema operativo Windows da prcticamente nada como la pila de
Bluetooth es una parte integral del ncleo del sistema operativo y al parecer no
hay manera de oler o ingrese paquetes Bluetooth. Lo que es an peor, las
diferentes versiones de Windows utilizan completamente diferentes stacks
Bluetooth, pero todos ellos son cajas negras - nadie sabe lo que est
sucediendo en el interior. Por otro lado, Linux y su pila de Bluetooth tienen todo
en su lugar para debuging paquete eficiente y solucin de problemas. Nuestro
equipo utiliza Lubuntu con el paquete preinstalado Bluez. Hovewer, para
registrar los paquetes de un paquete ms debe estar instalado: bluez-hcidump.
En nuestro entorno todo lo que tena que hacer para instalarlo fue apt-get
install bluez-hcidump en la lnea de comandos.

Y, por ltimo que necesitaramos un dispositivo para conectarse. Podra ser otro
PC o Laptor con adaptador Bluetooth o un adaptador ELM327. En este ltimo
caso un adaptador debe ser alimentado como en esta etapa no es necesario en
la comunicacin fsica con el autobs del coche y que es suficiente para aplicar
solamente la tensin de alimentacin. Tambin es extremadamente
inconveniente para ejecutar experimentos en un coche ya sea dentro de un
garaje oscuro o un lugar de estacionamiento, un laboratorio casero sera un
lugar mejor. Cualquier fuente de alimentacin de 12 V CC capaz de entregar al
menos 100 mA har. Durante nuestras pruebas hemos utilizado una fuente de
alimentacin de banco como se muestra en las fotos de abajo. Asegrese de
que usted consigue la derecha de polaridad: cable marrn es GND, cable rojo
es + 12VDC.

Encendido ELM327 fuera Bench Power Supply


Encendido ELM327 fuera Bench Power Supply
Encendido ELM327: polaridad del cableado
Encendido ELM327: polaridad del cableado
Ahora, una cantidad significativa de tiempo debe ser gastado tratando de
combinar el conocimiento contenido en las especificaciones Bluetooth, la lgica
que figuran en los archivos de SPP.cpp y BTD.cpp y el sentido comn.
Asimismo, toma algn tiempo para familiarizarse con las peculiaridades bluezhcidump ya que ofrece gran variedad de opciones que permiten iniciar una
sesin en diferentes formatos. Las especificaciones estn escritos de una
manera muy extraa, mientras leyendo sigues preguntando una sola pregunta
una y otra vez: qu eran esos chicos fumadores cuando escribieron esas
caractersticas? La informacin se dispersa a travs no slo de pginas y
captulos pero diferentes archivos, as, es muy difcil hacer sentido de ella. Ellos
siguen saltando de un tema a otro, a menudo utilizando largas descripciones
de una entidad o un proceso, mientras que una sola imagen-ejemplo sera vale
ms que mil palabras, usted necesita leer el mismo pasaje varias veces
tratando de entender lo que significaban. Lo que es an peor, la informacin
que a menudo parece ambigua y no concluyente, no hay manera de
comprenderlo plenamente a menos que tenga un hardware y biblioteca real
para llevar a cabo algunos experimentos de prueba o refutacin sus conjeturas
despus de leer la especificacin. La informacin disponible en Internet es
sorprendentemente escasa: adems de las especificaciones Bluetooth oficiales
que son fciles de entender slo para las personas que las escribieron no es
bsicamente nada ms. Documentacin y foro de debates para Bluez o BTstack
son slo alrededor de la API y cmo usarlo, las implementaciones reales de las
pilas no se tratan como tales o discutidos por los profesionales de BT que ya

tiene un profundo conocimiento de las especificaciones. Parece que todo el


mundo considera la pila como un hecho sin conocimiento real de cmo y por
qu funciona, y los que saben de eso prefieren mantener el conocimiento
cerrado, es muy claro cmo superar este vaco antes de que usted sabe lo
suficiente para seguir avanzando hacia el numerada grupo de gur Bluetooth.

Como ya pasamos cantidad significativa de tiempo aqu estn algunos hechos


que salieron de nuestro esfuerzo:
1. La inversin de la funcin de nuestro dispositivo de aceptor de iniciador
requiere evaluador importante rediseo de la lgica residido en SPP.cpp.
Formato y contenido de los paquetes enviados por iniciador se desconoce por
el momento y an por descubrir;
2. Con el fin de establecer la conexin a un dispositivo remoto a travs de SPP
es necesario interrogar a un servicio de SDP para obtener un nmero de puerto
para conectarse a;
3. Tan pronto como se conoce el nmero de puerto, la conexin con el servicio
RFCOMM debe ser iniciado.

Todas las interacciones con los servicios de SDP y RFCOMM se realizan a travs
de interfaz L2CAP subyacente, por razones de simplicidad lo consideran como
una capa de transporte troncal. Antes de cualesquiera solicitudes se pueden
enviar a los servicios ya sea SDP o RFCOMM una conexin a ese servicio tiene
que ser establecida por medio del conjunto estndar de comandos L2CAP. El
orden de estos comandos es importante. En la mayora de los casos, si un
comando est mal formado o enviado en el momento inapropiado ser
ignorado y ningn paquete de error de cualquier tipo ser enviado lo que sin
duda hace que la solucin de problemas ms difciles. Una secuencia tpica de
establecer conexin con un SDP (RFCOMM o cualquier otro) el servicio es la
siguiente:

1. Iniciador enva SOLICITUD DE CONEXIN;


2. aceptador responde con respuesta de conexin y poco despus enva
solicitud de configuracin;
3. Iniciador responde con RESPUESTA DE CONFIGURACIN y poco despus
enva solicitud de configuracin (o al revs);

4. aceptador responde con RESPUESTA DE CONFIGURACIN - y desde est


establecida y esta conexin momento comandos especficos de servicios puede
ser enviado;

Vamos a confirmar nuestro conocimiento terico con el sistema de trabajo real.


Encienda ELM327 a continuacin, iniciar el Administrador de Bluetooth en
Linux, la bsqueda de los dispositivos disponibles y debe detectar ELM327
como 'OBDII'. Par con l y entrar pin '1234' cuando se le solicite (consulte el
manual del usuario de su ELM327 ya que podra haber otro valor para el cdigo
pin). Comience Linux dos consolas y ejecutar en el primer comando de una
hcidump sin parmetros, y en segundo hcidump - X -R comando. A
continuacin, vaya a las propiedades de OBDII, haga clic en "Configuracin" y
seleccione "Conectar al puerto serie. Usted debe ver los datos que entran y
salen registrado por hcidump. Aqu est una parte de los datos registrados por
la primera consola:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

16
17
<Los datos ACL: manejar 43 banderas 0x02 dlargo 12
L2CAP (s): Conecte req: psm 1 scid 0x0040 // saliente solicitud de conexin
al PSM = 1 (Service Discovery Protocol) de un cliente con SCID = 0x0040
(Fuente Canal Identificador, un identificador nico de nuestro punto final o
cliente)
> Datos ACL: manejar 43 banderas 0x02 dlargo 16
L2CAP (s): Conecte rsp: dcid resultado 0x0040 0x0040 scid 0 0 Situacin //
respuesta de conexin entrante de un extremo remoto con DCID = 0x0040 con
resultado y el estado se establece en 0 (xito)
Conexin exitosa
<Los datos ACL: manejar 43 banderas 0x02 dlargo 12
L2CAP (s): Config req: DCID 0x0040 banderas 0x00 clen 0 // saliente
SOLICITUD CONFIG desde nuestro punto final con los parmetros de
configuracin (banderas) ajustado en 0
> Datos ACL: manejar 43 banderas 0x02 dlargo 20
L2CAP (s): Config req: DCID 0x0040 banderas 0x00 clen 8 // SOLICITUD
CONFIG entrante del extremo remoto
MTU 60
FlushTO 65535
<Los datos ACL: manejar 43 banderas 0x02 dlargo 18
L2CAP (s): Config rsp: flags 0x0040 scid 0x00 resultado 0 clen 4 // saliente
RESPUESTA CONFIG desde nuestro punto final
MTU 60
> Datos ACL: manejar 43 banderas 0x02 dlargo 18
L2CAP (s): Config rsp: flags 0x0040 scid 0x00 resultado 0 clen 4 //
RESPUESTA CONFIG entrante del extremo remoto
MTU 48
La segunda consola registra datos en formato RAW y le da la oportunidad de
ver flujo de bytes real. La misma porcin de los datos se ver as:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<0000:. 02 2a 20 0C 08 00 01 00 00 02 03 04 00 01 00 40 * ............ @ //
saliente CONEXIN SOLICITUD L2CAP CMD (0x02 en la direccin 0x0009)
0010: 00.

> 0000: 02 2a 20 10 00 01 00 0C 03 00 03 08 00 40 00 40 * .......... @ @ //


entrante CONEXIN RESPUESTA L2CAP CMD (0x03 en la direccin 0x0009)..
0010: 00 00 00 00 00 .....

<0000:. 02 2a 20 0C 08 00 01 00 00 04 04 04 00 40 00 00 * .......... @ .. //
saliente SOLICITUD L2CAP CONFIG (0x04 en la direccin 0x0009)

0010: 00.

> 0000:. 02 2a 14 00 10 20 00 01 00 04 4c 0c 00 40 00 00 * ....... L .. @ .. //


entrante SOLICITUD L2CAP CONFIG (0x04 en la direccin 0x0009)
0010: 00 01 02 00 02 02 3c ff ff ... <.....

<0000:. 02 2a 20 12 00 00 01 00 0e 05 4c 0a 00 40 00 00 * ....... L .. @ .. //
saliente RESPUESTA L2CAP CONFIG (0x05 en la direccin 0x0009)
0010: 00 00 00 01 02 00 3c ..... <.

> 0000:. 02 2a 20 12 00 0E 00 01 00 05 04 0a 00 40 00 00 * .......... @ .. //


entrante RESPUESTA L2CAP CONFIG (0x05 en la direccin 0x0009)
0010: 00 00 00 01 02 30 00 ..... 0.
En esta etapa, que sera la pena para familiarizarse un poco con la estructura
de paquetes y carga til. Hasta el momento hay cuatro tipos de paquetes:
L2CAP solicitud de conexin, L2CAP CONEXIN DE RESPUESTA, L2CAP CONFIG
peticin y L2CAP CONFIG DE RESPUESTA. Las cuatro estructuras se dan a
continuacin.

CONEXIN L2CAP estructura de paquete de PETICIN


1
2
3
4
5
6
7
8
9

10
11
12
13
14
15
16
17
18
=== === Encabezado HCI
02 2a HCI hanle con banderas del PP y BC
20 0c HCI ACL longitud total de datos (que en realidad especifica 0x000C
longitud total
de acuerdo con Bluetooth Core Spec. rev.4.0, Host Controller Interface Spec
Funcional)
y ser 0C 00 en lugar de 20 0C pero no te preocupes de eso ahora - que
funciona para nosotros de todos modos
00 08 L2CAP longitud de carga til
00 01 L2CAP ID del canal (0x0001 para ACL-U, consulte Bluetooth Core Spec.
Rev.4.0,
Control de enlace lgico y Adaptacin del Protocolo de Especificaciones,
pgina 54)

00 ??? Desconocido byte, est presente ni en spec ni en paquetes cuando se


envan desde Arduino / Luminardo.
Probablemente un error en hcidump como el byte ni siquiera se represent
por HCI ACL longitud total de datos

=== Comandos L2CAP Actual ===

02 L2CAP_CMD_CONNECTION_REQUEST
Identificador de 03 paquetes
04 00 Comando de carga til Longitud
01 00 SDP_PSM
40 00 SCID, Fuente Canal Identificador
CONEXIN L2CAP estructura de paquetes RESPUESTA
1
2
3
4
5
6
7
8
9
10
11
=== === Encabezado HCI
02 2a 20 10 00 0C 00 01 00 - encabezado HCI, como el anterior, por favor ver
la estructura paquete de PETICIN DE CONEXIN L2CAP

=== Comandos L2CAP Actual ===


03 L2CAP_CMD_CONNECTION_RESPONSE
Identificador de 03 paquetes
08 00 Comando longitud de carga til
40 00 DCID (Destino Canal Identificador, en otras palabras, un ID de punto final
remoto)

40 00 SCID (Identificador de canales de origen, en otras palabras, ID de punto


final local)
00 00 Resultado 0 (xito)
00 00 Ningn dato ms
L2CAP CONFIG estructura de paquete de PETICIN
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
Caso 1-st en nuestro registro generada por sniffer
=== === Encabezado HCI
02 2a 20 0C 00 08 00 01 00 - encabezado HCI, como el anterior, por favor ver
la estructura paquete de PETICIN DE CONEXIN L2CAP

=== Comandos L2CAP Actual ===


04 L2CAP_CMD_CONFIG_REQUEST
Identificador de 04 paquetes
04 00 Comando longitud de carga til
40 00 DCID (Destino Canal Identificador, en otras palabras, un ID de punto final
remoto)
00 00 Banderas

Caso 2-nd en nuestro registro generada por sniffer


=== === Encabezado HCI
02 2a 14 00 10 20 00 01 00 - encabezado HCI, como el anterior, por favor ver
la estructura paquete de PETICIN DE CONEXIN L2CAP

=== Comandos L2CAP Actual ===

04 L2CAP_CMD_CONFIG_REQUEST
Identificador 4c de paquetes
0c 00 Comando longitud de carga til
40 00 DCID (Destino Canal Identificador, en otras palabras, un ID de punto final
remoto)
00 00 Banderas
01 Config Opt: type = MTU (Maximum Transmission Unit) - Sugerencia
02 Config Opt: longitud
3c 00 MTU
02 Config Opt: type = Tiempo de espera Flush
02 Config Opt: longitud
ff ff tiempo de espera Flush
L2CAP CONFIG estructura de paquetes RESPUESTA
1
2
3
4
5
6
7
8
9
10
11
12
13
=== === Encabezado HCI

02 2a 20 12 00 00 01 00 0e - encabezado HCI, como el anterior, por favor ver


la estructura paquete de PETICIN DE CONEXIN L2CAP

=== Comandos L2CAP Actual ===


05 L2CAP_CMD_CONFIG_RESPONSE
Identificador 4c de paquetes
0a 00 Comando longitud de carga til
40 00 SCID (Identificador de canales de origen, en otras palabras, ID de punto
final local)
00 00 Sealizar 0
00 00 Resultado 0 (xito)
01 Config Opt: type = MTU (Maximum Transmission Unit) - Sugerencia
02 Config Opt: longitud
3c 00 MTU
Ahora tenemos un poco de entendimiento sobre la forma de establecer la
conexin al servicio de SDP (mismo se aplica a RFCom) y estamos dispuestos a
comminicate con servicio de SDP. Lo que se debe hacer y cmo hacerlo ser
discutido en nuestro post nido. Estn atentos y hacer preguntas si usted tiene
cualquiera!

30 de marzo 2014 | Etiquetas: Bluetooth Core Spec, dongle Bluetooth, del perfil
de Bluetooth, bricolaje, L2CAP, Luminardo, Magictale, RFCOMM, SDP, SPP, host
USB | Categora: Luminardo | Deja un comentario
Traductor de Google para empresas:Google Translator ToolkitTraductor de sitios
webGlobal Market Finder