Software

Bluetooth 5.1 : Toujours rien pour l’audio ?

écrit par audio du village

On n’en finit plus avec le bordel (la douleur m’égare) des nomenclatures du Bluetooth. Au départ Bluetooth 5.0, puis officiellement Bluetooth 5, la marque remet en avant les bases de la « Core Specification » d’une version 5.1, à savoir que cette version est maintenant ouverte aux développeurs.

Qu’est ce que cela veut dire une version 5.1 ? 3 options aux choix :

  • Qu’il n’y a pas vraiment de changement dans les noms, mais que le passage de la 5 à la 6 désignera un version majeure, parsemée de 1, 2 ou 3 versions mineures et plus rapprochées, pouvant potentiellement se mettre à jour sans vrai changement hardware (même si cela parait un peu compliqué)
  • Que le SIG fait n’importe quoi et repasse aux versions en 5.X, ce qui impliquerait de remettre un 5.0 au lieu du 5.
  • Que le concept de mise à jour majeure ou mineur n’existe plus.

Cette document n’est pour le moment qu’une vue générale, pas même un livre blanc. Je ne prendrais pas en détails tous les points (il me faudra un peu plus de temps).

Petit tour d’horizon.

(n’hésitez pas visitez mon article sur le Bluetooth 5 pour vous familiariser avec quelques concepts dont l’advertising)

TOUTES CES NOUVEAUTES SONT CONSULTABLES DANS CE DOCUMENT DU SITE OFFICIEL

Pas de changement sur l’audio

Est-ce vraiment une surprise ? Pas pour moi en tous cas, pas pour une mise à jour aussi rapide.

D’une manière générale, il y a 2 choses sur lesquelles :

  • Le Mode Low Energy ne semble toujours pas intégré d’audio, à moins que cela bien caché et hors des changements présentés ici
  • Il n’y a manifestement aucun changement sur le Mode Classic (excepté un micro détails sur lequel je ne reviendrai même pas)

En gros, s’il fallait reprendre la phrase de ma conclusion sur le Bluetooth 5 : Ne commencez pas à chouiner sur des casques qui ne seraient pas Bluetooth 5.1, ce sera aussi inutile que le Bluetooth 5 par rapport au 4.2, pour l’audio en tous cas.

Arrêtez vous là si vous veniez uniquement pour l’audio.

Les changements

La marque pointe 4 améliorations majeures, vous excuserez la traduction à la truelle (et peut être un peu inexacte) sur certains termes.

1. Repérage directionnel

Cette feature va permettre, via une technologie dite D’Angle D’Arrivée et d’une technologie dite D’Angle de Départ, de déterminer la direction du signal reçu, c’est à dire de pouvoir repérer très précisément un objet. Jusqu’à maintenant, 2 méthodes de repérage existaient, mais soit se limitaient à la distance en elle-même, avec une précision relative, soit demandaient l’utilisation d’un balise tierce, pour effectuer une sorte de triangulation.

Cette nouvelle méthode sera largement dédiée à la domotique et l’advertising, via le principe de balise. On peut aisément imaginer une condition de déclenchement, non plus à proximité d’une balise, mais à proximité ET dans une direction particulière, type repérage dans un musée ou publicité ciblée plus précisément. Certes dans l’idée on peut penser que cela sera utile pour retrouver ses écouteurs égarés, dans la pratique je ne suis pas persuadé que la fonction ait été développée pour ça.

Deux méthodes possibles pour ce repérage d’angle, l’un et l’autre demandant 2 antennes ou plus

EN REVANCHE. Cette méthode n’est pas miracle et demande, comme on peut le voir sur le schéma, de posséder : soit un réseau (au moins 2 antennes) d’émetteur ou un réseau de receveur (au moins 2 antennes), cela pour permettre de calcul l’angle d’incidence du signal. Je connais pas bien la composition de l’émetteur/receveur Bluetooth dans les smartphones et dans les objets connectés, mais cette fonction sera impossible si l’un et l’autre n’en ont qu’une seule.

Je reviendrais peut être en détail dessus (mais vu que l’audio n’est pas concerné), vu que cette méthode est un peu plus compliquée que ça dans les fait (pas tant que ça mais un peu plus).

2. Amélioration de la mise en cache du GATT

Le GATT est la gestion des profils dans le Bluetooth Low Energy.

Je saute très vite sur cette amélioration, qui si elle reste intéressante, notamment sur la consommation, sera de toute façon invisible pour l’utilisateur.

Pour faire très simple : 2 produits utilisant cette gestion de services GATT vont se parler, et se renseigner sur leur base de données (ou table d’attribut), contenant les services, caractéristiques, etc… via le biais de requêtes. Cette procédure est appelée « service discovery », et se faisait forcément jusqu’à maintenant, à chaque nouvelle connexion, que les bases de données changent ou non.

Exemple typique de cet échange, avec une potentielle mise en cache des attributs décrit en bleu clair

Mais justement, certains attributs peuvent varier dans certains devices, d’autres peuvent rester toujours les mêmes. Ainsi, la version 5.1 va définir un attribut de mise en cache, permettant de sauter (si pas de changement) cette opération au besoin.

Là encore je survole, avec peut être de grosse imprécisions, cette amélioration étant la plus dure à appréhender. N’hésitez pas à me communiquer une boulette ou une imprécision dessus.

3. Amélioration de l’advertising #1 : randomisation de l’indexation des canaux d’advertising

Egalement invisible pour l’utilisateur. Cette amélioration concerne uniquement les données d’advertising (voir le chapitre dans l’article sur le Bluetooth 5).

L’utilisation des canaux principaux (37, 38 et 39) pour les événements d’advertising se faisaient forcément en prenant le premier canal (37) en tête, et le dernier canal (39) en queue. Afin de réduire les risques de collisions de paquets, par exemple si 2 produits ou plus utilisent une séquence d’advertising (et voient l’utilisation d’un même canal en même temps), un temps de 0 à 10ms était alors définit pour « patienter » et éviter cette collision.

Le version Bluetooth 5.1 va introduire une randomisation de l’utilisation des canaux principaux pour ce type d’événements, n’étant plus limités à la séquence 37-38-39. Cette dimensions aléatoire doit permettre de largement réduire les problèmes en environnements parasités (beaucoup de smartphones en même temps par exemple), bien que rien ne précise si la durée de 0 à 10ms entre chaque événement est conservée .

4. Amélioration de l’advertising #2 : Transfert périodique de synchronisation d’advertising

Sans doute peu utilisée dans le futur (quoi que) mais potentiellement intéressante. La version Bluetooth 5 introduisait une possibilité d’événements d’advertising périodiques, permettant via une synchronisation (rien à voir avec une connexion) avec un autre device de se « mettre d’accord » sur un timing commun d’événements. Je ne suis pas tellement sûr de la finalité, n’étant pas développpeur, mais j’imagine, avec de très gros guillemets, que c’est ce genre de synchronisations qui sera particulièrement utile pour des applications type Broadcast audio, qui nécessiteront une grande quantités de données en restant hors connexion.

En revanche, la problématique de consommation et/ou de puissance qu’entraine la synchronisation en continue est problématique pour certains produits, comme par exemple une montre connectée. La nouvelle fonction de transfert introduite dans le Bluetooth 5.1, appelée PAST ( Periodic Advertising Sync Transfer ), permettra de se servir du smartphones (ou autre) pour faire le relais de cette synchronisation avec le premier objet (type balise ou autre) et laisser la montre faire le reste, c’est à dire l’échange de données en lui-même.

Le smartphone relaye les détails de synchronisation à la montre, procédure puissante et énergivore, laquelle peut faire le reste avec la télé.

Le SIG Bluetooth présente ainsi l’exemple suivant : Une montre connectée à un smartphone se trouve à proximité d’une TV, laquelle veut échanger avec la montre en synchronisant son timing d’advertising. De part sa nature un peu chétive, la montre ne permet pas une telle débauche de moyens demandée par une telle synchronisation. En revanche, le smartphone le peut. Ainsi, son rôle pourra être dans cette version de jouer le tampon entre la TV (avec laquelle elle assurera la synchronisation) et la montre, connectée à lui et pouvant donc parfaitement se faire envoyer des données de synchronisation de cette façon.

Je reviendrais peut être plus en détails sur ces améliorations et surtout sur les potentielles avancées pour l’audio, qu’elles soient dans le standard (mais apparemment nous n’aurons rien) ou hors standard, ce qui devrait logiquement arriver, en propriétaire, que ce soit via Apple ou Qualcomm. Il me faudra un peu de temps pour vraiment voir ces améliorations en détails.

Le reste des quelques améliorations est considéré comme mineur, je n’y reviendrai pas, par manque d’intérêt.

à propos de l'auteur

audio du village

laissez un commentaire