Aller au contenu
hoxca

SQM & TSL

Messages recommandés

Hello there,


Juste pour information, a propos de notre discussion sur le SQM Unihedron...


J'ai reçu hier ma commande du composant principal.

En attendant, toute mise en oeuvre je vous mets une photo sous la loupe du composant en package surface mount car c'est rikiki ;)

J'en ai pris 5 !


538990TSL237Real.jpg


Pour les plus curieux, j'ajoute la datasheet en attachement.

TSL237 Datasheet


Je sais que cela va vous laisser sur votre faim, mais je ne pouvais pas attendre de partager cela avec vous !

Je vous en dis plus, dès que l'oscilloscope me raconte des choses plus intéressantes.


A bientôt ;)

HoxCa

TSL237_Datasheet.pdf

Partager ce message


Lien à poster
Partager sur d’autres sites

je ne me rappelle plus (ou je n'ai pas suivi) cette discutions : peux tu me rappeler les tenant et les aboutissants ?

de ce que je comprend, tu vas bricoler un SQM toi même ?

Partager ce message


Lien à poster
Partager sur d’autres sites

Effectivement fredo.


J'avais clairement posé la question de savoir si nous avions de quoi mesurer l'épaisseur du ciel ;)

Et comme personne ne dispose d'un unihedron dans notre entourage je me suis lancé dans cette réflexion/construction.

Dans un premier temps, le prototype serait pour valider un fonctionnement en nomade.


Je sais qu'Il existe déjà des modèles en DIY, mais j'ai un truc derrière la tête; et je voudrais essayer de baisser au maximum le coût de fabrication.

Car j'ai dans l'idée un module communiquant à basse consommation qui pourrait rester dormir dehors...

J'ai donc commencer à chasser le milliampères dans mes soirées ;)


Stay tuned !

Partager ce message


Lien à poster
Partager sur d’autres sites

Bon, dans les reflexions du jour.


Pour pouvoir faire des mesures si l'appareil est censé rester dehors, il va falloir aussi détecter si il y a de la couverture nuageuse.

En règle générale les capteurs utilisés pour ce genre de détection fonctionnent avec une mesure de la température du ciel au zenith en infrarouge et compare ce résultat à la température ambiante. Le gradient de température au zenith étant beaucoup plus important lorsque le ciel est clair de tout nuage. (c'est aussi ce qui explique que la buée se forme plus facilement sur les optiques lorsque les instruments pointent au zenith)


On a dans la famille des MLX90614 ce qui est utile dans le domaine. Le truc triste c'est que plus la FOV est étroite et plus le capteur est cher !

En bref, c'est un peu plus de 20 euros pour un composant à 4 pattes je parle de la version ACC !


Voici la datasheet

MLX90614-Datasheet.pdf

 

Bref c'est en commande pour un 5V en ACC

Partager ce message


Lien à poster
Partager sur d’autres sites

Au passage j'ai aussi commandé quelques petits filtres ircut à destination du TSL237 pour supprimer les bandes dans l'infrarouge, car les mesures en serait certainement faussées...


Filtre ircut

236796ircut.jpg


En bref, j'avance.

Partager ce message


Lien à poster
Partager sur d’autres sites

ton sujet me passionne mais pk autant de filtres IR CUT ?

Ce ne sont pas tous les mêmes ?

Partager ce message


Lien à poster
Partager sur d’autres sites

arf, c'est tout le pb de l'electronique

par 100x cela vaut 10 centimes, à l'unité c'est 5 euro !


Cependant la photo n'est pas contractuelle.


et je n'ai toujours rien reçu. => j'imagine que cela viens à pied par la chine :)

Partager ce message


Lien à poster
Partager sur d’autres sites

Au passage j'ai aussi commandé quelques petits filtres ircut à destination du TSL237 pour supprimer les bandes dans l'infrarouge, car les mesures en serait certainement faussées...


Filtre ircut

236796ircut.jpg


En bref, j'avance.

ce serait intéressant de faire la mesure avec et sans, notamment sur des nuages :)

Partager ce message


Lien à poster
Partager sur d’autres sites

Ah, voila une remarque qui indique une incompréhension que je dois lever !


Le filtre à infrarouge est prévu pour le TSL237.

Evidemment il n'y aura pas de filtre sur le MLX90614 car c'est justement son domaine d'action !


Mais oui, en cas de nuage, la différence devrait être encore plus notable.

J'embarque tout le matériel pour un départ en bretagne ce soir. Donc, je vais avoir quelques heures à passer dans le nouveau laboratoire.

Au passage, j'ai fait l'acquisition d'une alimentation stabilisé en courant constant :)


Si j'ai le courage je vous ferais quelques screenshoot des courbes à l'oscillo, mais dans un premier temps ce sera sans nuages...


Bonnes fêtes à tous ;)

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonne année a tous !


Comme annoncé, j'ai étalé le matos sur un table pour ma semaine de vacances.


724596lab.jpg


Au départ, pour ce projet, je comptais me baser sur une pale copie chinoise de la plateforme arduino.


131277sunfounder.jpg


Le problème de ce truc, c'est qu'il consomme plus de 50mA à vide, en continu et sans rien faire !!!

Si c'est valable pour un prototype, cela risque d'être rapidement incompatible avec les futures évolutions de mon projet...


Je me suis donc lancé pour quelques recherche sur les modes de veille profondes de l'ATMEGA328PU, et je suis parti from scratch de ce microcontrôleur. Le truc s'alimente en 5V, il m'a donc fallu trouver un composant capable de stabiliser une tension en 5V sans dissiper plein d'énergie en chauffant les oiseaux (exit le LM317 !).


Je suis tombé sur ce LDO assez efficace le TC1262 en 5V, Je l'utilise comme base pour l'alimentation du microcontrôleur.

TC1262.pdf

 

Pour la plateforme, j'ai sorti le schéma classique de l'arduino sur breadboard et j'ai gravé le bootloader dans le nouveau MCU.

A partir de la, j'ai cablé de quoi brancher un FTDI 232 pour pouvoir reprogrammer facilement l'atmega.

Du coup, j'ai le schéma suivant:


243993schematic.png


Une fois le mode veille profonde implémenté, j'ai enfin une consommation plus raisonnable de 4,81mA en mode veille.

Une simple pression sur un bouton, permets de sortir l'engin de la veille pour effectuer une tâche...

Et réveille et à vide, je consomme moins de 20mA (l'amélioration est donc notable)


214166power.jpg


Je vous pose ici, une photo de la plateforme qui avance à nouveau un peu.

Et promis je vous parle des mesures du TSL237 et de son compagnon LDR GL55 prochainement...


804007sqm.jpg

Partager ce message


Lien à poster
Partager sur d’autres sites

:)))))))))))))

trop avancé pour mois, mais je comprend la direction générale et le fait qu'il faut un port serie pour programer le truc

bravo beau boulot


plutôt que de faire une mise en veille : c'est pas plus économique de faire un bouton on / off ?

Partager ce message


Lien à poster
Partager sur d’autres sites

Toute à fait. Il y aura un bouton on / off pour la version personnelle du SQM.


Cela dit, il ne faut pas oublier ma petite phrase anodine du 9 decembre 2017:

"un module communiquant à basse consommation qui pourrait rester dormir dehors..."

L'intérêt étant de systématiser la mesure en différents points du territoire !


Je n'en suis pas la, mais dans cette optique, je commence aussi à collecter

quelques informations sur les LPWAN ou "Low-Power Wide-Area Network".

eg: Lora ou Sigfox.

Partager ce message


Lien à poster
Partager sur d’autres sites

Bon alors ... j'ai rien compris mais bon, c'est pas mon univers aussi.

Ce que je comprends mieux c'est la finalité et ton objectif et, pour le coup, je trouve que c'est une super idée.

Partager ce message


Lien à poster
Partager sur d’autres sites

Ca c'est ccol.

mais j'ai lu que le LPWAN n'a qu'une portée max de 5 à 40km.


Dommage que tu sois obligé de passer de 9V (pile) à 5V (tension de l'Atmega).


Est-ce que le module FT232RL sera embarqué ? Il ne sert qu'à la programmation de l'Atmega c'est bien ça ?


La première étape est la lecture de la valeur SQM sur l'afficheur.

Je suppose que dans une version futur cet afficheur est inapproprié de part sa consommation et le fait que tu feras de la télétransmission de données via LPWAN.


Dis donc c'est pas donné le TSL237.

Partager ce message


Lien à poster
Partager sur d’autres sites

On a dans la famille des MLX90614 ce qui est utile dans le domaine. Le truc triste c'est que plus la FOV est étroite et plus le capteur est cher !

En bref, c'est un peu plus de 20 euros pour un composant à 4 pattes je parle de la version ACC !

 

Ah ouai quand même

Partager ce message


Lien à poster
Partager sur d’autres sites

Oui alban, tu as tout à fait raison.


Je commence à voir venir les étapes du projet qui sont les suivantes.

Je ne suis pas électronicien, si je fais des erreurs grossières dites le moi -bavardage-


[glow=red]Phase 1:[/glow] Le device est destiné à un usage dans les mains d'un utilisateur:


* Proto I/1:

1) Un proto qui marche avec un LDR et un TSL237, c'est alimenté avec une pile 9v, l'affichage s'effectue après la mesure sur un LCD

1a) Le LDR permets d'avoir une évaluation du nb de lux qui touche le capteur (ce ne sera pas précis, mais si le nb de lux est > 5, il est inutile de faire une mesure avec le TSL237)

1b) On sait lire la fréquence du TSL237 et la convertir en irradiance µW/cm^2 et mag/arcsec^2


* Proto I/2:

2) Dans la même configuration que précédemment, on peux ajouter le MLX90614 pour avoir une idée de la couverture nuageuse


* proto I/3:

3) Toujours sur la même plateforme, on rends le truc communiquant et on implémente un protocole de communication

ici, toujours pas besoin de passer sur du LPWAN, j'imagine que l'on sera sur un ESP8266 / ESP32.

Si on sait remonter les valeurs par le réseau, on peux abandonner le LCD !


* proto I/4:

4) Doit on détecter la pluie ?

Ajouter les mesures de température et de pression.


* proto I/5:

5) Programmation d'un driver ascom !


* proto I/6:

6) On passe a l'impression du PCB pour la version manuelle



[glow=red]Phase 2:[/glow] L'idée est de transformer la plateforme pour la rendre autonome...

C'est encore loin, mais on peut toujours commencer à rêver !


* proto II/1:

Pour cela il va falloir revoir totalement alimentation !

II/1a) Mettre en place un timer basse consommation pour le reveil de la bête. J'imagine un truc a base de TPL5110

II/1b) On bascule sur un batterie LIPO en 3,7 et on boost à 5V


* Proto II/2:

Ce serait bien que le device se recharge avec un petit panneau solaire.

cela nécessite aussi un module de recharge avec une protection de la batterie contre les surcharges et la décharge profonde...

La j'ai beaucoup de travail (j'y connais vraiment rien !) [coupé en 2]


* Proto II/3:

On se lance dans la communication LPWAN histoire de remonter les valeurs de l'objet sur un centralisateur.

Partager ce message


Lien à poster
Partager sur d’autres sites

Poursuite du projet avec l'implantation d'une photorésistance (ou LDR) sur la plateforme.


L'idée est de savoir détecter si il fait nuit et d'avoir une évaluation du flux lumineux dans lequel baigne le capteur.

Pour ce faire, j'ai choisi un composant très standard le photoresistor GL5528, dont vous trouverez ici la datasheet: GL55-SeriesPhotoresistor.pdf

 

Le principe de fonctionnement est très simple. Le composant agit comme une résistance variable en fonction du flux lumineux l'impactant.

Lorsqu'il est dans l'obscurité totale sa resistance est > 1MΩ


Pour l'utilisé avec notre microcontroleur, on implémente un très simple diviseur de tension

292402diviseurtension.jpg


Dans notre cas R2 est une résistance fixe reliée à la masse et à la pin A0 de notre microcontroleur

et le GL5528 est relier à la pin A0 du microcontroleur et a VCC soit dans notre cas 5V.

Le code du micorcontroleur fait la conversion de la valeur analogique lue sur la pin A0 (valeur entre 0 et 1023) pour obtenir le voltage au borne du LDR

float measured=analogRead(LDRpin);    // take a single reading
measured = 5 - (measured * 5.0 / 1023.0);   // convert to a voltage 

La valeur du voltage est affiché sur l'afficheur en Volt.


Une fois ce voltage obtenu, le code effectue un conversion pour obtenir la valeur en lux.

(j'ai fini par choisir une resistance de 47KΩ pour R2 afin d'avoir une plus grande sensibilité en faible lumière)

double getlux(float LDRvoltage)
{
 float LDRohms = 47000 / ((5/LDRvoltage) - 1); 
 double lux = (double)32017200 / (double)(pow(LDRohms, 1.5832)); 
 return lux;
}

 

Cependant j'ai remarqué que le capteur est très capricieux et peu renvoyer un nombre aléatoire de mesure erronées (outliers)

Comme nous sommes des astrophotographes, nous savons très bien traiter ce genre de problèmes statistique dans nos mesures.

J'ai donc ajouter un code pour calculer l'écart type de chaque mesure sur un échatillon de 25 mesures et j'expulse les valeurs aberrantes donc le σ > 1.65;

avant d'en sortir une moyenne :)


Voila ce que cela donne en lumière dans le labo

864216GL5528.jpg


Ce soir la lune était présente et j'ai mis le capteur sous son regard doux ! (avec 2 valeurs différentes de R2 10kΩ et 47KΩ)

J'ai obtenu les échantillons suivants sur une sortie debug en port série.


Moon 10k

142068moon10k.png


Moon 47k

828269moon47k.png


On note:

cCount le nombre d'échantillons,

oCount le nombre d'echantillon retenu,

SD l'écart type dans les valeurs retenues pour la moyenne

et la valeur en lux qui en découle ligne suivante


Il me semble que la résistance de 47K va l'emporter car elle est plus juste en basse lumière.

Certes le capteur va saturer plus vite en journée, mais cela à peu d'importance pour notre usage :)

Partager ce message


Lien à poster
Partager sur d’autres sites

Ne te serait-il pas possible d'utiliser les deux résistances et de faire une double mesure pour récupérer la mesure la plus précise en fonction du niveau mesuré ?

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour Axel,


En fait, la précision de la mesure n'est pas très importante, On veux juste une évaluation globale.

Il s'agit de savoir dans quel environnement on se trouve afin de pouvoir régler la période de référence pour la mesure de fréquence sur le TLS237.


En gros, je viens de coder un truc du genre:

si lux < 1 alors crépuscule astronomique => période de mesure 2 secondes

si lux < 3.4 alors crépuscule civil => période de mesure 1 secondes

si lux < 20 alors lieu public ombre => période de mesure 0.5 secondes

si lux > 20 alors il fait jour => période de mesure 0.1 secondes


L'idée étant de compter les fronts montant d'un signal périodique carré et d'en déduire la fréquence de lecture sur le TSL237.

avec cette librairie: Frequency Counter Library


Pour référence, voici le tableau de la page lux de wikipédia

475557lux.png


J'ai fait quelques tests sur le TLS237 hier soir. Dans l'obscurité à la lumière de mon écran le TSL237 à 20cm, l'oscilloscope indiquait une fréquence de 4 Hz.


696482sqmfreq.png


A la lumière, dans le bureau on passe vite la barrière du kHz...

Partager ce message


Lien à poster
Partager sur d’autres sites

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.


  • En ligne récemment   0 membre est en ligne

    Aucun utilisateur enregistré regarde cette page.

×
×
  • Créer...

Information importante

Conditions générales