Je traînais à Gifi avant les fêtes de Noël lorsque je suis tombé sur une montre connectée à un peu plus de 10 euros. Elle m'a rappelée mes déboires avec certaines smartwatches trouvées sur AliExpress, à la fois dans sa forme et dans les fonctionnalités suggérées par les photos de cette dernière affichées sur la boîte. Je me suis donc délesté d'une dizaine d'euros et suis reparti avec, dans l'idée de l'analyser durant un live Twitch. Et je n'ai pas été déçu !
Je planifie début janvier 2025 un live Twitch en annonçant que je vais m'amuser à analyser cette montre connectée, que ce soit au niveau de son électronique ou de son application associée. Je suis relativement curieux de savoir comment toutes ces fonctionnalités sont possibles dans une montre à moins de 15€.
Une fois la boîte ouverte, je me retrouve avec une montre qui semble d'assez bonne facture, avec un bracelet silicone plutôt agréable à porter, un chargeur magnétique et une notice d'utilisation. La notice indique de charger la montre à bloc avant le premier démarrage, cependant elle ne réagit pas à mes manipulations. Je la laisse se charger pendant une bonne demi-heure, et elle fonctionne alors comme prévu. Peut-être était-ce du au fait que je n'y ai pas touché pendant un mois ? En tout cas le niveau de batterie en sortie de boîte semble être relativement faible.
J'installe en parallèle l'application mobile associée, Lefun Health, sur mon smartphone (même pas peur !), crée un compte pour l'application et appaire ma montre avec cette dernière. Elle est reconnue sans problème, et la mise à jour automatique de l'heure et de la date se fait bien. Cependant, l'application mobile requiert tout une floppée de permissions assez intrusives comme l'accès au carnets de contacts, mais vu que la montre est censée pouvoir afficher les appels reçus, il est possible que ce soit normal.
L'application propose toute une floppée de thèmes de cadrans (ou watch face) sur la montre, mais à ma grande surprise la plupart sont payants et impossible d'en installer via mon smartphone qui tourne sous /e/OS.
Un aspect de la montre m'a tout de même intrigué. Comme l'expliquait Stéphane Marty dans son excellente vidéo intitulée Montre connectée intelligente à 2€ : anatomie d'une arnaque Aliexpress, les capteurs permettant de mesurer la saturation en oxygène dans le sang, ainsi que ceux mesurant le rythme cardiaque par exemple sont relativement coûteux et sont composés de plusieurs éléments miniaturisés dont des récepteurs photosensibles qui doivent être visibles sous le boîtier.
En regardant de plus près le boîtier de la montre, on observe la présence de quatres lentilles qui peuvent correspondre à ce type de capteurs. Néanmoins, il est difficile sans ouvrir ladite montre de savoir exactement quelle technologie est utilisée.
Je fais une série de mesure avec la motre portée sur mon bras, et elle donne des résultats qui semblent être acceptables. Lorsque les fonctions de mesure sont utilisées, que ce soit le rythme cardiaque, la saturation en oxygène ou la pression artérielle, les lentilles au dos du boîtier de la montre clignotent en rouge.
Je décide afin de tester la fiabilité de ces capteurs de placer la montre sur mon tapis silicone, utilisé habituellement pour les travaux de soudure, et de voir si déjà la montre se rend compte qu'il y a comme un souci. J'active le mode d'analyse de fréquence cardiaque et pose la montre à plat sur le tapis: après plusieurs secondes d'analyse, l'écran affiche différentes valeurs et enfin la synthèse des mesures.
Mon tapis serait-il ... vivant ? Je fais de même avec la mesure de saturation en oxygène, et la mesure de pression artérielle: à chaque fois la montre arrive à obtenir des mesures bien qu'elle ne soit pas portée sur un bras.
Je décide alors, pour en avoir le cœur net, d'ouvrir purement et simplement la montre afin de mettre à nu son électronique, exactement comme Stéphane Marty l'avait fait avec une smartwatch en provenance d'AliExpress.
L'ouverture du boîtier de la montre est un peu laborieux, je m'y attendais car il est marqué sur le site du distributeur (Gifi) que cette dernière est étanche:
Cependant, après quelques efforts à base de scalpel et d'outil adapté, j'arrive dans un premier temps à retirer le cache situé sur l'arrière du boîtier, celui se trouvant au contact de la peau du bras, et découvre la présence de quatre LEDs sur un circuit flexible, avec une sérigraphie indiquant "TS12-3_L21_KEY+LED_V1.0". Aucun capteur biométrique de présent, simplement des LEDs et un bouton poussoir connecté sur un PCB flexible !
Pour vous donner une idée, la photo ci-dessous montre un ensemble de capteurs de la Fitbit Surge où l'on peut voir des LEDs et un capteur photosensible utilisé pour mesurer les pulsations cardiaques (entre autres).
Je réussis ensuite à retirer l'écran et découvrir l'intérieur de la montre, et à ce moment la supercherie ne tient plus. La montre possède une petite batterie (annoncée à 200mAh) reliée à un petit circuit imprimé, auquel est aussi connecté un écran avec dalle tactile, un vibreur, un haut-parleur et un microphone. Pas de trace de capteur, juste ce qui ressemble à un système-sur-puce JieLi AC6958C6 en charge de la gestion de l'écran, de l'audio, de la connectivité Bluetooth, ainsi que des entrées utilisateurs.
Le circuit contient aussi un accéléromètre (utilisé par exemple pour déclencher des photos lorsque la montre est secouée) et une puce gérant la dalle tactile (BL6133).
Aucune trace de puce électronique ressemblant à un capteur de rythme cardiaque ou de mesure de saturation d'oxygène dans le sang, ni de capteur photosensible. Il y a fort à parier que les valeurs affichées par la montre sont tout simplement générées de façon aléatoire dans une plage de valeurs considérées comme normales.
Une smartwatch à 12 euros, cela semblait alléchant mais ce n'est au final pas bien différent de celles vendues sur AliExpress et qui ne correspondent pas aux promesses faites par le fabricant. Là où je suis étonné, c'est de trouver ce type de produit en rayon chez Gifi.
J'ai parcouru la notice en long et en large, et celle-ci mentionne pourtant des fonctionnalités qui sont simplement absentes du produit, mais qui semblent être simulées par ce dernier, en particulier les fonctions de suivi de santé. La notice mentionne certes que les données mesurées ne doivent pas être utilisées à des fins médicales, ambulatoires ou diététiques. Je peux comprendre pourquoi.
Le projet CutcutGo, qui vise à fournir un firmware de remplacement pour la Maker de Cricut, avance plutôt bien. En effet, j'ai pu boucler le développement d'un bootloader permettant la mise-à-jour du firmware de la machine via USB, ce qui permet une maintenance plus simple et évite de devoir utiliser le connecteur situé sous la machine pour déployer une nouvelle version du logiciel.
C'était à mon sens une des premières fonctionnalités critiques que je devais implémenter pour permettre aux beta-testeurs de tester facilement les versions en cours de développement et de pouvoir restauter une version fonctionnelle en cas de souci, et cela sans avoir à sortir un programmateur.
J'ai aussi pu améliorer la façon dont le micro-logiciel gère le démarrage et l'arrêt de la machine ainsi que la calibration automatique du moteur de l'axe X afin de pouvoir s'adapter aux légères différences qu'il existe entre les machines. On s'approche de plus en plus de quelque chose d'utilisable, même si certaines fonctionnalités sont encore manquantes... Il n'est pas encore possible d'utiliser une connexion Bluetooth Low Energy pour piloter la machine, et la fonctionnalité de print then cut disponible sur la machine d'origine est loin d'être implémentée. Ceci dit, je suis très satisfait du résultat et de comment le projet avance, sachant que je le développe seulement durant les streams (à raison d'une soirée par semaine).
Ce projet est quasi terminé, mais comme dans tous mes projets c'est la fin qui est très difficile à gérer. J'ai un prototype entièrement fonctionnel, que je vais passer à des collègues dans un futur très proche pour qu'ils le testent et me donnent leur avis sur la complexité et l'originalité des tâches à réaliser, sachant que cela doit convenir au débutant tout comme au reverser confirmé.
Je pense attaquer la finalisation de ce projet courant novembre, mais à mon humble avis il ne sera pas bouclé avant janvier 2024. Ça me fait mal de l'écrire, mais je sais que la fin d'année va être pas mal remplie donc je ne prévois pas grand chose pour décembre.
J'avais pris une bonne résolution en janvier de cette année, celle de ne pas m'éparpiller dans mes projets comme je le fais d'habitude, sans rien terminer (qui a dit ADHD ? -- faudra qu'on en parle un des ces jours par ailleurs...). Et je crois que pour le moment, à l'exception d'un ou deux streams Twitch où il fallait absolument que je me change les idées, j'ai pour le moment réussi à m'y tenir.
Cependant, je dois avouer que ce n'est vraiment pas simple. J'accumule du matériel acheté au cours de l'année dans une boîte, la boîte des "trucs à bidouiller plus tard", qui commence à être bien remplie. J'ai de quoi hacker pour faire des consoles portables à base d'ESP32, un téléphone opensource, des trucs permettant de hacker des protocoles radios, des badges électroniques cools, et plus encore. Mais globalement pas assez de temps pour ne faire que 10% de tout cela.
Et ça ne va pas s'arranger, car il y a tout le temps un truc qui capte mon attention et me tend les bras en attendant que je cède à la nouveauté et qu'il vienne s'ajouter à la longue liste de trucs super intéressants que je dois faire mais qu'en fait non, car je lutte pas mal pour rester sur mes deux projets principaux. Sauf que j'ai fait une rechute, récemment.
J'ai cédé à un caprice technologique, aucune idée du pourquoi. Un jour, je traînais sur Amazon et je suis tombé sur un clavier Qwerty 60%. Un petit clavier mécanique, avec des beaux switchs et un format très intéressant. Et je me suis dit que ça serait une bonne idée de me mettre à un clavier qwerty, et tant qu'à faire tester ce clavier. Oui, ça fait des années que des collègues me demandent pourquoi je n'utilise pas de clavier Qwerty pour le développement, et effectivement, pourquoi ? Alors j'ai craqué. J'ai acheté ce petit clavier 60%, ai reconfiguré tous mes systèmes pour l'utiliser, et ai passé une rude semaine à passer mes habitudes de Azerty à Qwerty. Pas simple, mais pas si éprouvant que cela.
Aujourd'hui, je ne regrette absolument pas d'avoir franchi le pas. Oui, le clavier Qwerty est une bénédiction pour le développeur: tous les caractères spéciaux utilisés dans les différents langages de programmations sont accessibles directement, le pavé numérique est inutile, et les caractères accentués ne sont pas si nécessaires que cela. Seul hic: mon clavier de laptop du boulot qui est en Azerty et qui m'embrouille de temps à autre le cerveau.
Alors oui, je suis content avec mon clavier 60%, mais il y a des choses que j'aimerais améliorer dessus. L'absence de flèches directionnelles se fait parfois sentir, tout comme les touches Page Up et Page Down. Et là je découvre qu'il existe des claviers 65% qui possèdent ces touches, et qui sont opensource de surcroit ! C'est un enfer. Je vais me fabriquer mon clavier 65% from scratch et je suis super content de cela. Non, je n'aurais jamais du mettre les doigts sur ce type de claviers, je me suis fait happé et je suis parti pour des années de customisation de layout et de discussions autour des différentes marques et types de switches mécaniques... Fuyez, pauvres fous !
Sans compter que ça va de fait casser mon assiduité à mes projets principaux.
L'année 2021 démarre plutôt bien, et j'ai profité des premiers lives Twitch de l'année pour continuer la bidouille de minitels mais aussi pour tenter de convertir deux anciens téléphones à cadrans rotatifs en interphones sans-fil. Tandis que la modification des minitels suit son cours (je viens tout juste de souder le connecteur du clavier du Minitel), la conversion des vieux téléphones en interphones sans-fil se révèle plus problématique que prévu. Petit point rapide dans ce billet des soucis rencontrés, des solutions testées, et de l'avenir de ce projet.
Revenons deux minutes à l'origine de ce projet. On trainait en famille dans un vide-grenier (oui, à l'époque où c'était encore possible) et je suis tombé sur un de ces vieux téléphones à cadran rotatif, ce même type de téléphone que j'utilisais tout petit pour appeler mes grands-parents. Il faut avouer que composer le numéro à 8 chiffres -- dans cet ancien temps la numérotation n'était pas encore à 10 chiffres -- était vraiment amusant: on plaçait le doigt dans le numéro souhaité, puis on faisait tourner le cadran jusqu'en butée, et ce dernier revenait en position initiale en faisant un petit bruit de crécelle. Tout nostalgique que j'étais, j'en ai acheté deux exemplaires pour moins de 10€, avec en tête l'idée de les réhabiliter à la maison.
Dans un premier temps, on souhaitait s'en servir comme second téléphone fixe, mais il s'est avéré que la méthode de génération du numéro composé n'est plus supportée par les réseaux téléphoniques d'aujourd'hui. Le système de numérotation par impulsion de l'ancien temps ne peut donc fonctionner, et il est donc impossible de passer des appels avec ce type de téléphone. Du coup, pourquoi ne pas les transformer en interphones sans-fil ? Tant qu'à faire, autant intégrer de la modernitude dans ces vieilleries ! Et c'est d'un pratique pour appeler les enfants qui jouent dans la mezzanine pour leur demander de mettre le couvert, pardi 😇.
Tout excité à l'idée de réaliser ce projet (on était en 2020 à ce moment là), je teste dans un premier temps si les micros et les hauts-parleurs des téléphones fonctionnent, ce qui est le cas. Puis je connecte un micro à une entrée analogique d'un arduino Nano, et je code un petit programme qui échantillonne le signal en provenance du micro (amplifié avec un module lm386, histoire d'avoir un niveau de signal suffisant) et le retransmet sur le haut-parleur, lui aussi couplé à un module d'amplification similaire. Et miracle, ça fonctionne ! Bon d'accord, le son est pourri, mais ça fonctionne !
La voix humaine varie entre 40 et 1500 Hertz (d'après Musimem), et l'arduino Nano que j'utilisais, cadencé à 16 MHz, ne peut pas échantillonner plus vite que 615 384 échantillons à la seconde, ou plus simplement 615 kHz. C'est plutôt pas mal, mais la résolution sonore est limitée car le convertisseur analogique/numérique (ou ADC) ne produit des valeurs que sur 8 bits au vu de la vitesse d'échantillonnage requise. Ceci dit, le résultat n'était pas trop mal !
Le souci avec un système de communication bi-directionnelle comme un interphone, c'est qu'il faut gérer en même temps la conversion du signal audio en provenance du micro en échantillons numériques, l'envoi de ces échantillons, mais aussi la conversion des échantillons numériques reçus en signal analogique à destination du haut-parleur. Ca veut donc dire faire plein d'autres choses que de l'échantillonnage de la voix, ce qui réduit la vitesse d'échantillonnage effective.
Avec ce premier test réussi, j'ai tenté l'implémentation d'un projet existant (Long Range Arduino Based Walkie Talkie using nRF24L01 [EN]) visant à transmettre de la voix sur du 2.4 GHz, mais sans succès. Comme je m'y attendais, l'arduino voit sa vitesse d'échantillonnage réduite et la piètre résolution du convertisseur analogique/numérique n'arrange pas la qualité sonore. En cherchant un peu plus, je me rends alors compte que je ne suis pas le seul qui s'est cassé la tête sur ce type d'usage, comme le démontre le retour d'expérience de GreatScott!! sur Hacakday [EN].
Il va falloir tester autre chose.
Vu que pas mal de mes connaissances m'ont parlé en bien des systèmes produits par Espressif et notamment la plateforme ESP32, je me suis demandé s'il était possible que ces derniers fassent l'affaire. J'ai pu expérimenter le développement sur ESP32 avec mon projet de smartwatch programmable (la vénérable T-Watch 2020 v1 de Lilygo), et je dois avouer que ça m'a bien bluffé. Je décidais donc de donner sa chance à l'ESP32, et commandais un ESP32 NodeMCU sur Amazon pour prototyper tout ça.
C'est à ce moment là (donc début 2021, si vous suivez) que j'ai commencé à prototyper sur ESP32 lors de lives sur Twitch, et les premiers résultats ont été assez satisfaisants. J'ai réussi à échantillonner le son du micro et à l'envoyer sur le haut-parleur, mais la qualité était juste horrible. Ceci dit, c'était encore acceptable. C'est quand j'ai commencé à interfacer l'ESP32 à un service accessible en WiFi que les choses se sont gâtées. L'envoi du son sur le service distant fonctionnait, mais d'une part la qualité n'était pas merveilleuse du tout, mais de la donnée était perdue et il y avait un décalage énorme (entre 5 à 10 secondes) entre l'échantillonnage par l'ESP32 et la transmission via WiFi.
Alors oui, l'ESP32 ça fonctionne bien, mais il a beaucoup de mal à réaliser en même temps la conversion du signal audio en échantillons numériques et la transmission de ces derniers. Et encore, c'était sans intégrer la convesion numérique/analogique pour la restitution du son sur le haut-parleur. Bref, ça devenait mal engagé. Certes l'ESP32 NodeMCU ne coûte pas bien cher, mais il souffre de plusieurs défauts.
Le premier défaut concerne la conversion numérique/analogique (DAC): la résolution du DAC interne de l'ESP32 est de 8 bits, on ne peut donc coder que des valeurs de 0 à 256, qui constitueront autant de "paliers" dans la tension de sortie et donc une imprécision dans le signal audio restitué. Surtout que la conversion analogique/numérique (ADC) ne souffre pas de cette limitation, la résolution étant de 12 bits. La réduction de 12 bits à 8 bits altère le son de manière significative, et impacte de fait la qualité de la communication. Le second défaut concerne l'électronique du NodeMCU: l'entrée analogique est parasitée par une alimentation du circuit un peu mal fichue, et par l'absence de quelques composants permettant de filtrer l'audio entrant. C'est aussi ce qui ressort des tests qu'a effectué atomic14 dans sa vidéo youtube [EN]: le son est parasité, la qualité sonore très dégradée, et sans prendre en compte la transmission via le réseau !
Encore un fail, mais bon ça m'aura permis de bien prendre en main le dev sur ESP32.
Une des solutions possibles consiste à externaliser la conversion numérique/analogique et analogique/numérique, idéalement en employant des composants permettant d'échantillonner avec une bonne résolution (12 bits dans les deux cas), et fournissant un débit suffisant pour avoir une bonne qualité audio. On pourrait aussi envisager l'emploi d'un microphone I2S (qui fournit directement des échantillons numériques), mais je n'ai pas envie de perdre le grain du microphone du téléphone original.
La solution idéale pour le prototypage consiste à utiliser une carte adaptée, en l'occurence une esp32-lyrat-mini, compatible avec le framework esp-adf d'Espressif. Ce framework est dédié au traitement audio, et cette carte compatible intègre tout ce qu'il faut pour faire la conversion analogique/numérique et numérique/analogique via des composants externes. Elle intègre aussi des filtres adaptés, histoire d'avoir une meilleure qualité sonore. En bref, c'est vraiment une board faite pour cet usage. Comme un crétin, je ne pensais pas devoir en arriver là pour réaliser ce projet, mais je pense que je ne vais pas avoir d'autre choix. J'ai passé commande, on verra dans quelques semaines ce que ça donne 😀.
