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 :

 schema_cabl_v2.png   384,02 Ko   5 téléchargement(s)

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 

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

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.

 schema_cabl_v1.png   284,24 Ko   36 téléchargement(s)

• 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 ? 

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

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

• 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 :

 prop1_cablage.png   139,15 Ko   6 téléchargement(s)

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 ?