vendredi 19 juin 2015

Sismo piezo

Passage du bus de 05h09 suivi d'une voiture capté sur la tablette de fenêtre avec une boule de pétanque posée sur un petit capteur piézoélectrique de quelques cents (disque; amplifié 20 fois par un LM386)

Petite exploration avec le genre de capteur piézoélectrique (piezo sensor disc) que l'on trouve sur eBay pour quelques euro-cents... Le bidule se comporte comme un condensateur rempli d'un générateur de charges sensible aux déformations. Sa résistance est très (très) grande et une tension apparaît à ses bornes quand on le déforme (ou qu'il subit une pression (?; voir ici)). Pour éviter une errance totale, on y adjoint une résistance en parallèle. Si la résistance est faible, on écrase complètement le signal; plus elle est forte et plus on aura de signal (ou quelque chose comme ça). Bref, mettons, par exemple, 10 mégaohms (marron-noir-bleu).

Si on soude une petite anse au disque en laiton (?), qu'on y attache un fil auquel on pend une petite masse. En maintenant fixe l'autre côté du disque (vertical) et en faisant balancer la masse, on peut vérifier à l'oscilloscope que la période du pendule est bien 2 Pi racine(longueur/g). Dans ce cas-ci, 0.63 mètre donne une période de 1.59 secondes et on a un signal d'environ 20 millivolts d'amplitude (pour une faible amplitude du pendule).
On peut donc capter des mouvements lents (la pastille n'est pas cantonnée à des signaux en kilohertz) et le niveau de signal est compatible avec ce que l'on peut mesurer avec un Arduino (5 volts sur 10 bits donne une résolution de 5 millivolts).

L'application classique de ce type de capteur avec un Arduino, c'est la détection des chocs. On pose la pastille sur une surface plane, on dépose une petite masse sur le capteur et quand on tapote sur la table, cela génère un signal (parce que la table fait bouger le disque en laiton et que l'inertie de la masse s'oppose au mouvement de la partie supérieure du capteur qui s'en trouve comprimé. C'est très sensible; un choc modéré génère un signal de plusieurs dizaines de millivolts. Pour pouvoir mesurer ce signal tant en positif qu'en négatif, on le 'conditionne' en reliant le disque de laiton au centre d'un diviseur résistif (par exemple, aussi, 100 mégaohms; dans "Make: AVR Programming", il met le capteur en parallèle sur une des branches du diviseur résistif).

Sur Instructables, on trouve un sismomètre pendulaire à base de capteur piézoélectrique pour détecter les mouvements horizontaux. Une tige terminée par une masselotte et soudée à la pastille en laiton fixée verticalement dans un bocal. Les oscillations déforment la pastille et génèrent un signal.

Comme ici, les tremblements de terre sont plutôt rares, je ne suis pas sûr de pouvoir capter des mouvements transversaux et je m'intéresse donc aux mouvements verticaux. Dans un premier temps, je conserve l'idée de la tige soudée à la pastille mais je dispose le tout horizontalement. L'idée est que la pastille rattachée au sol va bouger et que la tige va avoir une certaine inertie et que cela va déformer la pastille. Le problème, c'est que je ne peux pas mettre de masse trop importante au bout de ma tige sans plier la pastille de manière permanente. On fera avec... En fait, cela fait un système oscillant dont la période dépend de l'élasticité, de la masse et de la longueur de la tige... Là, j'utilise un bout de fil de cuivre domestique de 1.5 mm² d'environ 16 cm de long. Cela oscille librement à environ 9 hertz. Pour simuler les tremblements de terre, rien de mieux qu'un pont enjambant une autoroute. Aussitôt dit, aussitôt fait. Et me voilà en route vers un pont de la région avec mon Arduino, mon Raspberry Pi, la tige+capteur sur un petit bloc de ciment, un powerbank et une caisse pour protéger le tout du vent...
À peine à genoux sur le pont, en train de lancer l'application, j'entends une voix derrière moi : "Je peux vous aider?...". Je me retourne; c'est la police... (À juste titre,) mon comportement lui avait paru suspect ;-) . Contrôle d'identité; je lui explique le but de la manœuvre. Rassuré, il s'en va et me laisse faire mes mesures...
Un peu plus d'une demi-heure de mesure avec un zoom sur le spectre du signal (GNU Octave + plotspec.m). Il y a énormément de trafic à cette heure-là sur le pont; il n'y a que quelques zones de calme (comme, par exemple, un peu avant 700 secondes et un peu après 1000. Si on zoome sur le signal, on obtient quelque chose comme :
En s'approchant encore, on voit bien les oscillation de la tige (j'ignore d'où provient le signal à 90 Hz dans le spectre; est-il mécanique (vibration de la pastille) ou électronique?)
Mais donc, en gros, cela fonctionne. Ce n'est pas très étonnant parce que le pont 'vibre' franchement, surtout quand un camion ou un bus passe. Il serait intéressant de connaître le déplacement typique (amplitude et fréquence) d'une telle structure. Mais, il faut noter que l'amplitude ne semble pas directement proportionnelle au poids du véhicule; cela dépend de l'état de la chaussée à l'endroit où il passe (et probablement de sa vitesse, des caractéristiques de ses amortisseurs, etc...). Mais donc, on voit bien les camions et les voitures sur les deux bandes de circulation (le pont fait bloc).

Reste à rendre le dispositif plus sensible et s'affranchir des oscillations libres de la tige. Une solution serait d'amortir son mouvement dans un liquide visqueux. Mais, pour le moment, j'abandonne la tige pour construire un autre dispositif à base d'une boule de pétanque (720 grammes) posée sur deux écrous posés sur le capteur (posé sur la tablette de fenêtre). Un écrou sur la tranche m'offre deux surfaces planes parallèles et un écrou sur le flanc fournit un support stable à ma boule. À noter, la feuille de papier qui isole le capteur de la boule et des écrous qui, sinon, font antenne et captent plein de parasites (la 'terre' (fil blanc relié au radiateur) est mauvaise et cela fonctionne mieux sans...).
Tant qu'à faire, je vais maintenant amplifier le signal avec un LM386 (que je viens de recevoir). La mise en œuvre semble particulièrement simple, il suffit de mettre le piézo (en parallèle avec sa résistance) à l'entrée de l'ampli opérationnel (avec le disque à la terre) et le signal ressort multiplié par 20 et centré sur 2.5 volts (quand le LM386 est alimenté en 5 volts). Aussitôt dit, aussitôt fait. Pas sûr que ce soit l'idéal (tant au niveau du choix du composant que de sa mise en œuvre) mais bon... Et, de fait, j'obtiens le beau signal en tête d'article avec un bus suivi d'une voiture. La configuration des lieux (?) offre parfois des observations curieuses comme :
Les vibrations sont trop rapprochées pour appartenir à des véhicules différents et, à 36 km/h (pourquoi pas), ils parcourent 5 mètres en une demi seconde... Une zone pavée interrompt le bitume sur quelques mètres de la voie à sens unique. Y aurait-il là une explication? Ce patron n'est pas systématique mais il survient régulièrement.

En mettant un condensateur de 10 microfarads entre les pins 1 et 8, on pousse l'amplification à 200 et on obtient quelque chose comme :
Reste à regarder pourquoi le spectre enfle (dans ce cas-ci) vers 200 Hz, minimiser le bruit, augmenter le signal... Je ne suis pas sûr que le dispositif soit suffisamment stable pour résister aux mouvements du pont et c'est sûr qu'à x200, cela va saturer. Ici, le signal dominant est la circulation dans la rue, il y a peu de chance d'y trouver un tremblement de terre; il faudrait essayer dans la cave ou dans un lieu plus reculé. Il est probable que le dispositif soit plus sensible que les accéléromètres (MEMS; ADXL335, MMA8452, MPU-9250, MPU6050,...) qui se trouvent dans les smartphones et que le projet AcceleROB de l'Observatoire Royal de Belgique (Uccle) utilise. Bon marché, ils ont une résolution de l'ordre du milli-g. AcceleROB devrait détecter des séismes de magnitude locale 3. Les sismomètres du réseau de l'ORB sont beaucoup plus sensibles; ils détectent des déplacements de quelques nanomètres comme, par exemple, sur ce rapport. Reste à voir quelles sont les relations entre déplacement, vitesse, accélération, fréquence des mouvements du sol. Le sismomètre à boule de pétanque est sensible à l'accélération (F=ma); la force que la boule exerce sur le capteur varie (il serait peut-être intéressant de mesurer le poids apparent de la boule avec une vraie 'balance' (il faut voir à quelle fréquence on peut échantillonner...; un HX711 est limité à 80 mesures/seconde, ce qui n'est probablement pas assez). Un sismomètre à solénoïde est sensible à la vitesse (c'est la variation de champ magnétique qui génère la tension que l'on mesure). Il faut s'intéresser aux fréquences de vibration propres de l'instrument qui interagissent avec les mouvements du sol. Pour s'en affranchir (?), on utilise des systèmes asservis : on maintient la masse inertielle fixe (mesure interférométrique) avec un champ magnétique variable généré par un courant que l'on mesure (?). Mais donc, il y a moyen de s'amuser. On constate, par exemple, que les mesures de l'ORB sont fortement perturbées par des vibrations d'origine anthropique (pendant la journée en semaine), l'observatoire de Uccle est perturbé par des trains qui passent à plusieurs centaines de mètres de là; celui du Sart-Tilman, par le trafic sur l'autoroute;... Je me demande, si dans ma cave, je pourrais capter le passage des trains dans un tunnel situé à 130 mètres... (?) Il serait également intéressant de capter un 'vrai' tremblement de terre (et pas uniquement le trafic automobile). Le problème, c'est que c'est rare et que pour le moment, j'enregistre tout (environ 400 mesures par seconde envoyées par l'Arduino à 38400 bps vers le Raspberry Pi qui le stocke (environ 6 MB/heure)...

Le breakout i²c avec un accéléromètre MPU-6050 est le moins sensible. Sur la tablette de fenêtre, il ne donne que du bruit; là où passent les bus, quelques bus mais pas tous; au pont sur l'autoroute :
C'est très bruité; on voit bien quelques véhicules lourds; les voitures sont noyées dans le bruit. À noter que X, Y et Z donne des traces similaires : quand il y a une vibration en Z, elle se retrouve sur X et Y. Avec 16 bits pour +/- 2g, Z est à environ 16000 et X,Y sont quasi à zéro; c'est bien la sensibilité maximum. (J'ignore pourquoi le spectre s'épaissit maintenant vers 40 Hz (et 100 Hz); sur la tablette de fenêtre, le bruit est 'blanc')

N'osant pas aller avec la boule de pétanque sur le pont, voici une comparaison avec le MPU-6050 sur un carrefour dont le sous-sol est creux et où passent de nombreux bus. Le sol vibre moins que le pont mais, quand un bus passe, les vibrations sont souvent perceptibles :
Seules les plus fortes vibrations sont captées par le MPU-6050.
La boule de pétanque est beaucoup plus sensible. Trop même. Le signal sature lors des plus fortes vibrations.
Le matin vers 7 heures, le trafic est quasi constant. C'est rarement calme plus de quelques secondes. À 17 heures, les voitures et les bus se suivent :
À noter que le renflement du spectre passe de 200 Hz à 120... C'est peut-être (/probablement) dû au ralentissement du trafic (?). À 10 mètres par seconde, les 10 centimètres d'un pavé sont franchis en 1/100 seconde. Mais c'est peut-être un peu spéculatif... (En plus, en échantillonnant à 400 Hz, un signal à 200 Hz est à la limite de Nyquist)

Le passage des trains semble être à la limite du détectable (?); il faudrait augmenter le signal et diminuer le bruit... (Je pourrais, par exemple, augmenter la masse... (mais il ne faut pas casser le piézo non plus...))

Un kettlebell de 4 kg ne semble pas donner de bon résultats mais je pense avoir capté un passage de train avec la boule de pétanque (x200) dans la cave :
Un événement assez long, plus ou moins constant et de faible amplitude par rapport au passage des véhicules dans la rue...

mercredi 3 juin 2015

ESP8266 et Expect

Module FTDI & Esp-05 sur un breadboard.

L'Esp8266 permet d'accéder au WiFi via des commandes AT sur une connexion série... En principe 'Expect' (tcl) semble indiqué pour ce genre de chipotage... Voici, par exemple, un petit script qui interroge le chip en boucle pour connaître la liste des réseaux présents.
#!/usr/bin/expect -f

spawn -open [open /dev/ttyUSB0 w+]
stty raw -echo < /dev/ttyUSB0
fconfigure $spawn_id -encoding binary
send "AT\r\n"
while 1 {
  expect {
    "ready\r\n" {send "AT+CWLAP\r\n"}
    "OK\r\n"    {send "AT+CWLAP\r\n"}
    timeout     {puts "  ThisIsTimeout  "}
    eof         {puts "  ThisIseof   "}
    }
  }
Comme j'utilise très peu Expect, il est possible que cela ne soit pas vraiment optimal, mais cela donne une idée...

Dans le montage utilisé, on a un module ESP-05, une interface USB-Série (3.3V) FTDI232 et un 'MB102 breadboard power supply 3.3 volts module' et quelques fils (RX/TX & alimentation). Le module 'power supply', équipé d'un régulateur AMS 1117-3.3 semble optionnel, le 3.3 volts pouvant être délivré par le module FTDI. Je pensais que les resets intempestifs de l'esp8266 provenaient d'une faiblesse de l'alimentation par le FTDI mais ils persistent avec le module d'alimentation... Le problème doit venir d'ailleurs; il faut probablement mettre une 'pull-up' sur le reset de l'ESP-05 (?). Sinon, cela semble fonctionner. La version du firmware de l'ESP-05 (0018000902-AI03) communique en 9600 bps, 8-bits, nopar (et pas de contrôle de flux hardware), ce qui correspond aux valeurs par défaut pour /dev/ttyUSB0 sur mon GNU-Linux Ubuntu 14.04. L'Esp8266 fonctionne en 3.3 volts. Il est possible que l'interface USB-série soit autre chose que /dev/ttyUSB0, par exemple /dev/ttyUSBx (avec x =1,2,...) ou même /dev/ttyACM0 (1, 2,...). Il faut consulter dmesg(8) (et/ou faire 'ls -lrt /dev/tty*', lsusb,...).

Il est aussi possible d'utiliser 'minicom -D /dev/ttyUSB0' en terminant les commandes par ^M^J (\r\n) mais la pauvreté de l'interaction rend l'expérience rapidement frustrante (pas d'historique ni d'édition de ligne (?)). Avec Expect, 'spawn minicom ...' semble ajouter des caractères indésirables liés à la gestion d'écran de type VT100 (?) et je n'ai pas trouvé de solutions plus simples (tip?, cu?,...) mais je n'ai pas beaucoup cherché. Si on reçoit bien le prompt mais qu'on ne parvient pas à envoyer des caractères (et donc pas d'écho), vérifier que le contrôle de flux hardware est désactivé.

Le connecteur WiFi de l'Esp-05 est un U.FL (IPX). On trouve sur eBay des pigtails pour SMA et RP-SMA, N,...

Il faut noter qu'en ville, en Belgique, en 2015, les réseaux pullulent; j'en capte une quarantaine de ma table et une courte balade en rue m'en renseigne des centaines. Le wardriving a beaucoup changé depuis le début des années 2000. La plupart sont bien protégés (WAP), d'autres sont volontairement ouverts dans le cadre des offres de type 'Internet Everywhere' des fournisseurs d'accès dominants (PROXIMUS(_AUTO)_FON et VOO_HOMESPOT). Quelques-un sont probablement mal configurés...

On obtient des lignes du genre :
+CWLAP:(0,"PROXIMUS_FON",-44,"06:**:**:99:**:**",1)
+CWLAP:(4,"MonRezo",-87,"**:f8:**:**:**:9c",2)
...


qui renseignent le type de protection ( (encryption): 0 open; 1 WEP; 2 WPA_PSK; 3 WPA2_PSK; 4 WPA_WPA2-PSK), le SSID, la puissance du signal reçu (en dBm?), l'adresse MAC de l'access point et le canal WiFi. À noter que l'adresse MAC renseigne le type d'équipement via les octets qui désigne le 'manufacturer' (et donc probablement aussi les failles de sécurité propres à ce type d'équipement...).

AI-THINKER IoT

Acheté un peu plus de 6€ sur dx.com, ce bidule offre une démo clé en main. Une fois mis trois piles 'AA' (et décoché le jumper qui sert au re-flashage). Il existe (paraît-il) une application Android iot.apk mais il est possible de l'utiliser à partir d'un PC normal. Il suffit de se connecter au réseau AI-THINKER (mot de passe "ai-thinker") et de communiquer avec 192.168.4.1. Parfois cela 'se fait tout seul', sinon, faire quelque chose comme (à titre indicatif) :
$ sudo ifconfig wlan1 192.168.4.3
$ sudo route add -net 192.168.4.0 netmask 255.255.255.0 wlan1
$ # éventuellement utiliser : iwconfig, ifconfig, dmesg, lsusb,...
Le but étant de donner une adresse à l'interface WiFi et y faire transiter les paquets destinés au bidule.

On peut alors accéder aux GPIOs en JSON avec curl(1)
$ curl http://192.168.4.1/client?command=info
{
"Version":{
"hardware":"0.1",
"software":"0.9.2"
},
"Device":{
"product":"Light",
"manufacturer":"Espressif Systems"
}
$ curl http://192.168.4.1/config?command=light
{
"freq":100,
"io0":,
"io2":,
"io4":,
"io5":,
"io12":,
"io13":,
"io14":,
"io15":,
"rgb":{
"red":0,
"green":0,
"blue":200
}
$ curl -X POST -H Content-Type:application/json \
  -d '{"freq":100,"io4":0,"io5":0,"rgb":{"red":0,"green":0,"blue":200}}' \
   http://192.168.4.1/config?command=light


Voir http://www.electrodragon.com/w/ESP8266_IoT

Lua

Il est possible de reflasher les Esp8266 avec un interpréteur Lua. Pour cela, il faut connecter le GPIO-0 à la terre, faire un reset (reset->gnd; cela semble différer d'un power-up) et utiliser un outil comme Esptool (un utilitaire en Python)pour flasher un pre_build de firmware de NodeMCU :
$ sudo python esptool.py --port /dev/ttyUSB0 \
                         --baud 115200 \
                         write_flash 0x00000 \
                         ../lua/nodemcu_latest.bin
Après, voir cet exemple qui montre comment créer un fichier init.lua sur le SoC. Sur Wikipédia, ils conseillent de commencer par un file.format(). Voir l'API NodeMCU.

Voir aussi

Le petit bidule de 5x5mm² comporte un 'core' 32 bits tournant à 80 MHz, 512 Koctets de mémoire FLASH et quelques dizaines (?) de Koctets de RAM (plus tout ce qu'il faut pour recevoir/émettre du WiFi, quelques GPIO, ADC(?),...