Compréhension du protocole bluetooth appliqué aux modules bluetooth

[comptet]

Bonjour tout le monde,

Je cherche à réaliser un réseau sans fil en bluetooth entre un pc et un FPGA (PLD), afin de transmettre des données.
Je suis parti de zéro côté réseau et bluetooth car je n'avais aucune connaissances dans ce domaine.

J'ai lu la norme du protocole bluetooth (en diagonale car 600 pages je ne pouvais pas ^^), j'ai compris les différentes couches du protocole (Radio Frequence, BaseBand, Link Manager, HCI, etc...).
Du coup j'ai commencé à regarder du côté des modules bluetooth existants sur le marché.
Je me suis arrêté sur celui de chez Texas Instruments, le CC2560, car j'ai besoin d'une plage de température en stockage qui va au moins de -55°C à 85 °C.
C'est un contrôleur dit "Classic Bluetooth" qui supporte la norme bluetooth 4.0.
Il possède toute les couches basses (hardware) jusqu'au HCI, et ensuite les données transitent par l' UART.
Par contre TI ne précise pas (ou alors je n'ai pas su trouver l'info) si le composant intégré un bluetooth stack et des profils, celui qui m'intéresserai est le SPP.

Mon problème arrive à ce moment la.
De ce que j'ai lu dans les différentes doc du protocole bluetooth, les couches réseaux supérieures au HCI me semble nécessaires (mais je n'en suis pas totalement sure).
Du coup je me pose la question :
-faut-il que je rajoute un microcontrôleur (comme le MSP430 de chez Texas Instruments) entre le contrôleur bluetooth et le FPGA. Ce µC gérerait les couches hautes du protocole bluetooth (TI fournie un bluetooth stack).
-Ou je peux interfacer le contrôleur bluetooth directement avec le FPGA, car il possède lui aussi un UART, et du coup je suppose qu'il faudra que je me paluche certaines couches hautes du réseau, mais niveau complexité, je ne sais pas si c'est à ma portée vue que je suis débutant en réseau.

J'ai vue la carte d'évaluation de ce composant, la CC256x Bluetooth / Dual-Mode Evaluation Module de chez Texas Instruments. Et dans la description de celle ci, TI parle d'un bluetooth stack inclut avec certains profils. Or en regardant le PCB de cette carte d'évaluation, je ne vois aucun µC ou autres composants susceptible d’accueillir ce bluetooth stack et les profils. Du coup est ce que quelqu'un sait si le contrôleur simple (le CC2560) les embarque également ?
Ou alors est ce moi qui suis complétement à coté de la plaque ?

Je remercie d'avance ceux qui consacreront un peu de leur temps pour m'aider ^^
-----

[albanxiii]

Bonjour,

SPP est au dessus de HCI, il faut que vous lisiez la partie "profile" des spécifications Bluetooth. Il vous faut les couches supérieures dont vous parlez.
A l'époque où je travaillais sur Bluetooth (y'a longtemps !), la stack BlueZ était très bien, et opensource, sous Linux.

@+

[comptet]

Bonsoir,

Merci pour votre réponse albanxiii.
Mais de ce que j'avais compris, le bluetooth stack BlueZ ou un autre, ce n'est pas un soft que l'on fait tourner sous un OS PC (Linux, windows, etc...) ?
C'est peut être la du coup ou je me trompe sur le support de ce soft.

[RISC]

Salut,
Quelle norme bluetooth veux-tu utiliser : bluetooth classic (jusqu'à 3.0), Bluetooth LE (Single mode), ou les deux (dual mode).
Si c'est Bluetooth classic, tu peux utiliser les modules certifiés RN41 ou RN42 qui intègrent la stack bluetooth et gère le profil SPP.
Je suppose que tu vas devoir utiliser bluetooth Classic si l'autre coté est un PC
a+

[A voir en vidéo sur Futura]

[albanxiii]

Re,

Mais de ce que j'avais compris, le bluetooth stack BlueZ ou un autre, ce n'est pas un soft que l'on fait tourner sous un OS PC (Linux, windows, etc...) ?

C'est forcément sous Linux, vous pouvez oublier windows. Mais Linuw ne tourne pas que sur PC.
Si j'ai bien compris, vous ovulez transférer des données entre un PC et un FPGA, mais j'imagine que ces données côté FPGA ne sont pas des bits générés aléatoirement par le FPGA... il doit bien les tirer de quelque part. Et si c'est le FPGA qui reçoit, il doit bien faire quelque chose de ces données.
Si du côté FPGA vous avez un processeur assez puissant et de la mémoire, vous pouvez mettre Linux dessus et le problème est réglé. Sinon, il existe des modules Bluetooth avec tout le logiciel qu'il faut pour faire tourner certains profiles. CSR (Cambrige Silicon Radio en propose, par exemple, mais ils ne sont pas les seuls).

@+

[comptet]

RISC
Au niveau de la norme je souhaite utiliser le bluetooth classic, du coup bluetooth 3.0, même la 2.1 m'irait.
Pour les modules RN41 et RN42, je les ai déjà vu, mais ils ne vont pas car j'ai besoin d'une gamme de températures de stockage de minimum -55°C à 85°C, et les modules RN41 et RN42 ne supportent que -40 à 85°C.
Du coup rien que cela, je peux éliminer pas mal de modules et composants. C'est pour cela que le CC2560 de chez TI m'intéresse.

albanxiii
Non les données ne sont pas des bits aléatoires, se sera des données stockées dans une mémoire, et le FPGA pourra venir également écrire des données dans cette mémoire, ça dépendra des situations.
Concernant la puissance et la mémoire du FPGA je ne la connais pas pour le moment. Dans un premier temps, je vais réaliser un prototype avec une carte d'évaluation, du coup le FPGA qui sera sur la carte d'évaluation ne sera pas aussi performant que celui utilisé au final.
Et si par hasard je m’aventure dans la réalisation de mon propre stack ? Je pense que c'est long à développer, plusieurs mois, voir plus non ?
Je ne connaissais pas CSR, je vais jeter un coup d’œil aux composants qu'ils proposent.
Merci.

[comptet]

Bonjour tout le monde, je reviens vers vous.

J'ai avancé dans ma recherche et compréhension du protocole Bluetooth.
J'ai trouvé dans la norme du bluetooth toutes les HCI commands and events.
Du coup maintenant je vois comment je peux établir une connexion entre deux périphériques et les différentes commandes qu'il faut envoyer et leurs réponses.

Par contre j'ai une interrogation sur laquelle je ne sais pas répondre.
Mes 2 périphériques sont d'un côté un PC avec le bluetooth intégré (ou je rajouterai une clé bluetooth si le PC n'en a pas) et de l'autre un contrôleur bluetooth (pour la gestion des couches matérielles) associé à un PLD que je programmerai pour les couches hautes.
Je reste sur cette configuration à cause de mon besoin pour la gamme de température de stockage de -55 à +85°C, car même les composants de chez CSR ne possèdent pas cette gamme la, du coup le seul que j'ai trouvé est le CC2560 de chez Texas Instruments.

Côté PLD, il y a la gestion des HCI commands, mais une fois que la connexion est établie (une connexion ACL), est ce que j'ai réellement besoin d’implémenter dans mon PLD les couches L2CAP, RFCOMM et autres ?
Car c'est des couches de mise en forme des données pour les couches applicatives hautes, or je n'en aurai pas dans mon PLD.

Merci d'avance pour votre aide.

[invite03481543]

Bonjour,

si je lis votre pemier post, je vois que vous découvrez le Bluetooth, loin de moi l'idée de vous décourager mais implanter une stack BT même quand on s'y connait n'est pas une mince affaire.
Pourquoi ne pas pendre un RN41 ou RN42, voir mieux un RN4020 en BT 4.x qui a plus d'avenir avec les nouveaux standards et consomme bien moins ?
Vous verrez c'est déjà pas triste même quand la sack est déjà présente....
On ne connait pas grand chose de votre application, vous voulez faire quoi au juste?

[comptet]

Merci pour votre réponse HULK28.

J'ai bien vue le module RN41 ou RN42, mais le problème est toujours le même, la gamme de température de stockage ne correspond pas à mon cahier des charges (-55 à 85 °C au minimum).

Pour mon application je vais essayer d'être plus claire.
J'ai débuté mon stage de fin d'école d'ingénieur. Il y a une application X dans l'entreprise ou je suis, et celle ci est en cours de conception et sera implantée en aéronautique. Je dois réaliser pour cette application un réseau sans fil afin de communiquer avec un PC. L'application X ne me concerne pas, je gère juste le réseau sans fil. Je dois faire les couches logicielles nécessaires au bon fonctionnement de la communication, ces couches seront implantées dans un PLD. L'entreprise ne veut pas utiliser un soft développé par quelqu'un d'autre, de ce que j'ai compris niveau qualification du matériel après ça ne passe pas, et je présume que l'entreprise voudra réutiliser ce soft par la suite et sans doute ajouter des fonctions quand cela sera nécessaire.

J'ai commencé par faire un tour d'horizon sur toutes les techno sans fil existantes aujourd'hui, j'en avais retenue 3, le zigbee, le bluetooth et le wifi.
Mais finalement j'ai retenue le bluetooth car le wifi consomme trop et son implémentation est plus compliquée, et le zigbee possède un taux de transfert un peu trop faible. Du coup le bluetooth s'avère le meilleurs compromis.

Au début de mon stage je ne connaissais absolument pas les réseaux et encore moins le sans fil, du coup je me suis documenté sur le modèle OSI, TCP/IP afin de mieux comprendre.

En parallèle je recherchais des composants répondant à mon cahier des charges (il est pas super précis, mais la contrainte la plus exigeante est la gamme de température de stockage qui doit être de minimum -55 à +85 °C et de fonctionnement de -40 à +85°C).
Du coup avec juste cette exigence, pas mal de composants sont mis sur la touche, et un des seuls que j'ai trouvé est le CC2560 de chez Texas Instruments.
Il y a aussi le LMX9838, le problème est que celui ci embarque tout le stack (L2CAP, RFCOMM, SPP, GAP, SDP) du coup je pense que niveau implémentation de soft je vais juste avoir besoin d'utiliser les "AT Commands", et pour le stage c'est un peu juste.

C'est pour ça que je me suis penché sur le CC2560, et la du je vais devoir faire beaucoup plus de soft et utiliser à la place les "HCI Commands".

Et actuellement j'en suis à me poser la question pour savoir si côté PLD, j'ai vraiment besoin des couches L2CAP, RFCOMM et SPP car de ce que j'ai compris ces couches remettent en forme et servent au transport des données pour les couches plus hautes.
Hors j'ai vue dans la datasheet du CC2560 que les données arrivent par l'UART (et la config du composant se fait aussi par l'UART), la norme bluetooth me donne le format des données qui sortent et rentrent de la couche HCI par le biais de l'UART.
Ces données je ne peux pas les utiliser directement ? car il y a une partie Payload dans la trame HCI et normalement c'est mes données utiles, j'aurai juste besoin de séparer ces données du reste de la trame non ?
Et dans le sens inverse quand je voudrai envoyer des données à la couche HCI, j'aurai a mettre en forme la trame comme il faut.

J'ai volontairement mis de côté les étapes de demande d'info des autres composants, la connexion, etc... car de ce côté la, rien ne me pose problème pour le moment.

J'espère avoir bien expliqué mon application ^^

Merci d'avance

[albanxiii]

Bonjour,

Côté PLD, il y a la gestion des HCI commands, mais une fois que la connexion est établie (une connexion ACL), est ce que j'ai réellement besoin d’implémenter dans mon PLD les couches L2CAP, RFCOMM et autres ?
Car c'est des couches de mise en forme des données pour les couches applicatives hautes, or je n'en aurai pas dans mon PLD.

Toutes ces couches tournent sur un processeur, c'est du soft (link controller, LMP, HCI et au dessus).
Vous en avez besoin pour établir les connexions.

Ou alors, vous faites un truc propriétaire qui s'en passe, des deux côtés, mais de toute façon il y aura du soft.

@+

[comptet]

Mais dans le contrôleur bluetooth CC2560, il y a la couche link manager, link controller et HCI, il y a toutes les couches basses jusqu'au HCI.
Du coup ces couches la je ne les crée pas.
Je me posais la question pour celles au dessus plutôt, car côté PLD ma connexion bluetooth doit remplacer un câble, du coup c'est juste transfert de données pure et dure, je ne vais pas avoir de transmissions synchrones, de support vers des périphériques audio ou tous autres choses que le bluetooth supporte en plus.

ALBANXIII vous entendez quoi par soft ? car de toute manière dans mon PLD je vais faire un soft en VHDL pour établir une connexion et la gérer ainsi que gérer les trames reçues et envoyées au HCI (par le biais de l'UART).

[RISC]

Salut,

Le problème est que si tu utilises un module HCI tu vas devoir faire certifier ta stack Bluetooth...J'espère que tu as un gros volume pour amortir le cout de cette certification...Car cela sera impératif si ce produit est destiné à être vendu.

a+

[comptet]

Bonjour,

@RISC
Ce n'est pas un problème à l'heure actuelle, car l'entreprise veut son propre soft et elle sait qu'il faudra passer par la certification du matériel et du soft.

Mais du coup si je me fais un stack maison, je pense qu'il faudra que les deux périphériques utilisent le mien (un en serveur et l'autre en client) non ?
S'il n'y a qu'un périphérique qui utilise mon stack et l'autre un stack bluetooth normal, cela ne marchera pas non ?

[comptet]

Bonjour tout le monde,

Du coup personne peut me confirmer ? Si je fais mon propre stack, les deux modules communiquant devront utiliser mon stack ? (un en serveur et l'autre en client)
Ou existe t'il des dongles bluetooth usb pour le côté PC qui pourraient convenir ?

Pour le moment tous les dongles bluetooth usb que je trouve sont du Plug and Play, du coup ceux ci ne fonctionneront pas avec mon stack maison, non ?

Je pensais à la place utiliser un deuxième module CC2560, relié au pc par un adaptateur USB-UART pour émuler une liaison série avec un port COM.
Et après je me ferai un petit soft sur PC, en java, VB ou autre, pour me faire une interface et gérer la connexion et les données envoyées/reçues.

Merci d'avance pour votre expérience ^^

A plus