proyecto fin de grado - universidad de...
TRANSCRIPT
Equation Chapter 1 Section 1
Proyecto Fin de Grado
Grado en Ingeniería de las Tecnologías de
Telecomunicación
Autor: Jose Luis Alcoba Huertas
Tutor: Alfredo Pérez Vega-Leal
Localizador Bluetooth para carteras
Dpto. de Ingeniería electrónica
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2018
iii
Proyecto Fin de Grado
Grado en Ingeniería de las Tecnologías de Telecomunicación
Localizador Bluetooth para carteras
Autor:
Jose Luis Alcoba Huertas
Tutor:
Alfredo Pérez Vega-Leal
Profesor titular
Dpto. de Ingeniería electrónica
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2018
v
Proyecto Fin de Grado: Localizador Bluetooth para carteras
Autor: Jose Luis Alcoba Huertas
Tutor: Alfredo Pérez Vega-Leal
El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:
Presidente:
Vocales:
Secretario:
Acuerdan otorgarle la calificación de:
Sevilla, 2018
El Secretario del Tribunal
vii
Agradecimientos
Me gustaría aprovechar estas líneas para agradecer a mis padres y a mi hermano todo el apoyo y el esfuerzo
que han hecho para que hoy pueda tener una buena educación. Por otro lado, me gustaría agradecer a mi novia,
Ana Mª Pérez, todo el ánimo que me has dado, eres la única persona que ha sabido motivarme para continuar
la lucha, sin ti no habría conseguido llegar hasta aquí.
Por último, me gustaría agradecer a Alfredo Pérez Vega-Leal todas sus directrices y consejos, ya que me han
sido y serán de gran utilidad hoy y seguro que en el futuro. También me gustaría agradecer a Raúl Núñez y a
Diego Rodríguez toda la ayuda que me han dado, sin ellos todo hubiera sido más difícil.
Jose Luis Alcoba Huertas
Sevilla, 2018
ix
Resumen
Actualmente en el mercado existen dispositivos de alerta ante el robo de carteras, sin embargo, éstos se basan
en técnicas de dudosa calidad para detectar el robo. Existen también dispositivos que se basan en proximidad
para detectar el robo, sin embargo, el problema de éstos es que son caros y, en ocasiones, no son reutilizables
cuando se acaba la fuente de alimentación; obligando al usuario a adquirir uno nuevo.
En este contexto, se pretente desarrollar un dispositivo de alerta en caso de robo basado en proximidad. El
producto resultante debe tener el tamaño suficientemente como para entrar en una cartera de bolsillo de
tamaño medio, disponer de la mayor autonomía posible, contar con un sistema de alerta sonoro y
comunicaciones inalámbricas.
Para ello, se realizará un estudio de los diferentes protocolos de comunicación inalámbricos que permitan
calcular la distancia entre dos dispositivos y, a su vez, sea compatible con los teléfonos inteligentes disponibles
hoy en día en el mercado. Una vez se elija el protocolo más adecuado, se diseñará el hardware necesario y, por
último, se programará todo el código necesario.
xi
Abstract
Currently in the market there are warning devices against theft of portfolios, however, these are based on
techniques of dubious quality to detect theft. There are also devices that are based on proximity to detect theft,
however, the problem of these is that they are expensive and, sometimes, are not reusable when the power
supply is finished; Forcing the user to acquire a new one.
In this context, we intend to develop an alert device in case of theft based on proximity. The resulting product
must be large enough to fit into a medium-sized pocket portfolio, have the greatest possible autonomy, have a
sound alert system and wireless communications.
For this purpose, a study will be made of the different wireless communication protocols that allow to
calculate the distance between two devices and, at the same time, be compatible with the smartphones
available in the market today. Once the most appropriate protocol is chosen, the necessary hardware will be
designed and, finally, all the necessary code will be programmed.
Índice
Agradecimientos vii
Resumen ix
Abstract xi
Índice xii
Índice de Tablas xiv
Índice de Figuras xvi
Notación xviii
1 Introducción 1 1.1 Motivación 1 1.2 Solución técnica propuesta 3
2 Estado del arte 5 Dispositivos autónomos 5 Dispositivos asistidos 5
3 Estudio de los diferentes medios de comunicación 7 Elección del sistema de comunicación 7
3.1.1 Near Field Communications (NFC) 7 3.1.2 Wifi IEEE 802.11 7 3.1.3 Bluetooth Low Energy (BLE) 8
4 El dispositivo 11 4.1 Hardware 11
4.1.1 Requisitos del hardware 11 4.1.2 Diagrama de bloques 11 4.1.3 Descripción por bloques del sistema 12 4.1.4 Layout de la PCB 16 4.1.5 Hardware montado 17
4.2 Software 18 4.2.1 Sistema de posicionamiento en interiores, iBeacon 18 4.2.2 Entorno de desarrollo integrado elegido 21 4.2.3 Código Fuente 25
5 Pruebas de consumo 30
6 Presupuesto 31 6.1 Costes de desarrollo 31 6.2 Costes de fabricación prototipo 31
7 Conclusiones 33
8 Recomendaciones 34
Referencias 35
Glosario 37
xiii
ÍNDICE DE TABLAS
Tabla 3-1. Comparativa entre Bluetooth Classic y Bluetooth Low Energy 9
Tabla 4-1. Especificaciones técnicas del SoC nRF51822 12
Tabla 4-2. Características técnicas elevador TPS61040 15
Tabla 4-3. Relación entre tensión de alimentación y SOC 26
Tabla 5-1. Detalle de consumo del dispositivo 30
Tabla 6-1. Costes de desarrollo 31
Tabla 6-2. Costes de fabricación y montaje 31
xv
ÍNDICE DE FIGURAS
Figura 1-1. Mapa con los índices de robos con violencia 2
Figura 2-1. Detalle de cartera antirrobo [4] 5
Figura 2-2. Dispositivo antirrobo Tile Slim 6
Figura 3-1. Ejemplo de propagación de una señal inalámbrica 8
Figura 3-2. Organización de los objetos en GATT 10
Figura 4-1. Diagrama de bloques del sistema 11
Figura 4-2. Diagrama esquemático del nRF51822 14
Figura 4-3. Diagrama esquemático del elevador TPS61040 15
Figura 4-4. Amplificador clase AB 16
Figura 4-5. Capa inferior de la PCB 17
Figura 4-6. Capa de componentes de la PCB 17
Figura 4-7. Máscara de soldadura de la PCB 17
Figura 4-8. Fotografía del hardware ya montado 18
Figura 4-9. Las tramas de advertising se envían periódicamente 19
Figura 4-10. Comunicación entre periférico y escáner durante el advertising 19
Figura 4-11. Trama iBeacon 20
Figura 4-12. Captura de pantalla de Bluetooth Developoer Studio 21
Figura 4-13. Servicio de batería y a medida añadidos al perfil 22
Figura 4-14. Detalle de la configuración de la característica Buzzer 23
Figura 4-15. Generación del código fuente con el perfil GATT 24
Figura 4-16. Capura de pantalla de Keil en su repositorio de paquetes. 24
Figura 4-17. Pantalla de edición de código de Keil 25
Figura 4-18. Función que convierte la medida de tensión en SOC 26
Figura 4-19. Detalle de la función encargada de gestionar la señal PWM 27
Figura 4-20. Detalle de la señal PWM hacia el buzzer 27
Figura 4-21. Activación DC/DC 28
Figura 4-22. Función de inicialización del SoftDevice. 28
Figura 4-23. Definición para utilizar el reloj de 32 kHz interno 29
xvii
Notación
V Voltios
mV Milivoltios
mA Miliamperios
µA Microamperios
nA Nanoamperios
kbps Kilobits por segundo
Mbps Megabits por segundo
kHz Kilohercio
MHz Megahercio
GHz Gigahercio
dB Decibelio
dBm Decibelio tomando como referencia 1 mW
mW Milivatio
ppm Partes por millón
1 INTRODUCCIÓN
n este capítulo se van a exponer los diferentes motivos que han llevado al desarrollo del producto, así
como las diferentes razonamientos que se han seguido a lo largo del proyecto para cumplir con las
especificaciones de partida.
1.1 Motivación
Las carteras son objetos utilizados por prácticamente la totalidad de las personas. En ellas, llevamos
documentos de identidad, carnés, dinero, etc. Elementos todos de considerable valor.
Es por este motivo es que la pérdida o robo de la misma puede suponer un problema para el individuo; la
mayoría de las veces no es tan importante la pérdida económica como el hecho de tener que volver a solicitar
duplicados de toda la documentación. Por todo ello debemos tener especial cuidado con ella, intentando evitar
el abandono accidental o la posibilidad de ser robada.
El número de delitos en España en los seis primeros meses del año se han incrementado en un 0,8 por ciento
con respecto al mismo período de 2017, si bien la tasa de criminalidad1 se mantiene estable pese a dicho
aumento y se sitúa en el 43,3 por ciento.
En el primer semestre de 2017, el cómputo de infracciones penales ascendió a 999.924, mientras que en
mismo período de 2016 fue de 992.476, según el Balance de Criminalidad correspondiente al segundo
trimestre del año hecho público por el Ministerio del Interior. Esta cifra, pese a revelar un cierto incremento de
las infracciones penales, muestra “una estabilización” de la tasa de criminalidad.
Si analizamos el balance de criminalidad [1] publicado recientemente por el Ministerio del Interior
correspondientes al primer trimestre de 2018 y nos centramos en los robos y hurtos podemos apreciar una leve
reducción de estos.
Concretamente, en el primer trimestre de 2017 se acumuló un total de 38.722 delitos en todo el territorio
español; de los cuales, 13.573 pertenecieron a robos que implicaran algún tipo de violencia y el resto, 25.149
pertenecieron a hurtos. Sin emabrgo, en el mismo período de 2018 se produjeron un total de 34.595 delitos, de
los cuales 12.231 pertenecieron a robos con violencia, mientras que el resto, 22.364 corresponden a hurtos.
Al parecer, existen diferentes factores que provocan que determinadas provincias sean más propicias para el
desarrollo de hurtos de alguna clase. Por este motivo, se realizan estudios socioeconómicos de la población y,
en función de los resultados obtenidos, se desarrollan medidas preventivas optimizadas para cada lugar.
En este sentido, varios estudios apuntan al turismo como un “reclamo” para este tipo de delitos. Los turistas
constituyen una víctima fácil tanto por el valor de los objetos que portan (dinero en efectivo, varias tarjetas de
crédito, pasaportes que luego revenden en el mercado negro, cámaras fotográficas, móviles de alta gama…),
como el desconocimiento de los barrios de las diferentes ciudades y, en muchos casos, la barrera lingüística.
Precisamente, “los amigos de lo ajeno” pueden incluso deslazarse de un destino vacacional a otro para
desarrollar su actividad. Siguiendo muy de cerca a los turistas, las personas de avanzada edad son el segundo
objetivo prioritario de los carteristas.
Sin embargo, el turismo no es la única razón para el desarrollo de este tipo de delitos, también influyen otros
factores como por ejemplo la renta per cápita, es decir, el nivel económico de los habitantes de una
determinada región. Esto ofrece a los malhechores oportunidades para cometer robos.
1 La tasa de criminalidad mide el número de infracciones penales por cada mil habitantes.
E
Introducción
2
2
Figura 1-1. Mapa con los índices de robos con violencia
En la imagen anterior [2] podemos apreciar las provincias con mayor índice de robos con violencia en color
oscuro, mientras que las provincias con menor índice poseen un color más claro.
En nuestra ciudad sabemos que cuatro de cada diez delitos cometidos son hurtos [3]. Esta modalidad delictiva
es la más extendida de largo en la ciudad, y ha crecido un 2% durante el pasado año 2017 con relación al
ejercicio anterior.
En la capital andaluza se registraron 18.558 hurtos durante el año pasado, lo que supone un 39,6% del total de
los delitos, que fueron 46.901. La mayoría de estos pequeños robos se registraron en la capital hispalense,
puesto que en el total de la provincia se denunciaron 27.108 delitos de este tipo. La Policía Nacional está
ampliando los recursos destinados a combatir la actividad de grupos criminales especializados en cometer
hurtos en establecimientos comerciales, al detectar un incremento de esta actividad. Los hurtos son llevados a
cabo tanto por los hombres como por las mujeres en un mismo porcentaje. Suelen actuar en grupo o en
solitario, y utilizan elementos de apoyo para cometer su actividad delictiva. El valor de lo robado no suele
superar la cuantía de 400 euros para que, en caso de ser detenidos por la Policía, sean acusados de un delito de
hurto y no de robo. Esto hechos tienen condenas muy leves, casi irrisorias. De hecho, eran consideradas faltas
por el antiguo Código Penal y, en muchas ocasiones, no siquiera se detenía al autor del hurto. Las penas suelen
ser multas, lo que lleva a muchos delincuentes a pasarse a este tipo de delitos.
Como ya se ha dicho, no solo existe un tipo de robo, si no que también existe la apropiación de una cartera
olvidada accidentalmente, según registros policiales constituye uno de los principales motivos de denuncia.
Sea por un motivo u otro, lo cierto es que supone un problema para la persona afectada.
Dependiendo de la documentación extraviada, la recuperación de su totalidad puede suponer un periodo de
entre 15 días y 6 meses, con las implicaciones e inconvenientes que esto supone.
Por todo ello, la medida más importante para evitar la pérdida de una cartera es la prevención. Por este motivo
se han desarrollado diferentes dispositivos cuyo fin es alertar al usuario ante la separación inusual de la misma,
de modo que se puedan tomar las medidas oportunas para evitarlo. La tecnología disponible en la actualidad
permite la generación de dispositivos basados en la norma Bluetooth Low Energy. Sin embargo, muchos de
ellos no llegan a satisfacer las necesidades del usuario, bien porque la tecnología empleada no es la adecuada,
porque no funcionan adecuadamente o porque el precio del dispositivo es muy elevado.
Por estos motivos se propone desarrollar un producto que utilice los medios tecnológicos adecuados y sea
diseñado teniendo en cuenta los costes, de modo que se consiga un producto que sí satisfazca las necesidades
de los clientes.
3
1.2 Solución técnica propuesta
Se propone el desarrollo, tanto a nivel de hardware como de software, de un dispositivo que funcione por
proximidad, que respete las dimensiones necesarias para poder transportarlo en una cartera de tamaño medio,
sin exceder en tamaño ni en peso, que además posea la mayor autonomía posible, que sea compatible con la
mayoría de los smartphones del mercado y que sea económico.
Dada la complejidad del proyecto se propone:
1. Realizar un estudio previo de las diferentes normas de comunicación inalámbricas utilizadas por los
smartphones para determinar cuál se adapta mejor a los requisitos del proyecto.
2. Se elegirá un hardware que soporte la norma elegida durante el estudio y que requiera de poca energía
para funcionar, ya que la fuente de alimentación será muy limitada dado el reducido espacio con el
que se cuenta
3. Se elegirá un sistema de posicionamiento en interiores normalizado para aumentar la compatibilidad
del dispositivo y que, a su vez, sea compatible con la noma elegida.
4. Por último, se desarrollará el firmware necesario para funcionar teniendo en mente una política de
ahorro energético y respetando las normas seleccionadas para facilitar la compatibilidad del
dispositivo con los teléfonos móviles inteligentes existentes hoy en día.
Introducción
4
4
5
2 ESTADO DEL ARTE
ctualmente existen en el mercado diversos dispositivos destinados a alertar al usuario en caso de robo o
pérdida de una cartera o billetera, sin embargo, podemos reducirlos a dos grupos: los que funcionan de
manera autónoma y los que funcionan de manera asistida.
Dispositivos autónomos
Este tipo de dispositivos funcionan de manera autónoma, es decir, sin necesidad de otro dispositivo que le
asista. Su modo de operar se basa en el uso de algún tipo de sensor óptico que mide la luz que incide sobre el
dispositivo.
Al tratarse de un objeto que, por regla general, estará guardado en un lugar alejado de la luz, como puede ser
un bolsillo o un bolso, podemos detectar un uso no autorizado cuando este pase de una zona oscura, como las
mencionadas, a una zona iluminada.
El punto fuerte de este tipo de dispositivos es es la autonomía, ya que cuenta con energía para funcionar hasta
un año de manera ininterrumpida. Aunque esta cifra dependerá en gran medida del uso por parte del usuario.
Sin embargo, posee varios aspectos negativos.
El primero de ellos es que su batería no es reemplazable, de manera que al agotarse tendremos que desechar el
dispositivo y adquirir un dispositivo nuevo. Esto eleva el coste a largo plazo y favorece la acumulación de
desechos.
El segundo aspecto negativo es que se basan en una tecnología poco fiable, ya que al medir únicamente el
nivel de luz depende exclusivamente del desconocimiento por parte del malhechor para funcionar. Si un
asaltante conoce la existencia del dispositivo; solo se tendrá que preocupar en evitar que la luz incida sobre el
mismo para eludir el sistema de alerta.
Figura 2-1. Detalle de cartera antirrobo [4]
Por otro lado, también requiere la intervención del usuario cada vez que éste quiera hacer uso de su cartera, ya
que tendrá que desactivar el dispositivo con cada uso de esta, lo que implica un esfuerzo y activaciones
accidentales.
Dispositivos asistidos
Estos dispositivos no pueden funcionar por sí mismos, dependen de un teléfono móvil inteligente para
funcionar. A cambio, ofrecen muchas más funciones que la simple alerta en caso de robo.
A
Estado del arte
6
6
Utilizan comunicaciones inalámbricas basadas en la norma Bluetooth Low Energy (BLE); lo que les permite
mantener una autonomía considerable.
Por otro lado, utilizan protocolos que permiten conocer al teléfono móvil la distancia aproximada a la que se
encuentra el dispositivo, de modo que este actúe en consecuencia, alertando al usuario con una notificación o
una alarma sonora cuando el móvil y el dispositivo se separen una determinada distancia.
El principal aspecto negativo de este tipo de dispositivos es su elevado coste económico y la imposibilidad de
cambiar la batería. Aunque, en este caso, existen fabricantes como por ejemplo Tile [5], que ofrecen
descuentos al adquirir uno nuevo siempre y cuando se entrege el dispositivo antiguo.
Figura 2-2. Dispositivo antirrobo Tile Slim
El problema, al igual que en el de los dispositivos autónomos, es que se obliga al usuario a incurrir en un gasto
periódico al tener que adquirir un dispositivo nuevo, y se favorece la acumulación de residuos al desechar
dispositivos que aún funcionarían correctamente si se les cambiara la fuente de alimentación.
7
3 ESTUDIO DE LOS DIFERENTES MEDIOS DE
COMUNICACIÓN
ado que diseñaremos un dispositivo de los que hemos denominado asistido, en primer lugar
estudiaremos los diferentes medios de comunicación inalábrica disposibles en la mayoría de teléfonos
inteligentes, con el fin de elegir el que mejor se adapte al objetido del proyecto.
Actualmente los smarphones disponen de los siguientes sistemas de comunicación punto a punto:
• NFC.
• Wifi.
• Bluetooth
Elección del sistema de comunicación
3.1.1 Near Field Communications (NFC)
Fue aprobada como estándar ISO/IEC en 2003 [6], pero no fue hasta cinco años más tarde cuando se empezó a
ver en productos comerciales. Es una tecnología inalámbrica de corto alcance, unos 10 cms, que permite el
intercambio de información entre dos dispositivos a una tasa aproximada de 420 Kbps. Aunque es posible
transferir archivos pesados utilizado esta tecnología, su uso más habitual es para el traspaso de credenciales
entre dos dispositivos, como por ejemplo el código de emparejamiento de una comunicación Bluetooth o un
pago con tarjeta de crédito virtual. Esto es debido a que el corto alcance de la comunicación aporta un plus de
seguridad cuando se transfieren credenciales que, posteriormente, serán utilizadas en otro tipo de
comunicación de mayor alcance, como Wifi o Bluetooth.
La tecnología NFC puede funcionar de dos modos:
• Activo: Los dos dispositivos generan el campo magnético necesario para el intercambio de
información. Por ejemplo, al transferir una fotografía entre dos teléfonos móviles.
• Pasivo: Solo uno de los dos dispositivos es activo y genera el campo magnético. El restante se sirve
de este para alimentarse y responder a la comunicación. Es el utilizado en los abonos de transporte o
etiquetas, ya que estos carecen de una fuente de alimentación.
Desde el punto de vista de la seguridad, existe poca probabilidad de que nuestras comunicaciones se vean
comprometidas, esto es debido al corto acance de las mismas, sin embargo, esto no impide que un atacante
pueda copiar una tarjeta identificativa.
La característica que aporta la seguridad en esta comunicación es la que provoca descartar esta tecnología para
nuestro proyecto. Para nuestro dispositivo, 10 cm son totalmente insuficientes para un uso normal. Esto
obligaría a llevar constantemente el teléfono móvil y la cartera juntos, lo que se traduce en un problema de
usabilidad del dispositivo ya que a veces no es posible llevarlos juntos o, simplemente, que necesitamos
realizar una llamada telefónica.
Por este motivo, seguiremos analizando el resto de las opciones en busca de una tecnología más acertada.
3.1.2 Wifi IEEE 802.11
Es el nombre comercial que reciben todos los dispositivos que cumplen con alguna de las variantes de la
norma IEEE 802.11. Dicha norma se desarrolló para sustituir a la norma IEEE 802.3 (ethernet) y su principal
diferencia reside en la capa física, ya que se sustituye el cable de red por una comunicación totalmente
inalámbrica.
Las velocidades de transmisión que se pueden alcanzar hoy en día con esta norma superan 1Gbps gracias al
D
Estudio de los diferentes medios de comunicación
8
8
uso de varias bandas y a la aplicación de la tecnología MIMO.
La tecnología MIMO [7] se basa en un fenómeno recurrente en todas las comunicaciones inalámbricas, la
multitrayectoria. Este fenómeno se produce al recibirse en el receptor la señal transmitida directamente por el
emisor y posteriormente las diferentes reflexiones producidas al reflejarse la señal en los objetos situados entre
el emisor y receptor.
Figura 3-1. Ejemplo de propagación de una señal inalámbrica
En la figura anterior podemos ver el envío de una señal desde un router a un ordenador. La señal coloreada en
negro representa el camino directo, y más corto, desde el router hasta el ordenador. Sin embargo, la señal se
propaga en todas direcciones, rayos coloreados en azul y rojo. En ocasiones simplemente se pierde la señal,
pero en otras, se refleja en un edificio o un objeto y es recibida también por el receptor.
Como la distancia recorrida por un reflejo es mayor que la recorrida por el rayo directo, significa que una señal
reflejada llegará más tarde que la señal directa. Esto obliga a los sistemas de comunicación a detener la
transmisión un determinado tiempo para que las diferentes reflexiones lleguen al destino y poder iniciar así
una nueva transmisión. Este mecanismo reduce la probabilidad de error a la vez que también disminuye la tasa
de envío.
Sin embargo, la tecnología MIMO se aprovecha del fenómeno de la propagación multitrayectoria para
incrementar la tasa de envío y reducir la probabilidad de error.
Aplicado a nuestro dispositivo, una comunicación wifi implicaría un consumo energético elevado, teniendo en
cuenta que el espacio disponible para una fuente de alimentación es muy limitado. Por otro lado, generar un
punto de acceso inalámbrico para que el teléfono móvil se conecte implicaría, en la mayoría de los casos, una
pérdida de conexión a Internet del teléfono, ya que éste tomaría como conexión a Internet predeterminada la de
nuestro dispositivo, que carece de conexión a la Red.
Todo esto nos lleva a descartar la tecnología Wifi como sistema de comunicación para nuestro dispositivo.
3.1.3 Bluetooth Low Energy (BLE)
La norma Bluetooth dispone actualmente de dos perfiles, uno denominado clásico y otro denominado Smart o
Low Energy.
Blueooth Smart o Bluetooth Low Energy es una tecnología de comunicación inalámbrica de ámbito personal,
fue diseñada por el Bluetooth Special Interest Group para ayudar a las nuevas aplicaciones relacionadas con la
salud, entrenamiento, balizas, seguridad y la industria del entretenimiento doméstico.
Al contrario que en la versión clásica, donde el objetivo residía en conseguir el máximo rendimiento, el interés
se centró en reducir todo lo posible el consumo energético, de ahí que solo se pueda alcanzar actualmente tasas
de envío de 2 Mbps, aunque se mantiene el radio de alcance de unos 100 metros en campo abierto.
A continuación, se recoge una tabla [8] con las características más relevantes de cada versión:
9
Tabla 3-1. Comparativa entre Bluetooth Classic y Bluetooth Low Energy
Información Técnica Bluetooth Classic Bluetooth Low Energy
Distancia 100 m >100 m
Tasa de transferencia máxima 3 Mbps 2 Mbps
Tasa efectiva 2,1 Mbps 0.27 Mbps
Esclavos activos 7 Depende de la aplicación
Seguridad 56/128 bits.
Capa de aplicación definida por el
usuario
128-bit AES con CBC-MAC.
Capa de aplicación definida por el
usuario
Latencia (desde sin conexión) Típicamente 100 ms 6 ms
Tiempo mínimo de envío
(reduce batería)
100 ms 3 ms
Voz Sí No
Topología Red dispersa Red dispersa
Consumo 1 W 0,01 W – 0,50 W
Pico de consumo < 30 mA < 15 mA
Servicio de descubrimiento Si Si
Concepto de perfiles Si Si
La comunicación se basa en una topología en estrella, donde el dispositivo central actuaría como maestro y el
resto de los periféricos actuarían como esclavos.
Las transacciones entre un periférico y el maestro se realizan a través de GATT, donde el esclavo actuaría
como servidor GATT, ya que es el que posee las definiciones de los servicios y características, y el maestro
actuaría como cliente GATT, ya que es el que realiza las peticiones a los esclavos.
Es importante tener en cuenta que todas y cada una de las transacciones son iniciadas por el maestro, el cliente
GATT, las cuales recibirán una respuesta del esclavo, el servidor GATT. Cuando un maestro establece una
conexión con un esclavo, es este el que le sugiere unos intervalos de conexión al maestro. Sin embargo, es el
maestro el que decide en última instancia si acepta la sugerencia y respeta los intervalos de conexión o bien los
ignora.
Las transacciones GATT se basan en objetos de alto nivel denominados: Perfil, Servicio y Característica.
Dichos objetos se relacionan jerárquicamente, tal y como se puede apreciar en la figura siguiente.
Estudio de los diferentes medios de comunicación
10
10
Figura 3-2. Organización de los objetos en GATT
Como se puede apreciar en la figura anterior, un perfil GATT se compone de uno o más servicios. Dichos
servicios, a su vez, se componen de características donde realmente se almacena el dato en cuestión.
Imaginemos un perfil de un dispositivo que dispone de una batería. Podríamos añadir un servicio de
información de la batería. Dentro de dicho servicio podríamos incluir una característica que informara del
estado de carga de la batería. De modo que si un cliente GATT quiere conocer el SOC del sistema, solo tendría
que acceder al servicio de batería incluido dentro del perfil del sistema y, a continuación, solicitar la
característica “estado de carga”.
Tras analizar la forma de comunicación, donde el dispositivo puede sugerir los intervalos de conexión y
fomentar una política de reducción de consumo. Por estar específicamente diseñado para dispositivos como el
que pretendemos diseñar y por estar presente en prácticamente la totalidad de los dispositivos móviles;
elegiremos Bluetooth Low Energy como forma de comunicación para nuestro producto.
11
4 EL DISPOSITIVO
hora que ya hemos decidido el protocolo que utilizaremos para las comunicaciones, ya podemos
concretar las partes que compondrán el sistema. En primer lugar, detallaremos todas y cada una de las
partes del hardware teniendo en cuenta que se debe obtener como resultado un dispositivo de bajo
coste, así que se debe tratar de reducir al máximo el número de elementos del sistema.
4.1 Hardware
4.1.1 Requisitos del hardware
Antes de comenzar con el diseño debemos decidir los elementos deben componer el sistema para,
posteriormente, decidir cómo se implementarán.
• Dado que se necesitan comunicaciones inalámbricas; se debe disponer de un microcontrolador con los
periféricos necesarios para contar con comunicaciones BLE.
• El sistema contará con una pila reemplazable, de modo que es necesario estimar el estado de carga de
esta para poder avisar al usuario cuando la capacidad alcance un nivel crítico.
• Como se trata de un sistema de alerta al usuario, el hardware debe contar con un buzzer con potencia
suficiente como para captar la atención de las personas cercanas y detectar al malhechor. O bien, para
localizar la cartera en caso de pérdida.
4.1.2 Diagrama de bloques
En la siguiente figura podemos observar el diagrama con los bloques que formarán cada una de las partes del
sistema.
A
Figura 4-1. Diagrama de bloques del sistema
El dispositivo
12
12
4.1.3 Descripción por bloques del sistema
A continuación, se detallará cada uno de los bloques recogidos en la “Figura 4-1. Diagrama de bloques del
sistema”.
4.1.3.1 System on Chip nRF51822
Para realizar las comunicaciones, así como todo el funcionamiento del dispositivo se ha optado por un system
on chip de la serie NRF51 del fabricante Nordic Semiconductor. Sus integrados son bastante populares por su
potencia y ultra-bajo consumo. Además, el fabricante ofrece abundante documentación y soporte a los
desarrolladores, tanto a nivel de hardware como de software. Todo esto nos facilitará el desarrollo, reduciendo
costes y el time to market.
Los sistemas en chip o SoC, son cada vez más utilizados en la industria por utilizar técnicas de fabricación que
les permite contar en un mismo integrado con gran parte de los módulos necesarios en la mayoría de los
desarrollos. Esto se traduce en una reducción de elementos externos; lo que permite hacer sistemas más
pequeños y eficientes.
Para este proyecto necesitamos un SoC que diponga de, al menos, los siguientes elementos:
• 2 x Timers: Uno se utilizará para realizar las diferentes temporizaciones del sistema. El timer restante
se uttilizará para gestionar la señal PWM que se transmitirá al elevador.
• 1 x PWM: Señal utilizada para excitar el buzzer con el fin de producir la señal de alarma.
• 1 x ADC: Se utilizará un convertidor analógico-digital para medir la tension de alimentación. Esto nos
permitirá realizar una estimación del estado de carga de la batería.
• 2 x GPIO: Uno de los pines digitales de entrada se utilizará para conectar un pulsador; que se usará
para enviar una señal al dispositivo móvil. La otra señal digital se usará para activar el elevador de
tension que aportará la energía necesaria para excitar al buzzer.
Tras comprobar los dipositivos de la serie nRF51, vemos que todos disponen de recursos más que suficientes
para este proyecto, así que elegiremos el más económico de la serie; el nRF51822.
En la tabla sigueiente se recogen los datos técnicos más relevantes del nRF51822 [9]:
Tabla 4-1. Especificaciones técnicas del SoC nRF51822
CPU 32-bit ARM® Cortex™ M0 32-bit CPU
RAM 16 KB / 32 KB
Embedded flash 128 KB / 256 KB
Periféricos - 3 x 16/24-bit timers con modo Contador
- 16 canales independientes del CPU Programmable Peripheral Interconnect
(PPI)
- Coprocesador de encriptación 128-bit AES ECB/CCM/AAR
- RNG
- RTC
- Sensor de temperatura
GPIO - Configuración de pines de propósito general flexible
- Hasta 31 pines de propósito general
13
- Hasta 4 salidas PWM
Entras/Salidas
digitales
- Interfaces digitales SPI maestro/esclavo, TWI, UART
- Decodificador en cuadratura
Entradas/Salidas
analógicas
- Convertidor analógico-digital 8/9/10-bits configurable en 8 canales
- Comparador de baja potencia
Osciladores - 16 MHz XO
- 16 MHz RCOSC
- 32 MHz XO
- 32 kHz XO
- 32 kHz RCOSC
Gestión de energía - Amplio voltaje de alimentación (1,8 V a 3,6 V)
- Esquema de gestion de energía flexible
- Convertidor DC/DC integrado
Consumo - 6.3 mA TX a -4 dBm (3 V usando DC/DC integrado)
- 8.0 mA TX a 0 dBm (3 V usando DC/DC integrado)
- 10.5 mA TX a 0 dBm (sin usar DC/DC integrado)
- 11.8 mA TX a +4 dBm (3 V usando DC/DC integrado)
- 9.7 mA RX (3 V usando DC/DC integrado)
- 13 mA RX a 1 Mbps (sin usar DC/DC integrado)
- 0,6 µA – Sistema apagado, sin retención en RAM
- 1,2 µA – Sistema apagado, reteniendo 8 kB de RAM
- 2,6 µA – Sistema encendido, todos los periféricos en reposo
Radio a 2,4 GHz
multiprotocolo
- Potencia de salida configurable entre +4 dBm y -20 dBm en pasos de 4 dBm
- Potencia de salida en modo susurro -30 dBm
Sensibilidad - -96 dBm a 250 kbps
- -90 dBm a 1 Mbps
- -85 dBm a 2 Mbps
Tasas de
transferencia
- 250 kbps
- 1 Mbps
- 2 Mbps
Después de consultar la documentación facilitada por Nordic Semiconductor2 referente al diseño del hardware,
se ha llegado a la conclusion de que el bloque correspondiente al microcontrolador debe ser tal y como se
recoge en la “Figura 4-2. Diagrama esquemático del nRF51822”.
2 La documentación consultada se puede encontrar en el sisito web de Nordic Semiconductor. Concretamente en la URL: https://www.nordicsemi.com/eng/Products/Bluetooth-low-energy/nRF51822#hardware
El dispositivo
14
14
Figura 4-2. Diagrama esquemático del nRF51822
En el esquemático se ha suprimido el reloj externo de 32,768 kHz ya que el nRF51822 cuenta con uno interno
que, pese a consumir algunos nanoamperios más que un reloj externo, entendemos que no supondrá un gran
impacto en la vida de la batería y, sin embargo, sí supondrá un coste extra y un aumento del tamaño del
dispositivo resultante. De modo que resulta más ventajoso suprimirlo que incorporarlo en este diseño.
Por otro lado, se han incorporado las señales de enable, PWM y botón en los pines que mejor se acomodan a la
hora de rutar las pistas en la placa de circuito impreso. Esto ha sido posible gracias a que el integrado incorpora
la interconexión de periféricos programable, de modo que podemos redirigir las diferentes señales al pin que
mejor se adapte a nuestras necesidades.
En cuanto a la gestión de la batería, se ha conectado la alimentación directamente a la entrada analógica
número 2, que corresponde a la entrada desiganada con el nombre P0.01. Para poder hacer esto, se debe tener
en cuenta que el sistema no se puede alimentar a una tensión superior a 3,6 V, de modo que la batería debe
tener una tensión nominal de 3 V y debe ser no recargable. Evitando así la necesidad de incorporar un cargador
y un fuel gauge encargado de calcular el estado de carga.
Como la fuente de alimentación será una batería no recargable, no se justifica el uso de un fuel gauge para
medir con precisión el estado de carga. Puede usarse el convertidor analógico-digital incluido en el integrado
para realizar una estimación del estado de carga basándonos en la tensión de alimentación, donde el 100% de
la capacidad se encontrará cuando la tensión de alimentación se encuentre a 3,6 V y el 0% se encontrará al
alcanzar los 1,8V, tensión mínima de funcionamiento del nRF51822.
15
4.1.3.2 DC/DC Elevador TPS61040
Como se ha visto, la alimentación estará limitada a un máximo de 3,6 V. Tensión totalmente insuficiente como
para excitar el buzzer y obtener un volumen lo suficientemente alto como para llamar la atención del usuario.
Es por esto por lo que se ha optado por utilizar un DC/DC elevador de tensión. Dicho elevador aportará a su
salida una tensión regulada de 18 V. De manera que la señal PWM con 1,8 Vpp procedente del nRF51822 se
transformará en una señal PWM de 18 Vpp, lo que permitirá aumentar la intesidad sonora considerablemente.
Para esta función se ha seleccionado un integrado del fabricante Texas Instruments. Concretamente el modelo
TPS61040 cuyas características principales son [10]:
Tabla 4-2. Características técnicas elevador TPS61040
Rango de tensión de entrada De 1,8 V a 6 V
Rango de tensión de salida Ajustable desde VIN hasta 28 V
Corriente interna del conmutador 400 mA
Frecuencia de conmutación 1 MHz
Corriente de fuga sin carga Típicamente 28 µA
Corriente apagado Típicamente 1 µA
Siguiendo las recomendaciones de Texas Intruments para este disposivito, se ha realizado el siguiente
esquemático:
Figura 4-3. Diagrama esquemático del elevador TPS61040
Como se puede apreciar en el esquemático, de ha conectado la entrada de Enable del integrado a la señal de
habilitación del nRF51822, de manera que el software pueda activar el elevador solo en el momento de
utilizarse. Esto mejorará el consumo general del sistema ya que, como se puede apreciar en la “Tabla 4-2.
Características técnicas elevador TPS61040”, el consumo del integrado apagado es de tan solo 1 µA, mientras
que el consumo del sistema encendido sin carga es de 28 µA.
Dado que por regla general el buzer no estará funcionando, estaremos reduciendo el consumo en 27 µA solo
tomando esta simple medida.
4.1.3.3 Acondicionamiento de señal PWM
La señal PWM procedente del SoC no se puede utilizar directamente para excitar el buzzer. Esta señal necesita
El dispositivo
16
16
ser acondicionada para que disponga de la potencia necesaria para atacar al buzzer. Es por esto por lo que se
eligió el elevador de tensión descrito en el punto 4.1.3.2 para que aporte la potencia necesaria.
Sin embargo, a persar de contar con el nivel de tensión adecuado a la salida del elevador de tensión, es
necesario diseñar un amplificador que aumente la señal PWM y le añada la potencia necesaria para escitar el
buzzer.
Para esto se ha utilizado un circuito amplificador de clase AB tal y como se recoge en la Figura 4-4.
Amplificador clase AB.
Figura 4-4. Amplificador clase AB
Este tipo de amplificador es utilizado frecuentemente en circuitos de audio por tener un alto rendimiento y
calidad. Su principal incoveniente es una distorsión al paso por cero de la señal debida a la tensión de
polarizanción de los diferentes transistores, sin embargo, no es un problema en nuestra aplicación. Esto es
debido a que nuestra señal es de tipo PWM, de modo que conmutará entre la tensión de alimentación y tierra.
Los transistores encargados de excitar el buzzer son Q2 y Q3, mientras que Q1 será el encargado de polarizar a
los dos anteriores; dado que la tensión de polarización podría dañar la salida digital del SoC.
El modo de funcionamiento del circuito es sencillo. Cuando la señal PWM se encuentre a nivel alto provocará
la saturación del transisitor Q1, por el contrario, cuando la señal PWM tenga el nivel bajo provocará el corte
del transisor Q1. De modo que el transistor solo trabajará en saturación o en corte, nunca en lineal.
Como se ha visto en el párrafo anterior, el transistor Q1 solo trabajará en corte o saturación, de modo que las
bases de los transistores Q2 y Q3 estarán conectadas prácticamente a la tensión de alimentación o tierra, según
esté la señal PWM a nivel bajo o alto respectivamente. Esto implica que también trabajarán ambos en
saturación o corte.
Al ser Q2 un transistor bipolar tipo N y Q3 un transistor bipolar tipo P responderán de manera opuesta ante la
misma señal de excitación. Esto provocará que, cuando Q1 esté saturado, Q2 esté en corte y Q3 esté saturado,
conectando la salida negativa del buzzer a tierra y estableciendo una diferencia de potencial de 18 Voltios
entre los terminales del buzzer.
Por el contrario, cuando el transistor Q1 esté en corte, Q2 estará saturado y Q3 estará en corte, conectado la
salida negativa a alimentación y estableciendo una diferencia de potencial de prácticamente 0 Voltios entre los
terminales del buzzer.
4.1.4 Layout de la PCB
Ahora que ya se conoce qué elementos formarán parte del sistema y cómo se interconectan entre sí, es
momento de distribuirlos físicamente por la PCB.
Tras analizar los componentes necesarios y los elementos que componen el sistema se llegó a la conclusión de
17
que una PCB de dos capas era suficiente para este proyecto, de modo que se pudiera ahorrar costes de
fabricación también en este elemento.
A continuación, se recogen los gerbers necesarios para la fabricación de la placa PCB.
Figura 4-5. Capa inferior de la PCB
Figura 4-6. Capa de componentes de la PCB
Figura 4-7. Máscara de soldadura de la PCB
La parte más interesante del rutado se encuentra en la esquina inferior izquierda, donde se sitúa la parte de
radiofrecuencia del sistema y el reloj.
En cuanto a la parte de radiofrecuencia, se ha tenido en cuenta las restricciones del fabricante de la antena
cerámica, el cual recomienda mantener la antena en una zona libre de componentes y planos de tierra para
maximizar la recepción/transmisión de la señal. Además, se seleccionó esta posición para que la zona libre de
componentes quedara fuera de la PCB para poder minimizar el tamaño de la placa.
En el caso del cristal de 16 MHz, se ha tenido en cuenta que se trata de una señal diferencial. De modo que se
ha situado y rutado de manera que las pistas posean la misma impedancia, de modo que las señales se verán
afectadas en la misma medida por las diferentes perturbaciones.
4.1.5 Hardware montado
Como resultado de todo el proceso de diseño, fabricación y montaje tenemos un hardware completamente
El dispositivo
18
18
funcional a la espera del correspondiente software.
Figura 4-8. Fotografía del hardware ya montado
4.2 Software
4.2.1 Sistema de posicionamiento en interiores, iBeacon
iBeacon es el nombre comercial con el que Apple denomina a su sistema de posicionamiento en interiores.
Sistema que fue introducido en la séptima versión de su sistema operativo para teléfonos inteligentes y tablets,
el cual vio la luz en septiembre de 2013 [11]. Aunque actualmente es compatible también con dispositivos con
sistema operativo Android.
Es una tecnología que se apoya en Bluetooth Low Energy para establecer una región alrededor de un objeto.
Esto permite que un dispositivo inteligente determine cuándo ha entrado o salido de una región y actuar en
consecuencia, ya sea mostrando una determinada notificación o alertando al usuario.
El enfoque inicial se centró en la publicidad. Se podían disponer balizas en centros comerciales o museos, de
manera que los usuarios al acercarse a determinados lugares recibieran ofertas personalizadas, o bien,
recibieran información extra del objeto que estaban contemplando, en el caso de un museo.
Sin embargo, pronto se le otorgó más usos a esta tecnología. Colocando una baliza compatible con iBeacon en
un objeto personal o en un vehículo, podíamos potenciar su utilidad más allá que mostrar publicidad. Podemos
programar nuestro dispositivo móvil para que realice determinadas acciones al acercarnos al coche o al
alejarnos de las llaves.
Esto lo convierte en el sistema de posicionamiento ideal para nuestro dispositivo, ya que es compatible con la
gran mayoría de dispositivos móviles de la actualidad. Por otro lado, fue diseñado específicamente para
establecer regiones entorno a un dispositivo para que los teléfonos móviles determinaran la distancia al emisor
y actuaran en consecuencia. Que es precisamente lo que estamos buscando.
4.2.1.1 Funcionamiento de iBeacon
Para entender cómo funciona iBeacon, primero debemos entender cómo funciona el mecanismo de advertising
en Bluetooth Low Energy.
En Bluetooth se utilizan 40 radiocanales en la banda ISM de 2,4 GHz separados por 2 MHz [12]. La norma
Bluetooth define 2 tipos de canales transmisión:
• Advertising: Se reservan los canales 37, 38 y 39 para este tipo de transmisión. Corresponden a la parte
baja del especto, al centro y a la parte alta respectivamente.
• Data: Se reservan los 37 canales restantes para este tipo de comunicación.
19
Toda comunicación entre un dispositivo y un periférico comienza de la misma manera. El periférico se inicia
en modo advertising.
Durante este modo, se envían tramas de advertising periódicamente utilizando al menos uno de los tres canales
destinados a las transmisiones de advertising, exista un dispositivo dentro de área de alcance o no.
Figura 4-9. Las tramas de advertising se envían periódicamente
Las tramas de advertising portan información básica del propio periférico, como por ejemplo la dirección
física del emisor, la dirección física del receptor (en caso de ser una transmisión dirigida), el preámbulo,
CRC… pero lo que realmente es interesante es la carga de datos. Una trama de advertising puede contener
hasta 31 Bytes de carga útil.
Cuando un dispositivo escanea el aire en busca de periféricos; “escucha” los diferentes canales de advertising a
la espera de que los diferentes dispositivos envíen sus tramas. Al recibir una trama de advertising, se reponde
con una petición de escaneo para que el periférico le remita el resto de la información en caso de ser necesario.
En caso de que el dispositivo no esté autorizado a comunicarse con el periférico se rechazará su petición de
escaneo.
Figura 4-10. Comunicación entre periférico y escáner durante el advertising
La tecnología iBeacon aprovecha el espacio de datos disponible en la trama de advertising para insertar su
trama propietaria. Concretamente inserta los siguientes campos:
El dispositivo
20
20
Figura 4-11. Trama iBeacon
La parte realmente interesante de la trama corresponde a los 21 Bytes designados con el color azul, ya que el
prefijo está fijado y no cambia entre los diferentes dispositivos.
En cuanto al UUID, al Major y al Minor; se utilizan para distinguir a una baliza iBeacon de otra y poder así
localizar al usuario en una ubicación. Su utilización es bastante sencilla; el UUID identifica a la empresa, el
Major identifica al establecimiento y el Minor identifica a una sección o pasillo concreto dentro del
establecimiento. Veamos un ejemplo práctico:
Una cadena de supermercados quiere lanzar promociones específicas en determinados productos de
establecimientos concretos. Para esto, dispondría en las diferentes secciones de sus establecimientos balizas
iBeacon.
Establecería el campo UUID con su identificador de empresa, a continuación, asignaría a su establecimiento
de Sevilla un identificador Major, a su establecimiendo de Cádiz se le asignaría otro identificador Major
diferente, etc. Por último, cada establecimiento asignaría un identificador Minor único a cada sección.
De este modo, cuando un cliente se aproxime a una sección que dispone de una oferta especial, se le notificaría
a través de su disposivio móvil la existencia de dicha oferta.
Por otro lado, disponemos de un campo denominado potencia de transmisión. Este campo es el más
importante ya que nos permitirá calcular la distancia entre la baliza y el dispositivo móvil. Para poder lograrlo,
este campo recoge la potencia de transmisión en dBm que debería recibir el dispositivo móvil si se situara a 1
metro de la baliza.
Comparando la potencia de la señal recibida de la baliza con la potencia que se debería recibir a 1 metro
podemos estimar la distancia a la que nos encontramos. Dado que nos encontramos ante una transmisión
inalámbrica, existen múltiples factores que pueden alterar la potencia recibida por el dispotivo, de modo que
este dato no puede tomarse como una medida exacta, sin embargo, sí podemos usarlo como una aproximación
relativamente buena de la distancia.
4.2.1.2 Implementación de iBeacon
En nuestro caso, utilizaremos el identificador UUID para identificar a nuestra empresa, pero utilizaremos el
Major y el Minor como símples identificadores para distinguir a un dispositivo de otro, no tendrán mayor
significado que este. Por el contrario, el campo más relevante es el de la potencia de transmisión, ya que nos
permitirá estimar la distancia aproximada a la que se encuentra nuestro dispositivo y, por tanto, actuar en
consecuencia.
21
4.2.2 Entorno de desarrollo integrado elegido
Para llevar a cabo el desarrollo del software se han seleccionado dos entornos de desarrollo integrado:
• Bluetooth Developer Studio: Utilizado para generar una plantilla básica con los diferentes perfiles
GATT.
• Keil µVision: Entorno de desarrollo utilizado para programar todo el software partiendo de la plantilla
generada en Bluetooth Developer Studio.
4.2.2.1 Bluetooth Developer Studio
Bluetooth Developer Studio [13] es una herramienta de software gratuita desarrollada por la Bluetooth SIG.
Esta herramienta facilita la tarea a la hora de generar los diferentes perfiles GATT ya que posee una interfaz
muy visual y sencilla.
Los perfiles generados con esta herramienta cumplen en su totalidad las especificaciones impuestas por el
Bluetooth SIG. Además, genera el código fuente necesario para hacer uso del perfil GATT generado.
Esto facilita enormemente el trabajo del desarrollador, ya que puede pasar rápidamente al desarrollo de su
aplicación concreta en lugar de invertir tiempo en desarrollar código para cumplir las especificaciones.
Cuando accedemos a la interfaz principal del programa, vemos una ventana como la siguiente:
Figura 4-12. Captura de pantalla de Bluetooth Developoer Studio
Como se puede ver en la captura de pantalla, el software ya cuenta con una serie de perfiles Bluetooth ya
configurados y listos para ser utilizados en su barra de navegación lateral. Estos perfiles se ajustan a los
descritos por el Bluetooth SIG, de modo que serán compatibles con todos los dispositivos que soporten dichos
perfiles.
Lo único que tendremos que hacer para incorporar uno o varios de estos perfiles es arrastrarlos desde la barra
de navegación de la derecha a la parte izquierda y ya quedará incluido en nuestro proyecto.
El dispositivo
22
22
Dado que contaremos con una batería y un estimador del estado de carga, sería recomendable añadir el
servicio de batería. Dicho servicio cuenta con una característica normalizada para informar del estado de carga,
para más información acerca de este servicio consultar el Anexo I: Battery Service Specification.
De esta manera facilitaremos el trabajo de los desarrolladores de la aplicación del teléfono; ya que podrán
utilizar APIs destinadas a tal fin.
Sin embargo, dado que nuestro sistema dispone de funcionalidades muy específicas; será necesario crear un
servicio a medida.
Dicho servicio deberá contar con diversas características que nos permitan conocer el estado del sistema, así
como activar la señal de alarma:
• Device Name: Permite modificar el nombre del sistema. Útil cuando nos encontramos en un entorno
con más de un dispositivo del mismo tipo. Esta característica contará con permisos de lectura y
escritura. Se debe generar una característica propia porque la característica destinada a realizar este fin
no puede ser editada en dispositivos iOS.
• PIN: Permite cambiar el código PIN utilizado durante el emparejamiento. Esta característica cuenta
con permiso de lectura y escritura.
• Status: Recoge el estado del botón integrado en el dispositivo, así como el modo de funcionamiento.
Esta característica contará con los permisos de lectura, escritura y notificación.
• Alarm: Permite activar la alarma del dispositivo. Esta característica contará con los permisos de
lectura y escritura.
Figura 4-13. Servicio de batería y a medida añadidos al perfil
Para añadir una característica a un servicio, bastará con pulsar sobre el botón marcado con un signo “+”, acto
seguido se generará la característica y deberemos rellenar los diferentes campos, entre los que podemos
destacar: el nombre de la característica y los diferentes permisos de acceso por parte del cliente GATT.
23
Figura 4-14. Detalle de la configuración de la característica Buzzer
Gracias al uso de plug-ins en Bluetooth Developer Studio, podremos generar un código básico para nuestro
SoC totalmente compatible con el SoftDevice del fabricante. Dicho código podrá ser incorporado a nuestro
proyecto en Keil fácilmente.
Para generar el código bastará con pulsar en el menú “Tools” -> “Generate Code” o bien, presionar la
combinación de teclas “Ctrl+G”. Tras esto se abrirá una ventana nueva donde tendremos que seleccionar el
plugin de Nordic Semiconductor y pulsar el botón “Generate”.
El dispositivo
24
24
Figura 4-15. Generación del código fuente con el perfil GATT
4.2.2.2 Keil µVision IDE
Un entorno de desarrollo integrado se caracteriza por ofrecer al desarrollador un conjunto de herramientas
útiles para el desarrollo de software. En el caso de Keil; se combina la gestion de proyectos, el entorno en
tiempo de ejecución, los mecanismos de compilación, la edición de código y la depuración de un programa en
un mismo entorno de desarrollo.
El depurador integrado nos proporciona las herramientas habituales de un entorno de pruebas, como puede ser
el uso de breakpoints, acceso a los registros de la CPU, ejecución paso a paso, acceso a memoria…. Por otro
lado, también nos dota de las herramientas de verificación y optimización necesarias para que podamos
obtener el máximo rendimiendo de nuestro hardware.
Figura 4-16. Capura de pantalla de Keil en su repositorio de paquetes.
25
Uno de los puntos fuertes de Keil es su repositorio. Gracias a él, no es necesario estar comprobando
periódicamente las actualizaciones de librerías de los diferentes fabricantes, solo será necesario acudir al
repositorio y pulsar sobre el paquete que requiera una actualización o bien necesitemos instalar para nuestro
proyecto. Lo que resulta muy cómodo cuando se trabaja con varias plataformas.
El editor de código posee resaltado de sintaxis que, pese a no ser de los mejores, tiene las características
necesarias para cumplir con su función.
Figura 4-17. Pantalla de edición de código de Keil
Por otro lado, en la barra de funciones, tenemos acceso directo a todas las funciones organizadas por archivos
fuente que las contienen, de manera que se reduce mucho el tiempo cuando debermos modificar un código
dentro de una función concreta de un archivo concreto.
4.2.3 Código Fuente
Dado que el código fuente de la aplicación es muy extenso y complejo como para recogerlo al completo, nos
centraremos únicamente en los fragmentos de código realmente interesantes para el desarrollo del firmware.
4.2.3.1 Estimación del estado de carga
Cuando un usuario se conecta al dispositivo, se dispara un evento BLE_GAP_EVT_CONNECTED, que
utilizaremos para iniciar un timer periódico. Cada vez que se produzca un timeout, el callback del timer
disparará una conversión del ADC.
Cuando la conversión se haya completado, se disparará el callback del convertidor analógico digital,
El dispositivo
26
26
recibiendo como parámetro el valor digital medido. Para obtener el valor del SoC llamaremos a la función
“adc_to_soc()”, la cual recibirá como parámetro el valor digital medido por el convertidor y devolverá el
estado de carga correspondiente.
Figura 4-18. Función que convierte la medida de tensión en SOC
En primer lugar, limpiamos los 6 bits más significativos, ya que el convertidor solo ha rellenado los 10 bits
menos significativos. De ahí que se aplique la máscara “0x3FF”. A continuación, se convierte la medida
recibida a milivoltios y se guarda en la variable “mV”.
Una vez se dispone de la tensión de alimentación en milivoltios, se calcula el SOC correspondiente sabiendo
que:
Tabla 4-3. Relación entre tensión de alimentación y SOC
Tensión SOC correspondiente
3000 mV 100 %
1800 mV 0 %
Como se recogió durante el diseño del hardware, la tensión de alimentación partirá de los 3600 mV para el
caso de una pila CR2032 nueva (consultar Anexo II: Datasheet Energizer CR2032), sin embargo, no estamos
teniendo en cuenta esos 600 mV para el cálculo del SOC.
Esto es debido a que la tensión suele caer relativamente rápido desde los 3600mV a los 3000 mV, tensión
nominal de este tipo de baterías. Esto sería interpretado por el usuario como un consumo elevado cuando en
realidad no ha sucedido así. Para evitar esa mala experiencia truncaremos el máximo en la tensión nominal de
la batería y haremos que nuestra función sature en 100%.
27
4.2.3.2 Gestión de la señal PWM
Para generar esta señal utilizaremos directamente el periférico encargado de generar señales PWM del
nRF51822. Sin embargo, debemos aplicar una política de ahorro energético. Para esto, debemos tener en
cuenta que cuando inicializamos un periférico el consumo aumenta, puesto que dicho periférico está
encendido.
Dicho esto, debemos gestionar el periférico de manera que cada vez que querámos generar una señal PWM
debamos inicializar el periférico, configurarlo y activarlo. Cuando ya no sea necesario, aunque sea por un
breve intervalo de tiempo, debemos detenerlo y liberar los recursos. Solo así se mantendrá apagado el máximo
tiempo posible y podremos ahorrar el máximo de energía.
Figura 4-19. Detalle de la función encargada de gestionar la señal PWM
La función “Buzzer_control()” se llama periódicamente mientras la bandera “BuzzerEnable” esté activa, en
caso contrario se llamará a la función “pwm_stop()”, encargada de detener la señal PWM y liberar todos los
recursos.
Mientras la bandera “BuzzerEnable” esté activa, la función “Buzzer_control()” ira encendiendo y apagando la
señal PWM según los tiempos fijados en las definiciones DEFAULT_TON y DEFAULT_TOFF.
Figura 4-20. Detalle de la señal PWM hacia el buzzer
El dispositivo
28
28
Como se puede apreciar en la figura anterior, podemos ver que DEFAULT_TON indica el tiempo que
permanecerá la señal PWM activa y, por tanto, haciendo sonar el buzzer a una frecuencia fija. Por el contrario,
DEFAULT_TOFF recoge el tiempo que permanecerá la señal PWM desactivada.
Esta forma de excitar el buzzer provocará un sonido intermitente fácimente reconocido por el usuario a pesar
del posible ruido ambiental.
Para más información sobre la señal PWM consultar el “Anexo III: Modulación por ancho de pulso (PWM)”.
4.2.3.3 Activar DC/DC interno
Otro aspecto importante de cara a mejorar el consumo energético es activar el convertidor DC/DC interno del
nRF51288 en lugar del regulador lineal que viene activado por defecto. Para conseguirlo bastará con añadir la
siguiente instrucción al inicio del programa, para que este entre en funcionamiento lo antes posible.
Figura 4-21. Activación DC/DC
4.2.3.4 Configurar reloj de 32,768 kHz interno
En la sección correspondiente al diseño del hardware se decidió suprimir el reloj de 32,768 kHz externo. Esta
decisión se tomó con el fin de reducir costes y tamaño. De modo que es de vital importancia configurar
correctamente el nRF51, de lo contrario no arrancará.
Para realizarlo, acudiremos a la función encargada de configurar el SoftDevice, en este caso “ble_stack_init()”,
dentro del archivo main.c
Figura 4-22. Función de inicialización del SoftDevice.
29
La línea concreta que establece la configuración del reloj es la perteneciente a la declaración de la variable
“clock_lf_cfg”. Concretamente, la configuración a usar está tras la definición “NRF_CLOCK_LFCLKSRC”.
Figura 4-23. Definición para utilizar el reloj de 32 kHz interno
Como podemos ver en la definición, el campo “source” de la estructura recoge la definición correspondiente al
reloj RC interno del nRF51822. Por otro lado, en el campo “xtal_accuracy” recoge la precisión del este en
ppm.
Pruebas de consumo
30
30
5 PRUEBAS DE CONSUMO
na vez finalizada la fabricación y el posterior montaje del prototipo, se llevó a cabo un estudio del
consumo energético del mismo en diferentes situaciones con el fin de poder realizar una estimación de
la vida útil de la batería.
Los resultados obtenidos se han resumido en la siguiente tabla:
Tabla 5-1. Detalle de consumo del dispositivo
Estado Consumo
Resposo enviando tramas de advertising 34 µA
Dispositivo móvil conectado 34 µA
Consumo máximo en transmisión a 0 dBm 1,2 mA
Consumo señal PWM activa 15,7 mA
Dado que una batería de tipo CR2032 no recargable posee una capacidad media de 235 mAh [14] podemos
realizar una aproximación del tiempo de vida de la batería. Para hacerlo, supondremos despreciable el
consumo al transmitir una trama de advertising.
𝑇𝑟𝑒𝑝𝑜𝑠𝑜 =235 𝑚𝐴ℎ
0,034 𝑚𝐴= 6.911,76 ℎ𝑜𝑟𝑎𝑠 = 287,99 𝑑í𝑎𝑠 = 9,6 𝑚𝑒𝑠𝑒𝑠
𝑇𝐴𝑙𝑎𝑟𝑚𝑎 =235 𝑚𝐴ℎ
15,7 𝑚𝐴= 14,97 ℎ𝑜𝑟𝑎𝑠
U
31
6 PRESUPUESTO
ara realizar el presupuesto, separaremos lo que se puede considerar como costes de desarrollo y costes de
fabricación del prototipo.
6.1 Costes de desarrollo
En esta sección se recogerán todos los costes imputables al desarrollo del producto, no así los gastos
relacionados con la fabricación y montaje del prototipo.
Tabla 6-1. Costes de desarrollo
Concepto Precio Unidades Total
Horas de ingeniería 90 €/h 480 horas 43.200 €
Licencia de Keil 1.569,50 € 1 licencia 1.569,50 €
Licencia de Altium 2.356,30 € 1 licencia 2.356,30 €
Diseño de envolvente 300 € - 300€
Fabricación de moldes 2600 € - 2600€
Total 50.025,8 € (iva no incl.)
6.2 Costes de fabricación prototipo
En esta sección se recogen todos los gastos relativos a la fabricación del dispositivo.
Tabla 6-2. Costes de fabricación y montaje
Concepto Precio Unidades Total
nRF51822 2,53 € 1 2,53 €
TPS61040 0,69 € 1 0,69 €
Buzzer 0,09 € 1 0,09 €
PCB 4,86 € 1 4,86 €
Condensadores - 15 0,75 €
Resistencias - 5 0,25 €
Bobinas - 4 0,35 €
P
Presupuesto
32
32
Interruptor 2,73 € 1 2,73 €
Reloj 16 MHz 0,50 € 1 0,50 €
Pulsador 0,42 € 1 0,42 €
Antena 2,4 GHz 0,35 € 1 0,35 €
Transistores - 3 0,45 €
Diodo 0,10 € 1 0,10 €
Envolvente 0,20 € 1 0,20 €
Total 14,27 €
33
7 CONCLUSIONES
na vez finalizado el proyecto podemos reflexionar sobre los requisitos de partida y ver si se han podido
cumplir o no.
En primer lugar, analizaremos los datos de consumo. Según podemos ver en el punto 5, el dispositivo
puede estar en reposo de manera initerrumpida durante más de 9 meses. Es decir, si el usuario se preocupa de
hacer un buen uso de la energía y desconectar el dispositivo mientras duerme, superaría el año de autonomía
con una sola pila. Esto es un claro éxito para un dispositivo de estas características.
El siguiente requisito era en cuanto a dimensiones del producto final. El objetivo era que el dispositivo debía
entrar en una cartera de tamaño medio. En este aspecto, no se ha conseguido marcar una gran diferencia
respecto a la competencia, pero a pesar de esto, se ha conseguido.
El requisitio más importante era conseguir un dispositivo de bajo coste, que sea lo que realmente le otorgue un
nicho de mercado y posibilidad de éxito. En este caso vemos que el objetivo se ha conseguido con creces.
Hemos obtenido un coste realmente bueno, teniendo en cuenta que se ha fabricado un único prototipo. Cuando
se decida fabricar en serie los costes se reducirán algo más.
U
Recomendaciones
34
34
8 RECOMENDACIONES
e cara a una futura revisión del proyecto y, ahora que se posee más información de este, recomendaría
realizar algunas modificaciones.
1. Sustituir el SoC por uno de la familia nRF52: Esta serie será totalmente compatible con la nueva
versión de la norma Bluetooth, la 5.0. Que dispondrá de diversos perfiles de conexión, entre otros, un
perfil de bajo consumo energético aumentando el alcance. Sería interesante estudiar esta nueva vía ya
que el software sería compatible prácticamente en su totalidad.
2. Añadir soporte para la lista de permitidos: Permitir única y exclusivamente la conexión al primer
dispositivo que se conecta utilizando una lista de permitidos basada en la dirección física del teléfono
móvil. De este modo, si se pierde la conexión durante un momento, se realizará un advertising
dirigido y solo será visible el dispositivo para el móvil del propietario.
3. Volumen configurable: Sustituir la red de realimentación del DC/DC por un potenciómetro digital
para poder configurar el volumen del buzzer por software.
4. Añadir actualizaciones OTA: Implementar un soporte para actualizaciones permitiría añadir funciones
nuevas incluso después de haber lanzado el producto al mercado.
D
35
REFERENCIAS
[1] Gobierno de España - Ministerio del Interior, «Balances e Informes 2018,» [En línea]. Available:
http://www.interior.gob.es/documents/10180/8736571/01_Informe+Balance+Criminalidad+-
+Primer+trimestre+2018.pdf/f8a31d99-7275-436a-a66a-22e88832ae4d. [Último acceso: 24 Junio 2018].
[2] L. Albor, «ABC - Sociedad,» 12 Agosto 2016. [En línea]. Available: http://www.abc.es/sociedad/abci-
mapa-robo-espana-baleares-corre-peligro-cartera-y-ceuta-coche-201608111404_noticia.html. [Último
acceso: 24 Junio 2018].
[3] F. P. Ávila, «Diario de Sevilla,» 17 Abril 2018. [En línea]. Available:
https://www.diariodesevilla.es/sevilla/delitos-cometen-Sevilla-hurtos_0_1237076881.html. [Último
acceso: 24 Junio 2018].
[4] Ramón Toro, «Carteras antirrobo,» [En línea]. Available:
https://carteraantirrobo.com/es/antirrobo/cartera-billetera-de-piel-antirrobo-para-hombre-37.html. [Último
acceso: 24 Junio 2018].
[5] Tile, [En línea]. Available: https://www.thetileapp.com/en-us/products/slim. [Último acceso: 24 Junio
2018].
[6] «NFC Forum,» [En línea]. Available: https://nfc-forum.org. [Último acceso: 23 6 2018].
[7] I. f. R. Lipfert Hermann, « MIMO OFDM Space Time Coding – Spatial Multiplexing, Increasing
Performance and Spectral Efficiency in Wireless Systems, Part I Technical Basis,» 2007.
[8] Wikipedia, «Bluetooth Low Energy,» [En línea]. Available:
https://en.wikipedia.org/wiki/Bluetooth_Low_Energy. [Último acceso: 24 6 2018].
[9] Nordic Semiconductor, «nRF51822: Specification,» [En línea]. Available:
https://www.nordicsemi.com/eng/Products/Bluetooth-low-energy/nRF51822#SPECIFICATION. [Último
acceso: 24 6 2018].
[10] Texas Instruments, "TPS61040 28-V, 400-mA Switch Boost Converter in SOT-23 for LCD and White
LED Applications," [Online]. Available: http://www.ti.com/product/TPS61040. [Accessed 24 6 2018].
[11] Apple, «iBeacon - Apple Developer,» [En línea]. Available: https://developer.apple.com/ibeacon/Getting-
Started-with-iBeacon.pdf. [Último acceso: 24 6 2018].
[12] W. Warne, «Bluetooth Low Energy - It starts with Advertising,» 15 Febrero 2017. [En línea]. Available:
https://blog.bluetooth.com/bluetooth-low-energy-it-starts-with-advertising. [Último acceso: 24 Junio
2018].
[13] Bluetooth SIG, «Bluetooth Developer Studio,» [En línea]. Available:
https://docs.bluetooth.com/developerstudio/introduction/index.html. [Último acceso: 25 Junio 2018].
[14] Energizer, «Energizer,» [En línea]. Available: http://data.energizer.com/pdfs/cr2032.pdf. [Último acceso:
Referencias
36
36
25 Junio 2018].
37
GLOSARIO
BLE: Bluetooth Low Energy
NFC: Near Field Communication (Comunicación de Campo Cercano)
MIMO: Multiple-Inputs Multiple-Outputs (Múltiples entradas y múltiples salidas)
SoC: System on Chip (Sistema en un Chip)
SOC: State Of Charge (Estado de Carga)
PCB: Printed Circuit Board (Placa de Circuito Impreso)
SPI: Serial Peripheral Interface (Interfaz de Periférico Serie)
TWI: Two-Wire Interface (Interfaz de dos cables)
UART: Universal Asynchronous Receiver-Transmitter
PWM: Pulse Width Modulation (Modulación por ancho de pulso)
CRC: Código de Redundancia Cíclica
IDE: Integrated Development Environment (Entorno de Desarrollo Integrado)
GATT: Generic Attribute Profile
SIG: Special Interest Group (Grupo de Interés Especial)
ADC: Analog to Digital Converter (Convertidor Analógico Digital)
OTA: Over-The-Air (A través del aire)
BLUETOOTH® DOC Date / Year-Month-Day Approved Revision Document No
2011-12-27 Adopted V10r00 BAS_SPEC
Prepared By E-mail Address N.B.
GPA WG [email protected]
BATTERY SERVICE SPECIFICATION
Abstract:
The Battery Service exposes the state of a battery within a device.
BLUETOOTH SPECIFICATION Page 2 of 13
Battery Service Specification
Revision History
Revision Date (yyyy-mm-dd) Comments
D09r00 2010-10-26 Initial Draft
D09r08 2011-01-11 Updated after UCRDD approval to match UCRDD
D09r11 2011-05-26 Updated after review at GPA F2F meeting
D09r13 2011-06-13 Updated after review at GPA F2F meeting
D09r14 2011-06-14 Clean version for BARB review
D09r15 2011-09-28 Updated to add notification to Battery Level
D09r16 2011-10-21 Updated to add notification to Battery State and change Battery Level State to be broadcast only with description:namespace
D09r17 2011-11-23 Removed characteristics that were not IOP’d with sufficient test evidence.
D10r00 2011-12-06 Submitted to BTI as v1.0
V10r00 2011-12-27 Adopted by the Bluetooth SIG Board of Directors
Contributors
Name Company
Robin Heydon CSR
Nick Hunn CSR
Mats Anderson Connect Blue
David Edwin Nordic
Rob Hulvey Broadcom
Disclaimer and Copyright Notice
The copyright in this specification is owned by the Promoter Members of Bluetooth® Special Interest Group (SIG), Inc. (“Bluetooth SIG”). Use of these specifications and any related intellectual property (collectively, the “Specification”), is governed by the Promoters Membership Agreement among the Promoter Members and Bluetooth SIG (the “Promoters Agreement”), certain membership agreements between Bluetooth SIG and its Adopter and Associate Members (the “Membership Agreements”) and the Bluetooth Specification Early Adopters Agreements (1.2 Early Adopters Agreements) among Early Adopter members of the unincorporated Bluetooth SIG and the Promoter Members (the “Early Adopters Agreement”). Certain rights and obligations of the Promoter Members under the Early Adopters Agreements have been assigned to Bluetooth SIG by the Promoter Members.
Use of the Specification by anyone who is not a member of Bluetooth SIG or a party to an Early Adopters Agreement (each such person or party, a “Member”) is prohibited. The legal rights and obligations of each Member are governed by their applicable Membership Agreement, Early Adopters Agreement or Promoters Agreement. No license, express or implied, by estoppel or otherwise, to any intellectual property rights are granted herein.
Any use of the Specification not in compliance with the terms of the applicable Membership Agreement, Early Adopters Agreement or Promoters Agreement is prohibited and any such prohibited use may result in termination of the applicable Membership Agreement or Early Adopters Agreement and other liability permitted by the applicable agreement or by applicable law to Bluetooth SIG or any of its members for patent, copyright and/or trademark infringement.
THE SPECIFICATION IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, SATISFACTORY QUALITY, OR REASONABLE SKILL OR CARE, OR ANY WARRANTY ARISING OUT OF ANY COURSE OF DEALING, USAGE, TRADE PRACTICE, PROPOSAL, SPECIFICATION OR SAMPLE.
BLUETOOTH SPECIFICATION Page 3 of 13
Battery Service Specification
Each Member hereby acknowledges that products equipped with the Bluetooth technology ("Bluetooth products") may be subject to various regulatory controls under the laws and regulations of various governments worldwide. Such laws and regulatory controls may govern, among other things, the combination, operation, use, implementation and distribution of Bluetooth products. Examples of such laws and regulatory controls include, but are not limited to, airline regulatory controls, telecommunications regulations, technology transfer controls and health and safety regulations. Each Member is solely responsible for the compliance by their Bluetooth Products with any such laws and regulations and for obtaining any and all required authorizations, permits, or licenses for their Bluetooth products related to such regulations within the applicable jurisdictions. Each Member acknowledges that nothing in the Specification provides any information or assistance in connection with securing such compliance, authorizations or licenses. NOTHING IN THE SPECIFICATION CREATES ANY WARRANTIES, EITHER EXPRESS OR IMPLIED, REGARDING SUCH LAWS OR REGULATIONS.
ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY INTELLECTUAL PROPERTY RIGHTS OR FOR NONCOMPLIANCE WITH LAWS, RELATING TO USE OF THE SPECIFICATION IS EXPRESSLY DISCLAIMED. BY USE OF THE SPECIFICATION, EACH MEMBER EXPRESSLY WAIVES ANY CLAIM AGAINST BLUETOOTH SIG AND ITS PROMOTER MEMBERS RELATED TO USE OF THE SPECIFICATION.
Bluetooth SIG reserve the right to adopt any changes or alterations to the Specification as it deems necessary or appropriate.
Copyright © 2013. Bluetooth® SIG, Inc. All copyrights in the Bluetooth Specifications themselves are owned by Ericsson AB, Lenovo (Singapore) Pte. Ltd., Intel Corporation, Microsoft Corporation, Motorola Mobility, Inc., Nokia Corporation, and Toshiba Corporation.
*Other third-party brands and names are the property of their respective owners.
BLUETOOTH SPECIFICATION Page 4 of 13
Battery Service Specification
Document Terminology
The Bluetooth SIG has adopted Section 13.1 of the IEEE Standards Style Manual, which dictates use of the words ``shall’’, ``should’’, ``may’’, and ``can’’ in the development of documentation, as follows:
The word shall is used to indicate mandatory requirements strictly to be followed in order to conform to the standard and from which no deviation is permitted (shall equals is required to).
The use of the word must is deprecated and shall not be used when stating mandatory requirements; must is used only to describe unavoidable situations.
The use of the word will is deprecated and shall not be used when stating mandatory requirements; will is only used in statements of fact.
The word should is used to indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain course of action is deprecated but not prohibited (should equals is recommended that).
The word may is used to indicate a course of action permissible within the limits of the standard (may equals is permitted).
The word can is used for statements of possibility and capability, whether material, physical, or causal (can equals is able to).
BLUETOOTH SPECIFICATION Page 5 of 13
Battery Service Specification
Table of Contents
1 Introduction .................................................................................................................................... 6 1.1 Conformance ............................................................................................................................. 6 1.2 Service Dependency ................................................................................................................. 6 1.3 Bluetooth Specification Release Compatibility .......................................................................... 6 1.4 GATT Sub-Procedure Requirements ........................................................................................ 6 1.5 Transport Dependencies ........................................................................................................... 6 1.6 Error Codes ............................................................................................................................... 6 1.7 Byte Transmission Order ........................................................................................................... 6
2 Service Declaration ........................................................................................................................ 7 3 Service Characteristics ................................................................................................................. 8
3.1 Battery Level .............................................................................................................................. 8 3.1.1 Characteristic Behavior ....................................................................................................... 8 3.1.2 Characteristic Descriptors ................................................................................................... 9
3.1.2.1 Characteristic Presentation Format .............................................................................. 9 3.1.2.2 Client Characteristic Configuration Descriptor ............................................................. 9
4 Service Behaviors ........................................................................................................................ 10 4.1.1 Notification Behavior ......................................................................................................... 10
5 SDP Interoperability ..................................................................................................................... 11 6 Acronyms and Abbreviations ..................................................................................................... 12 7 References .................................................................................................................................... 13
BLUETOOTH SPECIFICATION Page 6 of 13
Battery Service Specification
1 Introduction
The Battery Service exposes the Battery Level of a single battery or set of batteries in a device.
1.1 Conformance
If a device claims conformance to this service, all capabilities indicated as mandatory for this service shall be supported in the specified manner (process-mandatory). This also applies for all optional and conditional capabilities for which support is indicated. All mandatory capabilities, and optional and conditional capabilities for which support is indicated, are subject to verification as part of the Bluetooth qualification program.
1.2 Service Dependency
This service has no dependencies on other GATT-based services.
1.3 Bluetooth Specification Release Compatibility
This service is compatible with any Bluetooth core specification host [1] that includes the Generic Attribute Profile (GATT).
1.4 GATT Sub-Procedure Requirements
Additional GATT Sub-Procedures requirements beyond those required by the GATT are indicated Table 1.1.
GATT Sub-Procedure Requirements
Read Characteristic Descriptors M
Notifications C1
Write Characteristic Descriptors C1
C1: Mandatory if the Battery Level characteristic properties supports notification, otherwise excluded.
Table 1.1: GATT Sub-Procedure Requirements
1.5 Transport Dependencies
This service may operate over LE and BR/EDR transports.
1.6 Error Codes
This service does not define any application error codes that are used in Attribute Protocol.
1.7 Byte Transmission Order
All characteristics used with this service shall be transmitted with the least significant octet first (i.e. little endian). The least significant octet is identified in the characteristic definitions in [2].
BLUETOOTH SPECIFICATION Page 7 of 13
Battery Service Specification
2 Service Declaration
The service UUID shall be set to «Battery Service». The UUID value assigned to «Battery Service» is defined in [2].
BLUETOOTH SPECIFICATION Page 8 of 13
Battery Service Specification
3 Service Characteristics
Characteristic Ref. Mandatory / Optional
Battery Level 3.1 M
Table 3.1: Service Characteristics
In Table 3.1, characteristics that are mandatory or characteristics that are optional that are implemented shall comply with the properties in Table 3.2:
Bro
ad
ca
st
Read
Wri
te w
ith
ou
t
Resp
on
se
Wri
te
No
tify
Ind
icate
Sig
ned
Wri
te
Reliab
le W
rite
Wri
tab
le
Au
xilia
rie
s
Battery Level X M X X O X X X X
Table 3.2: Characteristic properties
Requirements marked with ‘M’ are mandatory, ‘O’ are optional and ‘X’ are excluded (not permitted).
This service defines no security requirements for these characteristics.
3.1 Battery Level
3.1.1 Characteristic Behavior
The Battery Level characteristic is read using the GATT Read Characteristic Value sub-procedure and returns the current battery level as a percentage from 0% to 100%; 0% represents a battery that is fully discharged, 100% represents a battery that is fully charged.
For many devices, the battery level value will not change frequently; therefore it is recommended not to poll this characteristic value at a high frequency. For example, if the expected battery life is in the order of years, reading the battery level value more frequently than once a week is not recommended.
This characteristic can be configured for notification using the GATT Write Characteristic Descriptors sub-procedure on the Client Characteristic Configuration descriptor. When configured for notification, this characteristic can be notified while in a connection; see section 4.1.1.
The value of the Client Characteristic Configuration descriptor is persistent for bonded devices when not in a connection.
BLUETOOTH SPECIFICATION Page 9 of 13
Battery Service Specification
3.1.2 Characteristic Descriptors
3.1.2.1 Characteristic Presentation Format
When a device has more than one instance of the Battery service, each Battery Level characteristic shall include a Characteristic Presentation Format descriptor that has a namespace/description value that is unique for that instance of the Battery service.
This descriptor shall be readable.
This descriptor shall be read using the GATT Read Characteristic Descriptors sub-procedure.
3.1.2.2 Client Characteristic Configuration Descriptor
If the characteristic properties of this characteristic allow notification, then the Client Characteristic Configuration descriptor shall be included in this characteristic; otherwise, this descriptor shall not be included.
If included, this descriptor shall be readable and writable.
This descriptor can be read using the GATT Read Characteristic Descriptors sub-procedure.
This descriptor can be written using the GATT Write Characteristic Descriptors sub-procedure.
BLUETOOTH SPECIFICATION Page 10 of 13
Battery Service Specification
4 Service Behaviors
4.1.1 Notification Behavior
If a client has configured notification on the Battery Level characteristic, no notifications of this characteristic shall be sent when disconnected. The Battery service shall not initiate a connection if a notification would have been sent when connected.
Upon reconnection, the server shall send a notification if the value of the Battery Level characteristic has changed while the service has been disconnected from a bonded client.
If a client has configured notification on the Battery Level characteristic and the Battery Level characteristic value changes while in a connection, then the characteristic shall be notified.
BLUETOOTH SPECIFICATION Page 11 of 13
Battery Service Specification
5 SDP Interoperability
If this service is exposed over BR/EDR then it shall have the following SDP record:
Item Definition Type Value Status
Service Class ID List
M
Service Class #0 UUID «Battery Service» M
Protocol Descriptor List
M
Protocol #0 UUID L2CAP M
Parameter #0 for Protocol #0
PSM Uint16 PSM = ATT M
Protocol #1 UUID ATT M
Parameter #0 for Protocol #1
GATT Start Handle
Uint16 M
Parameter #1 for Protocol #1
GATT End Handle Uint16 M
BrowseGroupList PublicBrowseRoot M
Table 5.1: SDP records
BLUETOOTH SPECIFICATION Page 12 of 13
Battery Service Specification
6 Acronyms and Abbreviations
Acronyms and Abbreviations Meaning
AD Advertising Data
BR/EDR Basic Rate / Enhanced Data Rate
GATT Generic Attribute Profile
LE Low Energy
UUID Universally Unique Identifier
L2CAP Logical Link Control and Adaption Protocol
PSM Protocol Service Multiplex
ATT Attribute Protocol
SDP Service Discovery Protocol
Table 6.1: Acronyms and Abbreviations
BLUETOOTH SPECIFICATION Page 13 of 13
Battery Service Specification
7 References
[1] Bluetooth v4.0 Core Specification [2] Characteristic and Descriptor descriptions are accessible via the Bluetooth SIG Assigned Numbers.
Classification: "Lithium Coin"
Chemical System: Lithium / Manganese Dioxide (Li/MnO2)
Designation: ANSI / NEDA-5004LC, IEC-CR2032Nominal Voltage: 3.0 VoltsTypical Capacity: 235 mAh (to 2.0 volts)
(Rated at 15K ohms at 21°C)Typical Weight: 3.0 grams (0.10 oz.)
Typical Volume: 1.0 cubic centimeters (0.06 cubic inch)
Max Rev Charge: 1 microampereEnergy Density: 198 milliwatt hr/g, 653 milliwatt hr/ccTypical Li Content: 0.109 grams (0.0038 oz.)Operating Temp: -30C to 60CSelf Discharge: ~1% / year
Load Cutoff
2.0V
(ohms) (hours)
15,000 1245 Bkgnd Drain: Continuous
21°C (70°F) 15K ohms
0.19 mA @2.9V
Pulse Drain: 2 seconds X 12 times/day400 ohms
~6.8 mA @2.7V
Typical Drains:
Simulated Application testTypical Performance at 21°C (70°F)
at 2.9V
(mA)
Continuous 0.19
Pulse Discharge Characteristics
This datasheet contains typical information specific to products manufactured at the time of its publication.
Schedule:
Pulse Test at 21°C (70°F)
Contents herein do not constitute a warranty and are for reference only.
ENERGIZER CR2032
Important Notice
Lithium CoinSpecifications
mm (inches)
Industry Standard Dimensions
Safety:
(1) KEEP OUT OF REACH OF CHILDREN. Swallowing may lead to
serious injury or death in as little as 2 hours due to chemical burns and
potential perforation of the esophagus. Immediately see doctor;
have doctor phone (800) 498-8666.
(2) Battery compartment design. To prevent children from
removing batteries, battery compartments should be designed with one
of the following methods: a) a tool such as screwdriver or coin is
required to open battery compartment or b) the battery compartment
door/cover requires the application of a minimum of two independent
and simultaneous movements of the securing mechanism to open by
hand. Screws should remain captive with the battery door or cover.
Continuous Discharge Characteristics
PRODUCT DATASHEET
1.8
2.0
2.2
2.4
2.6
2.8
3.0
3.2
0 300 600 900 1200 1500
Vo
lta
ge
, C
CV
Hours
Load: 15K ohms - continuous 21°C (70°F) Typical Drain @ 2.9V: 0.19 mA
3.20 (0.126)
2.90 (0.114)
17.70 (0.697)
Maximum
20.00 (0.787)
19.70 (0.776)
0.20 (0.008) Maximum Ref.
Permissible deflection from a flat.
0.10 (0.004) Minimum Ref.
(Applies to top edge of gasket or
edge of crimp, whichever is higher.)
0
20
40
60
80
100
120
140
1.8
2.0
2.2
2.4
2.6
2.8
3.0
3.2
0 25 50 75 100 125 150 175 200 225
IR,
oh
ms
Vo
lta
ge
, C
CV
Capacity, mAh
IR
Pulse
Bkgnd
Form No. 2032NA0618 Page 1 of 1
1 ANEXO III: MODULACIÓN POR ANCHO DE
PULSO (PWM)
La modulación por ancho de pulso o PWM, por sus sigas en inglés, de una señal consiste en una técnica mediante
la cual se modifica el ciclo de trabajo de una señal periódica con el fin de transmitir información o controlar la
energía que se envía a una carga.
Una señal PWM tiene, por regla general, la siguiente forma:
El ciclo de trabajo se obtiene del cociente entre tiempo que permanece la señal a nivel alto y el periodo de esta.
Es decir:
𝐷 =𝑇𝑜𝑛
𝑃𝑒𝑟𝑖𝑜𝑑𝑜
Donde:
• D: Corresponde al ciclo de trabajo.
• Ton: Tiempo que permanece la señal a nivel alto, es decir, el ancho de la señal.
• Periodo: Periodo de la señal.
Como Ton no podrá ser nunca superior al Periodo de la señal, el ciclo de trabajo siempre tendrá un valor entre
0 y 1. Es por eso por lo que, en muchas ocasiones, se habla del ciclo de trabajo en tanto por ciento. Ya que se
puede entender como el porcentaje del tiempo que permanece la señal a nivel alto.
Este tipo de señal es muy utilizada en electrónica de potencia para regular la potencia que alimenta un
determinado circuito o en control de motores, ya que permite controlar el sentido sentido de giro, la velocidad o
el par.
1 ANEXO IV: CÓDIGO FUENTE SERVICIO DE
BATERÍA
En este documento se recoge el código fuente, así como el fichero cabecera del servicio de batería generado con
el software Bluetooth Developer Studio.
1.1 Archivo ble_bas.h:
/* This file was generated by plugin 'Nordic Semiconductor nRF5x
v.1.2.2' (BDS version 1.1.3139.0) */
#ifndef BLE_BAS_H__
#define BLE_BAS_H__
#include <stdint.h>
#include <stdbool.h>
#include "ble.h"
#include "ble_srv_common.h"
#include "app_util_bds.h"
/**@brief Battery Service event type. */
typedef enum
{
BLE_BAS_BATTERY_LEVEL_EVT_NOTIFICATION_ENABLED, /**< Battery
Level value notification enabled event. */
BLE_BAS_BATTERY_LEVEL_EVT_NOTIFICATION_DISABLED, /**< Battery
Level value notification disabled event. */
BLE_BAS_BATTERY_LEVEL_EVT_CCCD_WRITE, /**< Battery Level CCCD
write event. */
} ble_bas_evt_type_t;
// Forward declaration of the ble_bas_t type.
typedef struct ble_bas_s ble_bas_t;
typedef enum
{
FORMAT_RESERVED_FOR_FUTURE_USE = 0,
FORMAT_BOOLEAN = 1,
FORMAT_UNSIGNED_2_BIT_INTEGER = 2,
FORMAT_UNSIGNED_4_BIT_INTEGER = 3,
FORMAT_UNSIGNED_8_BIT_INTEGER = 4,
FORMAT_UNSIGNED_12_BIT_INTEGER = 5,
FORMAT_UNSIGNED_16_BIT_INTEGER = 6,
FORMAT_UNSIGNED_24_BIT_INTEGER = 7,
FORMAT_UNSIGNED_32_BIT_INTEGER = 8,
FORMAT_UNSIGNED_48_BIT_INTEGER = 9,
FORMAT_UNSIGNED_64_BIT_INTEGER = 10,
FORMAT_UNSIGNED_128_BIT_INTEGER = 11,
12
FORMAT_SIGNED_8_BIT_INTEGER = 12,
FORMAT_SIGNED_12_BIT_INTEGER = 13,
FORMAT_SIGNED_16_BIT_INTEGER = 14,
FORMAT_SIGNED_24_BIT_INTEGER = 15,
FORMAT_SIGNED_32_BIT_INTEGER = 16,
FORMAT_SIGNED_48_BIT_INTEGER = 17,
FORMAT_SIGNED_64_BIT_INTEGER = 18,
FORMAT_SIGNED_128_BIT_INTEGER = 19,
FORMAT_IEEE_754_32_BIT_FLOATING_POINT = 20,
FORMAT_IEEE_754_64_BIT_FLOATING_POINT = 21,
FORMAT_IEEE_11073_16_BIT_SFLOAT = 22,
FORMAT_IEEE_11073_32_BIT_FLOAT = 23,
FORMAT_IEEE_20601_FORMAT = 24,
FORMAT_UTF_8_STRING = 25,
FORMAT_UTF_16_STRING = 26,
FORMAT_OPAQUE_STRUCTURE = 27,
} enum_format_t;
typedef struct
{
enum_format_t format;
} bas_characteristic_presentation_format_format_t;
typedef enum
{
NAMESPACE_BLUETOOTH_SIG_ASSIGNED_NUMBERS = 1,
} enum_namespace_t;
typedef struct
{
enum_namespace_t namespace;
} bas_characteristic_presentation_format_namespace_t;
/**@brief Characteristic Presentation Format structure. */
typedef struct
{
bas_characteristic_presentation_format_format_t format;
int8_t exponent;
uint16_t unit;
bas_characteristic_presentation_format_namespace_t namespace;
uint16_t description;
} ble_bas_characteristic_presentation_format_t;
/**@brief Battery Level structure. */
typedef struct
{
uint8_t level;
ble_bas_characteristic_presentation_format_t
characteristic_presentation_format;
} ble_bas_battery_level_t;
/**@brief Battery Service Service event. */
typedef struct
{
ble_bas_evt_type_t evt_type; /**< Type of event. */
union {
uint16_t cccd_value; /**< Holds decoded data in Notify and
Indicate event handler. */
} params;
} ble_bas_evt_t;
/**@brief Battery Service Service event handler type. */
typedef void (*ble_bas_evt_handler_t) (ble_bas_t * p_bas,
ble_bas_evt_t * p_evt);
/**@brief Battery Service Service init structure. This contains all
options and data needed for initialization of the service */
typedef struct
{
ble_bas_evt_handler_t evt_handler; /**< Event handler to be
called for handling events in the Battery Service Service. */
bool is_battery_level_notify_supported; /**< TRUE if
notification of Battery Level is supported. */
ble_bas_battery_level_t ble_bas_battery_level_initial_value; /**<
If not NULL, initial value of the Battery Level characteristic. */
} ble_bas_init_t;
/**@brief Battery Service Service structure. This contains various
status information for the service.*/
struct ble_bas_s
{
ble_bas_evt_handler_t evt_handler; /**< Event handler to be called
for handling events in the Battery Service Service. */
uint16_t service_handle; /**< Handle of Battery Service Service
(as provided by the BLE stack). */
bool is_battery_level_notify_supported; /**< TRUE if
notification of Battery Level is supported. */
ble_gatts_char_handles_t battery_level_handles; /**< Handles
related to the Battery Level characteristic. */
ble_gatts_char_handles_t
characteristic_presentation_format_handles; /**< Handles related to the
Characteristic Presentation Format descriptor. */
uint16_t conn_handle; /**< Handle of the current connection (as
provided by the BLE stack, is BLE_CONN_HANDLE_INVALID if not in a
connection). */
};
/**@brief Function for initializing the Battery Service.
*
* @param[out] p_bas Battery Service Service structure. This
structure will have to be supplied by
* the application. It will be initialized by
this function, and will later
* be used to identify this particular service
instance.
* @param[in] p_bas_init Information needed to initialize the
service.
*
* @return NRF_SUCCESS on successful initialization of service,
otherwise an error code.
14
*/
uint32_t ble_bas_init(ble_bas_t * p_bas, const ble_bas_init_t *
p_bas_init);
/**@brief Function for handling the Application's BLE Stack events.*/
void ble_bas_on_ble_evt(ble_bas_t * p_bas, ble_evt_t * p_ble_evt);
/**@brief Function for setting the Battery Level.
*
* @details Sets a new value of the Battery Level characteristic. The
new value will be sent
* to the client the next time the client reads the Battery
Level characteristic.
* This function is only generated if the characteristic's
Read property is not 'Excluded'.
*
* @param[in] p_bas Battery Service Service structure.
* @param[in] p_battery_level New Battery Level.
*
* @return NRF_SUCCESS on success, otherwise an error code.
*/
uint32_t ble_bas_battery_level_set(ble_bas_t * p_bas,
ble_bas_battery_level_t * p_battery_level);
/**@brief Function for sending the Battery Level.
*
* @details The application calls this function after having performed
a battery level.
* The battery level data is encoded and sent to the client.
* This function is only generated if the characteristic's
Notify or Indicate property is not 'Excluded'.
*
* @param[in] p_bas Battery Service Service
structure.
* @param[in] p_battery_level New battery level.
*
* @return NRF_SUCCESS on success, otherwise an error code.
*/
uint32_t ble_bas_battery_level_send(ble_bas_t * p_bas,
ble_bas_battery_level_t * p_battery_level);
/**@brief Function for setting the Characteristic Presentation Format.
*
* @details Sets a new value of the Characteristic Presentation Format
descriptor. The new value will be sent
* to the client the next time the client reads the
Characteristic Presentation Format descriptor.
* This function is only generated if the descriptor's Read
property is not 'Excluded'.
*
* @param[in] p_bas Battery Service Service structure.
* @param[in] p_characteristic_presentation_format New
Characteristic Presentation Format.
*
* @return NRF_SUCCESS on success, otherwise an error code.
*/
uint32_t ble_bas_characteristic_presentation_format_set(ble_bas_t *
p_bas, ble_bas_characteristic_presentation_format_t *
p_characteristic_presentation_format);
#endif //_BLE_BAS_H__
1.2 Archivo ble_bas.c
/* This file was generated by plugin 'Nordic Semiconductor nRF5x
v.1.2.2' (BDS version 1.1.3139.0) */
#include "ble_bas.h"
#include <string.h>
#include "nordic_common.h"
#include "ble_srv_common.h"
#include "app_util.h"
#include "app_util_bds.h"
#define OPCODE_LENGTH 1 /**< Length of opcode inside Battery Service
packet. */
#define HANDLE_LENGTH 2 /**< Length of handle inside Battery Service
packet. */
/* TODO Consider changing the max values if encoded data for
characteristic/descriptor is fixed length */
#define MAX_BATTERY_LEVEL_LEN (BLE_L2CAP_MTU_DEF - OPCODE_LENGTH -
HANDLE_LENGTH) /**< Maximum size of a transmitted Battery Level. */
#define MAX_CHARACTERISTIC_PRESENTATION_FORMAT_LEN (BLE_L2CAP_MTU_DEF
- OPCODE_LENGTH - HANDLE_LENGTH) /**< Maximum size of a transmitted
Characteristic Presentation Format. */
/**@brief Function for encoding Battery Level.
*
* @param[in] p_battery_level Battery Level characteristic
structure to be encoded.
* @param[out] p_encoded_buffer Buffer where the encoded data will
be written.
*
* @return Size of encoded data.
*/
static uint8_t battery_level_encode(ble_bas_battery_level_t *
p_battery_level, uint8_t * encoded_buffer)
{
uint8_t len = 0;
encoded_buffer[len++] = p_battery_level->level;
return len;
}
/**@brief Function for encoding Format.
*
* @param[in] p_format Format structure to be encoded.
* @param[out] p_encoded_buffer Buffer where the encoded data will
be written.
*
16
* @return Size of encoded data.
*/
static uint8_t
characteristic_presentation_format_format_encode(bas_characteristic_pr
esentation_format_format_t * p_format, uint8_t * encoded_buffer)
{
uint8_t format;
format = p_format->format;
encoded_buffer[0] = format;
return 1;
}
/**@brief Function for encoding Namespace.
*
* @param[in] p_namespace Namespace structure to be
encoded.
* @param[out] p_encoded_buffer Buffer where the encoded data will
be written.
*
* @return Size of encoded data.
*/
static uint8_t
characteristic_presentation_format_namespace_encode(bas_characteristic
_presentation_format_namespace_t * p_namespace, uint8_t *
encoded_buffer)
{
uint8_t namespace;
namespace = p_namespace->namespace;
encoded_buffer[0] = namespace;
return 1;
}
/**@brief Function for encoding Characteristic Presentation Format.
*
* @param[in] p_characteristic_presentation_format
Characteristic Presentation Format descriptor structure to be encoded.
* @param[out] p_encoded_buffer Buffer where the encoded data will
be written.
*
* @return Size of encoded data.
*/
static uint8_t
characteristic_presentation_format_encode(ble_bas_characteristic_prese
ntation_format_t * p_characteristic_presentation_format, uint8_t *
encoded_buffer)
{
uint8_t len = 0;
len +=
characteristic_presentation_format_format_encode(&p_characteristic_pre
sentation_format->format, &encoded_buffer[len]);
encoded_buffer[len++] = p_characteristic_presentation_format-
>exponent;
len += bds_uint16_encode(&p_characteristic_presentation_format-
>unit, &encoded_buffer[len]);
len +=
characteristic_presentation_format_namespace_encode(&p_characteristic_
presentation_format->namespace, &encoded_buffer[len]);
len += bds_uint16_encode(&p_characteristic_presentation_format-
>description, &encoded_buffer[len]);
return len;
}
/**@brief Function for handling the Connect event.
*
* @param[in] p_bas Battery Service Service structure.
* @param[in] p_ble_evt Event received from the BLE stack.
*/
static void on_connect(ble_bas_t * p_bas, ble_evt_t * p_ble_evt)
{
p_bas->conn_handle = p_ble_evt->evt.gap_evt.conn_handle;
}
/**@brief Function for handling the Disconnect event.
*
* @param[in] p_bas Battery Service Service structure.
* @param[in] p_ble_evt Event received from the BLE stack.
*/
static void on_disconnect(ble_bas_t * p_bas, ble_evt_t * p_ble_evt)
{
UNUSED_PARAMETER(p_ble_evt);
p_bas->conn_handle = BLE_CONN_HANDLE_INVALID;
}
/**@brief Function for handling the Write event.
*
* @param[in] p_bas Battery Service Service structure.
* @param[in] p_ble_evt Event received from the BLE stack.
*/
static void on_write(ble_bas_t * p_bas, ble_gatts_evt_write_t *
p_ble_evt)
{
if(p_ble_evt->handle == p_bas->battery_level_handles.cccd_handle)
{
if(p_bas->evt_handler != NULL)
{
ble_bas_evt_t evt;
evt.evt_type = BLE_BAS_BATTERY_LEVEL_EVT_CCCD_WRITE;
bds_uint16_decode(p_ble_evt->len, p_ble_evt->data,
&evt.params.cccd_value);
p_bas->evt_handler(p_bas, &evt);
}
}
}
/**@brief Authorize WRITE request event handler.
*
* @details Handles WRITE events from the BLE stack.
*
* @param[in] p_sc_ctrlpt SC Ctrlpt structure.
* @param[in] p_gatts_evt GATTS Event received from the BLE stack.
18
*
*/
static void on_rw_authorize_request(ble_bas_t * p_bas, ble_gatts_evt_t
* p_gatts_evt)
{
ble_gatts_evt_rw_authorize_request_t * p_auth_req = &p_gatts_evt-
>params.authorize_request;
if (p_auth_req->type == BLE_GATTS_AUTHORIZE_TYPE_WRITE)
{
if ( (p_gatts_evt->params.authorize_request.request.write.op
!= BLE_GATTS_OP_PREP_WRITE_REQ)
&& (p_gatts_evt-
>params.authorize_request.request.write.op
!= BLE_GATTS_OP_EXEC_WRITE_REQ_NOW)
&& (p_gatts_evt-
>params.authorize_request.request.write.op
!= BLE_GATTS_OP_EXEC_WRITE_REQ_CANCEL)
)
{
}
}
}
/**@brief Function for handling BLE events.
*
* @param[in] p_bas Battery Service Service structure.
* @param[in] p_ble_evt Event received from the BLE stack.
*/
void ble_bas_on_ble_evt(ble_bas_t * p_bas, ble_evt_t * p_ble_evt)
{
switch (p_ble_evt->header.evt_id)
{
case BLE_GAP_EVT_CONNECTED:
on_connect(p_bas, p_ble_evt);
break;
case BLE_GAP_EVT_DISCONNECTED:
on_disconnect(p_bas, p_ble_evt);
break;
case BLE_GATTS_EVT_WRITE:
on_write(p_bas, &p_ble_evt->evt.gatts_evt.params.write);
break;
case BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST:
on_rw_authorize_request(p_bas, &p_ble_evt-
>evt.gatts_evt);
break;
default:
//No implementation needed.
break;
}
}
/**@brief Function for initializing the Battery Service. */
uint32_t ble_bas_init(ble_bas_t * p_bas, const ble_bas_init_t *
p_bas_init)
{
uint32_t err_code;
ble_uuid_t ble_uuid;
// Initialize service structure
p_bas->evt_handler = p_bas_init->evt_handler;
p_bas->conn_handle = BLE_CONN_HANDLE_INVALID;
BLE_UUID_BLE_ASSIGN(ble_uuid, 0x180F);
// Add service
err_code = sd_ble_gatts_service_add(BLE_GATTS_SRVC_TYPE_PRIMARY,
&ble_uuid, &p_bas->service_handle);
if (err_code != NRF_SUCCESS)
{
return err_code;
}
// Add Battery Level characteristic
ble_bas_battery_level_t battery_level_initial_value = p_bas_init-
>ble_bas_battery_level_initial_value;
p_bas->is_battery_level_notify_supported = p_bas_init-
>is_battery_level_notify_supported;
uint8_t battery_level_encoded_value[MAX_BATTERY_LEVEL_LEN];
ble_add_char_params_t add_battery_level_params;
memset(&add_battery_level_params, 0,
sizeof(add_battery_level_params));
add_battery_level_params.uuid = 0x2A19;
add_battery_level_params.max_len =
MAX_BATTERY_LEVEL_LEN;
add_battery_level_params.init_len =
battery_level_encode(&battery_level_initial_value,
battery_level_encoded_value);
add_battery_level_params.p_init_value =
battery_level_encoded_value;
add_battery_level_params.char_props.notify = p_bas-
>is_battery_level_notify_supported;
add_battery_level_params.char_props.read = 1;
add_battery_level_params.read_access = SEC_OPEN;
add_battery_level_params.cccd_write_access = SEC_OPEN;
// 1 for variable length and 0 for fixed length.
add_battery_level_params.is_var_len = 1;
// Add Characteristic Presentation Format descriptor
ble_gatts_char_pf_t characteristic_presentation_format;
memset(&characteristic_presentation_format, 0,
sizeof(characteristic_presentation_format));
characteristic_presentation_format.format =
BLE_GATT_CPF_FORMAT_UINT64; //See BLE_GATT_CPF_FORMATS in ble_gatt.h
file for the list of possible values
characteristic_presentation_format.desc =
BLE_GATT_CPF_NAMESPACE_BTSIG; //See BLE_GATT_CPF_NAMESPACES in
ble_gatt.h file for the list of possible values
characteristic_presentation_format.exponent = -2;
//Exponent for integer data types.
20
characteristic_presentation_format.name_space =
BLE_GATT_CPF_NAMESPACE_BTSIG; //See BLE_GATT_CPF_NAMESPACES in
ble_gatt.h file for the list of possible values
characteristic_presentation_format.unit = 0x2702;
//corresponds to mass (kilogram), see
https://developer.bluetooth.org/gatt/units/Pages/default.aspx for the
list of units.
add_battery_level_params.p_presentation_format =
&characteristic_presentation_format;
err_code = characteristic_add(p_bas->service_handle,
&add_battery_level_params, &(p_bas->battery_level_handles));
if (err_code != NRF_SUCCESS)
{
return err_code;
}
return NRF_SUCCESS;
}
/**@brief Function for setting the Battery Level. */
uint32_t ble_bas_battery_level_set(ble_bas_t * p_bas,
ble_bas_battery_level_t * p_battery_level)
{
ble_gatts_value_t gatts_value;
uint8_t encoded_value[MAX_BATTERY_LEVEL_LEN];
// Initialize value struct.
memset(&gatts_value, 0, sizeof(gatts_value));
gatts_value.len = battery_level_encode(p_battery_level,
encoded_value);
gatts_value.offset = 0;
gatts_value.p_value = encoded_value;
return sd_ble_gatts_value_set(p_bas->conn_handle, p_bas-
>battery_level_handles.value_handle, &gatts_value);
}
/**@brief Function for setting the Characteristic Presentation Format.
*/
uint32_t ble_bas_characteristic_presentation_format_set(ble_bas_t *
p_bas, ble_bas_characteristic_presentation_format_t *
p_characteristic_presentation_format)
{
ble_gatts_value_t gatts_value;
uint8_t
encoded_value[MAX_CHARACTERISTIC_PRESENTATION_FORMAT_LEN];
// Initialize value struct.
memset(&gatts_value, 0, sizeof(gatts_value));
gatts_value.len =
characteristic_presentation_format_encode(p_characteristic_presentatio
n_format, encoded_value);
gatts_value.offset = 0;
gatts_value.p_value = encoded_value;
return sd_ble_gatts_value_set(p_bas->conn_handle, p_bas-
>characteristic_presentation_format_handles.value_handle,
&gatts_value);
}
/**@brief Function for sending the Battery Level. */
uint32_t ble_bas_battery_level_send(ble_bas_t * p_bas,
ble_bas_battery_level_t * p_battery_level)
{
uint32_t err_code = NRF_SUCCESS;
if (p_bas->conn_handle != BLE_CONN_HANDLE_INVALID)
{
ble_gatts_hvx_params_t hvx_params;
uint8_t encoded_value[MAX_BATTERY_LEVEL_LEN];
uint16_t hvx_len;
// Initialize value struct.
memset(&hvx_params, 0, sizeof(hvx_params));
hvx_len = battery_level_encode(p_battery_level,
encoded_value);
hvx_params.handle = p_bas-
>battery_level_handles.value_handle;
hvx_params.type = BLE_GATT_HVX_NOTIFICATION;
hvx_params.p_len = &hvx_len;
hvx_params.offset = 0;
hvx_params.p_data = encoded_value;
err_code = sd_ble_gatts_hvx(p_bas->conn_handle, &hvx_params);
}
else
{
err_code = NRF_ERROR_INVALID_STATE;
}
return err_code;
}
1 ANEXO V: CÓDIGO FUENTE SERVICIO LCB
En este documento se recoge el código fuente, así como el fichero cabecera del servicio personalizado para el
proyecto generado con el software Bluetooth Developer Studio.
1.1 Archivo ble_lcb_service.h:
#define BLE_LCB_SERVICE_H__
#include <stdint.h>
#include <stdbool.h>
#include "ble.h"
#include "ble_srv_common.h"
#include "app_util_bds.h"
/**@brief LCB service event type. */
typedef enum
{
BLE_LCB_SERVICE_STATUS_EVT_NOTIFICATION_ENABLED, /**< Status
value notification enabled event. */
BLE_LCB_SERVICE_STATUS_EVT_NOTIFICATION_DISABLED, /**< Status
value notification disabled event. */
BLE_LCB_SERVICE_STATUS_EVT_CCCD_WRITE, /**< Status CCCD write
event. */
BLE_LCB_SERVICE_STATUS_EVT_WRITE, /**< Status write event. */
BLE_LCB_SERVICE_BUZZER_EVT_NOTIFICATION_ENABLED, /**< Buzzer
value notification enabled event. */
BLE_LCB_SERVICE_BUZZER_EVT_NOTIFICATION_DISABLED, /**< Buzzer
value notification disabled event. */
BLE_LCB_SERVICE_BUZZER_EVT_WRITE, /**< Buzzer write event. */
BLE_LCB_SERVICE_PIN_EVT_NOTIFICATION_ENABLED, /**< Pin value
notification enabled event. */
BLE_LCB_SERVICE_PIN_EVT_NOTIFICATION_DISABLED, /**< Pin value
notification disabled event. */
BLE_LCB_SERVICE_PIN_EVT_WRITE, /**< Pin write event. */
BLE_LCB_SERVICE_DEVICE_NAME_EVT_NOTIFICATION_ENABLED, /**< Device
Name value notification enabled event. */
BLE_LCB_SERVICE_DEVICE_NAME_EVT_NOTIFICATION_DISABLED, /**<
Device Name value notification disabled event. */
BLE_LCB_SERVICE_DEVICE_NAME_EVT_WRITE, /**< Device Name write
event. */
} ble_lcb_service_evt_type_t;
// Forward declaration of the ble_lcb_service_t type.
typedef struct ble_lcb_service_s ble_lcb_service_t;
/**@brief Status structure. */
typedef struct
{
uint8_t value;
12
} ble_lcb_service_status_t;
/**@brief Buzzer structure. */
typedef struct
{
uint8_t value;
} ble_lcb_service_buzzer_t;
/**@brief Pin structure. */
typedef struct
{
ble_srv_utf8_str_t value;
} ble_lcb_service_pin_t;
/**@brief Device Name structure. */
typedef struct
{
ble_srv_utf8_str_t value;
} ble_lcb_service_device_name_t;
/**@brief LCB service Service event. */
typedef struct
{
ble_lcb_service_evt_type_t evt_type; /**< Type of event. */
union {
uint16_t cccd_value; /**< Holds decoded data in Notify and
Indicate event handler. */
ble_lcb_service_status_t status; /**< Holds decoded data in
Write event handler. */
ble_lcb_service_buzzer_t buzzer; /**< Holds decoded data in
Write event handler. */
ble_lcb_service_pin_t pin; /**< Holds decoded data in Write
event handler. */
ble_lcb_service_device_name_t device_name; /**< Holds decoded
data in Write event handler. */
} params;
} ble_lcb_service_evt_t;
/**@brief LCB service Service event handler type. */
typedef void (*ble_lcb_service_evt_handler_t) (ble_lcb_service_t *
p_lcb_service, ble_lcb_service_evt_t * p_evt);
/**@brief LCB service Service init structure. This contains all options
and data needed for initialization of the service */
typedef struct
{
ble_lcb_service_evt_handler_t evt_handler; /**< Event handler
to be called for handling events in the LCB service Service. */
ble_lcb_service_status_t ble_lcb_service_status_initial_value;
/**< If not NULL, initial value of the Status characteristic. */
ble_lcb_service_buzzer_t ble_lcb_service_buzzer_initial_value;
/**< If not NULL, initial value of the Buzzer characteristic. */
ble_lcb_service_pin_t ble_lcb_service_pin_initial_value; /**< If
not NULL, initial value of the Pin characteristic. */
ble_lcb_service_device_name_t
ble_lcb_service_device_name_initial_value; /**< If not NULL, initial
value of the Device Name characteristic. */
} ble_lcb_service_init_t;
/**@brief LCB service Service structure. This contains various status
information for the service.*/
struct ble_lcb_service_s
{
ble_lcb_service_evt_handler_t evt_handler; /**< Event handler to
be called for handling events in the LCB service Service. */
uint16_t service_handle; /**< Handle of LCB service Service (as
provided by the BLE stack). */
ble_gatts_char_handles_t status_handles; /**< Handles related to
the Status characteristic. */
ble_gatts_char_handles_t buzzer_handles; /**< Handles related to
the Buzzer characteristic. */
ble_gatts_char_handles_t pin_handles; /**< Handles related to the
Pin characteristic. */
ble_gatts_char_handles_t device_name_handles; /**< Handles related
to the Device Name characteristic. */
uint16_t conn_handle; /**< Handle of the current connection (as
provided by the BLE stack, is BLE_CONN_HANDLE_INVALID if not in a
connection). */
};
/**@brief Function for initializing the LCB service.
*
* @param[out] p_lcb_service LCB service Service structure. This
structure will have to be supplied by
* the application. It will be initialized by
this function, and will later
* be used to identify this particular service
instance.
* @param[in] p_lcb_service_init Information needed to initialize
the service.
*
* @return NRF_SUCCESS on successful initialization of service,
otherwise an error code.
*/
uint32_t ble_lcb_service_init(ble_lcb_service_t * p_lcb_service, const
ble_lcb_service_init_t * p_lcb_service_init);
/**@brief Function for handling the Application's BLE Stack events.*/
void ble_lcb_service_on_ble_evt(ble_lcb_service_t * p_lcb_service,
ble_evt_t * p_ble_evt);
/**@brief Function for setting the Status.
*
* @details Sets a new value of the Status characteristic. The new
value will be sent
* to the client the next time the client reads the Status
characteristic.
* This function is only generated if the characteristic's
Read property is not 'Excluded'.
*
* @param[in] p_lcb_service LCB service Service
structure.
* @param[in] p_status New Status.
*
* @return NRF_SUCCESS on success, otherwise an error code.
*/
14
uint32_t ble_lcb_service_status_set(ble_lcb_service_t * p_lcb_service,
ble_lcb_service_status_t * p_status);
/**@brief Function for sending the Status.
*
* @details The application calls this function after having performed
a status.
* The status data is encoded and sent to the client.
* This function is only generated if the characteristic's
Notify or Indicate property is not 'Excluded'.
*
* @param[in] p_lcb_service LCB service Service
structure.
* @param[in] p_status New status.
*
* @return NRF_SUCCESS on success, otherwise an error code.
*/
uint32_t ble_lcb_service_status_send(ble_lcb_service_t *
p_lcb_service, ble_lcb_service_status_t * p_status);
/**@brief Function for setting the Buzzer.
*
* @details Sets a new value of the Buzzer characteristic. The new
value will be sent
* to the client the next time the client reads the Buzzer
characteristic.
* This function is only generated if the characteristic's
Read property is not 'Excluded'.
*
* @param[in] p_lcb_service LCB service Service
structure.
* @param[in] p_buzzer New Buzzer.
*
* @return NRF_SUCCESS on success, otherwise an error code.
*/
uint32_t ble_lcb_service_buzzer_set(ble_lcb_service_t * p_lcb_service,
ble_lcb_service_buzzer_t * p_buzzer);
/**@brief Function for setting the Pin.
*
* @details Sets a new value of the Pin characteristic. The new value
will be sent
* to the client the next time the client reads the Pin
characteristic.
* This function is only generated if the characteristic's
Read property is not 'Excluded'.
*
* @param[in] p_lcb_service LCB service Service
structure.
* @param[in] p_pin New Pin.
*
* @return NRF_SUCCESS on success, otherwise an error code.
*/
uint32_t ble_lcb_service_pin_set(ble_lcb_service_t * p_lcb_service,
ble_lcb_service_pin_t * p_pin);
/**@brief Function for setting the Device Name.
*
* @details Sets a new value of the Device Name characteristic. The
new value will be sent
* to the client the next time the client reads the Device
Name characteristic.
* This function is only generated if the characteristic's
Read property is not 'Excluded'.
*
* @param[in] p_lcb_service LCB service Service
structure.
* @param[in] p_device_name New Device Name.
*
* @return NRF_SUCCESS on success, otherwise an error code.
*/
uint32_t ble_lcb_service_device_name_set(ble_lcb_service_t *
p_lcb_service, ble_lcb_service_device_name_t * p_device_name);
#endif //_BLE_LCB_SERVICE_H__
1.2 Archivo ble_lcb_service.c
/* This file was generated by plugin 'Nordic Semiconductor nRF5x
v.1.2.2' (BDS version 1.1.3139.0) */
#include "ble_lcb_service.h"
#include <string.h>
#include "nordic_common.h"
#include "ble_srv_common.h"
#include "app_util.h"
#include "app_util_bds.h"
#define OPCODE_LENGTH 1 /**< Length of opcode inside LCB service
packet. */
#define HANDLE_LENGTH 2 /**< Length of handle inside LCB service
packet. */
/* TODO Consider changing the max values if encoded data for
characteristic/descriptor is fixed length */
#define MAX_STATUS_LEN (BLE_L2CAP_MTU_DEF - OPCODE_LENGTH -
HANDLE_LENGTH) /**< Maximum size of a transmitted Status. */
#define MAX_BUZZER_LEN (BLE_L2CAP_MTU_DEF - OPCODE_LENGTH -
HANDLE_LENGTH) /**< Maximum size of a transmitted Buzzer. */
#define MAX_PIN_LEN (BLE_L2CAP_MTU_DEF - OPCODE_LENGTH -
HANDLE_LENGTH) /**< Maximum size of a transmitted Pin. */
#define MAX_DEVICE_NAME_LEN (BLE_L2CAP_MTU_DEF - OPCODE_LENGTH -
HANDLE_LENGTH) /**< Maximum size of a transmitted Device Name. */
/**@brief Function for encoding Status.
*
* @param[in] p_status Status characteristic structure
to be encoded.
* @param[out] p_encoded_buffer Buffer where the encoded data will
be written.
*
16
* @return Size of encoded data.
*/
static uint8_t status_encode(ble_lcb_service_status_t * p_status,
uint8_t * encoded_buffer)
{
uint8_t len = 0;
encoded_buffer[len++] = p_status->value;
return len;
}
/**@brief Function for decoding Status.
*
* @param[in] data_len Length of the field to be decoded.
* @param[in] p_data Buffer where the encoded data is
stored.
* @param[out] p_write_val Decoded data.
*
* @return Length of the decoded field.
*/
static uint8_t status_decode(uint8_t data_len, uint8_t * p_data,
ble_lcb_service_status_t * p_write_val)
{
uint8_t pos = 0;
p_write_val->value = p_data[pos++];
return pos;
}
/**@brief Function for encoding Buzzer.
*
* @param[in] p_buzzer Buzzer characteristic structure
to be encoded.
* @param[out] p_encoded_buffer Buffer where the encoded data will
be written.
*
* @return Size of encoded data.
*/
static uint8_t buzzer_encode(ble_lcb_service_buzzer_t * p_buzzer,
uint8_t * encoded_buffer)
{
uint8_t len = 0;
encoded_buffer[len++] = p_buzzer->value;
return len;
}
/**@brief Function for decoding Buzzer.
*
* @param[in] data_len Length of the field to be decoded.
* @param[in] p_data Buffer where the encoded data is
stored.
* @param[out] p_write_val Decoded data.
*
* @return Length of the decoded field.
*/
static uint8_t buzzer_decode(uint8_t data_len, uint8_t * p_data,
ble_lcb_service_buzzer_t * p_write_val)
{
uint8_t pos = 0;
p_write_val->value = p_data[pos++];
return pos;
}
/**@brief Function for encoding Pin.
*
* @param[in] p_pin Pin characteristic structure to be
encoded.
* @param[out] p_encoded_buffer Buffer where the encoded data will
be written.
*
* @return Size of encoded data.
*/
static uint8_t pin_encode(ble_lcb_service_pin_t * p_pin, uint8_t *
encoded_buffer)
{
uint8_t len = 0;
len += bds_ble_srv_utf8_str_encode(&p_pin->value,
&encoded_buffer[len]);
return len;
}
/**@brief Function for decoding Pin.
*
* @param[in] data_len Length of the field to be decoded.
* @param[in] p_data Buffer where the encoded data is
stored.
* @param[out] p_write_val Decoded data.
*
* @return Length of the decoded field.
*/
static uint8_t pin_decode(uint8_t data_len, uint8_t * p_data,
ble_lcb_service_pin_t * p_write_val)
{
uint8_t pos = 0;
pos += bds_ble_srv_utf8_str_decode((data_len-pos), &p_data[pos],
&p_write_val->value);
return pos;
}
/**@brief Function for encoding Device Name.
*
* @param[in] p_device_name Device Name characteristic
structure to be encoded.
* @param[out] p_encoded_buffer Buffer where the encoded data will
be written.
*
* @return Size of encoded data.
*/
static uint8_t device_name_encode(ble_lcb_service_device_name_t *
p_device_name, uint8_t * encoded_buffer)
{
uint8_t len = 0;
len += bds_ble_srv_utf8_str_encode(&p_device_name->value,
&encoded_buffer[len]);
return len;
}
18
/**@brief Function for decoding Device Name.
*
* @param[in] data_len Length of the field to be decoded.
* @param[in] p_data Buffer where the encoded data is
stored.
* @param[out] p_write_val Decoded data.
*
* @return Length of the decoded field.
*/
static uint8_t device_name_decode(uint8_t data_len, uint8_t * p_data,
ble_lcb_service_device_name_t * p_write_val)
{
uint8_t pos = 0;
pos += bds_ble_srv_utf8_str_decode((data_len-pos), &p_data[pos],
&p_write_val->value);
return pos;
}
/**@brief Function for handling the Connect event.
*
* @param[in] p_lcb_service LCB service Service structure.
* @param[in] p_ble_evt Event received from the BLE stack.
*/
static void on_connect(ble_lcb_service_t * p_lcb_service, ble_evt_t *
p_ble_evt)
{
p_lcb_service->conn_handle = p_ble_evt->evt.gap_evt.conn_handle;
}
/**@brief Function for handling the Disconnect event.
*
* @param[in] p_lcb_service LCB service Service structure.
* @param[in] p_ble_evt Event received from the BLE stack.
*/
static void on_disconnect(ble_lcb_service_t * p_lcb_service, ble_evt_t
* p_ble_evt)
{
UNUSED_PARAMETER(p_ble_evt);
p_lcb_service->conn_handle = BLE_CONN_HANDLE_INVALID;
}
/**@brief Function for handling the Write event.
*
* @param[in] p_lcb_service LCB service Service structure.
* @param[in] p_ble_evt Event received from the BLE stack.
*/
static void on_write(ble_lcb_service_t * p_lcb_service,
ble_gatts_evt_write_t * p_ble_evt)
{
if(p_ble_evt->handle == p_lcb_service-
>status_handles.cccd_handle)
{
if(p_lcb_service->evt_handler != NULL)
{
ble_lcb_service_evt_t evt;
evt.evt_type = BLE_LCB_SERVICE_STATUS_EVT_CCCD_WRITE;
bds_uint16_decode(p_ble_evt->len, p_ble_evt->data,
&evt.params.cccd_value);
p_lcb_service->evt_handler(p_lcb_service, &evt);
}
}
if(p_ble_evt->handle == p_lcb_service-
>status_handles.value_handle)
{
if(p_lcb_service->evt_handler != NULL)
{
ble_lcb_service_evt_t evt;
evt.evt_type = BLE_LCB_SERVICE_STATUS_EVT_WRITE;
status_decode(p_ble_evt->len, p_ble_evt->data,
&evt.params.status);
p_lcb_service->evt_handler(p_lcb_service, &evt);
}
}
if(p_ble_evt->handle == p_lcb_service-
>buzzer_handles.value_handle)
{
if(p_lcb_service->evt_handler != NULL)
{
ble_lcb_service_evt_t evt;
evt.evt_type = BLE_LCB_SERVICE_BUZZER_EVT_WRITE;
buzzer_decode(p_ble_evt->len, p_ble_evt->data,
&evt.params.buzzer);
p_lcb_service->evt_handler(p_lcb_service, &evt);
}
}
if(p_ble_evt->handle == p_lcb_service->pin_handles.value_handle)
{
if(p_lcb_service->evt_handler != NULL)
{
ble_lcb_service_evt_t evt;
evt.evt_type = BLE_LCB_SERVICE_PIN_EVT_WRITE;
pin_decode(p_ble_evt->len, p_ble_evt->data,
&evt.params.pin);
p_lcb_service->evt_handler(p_lcb_service, &evt);
}
}
if(p_ble_evt->handle == p_lcb_service-
>device_name_handles.value_handle)
{
if(p_lcb_service->evt_handler != NULL)
{
ble_lcb_service_evt_t evt;
evt.evt_type = BLE_LCB_SERVICE_DEVICE_NAME_EVT_WRITE;
device_name_decode(p_ble_evt->len, p_ble_evt->data,
&evt.params.device_name);
p_lcb_service->evt_handler(p_lcb_service, &evt);
}
}
}
/**@brief Authorize WRITE request event handler.
20
*
* @details Handles WRITE events from the BLE stack.
*
* @param[in] p_sc_ctrlpt SC Ctrlpt structure.
* @param[in] p_gatts_evt GATTS Event received from the BLE stack.
*
*/
static void on_rw_authorize_request(ble_lcb_service_t * p_lcb_service,
ble_gatts_evt_t * p_gatts_evt)
{
ble_gatts_evt_rw_authorize_request_t * p_auth_req = &p_gatts_evt-
>params.authorize_request;
if (p_auth_req->type == BLE_GATTS_AUTHORIZE_TYPE_WRITE)
{
if ( (p_gatts_evt->params.authorize_request.request.write.op
!= BLE_GATTS_OP_PREP_WRITE_REQ)
&& (p_gatts_evt-
>params.authorize_request.request.write.op
!= BLE_GATTS_OP_EXEC_WRITE_REQ_NOW)
&& (p_gatts_evt-
>params.authorize_request.request.write.op
!= BLE_GATTS_OP_EXEC_WRITE_REQ_CANCEL)
)
{
if (p_auth_req->request.write.handle == p_lcb_service-
>status_handles.value_handle)
{
on_write(p_lcb_service, &p_auth_req->request.write);
}
if (p_auth_req->request.write.handle == p_lcb_service-
>buzzer_handles.value_handle)
{
on_write(p_lcb_service, &p_auth_req->request.write);
}
if (p_auth_req->request.write.handle == p_lcb_service-
>pin_handles.value_handle)
{
on_write(p_lcb_service, &p_auth_req->request.write);
}
if (p_auth_req->request.write.handle == p_lcb_service-
>device_name_handles.value_handle)
{
on_write(p_lcb_service, &p_auth_req->request.write);
}
}
}
}
/**@brief Function for handling BLE events.
*
* @param[in] p_lcb_service LCB service Service structure.
* @param[in] p_ble_evt Event received from the BLE stack.
*/
void ble_lcb_service_on_ble_evt(ble_lcb_service_t * p_lcb_service,
ble_evt_t * p_ble_evt)
{
switch (p_ble_evt->header.evt_id)
{
case BLE_GAP_EVT_CONNECTED:
on_connect(p_lcb_service, p_ble_evt);
break;
case BLE_GAP_EVT_DISCONNECTED:
on_disconnect(p_lcb_service, p_ble_evt);
break;
case BLE_GATTS_EVT_WRITE:
on_write(p_lcb_service, &p_ble_evt-
>evt.gatts_evt.params.write);
break;
case BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST:
on_rw_authorize_request(p_lcb_service, &p_ble_evt-
>evt.gatts_evt);
break;
default:
//No implementation needed.
break;
}
}
/**@brief Function for initializing the LCB service. */
uint32_t ble_lcb_service_init(ble_lcb_service_t * p_lcb_service, const
ble_lcb_service_init_t * p_lcb_service_init)
{
uint32_t err_code;
ble_uuid_t ble_uuid;
// Initialize service structure
p_lcb_service->evt_handler = p_lcb_service_init->evt_handler;
p_lcb_service->conn_handle = BLE_CONN_HANDLE_INVALID;
// Add a custom base UUID.
ble_uuid128_t bds_base_uuid = {{0x6F, 0x82, 0xF8, 0xBD, 0x07, 0xAA,
0xB4, 0x8F, 0xDA, 0x45, 0xF5, 0xB5, 0x00, 0x00, 0xD2, 0xF9}};
uint8_t uuid_type;
err_code = sd_ble_uuid_vs_add(&bds_base_uuid, &uuid_type);
if (err_code != NRF_SUCCESS)
{
return err_code;
}
ble_uuid.type = uuid_type;
ble_uuid.uuid = 0x9E17;
// Add service
err_code = sd_ble_gatts_service_add(BLE_GATTS_SRVC_TYPE_PRIMARY,
&ble_uuid, &p_lcb_service->service_handle);
if (err_code != NRF_SUCCESS)
{
return err_code;
}
// Add Status characteristic
ble_lcb_service_status_t status_initial_value =
p_lcb_service_init->ble_lcb_service_status_initial_value;
22
uint8_t status_encoded_value[MAX_STATUS_LEN];
ble_add_char_params_t add_status_params;
memset(&add_status_params, 0, sizeof(add_status_params));
add_status_params.uuid = 0x4EBF;
add_status_params.uuid_type = ble_uuid.type;
add_status_params.max_len = MAX_STATUS_LEN;
add_status_params.init_len =
status_encode(&status_initial_value, status_encoded_value);
add_status_params.p_init_value = status_encoded_value;
add_status_params.char_props.notify = 1;
add_status_params.char_props.read = 1;
add_status_params.read_access = SEC_MITM;
add_status_params.char_props.write = 1;
add_status_params.write_access = SEC_MITM;
add_status_params.cccd_write_access = SEC_MITM;
// 1 for variable length and 0 for fixed length.
add_status_params.is_var_len = 1;
err_code = characteristic_add(p_lcb_service->service_handle,
&add_status_params, &(p_lcb_service->status_handles));
if (err_code != NRF_SUCCESS)
{
return err_code;
}
// Add Buzzer characteristic
ble_lcb_service_buzzer_t buzzer_initial_value =
p_lcb_service_init->ble_lcb_service_buzzer_initial_value;
uint8_t buzzer_encoded_value[MAX_BUZZER_LEN];
ble_add_char_params_t add_buzzer_params;
memset(&add_buzzer_params, 0, sizeof(add_buzzer_params));
add_buzzer_params.uuid = 0x9B11;
add_buzzer_params.uuid_type = ble_uuid.type;
add_buzzer_params.max_len = MAX_BUZZER_LEN;
add_buzzer_params.init_len =
buzzer_encode(&buzzer_initial_value, buzzer_encoded_value);
add_buzzer_params.p_init_value = buzzer_encoded_value;
add_buzzer_params.char_props.read = 1;
add_buzzer_params.read_access = SEC_MITM;
add_buzzer_params.char_props.write = 1;
add_buzzer_params.write_access = SEC_MITM;
// 1 for variable length and 0 for fixed length.
add_buzzer_params.is_var_len = 1;
err_code = characteristic_add(p_lcb_service->service_handle,
&add_buzzer_params, &(p_lcb_service->buzzer_handles));
if (err_code != NRF_SUCCESS)
{
return err_code;
}
// Add Pin characteristic
ble_lcb_service_pin_t pin_initial_value = p_lcb_service_init-
>ble_lcb_service_pin_initial_value;
uint8_t pin_encoded_value[MAX_PIN_LEN];
ble_add_char_params_t add_pin_params;
memset(&add_pin_params, 0, sizeof(add_pin_params));
add_pin_params.uuid = 0xE2BB;
add_pin_params.uuid_type = ble_uuid.type;
add_pin_params.max_len = MAX_PIN_LEN;
add_pin_params.init_len = pin_encode(&pin_initial_value,
pin_encoded_value);
add_pin_params.p_init_value = pin_encoded_value;
add_pin_params.char_props.read = 1;
add_pin_params.read_access = SEC_MITM;
add_pin_params.char_props.write = 1;
add_pin_params.write_access = SEC_MITM;
// 1 for variable length and 0 for fixed length.
add_pin_params.is_var_len = 1;
err_code = characteristic_add(p_lcb_service->service_handle,
&add_pin_params, &(p_lcb_service->pin_handles));
if (err_code != NRF_SUCCESS)
{
return err_code;
}
// Add Device Name characteristic
ble_lcb_service_device_name_t device_name_initial_value =
p_lcb_service_init->ble_lcb_service_device_name_initial_value;
uint8_t device_name_encoded_value[MAX_DEVICE_NAME_LEN];
ble_add_char_params_t add_device_name_params;
memset(&add_device_name_params, 0,
sizeof(add_device_name_params));
add_device_name_params.uuid = 0x6705;
add_device_name_params.uuid_type = ble_uuid.type;
add_device_name_params.max_len = MAX_DEVICE_NAME_LEN;
add_device_name_params.init_len =
device_name_encode(&device_name_initial_value,
device_name_encoded_value);
add_device_name_params.p_init_value =
device_name_encoded_value;
add_device_name_params.char_props.read = 1;
add_device_name_params.read_access = SEC_MITM;
add_device_name_params.char_props.write = 1;
add_device_name_params.write_access = SEC_MITM;
// 1 for variable length and 0 for fixed length.
add_device_name_params.is_var_len = 1;
err_code = characteristic_add(p_lcb_service->service_handle,
&add_device_name_params, &(p_lcb_service->device_name_handles));
if (err_code != NRF_SUCCESS)
{
return err_code;
}
24
return NRF_SUCCESS;
}
/**@brief Function for setting the Status. */
uint32_t ble_lcb_service_status_set(ble_lcb_service_t * p_lcb_service,
ble_lcb_service_status_t * p_status)
{
ble_gatts_value_t gatts_value;
uint8_t encoded_value[MAX_STATUS_LEN];
// Initialize value struct.
memset(&gatts_value, 0, sizeof(gatts_value));
gatts_value.len = status_encode(p_status, encoded_value);
gatts_value.offset = 0;
gatts_value.p_value = encoded_value;
return sd_ble_gatts_value_set(p_lcb_service->conn_handle,
p_lcb_service->status_handles.value_handle, &gatts_value);
}
/**@brief Function for sending the Status. */
uint32_t ble_lcb_service_status_send(ble_lcb_service_t *
p_lcb_service, ble_lcb_service_status_t * p_status)
{
uint32_t err_code = NRF_SUCCESS;
if (p_lcb_service->conn_handle != BLE_CONN_HANDLE_INVALID)
{
ble_gatts_hvx_params_t hvx_params;
uint8_t encoded_value[MAX_STATUS_LEN];
uint16_t hvx_len;
// Initialize value struct.
memset(&hvx_params, 0, sizeof(hvx_params));
hvx_len = status_encode(p_status, encoded_value);
hvx_params.handle = p_lcb_service-
>status_handles.value_handle;
hvx_params.type = BLE_GATT_HVX_NOTIFICATION;
hvx_params.p_len = &hvx_len;
hvx_params.offset = 0;
hvx_params.p_data = encoded_value;
err_code = sd_ble_gatts_hvx(p_lcb_service->conn_handle,
&hvx_params);
}
else
{
err_code = NRF_ERROR_INVALID_STATE;
}
return err_code;
}
/**@brief Function for setting the Buzzer. */
uint32_t ble_lcb_service_buzzer_set(ble_lcb_service_t * p_lcb_service,
ble_lcb_service_buzzer_t * p_buzzer)
{
ble_gatts_value_t gatts_value;
uint8_t encoded_value[MAX_BUZZER_LEN];
// Initialize value struct.
memset(&gatts_value, 0, sizeof(gatts_value));
gatts_value.len = buzzer_encode(p_buzzer, encoded_value);
gatts_value.offset = 0;
gatts_value.p_value = encoded_value;
return sd_ble_gatts_value_set(p_lcb_service->conn_handle,
p_lcb_service->buzzer_handles.value_handle, &gatts_value);
}
/**@brief Function for setting the Pin. */
uint32_t ble_lcb_service_pin_set(ble_lcb_service_t * p_lcb_service,
ble_lcb_service_pin_t * p_pin)
{
ble_gatts_value_t gatts_value;
uint8_t encoded_value[MAX_PIN_LEN];
// Initialize value struct.
memset(&gatts_value, 0, sizeof(gatts_value));
gatts_value.len = pin_encode(p_pin, encoded_value);
gatts_value.offset = 0;
gatts_value.p_value = encoded_value;
return sd_ble_gatts_value_set(p_lcb_service->conn_handle,
p_lcb_service->pin_handles.value_handle, &gatts_value);
}
/**@brief Function for setting the Device Name. */
uint32_t ble_lcb_service_device_name_set(ble_lcb_service_t *
p_lcb_service, ble_lcb_service_device_name_t * p_device_name)
{
ble_gatts_value_t gatts_value;
uint8_t encoded_value[MAX_DEVICE_NAME_LEN];
// Initialize value struct.
memset(&gatts_value, 0, sizeof(gatts_value));
gatts_value.len = device_name_encode(p_device_name,
encoded_value);
gatts_value.offset = 0;
gatts_value.p_value = encoded_value;
return sd_ble_gatts_value_set(p_lcb_service->conn_handle,
p_lcb_service->device_name_handles.value_handle, &gatts_value);
}