13 réponses à ce sujet

[abdelkrim]

Bonjour à tous,

J'espère être dans la bonne section.

 

Avec 2 autres camarades de classe en GEII on a pour projet de fin d'année de mettre en place une "gestion de disponibilité" dans la cantine de l'université.

Notre projet est simple, là où sont entreposé des genre de dessous de table, nous souhaitons mettre un capteur de distance au dessus. Par exemple, si le capteur mesure une distance de 30 cm, cela signifie qu'il reste une cinquantaine de dessous de table, tandis qu'à 50 cm, il n'en reste plus qu'une dizaine.

Pour mieux comprendre on a fait un schéma qu'on a proposé au professeur.

 

Ils ont fortement apprécié l'idée et nous ont demandés de leur proposer une solution et un budget pour la rentrée.

Nous prévoyons donc d'utiliser un Arduino pour gérer les mesures des différents "sous modules" et pour les renvoyer ensuite à un serveur. Auriez-vous des conseils pour :

• Choisir le type de capteur de distance le plus adapté (ultrason, infrarouge, ou autre) ?
• Choisir la bonne technologie pour transmettre ces données de manière fiable sans prendre trop d'énergie à la pile (Bluetooth, LoRa, Zigbee ect..) ?

Pour avoir une idée de la distance et du nombre de module qu'on doit connecter au poste centrale, voici un schéma de la cantine :

La longueur de la cantine est facilement de 40 mètre * 30 mètre (grande cantine qui sert également de salle d'expo)

 

Bien sûr il faut au maximum éviter des modules tout prêt déjà existant sinon on va se faire tirer les oreilles pour manque de travail lol.
Merci d'avance pour vos retours et vos idées !

[Oracid]

Le projet est original. 

Personnellement, je commencerais avec un Arduino Nano enfiché sur un Shield et un télémètre à ultrasons. Quelques leds de différentes couleurs, visibles de loin, détermineraient le niveau de la pile. Je dupliquerais ce système au dessus de chaque pile.

Voici quelques lien :

Capteur à ultrasons HC-SR04 HCSR04 avec un excellent tuto

Clone arduino nano , c'est un choix !

Carte De Blindage Nano Keyestudio Avec Interrupteur D'alimentation Pour Arduino Nano - Circuits Intégrés - AliExpress Un Shield, pour moi, c'est indispensable et cela permet de simplifier le travail.

 

Bien entendu, il y a d'autres solutions. VL53L0X V2 l'infrarouge pour une grande précision.

 

Il y a aussi une autre solution qu'un télémètre, c'est le capteur de pression. Capteur de pression HX710B

[Sandro]

Bonjour,

 

J'imagine que tu veux que chaque capteur soit autonome (ie pas de cables entre les différents capteurs, pour éviter d'avoir des fils partout en travers de la pièce).

Je vais faire l'hypothèse que vos profs attendent à ce que vous fassiez le prototype d'un système industrialisable (et pas une simple preuve de concept). Je vais donc essayer de prendre en compte dans les choix qu'il faut (que produit en grand nombre), le système soit pas cher, ait une grande autonomie, et permette le nettoyage.


Pour les capteurs :
- capteur ultrason : consommation électrique importante, et la plupart des modules pas trop cher ne sont pas étanches (quand j'avais cherché il y a quelques années, les moins cher en IP54 étaient autour de 15€ pièce). Donc pas de problème pour un proto, mais probablement pas le bon choix pour une industrialisation (il faut choisir entre pas étanche du tout et cher)

- capteurs infra-rouge : prix bien moindre (le VL53L0X (pas le module, le capteur lui même) est à 2.59$/pièce en quantité 250, je suppose qu'on peut trouver bien moins cher). Il est possible de placer une plaque de protection par dessus (nb : c'est pas forément facile de trouver le bon matériel qui soit transparent dans l'infrarouge, mais c'est faisable). Je penses que ce serait mon premier choix de techno

- capteur de force/contrainte : intégration "facile" dans une structure mécanique, assez fiable mais pas très précis. Ça peut être une solution si vous avez un mécanicien dans l'équipe, mais si toute l'équipe est en GEII, je penses que la partie intégration mécanique vous prendra trop de temps sans grande valeur ajoutée pour vos profs

- potentiomètre linéaire : honnêtement, j'en ai jamais utilisé. Donc difficile de vous faire un retour sur le prix et la fiabiltié dans le temps. Très facile à mettre en oeuvre électriquement, un peu de boulot de méca

À première vue, avec les infos que j'ai, je choisirais le capteur de distance infrarouge

 

 

Pour le micro-controleur de chaque capteur :
- en mode industriel, il faudra une solution très basse consommation avec sommeil profond entre les mesures (donc pas de cartes toutes prêtes avec une LED et un convertisseur de tension linéaire)

- dans un premier temps, n'importe quel microcontrôleur habituel peut faire l'affaire à priori (arduino Nano, stm32, ESP32, ...)
 

Si vous voulez faire simple, un Arduino Nano pour le premier proto, et un Atmega328p seul (le micro-controleur qu'il y a dans l'arduino Nano) pour le proto industriel.
Si vous voulez pousser un peu plus loin, n'hésitez pas à partir sur des micro-controleurs plus "professionnels" (STM32 par exemple), mais ce sera plus de boulot.

Pour la communication des micro-controleurs de chaque capteur vers le cerveau central :

je laisse la parole à d'autres, je ne m'y connais pas assez pour vous faire un panorama complet des solutions et de leurs avantages/inconvéniants.
Du wifi peut permettre de connecter chaque capteur individuellement au wifi de l'établissement, donc de se passer d'unité centrale "physique", et d'utiliser un serveur comme unité de centralisation. Par contre la consommation électrique est (trop?) importante
Pour les solutions bluethooth ou infra-rouge, je penses que le capteur en haut à droite risque de poser problème avec le mur.
La plupart des solutions à base d'ondes radios (wifi, modules radios, lora, ...) devraient fonctionner
Via ondes téléphone (2G/3G/4G/5G) : probablement trop cher

À noter que certains micro-controleurs (ou modules contenant un micro-controleur) contiennent déjà certaines solutions de communication sans fil ou des circuits support. Selon les cas, ça peut justifier l'utilisation d'un capteur spécialisé.

À noter aussi que certains modules de communication ont une sortie série directement : si vous trouvez un capteur compatible, il y a peut-être moyen de se passer de micro-controleur (mais il sera plus compliqué de mettre le capteur en veille)

 

 

À propos de la consommation d'énergie :

Pour que le système soit pratique, il faut que le la batterie tienne longtemps (je penses qu'en dessous de 6 mois, le système ne sera pas utilisé dans la vrai vie). Je ne sais pas la place que vous avez pour la batterie, mais elle sera probablement limitée. Il faudra donc (sur le proto industriel) réduire au maximum la consommation électrique :
- le capteur ne doit pas prendre des mesures en continue (à part dans le cas d'un capteur de pression, qui consomme presque rien). Une mesure toutes les 1 à 3 minutes devrait suffire. Dans l'idéal, passer en veille encore plus profonde en dehors des heures de repas (soit basé sur l'heure, soit sur l’absence de changement depuis X minutes).
- il faut (sur le proto industriel) à tout pris éviter un module micro-controleur tout fait (arduino nano, ...) qui contient des LEDs allumées en permanence et qui empêchent donc de réduire la consommation. Le mieux est de faire votre propre PCB avec juste le stricte nécessaire. Il faudra également jouer sur les modes de sommeil du micro-controleur, et désactivé les périphériques (ADC, timers, SPI, ... inutilisés)

- selon le capteur et le micro-controleur choisis, soit le micro-controleur peut réveiller le capteur quand il se réveille (selon le capteur, on utilisera un pin enable, ou on coupera/allumera l'alimentation du capteur, ou on envera la commande pour prendre une mesure), ou alors ça peut être l'inverse, et le capteur réveille le micro-controleur quand il a une nouvelle mesure (idéalement seulement en cas de changement non négligeable)
- probablement le plus important : la communication sans fil consomme beaucoup lorsqu'elle est active. Il faut donc envoyer des messages uniquement lorsque c'est indispensable (ie la valeur à changé de manière significative), et finir la communication le plus vite possible (ie messages courts, peu de latence, éventuellement ne même pas demander de confirmation de réception). De même, si possible, on évitera de rester à l'écoute : le mieux est si la communication est uniquement à l’initiative du capteur (voir mono directionnelle)

 

Unitée "centrale" :

J'ai pas trop d'avis, ça dépendra de tous les autres choix effectués. Elle pourra probablement être reliée au secteur, donc pas trop de contraintes.

Déroulement du projet :

1) Identification des technologies

2) Plan avec des modules "tout prêt"

3) Test "unitaires" des modules (ie métriser chaque élément séparément), d'un point de vue électrique et logiciel

4) Assemblage d'un premier proto à base de modules

5) Programmation du premier proto, pour obtenir un "proof of concept", c'est à dire un démonstrateur que votre idée fonctionne (même si elle n'est pas industrialisée ni optimale)

6) Conception d'un prototype (semi) industriel : pour les capteurs, vous faites votre propre PCB avec le capteur (plutôt qu'un module) et un micro-controleur "nu" (plutôt qu'une arduino). Pour la partie communication, il vous faudra probablement rester sur un module (mais si possible un module qui ce soude sur un PCB), à moins que vous ne voyez la concetion de PCBs en radifréquence en cours (mais cette partie est beaucoup, beaucoup plus dur que le reste du projet).

 

Avec le point 6, vous pouvez commencer avec autant de modules que vous voulez, sans pour autant que vos profs se plaignent que vous ne faites rien. Si vous n'avez pas assez de temps ou que le projet est plus dur pour vous que prévu, alors avec les points 1 à 5 (et éventuellement un début du 6), vous avez déjà quelque chose à présenter. Si vous allez au bout du 6, alors ça fera un projet très abouti (si vraiment il reste du temps : faites en plus l'enceinte mécanique propre)

 

 

N'hésites pas si certains points ne sont pas clair ou qu'il te faut plus d'informations

[abdelkrim]

Merci pour vos réponses très détaillées !

 

Le projet est original. 

Personnellement, je commencerais avec un Arduino Nano enfiché sur un Shield et un télémètre à ultrasons. Quelques leds de différentes couleurs, visibles de loin, détermineraient le niveau de la pile. Je dupliquerais ce système au dessus de chaque pile.

 

Carte De Blindage Nano Keyestudio Avec Interrupteur D'alimentation Pour Arduino Nano - Circuits Intégrés - AliExpress Un Shield, pour moi, c'est indispensable et cela permet de simplifier le travail.

 

 

Alors concernant le niveau de la pile, on s'est dit que cette donnée pourrait être transmise au poste central pour qu'il la transmet ensuite a un serveur qui nous affichera la batterie du module pour économiser de l'énergie et de la technologie pour chaque module.

C'est quoi le concept de ce shield ?

 

Bien entendu, il y a d'autres solutions. VL53L0X V2 l'infrarouge pour une grande précision.

 

Il y a aussi une autre solution qu'un télémètre, c'est le capteur de pression. Capteur de pression HX710B

Si on n'a pas besoin d'une précision aussi avancée mais surtout d'économiser les coûts en énergie (et en argent pour l'université lol) on devrait partir sur quel capteur de distance ?

Et le capteur de pression c'est pour quelle solution ?

 

 

Bonjour,

 

J'imagine que tu veux que chaque capteur soit autonome (ie pas de cables entre les différents capteurs, pour éviter d'avoir des fils partout en travers de la pièce).

Je vais faire l'hypothèse que vos profs attendent à ce que vous fassiez le prototype d'un système industrialisable (et pas une simple preuve de concept). Je vais donc essayer de prendre en compte dans les choix qu'il faut (que produit en grand nombre), le système soit pas cher, ait une grande autonomie, et permette le nettoyage.

Effectivement chaque module est autonome même si certains seront assez proche. On veut éviter qu'il y ai un groupe que l'on doit recharger ou changer de pile 2 fois plus.

 

Les profs attendent effectivement un produit fini et on aimerai, pourquoi pas, que ce soit réellement bien fait pour qu'au final ils gardent la solution et qu'on marque l'histoire de notre école 

 

Si les capteurs infra-rouge sont moins gourmand en énergie et moins chère, ils sont effectivement le meilleur choix pour nous. Par contre j'ai pas compris pourquoi il y a des capteur de force/contrainte et potentiomètre linéaire ? Il y a peut-être des problématique qu'on n'a pas remarqué ?

 

 

Entre temps de notre côté on avait comme première idée :

 

 

Modules :

• Microcontrôleur : ATmega328P
• Technologie de communication : NRF24L01+
• Capteur : HC-SR04
• Pile : à voir selon le besoin

 

poste centrale :

• Microcontrôleur : ESP32 avec Wifi intégré
• Technologie de communication : NRF24L01+

 

Le poste centrale n'est pas le point le plus "compliqué" car il n'y en a qu'un et est sur prise secteur donc pas de soucis de ce côté.

En câblage pour les modules on a un truc dans le genre :

 

Niveau consommation on a effectivement pensé à un mode veille et que la stratégie serait donc :

Côté programmation on fera en sorte que les modules seront tout le temps en mode veille et que le poste central les réveillera -> communique > remettra en veille 1 par 1 pour éviter les collisions de donnée (même si d'après les profs il reste assez robuste pour gérer ça).

 

 

C'est intéressant un peu ? 

[Oracid]

Le Shield permet de connecter tout ce que l'on veut proprement, servo, capteur, potentiomètre, I2C, RxTx, etc. 

Un capteur de pression, installé sous la pile, permettrais d'évaluer le nombre de plateaux restants.

Je pense que le moins couteux serait le télémètre à ultrasons.

[abdelkrim]

Pour le shield c'est peut-être un peu trop grand non ? Car on essaye de faire quelque chose d'assez discret aussi lol

 

Par contre pour le capteur de pression sous la pile c'est une super idée ! Sa pourrait fonctionner comme un pèse-personne et donc pas besoin de capteur de distance !

 

Je réfléchis avec les autres membres et les profs, je vous donne un schéma dès que possible

[Oracid]

Par contre pour le capteur de pression sous la pile c'est une super idée ! 

Et bien, je pense que c'est précisément de cette manière que fonctionne les piles d'assiettes ou de plateaux, dans les selfs.

Mais je pense que c'est un système purement mécanique. Sans doute à base de ressorts.

[Oracid]

Cela s'appelle "un distributeur d'assiettes" et effectivement, cela fonctionne par gravité et ressorts.

[Sandro]

Si les capteurs infra-rouge sont moins gourmand en énergie et moins chère, ils sont effectivement le meilleur choix pour nous. Par contre j'ai pas compris pourquoi il y a des capteur de force/contrainte et potentiomètre linéaire ? Il y a peut-être des problématique qu'on n'a pas remarqué ?

Le capteur de force, c'est si vous voulez peser la pile, plutôt que de mesurer la hauteur à laquelle elle se trouve. Si c'est bien conçu, ça peut être très économique en énergie (selon le type de capteur de pression, c'est juste une résistance qui varie avec la pression, donc la mesure est quasi instantanée et demande très peu de courant). La difficultés est l'intégration mécanique, et la calibration (la précision de ces capteurs de forces est souvent médiocre).

Le potentimètre linéaire est encore une autre solution : tu fixe le corps du potentimètre à la partie fixe, et la "gachette" à la partie mobile : la tension mesurée au point milieu du potentiomètre sera une fonction affine de la position de ta pile. La consommation J électrique est très faible (si tu n'aliments le potentiomètre que pendant la mesure, et que tu choisis un potentiomètre avec une résistance assez élevée), et l'électronique est simplissime : tu alimentes ton potentiomètre avec une tension fixe (3.3V ou 5V) et tu mesures la tension du point milieu avec une entrée analogique de ton micro-controleur. (nb : si tu veux optimiser à fond, alors ça rajoute quelques composants : un mosfet pour couper l'alim, un condensateur entre GND et le point milieu si tu veux pouvoir faire une mesure très rapide avec un potentiomètre avec une grande résistance, ...). Je n'ai aucune idée du prix d'un tel potentiomètre (ça dépendra beaucoup de la course dont tu as besoin, et de la durée de vie souhaitée). Mais ce qui vas autour est très bon marché et facile.

 

Niveau consommation on a effectivement pensé à un mode veille et que la stratégie serait donc :

Côté programmation on fera en sorte que les modules seront tout le temps en mode veille et que le poste central les réveillera -> communique > remettra en veille 1 par 1 pour éviter les collisions de donnée (même si d'après les profs il reste assez robuste pour gérer ça).

Je te conseillerais plutôt d'avoir la communication à l'initiative des capteurs. Si tu gères bien le mode veille, celui-ci aura un impact négligeable sur la consommation. Il y a donc 2 élements couteux en énergie : gérer la transmission et faire les mesures.

Si c'est l'unité centrale qui dirige :
- le capteur doit être à l'écoute en permanence (ce qui empêchera de mettre l'antenne en veille, et possiblement de mettre le micro-controleur en veille (si l'antenne peut signaler qu'elle a des données, alors on peut passer par un gpio capable d'intéruptions pour réveiller le micro-controleur))
- lors de la réception du message, il faut démarrer le capteur (et attendre qu'il démarre), prendre la mesure, lire la mesure, transmettre la mesure à l'unité centrale (et optionnellement attendre une confirmation)

Si c'est le capteur qui dirige :

- le micro-controleur se réveille à intervals réguliers (toutes les 1 à 5 minutes je dirais)

- il allume le capteur et lit la valeur
- si la valeur n'a pas changée (ou pas suffisamment, le micro-controleur se rendort (on a économisé la transmission)

- si la valeur à changée, on envoi la donnée à l'unité centrale. La probabilité que celle-ci soit occupée est minime: si on envoi 8 bits (bien suffisent comme précision) sur une transmission à 115200 baud (pas très rapide, probablement ce sera plus rapide que ça), alors la transmission dure 69µs. Avec une émission par minute, ça fait une proportion de 1.15 ppm (=0.000115%) d'occupation du temps par capteur. Avec 10 capteurs, 99.999% du temps, personne n'émet. Et si tu rates une mesure, c'est pas très grave.
- en optionnel : l'unité centrale confirme la bonne réception : je te conseilles plutôt d'ajouter quelques bits pour avoir une détection ou correction d'erreur du coté unité centrale
- en optionnel : si tu veux faire de la veille prolongée en dehors des heures de repas, alors tu as 2 options : soit tu mets une RTC dans chaque capteur (consommation d'énergie très faible, tu tiens plusieurs années sur une pile bouton, mais ça rajoute un peu de cout), soit une fois par heure, le capteur envoit un messsage à l'unité centrale pour demander l'heure, et ainsi recaller l'horloge interne du micro-controleur (qui est pas très précise). Pour le coup, on est obligé de faire une communication en aller-retour (donc un peu plus de consommation), mais si en contre partie pendant toute une heure on n'émet rien car c'est pas l'heure des repas, on est gagnant. Nb : la fréquence à laquelle il faut envoyer l'heure dépendra de la vitesse de dérive de l'horloge du micro-controleur. Une astuce peut aussi être que l'unité centrale répond systématiquement l'heure à une valeur du capteur : juste, la plupart du temps, on n'écoute pas la réponse et on coupe l'antenne avant.


Pour te donner quelques ordres de grandeurs sur la consommation dont on parle, sur base du datasheet du nRF24L01+ (nb en lecture rapide, j'ai pas lu tout en détail, et j'ai jamais utilisé ce module) :
- lien vers une datasheet (probablement pas la dernière version) : https://www.sparkfun...cation_v1_0.pdf

- consommation en mode power-down : 900nA
- consommation en mode standby-I : 26µA
- consommation en mode transmission : 7 à 11.3mA (selon la puissance émise)

- consommation en mode réception : 12.6 à 13.5 mA (selon le baudrate)
- changement de mode power down à standby-I : 400µA pendant 1.5ms
- changements de standby-I vers RX ou TX, ou entre RX et TX : 8 à 8.9mA pendant 130µs

Supposons 1 transmission par minute, et calculons la capacité nécessaire par transmission et la capacité nécessaire par an.

Mode power down (900nA) :
par an : 900nA * 24*365= 7.9mAh

Mode standby-I (26µA):
par an (en continue): 26µA * 24*365= 227mAh (environ la capacité d'une pile bouton CR2025)

Mode powerdown (900nA) + réveil 1 fois/minute (nb : on compte juste le passage en mode standby-I, pas le passage en mode transmission ou réception)
- un passage de power-down à standby-I : 400µA pendant 1.5ms (=4*10^-7 h) : capacité = 0.4mA * 4*10^-7 h = 2*10^-7 mAh

- une passage de power-down à standby-I par heure pendant 1h : capactié = 60 * 2*10^-7 mAh = 1.2 * 10^-5 mAh
- une passage de power-down à standby-I par heure pendant 1 an : capactié = 24*365* 1.2 * 10^-5 mAh = 0.1 mAh

- consommation totale hors modes réceptions et émission : 7.9mAh pour le mode power-down + 0.1mAh pour les transistions ) 8mAh


Mode transmission (9mA), et passage d'un mode standby-I ou réception vers transmission : 9mA pendant 130µs:

- transmission de 16 bits @ 250kbaud : 64µs
- changement de mode + transmission = 130+64 = 200µs = 5.5 * 10^-8 heures
- capacité usée pour une transmission : 9mA * (5.5*10^-8 h) = 5*10^-7 mAh (pour envoyer un message)
- capacité usée pour transmettre 1 message par minuté pendant 1h : 5*10^-7 * 60 = 3 * 10^-5 mAh
- capacité usée pour transmettre un message par minute pendant 1an : 0.3 mAh

Mode réception (13mA):
par an (en continue): 13mA * 24*365= 114000mAh= 114Ah (114Ah@3.3V = 31Ah@12V, soit environ la moitié d'une batterie de voiture)

Mode réception (13mA) pendant 870µs + passage en mode réception (depuis standby-I ou transmission) (9mA):
 

- pour simplifier, disons 13mA pendant 1ms (=3*10^-7 heures)
- capacité usée pour une réception : 13mA * (3*10^-7 h) = 4*10^-6 mAh
- capacité usée pour une réception par minute pensant 1h : 2*10^-4 mAh
- capacité usée pour une réception par minute pendant un an : 2mAh


En conclusion, à condition d'avoir le capteur maitre des transmissions, et de passer toujours dans le mode de veille le plus profond possible (power-down) entre tes transmissions, il devrait être possible d'être <10mAh (@3.3V) si tu fais que transmettre, et <15mAh si tu veux attendre des réponses de l'unité centrale. Avec ça, la partie communication seule, peut tenir plus de 10 ans sur une pile bouton!

Reste à vérifier l'énergie nécessaire par les autres composants (micro-controleur, capteur)
 

[abdelkrim]

Merci pour vos réponses elles permettent à chaque fois de bien avancer sur le projet !

 

Mais je pense que c'est un système purement mécanique. Sans doute à base de ressorts.

Ah dans ce cas c'est pas pour nous mais on pourrait transmettre l'idée à nos collègues en GMP. Par contre entre l'idée électronique et mécanique je pense que l'école prendrait la mécanique donc on va garder le silence pour le moment 

 

Je te conseillerais plutôt d'avoir la communication à l'initiative des capteurs. Si tu gères bien le mode veille, celui-ci aura un impact négligeable sur la consommation. Il y a donc 2 élements couteux en énergie : gérer la transmission et faire les mesures.

Effectivement j'ai transféré l'info au membre de notre groupe qui fait les calculs et il a remarqué que dans la datasheet le mode veille est différent du mode stand-by et qu'attendre en mode écoute est trop gourmand.

 

Si c'est le capteur qui dirige :

- le micro-controleur se réveille à intervals réguliers (toutes les 1 à 5 minutes je dirais)

- il allume le capteur et lit la valeur
- si la valeur n'a pas changée (ou pas suffisamment, le micro-controleur se rendort (on a économisé la transmission)

- si la valeur à changée, on envoi la donnée à l'unité centrale. La probabilité que celle-ci soit occupée est minime: si on envoi 8 bits (bien suffisent comme précision) sur une transmission à 115200 baud (pas très rapide, probablement ce sera plus rapide que ça), alors la transmission dure 69µs. Avec une émission par minute, ça fait une proportion de 1.15 ppm (=0.000115%) d'occupation du temps par capteur. Avec 10 capteurs, 99.999% du temps, personne n'émet. Et si tu rates une mesure, c'est pas très grave.
- en optionnel : l'unité centrale confirme la bonne réception : je te conseilles plutôt d'ajouter quelques bits pour avoir une détection ou correction d'erreur du coté unité centrale
- en optionnel : si tu veux faire de la veille prolongée en dehors des heures de repas, alors tu as 2 options : soit tu mets une RTC dans chaque capteur (consommation d'énergie très faible, tu tiens plusieurs années sur une pile bouton, mais ça rajoute un peu de cout), soit une fois par heure, le capteur envoit un messsage à l'unité centrale pour demander l'heure, et ainsi recaller l'horloge interne du micro-controleur (qui est pas très précise). Pour le coup, on est obligé de faire une communication en aller-retour (donc un peu plus de consommation), mais si en contre partie pendant toute une heure on n'émet rien car c'est pas l'heure des repas, on est gagnant. Nb : la fréquence à laquelle il faut envoyer l'heure dépendra de la vitesse de dérive de l'horloge du micro-controleur. Une astuce peut aussi être que l'unité centrale répond systématiquement l'heure à une valeur du capteur : juste, la plupart du temps, on n'écoute pas la réponse et on coupe l'antenne avant.
 

On apprécie grandement cette proposition, surtout qu'on avait pas penser à ne rien transférer si la valeur n'a pas changé lol. Par contre imaginons que si on se met à communiquer dès 11h30 et que pendant 30 minutes personne ne touche au plateau d'un endroit, ça fera beaucoup de communication ignoré au point où on pourrait croire que le module (capteur) est défaillant. Peut-être ajouter dans le code qu'au bout de 3 fois même s'il n'y a pas de changement on communique avec l'unité central.

L'option que tu propose de confirmer la réception on y a pensé, par contre j'ai pas trop compris quand tu dis " je te conseilles plutôt d'ajouter quelques bits pour avoir une détection ou correction d'erreur du coté unité centrale"

 

Après avoir vue ta proposition avec une pile bouton, on a fait un schéma avec EasyEDA (n'ayant pas accès aux outils de l'école chez nous comme Altium) et donc voici le schéma actuel :
 

Pour la veille prolongé on a pensé la même chose, que lorsque l'unité central confirme la réception du message au capteur, il recalle en même temps l'horloge du capteur et lui dit de se réveiller dans environ 5min. Lorsque l'heure des repas est passé, il le rendort et lui dit de revenir dans 20 heures.

 

Sur ce schéma pour le moment on a gardé l'HC-SR04 car c'est celui qu'on trouve le plus simple à utiliser pour nous tout en étant le moins chère. On reste quand même ouvert à d'autre solution tout aussi intéressante car pour le moment avec nos calcul on voit qu'il est TROP gourmand.

La pile bouton est celle de disponible dans leur site mais les profs nous ont expliqué qu'elle ne tiendra pas forcément face au NRF24L01+, du coup on commence à réfléchir si on ne devrais pas utiliser une CR123A au vue de sa longévité (théorique).

On s'est également tourné vers l'ATtiny85 pour tester une autre approche qu'avec celle de l'ATMEGA328 car on utilisait seulement 9 broches sur les 28 disponible.

 

Pour le condensateur entre VCC et GND du NRF24L01+ on a vue que c'est assez important à faire pour stabiliser l'alimentation.

Les 2 résistances entre qui divise la tension pour PB3 c'est pour mesurer l'état de la batterie. Peut-être une info qu'on voudra communiquer de temps à autre (voir plus bas)

 

D'autre point à prendre en compte :

• l'ATtiny à un réveil tous les 7 ou 8 secondes (j'ai pas encore bien saisi ça dans la datasheet) donc on va pas réveiller le microcontroleur toutes les 5min exactement mais plutôt tout les x cycles de réveil (par exemple 37 cycles de 8 secondes = 4min56)
• Potentiel ajout d'un transistor pour éteindre complètement le capteur de distance car il est trop gourmand.

 

La stratégie au niveau du code :

• Mise en veille de tous les éléments, seulement le timer interne de l'ATtiny85 qui fonctionne
• Au bout de 5 minute, réveil des composants, calcul de la distance et envoie au poste central (selon si la distance a changé)
• Réponse du poste central pour la réception et rendort le module pour 5 minutes
• Cas où il la cantine est fermé Réponse du poste central pour la réception et rendort le module pour 20 heures (environ) tout en demandant une estimation de la batterie au prochain réveil.

 

On a pris note un peu de la consommation, on est pas sûr à 100% pour nos calculs car c'est un truc qu'on a jamais fait en cours (bizarrement on ne calcul jamais l'autonomie lol). Tout est détaillé dans un Excel ou on remarque que si on gère pas bien le HC-SR04, on a une autonomie de 20 jours 

 

On est sur la bonne voie ou on a tout fait de travers ? 

[Sandro]

NB : réponse sur 2 messages, car sinon ça dépasse le nombre max de citations

 

L'option que tu propose de confirmer la réception on y a pensé, par contre j'ai pas trop compris quand tu dis " je te conseilles plutôt d'ajouter quelques bits pour avoir une détection ou correction d'erreur du coté unité centrale"

En communication sans fil (voir même en filaire selon les cas), il est généralement prudent de considérer le cas où la transmission échoue. Un désagrément "mineur" est tolérable, un désagrément majeur doit être évité.
Dans ton cas, je vois 2 problèmes potentiels de communication :
1) L'unité centrale n'arrive pas à recevoir la valeur (par exemple car par grande malchance elle était en train d'écouter un autre capteur pile à ce moment là). Si tu envois une info toutes les N minutes, alors la conséquence est "juste" un retard de N minutes (à priori pas grave si N est suffisement petit). Si tu envois l'info que lors des changements, alors ça dépend : si "l'action" à entreprendre est basé sur une valeur précise (ou un changement atteignable sur le temps entre 2 mesures), alors il y a un risque que tu passes à "0 dessous de table restant" sans t'en rendre compte, car tu as raté le message (dans ce cas, c'est bien de demande une confirmation, au moins pour le cas "0 dessous de tables restant" ; si par contre l'action est basée sur un seuil pas trop bas (par exemple "<20 dessous de tables0)", et que tu ne peux pas passer de >=20 dessous de tables à 0 en moins de temps que l'intervalle de mesure, alors tu es safe.
2) Le risque que ta valeur soit corrompue (le plus classique est qu'un zéro devienne un 1 ou l'inverse, mais il existe des cas plus tordus. Il y a alors un risque de déclancher l'action à cause d'un nombre éronné (par exemple si tu avais (en binaire) 01000000 (=64) plateaux, et que par malchance ton 1 devient un 0, alors tu penses avoir 0 plateau, ce qui t'oblige à agir pour rien. Si tu ajoutes un code de vérification (par exemple un bit de parité, ou un octet qui est le xor de tous les octets du message), alors l'unité centrale peut détecter si le message est invalide et l'ignorer. Il existe des techniques un peu plus poussées qui permettent de corriger 1 (voir plusieurs) erreurs. NB : certains modules de communication gèrent ça pour toi sous le chapeau (au prix d'un débit efficace un peu moindre que celui théoriquement atteignable, sinon, il faut el faire toi même)
 

 

On apprécie grandement cette proposition, surtout qu'on avait pas penser à ne rien transférer si la valeur n'a pas changé lol. Par contre imaginons que si on se met à communiquer dès 11h30 et que pendant 30 minutes personne ne touche au plateau d'un endroit, ça fera beaucoup de communication ignoré au point où on pourrait croire que le module (capteur) est défaillant. Peut-être ajouter dans le code qu'au bout de 3 fois même s'il n'y a pas de changement on communique avec l'unité central.

Envoyer la valeur une fois de temps en temps si elle n'a pas changée, pourquoi pas. L'envoyer une fois sur 3 me semble un peu excessif, à moins que votre capteur ne soit vraiment pas fiable.
Si le capteur est bien fait, la principale "panne" devrait être la pile vide. Pour ça, vous pouvez envoyer 1 fois par jour la tension de la batterie à l'unité centrale : ça permettra au personnel de changer les piels en préventif, à un moment qui les arrange, plutôt que d'attendre la "panne" de batterie.

 

 

 

schema_cabl_v1.png

 

Je vois plusieurs problème sur le schéma :
1) Le module HC-SR04 est alimenté en permanence (je ne sais pas ce qu'il consomme, mais probablement trop pour l'alimenter en continue)
2) Les pins 5 et 6 de l'Attiny sont utilisé à la fois pour le NRF24L01+ et pour le HC-SR04 : à moins que vous n'ayez trouvé une astuce particulièrement astucieuse, vous ne pouvez pas utiliser les même pins. Ils vous faut donc 2 pins de plus sur le micro-controleur (quitte à changer de modèle de micro-controleur). NB : j'ai pas étudié la doc du NRF24L01+ pour savoir si les pins CE et CSN sont indispensables ou pas (si jamais ils ne le sont pas, vous récupérez ces 2 pins)
3) Je vous conseilles de toujours prévoir un condensateur céramique (typiquement 100nF) entre Vcc et GND pour chaque circuit intégré (ici l'arryiny85-20PU), placé très proche (<1cm, le plus proche étant le mieux) des pins Vcc et GND
4) Pour les résistances R1 et R2, dans l'état actuel, tu crée un chemin à 30koms entre le + et le - de ta pile 3V, soit un courant de 0.1mA : pour un système basse consommation comme le tien, c'est énorme. Si tu veux faire de la basse consommation, il te faut utiliser des valeurs (beaucoup) plus grandes. Le NRF24L01+ consomme 900mA (environ 1µA) en mode power down. Si tu veux une consommation du même ordre de grandeur, il te faut des résistances 100 fois plus élevées. Le problème est qu'avec des valeurs aussi élevées (1Mohms et 2Mohms), il est bien possible que ça perturbe le convertisseur analogique -> numérique de l'ATtiny (car il fait un appel de courant à chaque mesure pour charger un petit condensateur interne). Ça peut se résoudre en rajoutant un condensateur céramique suffisement gros en parallèle de R2 (une capacité de 100 fois celle du condensateur interne de l'ATiny donnera une erreur <1% si les mesures sont assez espacées pour laisser le temps de recharger)).
5) vérifie bien pour ton micro-controleur s'il a besoin d'un cristal externe ou pas (et si la précision de l'horloge interne sans cristal (si disponible) te satisfait)
 

 

Sur ce schéma pour le moment on a gardé l'HC-SR04 car c'est celui qu'on trouve le plus simple à utiliser pour nous tout en étant le moins chère. On reste quand même ouvert à d'autre solution tout aussi intéressante car pour le moment avec nos calcul on voit qu'il est TROP gourmand.

trop gourmand lors des mesures ou en veille? S'il est trop gourmand en veille, il suffit de lui couper l'alimentation lorsqu'il est en veille. Si c'est les mesures qui sont trop gourmandes, alors il n'y a rien à faire à part changer de capteur ou prendre une batterie plus grosse

 

La pile bouton est celle de disponible dans leur site mais les profs nous ont expliqué qu'elle ne tiendra pas forcément face au NRF24L01+, du coup on commence à réfléchir si on ne devrais pas utiliser une CR123A au vue de sa longévité (théorique).

Quand les profs disent qu'elle ne tient pas face au NRF24L01+ : ils veulent dire qu'elle n'a pas assez de capacité, ou qu'elle ne peut pas fournir assez de courant instantané? Dans le second cas, il suffit de remplacer le condensateur 10µF par un condensateur suffisement grand pour fournir toute l'énergie nécessaire à un cycle de mesure+transmission.

Pour l'utilisateur, tant que la taille de la pile ne devient pas gênant, moins souvent il faut la changer, mieux c'est. Donc ne pas hésiter à prendre une pile de grosse capacité si elle ne gène pas. NB : sur des durées >1 an, pensez à prendre l'auto-décharge de la pile en compte dans le calcul de l'autonomie : il vaut parfois mieux une pile avec un peu moins de capactié mais avec moins d'auto-décharge.
 

[Sandro]

On s'est également tourné vers l'ATtiny85 pour tester une autre approche qu'avec celle de l'ATMEGA328 car on utilisait seulement 9 broches sur les 28 disponible.

Si les broches vous suffisent, pourquoi pas. Mais le nombre de broches n'est pas vraiment lié ni au prix, ni à la taille.
Si on regarde chez digikey, l'ATtiny85-20PU est à 1.58€ : https://www.digikey....gAYAFAVRAF0BfIA
Un micro-controleur alternatif, avec 20 pins, à 0.90€, et qui fait seulement 3x3mm : https://www.digikey....3F3U6TR/3087895

 

 

Pour le condensateur entre VCC et GND du NRF24L01+ on a vue que c'est assez important à faire pour stabiliser l'alimentation.

Je suis d'accord, il en fondra probablement un, surtout si vous utilisez une pile avec un faible courant max.
NB : le choix du condensateur, en plus de la capacité, devra également prendre en compte le courant de fuite (ou la résistance de fuite). Selon les modèles de condensateurs, le courant de fuite risque d'être non négligeable pour votre application

 

Les 2 résistances entre qui divise la tension pour PB3 c'est pour mesurer l'état de la batterie. Peut-être une info qu'on voudra communiquer de temps à autre (voir plus bas)

 

Comme évoqué plus haut, 10k + 20k sont des valeurs beaucoup trop faibles (trop de courant de fuite). Par contre, si vous montez trop haut, l'appel de courant sur le pin de lATtiny vas fausser le diviseur de tension : la solution est soit de mettre un condensateur en parallèle avec R2, d'ajouter un ampli-op en suiveur (mais attention à la consommation de celui-ci : il en faudra probablement un spécial pour basse consomamtion et/ou avec un pin qui permet de le mettre en veille
 

 

D'autre point à prendre en compte :

• l'ATtiny à un réveil tous les 7 ou 8 secondes (j'ai pas encore bien saisi ça dans la datasheet) donc on va pas réveiller le microcontroleur toutes les 5min exactement mais plutôt tout les x cycles de réveil (par exemple 37 cycles de 8 secondes = 4min56)

Il n'y a que les humains qui se soucient des minutes. Si ça ne perturbe pas l'interface utilisateur, choisissez n'importe quelle durée qui vous convient
 

• Potentiel ajout d'un transistor pour éteindre complètement le capteur de distance car il est trop gourmand.

très probablement nécessaire avec la plupart des capteurs qui n'ont pas de mode veille intégré
 

 

La stratégie au niveau du code :

• Mise en veille de tous les éléments, seulement le timer interne de l'ATtiny85 qui fonctionne
• Au bout de 5 minute, réveil des composants, calcul de la distance et envoie au poste central (selon si la distance a changé)
• Réponse du poste central pour la réception et rendort le module pour 5 minutes
• Cas où il la cantine est fermé Réponse du poste central pour la réception et rendort le module pour 20 heures (environ) tout en demandant une estimation de la batterie au prochain réveil.

Je suggère que l'unité centrale indique la durée de rendormissement souhaitée si la cantine est fermée : si c'est les vacances, on peut demander bien plus que 20h, si la demande est faite à 4h du matin, alors ça sert à rien d'activer le capteur dessuite, mais il n'y a pas le temps pour dormir 20h. NB : il vaut mieux toujours sous-estimer un peu la durée du sommeil pour prendre en compte la tolérance de l'horloge du capteur. Au pire on lui dit de se rendormir pour 30 minutes. Mais ce serait dommage qu'il se réveille 30 minutes trop tard.

 

On a pris note un peu de la consommation, on est pas sûr à 100% pour nos calculs car c'est un truc qu'on a jamais fait en cours (bizarrement on ne calcul jamais l'autonomie lol). Tout est détaillé dans un Excel ou on remarque que si on gère pas bien le HC-SR04, on a une autonomie de 20 jours 

Ça ne me surprends absolument pas qu'avec le HC-SR04 actif en permanance l'autonomie soit muavaise (j'ai pas regardé sa consommation). Je vous conseille de faire aussi le calcul de sa consomation en l'activant juste le temps de faire la mesure (passage en mode alimenté + énergie nécessaire pour faire la mesure), pour voir si c'est acceptable sur l'année ou pas.
 

 

 

[abdelkrim]

Dans ton cas, je vois 2 problèmes potentiels de communication :

Effectivement on a une communication toutes les N minutes, à définir plus tard de combien est ce N, donc si la communication échoue 1 fois ça pourrait aller. Surtout qu'en vrai le NRF24L01+ a l'option d'attendre une confirmation de réception et également il inclut déjà des mécanismes de détection/correction d'erreur avec son CRC intégré. A voir comment l'ajouter au code. 

Par contre il serait peut-être judicieux de confirmer 2 fois quand c'est vide pour être sûr que justement c'est bien vide avant de lancer l'alerte ?

 

On va du coup envoyer 1 fois par jour la batterie à l'unité centrale pour qu'il décide quoi faire.

 

 

Concernant le schéma :

1) Effectivement et on s'en et rendu compte trop tard qu'il a un mode veille très gourmand et qu'à lui seul il peut mettre à terre une batterie 1000mA en 20 jours. Là on va soit le retirer soit mettre un transistor comme dit plus haut.

2) Alors on avait pensé que selon si l'info vient de l'un ou de l'autre, on a une sorte d'ID pour dire au microcontroleur qui communique. On voulait éviter l'ATMega328 car il consommait beaucoup alors que le 2/3 de ses pins étaient inutilisés. Du coup au vue de la réponse on a fouiné pour trouver une autre alternative qu'on va présenter plus bas. Merci !

2 NB ) Le CE permet de gérer le mode veille et le CSN le mode écoute, donc les 2 sont assez important finalement lol

3) C'est noté et ajouté pour le prochain schéma

4) D'accord merci, on refera nos calculs du coup au prochain schéma pour voir quoi y mettre

5) N'étant pas dans la précision, je pense pas qu'il en ai besoin.

 

 

Quand les profs disent qu'elle ne tient pas face au NRF24L01+ : ils veulent dire qu'elle n'a pas assez de capacité, ou qu'elle ne peut pas fournir assez de courant instantané? Dans le second cas, il suffit de remplacer le condensateur 10µF par un condensateur suffisement grand pour fournir toute l'énergie nécessaire à un cycle de mesure+transmission.

Pour l'utilisateur, tant que la taille de la pile ne devient pas gênant, moins souvent il faut la changer, mieux c'est. Donc ne pas hésiter à prendre une pile de grosse capacité si elle ne gène pas. NB : sur des durées >1 an, pensez à prendre l'auto-décharge de la pile en compte dans le calcul de l'autonomie : il vaut parfois mieux une pile avec un peu moins de capactié mais avec moins d'auto-décharge.
 

Plutôt le second oui, en gros ils ont expliqués que le NRF24L01+ peut générer des pics de courant (11mA pendant 2ms), chose mal géré par ce type de pile qui se résulte par une chute de tension significative --> résultat, le NRF24L01+ ne supporte pas la tension trop basse et ne fonctionne plus/mal. On pourrait gérer ça en ajoutant un condensateur mais ça rajoute baisse encore l'autonomie non ?

En vrai on préfère ne pas avoir un gros cylindre qui dépasse du plafond par rapport à un circuit bien plat mais si on ne trouve pas de pile-bouton qui nous conviennent on n'aura pas le choix 

 

 

Alors on a vue que le microcontrôleur ATtiny1616 est assez intéressant car en plus d'avoir légèrement plus de broche, il a une consommation équivalente voir plus faible que l'ATtiny85 !

 

 

Je suis d'accord, il en fondra probablement un, surtout si vous utilisez une pile avec un faible courant max.

NB : le choix du condensateur, en plus de la capacité, devra également prendre en compte le courant de fuite (ou la résistance de fuite). Selon les modèles de condensateurs, le courant de fuite risque d'être non négligeable pour votre application

Le choix de la pile est limite la plus cruciale visiblement, c'est pour ça pour le moment j'adapte tout mon circuit à lui lol

 

 

Je suggère que l'unité centrale indique la durée de rendormissement souhaitée si la cantine est fermée : si c'est les vacances, on peut demander bien plus que 20h, si la demande est faite à 4h du matin, alors ça sert à rien d'activer le capteur dessuite, mais il n'y a pas le temps pour dormir 20h. NB : il vaut mieux toujours sous-estimer un peu la durée du sommeil pour prendre en compte la tolérance de l'horloge du capteur. Au pire on lui dit de se rendormir pour 30 minutes. Mais ce serait dommage qu'il se réveille 30 minutes trop tard.

 

Ça ne me surprends absolument pas qu'avec le HC-SR04 actif en permanance l'autonomie soit muavaise (j'ai pas regardé sa consommation). Je vous conseille de faire aussi le calcul de sa consomation en l'activant juste le temps de faire la mesure (passage en mode alimenté + énergie nécessaire pour faire la mesure), pour voir si c'est acceptable sur l'année ou pas.

Ah oui très bonne idée, le poste central ayant l'information exacte sur l'heure et même la date, on pourra mettre ça en place pour éviter 15 jours de vacances d'utilisé lol.

 

Le HC-SR04 prend 2mA en mode veille, c'est un assassin de batterie lol. Pour ça on songe à le changer

[abdelkrim]

Re-bonjour !

 

Je reviens après les fêtes, on s'est pris une petite pause sur le projet mais on ne doit pas l'oublier même pendant les vacances car comme je le rappel :

 

Ils ont fortement apprécié l'idée et nous ont demandés de leur proposer une solution et un budget pour la rentrée.

 

Du coup je reviens avec plusieurs nouveaux éléments et nouvelles idées !

 

On a changé le microcontrôleur, on a opté pour l'ATTiny1616 car, en plus d'avoir plus de broches et une consommation d'énergie plus faible, il a un SPI matériel intégré se qui facilite la communication avec NRF24L01+. Egalement un ADC intégré et plus de mémoire flash et RAM tout en ayant un prix très abordable.

On a également changé le capteur de distance pour utiliser le VL6180X surtout pour sa faible consommation (par rapport au HC-SR04) et sa mesure rapide (par rapport au VL53L0X).

En module de communication on reste sur le NRF24L01+ car on lui trouve pas spécialement de défaut pour le moment.

Voici notre schéma :

 

Pour les autres câblages, on a mis un condensateur céramique de découplage (100nF) pour chaque composant afin de stabiliser sa tension d'alimentation.

Un diviseur de tension pour mesurer l'état de la batterie avec des résistances très élevé pour minimiser la consommation et on a ajouté un condensateur en parallèle de R2 (qui fait au moins 100 fois la capacité de celle du microcontrôleur) pour garantir une mesure précises.

Des résistances pull-up lorsque nécessaire pour le VL6180X.

 

Du coup maintenant on se pose la question de la pile et du régulateur de tension. De préférence et pour un soucis de place (et pour rester le plus plat possible) on aimerait utiliser des piles-bouton. S'il le faut, plusieurs en parallèles et/ou série pour augmenter l'autonomie et pour dépasser les 3V3 nécessaire pour nos différents éléments. Et dans ce cas on ajoute un régulateur de tension pour stabiliser le tout à 3V3.
Bien sûr il faut pas que tout ces composants "secondaires" aient une consommation trop importante que l'on ne pourrait plus se permettre de négliger lol

 

 

J''espère qu'on avance bien et pas plutôt dans la mauvaise direction