Mot-clé - Electronique

Fil des billets - Fil des commentaires

Mercredi, juillet 13 2016

[DIY] Cat-Hunter, l’anti pisse

Quand on aime pas les chats il faut savoir s’en débarrasser ! Depuis mon déménagement (au rez de chaussée) un chat a déjà pissé plusieurs fois sur nos rideaux par la fenêtre !

Les répulsifs sous formes de granules odorantes (gerbantes !) n’ont pas l’air des plus efficaces, après moultes réflexions de plusieurs personnes l’idée d’un « psssshhhttt » automatisé fit son chemin.

Dans l’urgence, j’en ai acheté un sur Amazon, il s’agit basiquement d’une bombe d’air sec avec un déclencheur utilisant un PIR, dans le même temps j’ai commencé à fabriquer mon propre dispositif. L’idée de base est d’utiliser un désodorisant à chiotte automatique.

sense spray naked3

Plusieurs problèmes se posent, dans un premier temps le détecteur est au niveau du bouton (à la perpendiculaire du spray) et lors de déclenchements successifs il y a un temps d’attente de plusieurs minutes….

Commençons la charcuterie… On enlève toute l’électronique embarquée pour la remplacer et on gardera le moteur et la structure en plastique.

IMG_20160708_012235

La carte que j’ai prévu utilise un pic12f675 avec un mosfet 7n7002 et un PIR de Panasonic EKMB.

cat_hunter

IMG_20160712_005022

Le système marche correctement, reste plus qu’a voir son efficacité au prochain passage de cette saleté de chat !

IMG_20160713_004210

J’ai déporté le capteur PIR dans une boite de pellicule (oui oui j’utilise encore de la pellicule !) et je l’ai couvert avec un PAD de BMX qui trainait dans un coin. (il faut que je trouve un moyen de désactiver le système je n’ai pas mit de bouton et ça pu le jasmin Brise(r) chez moi !).

IMG_20160713_201524

#include <pic12f675.h>
#include <xc.h>
#include <stdint.h>

#define _XTAL_FREQ 4000000

#define MOTOR GPIObits.GP5
#define PIR GPIObits.GP2

#pragma config FOSC = INTRCIO
#pragma config WDTE = OFF
#pragma config PWRTE = OFF
#pragma config MCLRE = OFF
#pragma config BOREN = OFF
#pragma config CP = OFF
#pragma config CPD = OFF

uint8_t pir_detected = 0;

void main() {
TRISIObits.TRISIO5 = 0; // GP5 = Output for motor
TRISIObits.TRISIO2 = 1;
ANSEL = 0;
MOTOR = 0;

// Enable interrupt on change
INTCONbits.GIE = 1;
INTCONbits.GPIE = 1;
IOCbits.IOC2 = 1;

while(1) {
SLEEP();
if(pir_detected == 1) {
MOTOR = 1;
__delay_ms(500);
MOTOR = 0;
pir_detected = 0;
__delay_ms(1000);
__delay_ms(1000);
__delay_ms(1000);
}
}
}

void interrupt isr(void) {
uint8_t tmp = 0;
if(INTCONbits.GPIF == 1) {
pir_detected = 1;
tmp = GPIObits.GP2;
INTCONbits.GPIF = 0;
}
}

Classé dans:Astuce / Tips, Divers, DIY, Electronique

Lundi, avril 11 2016

[TIPS] Prends un cône je te dis !

Ça fait plusieurs fois que l’on me demande comment souder des CMS, je vais essayer de faire une série sur tous les types de package que j’aime assembler :) On va commencer avec le plus simple le TQFP (0.5mm pitch).

En premier lieu oubliez toutes les conneries vous disant de prendre de la pâte à braser ou des pannes de fer de 0.15mm. Pourquoi ? parce que c’est des conneries et que vous allez perdre plus de temps et d’argent que nécessaire. Tant que l’on ne touche pas aux QFN ou aux BGA il n’y a besoin que de matériel générique.

Alors les petits… On va commencer par le premier point les Pannes de Fer pour faire du CMS. Je vais y aller direct la meilleure c’est le 0.8mm conique. Et rien d’autre ! Avec la 0.8mm conique vous pouvez assembler aussi bien du TQFP que du gros PDIP (pour ceux qui aiment ça… faut de tout pour défaire un monde). Pour faire simple avec une 0.8mm conique la transmission de chaleur est très bonne et il est simple de faire glisser une goutte de soudure sur la patte.  La vidéo n’est pas de bonne qualité mais on fait ce qu’on peut :) Le secret ? Utiliser du flux pour souder proprement ça évite les ponts de soudure en court circuit !

Vous pouvez voir que la première soudure sans flux à tendance à adhérer sur toutes les parties métallique et à faire un gros pâté sale. Une fois le flux en place il suffit d’étamer la panne et de faire de rapide mouvement dans le sens de la PIN du chip pour déposer la soudure ! \o/

Bon bon bon ok j’ai dit de prendre du 0.8mm et j’ai utilisé du 0.5mm et vous allez me dire que je mens, du coup comme j’aime bien les challenges (et surtout avoir raison…) je vous fait la même avec la panne de 2.0mm !

Avec la panne de 0.8mm la soudure se fait à 350°C, 330°C pour la panne de 2.0mm. L’exemple le plus intéressant est le suivant avec la panne de 0.15mm. Le problème de ces pannes fines est le refroidissement de la pointe quand elle entre en contact avec la soudure. Dans la vidéo on peut voir que la pointe a du mal a fondre les boules de soudure… et je suis à 380°C.

Comme vous pouvez le voir le bout de la pointe ne transmet pas assez de chaleur seule la surface autour du cône permet de fondre la soudure. Je ne dis pas qu’il est impossible de faire ça avec une panne aussi fine, mais juste que c’est plus d’emmerdes que nécessaire.

panne015_result good_resultLes deux secrets sont donc l’utilisation de flux (il en faut toujours beaucoup !) et une binoculaire. Et la c’est sans négociation, en fait si je devais donner un conseil ça serait de partir sur une station de soudage moins cher (AOYUE ?) avec un fer au minimum 60W si possible 80W et avec les 200 euros que vous économiserez (par rapport a une station Weller) achetez-vous une bino ! Le problème quand on soude c’est pas la main qui tremble, c’est le feedback des yeux qui est peu précis :) Vous serez étonnez de voir la précision de vos mouvement une fois accompagné d’une bino. Le premier prix que j’utilise depuis des années est ici. Il existe une version avec un objectif 2X qui a une distance de travail plus courte. Elle est super cheap et c’est très bien parce que les optiques se retrouvent au dessus du fer ou de la souflette. Donc en attendant de devenir le roi du CMS et d’acheter une Mantis garder vos 5k$ pour vos projets :)

PS: je n’ai pas parlé d’une de mes techniques de soudure les plus rapide. Celle qui consiste à souder toute la rangée d’une traite en faisant des court-circuits et en les nettoyants avec de la tresse.

IMG_20160411_234439[1]


Classé dans:Astuce / Tips, Divers, DIY, Electronique, PCB

Mardi, mars 22 2016

Stylo Ventouse ++

Ça faisait un bout de temps que je n’avais rien posté et HugoKernel menaçait de me virer de #madeinfr !

Maintenant que mon four est réparé je compte bien me remettre à assembler des cartes et pour ça pas mieux qu’un stencil, de la pâte à braser et une pompe à vide pour poser les composants. Il est possible d’acheter des stylo ventouse pas cher sur la Baie !

$_12

Soyons francs…. C’est de la merde, ça n’aspire même pas une poussière et la construction est fragile. On va avoir besoin de quelques trucs pour moins de 20$.

SONY DSC

Le stylo, une pompe motorisée de chez seeedstudio et un peu de tuyau plastique 6/4mm (pour aquarium). (EDIT: La pompe peut-être trouvée sur ebay pour moins de 3€ ! http://www.ebay.fr/itm/152016013472 )

pvc_tube6V Mini Vacuum Pump_01

 

 

 

 

 

Il va falloir modifier la pompe pour l’utiliser à l’envers. Commencez par démonter les vis noires et accéder à la dernière cavité au contact du moteur.

SONY DSC
Dernière cavité

Percez le trou pour le tuyau sur la paroi en plastique de la dernière cavité (au foret à main pour plus de contrôle). L’air est initialement aspiré dans une petite rigole entre le plastique et la cage du moteur. Étalez de l’Araldite entre le plastique et le moteur en prenant soin de ne pas baver sur l’axe. Puis maintenir le moteur alimenté en rotation en revissant la pièce de plastique (pour éviter de coller l’axe).

SONY DSC
Joint de très haute technologie à base de résine polymère !

Remontez la pompe en prenant bien soin de replacer l’axe de la valve dans le bras du moteur.

Il ne manque plus qu’a percer le capuchon arrière du stylo et de couper une petite partie de la « baudruche » interne. Le tube PVC rentre tout juste dedans, autant en profiter pour faire joint. Faites aussi un trou de 3mm dans le plastique juste au dessus de la buse d’aspiration.

SONY DSC

La pompe de seeedstudio est largement assez efficace à 2 ou 3V (voir la vidéo).

IMG_20160323_002016 (2)


Classé dans:Astuce / Tips, Divers, DIY, Electronique

Stylo Ventouse ++

Ça faisait un bout de temps que je n’avais rien posté et HugoKernel menaçait de me virer de #madeinfr !

Maintenant que mon four est réparé je compte bien me remettre à assembler des cartes et pour ça pas mieux qu’un stencil, de la pâte à braser et une pompe à vide pour poser les composants. Il est possible d’acheter des stylo ventouse pas cher sur la Baie !

$_12

Soyons francs…. C’est de la merde, ça n’aspire même pas une poussière et la construction est fragile. On va avoir besoin de quelques trucs pour moins de 20$.

SONY DSC

Le stylo, une pompe motorisée de chez seeedstudio et un peu de tuyau plastique 6/4mm (pour aquarium). (EDIT: La pompe peut-être trouvée sur ebay pour moins de 3€ ! http://www.ebay.fr/itm/152016013472 )

pvc_tube6V Mini Vacuum Pump_01

 

 

 

 

 

Il va falloir modifier la pompe pour l’utiliser à l’envers. Commencez par démonter les vis noires et accéder à la dernière cavité au contact du moteur.

SONY DSC
Dernière cavité

Percez le trou pour le tuyau sur la paroi en plastique de la dernière cavité (au foret à main pour plus de contrôle). L’air est initialement aspiré dans une petite rigole entre le plastique et la cage du moteur. Étalez de l’Araldite entre le plastique et le moteur en prenant soin de ne pas baver sur l’axe. Puis maintenir le moteur alimenté en rotation en revissant la pièce de plastique (pour éviter de coller l’axe).

SONY DSC
Joint de très haute technologie à base de résine polymère !

Remontez la pompe en prenant bien soin de replacer l’axe de la valve dans le bras du moteur.

Il ne manque plus qu’a percer le capuchon arrière du stylo et de couper une petite partie de la « baudruche » interne. Le tube PVC rentre tout juste dedans, autant en profiter pour faire joint. Faites aussi un trou de 3mm dans le plastique juste au dessus de la buse d’aspiration.

SONY DSC

La pompe de seeedstudio est largement assez efficace à 2 ou 3V (voir la vidéo).

IMG_20160323_002016 (2)


Classé dans:Astuce / Tips, Divers, DIY, Electronique

Vendredi, mars 18 2016

RaspiO'Mix+ vs GrovePi+

Après le comparatif entre RaspiO'Mix et GrovePi, il était temps de faire un comparatif entre chaque évolution de ces cartes : RaspiO'Mix+ et GrovePi+.

RaspiO'Mix+ vs GrovePi+

Tout comme RaspiO'Mix, GrovePi vous permet de connecter vos modules Grove à votre Raspberry, même finalité mais choix technique différent : là ou RaspiO'Mix utilise directement les entrées / sorties du Raspberry, GrovePi utilise en fait un ATMega jouant le rôle d’intermédiaire entre le Raspberry et le monde extérieur via une liaison I2C.

RaspiO'Mix fait office d'interface direct entre le Raspberry et le monde extérieur, vous pouvez donc utiliser des lignes de commandes, du Python, ce que vous voulez sans avoir à passer par une complexe interface.

oshw-logo-100-px.png

Dans les 2 cas, GrovePi+ et RaspiO'Mix+ sont des projets OpenSource / OpenHardware et vous pouvez retrouver toutes les sources sur GitHub : GitHub / GrovePi et GitHub / RaspiO'Mix


Fonctionnalité GrovePi+ RaspiO'Mix+
Entrées / Sorties 7 8
Entrées analogiques 3 8
Résolution CAN 10bits 18bits
Lignes I2C 4 3
Lignes série 1 1
Horloge Non Oui (via DS1307) avec batterie de sauvegarde
Interrupteur 0 2
Alimentation via le Raspberry via le Raspberry ou une prise jack / bornier
Compatibilité Raspberry Pi A/B, A+/B+, Pi 2, Pi 3, Zero Raspberry Pi A+/B+, Pi 2, Pi 3, Zero
Respect du format HAT* Non Oui

* Le format HATs

Flag_of_France.svg.png
Autre chose importante, les RaspiO'Mix+ sont toujours fabriquées en France !

RaspiO'Mix+ est disponible à la vente sur le site www.raspiomix.org.

Vendredi, novembre 27 2015

Les entrailles d'OpenAlarm : Une première interface PC en Python

Je vous ai présenté dans le précédent article le principe de fonctionnement d'un OpenAlarm Node, c'est parfaitement fonctionnel et utilisable mais nous pouvons simplifier grandement tout ça et c'est là qu'intervient l'interface que je vais vous présenter dans cet article.

Un programme en Python nommé simplement base.py permet les interactions avec les OpenAlarm Node, il s'utilise en ligne de commande :

$ python3 base.py --help
OpenAlarm Base
Usage:
base.py [options] nodeid <nodeid>
base.py [options] config write <config>
base.py [options] config set <key> <value>
base.py [options] profile write <profile_name> [<profile_id>]
base.py [options] profile set <profile_id>
base.py [options] node write <node_name>
base.py [options] node read
base.py [options] listen [--csv <csv_file>]
base.py [options] remote <node_name> --set <commands>...
base.py --version
Options:
-p            Serial port
-f            Force node write even when different nodeid
-h --help     Show this screen
-d --debug    Debug mode
-v --verbose  Verbose mode
$ 

Je vais passer en revue toutes les possibilités offertes par ce programme.

nodeid

python3 base.py -p /dev/usbserial0 nodeid 2

Cette commande va donner au Node dont le périphérique série est /dev/usbserial0 l'identifiant de node 2

config write

python3 base.py -p /dev/usbserial0 config write default

Cette commande va écrire la configuration nommée default dans le node lié au périphérique /dev/usbserial0

Mais d'oû sort la configuration default ?

Toute la configuration d'OpenAlarm tient dans un fichier au format Yaml et default correspond dans l'exemple ci-dessus à la configuration du même nom du nœud config.

Ce n'est pas clair ? Regardons de plus près une partie du fichier de configuration oa.yaml :

[...]
configs:
    default: &default
        group: 210
        freq: 433
        ack: yes
        cmdtimeout: 15
        usbtimeout: 15
        autostart: yes
        power: 0
        remote:
            active: yes
            wait_error_cycle: 7
[...]

Nous y trouvons une suite de clefs / valeurs (les mêmes clefs que nous avons aperçu dans l'article précédent sur les entrailles du firmware) qui vont permettre de configurer comme nous le souhaitons notre Node.

Ainsi, dans l'exemple ci-dessus, nous donnons au Node le groupe 210, nous les spécifions une fréquence de 433Mhz, avec accusé de réception (ack = true), bref, je suppose que vous avez compris le principe de fonctionnement...

La commande config write va donc lire la configuration et l'envoyer au Node directement.

config set

python3 base.py -p /dev/usbserial0 config set group 220

Cette commande permet de modifier directement des variables de configuration, utile si on ne veut changer qu'un seule des paramètres.

profile write

python3 base.py -p /dev/usbserial0 profile write pir0

C'est assez explicite, avec cette commande, nous écrivons le profile nommé pir0 dans le périphérique /dev/usbserial0 (pour en savoir plus sur les profiles, voir le dernier article)

pir0 correspond au nœud du même nom du fichier oa.yaml :

[...]
    pir0: &profilepir
        description: Module avec capteur infrarouge 0
        feedback: yes
        period: 3
        eintwait: 3
        external_interrupts:
            io0: rising
        ios:
            io0: [ input, nopullup ]
        frame:
id: 2
content:
- counter
- waketype
- wakearg
- [ input0, input1, input2 ]
- voltage
- temperature
[...]

profile set

python3 base.py -p /dev/usbserial0 profile set 0

Change le profile courant du Node.

node write

python3 base.py -p /dev/usbserial0 node write xxx

Nous avons vu au dessus le fichier Yaml avec les nœuds configs et profiles, il existe un autre type de nœud, il s'agit de 'nodes' qui contient tous les paramètres pour un Node nommé.

Voici le contenu du nœud nodes du fichier oa.yaml :

[...]
nodes:
    pir0:
        id: 2
        config: *default
        key: abcdefghijklmnop
        profile:
            0: *profilepir
    temp:
        id: 1
        config: *default
        key: AKdlIqdjMKAQwJKz
        profile:
            0: *profiletemp
[...]

node read

python3 base.py -p /dev/usbserial0 node read

Lit le Node et affiche des informations sur sa configuration.

listen

python3 base.py -p /dev/usbserial0 node listen

Se connecte au Node via la liaison série et passe en mode promiscuous, une sorte de mode sniffer ou toutes les frames valident envoyées par les OpenAlarm Node sont retournées via l'interface série.

Si nous nous connections au node directement via l'interface série et que nous entrons la commande série, voici le format du contenu retourné :

$ ino serial
listen
OKX 010206000103047A0B16
OKX 010207000103007A0B16
OKX 010208000202007A0B16
OKX 010209000103007A0B16

À chaque réception d'une frame valide, elle est retournée sous la forme OKX 010206000103047A0B16, ou OK indique un paquet valide, X indique que le format de la frame est hexa, puis, suivi d'un espace, nous avons la frame brute.

Ce contenu n'est pas franchement lisible et c'est pour cela que nous utilisons le programme en Python qui nous simplifie grandement la vie, voici la même fonction listen mais utilisée via l'interface en Python :

$ python3 base.py -p /dev/usbserial0 node listen
Use device /dev/usbserial0
Start listen mode !
Nodeid: 1, frame type: 2 (0 second(s))
    Input       : bit0:0, bit1:0, bit2:0
    Voltage     : 2.94
    Temperature : 21.00
Nodeid: 1, frame type: 2 (5 second(s))
    Input       : bit0:0, bit1:0, bit2:0
    Voltage     : 2.94
    Temperature : 21.00
Nodeid: 1, frame type: 2 (5 second(s))
    Input       : bit0:0, bit1:0, bit2:0
    Voltage     : 2.94
    Temperature : 21.00
Nodeid: 1, frame type: 2 (5 second(s))
    Input       : bit0:0, bit1:0, bit2:0
    Voltage     : 2.94
    Temperature : 21.00

C'est tout de même beaucoup plus clair ainsi ! Non ?

Par curiosité, rendons cela un peu plus verbeux...

$ python3 base.py -p /dev/usbserial0 --verbose node listen
Verbose mode !
Use device /dev/usbserial0
Start listen mode !
verbose get
-> 0
verbose set 0
-> OK
listen raw
Nodeid: 1, frame type: 2, payload: 64000202007A0B15 (2 second(s))
    Counter     : 100
    Waketype    : 2
    Wakearg     : 2
    Input       : bit0:0, bit1:0, bit2:0
    Voltage     : 2.94
    Temperature : 21.00
Nodeid: 1, frame type: 2, payload: 65000202007A0B15 (5 second(s))
    Counter     : 101
    Waketype    : 2
    Wakearg     : 2
    Input       : bit0:0, bit1:0, bit2:0
    Voltage     : 2.94
    Temperature : 21.00
Nodeid: 1, frame type: 2, payload: 66000202007A0B15 (5 second(s))
    Counter     : 103
    Waketype    : 2
    Wakearg     : 2
    Input       : bit0:0, bit1:0, bit2:0
    Voltage     : 2.94
    Temperature : 21.00

Une fois ces données reçue, c'est à vous d'en faire ce que vous voulez...
Un paramètre csv vous permet de spécifier un fichier afin de stocker toutes ces informations dans un fichier.

node remote

python3 base.py -p /dev/usbserial0 remote pir --set period=1

Cette commande va se connecter à l'OpenAlarm Node connecté sur l'USB puis tenter une liaison distante avec le Node nommé pir (voir fichier format Yaml) afin de changer le paramètre period.


Voilà, vous savez tout sur l'interface actuelle en Python, si vous voulez en savoir, vous pouvez consulter le code et au sujet du fichier oa.yaml, je vous invite également à le consulter !

Lundi, novembre 16 2015

Les entrailles d'OpenAlarm : Le firmware

Il est temps de vous parler un peu de la partie logiciel du projet OpenAlarm qui est en 2 parties : le logiciel interne (firmware) aux OpenAlarm Node et la partie qui tourne sur l'ordinateur, dans cette première partie, je vais vous présenter uniquement le fonctionnement des OpenAlarm Node.

Cet article est volontairement technique et rentre dans des détails que l'utilisateur final n'aura pas à connaître mais si vous souhaitez participer au projet, vous aurez besoin de ces informations.

Principe de fonctionnement

Le fonctionnement des OpenAlarm Node est plutôt simple, le système est conçu pour être utilisable sans base, c'est à faire qu'avec juste 2 Node (et un ordinateur), vous avez un système pleinement utilisable, en effet, chaque Node embarque le code nécessaire pour la surveillance de grandeur issue de capteur (mouvement, température, luminosité, courrier dans la boite aux lettres, etc...) mais également celui pour servir de base réceptionnant les messages des autres capteurs.

Un Node à donc plusieurs modes de fonctionnement :

  • Le mode « écoute »  (lancé par la commande listen) qui permet de recevoir tous les messages des autres nodes, ce mode sera celui utilisé par la base pour réceptionner les messages de tous les Nodes
  • Le mode « surveillance » (lancé par la commande guard) permettant de rentrer en surveillance et d'envoyer à intervalle régulier les informations contenues dans les frames (voir plus bas)
  • Le mode « remote » (lancé par la commande remote) afin de se connecter à un Node distant (par radio) afin d'en modifier les paramètres

À la mise sous tension, un Node démarrera automatiquement en mode surveillance si ce dernier n'est pas branché à un ordinateur et ne reçoit pas de commande le lançant dans un autre mode.

Difficile de faire plus simple, non ?

Les sources

Tous les fichiers sources sont disponibles dans le dossier /src dont voici l'arborescence :

  • base : Contient le code source Python utilisé sur l'ordinateur
  • lib : Les librairies utilisées par le projet voir plus bas
  • node : Le code source embarqué dans les node

Le firmware

Les sources et librairies

Le firmware de chaque node est écrit en C et compilé avec les outils Arduino, j'ai utilisé Ino (une interface en ligne de commande pour Arduino) pour compiler / programmer les OpenAlarm Node mais vous pouvez bien entendu utiliser l'environnement par défaut d'Arduino.

Les librairies utilisées :

  • Jeelib : la plus importante, elle est l'interface entre le cœur du montage, le microcontrôleur, et la partie radio, elle gère également des fonctions très utile de mise en sommeil, etc... Je vous invite à parcourir la documentation très complète sur cette librairie qui simplifie grandement le développement.
    Il existe d'autres librairies permettant l'interfaçage avec les modules radios utilisés dans OpenAlarm comme celle de LowPowerLab ou encore RadioHead que j'ai découvert il y a peu de temps. L'idée serait de les tester en profondeur afin de voir si il serait intéressant de basculer sur une autre ou pourquoi pas, prendre le meilleur des 3 pour en faire une dédiée à OpenAlarm qui permettrait notamment de prendre moins de place en mémoire (le principale problème de Jeelib)...
  • SerialCommand : Une librairie utilitaire permettant de piloter les OpenAlarm Node via des lignes de commande, elle prend peu de place et permet de gérer des commandes suivi de leur arguments simplement (ex: set power 1 envoyé via la liaison série va modifier la valeur de la puissance d'émission à 1)
  • DallasTemperature et OneWireNoResistor sont utilisées si vous souhaitez communiquer avec des modules OneWire
  • OpenAlarm qui contient les fonctions principales du projet

Afin de compiler les sources avec Ino, voici les étapes à suivre :

  1. Installer Ino, ça peut être utile ;)
  2. Placez-vous dans le dossier src/node
  3. Lancez la commande ino build et voilà, vous pouvez maintenant envoyer le firmware sur le node (après avoir appuyé sur le bouton reset de ce dernier) via la commande ino upload

Voilà, vous avez un OpenAlarm Node fonctionnel...

Les commandes

Lorsque vous branchez un OpenAlarm Node sur le port USB de votre ordinateur, un périphérique série est créé et vous permet de dialoguer directement avec ce dernier via des commandes.

Pour lire la configuration du Node connecté :

$ ino serial
config
OpenAlarm node, version oa10
- nodeid      : 1
- freq        : 433Mhz
- group       : 210
- ack         : yes
- power       : 0 (highest)
- autostart   : yes
- cmd timeout : 15 second(s)
- usb timeout : 15 second(s)
- remote      : yes (wait error cycle: 7)
- key         : AKdlIqdjMKAQwJKz
Profile 0:
- period    : 3 second(s)
- feedback  : yes
- eint wait : 3

En rouge, nous avons la commande saisie sur l'ordinateur pour démarrer la liaison serie via USB et en vert la commande saisie via la liaison série sur le Node, le reste étant la réponse faite par la Node.

Liste des commandes disponibles :

Liées à la configuration :

  • config : Affiche la configuration courante
  • verbose : Spécifie le niveau de verbosité
  • debug : Active ou non la débug
  • get : Retourne la valeur d'une variable de configuration (ex: get power pour lire la puissance d'émission)
  • set : Modifie la valeur d'une variable de configuration (ex: set key ABCDEF pour modifier la clef)
  • frame : Permet de lire / modifier les frames radio (voir plus bas)
  • int : Permet de lire / modifier les interruptions matérielles (ce qui va sortir le node du mode veille)
  • io : Permet de lire / modifier / configurer les entrées / sorties

Commandes permettant de faire rentrer la node dans des modes spécifiques :

  • guard : Entre dans le mode de surveillance
  • listen : Entre dans le mode réception
  • remote : Connexion à un node distant
  • exit : Sort du mode courant

Liées à la partie radio :

  • send : Envoie les arguments par radio
  • rfinit : Initialise la partie radio

Liées aux tests :

  • blink : Fait clignoter les leds
  • test : Commandes fourre-tout permettant de lancer divers tests (usb, io, sleep, ...)
  • read : Lit une frame
  • volt : Lit la tension
  • temp : Lecture / calibration de la température (capteur intégré à l'µC)

Toutes les commandes ne sont pas toujours directement accessibles à des fins d'économies de mémoire et sont activables ou non via des #define.

Les paquets

J'ai voulu faire un système totalement configurable, ainsi, le format des paquets envoyés par la liaison radio n'est pas fixe et modifiable à souhait.

Utilisons la commande frame afin d'afficher le format courant :

frame
Frame (type: 2, size: 9) :
-> [type] [counter] [waketype] [wakearg] [input0,input1,input2] [voltage] [temperature]

La commande frame affiche alors le contenu d'une frame telle qu'elle sera envoyée à la base, voici une explication sur les différents éléments :

  • [type] : Le type de frame sur un octet permettant à la base de décoder les informations reçues (type: 2 dans l'exemple)
  • [counter] : Le compteur de frame usr 2 octets, à chaque envoi de frame, ce compteur est incrémenté (utile à la base pour savoir si cette dernière a manqué des paquets)
  • [waketype] : Une information sur ce qui a sorti la node de la veille (ex: interruption externe, timer, etc...) sur un octet
  • [wakearg] : Informations complémentaire sur la sortie de vieille (ex: l'entrée pour une interruption externe, la période pour le timer, etc...) sur un octet
  • [input0,input1,input2] : Un octet contenant la valeur des entrées 0, 1 et 2
  • [voltage] : La tension de la batterie (sur 2 octets)
  • [temperature] : La température lue via le capteur de l'µC (sur un octet)

En rouge, il s'agit de l'entête fixe (le préambule), en vert, nous avons ce qui reste totalement configurable par l'utilisateur

Si dans votre application, vous n'avez besoin que de la température, il vous suffit de le spécifier à l'aide de la commande frame :

frame set 4 65
Frame set !

Explication des arguments envoyés :

  • frame : La commande voulue
  • set : Un argument de la commande frame : on souhaite écrire le format d'une frame
  • 4 : Le type de frame (ce sera utilisé par la base pour reconnaitre le format)
  • 65 : 65 correspond à la température (voir explication plus bas)

Si nous retapons la commande frame, nous voyons que le format à bien changé :

frame
Frame (type: 4, size: 5) :
-> [type] [counter] [waketype] [wakearg] [temperature]

Au sujet du contenu des frames, dans la précédente commande, nous voulions une frame constituée uniquement de la température et nous avons utilisé 65 pour le spécifier, voici une liste de ce qu'il est possible d'utiliser pour constituer une frame :

  • input0 à input9 (8 à 17) : Les entrées numérique du microcontrôleur sur un bit
  • analog0 à analog5 (32 à 37) : Les entrées analogiques sur 2 octets
  • voltage (64) : La tension de la batterie
  • temperature (65) : La température issue du capteur interne du microcontrôleur
  • Bien entendu, vous pouvez ajouter n'importe quel type de chose à ajouter dans une frame

Les interruptions

Nous venons de le voir, au travers des frames, nous pouvons envoyer les informations que nous voulons à la base, ces informations seront envoyées à intervalle régulier défini au préalable (par exemple, avec un intervalle d'une minute), le reste du temps, l'OpenAlarm Node reste en veille afin de consommer le moins possible.

Mais comment faire si un événement se produit exactement durant cette veille ? C'est là qu'intervienne les interruptions qui vont sortir de veille notre Node afin d'envoyer immédiatement une frame dans le but d'alerter la base.

Le microcontrôleur possède des interruptions matérielles sur certaines de ses entrées / sorties et afin de spécifier lesquelles vont nous servir pour sortir le Node du sommeil, nous utilisons la commande int comme ceci :

La commande int sans argument nous liste les interruptions actuelles :

int
Not int !

Ajoutons 2 interruptions, la 2 correspondant à l'entrée / sortie 0 afin de surveiller un front descendant (falling) et la 0 pour un front montant (rising) :

int add 2 falling
Int added !
int add 0 rising
Int added !

Listons de nouveau les interruptions :

int
Ints (size: 2) :
- 2 (input 0) falling
- 0 (input 3) rising

Voilà, lorsque l'OpenAlarm Node rentrera en mode guard, il configurera les interruptions ci-dessus afin qu'il sorte du mode veille en cas d’événement pour envoyer une frame d'alerte.

Les entrées / sorties

Voilà une dernière commande qui va nous être bien utile, elle permet de configurer les entrées / sorties dans un état prédéfinie au moment de l'entrée en veille.

io
Inputs :
- io0 : input pullup
- io1 : input nopullup
- io2 : input nopullup
- io3 : input nopullup
- io4 : input nopullup
- io5 : input nopullup
- io6 : input nopullup
- io7 : input nopullup
- io8 : input nopullup
- io9 : input nopullup

Les profiles

Nous venons de voir les paquets, les interruptions et les entrées / sorties, OpenAlarm permet de créer des profiles qui regroupent tous ces paramètres afin de changer rapidement de configuration sans avoir à renvoyer tous les réglagles.

On peut ainsi imaginer être sur un profile simple lorsque vous êtes chez vous ou l'OpenAlarm Node envoie à une période de 5 minutes les paquets contenant le contenu des mesures de ces capteurs, et, lorsque vous partez de chez vous, vous basculez à distance sur un autre profile ou la période d'envoi est de 15 secondes.
En procédant ainsi, on gagne en autonomie.

Un profile peut contenir les informations suivantes :

  • period : La période d'envoi des informations à la base
  • feedback : Faire clignoter les leds du Node selon l'action courant
  • eintwait : Lorsqu'un évènement est détecté, nombre de cycle d'attente durant laquelle l'évènement si il est reproduit doit être ignoré (si eintwait = 2 et period = 5 secondes alors, le temps durant lequel un nouvel évènement sera ignoré sera de 10 secondes)
  • external_interrupts : Il s'agit de la configuration des interruptions externes (Les interruptions)
  • ios : La configuration des entrées / sorties (Les entrées / sorties)
  • frame : Le format des paquets (Les paquets)

Chaque OpenAlarm Node peut avoir un maximum de 3 profiles différents.

Pour basculer d'un profile à un autre, il suffit d'utiliser la commande set ainsi :

set profile set 1
Done

Un exemple concret

Voici un exemple concret d'utilisation de ce que nous venons de voir.

Imaginez que vous vouliez surveiller une pièce isolée avec un détecteur de mouvement, vous souhaitez également détecter des chocs (dans le cas ou votre Node est placé sur une des portes par exemple) et tant qu'à faire, vous aimeriez connaître la température de cette pièce.

Nous avons 3 capteurs utilisées :

  • Le détecteur de mouvement (PIR) que nous allons brancher arbitrairement sur l'entrée 0, ce capteur place sa sortie à l'état haut lorsqu'une détection est faite, sa sortie est de type push / pull et ne nécessite donc pas de résistance de tirage
  • Un capteur de vibration qui peut être vue comme un simple interrupteur se fermant lorsqu'une vibration est détecté, nous aurons besoin pour lui d'une résistance de tirage et nous brancherons ce capteur sur l’entrée 1
  • Le capteur de température interne

Nous nous connectons alors sur l'OpenAlarm Node :

$ ino serial
frame set 2 8 9 64
Frame set !
io set 0 input nopullup
Io set !
io set 1 input pullup
Io set !
int add 2 falling
int set !
int add 3 rising
int set !

Explications pour chaque commande :

  • ino serial On ouvre dans un terminal une liaison série avec le Node
  • frame set 2 8 9 64
  • io set 0 input nopullup On indique que l’entrée / sortie 0 devra être configurée en entrée sans résistance de rappel
  • io set 1 input pullup On indique que l’entrée / sortie 1 devra être configurée en entrée avec résistance de rappel
  • int add 2 falling On configure une interruption matérielle 2 (correspondant a l’entrée 0) sur un front montant
  • int add 3 rising On configure une interruption matérielle 3 (correspondant a l’entrée 1) sur un front descendant

Pour voir le paquet qui sera envoyé, utilisez la commande frame :

frame
Frame (type: 2, size: 7) :
-> [type] [counter] [waketype] [wakearg] [input0,input1] [temperature]

Une fois ceci réalisé, on peut configurer la période à laquelle le Node va nous donner des nouvelles de lui (1 minute et 30 secondes ici) puis on le lance en mode surveillance :

set period 90
Done
guard
Starting guard mode !

Maintenant, l'OpenAlarm Node nous enverra toutes les 1 minute et 30 secondes la frame que nous avons configuré et si un évènement survient via le capteur de mouvement ou le capteur de vibration, une frame est immédiatement envoyée.

Notre Node est pleinement fonctionnel en surveillance de sa zone mais imaginons que nous voulions changer la période d'envoi des frames, comme nous sommes feignants, nous n'allons pas aller chercher le Node mais tout simplement nous connecter à distance dessus afin de changer le paramètre voulu :

remote 1 AKdlIqdjMKAQwJKz 
Connecting...
Success!
period 60
power 3
exit
Disconnected!

Dans cet exemple, l'utilisateur se connecte au Node 1 avec la clef AKdlIqdjMKAQwJKz, puis saisie 3 commandes (en orange) afin de changer la période d'envoi des informations à 60 secondes et modifie la puissance d'émission avant de se déconnecter avec la commande exit.

Voilà pour le tour de présentation du fonctionnement logiciel des OpenAlarm Node, dans un prochain article, je présenterai l'interface Python permettant de réaliser les mêmes opérations mais de façon automatisées...

Mardi, juin 16 2015

Mise à jour de RaspiO'Mix : RaspiO'Mix+

RaspiO'Mix est, comme son nom l'indique, l'évolution logique de RaspiO'Mix pour les RaspberryPi dit « Plus » et Raspberry 2.

RaspiO'Mix est une carte fille (également appelée hats) pour RaspberryPi qui vous permet de connecter vos capteurs / actionneurs Grove (le système Grove chez Lextronic) au Raspberry simplement, sans connaissance en électronique.
RaspiO'Mix est un projet libre et ouvert, tous les plans sont disponibles en ligne.

product-plus.png

Caractéristiques

  • Compatible Raspberry A+, Raspberry B+, Raspberry 2
  • 8 entrées / sorties tolérantes 5V
  • 8 entrées analogiques, 0-5V, 18 bits de résolution
  • 2 entrées numériques via DIP switch
  • Horloge temps réel avec batterie de sauvegarde
  • 3 connecteurs pour I2C
  • 1 connecteur pour communication série
  • Alimentation 5V via jack ou bornier à vis

Utilisation en Python

Des exemples en Python sont présents sur GitHub et vous montreront à quel point il est simple de dialoguer avec les capteurs / actionneurs Grove.

Par exemple, pour faire clignoter une LED présente sur le port IO0 et afficher la valeur analogiques lue sur le port AN0.

# On importe les librairies qui nous seront utiles
from raspiomix import Raspiomix import RPi.GPIO as GPIO import time
r = Raspiomix()
GPIO.setmode(GPIO.BOARD)
# On configure le port IO0 de RaspiO'Mix en sortie GPIO.setup(r.IO0, GPIO.OUT)
# Et on boucle ! while True: GPIO.output(r.IO0, not GPIO.input(r.IO0))
print("%f Volt !" % r.readAdc(0))
time.sleep(1)

Difficile de faire plus simple ! Non ?

Plus d'informations

Tout ce dont vous avez besoin pour avancer avec RaspiO'Mix+ est disponible sur le site www.raspiomix.org :

Et bien entendu, pour commander votre RaspiO'Mix+, cela se passe sur www.raspiomix.org !

- page 1 de 14