Bluetooth PAN¶

Vue d'ensemble¶

Bluetooth PAN (Personal Area Networking, réseau personnel) permet à un appareil SF32 d'accéder à un réseau IP par une liaison Bluetooth classique. Pour accéder à Internet, il utilise généralement le partage de connexion du téléphone. Cette solution peut éviter l'ajout d'une radio Wi-Fi dédiée. PAN est l'un des profils Bluetooth classiques présentés dans la Vue d'ensemble Bluetooth et l'une des options de transport OTA décrites dans OTA et DFU.

Envisagez PAN pour un trafic IP intermittent ou modéré : météo, synchronisation de l'heure, appels d'API cloud, échanges avec un assistant vocal ou téléchargements de firmware. PAN peut éviter l'ajout d'un sous-système Wi-Fi dédié lorsque le coût, l'encombrement, l'effort d'intégration et la consommation de celui-ci l'emportent sur son intérêt pour le cas d'usage. Évaluez les exigences de conformité RF applicables au matériel choisi et au produit final.

Comment fonctionne le Bluetooth PAN¶

Le Bluetooth SIG définit PAN comme un profil Bluetooth Classic (BR/EDR). PAN transporte des paquets au format Ethernet sur une liaison ACL Bluetooth au moyen de BNEP (Bluetooth Network Encapsulation Protocol). BNEP fonctionne au-dessus de L2CAP, et non de RFCOMM. PAN nécessite BR/EDR et une implémentation PAN compatible, mais pas la prise en charge de BLE. Un matériel limité à Bluetooth Classic peut donc aussi implémenter PAN.

PAN ne fonctionne pas sur BLE. En revanche, le profil distinct Internet Protocol Support Profile (IPSP) permet de transporter IPv6 sur BLE. Cette possibilité du protocole ne prouve pas que SiFli-SDK ou le service de partage de connexion d'un téléphone implémentent IPSP. La comparaison BLE ci-dessous porte sur une application qui relaie les données GATT, pas sur IPSP.

Le profil définit trois rôles :

Le PANU peut découvrir les appareils proches par Inquiry et identifier leur service PAN et leur rôle par SDP. L'indication Networking dans Class of Device est un indice de découverte, pas une preuve qu'un service NAP utilisable est disponible. Après l'établissement d'ACL et de BNEP au-dessus de L2CAP, le NAP transmet le trafic vers son réseau externe par pontage ou routage, selon son implémentation. Il peut s'agir d'un téléphone ou d'une passerelle LAN, comme l'indique la spécification PAN. Chaque extrémité peut terminer la connexion ; dans l'architecture avec partage de connexion du téléphone décrite ici, un changement d'état du partage peut nécessiter une reconnexion.

Quand choisir PAN plutôt que le Wi-Fi¶

Pour un produit qui utilise déjà le Bluetooth bimode pour l'audio, les services GATT ou les profils Bluetooth Classic, PAN permet souvent d'ajouter un accès à Internet à faible coût, sans second sous-système radio. Cette solution suppose toutefois que le produit puisse dépendre d'un téléphone proche capable de partager sa connexion.

Transport de données sous iOS : relais BLE, Bluetooth Classic et PAN¶

Il est important de distinguer trois conceptions de connectivité iPhone différentes. Dire « le Bluetooth Classic requiert MFi » sans nuance est trop large : iOS prend en charge les profils Bluetooth standards, et le Partage de connexion lui-même peut utiliser le Bluetooth. La restriction s'applique lorsqu'une application iOS a besoin d'un canal de données personnalisé vers un accessoire Bluetooth Classic via le chemin External Accessory/iAP d'Apple. Apple documente qu'External Accessory communique avec les accessoires MFi via Bluetooth, tandis que son Q&A technique indique que les accessoires BLE utilisent Core Bluetooth à la place et ne sont pas tenus d'être conformes MFi.

Pour un assistant vocal, un client OTA ou tout autre produit qui nécessite un flux continu ou des échanges HTTP/WebSocket directs, PAN peut remplacer le relais BLE par application après validation de l'iPhone cible et de la configuration du SDK. L'exemple SiFli v2.5.1 active également A2DP pour contourner le problème documenté de connexion à PAN seul sous iOS ; A2DP n'est pas une exigence du protocole PAN. PAN ne remplace pas l'application nécessaire à la configuration du produit, à l'authentification des utilisateurs, aux notifications ou au contrôle local ; il évite simplement que le plan de données applicatif soit limité par ce relais applicatif. L'assistant vocal SF32 Xiaozhi illustre cette architecture en fonctionnement.

Prise en charge des appareils SF32¶

Pour SF32, choisissez une famille compatible avec Bluetooth Classic et vérifiez la pile PAN, la version du SDK et la configuration de la carte cible. Les familles compatibles avec PAN du tableau utilisent le Bluetooth bimode : c'est une caractéristique de ces appareils SF32, pas une exigence du protocole PAN.

Pour d'autres critères de choix entre BLE et Bluetooth bimode, consultez la Vue d'ensemble Bluetooth.

Exemple PAN de SiFli-SDK¶

SiFli-SDK fournit une implémentation PANU fonctionnelle dans example/bt/pan, compatible avec les séries de cartes eh-lb52x, eh-lb56x, eh-lb58x et sf32lb52/56/58-lcd. L'exemple se connecte au service PAN (NAP) d'un téléphone et permet de tester le réseau à l'aide de commandes Finsh. Par exemple, weather récupère les conditions météorologiques actuelles via la liaison PAN établie. La capture du README présente les champs de la réponse du service météo : id, name, country, path, timezone, timezone_offset, txt, code, temperature et last_update. L'exemple indique Chongqing (CN), Asia/Shanghai (+08:00), 多云 (« nuageux », code 4), une température de 10 et une mise à jour à 2025-01-13T15:54:09+08:00. Il s'agit de données applicatives, pas de champs PAN/BNEP ; leurs valeurs peuvent varier.

Au démarrage, l'exemple active Inquiry et Page Scan Bluetooth. Le téléphone peut ainsi détecter l'appareil et s'y appairer sous son nom Bluetooth par défaut, sifli_pan.

Pour HTTPS, configurez les certificats conformément au README PAN de v2.5.1. Les certificats CA par défaut se trouvent dans external/mbedtls_228/certs/default ; placez les certificats CA supplémentaires nécessaires dans external/mbedtls_228/certs. Ils doivent être au format PEM, pas DER : vérifiez la présence de -----BEGIN CERTIFICATE----- dans le contenu, sans vous fier uniquement à l'extension. Lorsque PKG_USING_MBEDTLS_USER_CERTS est activé dans proj.conf, la compilation regroupe les fichiers de ce répertoire dans ports/src/tls_certificate.c. Vérifiez les ancres de confiance nécessaires au serveur réel. Une connexion PAN réussie ne prouve pas que le certificat TLS a été validé ; vérifiez l'identité du serveur et l'heure de l'appareil lorsque le contrôle de la période de validité en dépend.

Le README nomme ce répertoire mbedtls_288, mais ses captures et le code de génération des certificats de v2.5.1 utilisent mbedtls_228. Les chemins ci-dessus suivent l'implémentation. Le script n'accepte que les certificats dont la première ligne commence par -----BEGIN CERTIFICATE ; conservez ce format et consultez les avertissements de compilation pour repérer les fichiers ignorés.

Avant d'exécuter l'exemple, vérifiez ces réglages dans le README de la version indiquée et pour votre plateforme cible :

• Activez CONFIG_BLUETOOTH, CONFIG_BT_PROFILE_CUSTOMIZE, CONFIG_CFG_PAN et CONFIG_BSP_BT_CONNECTION_MANAGER. L'exemple active aussi A2DP pour contourner le problème documenté d'iOS lors d'une connexion PAN seule ; A2DP n'est pas une exigence du protocole PAN.
• CONFIG_BT_FINSH active les commandes optionnelles de contrôle Bluetooth. Conservez les fonctions du shell nécessaires aux commandes à tester.
• Réglez CONFIG_BSP_BLE_NVDS_SYNC selon le processeur qui exécute Bluetooth : le README l'active pour HCPU et le désactive pour LCPU. Ne recopiez pas telle quelle une configuration dont la répartition entre processeurs est différente.
• Pour reconnecter le dernier appareil, vérifiez CONFIG_BT_AUTO_CONNECT_LAST_DEVICE et CONFIG_PKG_USING_FLASHDB. Validez la conservation des réglages après redémarrage et limitez les tentatives à l'aide des commandes de reconnexion du tableau précédent, plutôt que de réessayer indéfiniment.

Compatibilité des systèmes mobiles et validation produit¶

Le téléphone joue le rôle de NAP et fait partie du chemin réseau du produit ; ce n'est pas un simple outil de configuration. Son système d'exploitation, son modèle, le forfait de l'opérateur et les règles de partage de connexion font partie de la configuration produit à prendre en charge. Un appairage Bluetooth réussi ne suffit pas : le téléphone doit fournir un service PAN par Bluetooth et acheminer le trafic après la connexion du PANU.

Configuration sur le téléphone¶

Cette illustration indique où chercher les réglages ; ce n'est pas une capture d'écran réelle du système. Leur libellé et leur emplacement varient selon la version d'iOS/iPadOS, le fabricant Android et les règles de gestion du téléphone. Recherchez Autoriser d'autres personnes à se connecter sous iOS/iPadOS ou l'option de partage de connexion Bluetooth sous Android. La capture iOS de SiFli v2.5.1 montre également l'option Maximize Compatibility activée. Il s'agit d'un réglage illustratif, pas d'une exigence PAN ; vérifiez s'il est nécessaire sur chaque téléphone cible.

Suivez ces étapes pour chaque téléphone testé :

1. Vérifiez la connexion amont du téléphone. Le partage de connexion d'Apple utilise les données cellulaires ; assurez-vous que l'opérateur l'autorise. Certains téléphones Android peuvent aussi partager une connexion Wi-Fi, mais cette possibilité doit être vérifiée sur le modèle et la version exacte du système.
2. Activez le partage de connexion Bluetooth ou le Point d'accès personnel du téléphone avant de demander une connexion PAN depuis l'appareil SF32.
3. Appairez le téléphone et l'appareil, en gardant le téléphone découvrable lorsque l'OS l'exige.
4. Exécutez pan_cmd conn_pan, puis vérifiez un échange IP réel, par exemple avec la commande weather. Une connexion Bluetooth réussie ne suffit pas.
5. Désactivez le partage de connexion, mettez le téléphone en veille puis réactivez-le, et éloignez-le hors de portée. Vérifiez que le produit se reconnecte comme prévu.

Si le partage n'est activé qu'après que la connexion Bluetooth est déjà établie, reconnectez explicitement le PAN avec pan_cmd conn_pan.

Définir la matrice des téléphones pris en charge par le produit¶

Pour un produit grand public, publiez les combinaisons prises en charge modèle de téléphone + version d'OS + opérateur/région, plutôt qu'une simple mention « iOS » ou « Android ». Pour chaque modèle testé, consignez au minimum : modèle, numéro de compilation de l'OS, opérateur, service cellulaire actif et état de la SIM/eSIM, nom du réglage de partage de connexion, délai de première connexion, reconnexion après verrouillage de l'écran ou perte de la liaison radio, résultat avec un trafic soutenu et actions nécessaires pour rétablir le service. Reprenez ces essais après toute modification de l'application, du firmware PAN, de l'OS du téléphone ou du profil opérateur.

Mise à jour OTA via PAN¶

Dans l'exemple PAN, OTA est activé par défaut. pan_cmd ota_pan télécharge et installe une image de firmware par la même liaison Bluetooth PAN que celle utilisée pour le réseau, selon le chemin DFU_PAN OTA décrit avec le service de mise à jour de firmware de SiFli-SDK. Cette solution convient aux produits qui utilisent déjà PAN pour leurs données et n'ont pas besoin d'un second transport OTA. Consultez OTA et DFU pour comparer PAN à BLE et aux autres transports de mise à jour ; quel que soit le transport, prévoyez un mécanisme de retour arrière et de récupération.

Le README décrit aussi un échec de compilation lorsque la cible choisie ne possède pas de ptab.json adapté à OTA. Ses captures montrent comment désactiver le sous-projet DFU et le support de mise à jour du middleware pour tester l'exemple sans OTA. Ce diagnostic supprime OTA ; il ne permet pas de commercialiser un produit qui doit être mis à jour. Fournissez et validez la disposition des partitions et la configuration de mise à jour correctes avant d'activer ce transport.

PAN fournit un transport, pas une garantie d'authenticité du firmware ou de récupération. Avant la commercialisation, validez l'authentification du serveur, l'authenticité et l'intégrité de l'image, la compatibilité de cible et de version et la récupération après interruption. Testez les pertes de connexion et les coupures d'alimentation, puis vérifiez le comportement réel de récupération ou de retour arrière du bootloader ; ne supposez pas que la commande de téléchargement fournit ces protections.

Exemple de produit SF32 utilisant PAN¶

Le projet assistant vocal SF32 Xiaozhi est un exemple fonctionnel de PAN sur SF32 : l'appareil accède à Internet via un téléphone appairé et transmet les échanges vocaux à un service cloud par cette liaison. Le projet montre comment un produit intègre la connectivité PAN, le trafic applicatif WebSocket/HTTP et sa dépendance au partage de connexion du téléphone.

Dépannage¶

Le README recommande aussi de contrôler l'attribution de l'adresse Bluetooth. Lisez l'adresse avec nvds get_mac. Utilisez uniquement un OUI attribué à votre organisation ou autorisé pour le produit, avec une adresse unique par appareil ; ne copiez pas l'OUI d'un autre fabricant depuis un exemple. Dans nvds update addr 6 xxxxxxYYYYYY, YYYYYY est l'OUI avec l'ordre des octets inversé et xxxxxx représente les trois autres octets. Respectez l'ordre des octets de la commande au lieu de coller telle quelle une adresse MAC affichée.

CONFIG_NVDS_AUTO_UPDATE_MAC_ADDRESS peut écraser une modification manuelle. Si une adresse de test autorisée n'est pas conservée, le README recommande de désactiver cette option, de recompiler et de flasher à nouveau le firmware, puis de définir à nouveau l'adresse. Il s'agit d'un diagnostic de test, pas d'une politique d'attribution en production : validez après redémarrage la politique automatique ou de programmation en usine retenue avant la commercialisation.

Liste de contrôle de mise en service¶

• Vérifier le matériel Bluetooth Classic et la pile/configuration PAN pour le SDK et la carte précis. L'exemple de référence liste SF32LB52x/56x/58x ; valider SF32LB57x séparément. SF32LB55x ne prend en charge que BLE.
• Déterminer si la dépendance de PAN au partage de connexion du téléphone convient au produit ou si une radio Wi-Fi dédiée est nécessaire.
• Mettre en service example/bt/pan sur la carte cible et vérifier le partage de connexion côté téléphone (Point d'accès personnel sous iOS/iPadOS ou partage Bluetooth sous Android).
• Valider de bout en bout une connexion PAN réelle et au moins une opération réseau, par exemple la commande weather de l'exemple.
• Tester chaque modèle de téléphone, numéro de compilation de l'OS, combinaison région/opérateur et chemin de réglage prévu. Ne pas annoncer une compatibilité générale « iOS/Android » sans ces essais.
• Vérifier que l'OUI de l'adresse MAC Bluetooth de l'appareil est valide avant d'utiliser les fonctions réseau.
• Si PAN sert au transport OTA, tester entièrement pan_cmd ota_pan, y compris le retour arrière, avant la mise sur le marché.
• Définir le comportement de reconnexion et de reconnexion automatique (set_retry_flag, set_retry_time) selon la fréquence à laquelle le téléphone doit se trouver à portée.

Points clés à retenir¶

• Bluetooth PAN transporte du trafic IP ou de type Ethernet sur BR/EDR, par BNEP au-dessus de L2CAP. BLE n'est pas requis. IPv6 sur BLE utilise le profil distinct IPSP, pas PAN, et nécessite une pile et une passerelle dont la compatibilité a été vérifiée.
• Les appareils SF32 utilisent le rôle client PANU et se connectent généralement à un téléphone jouant le rôle de NAP via le partage de connexion ou le Point d'accès personnel.
• Sous iOS, les accessoires BLE peuvent utiliser Core Bluetooth sans MFi. En revanche, un canal de données personnalisé entre une application et un accessoire Bluetooth Classic via External Accessory/iAP relève du programme MFi. PAN utilise le partage de connexion du téléphone pour permettre à l'appareil SF32 d'utiliser son propre client IP plutôt que de faire relayer les données par une application BLE.
• L'exemple PAN de référence liste les cibles SF32LB52x/56x/58x. SF32LB57x dispose d'un matériel bimode, mais sa pile PAN et sa carte nécessitent une validation distincte ; SF32LB55x ne prend en charge que BLE et ne peut pas utiliser PAN.
• example/bt/pan de SiFli-SDK est une implémentation de référence fonctionnelle avec des commandes Finsh pour se connecter, rétablir la connexion et effectuer une mise à jour OTA via PAN.
• Le PAN avec partage de connexion convient à un trafic IP intermittent ou modéré lorsque le téléphone se trouve généralement à proximité. Pour un débit élevé soutenu ou un fonctionnement indépendant du téléphone, évaluez une radio Wi-Fi dédiée ou une autre voie réseau indépendante ; une passerelle NAP autre qu'un téléphone est également possible.

Dernière mise à jour: 2026-10-19