Interphone BLE SF32 (Talkback)¶

Qu'est-ce que Talkback ?¶

OpenSiFli Talkback est un exemple BLE de push-to-talk (PTT) multiappareil pour le kit de développement SF32LB52-DevKit-ULP, également appelé Huangshan Pi. En mode Master, un appareil crée une salle ; en mode Slave, il en recherche une et la rejoint. Une fois connecté, l'utilisateur maintient la touche de parole pour transmettre et la relâche pour arrêter. La référence officielle prend en charge jusqu'à huit appareils et permet à trois d'entre eux au maximum de parler simultanément.

Le projet utilise Opus pour le codage vocal et associe une LED RGB, des touches et un écran dans une interface locale minimale. Il permet également au Slave de se reconnecter avec une seule touche, affiche la tension et le niveau de batterie, passe en veille après 60 secondes sans entrée et gère l'allumage et l'extinction par appui long. Il constitue ainsi une référence plus complète pour un interphone portable qu'un simple exemple audio point à point.

Pourquoi l'implémentation SF32 ?¶

Ce parcours réunit BLE, audio, écran, touches, surveillance de la batterie et fonctions basse consommation de SF32LB52 dans une base opérationnelle. Une équipe peut évaluer le réseau et les performances audio sur du matériel de développement pris en charge avant d'investir dans une conception RF, audio et d'alimentation spécifique.

« Jusqu'à huit appareils et trois locuteurs simultanés » décrit une limite de l'implémentation amont, et non une capacité produit validée pour toutes les distances, interférences, pertes de paquets et configurations de simultanéité. La documentation amont ne précise pas non plus l'authentification des salles, la politique de chiffrement de la liaison, une garantie de confidentialité vocale, le statut réglementaire radio ni l'ensemble des conditions de licence du composant binaire talk_back. Chacun de ces points nécessite une revue produit distincte.

Note sur la source de la carte : La page chinoise de SiFli consacrée à la carte ULP est explicitement signalée comme pas encore disponible ; elle indique seulement les usages pour capteurs basse consommation et objets connectés portés, les options de capteurs à 3 ou 6 axes et des points de test réservés aux mesures basse consommation. Elle ne constitue pas une spécification complète de la carte. Vérifiez les périphériques à partir de la révision réelle et du schéma ; le comportement Talkback décrit ci-dessous provient du code applicatif figé.

Résultat, portée et critères d'entrée¶

Résultat attendu : utiliser au moins deux cartes dont la révision est identifiée pour reproduire la création d'une salle, la rejoindre, communiquer en PTT, quitter et se reconnecter, entrer en veille et se réveiller, ainsi que vérifier l'état de la batterie ; réunir ensuite assez de preuves pour décider si un matériel spécifique se justifie.

Hors portée : cette page ne démontre ni une couverture longue portée, ni une qualité vocale en liaison dégradée, ni un chiffrement de bout en bout, ni une certification, ni une consommation en production, ni la constance des antennes, ni une conformité réglementaire, ni une compatibilité avec tous les appareils BLE.

Critères d'entrée : l'équipe sait installer un environnement de compilation SiFli-SDK, flasher le firmware via UART, examiner les journaux et raccorder sans risque un haut-parleur et une batterie. Une base vocale complète nécessite au moins deux cartes de même révision.

Spécifications matérielles et logicielles¶

Spécification matérielle¶

Spécification logicielle¶

Choisir une configuration de référence prise en charge¶

Commencez avec deux cartes SF32LB52-DevKit-ULP de même révision. Verrouillez le dépôt de démonstration sur 6fa55ac, sélectionnez et consignez un commit SiFli-SDK concret conforme à ^2.4, et conservez la résolution Conan de talk_back/1.2@sifli. Ne modifiez ni les paramètres audio, ni la logique des rôles, ni le minutage basse consommation lors de la première reproduction.

Depuis la racine du dépôt, accédez au chemin qui existe réellement :

cd talkback/project
scons --board=sf32lb52-lchspi-ulp -j8

Sous Windows, le nom du script de flashage généré est build_sf32lb52-lchspi-ulp_hcpu\uart_download.bat. Exécutez-le et indiquez le port COM approprié lorsqu'il vous le demande. Utilisez la même image de référence sur tous les appareils et consignez l'identifiant de chaque carte ainsi que l'empreinte de l'image.

Commandes par défaut et indication d'état¶

Étapes du projet¶

Architecture système et dépendances¶

flowchart LR
    subgraph A["Master — SF32LB52-DevKit-ULP"]
        AM["Microphone"] --> AC["Opus / traitement audio"]
        AK["KEY1 / KEY2"] --> AN["Machine à états de salle et PTT"]
        AN --> AL["LED RGB / écran"]
        AC <--> AN
    end
    subgraph B["Slave — SF32LB52-DevKit-ULP"]
        BN["Composant réseau BLE Talkback"] <--> BC["Opus / traitement audio"]
        BC --> BS["Haut-parleur"]
        BK["KEY1 / KEY2"] --> BN
        BN --> BL["LED RGB / écran"]
    end
    AN <--> |"Commande de salle et voix via BLE"| BN
    AP["Batterie / alimentation USB"] --> A
    BP["Batterie / alimentation USB"] --> B

Les principaux domaines de panne sont la recherche BLE et la création de salle, la synchronisation de son état, l'ordonnancement des locuteurs simultanés, la chaîne Opus/acoustique, les événements des touches, la batterie faible et la veille, la récupération par la touche d'alimentation, ainsi que les détails non publiés des composants et de leurs licences. Commencez par diagnostiquer le rôle et l'état, puis distinguez les défaillances radio, audio et d'alimentation locale.

Étape 1 — Établir la référence source intacte¶

Objectif : vérifier que les sources, le SDK et les dépendances résolues, tous verrouillés, produisent une image reproductible.

1. Verrouillez le commit de l'application et un commit SDK concret ; conservez la sortie de résolution des dépendances.
2. Compilez sf32lb52-lchspi-ulp dans un répertoire propre et flashez le firmware sur deux cartes.
3. Vérifiez que chaque appareil démarre en Slave avec une LED rouge fixe, puis contrôlez les touches, l'écran, la batterie et le haut-parleur.

Éléments à conserver : manifeste complet des versions, journaux de compilation et de flashage, empreintes des firmwares, révisions des deux cartes et comptes rendus de démarrage.

Critère de sortie du point de contrôle 1 : les mêmes entrées génèrent de façon reproductible la même image de référence, flashée sur les deux appareils ; leur état au démarrage correspond au comportement amont.

Étape 2 — Valider la configuration de la salle et le PTT bidirectionnel¶

Objectif : vérifier qu'un utilisateur peut créer et utiliser une salle minimale sans intervention du débogueur.

1. En Standby, appuyez brièvement sur KEY2 pour passer un appareil en Master (LED bleue fixe) ; laissez l'autre en Slave (LED rouge fixe).
2. Maintenez KEY2 sur les deux appareils : le Master crée une salle et le Slave la recherche. La tentative d'association expire au bout de 30 secondes.
3. En attente, maintenez KEY2 sur le Master pour démarrer. En état de conversation, maintenez KEY2 pour parler et relâchez-la pour arrêter.
4. Vérifiez que la LED est verte fixe pendant l'émission et orange fixe pendant la réception, et que la voix reste intelligible dans les deux sens.

Éléments à conserver : rôles, chronologie des opérations, états des LED, journaux UART, échantillons audio bidirectionnels et résultats des nouvelles tentatives.

Critère de sortie du point de contrôle 2 : au moins deux appareils effectuent plusieurs sessions PTT bidirectionnelles ; les indicateurs correspondent au sens réel de l'audio et l'expiration de 30 secondes ramène à un état explicable.

Étape 3 — Valider les limites de sortie, de reconnexion et de capacité¶

Objectif : vérifier que les chemins de récupération et limites de capacité amont ne laissent pas l'utilisateur dans un état bloqué.

1. En état de conversation, relâchez KEY2 avant d'appuyer brièvement sur KEY1 pour quitter ; un appareil ne peut pas quitter la salle pendant qu'il transmet.
2. Un Slave ayant déjà rejoint une salle avec succès peut se reconnecter par appui bref sur KEY1 en Standby. Le Master ne dispose pas d'un mécanisme équivalent.
3. Testez le fonctionnement hors de portée, l'expiration de la tentative d'association, la perte du Master et le redémarrage après coupure d'alimentation.
4. Si le fonctionnement à plusieurs appareils est requis, augmentez le nombre de participants jusqu'à la cible et vérifiez les limites annoncées de huit appareils et trois locuteurs simultanés.

Éléments à conserver : état initial, déclencheur, action et durée de récupération, journaux et appartenance finale à la salle pour chaque panne.

Critère de sortie du point de contrôle 3 : chaque panne visée a un chemin de récupération explicite, reproductible et compréhensible par l'utilisateur ; la capacité et la simultanéité requises sont mesurées dans l'environnement RF cible, et non déduites de la limite annoncée.

Étape 4 — Évaluer l'audio, les performances RF et la consommation énergétique¶

Objectif : déterminer si le comportement de la carte de développement convient au boîtier, à la portée et à l'autonomie visés.

1. Consignez l'intelligibilité, l'écrêtage, l'écho et les coupures au début/à la fin du PTT en environnement calme, en double parole côté microphone, avec bruit de fond et à plusieurs niveaux de volume du haut-parleur.
2. Consignez la connexion, les pertes et la récupération à la distance cible, derrière des obstacles et en présence d'interférences 2,4 GHz.
3. Vérifiez la veille après 60 secondes sans entrée, le retour au rôle Slave, le réveil par n'importe quelle touche, l'arrêt et la mise sous tension par appui long, ainsi que l'indication LED sous 20 % de batterie.
4. Mesurez le courant en attente (appareil actif), en émission, en réception, en veille et au réveil ; ne confondez pas les mesures sur carte de développement avec l'autonomie du produit final.

Éléments à conserver : environnement, orientation de la carte et de l'antenne, fichiers audio, distance et interférences, courbes de courant, état de la batterie et résultats de récupération.

Critère de sortie du point de contrôle 4 : l'équipe produit a défini et atteint les seuils acoustiques, RF, d'alimentation et de réveil pour son environnement cible ; chaque écart a un responsable et un plan de traitement.

Étape 5 — Revue de préparation produit¶

Avant de concevoir du matériel spécifique, répondez au minimum aux questions suivantes :

• Comment une salle identifie-t-elle les appareils de confiance, et quels mécanismes d'authentification, de chiffrement et de protection contre le rejeu protègent la voix et les données de commande ?
• Qui est responsable des licences, de la mise à disposition du code source et de la réponse aux vulnérabilités de talk_back/1.2@sifli, d'Opus, des composants WebRTC et des fichiers source du dépôt ?
• Quelle couverture, latence, perte de paquets et capacité de récupération ont été mesurées avec l'antenne et le boîtier visés, en présence d'obstacles corporels et de communications simultanées ?
• Comment le microphone, l'amplificateur, la cavité du haut-parleur et les limites de volume satisferont-ils les exigences acoustiques et de sécurité ?
• Comment l'appareil récupère-t-il après une batterie faible, une coupure anormale, un firmware corrompu ou l'échec d'une mise à jour sur le terrain ?
• Quelles activités de conformité Bluetooth, CEM, radio et batterie s'appliquent ?

Critère de sortie du point de contrôle 5 : le registre des risques inclut des preuves, des responsables, des mesures d'atténuation et une décision explicite de poursuivre, différer ou arrêter. Les sujets de sécurité, de licence et de réglementation ne peuvent pas rester des tâches « à traiter plus tard » sans responsable.

Passage à la conception du produit¶

Le dossier de transfert doit inclure les sources, le SDK et les dépendances verrouillés, les rôles et la machine à états, la matrice de capacité et de récupération, les mesures audio/RF/alimentation, les hypothèses d'antenne et d'acoustique, les limites liées à la batterie et à sa charge, le modèle de sécurité et de confidentialité, les documents de licence, les besoins en tests de production et le plan de récupération. Utilisez le parcours d'intégration SF32LB52x pour sélectionner le circuit, le module, la carte, le guide de conception matérielle et la liste de contrôle. Intégrez au schéma et au routage spécifiques les comportements validés, puis revérifiez-les au lieu de reprendre sans vérification les conclusions obtenues sur la carte de développement.

Sources de référence¶

• Répertoire Talkback d'OpenSiFli
• Commit de l'application examiné 6fa55ac
• README officiel de Talkback
• Manifeste Conan de Talkback
• Configuration du projet Talkback
• OpenSiFli/SiFli-SDK
• Source officielle du Wiki SiFli pour le SF32LB52-DevKit-ULP
• Source chinoise du Wiki SiFli pour le SF32LB52-DevKit-ULP

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