Lire de multiples capteurs : quelle techno ?

Bonsoir,

Je souhaiterais avoir votre avis sur ce projet.
L'idée est de relever les données d'une cinquantaine de capteurs disposés à une distance de moins de 10m. Les données sont légères : un octet par capteur.
Je dois relever les capteurs à une fréquence d'une cinquantaine de fois par minute. J'ai donc besoin d'une collecte qui durerait moins d'une seconde, soit 0,02s/capteur max.

J'envisage deux technos : le RS495 et la radio (nrf24l01).

A-priori, j'ai une préférence pour le RS485, qui m'évite un éventuel problème d'interférence radio. Mais les tests que j'ai fait me posent un problème de timing : il faut que je place pas mal de delay pour basculer les modes émetteur/récepteur et attendre les réponses.

Avec-vous des conseils à me donner pour avoir un collecte rapide et fiable ?

Merci

Bonsoir

Quels sont ces capteurs qu'il faut interroger en moins de 20ms ? référence ?

Chaque capteur est connecté à un arduino-esclave.

L'arduino-esclave scrute la valeur max de son capteur entre deux relevés par l'arduino-maître.

Bonjour vblocs,

tu devrais répondre précisément aux questions, réfléchir dans le flou n'est pas très intéressant.

Donc quand tu auras répondu à celle al1fch réponds peut-être à celles ci ?

  • le matériel est déjà fixé ?
  • Quel est le rôle du maître : que fait-il des données des capteurs pendant qu'il les reçois ?

Oui, le matériel est fixé :

Les esclaves sont des Arduino Nano, connectés chacun à un capteur. Entre deux mesures, l’esclave met à jour la valeur max du capteur (1 octet). Dès que la valeur est lue, elle est remise à zéro.

Le maître et un Arduino Mega.

C’est le maître qui donne l’ordre de lecture des capteurs. Et une fois la lecture terminée, il envoie les données à un PC, en liaison série. Le PC stocke alors les données dans un journal.

Le problème, ici, c’est de raccourcir le délai de lecture.

L’une des idées que j’ai est la suivante :

  • le maître donne l’ordre à tous les esclaves,
  • le maître passe en mode “receive”
  • chaque esclave envoie ses données, avec un délai entre chaque. Par exemple :
    le capteur 01 envoie ses données à t0,
    le capteur 02 envoie ses données à t0 + d
    le capteur 03 envoie ses données à t0 + 2*d
    etc …
    Les données du capteur sont : un octet pour le n° du capteur + un octet pour la donnée

L’autre idée est d’utiliser une arborescence. Par exemple avec des expandeurs https://www.atlas-scientific.com/product_pages/components/port_expander.html
J’aurais alors un arduino qui lirait les données de sept capteurs puis renverrait le sous-groupe de données.

Qu’en pensez-vous ?

Ok c'est plus clair mais pas encore assez pour moi :

quand tu dis :

cinquantaine de capteurs, ..., relevés, ..., une cinquantaine de fois par minute.

Le processus est continu ou par cycle (une minute, petite pause, une minute, petite pause, ... ) ?

Tu vois où veux en venir ?

Non, je ne vois pas où tu veux en venir ... :confused:

Le relevage des mesures est aléatoire.

Les mesures se font par séries d'environ cinq minutes. Durant les séries, les mesures se font approximativement toutes les secondes. Donc, environ toutes les secondes, je dois relever les cinquante valeurs.

Ce qui est important, c'est d'obtenir les mesures en temps réel. Je dois les visualiser et les stocker.

L'ensemble fonctionne durant plusieurs heures.

Mon idée, est qu'avant de se confronter a des timings précis, est de voir si on ne peut pas les éviter logiciellement.

Les nano on peu mais assez de mémoire pour stocker chacune temporairement quelques centaines de valeurs de tes capteurs..

Elles stockent donc les valeurs des capteurs en attendant que le maître les récupères (toutes celles dispo à l'instant t d'un coup).

Cette technique de "bufferisation" utilisé dans les systèmes d'exploitation par exemple pour pallier les différences de rythmes entre la production de valeurs et leur traitement (buffers graphiques, buffers réseaux, ..., archivage, ...).

Je vois ce à quoi tu penses.

Effectivement, stocker les données serait une solution, mais il faudra alors que j'ajoute une horloge précise à chaque capteur pour assurer la synchro.

Ce que j'aimerais, c'est récupérer les données en temps réel, pour pouvoir observer le phénomène sans avoir à attendre la fin d'un cycle.

Effectivement, stocker les données serait une solution, mais il faudra alors que j'ajoute une horloge précise à chaque capteur pour assurer la synchro.

Oui, une interruption matérielle sur débordement de temporisation ferai l'affaire je pense.

Ce que j'aimerais, c'est récupérer les données en temps réel, pour pouvoir observer le phénomène sans avoir à attendre la fin d'un cycle.

Quand on parle de temps réel il faut préciser le délais max acceptables entre la production de la donnée et son traitement. Si ici c'est de la visualisation tu ne devrais pas avoir de retard trop perceptible avec la bufferisation.

Maintenant si a peu de frais une adaptation matérielle est envisageable il faut aussi explorer cette voie...

On ne sais toujours pas de quel capteur tu parles ! Et une petite idée du but général de ton montage serait sympa aussi... C'est top secret ?

C'est top secret ?

Oui, pour l'instant. Désolé. 8)

Mon problème, c'est le délai : j'aimerais pouvoir afficher les valeurs en moins d'une seconde. C'est là que je bloque en RS485.

Pour le master, il me faut des délais pour lancer l'appel aux esclaves :

    digitalWrite(pin,HIGH);// passage en mode émission
    Serial.print('1');// appel de l'esclave 1
    delay(20);
    digitalWrite(pin,LOW);// mode réception

Ensuite, pour les esclaves :

  // Attente d'une demande
   if(Serial.available()){
    getdata=Serial.read();
    }
    
   if(getdata=='1'){
    // on a reçu une demande :
    delay(20);
    digitalWrite(pin,HIGH);// passage en mode "émission"
    delay(10);
    Serial.println("AB"); // envoi des données
    delay(10);
    }

Donc, avec cette méthode, pour chaque esclave, j'ai :

  • 20 ms pour l'appel du maître
  • (20 + 10 + 10 =) 40 ms pour la réponse de l'esclave
    soit, pour cinquante capteurs : 50 * 60 = 3.000 ms

Est-ce que la solution consistant à insérer un délai dans la réponse de l'esclave fonctionnerait ?

   delay(slaveDelay);
   Serial.println("AB"); // envoi des données

avec un "slaveDelay" qui dépend du numéro d'ordre et qui sera fixé en fonction du temps de traitement du maître ?

Sinon, si ce n'est pas possible en liaison série, je vais passer en radio.

C'est top secret ?

Oui, pour l'instant. Désolé. 8)

C'est toi qui vois, perso je préfère travailler dans des environnement "libres" et "ouverts".

Bonne chance !

Passer en radio me semble une bonne solution. Je viens de tester la bibliothèque painless mesh qui met en réseau des ESP8266 et ESP32 avec la possibilité de passer des messages et de maintenir une synchronisation entre les nœuds (pas testé).

Ça pourrait répondre à ton besoin, mais il faudra remplacer les Nanos par des ESPxx.
D'un autre côté, tu n'auras plus le plat de spaghettis que tu dois voir pour l'instant...

vblocs:
C'est top secret ?

Oui, pour l'instant. Désolé. 8)

Le coté ennuyeux c'est que ce forum est un site de partage qui doit fonctionner dans les deux sens et son public est un public amateur.

trop de mystères , je passe mon chemin …, pas du tout motivé pour chercher des solutions qui ne sont peut être pas compatibles avec les contraintes inconnues de grosse part cachée du projet.

A tout hasard , en aveugle , une dernière idée malgré tout :
-câblage SPI filaire soigné, blindé (moins de 10m selon le message iniltial)
-mettre les cartes Arduino reliées aux capteurs en esclaves SPI
-côté "Arduino maître"un circuit matériel de décodage en cascade 6 vers 64 pour générer le 50 signaux CS (plus besoin d’adresse à transmettre, le maître sélectionne un à un les esclaves SPI et récupère les octets de données mesurées

Je vais regarder du côté des esclaves SPI.

Merci pour vos réponses et désolé de ne fournir davantage d'infos.