Vu la faible consommation d'un arduino, on peut envisager de garder la carte de commande sur batterie, avec une entrée qui surveille la présence du secteur et une qui surveille l'état de la batterie.

Salut,

j'ai un p'tit programme tout simple qui joue avec 2 sondes qui réponds pas exactement a ta question, mais pas loin.
Je te le mets, au cas ou ca te donne de l'inspiration

Code:

#include <OneWire.h> // librairie pour capteur OneWire

//---- code des instructions du capteur
const int modeLecture=0xBE;
const int lancerMesure=0x44;

// --- constantes des broches ---
const int broche_OneWire=2; // declaration constante de broche des capteurs
const int ledPin = 13;      // LED connectée à la broche n°13
const int inPin = 7;        // un bouton poussoir connecté à la broche 7
                            // avec une résistance de pulldown


// --- Déclaration des variables globales ---
//byte data[12]; // Tableau de 12 octets pour lecture des 9 registres de RAM et des 3 registres d'EEPROM du capteur One Wire

// --- Déclaration des objets utiles pour les fonctionnalités utilisées ---
OneWire  capteur(broche_OneWire);  // crée un objet One Wire sur la broche voulue

void setup()   {
  pinMode(ledPin, OUTPUT);  // configure la broche 13 en SORTIE
  pinMode(inPin, INPUT);    // configure la broche 7 en ENTREE
  Serial.begin(115200);     // initialise connexion série à 115200 bauds
}

void loop(){
  unsigned long time;
  int Temp1=0;
  byte Adresse2[8]={0x28,0xBF,0xF5,0x33,0x03,0x00,0x00,0x6D};
  int Temp2=0;
  byte Adresse1[8]={0x28,0x4D,0xF0,0x33,0x03,0x00,0x00,0xA3};
delay (500);
 while (1){
  Temp1=capteurMesureTemp(Adresse1)*10;
  Serial.print (Temp1,DEC);
  Temp2=capteurMesureTemp(Adresse2)*10;
  Serial.print (":");Serial.println(Temp2,DEC);
  digitalWrite(ledPin,0);
  time=millis()+28500; // 30-1.5 secondes pour 2 pts/minute
  while (millis()<time)
    {// petite tempo dont on peut sortir si un clic
     if (digitalRead(inPin)) break;
     if (Serial.available() > 0) {Serial.flush(); break;}
    }
  digitalWrite(ledPin,1);
 }
}

float capteurMesureTemp(byte adressecapteur[8]) { //fonction qui renvoie résultat float et ne reçoit rien
  //-------- variable locale de la fonction ----------
  byte data[12]; // Tableau de 12 octets pour lecture des 9 registres de RAM et des 3 registres d'EEPROM du capteur One Wire
  int tempet=0; // variable pour resultat brute  de la mesure
  float tempetf=0.0; // variable pour resultat à virgule de la mesure
  // XXXXXXXXXXXXXXXXXXXXXX Lancement d'une mesure et lecture du résultat XXXXXXXXXXXXXXXXXXXXXXX
  // Serial.println("**** Acquisition d'une mesure de la temperature **** ");
  // avant chaque nouvelle instruction, il faut :
  //    * initialiser le bus 1-wire
  //    * sélectionner le capteur détecté
  //    * envoyer l'instruction
  //--------- lancer une mesure --------
  capteur.reset(); // initialise le bus 1-wire avant la communication avec un capteur donné
  capteur.select(adressecapteur); // sélectionne le capteur ayant l'adresse 64 bits contenue dans le tableau envoyé à la fonction
  capteur.write(lancerMesure,1); // lance la mesure et alimente le capteur par la broche de donnée
  //-------- pause d'une seconde -----
  delay(750);     // au moins 750 ms
  // il faudrait mettre une instruction capteur.depower ici, mais le reset va le faire
  //---------- passer en mode LECTURE -------------
  capteur.reset(); // initialise le bus 1-wire avant la communication avec un capteur donné
  capteur.select(adressecapteur); // sélectionne le capteur ayant l'adresse 64 bits contenue dans le tableau envoyé à la fonction
  capteur.write(modeLecture,1); // passe en mode lecture de la RAM du capteur
  // ----------- lire les 9 octets de la RAM (appelé Scratchpad) ----
  for ( int i = 0; i < 9; i++) {           // 9 octets de RAM stockés dans 9 octets
    data[i] = capteur.read();             // lecture de l'octet de rang i stocké dans tableau data
  }
  //----- caclul de la température mesurée (enfin!) ---------
  /*data[1]=data[1] & B10000111; // met à 0 les bits de signes inutiles
  tempet=data[1]; // bits de poids fort
  tempet=tempet<<8;
  tempet=tempet+data[0]; // bits de poids faible
  */
  tempet=(data[1]<<8)|data[0]; // a l'arrache style !
  // --- en mode 12 bits, la résolution est de 0.0625°C - cf datasheet DS18B20
  tempetf=float(tempet)*6.25;
  tempetf=tempetf/100.0;
  return (tempetf);
}

Pourquoi utiliser des télérupteurs ?
C'est pas ton arduino qui va commander tes relais d'eclairage ?

Quand je parle de diodes, bah je parle de diodes.
En l'occurrence je mets des diodes de redressement type 1N4007 (ou equivalent).
Leurs fonctions habituelle est de redresser une tension, ou de bloquer le passage de courant dans un sens, mais ici je les détourne de leur usage habituel.
En effet, quelque soit le courant qui les traverse, la tension a leur bornes est de l'ordre de 0.6/0.7V
Avec 3 en série avant l'alim de mon arduino il ne reste donc plus que 12-(3*0,6)= 10,2V.
Comme ça si mon alim fait un petite surtension de 1 ou 2 volts,mon arduino reste dans sa plage de fonctionnement normal.

Quand j'alimente un arduino avec une alim de PC, je mets 2 ou 3 diodes en série entre le +12 et le VIN.
Je sait pas si c'est indispensable, mais ca diminue un peu la tension d'alim de l'arduino, ca évite de trop faire chauffer le régulateur et ca le protège un peu des éventuels pics de tensions sur le +12V

Dans l'idée c'est vaguement ca :

(sauf que la il n'y a pas un ev par manche, mais des diffuseurs et surement une EV tres gros debit au bout du tube)
Tu imagine qu'a la place des diffuseurs il y'a tes electrovannes.

Le tube d'alimentation de chaque groupe d'électrovanne fait office de cuve de par sa taille par rapport au diamètre des électrovannes, un peu comme un condo de découplage qu'on met entre les bornes d'un composant électronique.

Le détendeur est monté directement sur le gros tube d'alimentation.

Entre le compresseur et sa cuve c'est pas un détendeur, c'est le manocontact qui commande le moteur du compresseur en fonction de la dite cuve.

J'ai travaillé sur des (gros, voire énormes) filtres a manches industriel, (le genre de machin de 150-200 mètres cubes avec 64/96 ou 128 électrovannes )
C'est pas tout a fait le meme principe que ton projet, mais il y'a des similitudes flagrantes.
Je sait pas caculer les debits et les tailles du tuyaux qui vont bien (je suis pas ingé, je suis un simple technicien), par contre j'en ai réglé et dépanné assez pour savoir ce qui ne marche pas.

J'essaye de te faire un dessin, mais sur informatique je galère faute de logiciel kivabien.

Je vais te faire un truc sur papier et le scanner, mais la j'ai pas trop le temps.


Dans le principe tu fait des groupes de 4 ou 8 electrovannes sur des gros tubes qui servent a la fois de nourice d'alimentation et de reservoir tampon pour les oscillation de pression

Sur chaque tube tu mets un détendeur a 5 bar par exemple (si c'est la pression qui va bien pour tes electrovanne)

Et tu alimente chaque détendeur avec un gros tuyau depuis la cuve du compresseur ou tu mets au moins 1 bar de plus que la pression dans tes tubes.


Ce dont je suis sur c'est que si ta distribution d'air entre les electrovanne et le compresseur n'est pas bien équilibrée, tu pourra augmenter la puissance du compresseur tant que tu veux, tu n'aura jamais des "pschit" regulier pour soulever ton sable.


Chainer tes vannes avec du tuyau de meme diametre partout, et avoir une grande longueur totale de tuyau, c'est le meilleur moyen pour que ca marche mal.

En pneumatique quand le débit d'air fait a yoyo comme ça il est important d'avoir avant tout une "grosse" réserve d'air, et que les tuyaux d'alimentation soient dimensionnés généreusement.
Les phénomènes de rebonds de pression dans le tuyaux d'alim et les pertes de charge jouent bien plus que la puissance du compresseur.
La qualité de la réalisation de la "nourrice" qui alimentera tes 64 vannes a bcp plus d'influence sur le résultat final que le compresseur.

Tes 64 EV, c'est une matrice de 8x8 ?

Bonjour,

le co et le co2 peuvent en effet se mesurer a l'aide de capteurs, mais ils sont inodores. En quantité le gaz principal d'un pet c'est le methane, qui ne sent rien non plus, mais qui se detecte facilement aussi.
Les "aromes" d'un pet sont en partie du aux gaz contenant du souffre, et la par contre ça décalamine bien les narines.

Merci

Je part en vacances dans quelques heures, j'aurais surement pas trop le temps de regarder de trop pres, mais en attendant j'ai installé python sur mon mac.
Des fois qu'entre 2 descentes et quelques tartiflettes je sache pas quoi quoi faire

J'ai choisi le BT car c’était le plus simple a mettre en place, mon "serveur" étant déjà équipe tout ça tout ça.

J'ai réalisé mon traceur de courbes en processing parce que j'avais trouvé un programme de départ que j'ai adapté a peu prés a mon besoin, mais en fait j'y connais pas grand chose en processing, je découvre le langage.
Passer en Python si tu me dit que c'est plus facile, ma foi pourquoi pas. Il faut que je trouve quelques exemples de codes qui causent via le port série, et d'autres qui font des dessins.
A partir de ça je devrais me débrouiller.
Du reste processing pour écrire des trucs dans un fichier texte ca a l'air assez chiant. Je cherche toujours un équivalent au fopen("truc.txt",a) de php (pour loger les trames de mon arduino). Si c'est plus simple en python ca me va bien.

Bonjour a tous,


je suis en train de réaliser une station météo a base d'un arduino nano (V 3.0) et d'une poignée de composants (un BMP085 pour la pression atmo, quelques DS18b20 pour la température a divers endroits, auxquels je compte ajouter des capteurs de luminosité,d'humidité, une RTC, et puis (soyons fous) par la suite girouette, vitesse du vent et compteur geiger (mais bon, chaque chose en son temps)).
Bref, pour le moment j'ai juste 2 DS18b20, le BMP085 et un module "bluetooth slave"  (en provenance d'eBay).

Coté arduino je me contente de lire mes capteurs chacun leur tour puis d'envoyer les valeurs soit sur l'usb, soit via la libraire "newsoftserial" en bluetooth vers mon mac.

Coté mac je récupère les valeurs dans processing, soit via l'usb, soit en bluetooth.

En USB ca se passe assez bien, je reçoit toutes les trames et je fait de "jolie" courbes sans problèmes particuliers.

En Bluetooth au bout d'un temps indéterminé je fini par avoir une déconnection (ça prends entre quelques heures et parfois 2/3 jours), et forcement après il ne se passe plus rien coté mac, alors que mon arduino continue de son coté a "parler tout seul".


J'aimerais trouver un moyen coté arduino et coté "processing" de détecter que la liaison a été coupée, ainsi qu'un moyen de la rétablir.

Bonjour,

vu de loin je pense qu'il faudrais que tu commande un relais pour utiliser le contact de celui ci.

Que veux tu faire exactement ?

J'ai trouvé des tas de trucs passionnants sur son site, mais pas de rubrique "contact" 


Je crois qu'il se cache derrière le pseudo d'un des intervenants de ce site (vu la FAQ, la traduction d'une bonne partie de la doc Arduino et pleins de liens),
j'ose espérer qu'il trouvera cette bouteille a la mer.

Bonjour, je me permet un petit up


la bibliothèque de X. HINAULT est très sympa, mais des que les températures négatives arrivent elle fonctionne bcp moins bien !

en fait le bug se cache dans ce coin la

Code:

data[1]=data[1] & B10000111; // met à 0 les bits de signes inutiles
tempet=data[1]; // bits de poids fort
tempet=tempet<<8;
tempet=tempet+data[0]; // bits de poids faible

En fait le bit de signe n'est pas si inutile que ça !!!
J'utilise une façon plus bourrine pour récupérer la dite température, en une seule ligne.

Code:

tempet=(data[1]<<8)|data[0];

Sachant que je fait des courbes sur mon mac a partir des données de mon arduino, j'ai cherché le pourquoi de mes tracés bizarre un certain temps !

En espérant que ce patch aidera d'autres.