J'ai acheté récemment un clavier MIDI SMK-25 Mini pour un peu plus de 50 euros sur AliExpress...
Ce qui est étonnant, c'est le peu d'information et de documentation disponible sur ce produit. En fait, il semble répondre aux standards USB-Audio MIDI et Bluetooth-LE Audio MIDI.
Sur Linux, on peut l'utiliser avec qjackctl(1) et qsynth(1).
L'identifiant USB 4353:4b4d correspond aux informations suivantes :
* Fabricant (Vendor ID 4353) : Jieli Technology.
* Produit (Product ID 4b4d) : SINCO.
De manière plus détaillée,
Ce qui donne dans QjackCtl 0.9.6 sur une Linux Mint plus ou moins récente,
En Bluetooth, cela ne semble pas fonctionner sur mon Linux Mint... Probablement parce que Bluez n'a pas été configuré avec MIDI (./configure --enable-midi ... mais je ne sais pas quelle version choisir et il exige une glibc plus récente...), ce qui est étrange parce que MIDI sur Bluetooth date de plusieurs années (2017?). Sur Debian Trixie, MIDI-BLE semble fonctionner mais pour une autre raison, qsynth(1) ne sort aucun son (alors que j'ai du son avec Firefox...). J'ignore comment configurer la sortie de qsynth(1)... Peut-être que je l'avais fait sur la Mint avec fluidsynth(1) que je ne retrouve pas sur Trixie... Tout cela est bien compliqué...
lundi 22 décembre 2025
samedi 2 août 2025
Smart Indoor IP Camera de chez Action...
En juillet 2025, il y a eu une promotion pour des caméras IP chez Action en Belgique. Le modèle le plus simple, avec une résolution HD (1920x1080) était à 6.95 euros... C'est étonnant ce que l'on peut avoir pour ce prix-là... Outre le capteur sc2331, elle fonctionne grâce à un SoC Ingenic T23 (core Xburst-1 (Mips 32 bits), (+core SYS V?), 64 MB de RAM et un tas de fonctionnalités dont le BlueTooth (pour la configuration) et le WiFi (pour le fonctionnement ordinaire) et une mémoire FLASH XMC 25QH64.... de 8 MB. Et un slot pour enregistrer les images sur carte µSD.
Elle fonctionne avec l'application pour smartphone smart life, ce qui est étonnamment pratique (on communique les informations sur le WiFi (ESSID+mot-de-passe) et ensuite, on peut voir ce que voit la caméra (connectée au WiFi) partout là où l'on a accès à Internet avec son smartphone... Ce qui n'est bien sûr possible que parce que la caméra maintient un lien avec le 'cloud' de smart connect. On a, en quelque sorte, invité un cheval de Troie sur son réseau. Et, comme le bidule est équipé d'un processeur 32 bits à 1 GHz avec 64 MB de RAM (qui se met à jour automatiquement par le réseau), ce n'est pas anodin.
Le bidule ne semble pas encore 'rootable', ni sur OpenIPC.org, ni sur thingino.com. Ce n'est probablement qu'une question de temps...
lsusb(8) ne détecte rien, l'USB-C ne semble servir qu'à l'alimentation (pas de connexion et/ou pas de logiciel?). On pourrait imaginer que le bidule est bootable via la carte µSD (mais cela reste à prouver). Le WiFi en mode infrastructure nécessite une configuration, elle se fait via Bluetooth et l'application pour smartphone 'smart life'. Une fois configuré et que la caméra a contacté le cloud TUYA, nrf connect semble indiquer que le Bluetooth n'est plus actif. Quant au WiFi, nmap(1) indique que seul le port 6668 (IRC) est ouvert...
En face avant, on trouve 3 pastilles labellées 'Rx', 'Tx' et 'Gnd' et, de fait, il y a quelque chose qui sort sur le 'Tx', d'abord observé avec pulseview(1) et un clone Saleae et ensuite avec minicom(1) (115200 8N1)
Et c'est là que l'on voit que le T23 commence par exécuter U-Boot puis, si on ne l'interrompt pas, Linux et tout le logiciel nécessaire au bon fonctionnement de la caméra. On voit même un 'login:' apparaître mais sans connaître le nom d'utilisateur et le mot de passe, ce n'est pas d'une grande utilité. Si on interrompt U-Boot (il faut être rapide; mettre sous tension en maintenant une touche enfoncée), on se retrouve avec un moniteur dans lequel on peut lancer des commandes (par exemple, 'help'). On peut inspecter la mémoire, la modifier, charger des données à partir de la FLASH et ...uploader du code à un endroit donné, par exemple, avec la commande 'loady <adresse>'; sur minicom, on fera, '<ctrl>-A S' (send), on sélectionnera [ymodem] puis le fichier à envoyer.
Sur Ubuntu,
0x80600000, c'est là où U-Boot dit qu'il met Linux. Les I/O sont 'mappés' en mémoire et les sources de U-Boot adaptées au T23 sont sur github : ingenic-u-boot-xburst1. On troue les adresse dans arch/mips/include/asm/arch-t23/base.h, la structure dans arch/mips/include/asm/jz_uart.h et le code (polling, pas d'interruption) dans arch/mips/cpu/xburst/jz_serial.c. En quick&dirty, cela donne :
Tout ceci ne sert bien sûr à rien. C'est juste un exercice amusant (et on peut vérifier qu'il y a bien 64 MB de RAM). Tout cela pour 6.95€ (maintenant, elle est à 9.95€). La suite, c'est probablement d'utiliser flashrom(8) avec un CH341A, lire le contenu de la FLASH, analyser son contenu avec binwalk(1) et voir comment aller plus loin...
Dans le moniteur de U-Boot, les commandes 'printenv' et 'setenv' laissent entrevoir la possibilité de modifier les paramètres du boot Linux et, par exemple, remplacer le 'init=linuxrc' par 'init=/bin/bash' pour contourner le 'login:'? Pour je ne sais pour quelle raison, cela ne semble pas avoir fonctionné... À ré-essayer?
Elle fonctionne avec l'application pour smartphone smart life, ce qui est étonnamment pratique (on communique les informations sur le WiFi (ESSID+mot-de-passe) et ensuite, on peut voir ce que voit la caméra (connectée au WiFi) partout là où l'on a accès à Internet avec son smartphone... Ce qui n'est bien sûr possible que parce que la caméra maintient un lien avec le 'cloud' de smart connect. On a, en quelque sorte, invité un cheval de Troie sur son réseau. Et, comme le bidule est équipé d'un processeur 32 bits à 1 GHz avec 64 MB de RAM (qui se met à jour automatiquement par le réseau), ce n'est pas anodin.
Le bidule ne semble pas encore 'rootable', ni sur OpenIPC.org, ni sur thingino.com. Ce n'est probablement qu'une question de temps...
lsusb(8) ne détecte rien, l'USB-C ne semble servir qu'à l'alimentation (pas de connexion et/ou pas de logiciel?). On pourrait imaginer que le bidule est bootable via la carte µSD (mais cela reste à prouver). Le WiFi en mode infrastructure nécessite une configuration, elle se fait via Bluetooth et l'application pour smartphone 'smart life'. Une fois configuré et que la caméra a contacté le cloud TUYA, nrf connect semble indiquer que le Bluetooth n'est plus actif. Quant au WiFi, nmap(1) indique que seul le port 6668 (IRC) est ouvert...
En face avant, on trouve 3 pastilles labellées 'Rx', 'Tx' et 'Gnd' et, de fait, il y a quelque chose qui sort sur le 'Tx', d'abord observé avec pulseview(1) et un clone Saleae et ensuite avec minicom(1) (115200 8N1)
$ minicom -b 115200 -8 --capturefile=$(date +"%Y%m%d.%H%M%S").txt -D /dev/ttyUSB0
Et c'est là que l'on voit que le T23 commence par exécuter U-Boot puis, si on ne l'interrompt pas, Linux et tout le logiciel nécessaire au bon fonctionnement de la caméra. On voit même un 'login:' apparaître mais sans connaître le nom d'utilisateur et le mot de passe, ce n'est pas d'une grande utilité. Si on interrompt U-Boot (il faut être rapide; mettre sous tension en maintenant une touche enfoncée), on se retrouve avec un moniteur dans lequel on peut lancer des commandes (par exemple, 'help'). On peut inspecter la mémoire, la modifier, charger des données à partir de la FLASH et ...uploader du code à un endroit donné, par exemple, avec la commande 'loady <adresse>'; sur minicom, on fera, '<ctrl>-A S' (send), on sélectionnera [ymodem] puis le fichier à envoyer.
Sur Ubuntu,
$ sudo apt-get install gcc-7-mips-linux-gnu
$ mips-linux-gnu-gcc-7 -EL -nostartfiles -nodefaultlibs -T ld_spec.txt -static -o hello_world hello_world.c
$ mips-linux-gnu-objcopy -S -O binary hello_world hello_world.bin
$ nm hello_world |grep main
$ # avec
$ $ cat ld_spec.txt
SECTIONS
{
. = 0x80600000;
.text : { *(.text) }
.data : { *(.data) }
.bss : { *(.bss) }
}
0x80600000, c'est là où U-Boot dit qu'il met Linux. Les I/O sont 'mappés' en mémoire et les sources de U-Boot adaptées au T23 sont sur github : ingenic-u-boot-xburst1. On troue les adresse dans arch/mips/include/asm/arch-t23/base.h, la structure dans arch/mips/include/asm/jz_uart.h et le code (polling, pas d'interruption) dans arch/mips/cpu/xburst/jz_serial.c. En quick&dirty, cela donne :
#define SERIAL_DATA ((char*)0xb0031000) /* receive/transmit reg */
#define SERIAL_LSR ((char*)0xb0031014) /* line status reg */
void my_putc(char c)
{
if (c == '\r')
my_putc('\n');
*SERIAL_DATA = c;
while ((*SERIAL_LSR & 0x60) != 0x60) /* xmit fifo not empty */
;
}
char my_getc()
{
while (!(*SERIAL_LSR & 0x01)) /* no data ready */
;
return(*SERIAL_DATA);
}
Et on peut donc ainsi, imprimer 'Hello world!' avec un programme compilé localement.
Tout ceci ne sert bien sûr à rien. C'est juste un exercice amusant (et on peut vérifier qu'il y a bien 64 MB de RAM). Tout cela pour 6.95€ (maintenant, elle est à 9.95€). La suite, c'est probablement d'utiliser flashrom(8) avec un CH341A, lire le contenu de la FLASH, analyser son contenu avec binwalk(1) et voir comment aller plus loin...
Dans le moniteur de U-Boot, les commandes 'printenv' et 'setenv' laissent entrevoir la possibilité de modifier les paramètres du boot Linux et, par exemple, remplacer le 'init=linuxrc' par 'init=/bin/bash' pour contourner le 'login:'? Pour je ne sais pour quelle raison, cela ne semble pas avoir fonctionné... À ré-essayer?
mercredi 28 mai 2025
Chauves-souris
Je possède depuis un certain temps un Batseeker qui rend audibles le cris des chauves-souris. J'ignore de quelle version il s'agit. En principe, les ultrasons sont captés par un microphone 'mems' et la fréquence en serait divisée par 10. Le résultat, c'est qu'on entend une espèce de chr-chr-chr-chr... rapide quand une chauve-souris passe à proximité. En les entendant, c'est plus facile de les repérer.
Récemment, à je ne sais plus quelle occasion, j'ai vu qi'il y avait moyen d'acquérir un enregistreur AudioMoth pas trop cher. Du genre 100€ mais en ajoutant divers frais (taxes et port), comptez 140e, sans compter les piles et la carte SD. Cela reste accessible. Le bidule est configurable et autonome. On peut aussi l'utiliser 'à la demande' (une fois le taux d'échantillonnage sélectionné). Pour les pipistrelles, 192 kilo-échantillons par seconde permet d'enregistrer jusqu'à 96 kHz, ce qui est bien suffisant. À 16 bits par échantillon, on est à quelque chose du genre 20 MB par minutes mais les PC modernes traitent cela sans problème et les cartes SD permettent de stocker des dizaines de giga-octets. En mode autonome, avec des pages horaires programmées, il y a deux contraintes : l'énergie fournie par les piles et la capacité mémoire de la carte SD. Dans les deux cas, cela se compte en jours. L'enregistrement en continu se compose de fichiers .WAV de tailles raisonnables (qu'il faut extraire avec un lecteur de carte). Audacity permet d'inspecter les enregistrements. Ci-dessus, on peut voir les cris d'écholocalisation (avec un maximum vers 48 kHz) et un 'buzz' de capture typique des pipistrelles.
Batseeker suggère d'agiter un trousseau de clés pour tester le détecteur. Celles-ci génèreraient des ultrasons que le détecteur rendrait audibles. Et, en effet, si on enregistre l'agitation des clés avec l'AudioMoth à 192 kilo-échantillons par seconde, on trouve beaucoup de signal au dessus de 20 kHz. L'audiogramme ci-dessous montre l'enregistrement sans batseeker à guche et avec batseeker à droite. On observe clairement l'apparition d'un signal basse fréquence. Pour voir si il y a réellement division des fréquence par 10, il faudrait un signal d'entrée plus pur. Par exemple, le sinus d'un générateur de fréquences dans un haut-parleur allant des les ultrasons. Il faudrait que je retrouve mes pièces de modules HC-SR04... Un aute truc amusant, c'est d'avoir enregistré le 'chime' de l'application de configuration. Le smartphone jour une petite musique qui permet de démarrer un enregistrement 'custom' avec des coordonnées GPS (mais sans pouvoir spécifier d'autres paramètres comme le taux d'échantillonnage ou ou le gain). Quand on observe l'audiogramme, on s'aperçoit que la petite musique est décorative et que le signal utile se situe à 18 kHz.
Je n'ai pas encore trouvé d'insectes (grillons, sauterelles) à enregistrer (ni de batraciens ou autres animaux). Cela fonctionne pour les oiseaux mais l'application BirdNet pour smartphone est beaucoup plus pratique et elle est associée à un logiciel qui permet de déterminer l'espèce à partir de son chant.
Finalement si. Probablement un 'criquet' stridulant autour de 23 kHz (?).
Récemment, à je ne sais plus quelle occasion, j'ai vu qi'il y avait moyen d'acquérir un enregistreur AudioMoth pas trop cher. Du genre 100€ mais en ajoutant divers frais (taxes et port), comptez 140e, sans compter les piles et la carte SD. Cela reste accessible. Le bidule est configurable et autonome. On peut aussi l'utiliser 'à la demande' (une fois le taux d'échantillonnage sélectionné). Pour les pipistrelles, 192 kilo-échantillons par seconde permet d'enregistrer jusqu'à 96 kHz, ce qui est bien suffisant. À 16 bits par échantillon, on est à quelque chose du genre 20 MB par minutes mais les PC modernes traitent cela sans problème et les cartes SD permettent de stocker des dizaines de giga-octets. En mode autonome, avec des pages horaires programmées, il y a deux contraintes : l'énergie fournie par les piles et la capacité mémoire de la carte SD. Dans les deux cas, cela se compte en jours. L'enregistrement en continu se compose de fichiers .WAV de tailles raisonnables (qu'il faut extraire avec un lecteur de carte). Audacity permet d'inspecter les enregistrements. Ci-dessus, on peut voir les cris d'écholocalisation (avec un maximum vers 48 kHz) et un 'buzz' de capture typique des pipistrelles.
Batseeker suggère d'agiter un trousseau de clés pour tester le détecteur. Celles-ci génèreraient des ultrasons que le détecteur rendrait audibles. Et, en effet, si on enregistre l'agitation des clés avec l'AudioMoth à 192 kilo-échantillons par seconde, on trouve beaucoup de signal au dessus de 20 kHz. L'audiogramme ci-dessous montre l'enregistrement sans batseeker à guche et avec batseeker à droite. On observe clairement l'apparition d'un signal basse fréquence. Pour voir si il y a réellement division des fréquence par 10, il faudrait un signal d'entrée plus pur. Par exemple, le sinus d'un générateur de fréquences dans un haut-parleur allant des les ultrasons. Il faudrait que je retrouve mes pièces de modules HC-SR04... Un aute truc amusant, c'est d'avoir enregistré le 'chime' de l'application de configuration. Le smartphone jour une petite musique qui permet de démarrer un enregistrement 'custom' avec des coordonnées GPS (mais sans pouvoir spécifier d'autres paramètres comme le taux d'échantillonnage ou ou le gain). Quand on observe l'audiogramme, on s'aperçoit que la petite musique est décorative et que le signal utile se situe à 18 kHz.
Je n'ai pas encore trouvé d'insectes (grillons, sauterelles) à enregistrer (ni de batraciens ou autres animaux). Cela fonctionne pour les oiseaux mais l'application BirdNet pour smartphone est beaucoup plus pratique et elle est associée à un logiciel qui permet de déterminer l'espèce à partir de son chant.
Finalement si. Probablement un 'criquet' stridulant autour de 23 kHz (?).
dimanche 23 février 2025
Cassette de brodeuse Toyota ESP-510
(xofc sur Wikipédia)
La brodeuse Toyota Expert SP-510 (1986) peut lire des motifs à broder à partir de cassettes audio. L'encodage semble être identique à celui utilisé dans les Datassettes de Commodore. Une cassette peut contenir plusieurs designs et chaque design est constitué de plusieurs sections.
Une cassette de démonstration comprenant 8 motifs (1/letter A; 2/Dancing; 3/ Bouquet; 4/ Pigeon; 5/ Butterfly; 6/ Pisces; 7/ Rosetted ribbon; 8/ Star) a été lue avec un lecteur de cassette USB (Super USB Cassette Capture / Cassette Converter vendu chez Aldi (?)) que Linux voit comme un micro USB (alsamixer(1) et gnome-sound-recorder(1)) et convertie en fichier .mp3. La compression du fichier ne semble pas poser problème (sinon, on pourrait le sauver en .flac). On peut alors analyser le contenu de l'enregistrement avec audacity(1), par exemple.
Via Audacity.Tools->Frequency_analysis, sur un bout d'enregistrement, on peut deviner qu'il s'agit d'un encodage AFSK avec du signal à 1000 et 2000 Hz.
L'ensemble de la bande montre les huit motifs séparés par des silences de 30 secondes.
Un motif particulier étant composé de plusieurs sections. Par exemple, le cinquième motif, qui est un papillon (Butterfly) assez complexe, est composé de nombreuses sections séparées par des silences de 2.5 secondes.
En zoomant encore sur une section, on voit apparaître le signal. Ici, au moment ou une succession de cycles à 1000 Hertz utile à la synchronisation fait place aux données proprement dites.
En zoomant davantage, on voit apparaître l'échantillonnage à 44100 Hertz (standard des CD audio) des signaux à 1000 et 2000 Hertz.
Certaines sections affichent des signaux différents qui ne semble contenir aucune information particulière, c'est juste du remplissage.
Il faut noter que Audacity affiche des valeurs entre +1 et -1 mais quand on transforme le fichier .mp3 en .wav (16 bits signés à 44100 échantillons par seconde) pour pouvoir l'analyser numériquement facilement, on obtient des valeurs entre 32767 et -32768. Avec le module audio de Octave(1), on peut également lire les fichiers audio (en .flac, .wav et .ogg mais pas .mp3).
mpg123(1) permet de convertir les différents formats. Typiquement, pour lire des données .wav (sans header) en entrée standard de 'mon_programme', on va faire :
Après, il ne restera plus qu'à essayer de deviner ce que contiennent ces sections... Ce n'est pas gagné parce que, curieusement, il existe une masse de formats de fichier propriétaires pour brodeuses alors qu'on aurait pu penser qu'il aurait existé une espèce de G-Code universel ne contenant que des dx et dy entre les piqures. Pour se faire une idée de la matière, on peut analyser comment Ink/Stich, un module pour Inkscape(1), approche le sujet.
La brodeuse Toyota Expert SP-510 (1986) peut lire des motifs à broder à partir de cassettes audio. L'encodage semble être identique à celui utilisé dans les Datassettes de Commodore. Une cassette peut contenir plusieurs designs et chaque design est constitué de plusieurs sections.
Une cassette de démonstration comprenant 8 motifs (1/letter A; 2/Dancing; 3/ Bouquet; 4/ Pigeon; 5/ Butterfly; 6/ Pisces; 7/ Rosetted ribbon; 8/ Star) a été lue avec un lecteur de cassette USB (Super USB Cassette Capture / Cassette Converter vendu chez Aldi (?)) que Linux voit comme un micro USB (alsamixer(1) et gnome-sound-recorder(1)) et convertie en fichier .mp3. La compression du fichier ne semble pas poser problème (sinon, on pourrait le sauver en .flac). On peut alors analyser le contenu de l'enregistrement avec audacity(1), par exemple.
Via Audacity.Tools->Frequency_analysis, sur un bout d'enregistrement, on peut deviner qu'il s'agit d'un encodage AFSK avec du signal à 1000 et 2000 Hz.
L'ensemble de la bande montre les huit motifs séparés par des silences de 30 secondes.
Un motif particulier étant composé de plusieurs sections. Par exemple, le cinquième motif, qui est un papillon (Butterfly) assez complexe, est composé de nombreuses sections séparées par des silences de 2.5 secondes.
En zoomant encore sur une section, on voit apparaître le signal. Ici, au moment ou une succession de cycles à 1000 Hertz utile à la synchronisation fait place aux données proprement dites.
En zoomant davantage, on voit apparaître l'échantillonnage à 44100 Hertz (standard des CD audio) des signaux à 1000 et 2000 Hertz.
Certaines sections affichent des signaux différents qui ne semble contenir aucune information particulière, c'est juste du remplissage.
Il faut noter que Audacity affiche des valeurs entre +1 et -1 mais quand on transforme le fichier .mp3 en .wav (16 bits signés à 44100 échantillons par seconde) pour pouvoir l'analyser numériquement facilement, on obtient des valeurs entre 32767 et -32768. Avec le module audio de Octave(1), on peut également lire les fichiers audio (en .flac, .wav et .ogg mais pas .mp3).
octave> [y,fs]=audioread('file.ogg');
octave> x = [0:length(y)-1];
octave> plot(x,y)
# or
octave> fd = fopen('file.wav', 'rb');
octave> y = fread(fd, 'int16'); # ?!should skip the header...
octave> x = [0:length(y)-1];
octave> plot(x,y)
mpg123(1) permet de convertir les différents formats. Typiquement, pour lire des données .wav (sans header) en entrée standard de 'mon_programme', on va faire :
linux$ mpg123 -s -0 mp3/butterfly.mp3 | ./mon_programme
Après, il ne restera plus qu'à essayer de deviner ce que contiennent ces sections... Ce n'est pas gagné parce que, curieusement, il existe une masse de formats de fichier propriétaires pour brodeuses alors qu'on aurait pu penser qu'il aurait existé une espèce de G-Code universel ne contenant que des dx et dy entre les piqures. Pour se faire une idée de la matière, on peut analyser comment Ink/Stich, un module pour Inkscape(1), approche le sujet.
mercredi 15 janvier 2025
Linux et la balance de cuisine SilverGear
La semaine dernière, la semaine d'Action (en Belgique) faisait la promotion d'une balance de cuisine Silvergear 'connectée' à 5.99 euros... Impossible de résister. L'occasion de jouer un peu avec Bluetooth. L'application conseillée est 'Silvergear fit'. Après avoir choisi le type de nourriture, elle calcule l'apport en calories, matières grasses, protéines, glucides,... de la pesée. L'application est plutôt mal cotée. J'ignore si c'est justifié ou non, je n'ai pas vraiment l'intention de l'utiliser.
Pour jouer avec en Bluetooth, le premier problème est d'obtenir son adresse MAC. J'avais déjà eu des problèmes avec le pèse-personne SilverGear à 10 euros la semaine précédente. Je dois être entouré de voisins fans de bidules connectés et c'est difficile de retrouver mon bidule dans toutes ces adresses. Le pèse-personne s'annonçait comme 'TY' (pour tuya) et il y en avait déjà 3 dans l'environnement... Dans un environnement moins fréquenté, j'ai découvert que mon pèse-personne avait une adresse DC:23:50:XX:XX:XX. La balance de cuisine s'annonce comme '4454' (cela apparaît également avec l'application du smartphone lors du 'pairing'). Ce n'est pas très explicite mais l'information figure sur l'étiquette à l'arrière. Son adresse MAC est BC:A5:46:XX:XX:XX.
Une fois son adresse MAC connue, on peut utiliser gatttool(1) pour aller plus loin et découvrir ce que le bidule propose. Un truc à essayer, par exemple, c'est '--primary':
L'intérêt d'avoir accès aux mesures indépendamment de l'application, c'est que l'on peut maintenant faire ce que l'on veut. Je peux compter des boulons, multiplier le poids par le prix des bananes,...
Il faudrait aussi faire des expériences pour savoir dans quelle mesure le résultat est reproductible, correct, linéaire,... À quel point. Et, par exemple, si 3 grammes à partir de X grammes est plus précis qu'à partir de 0,...
Pour jouer avec en Bluetooth, le premier problème est d'obtenir son adresse MAC. J'avais déjà eu des problèmes avec le pèse-personne SilverGear à 10 euros la semaine précédente. Je dois être entouré de voisins fans de bidules connectés et c'est difficile de retrouver mon bidule dans toutes ces adresses. Le pèse-personne s'annonçait comme 'TY' (pour tuya) et il y en avait déjà 3 dans l'environnement... Dans un environnement moins fréquenté, j'ai découvert que mon pèse-personne avait une adresse DC:23:50:XX:XX:XX. La balance de cuisine s'annonce comme '4454' (cela apparaît également avec l'application du smartphone lors du 'pairing'). Ce n'est pas très explicite mais l'information figure sur l'étiquette à l'arrière. Son adresse MAC est BC:A5:46:XX:XX:XX.
linux$ bluetoothctl scan le # could have been 'sudo hcitool lescan ? ... [bluetooth]# scan on ... [NEW] Device BC:A5:46:XX:XX:XX 4454 ... ^D
Une fois son adresse MAC connue, on peut utiliser gatttool(1) pour aller plus loin et découvrir ce que le bidule propose. Un truc à essayer, par exemple, c'est '--primary':
linux$ gatttool -t public -b BC:A5:46:XX:XX:XX --primary # Cuisine attr handle = 0x0001, end grp handle = 0x000f uuid: 0000180a-0000-1000-8000-00805f9b34fb attr handle = 0x0010, end grp handle = 0xffff uuid: 0000ffb0-0000-1000-8000-00805f9b34fbVoilà qui est bien mais ne nous avance pas beaucoup. Si le '180a' se trouve bien dans les Bluetooth Assigned Numbers (Device Information Service), 'ffb0' n'y est pas... Essayons de nous connecter en mode interactif pour pouvoir l'interroger...
linux$ gatttool -t public -b BC:A5:46:17:F5:07 --interactive # Cuisine [BC:A5:46:XX:XX:XX7][LE]> connect Attempting to connect to BC:A5:46:XX:XX:XX Connection successful Notification handle = 0x0014 value: ac 40 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a6 a7 Notification handle = 0x0014 value: ac 40 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a6 a7 ... Notification handle = 0x0014 value: ac 40 00 00 01 0d 4c 00 00 00 00 00 00 00 00 00 00 00 a6 00 [BC:A5:46:XX:XX:XX][LE]> ^CEt là, bonne surprise! La balance envoie des 'notifications' dont la valeur change lorsque l'on dépose un poids dessus, sans aucune autre intervention que la connexion. Là, ce n'est pas encore trop pratique mais c'est encourageant. Le plus simple, maintenant, cela doit être d'écrire un petit script Python utilisant le module pygatt pour interagir avec le Bluetooth LE Generic Attribute Profile (GATT). Et, justement, dans la doc, il y a un exemple de captation des notifications. Le problème, c'est qu'il faut associer le 'callback' à un UUID et que nous n'avons que le 'handle' 0x0014... C'est là que la commande '--char-desc' de gatttool intervient. On trouve l'UUID correspondant au handle 0x0014, '0000ffb2-0000-1000-8000-00805f9b34fb' que l'on peut utiliser dans le script.
linux$ gatttool -t public -b BC:A5:46:XX:XX:XX --char-desc # Cuisine handle = 0x0001, uuid = 00002800-0000-1000-8000-00805f9b34fb handle = 0x0002, uuid = 00002803-0000-1000-8000-00805f9b34fb handle = 0x0003, uuid = 00002a23-0000-1000-8000-00805f9b34fb handle = 0x0004, uuid = 00002803-0000-1000-8000-00805f9b34fb handle = 0x0005, uuid = 00002a24-0000-1000-8000-00805f9b34fb handle = 0x0006, uuid = 00002803-0000-1000-8000-00805f9b34fb handle = 0x0007, uuid = 00002a25-0000-1000-8000-00805f9b34fb handle = 0x0008, uuid = 00002803-0000-1000-8000-00805f9b34fb handle = 0x0009, uuid = 00002a26-0000-1000-8000-00805f9b34fb handle = 0x000a, uuid = 00002803-0000-1000-8000-00805f9b34fb handle = 0x000b, uuid = 00002a27-0000-1000-8000-00805f9b34fb handle = 0x000c, uuid = 00002803-0000-1000-8000-00805f9b34fb handle = 0x000d, uuid = 00002a28-0000-1000-8000-00805f9b34fb handle = 0x000e, uuid = 00002803-0000-1000-8000-00805f9b34fb handle = 0x000f, uuid = 00002a29-0000-1000-8000-00805f9b34fb handle = 0x0010, uuid = 00002800-0000-1000-8000-00805f9b34fb handle = 0x0011, uuid = 00002803-0000-1000-8000-00805f9b34fb handle = 0x0012, uuid = 0000ffb1-0000-1000-8000-00805f9b34fb handle = 0x0013, uuid = 00002803-0000-1000-8000-00805f9b34fb handle = 0x0014, uuid = 0000ffb2-0000-1000-8000-00805f9b34fb handle = 0x0015, uuid = 00002902-0000-1000-8000-00805f9b34fbEt donc, le script devient :
#!/usr/bin/python3
import pygatt, time
adapter = pygatt.GATTToolBackend()
old_weight = 0
def handle_data(handle, value):
"""
handle -- integer, characteristic read handle the data was received on
value -- bytearray, the data returned in the notification
"""
global old_weight
weight = ((value[3]*256+value[4])*256+value[5])*256+value[6]
if weight != old_weight :
print(weight, flush=True)
old_weight = weight
try:
adapter.start()
device = adapter.connect('BC:A5:46:XX:XX:XX') # balance cuisine
device.subscribe("0000ffb2-0000-1000-8000-00805f9b34fb",
callback=handle_data)
while True:
time.sleep(10)
finally:
adapter.stop()
Il y a visiblement encore des choses à explorer mais en utilisant les octets de 3 à 6, on obtient un nombre de milligrammes qui correspond à la valeur affichée sur la balance en grammes. La bidouille avec 'old_weight', c'est pour éviter les mesures redondantes plusieurs fois (combien?) par seconde. Pas sûr que cela soit stable au niveau du milligramme. Il faudrait peut-être faire quelque chose de plus sophistiqué...
linux$ ./kichen_notif.py 72110Et la balance affiche '72' grammes.
L'intérêt d'avoir accès aux mesures indépendamment de l'application, c'est que l'on peut maintenant faire ce que l'on veut. Je peux compter des boulons, multiplier le poids par le prix des bananes,...
Il faudrait aussi faire des expériences pour savoir dans quelle mesure le résultat est reproductible, correct, linéaire,... À quel point. Et, par exemple, si 3 grammes à partir de X grammes est plus précis qu'à partir de 0,...
dimanche 10 septembre 2023
Teledistribution
Ayant connu quelques problèmes de réception de chaînes TV sur le câble, je me suis un peu intéressé à ce qui s'y passait...
La première idée a été de regarder le spectre avec un analyseur de spectre TinySA, un étonnant bidule à quelques dizaines d'euros qui affiche des spectres de 0 à quasi 1 GHz. Par défaut, il affiche le spectre de 0 à 350 MHz. On voit quelque chose du côté de 100 MHz, probablement la FM puis les signaux numériques commencent un peu avant 300 MHz. Si l'on zoome du côté de 330 MHz (la fréquence recommandée pour un scan rapide lors de l'installation d'un nouveau téléviseur), on voit bien les bandes de signaux de 8 MHz propres au DVB-C.
Le TinySA permet également d'obtenir les mesures via l'USB. Sur Linux, avec Minicom,
Tout cela c'est très bien. En regardant vers les fréquences plus hautes, on pouvait constater une baisse de la puissance du signal dûe à la qualité du câble coaxial à l'intérieur du bâtiment. Mais cela n'expliquait pas pourquoi le signal était bon à certains moments et insuffisant à d'autres moments. Une fonction de la T24D390EW/EN permet d'afficher les caractéristiques d'un signal (fréquence, qualité du signal,...). Un technicien est venu remplacer quelques connecteurs et a fini par me laisser un amplificateur. Cela a peut-être un peu boosté le signal et je n'ai plus eu d'images avec des blocs mais la veille de sa venue, je n'ai subitement plus eu de programme du tout, sauf sur La Trois, ...seule chaîne non cryptée dans le bouquet standard. Et cela, c'était un autre problème, sûrement un problème de module CAM ou de carte CI... et le technicien m'a invité à aller dans une boutique du téléopérateur. Là, on me donne une 'nouvelle carte' (usagée) et on m'invite à téléphoner au support technique pour l'activer. Là, chipotage, seconde ligne, blabla... Je dois contacter le service technique de Samsung, faire une mise à jour du firmware de la TV,... Je fais la mise à jour avec un mystérieux T-NT14LDEUCM_1013.0.exe trouvé sur le site de Samsung. En fait un .rar autoextractible sur lequel je peux faire un unrar(1) et je passe donc ma TV de la version 1005 à la version 1013 (tout en constantant qu'il y a du Linux à l'intérieur...). Mais rien n'y fait. Comme l'opérateur s'entête à m'encourager à contacter Samsung, je finis par le faire et la personne suspecte qu'ils sont passé de CI+ 1.3 à CI+ 1.4 que ma TV ne peux malheureusement pas traiter... Hum... L'opérateur finit par me re-contacter pour savoir comment s'est passé le changement de signal... C'est la première fois qu'ils me parlent d'un 'changement de signal'. J'avais donc raison de ne pas croire au hasard, ils ont bien changé quelque chose. Curieusement, la solution ne semble pas consister à me remettre en CI+ 1.3 (ou je ne sais quoi d'autre) mais à changer ma formule d'abonnement, d'acquérir un décodeur et de prendre Internet et le téléphone chez eux... Il y en a qui ne manquent pas d'air.
Là-dessus, je me suis demandé comment fonctionnait exactement cette histoire de bouquets cryptés sur DVB-C et j'ai acquis un bidule USB, Hauppauge SoloHD qui permet de capter les chaînes non cryptées et est bien supporté sous Linux (j'ai d'abord tenté un dongle bon marché DVBT2 qui promettait le DVB-C mais la démodulation 64-QAM semble se faire sur le PC à partir des signaux IQ bruts et ce n'est pas supporté par Linux). Hauppauge fournit de la documentation pour installer sous Linux (notamment pour Raspberry Pi). En gros, c'est supporté par défaut, il faut juste télécharger et installer le firmware (deux fichiers à copier dans /lib/firmware/).
Ensuite, il reste à trouver les utilitaires qui vont bien. Par exemple, w_scan(1) (...qui se trouve dans le package w-scan)
Ce qui est étonnant, c'est le nombre de chaînes que l'on parvient à passer en haute définition dans un seul MPEG-TS en 64QAM de 8 MHz. Il semble y avoir 18 chaînes en clair sur le canal de 8 MHz à 314 MHz! (6875 kilo-symboles par seconde avec les 6 bits par symbole du 64QAM, cela fait environ 41 Mbits/seconde).
J'aimerais bien comprendre la structure de tout cela. À 330 MHz, il y a des informations qui renseignent les chaînes disponibles sur différentes fréquences, par exemple. Et j'aimerais bien extraire le guide électronique des programmes (EPG)...
à suivre...
En tout cas, rien de tel qu'une panne de télédistribution pour se rendre compte à quel point la télévision est une drogue dure et prendre la mesure du temps que l'on perd à regarder des programmes sans aucun intérêt.
La première idée a été de regarder le spectre avec un analyseur de spectre TinySA, un étonnant bidule à quelques dizaines d'euros qui affiche des spectres de 0 à quasi 1 GHz. Par défaut, il affiche le spectre de 0 à 350 MHz. On voit quelque chose du côté de 100 MHz, probablement la FM puis les signaux numériques commencent un peu avant 300 MHz. Si l'on zoome du côté de 330 MHz (la fréquence recommandée pour un scan rapide lors de l'installation d'un nouveau téléviseur), on voit bien les bandes de signaux de 8 MHz propres au DVB-C.
Le TinySA permet également d'obtenir les mesures via l'USB. Sur Linux, avec Minicom,
$ minicom -D /dev/ttyACM0 scan 333M 343M 290 3
Tout cela c'est très bien. En regardant vers les fréquences plus hautes, on pouvait constater une baisse de la puissance du signal dûe à la qualité du câble coaxial à l'intérieur du bâtiment. Mais cela n'expliquait pas pourquoi le signal était bon à certains moments et insuffisant à d'autres moments. Une fonction de la T24D390EW/EN permet d'afficher les caractéristiques d'un signal (fréquence, qualité du signal,...). Un technicien est venu remplacer quelques connecteurs et a fini par me laisser un amplificateur. Cela a peut-être un peu boosté le signal et je n'ai plus eu d'images avec des blocs mais la veille de sa venue, je n'ai subitement plus eu de programme du tout, sauf sur La Trois, ...seule chaîne non cryptée dans le bouquet standard. Et cela, c'était un autre problème, sûrement un problème de module CAM ou de carte CI... et le technicien m'a invité à aller dans une boutique du téléopérateur. Là, on me donne une 'nouvelle carte' (usagée) et on m'invite à téléphoner au support technique pour l'activer. Là, chipotage, seconde ligne, blabla... Je dois contacter le service technique de Samsung, faire une mise à jour du firmware de la TV,... Je fais la mise à jour avec un mystérieux T-NT14LDEUCM_1013.0.exe trouvé sur le site de Samsung. En fait un .rar autoextractible sur lequel je peux faire un unrar(1) et je passe donc ma TV de la version 1005 à la version 1013 (tout en constantant qu'il y a du Linux à l'intérieur...). Mais rien n'y fait. Comme l'opérateur s'entête à m'encourager à contacter Samsung, je finis par le faire et la personne suspecte qu'ils sont passé de CI+ 1.3 à CI+ 1.4 que ma TV ne peux malheureusement pas traiter... Hum... L'opérateur finit par me re-contacter pour savoir comment s'est passé le changement de signal... C'est la première fois qu'ils me parlent d'un 'changement de signal'. J'avais donc raison de ne pas croire au hasard, ils ont bien changé quelque chose. Curieusement, la solution ne semble pas consister à me remettre en CI+ 1.3 (ou je ne sais quoi d'autre) mais à changer ma formule d'abonnement, d'acquérir un décodeur et de prendre Internet et le téléphone chez eux... Il y en a qui ne manquent pas d'air.
Là-dessus, je me suis demandé comment fonctionnait exactement cette histoire de bouquets cryptés sur DVB-C et j'ai acquis un bidule USB, Hauppauge SoloHD qui permet de capter les chaînes non cryptées et est bien supporté sous Linux (j'ai d'abord tenté un dongle bon marché DVBT2 qui promettait le DVB-C mais la démodulation 64-QAM semble se faire sur le PC à partir des signaux IQ bruts et ce n'est pas supporté par Linux). Hauppauge fournit de la documentation pour installer sous Linux (notamment pour Raspberry Pi). En gros, c'est supporté par défaut, il faut juste télécharger et installer le firmware (deux fichiers à copier dans /lib/firmware/).
Ensuite, il reste à trouver les utilitaires qui vont bien. Par exemple, w_scan(1) (...qui se trouve dans le package w-scan)
$ sudo apt-get install w-scan ... $ w_scan -fc # pour scanner toutes les fréquences DVB-C
Ce qui est étonnant, c'est le nombre de chaînes que l'on parvient à passer en haute définition dans un seul MPEG-TS en 64QAM de 8 MHz. Il semble y avoir 18 chaînes en clair sur le canal de 8 MHz à 314 MHz! (6875 kilo-symboles par seconde avec les 6 bits par symbole du 64QAM, cela fait environ 41 Mbits/seconde).
J'aimerais bien comprendre la structure de tout cela. À 330 MHz, il y a des informations qui renseignent les chaînes disponibles sur différentes fréquences, par exemple. Et j'aimerais bien extraire le guide électronique des programmes (EPG)...
à suivre...
En tout cas, rien de tel qu'une panne de télédistribution pour se rendre compte à quel point la télévision est une drogue dure et prendre la mesure du temps que l'on perd à regarder des programmes sans aucun intérêt.
samedi 6 mai 2023
Triomphe de la Lune
Le 26 avril 2023, la Nasa publiait une photo de la Lune occupant presque toute la voûte de l'Arc de Tromphe de l'Étoile comme photo du jour.
Une occasion d'utiliser PyEphem pour vérifier tout ça...
C'est simple, amusant et vraisemblablement très précis. On a un observateur positionné dans l'espace et le temps et un astre dont la position dans un repère géographique nous intéresse...
Pour le calcul de l'azimut entre la Porte Maillot et l'Arc, ChatGPT me proposait 'geopy' mais le code qu'il proposait n'était pas correct... Google m'a proposé geographiclib...
On positionne le programme en début de soirée (UTC!), Porte Maillot et on demande à pyephem quand a lieu le lever suivant. On y positionne l'observateur pour obtenir la position de la Lune sur l'horizon à ce moment-là.
Le programme ci-dessous donne les résultats suivants :
Remarquez que la Porte Maillot, à un peu plus d'un kilomètre, c'est un peu juste. La Lune ne fait que 9.3 mètres à l'Arc alors que la voûte en fait 14.6.
Je ne suis ni photographe ni observateur. J'ignore si on peut obtenir quelque chose d'aussi net à cette distance-là. Ni si on peut voir la Lune aussi nette si près de l'horizon en ville. Mais, sinon, c'est tout-à-fait plausible. La Lune, levée depuis quelques minutes, a parcouru quelques degrés pour se trouver dans le bon azimut légèrement au dessus de l'horizon.
Après, on peut refaire l'exercice pour le Cinquantenaire à Bruxelles en faisant une boucle sur 365 jours et en alternant next_rising(moon) et next_setting(moon). Comme le comportement de la Lune est un peu erratique, il vaut peut-être mieux s'exercer avec le Soleil... (sun).
Dans le 'Hacker's Dictionary', vers 1980, pour désigner un programme dont les résultats étaient incertains, on trouvait :
> POM n. Phase of the moon (q.v.).
> Usage: usually used in the phrase "POM dependent"
> which means flakey (q.v.).
( https://www.dourish.com/goodies/jargon.html )
Pour une doc rapide, voir :
Une occasion d'utiliser PyEphem pour vérifier tout ça...
C'est simple, amusant et vraisemblablement très précis. On a un observateur positionné dans l'espace et le temps et un astre dont la position dans un repère géographique nous intéresse...
Pour le calcul de l'azimut entre la Porte Maillot et l'Arc, ChatGPT me proposait 'geopy' mais le code qu'il proposait n'était pas correct... Google m'a proposé geographiclib...
pip install pyephem pip install geographiclib(avec ces modules, le code Python est compact et lisible) Pour les coordonnées GPS des points d'intérêt, j'utilise wikimapia qui a un curseur au centre et affiche sa position dans l'URL.
On positionne le programme en début de soirée (UTC!), Porte Maillot et on demande à pyephem quand a lieu le lever suivant. On y positionne l'observateur pour obtenir la position de la Lune sur l'horizon à ce moment-là.
Le programme ci-dessous donne les résultats suivants :
(https://apod.nasa.gov/apod/ap230426.html - EXIF 'Fr, 07 April 2023 22:21:14') ---- Lever Lune : 2023/4/7 20:16:01 112.160414663 Maillot->Etoile : distance = 1065.04410143 ; azimut = 115.71367909 distance * sin(0.5 deg) = 9.29414515847 m ---- https://fr.wikipedia.org/wiki/Arc_de_Triomphe_de_Paris http://wikimapia.org/#lang=en&lat=48.873776&lon=2.295027&z=16&m=o
Remarquez que la Porte Maillot, à un peu plus d'un kilomètre, c'est un peu juste. La Lune ne fait que 9.3 mètres à l'Arc alors que la voûte en fait 14.6.
Je ne suis ni photographe ni observateur. J'ignore si on peut obtenir quelque chose d'aussi net à cette distance-là. Ni si on peut voir la Lune aussi nette si près de l'horizon en ville. Mais, sinon, c'est tout-à-fait plausible. La Lune, levée depuis quelques minutes, a parcouru quelques degrés pour se trouver dans le bon azimut légèrement au dessus de l'horizon.
Après, on peut refaire l'exercice pour le Cinquantenaire à Bruxelles en faisant une boucle sur 365 jours et en alternant next_rising(moon) et next_setting(moon). Comme le comportement de la Lune est un peu erratique, il vaut peut-être mieux s'exercer avec le Soleil... (sun).
Dans le 'Hacker's Dictionary', vers 1980, pour désigner un programme dont les résultats étaient incertains, on trouvait :
> POM n. Phase of the moon (q.v.).
> Usage: usually used in the phrase "POM dependent"
> which means flakey (q.v.).
( https://www.dourish.com/goodies/jargon.html )
#!/usr/bin/python
import math
import ephem
from geographiclib.geodesic import Geodesic
moon = ephem.Moon()
#
# Porte Maillot (48.877938, 2.281962)
# Arc de Triomphe (48.873782, 2.295043)
# altitude : 59m
# https://commons.wikimedia.org/wiki/File:Rep%C3%A8re_d%27altitude_sur_l%27Arc_de_Triomphe.jpg
#
x = Geodesic.WGS84.Inverse(48.877938, 2.281962, 48.873782, 2.295043)
azimut = x['azi1']
distance = x['s12']
Pt_Maillot = ephem.Observer()
Pt_Maillot.lat = '48.877938'
Pt_Maillot.lon = '2.281962'
Pt_Maillot.elevation = 55 # ?
Pt_Maillot.date = ephem.Date('2023/04/07 18:00')
Pt_Maillot.date = Pt_Maillot.next_rising(moon)
print "(https://apod.nasa.gov/apod/ap230426.html - EXIF 'Fr, 07 April 2023 22:21:14')"
print "----"
print "Lever Lune : ", Pt_Maillot.date, moon.az * 180 / math.pi
print "Maillot->Etoile : distance = ", distance, "; azimut = ", azimut
print "distance * sin(0.5 deg) = ", distance * math.sin(.5 * math.pi/180), "m"
print "----"
print "https://fr.wikipedia.org/wiki/Arc_de_Triomphe_de_Paris"
print "http://wikimapia.org/#lang=en&lat=48.873776&lon=2.2950&z=16&m=o"
Pour une doc rapide, voir :
- https://rhodesmill.org/pyephem/quick.html (PyEphem Quick Reference)
- https://geographiclib.sourceforge.io/html/python/code.html
Inscription à :
Commentaires (Atom)


























