Mais uma vez, falando um pouquinho do que estou fazendo ultimamente com Bluetooth.
O perfil HDP (Health Device Profile) é, como o nome diz, voltado para dispositivos médicos e de fitness. Nesta lista entram coisas como medidores de pressão, oxímetros, podômetros (uma palavrinha d'Os Sertões que o modismo do fitness 'introduziu' na boca do povo -- Euclides da Cunha deve ter gostado), balanças com ou sem medidor elétrico de massa gorda corporal. Enfim, brinquedos relacionados à área da saúde.
O perfil é novo, e como eu disse no post sobre MCAP, os dispositivos são raros e caros. Mas a tendência é que se popularizem, e é perfeitamente possível um celular com Bluetooth e acelerômetros fazer o papel de podômetro.
Detalhes sórdidos
No frigir dos ovos, o perfil HDP define apenas o formato do registro SDP do serviço. Então, implementar HDP é, a rigor, nada mais que implementar a publicação e parsing desse tipo de ficha SDP.
Mas o HDP apresenta algumas 'surpresas desagradáveis' para quem for implementá-lo. Primeiro, ele usa MCAP como protocolo de transporte/sessão -- que por ser novo provavelmente não está implementado no seu sistema operacional. Segundo, o protocolo de aplicação é o IEEE 11073, que é bastante complicado (mas continue lendo, está a trabalhar-se numa implementação livre).
Para completar a lista, o HDP exige que as conexões L2CAP sejam em modo ERTM ou Streaming, ambos relativamente novos. Por exemplo, no Linux o ERTM entrou apenas no kernel 2.6.33 e ainda assim de forma experimental. Nos demais sistemas, provavelmente não há suporte algum.
Parece que quem elaborou a especificação do HDP quis usar todos os vistosos recursos novos do Bluetooth :)
No post sobre MCAP, mencionamos que uma conexão MCAP pode comportar diversos canais de dados, mas não é obrigatório usar todos os canais disponíveis. O HDP usa esse recurso, separando cada tipo de dado num canal diferente, e apenas os canais que interessam são realmente estabelecidos.
O HDP força cada canal de dados a ter um papel (role) bem definido: ou como fonte (source) ou como dreno (sink). Por exemplo, um medidor de pressão provavelmente só vai oferecer uma fonte. Uma balança com medidor de massa gorda poderia oferecer duas fontes.
Um computador ou celular pode ser um dreno. Um concentrador poderia ter canais de fonte e dreno ao mesmo tempo: drenos para obter dados de diversos sensores, e uma fonte para repassar tudo a um computador mais poderoso.
Tanto fontes quanto drenos são rotulados por tipos: oxímetro, balança, pressão, etc. Assim, o tipo da fonte tem de bater com o dreno, para que os dois lados "se entendam". Todos esses detalhes são publicados via SDP.
E quem toma a iniciativa da conexão? Normalmente, a fonte tem a iniciativa de conectar-se ao dreno com quem ela foi pareada, não sem antes obter o registro SDP para descobrir número do PSM L2CAP etc. Alguns dispositivos-fontes nem aceitam a conexão quando ela é de iniciativa do dreno.
Como o MCAP tem alguma proteção embutida contra conexões "cruzadas" entre os mesmos dois dispositivos, a questão da iniciativa não é um problema tão grande quanto parece a princípio.
No Linux
Assim como no caso do ERTM, o Linux sai na frente com o HDP.
Uma equipe da Espanha, do projeto OpenHealth, tem trabalhado no HDP para o BlueZ. O repositório pode ser encontrado em http://gitorious.org/bluez-mcap-hdp. Nosso trabalho baseia-se neste projeto.
Eles também estão trabalhado numa implementação do IEEE 11073, embora desta parte eu tenha ficado propositadamente longe :) Meu objetivo é ajudar a fazer o HDP "entrar" no BlueZ. Depois disso, talvez eu faça um script para tweetar minha pressão sanguínea ou pulsação para assustar os hipocondríacos.
Creio que o tipo mais comum de uso do HDP no BlueZ seja como dreno de dispositivos-sensores, embora possamos imaginar celulares na função de concentradores (com drenos e fontes), bem como simuladores de sensores HDP (com fontes), ou mesmo um Linux embarcado rodando num sensor comercial.
