LPMD V6

Ceux qui connaissent mes activités dans la lutte contre la PL connaissent cet acronyme "LPMD"

LPMD = Light Pollution Mobile Detector 

Un "bricolage "avec lequel j'ai déjà pas mal étudié le sujet...

V1.0 = basé sur un simple capteur (Lightmeter) déposé sur le toit d'une voiture et un PC portable sur le siège...
V2.0 = idem, avec un GPS externe...
V3.0 = idem, avec un GPS connecté et cartographie en temps réel de la PL d'un lieu
V4.0 = idem, avec une caméra et l'intégration des images de la route 
V5.0 = idem, via désormais un SQM Meter et une analyse d'image en temps réel par des techniques IA
V6.0 = on supprime le PC et on le rend totalement autonome.... Via un EAB !
(EAB = EasyAstroBox, cherchez sur le forum...)

Fonctionnalités (V6.0, prototype) :
- fin de l'utilisation de programmes "fournisseur", code en open-source développé par mes soins (qui sera publié
sur mon site d'Astronomie sous Python)
- intégration de toutes les fonctions dans un boitier étanche, seule exigence : alimentation 5V (batterie ou 220V avec transfo interne)
- support de la mesure et de la capture sur un Raspberry PI (3 pour le moment, bientôt sur PIZero) faisant tourner le package EAB
- support des "SQM" Sky Quality meter (LU, LE, DL/LU, LR) par pour USB, série ou remote
- intégration d'une caméra 5Mpix 
- support d'un GPS au besoin...
- deux programmes : 


SQMReader : avec interface de contrôle visuelle permettant 

• sélection du port de lecture (plusieurs SQM peuvent être contrôles par un même boitier)
  
• choix du délai entre chaque mesure
  
• option de sauvetage dans un fichier (format standardisé)
  
• option de capture de l'image du ciel (vue à 60°, différent modes, selon la noirceur du ciel)
  
• option de sauvegarde sur un site FTP (j'y reviendrai)    
  

SQMMonitor : en démarrage automatique  

• reprend les options du précédant, mais en mode totalement autonome. Il suffit de mettre le courant pour que les opérations débutent.
  
• a une fréquence donnée, le boitier sauve les informations sur un site FTP (sur un serveur dédié).
  Des programmes de gestion vont pré-traiter les données et les centraliser, puis les transmettre à un autre site, pour participer à un programme international sur le sujet)
  
• si arrêt (panne de courant), la reprise des opérations est faite automatiquement dès la puissance revenue
  

Le logiciel étant une partie... Il fallait une "base" assez solide que pour supporter des activités "en tout temps" sur de longues durées.
Pour cela, j'utilise une distribution de EAB (voir sujet dédié) avec un support minimal (inutile de tout garder), mais parfaitement opérationnelle
(connexion à distance, support WIFI, WIFI access point, support GPS, etc...).

L'intégration physique est une autre paire de manche... Et en pleine élaboration. Il est certain que à terme, le boitier sera plus petit et permettra la capture "All Sky" via une nouvelle caméra (en test). Ce qui permettra au LPMD d'intégrer la poursuite des météores, au cas où... (mais cela, c'est une autre histoire ) 

Vue actuelle : 


Dans un boitier IP66, devant résister aux intempéries... Le seul fil sortant : l'alimentation... Aucune action manuelle requise.
C'est encore du "prototype", a vitre finale sera bombée... 

Mais je dois tester le fonctionnement, la réaction à la température (CPU + capteur + extérieur) et je l'ai donc disposé en site "réel" 



La phase de "debugging" commence donc... 
Le programme pouvant tourner indifféremment sous Windows ou PI, cela simplifie l'analyse de son fonctionnement

Version Windows...

Version PI


Quand il sera au point, le comité d'Astronamur a déjà décidé d'investir dans une modèle "opérationnel" pour le disposer dans la région, 
avant la migration "LED" qui approche à grand pas.

Si on veut argumenter, il faut des mesures claires et précises. Et la prise d'image pourra servir pour évaluer l'impact de changement de lumière (de Sodium orange vers un blanc bleuté de 4000 K   )

Bon, certes, il reste à faire... 
Mais ceux qui seraient intéressé de participer à ce projet, faites signe...

Remarque pratique, en passant... 
Un boitier de ce style disposé dans un site près de.. Ramillies, par exemple, permettrait d'être informé de la situation du ciel en quasi temps réel...
Ex : en mettant la capture des images (env 300 KB) toutes les 10 min, et l'envoi toutes les 30 min = 3 images "temps réel" sur un site, avec une information de la qualité du ciel locale, avant de s'y rendre... 

Je dis cela, je ne dis rien... 
Car moi, de toute façon, je n'irai plus guère observer là-bas avant (très) longtemps... 

On pourrait mettre un capteur chez moi, donc près du site.
les LED sont déjà là, donc difficile d'argumenter sauf si on a gardé les données faites ici sous le sodium.
Je peux fournir le 220 V évidemment.

J'avais quelques mesures faites sur ton site. On pourra voir à l'occase.

Mais en effet, en dehors de l'aspect PL (en restant "contributeur" pour la région) c'est une idée à creuser pour la version "all sky", qui permettrait à tout le monde (toi y compris) d'avoir une statistique totale sur la qualité du ciel... Et donc, de facto, sur le site d'observation.

C'est le même genre de dispositif (en plus coûteux) que l'on trouve sur les observatoires "pro".

J'en discute prochainement avec l'OCA également... Le but est d'obtenir un "maillage" qui permet 
d'objectiver les évolutions (dans un sens ou l'autre)...

TTF,

Ma rue est encore éclairée avec des vapeurs oranges. Pourquoi pas mesurer également chez moi.
On suit ton post avec intérêt , ce sera sûrement un prochain sujet à débattre en réunion mensuelle.

@Geist : Disposes-tu d'un SQM (même manuel ?) Si pas, même sans cela, tu peux déjà déterminer ton "environnement" en prévision du moment où la conversion sera faite. 
Cela permet déjà de "qualifier" ta région. Le but est de faire des photos (APN) (5 suffisent) avec des caractéristiques fixées. Photos à idéalement refaire selon les conditions météo "clés" (ciel clair, ciel nuageux, ciel pluvieux, brouillard) et conserver correctement annotées.   

Une fois la conversion LED effectuée (ou en cours), refaire les photos dans les conditions identiques
(setup APN et météo) permet d'objectiver les effets de la conversion : positifs ou négatifs ?
=> on a un aspect "qualitatif", le "quantitatif" est fournit par une vraie mesure de type NSB (en mag/arcsec²) tel que issue de ce type de boitier...

Mais faute de mieux, c'est déjà une très bonne base d'information, surtout si tout le monde le faisait... Ensuite, avec une mesure calibrée, on peut déjà relativement objectivement "comparer" (avec une marge d'erreur, mais soit, c'est mieux que rien ). 

Nouveau release software (version 1.8 )...



Je décode désormais toutes les caractéristiques du SQM Meter pour en extraire toutes les les données de calibration et d'identification. Mais j'ai encore à bosser sur la gestion automatisée des fichiers. 

Pendant ce temps, la version 1.6 "tourne" et attend la nuit...
(avec un bug hardware camera (certainement une soudure), mais on examinera cela demain...)

Petite mise à jour...

J'ai passé pas mal de temps à me battre avec un... connecteur de camera !
Et en finale, il a fallut tout remplacer (la camera aussi) pour que cela fonctionne. 
A noter : si on rate un minuscule problème de branchement... C'est la mort des composants sensibles...  

1) Remise "à plat" des versions, on démarre désormais avec la V2.0 de SQMReader, qui offre
- vérification de version (dans un futur release, mise à jour automatique)
- reformatage des données captées, extension des valeurs (voir plus loin)
- correction des bugs découverts
- annotation améliorée des images (voir plus loin)
- test des "modes" low light de la caméra
=> c'est la première version "stable". On peut désormais passer au deuxième programme,
qui sera évidemment basé sur les fonctions du premier.

2) Un test ok !
- la nuit passée, le boitier a correctement pris mesures et images (dans les limites actuelles de la capture). Le mode "pose" me pose (sic) quelques problème de ressources sur un processus "temps réel" et des actions en // pendant les différents processus
a) celui qui capture le NSB
b) celui qui calcule le temps entre deux captures
c) celui qui lors d'une mesure NSB, contrôle la caméra et qui "pré-examine" la luminosité pour savoir dans quels mode de prise de vue basculer.
d) celui qui estime la durée de la pose "idéale" (et qui règle ISO, durée, etc...)
e) celui qui sauve les données dans des fichiers
f) celui qui assure les échanges entre serveurs... 
Tout ce petit monde s'entrechoquent un peu pour le moment.
Actuellement, je limite la prise de vue à deux "conditions" : "Day" et "Night", avec une pose d'intégration des conditions limitée (max 5 sec d'analyse). Mais le mode actuel requiers min 1 min entre deux mesures pour garantir que tout se soit passé.       

Rem : on n'est pas sur un APN... Il faut tout coder soi-même et je teste le "Raw" (max 6s de pose) 
Mais la future caméra (HD) sera visiblement meilleure et plus sensible.

Ex de capture :

http://www.beastro.be/publication/LP/LMPD_V6.0_IMG_BEL01_00004587_2020_07_07.gif

Dans chaque image : date / heure / mode de capture (N=Night / A=Auto(Day))
Délai de capture     : 5 min

Analyse des données :

 
Du grand classique de l'analyse PL... Avec une différence marquante : la température interne du boitier du SQM Meter, qui n'est évidemment plus en rapport direct avec l'environnement extérieur.
=> il faudra rajouter une sonde thermo/barométrique à la prochaine version pour en tenir compte. 

Et en examinant les aspects "internes" du fonctionnement du SQM Meter, deux choses intéressantes :


J'ai volontairement "ajusté" les valeurs pour avoir une vue significative des courbes...
Et on remarque que vis à mis de la MPSAS mesurée, que :
- il y a un "point" de basculement dans la méthode d'estimation avec la descente de la fréquence (d'échantillonnage ?)
- épaulé par un nombre de "comptage" directement lié à la noirceur du ciel... (au plus haut, au plus de comptage avant l'intégration en maq/arsec²)
- mais même si la mesure reste relativement "stable" pendant la nuit, les deux courbes semblent descendre au fur et à mesure de la nuit (pourquoi ?)
- par contre, si la mesure fournie, passé (env) 6 Mag/arcsec² devient systématiquement "0", la fréquence continue à grimper... (jusque où ?)
=> est-ce que l'on pourrait utiliser cette valeur pour un "luxmètre" simplifié ? A creuser...

Le boitier vient de passer (avec succès) l'épreuve d'une perte réseau... Il reste désormais en test pendant le développement de SQMMonitor.
Il sera ensuite déposé dans le jardin d'un membre (éminent) de Astronamur... Pour examiner les impacts (imminents) du passage vers les LED !

Super tout ça, ça avance bien !

Parfois, cela recule... 

- nuit 1 : s'arrête sur une "exception camera", soit, j'avais un doute sur la connectique et il faut remplacer tous les composants (cable, camera, boitier) pour que cela daigne re-fonctionner

- nuit 2 : tout va bien jusque 4h32 du matin, quand : "exception camera" 

L'examen (à distance, même si le boitier n'est pas loin...) : c'est comme si la caméra avait été physiquement "enlevée" de la carte ! 

De facto : planté... Pourtant, la température interne (27° quasi constant) empêche largement toute humidité de s'installer et de toucher un connecteur... (En IR, le boitier irradie dans la nuit !)

Et si il y avait eu une interférence, d'autres composants l'aurait vu (stabilité courant : nickel)..
Donc : faudra tout démonter pour comprendre... 

Donc : version 2.1 
- pallie à toute "disparition virtuelle"
- continue à prendre les mesures (le SQM ne pose pas de problème) même la capture d'image est activée mais ne se prend pas...
- nouveau fichier "log" plus étendu
- extension des commandes FTP pour envoyer plus d'info sur la situation du boitier.
    
Les mesures se prennent et les synchronisations automatique fonctionnent, en tout cas... 
On a déjà 80% de l'objectif... 

On avance, mais avec des interrogations... Sur la fiabilité de certains composants, notamment ?

Un pas en arrière, deux pas en avant... 

Bon, la cause de la panne : facile... L'eau trouvant toujours son chemin quand il y a possibilité : 



Et deuxième caméra "out"... 

Bon, a noter : la "colle" des pistolets, c'est pas idéal. Tout démonté, tout arraché (trop facilement, d'ailleurs) et recommencé avec une colle de "contact". Après test sous la douche et en situation (merci la pluie) : plus une goutte, donc : on remonte... 

Oui, mais.. Je n'ai plus de caméra.. Donc : "review" software et adaptation vers la version 2.2, qui inclut :
- support de n'importe quelle camera USB compatible UVC (inclus dans le noyau Linux)
- des fonctions de contrôle améliorée (configuration, correction de bugs, stabilité)
- une fonction de contrôle mémoire (gestion caméra)
- ajout d'un outil de calibration de la mesure SQM (selon la qualité du transparent)
- la première partie d'un module de "remote control" (ex : si on veut que toutes les caméras du réseau s'activent pendant une période, pour une capture du ciel simultanée)
- la perte (temporaire) de l'annonation de l'image, qui demande une ré-écriture dédiée (pour s'adapter à chaque type de caméra) => pour la version 2.3

Une fois remonté... 


Y a plus qu'à... Avec deux jours de beau temps, cela devrait le faire... 

SQM Reader V2.3 (déjà, comme le temps passe...  )

Entre-temps, tout s'est planté... (court jus) => nouvelle carte, nouvelle SD, nouveau setup et compilations des 
librairies... Mais j'ai maintenant une "image" qui est proche de la version finale (2 jours de boulot, ouf.... )
- le programme peut désormais supporter les caméras de plusieurs types (propriétaire, USB générale (UVC), etc, remote...). Mais une constatation : le contrôle via USB et la qualité des "webcams" est très variable et le modèle "low cost" que j'avais en stock assez pitoyable en qualité...
Il faudra repasser à la "PiCamera" qui donne une qualité largement supérieure.
- standardisation (finale) des contenus et formats de fichiers enregistrés
- rajout de l'annotation des images issues de type "USB" 
- choix actuel du format d'image : jpeg... (quand on aura mieux comme caméra, on reverra)
- amélioration des fonctions de synchronisation avec le site de centralisation
- première version du contrôle à distance des paramètres de capture (encore expérimental)
- calibration des mesures SQM : ok (la vitre "atténue" la lumière de 0.1 mag/arsec², faussant la mesure en la rendant "meilleure" que la réalité). 
- synchronisation au lieu/heure internet disponible sur le WIFI
- de manière fréquente, les informations (état, adresse ip, status des détecteurs, log technique, etc...) sont envoyés sur le site de contrôle, ainsi que les données déjà disponibles.

Premier test / graphique actualisé toutes les heures 


On peut déjà dire deux choses, dans mon coin... 
1) c'est stable... 
2) pas trop mauvais... (NSB max = 20.73 mag/arcsec², moyenne (top 10) = 20.5)
3) peu d'influence Lunaire, à ce stade, vu la position du capteur...

Mais la qualité des images : pas terrible... Faudra y retravailler... 

Ca avance ça avance

Itération V2.4... 

Les idées, c'est fait pour être testées... 
Et puis : validées ou remises en question.
Et il est temps de mettre à plat les expériences acquises avec la version 6.0.

En gros : le boitier actuel montre des faiblesses sur la durée.
- est-ce gérable : certes, par une action délibérée sur le boitier, nécessitant actuellement de l'ouvrir ou de laisser un clavier/souris accessible. Mais ce n'est pas le but final.
- les problèmes détectés sont à plusieurs niveaux, mais en gros, la solution va se trouver dans un "repackaging" des éléments, dans lequel on revient à des fondamentaux mais aussi à des choix techniques à intégrer.

Fondamental :
- l'interaction entre composants proches est bien plus à prendre en compte que supposé...  
- il faut que le SQM (le composant le + fiable) soit "isolé" dans le boitier pour être efficace.   
- il ne faut pas négliger l'énergie nécessaire pour faire fonctionner optimalement les capteurs
- il ne faut pas négliger l'énergie nécessaire pour faire fonctionner carte "PC", WIFI et les capteurs ensemble... Ni les aspects thermiques générés. 
- le design du boitier (isolation, transparence, ventilation) est directement liés aux points précédents

Particulier:
- la connexion à distance et l'envoi des données automatique : parfait, tant en pratique qu'en fiabilité.
- le "remote control" : pratique... Mais on doit réfléchir à la sécurité. 
- la stabilité électrique et puissance nécessaire pour le WIFI : surprenant... Mais à prendre en compte
- la visibilité immédiate (ou "status") du boitier pose problème : Comment savoir si tout est en ordre ?
- la maintenance, avec la procédure ad-hoc (renvoi du boitier, démontage local, intervention sur place, etc...), doit être revue. 
- la qualité des images... Si elles ne sont pas impeccables (exposition, colorimétrie, résolution), elles sont inutiles => la qualité du capteur et la taille des images à chaque capture sont remises en question.  
- un capteur de nuage (testé en mode expérimental) est plus utile à ce stade du projet.

Conclusion : mieux vaut se focaliser sur les points "avec solution" immédiatement. 
et on verra pour le reste ensuite... 

Donc : le boitier va évoluer en une version "moins autonome"
- un boitier extérieur, avec sondes "passives" (humidité, SQM)
- une connexion de type USB (ou réseau) entre boitier et boitier de commande
- un boitier de commande avec écran de contrôle et alimentation individuelle
       
Et c'est parti pour la version 6.1... 

Qualité des images : un petit bestiaire... 

J'essaie d'entraîner un petit réseau (neuronal) pour "reconnaître" les conditions météo lors de la prise de mesure... Et indiquer un facteur de correction dans l'évaluation de la PL (diffusion, etc...)

Mais quand on a la qualité de données telle que je montre ci-dessus...
De gauche à droite, de haut en bas :
- exploitable
- passage au zénith du soleil... Mieux vaut ne pas prendre de photo, mais à déterminer soit sur base éphéméride, soit d'un luxmètre additionnel (le SQM est bloqué à 0, dans ce cas) et => courant...
- condition de nuit, mais pas d'info exploitable (manque sensibilité)
- exploitable, mais à "nettoyer" avant, car sinon : erreur d'apprentissage 
- conflit : si la précédente représente "un nuage", le réseau va enregistrer qu'une "ligne" dans l'image est une caractéristique marquante (dont déterminante) de "ce qu'est un nuage"... Et ici, il va indiquer "nuage", mais en fait : peut-être, ou pas... (OK, ici : couverture nuageuse totale, mais il faut prendre en compte les données temporelles pour le déterminer, ce qui rajoute de la complexité...)
- inexploitable : le ciel est bon, ou pas ? 

=> sans une image de très bonne qualité, la détermination "correcte" approche les 12%, ce qui est peu... 
On va donc y repenser... Si on a un "allsky" du ciel, par exemple...

Et pour la version 19, reconnaissance et identification des rapaces et des papillons

Sans vouloir lancer de polémique :  le but final de tout cela .... on essaye de mesurer on essaye de comparer et puis ??

But n° 1 : 
Pouvoir répondre, autrement que par des approximations peu fiables (car humaines), aux effets de la conversion "Sodium => LED 4000K" de l'ensemble du pays...  

La mesure ponctuelle "une fois faite" (ni celle "avant", d'ailleurs), ne vaut rien devant les organismes 
qui diront (et d'ailleurs à raison) que personne ne possède leurs appareils de mesure calibré.
Donc : "quoi qu'on l'ait mesuré, cela ne vaut rien car vous 'êtes pas des experts" (sic)... 

SAUF (et ils ont du l'admettre car c'est physiquement indéniable) si on évalue la différence entre deux mesures réalisées avec une correction identifiée...
Que l'on mesure X ou Y, puis X+d ou Y+d, c'est (d) qui est important et non discutable.

En Belgique, il y a que 4 appareils "ad-hoc" en service sur le territoire auprès des amateurs... 
Donc : pas un maillage suffisant. Et on ne maîtrise pas le planning de conversion vers les LED.
Il faut désormais observer dans la durée et centraliser les données...

Constatation : les amateurs concernés doivent actuellement mettre un matériel conséquent (ou ne pas oublier de la gérer)... Trop énergivore, peu adapté, pas de centralisation. j'essaie d'apporter une solution "low cost" à ce besoin... Et suis largement seul sur le créneau, en effet...   

But 2 : 
S'inscrire dans un projet international avec la publication de données de PL prise sur une longue durée (surtout maintenant). Il y a déjà plus de 50 stations de mesures actives au niveau Européen et Asiatique... Et zéro en Belgique... 

Et cela arrange fort ceux qui disent que : "la PL, cela ne dérange qu'une fraction d'amateurs du ciel, généralement dépassé par la technologie (les professionnels n'en ont pas besoin) et qui prônent de revenir au moyen-âge en terme d'éclairage urbain et de sécurité..." 

Mais il est vrai qu'en Belgique... Il est tellement plus facile de se plaindre plutôt que d'agir... 

Donc, à mon (modeste) stade... 
J'essaie d'agir et qui sait : d'émuler d'autres à faire pareils. Car il n'y aura de réponse (politique) que s'il y a des évidences... 
4 projets sont en cours sur le territoire mais ils concernent la biodiversité (domaine très spécifique) et on se bat sur l'aspect 2700K au lieu de 4000K (un autre sujet, touchant à la santé).
Pour ce qui est "avant / après", et impact réel (peut être positif, d'ailleurs, qui sait ?), aucune donnée actuelle ne permet une réelle comparaison contradictoire.

SQMMon(itor) V1.0 et le nouveau design du LPMD lancé en test...
Le boitier ne contient plus que le capteur et la caméra  
Liaison : via USB
En première version : 
- que SQM actif
- delay de mesure : 5min
- envoi des données toutes les heures vers le site

Mis en // avec un SQM avec Data logger (d'origine), enregistrant en "mémoire interne"

Voyons si cela "tient" la nuit et comment sont les données demain matin...
(et une carte Pi 4 en moins, suite aux essais de "stabilité"... 
Je suis revenu au PI 3, moins fragile...)

"Fin de sprint, il est temps de faire le review sur le delivery..."

Ok, c'est pour les "IT people"...
Ne vous en faites pas si vous ne voyez pas l'allusion... 




Ok, j'y suis... Le "MVP" (Minimal Viable Product) de LPMD est terminé...
J'ai passé un temps de fou pour le rendre "résiliant" et "autonome"... 
Bref : un vrai petit agent "IOT"  (Internet Of Thing), qui est la prochaine idée, d'ailleurs... 

De ce côté :
- il y a désormais deux boîtiers : le "boitier de lecture" , contenant les capteurs, et le boitier de contrôle indépendant. C'est la version la plus fiable, donc on y revient. La connexion entre les deux est de type USB (max 10m, ou avec un convertisseur RJ45/LAN si on veut plus loin...)
- il reste de la place dans le boitier capteur, ce qui permettra d'évoluer... 
- aucun réglage, à part un fichier d'installation une fois pour toute (par site concerné). Mettre le courant et c'est tout... Il devrait réagir automatiquement aux "problèmes courants" (perte de courant, perte de connectivité, perte de détection, etc...)    
- chaque boitier se voit affecté un user/password dédié pour l'envoi de ces données, de manière régulière, vers un site web dédié. Dans les fichiers envoyés se trouve un "log" technique donnant l'état de santé du système.
- chaque boitier porte un "nom" dédié, impliquant sa localisation et son rôle.
- les prises de mesures peuvent être ajustées selon chaque cas...
- A période fixe (ou en cas de problème), on obtient un "bloc d'informations" tel que :

Code:

...
Activity File Sync on
Start period : 2020_07_24 13:03:54
End period : 2020_07_24 14:40:07
number of SQM read : 384
number of read (over 17 ) : 0.0
max value : 0
Last config is
-location=LAB001
-calib=0.1
-unit=00004587
-baud=115200
-sqmport=/dev/ttyUSB0
-path=/home/astro/sqmmon/
-delay=0.25
Activity File Sync on
Start period : 2020_07_24 13:03:54
End period : 2020_07_24 14:41:07
number of SQM read : 388
....

J'ai créé un "tableau" qui met en comparaison les diverses solutions basée "Sky Quality Meter" (voir joint)
Il est temps de "jeter" les concepts réalisés sur papier...   

=> Julien... Il est temps pour Fernelmont de passer sous contrôle PL... 
 
 .

Ok quand tu veux Thierry suis rentré à la maison

OK, on va se synchroniser la semaine prochaine... 
Rem : Première analyse sur un "site" test durant 3 belles nuits de Juillet 2020...

Lieu : Station WELL01 (Wellin, Wallonie)...  
Période : de 00h30 à 04h30, 52 à 53 mesures/nuit, période de 3 nuits 

Min : 18,73 MPSAS
Max : 20,9 MPSAS
Moy : 20,7 MPSAS

Le moins que 'on puisse dire, c'est que c'est stable dans le coin... 
Et comme on n'a pas de statistiques sur d'autres lieux aux même heures en Belgique... 
=> est-ce bon, ou pas ? Pas d'éléments pouvant être argumentés à ce stade....

De l'idée au concept, puis au prototype et pour finir : la version finale... 

Voici la station "BEFERN001" (BElgium FERNelmont N°1) complètement montée, testée (sous la pluie) et opérationnelle...

 
L'ensemble "capteur" + "boitier" totalement autonome (une fois connecté à un réseau via WIFI ou cable)... 

Je m'attaque aux pages du site, qui permettront de visualiser les mesures.
Encore une petite modif des messages (cela sera la version 1.4 qui partira sur site...)
et on peut aller la déposer sur place... 

  Bon, si j'ai bien compris, il va être temps que je raccorde mon câble RJ45

Trois choses nécessaires :
- un emplacement dégagé (vue du ciel) avec un support pour le fixer (abri de jardin, mat, etc...)
- de l'électricité (soit 220V, soit 5V 2.5-3A)
- de la connectivité (soit LAN RJ45, soit un WIFI assez puissant que pour atteindre l'endroit)

Abri de jardin : OK (je t'enverrai quelques photos)
Electricité 220V : OK
Connectivité : en cours RJ45

Après quelques surprises de dernières minutes (sinon, cela ne serait pas amusant...)

Le premier LPMD est désormais installé et actif !



Même, pour s'en convaincre ; il suffit d'aller voir... 

http://lightpollution.beastro.be/php/lpmdstatus.php

Ok, je sais : c'est basique de basique et les droits d'accès sont à revoir... (j'y travaille ) 
Mais le contenu se met à jour automatiquement... 

Et cela devient la première station d'observation automatisée "dédiée" Pollution Lumineuse
pour la Belgique... Aux premières loges pour la future conversion LED !

Il faudrait que des petites soeurs arrivent rapidement, pour que l'on couvre les effets de la conversion 
avec des chiffres objectifs et incontestables... 

Du genre :
Start period       : 2020_08_17 22:59:52
End period         : 2020_08_18 04:00:04
Nbr read            : 61
Nbr read (>17)  : 61.0
Max value          : 20.24
Average (>17)   : 19.965901639344253

Explication :
- la capture la luminosité se fait toutes les 5 min
- la synchronisation des données se fait automatiquement toutes les heures... 
- je produis un "petit résumé" de la station dans un log (publié quand le buffer est plein)
- je garde évidemment toutes les mesures, mais je ne considère pour le résumé automatique que les mesures > à 17 mag/arcsec² (supposé être la nuit)
- donc, à ce stade (4h du matin)   

Sur 61 mesures effectives, on a 19.96 mag/arcsec² de moyenne et un maximum de 20.24 largement utilisable pour l'astro !

Quand on aura plusieurs capteurs, on pourra (enfin) obtenir une mesure réaliste
de la PL en Belgique... Cela n'a l'air de rien, mais sinon : on n'a que la bonne volonté et
la capture manuelle des données... (avec toutes les incertitudes...)

C'est pas vrai... 

Le site et le point d'accès est là depuis moins de 24h, et on est déjà "scanné" par des sites distants (russes et chinois !) 

Et ce n'est pas avec ce que l'on va trouver dedans que l'on va briser des codes nucléaires !!!


Bon, mieux vaut s'occuper de tous les aspects de sécurité directement... 
Faudra modifier un peu de code pour (déjà) limiter les infos... 
Snif...  

Arf purée.... je savais bien que mon abris de jardin était top, mais au point d'intéresser les russes et les chinois, je vais devoir réhausser ma clôture

Tiens quand on va sur le lien du site on voit bien les 2 logfiles mais ils ne sont pas accessibles, je ne sais pas si c'est volontaire.

Je prépare un draft de réponse à la commune (car on en est resté au stade "Que AstroNamur fasse des recommandations constructives" et je n'ai pas envie qu'on passe pour les râleurs qui n'ont rien proposé (même si le projet village étoilé était déjà un recueil de recommandations constructives).

C'est sympa le "guide des valeurs" en début de page, ça aide à comprendre l'échelle pour les non-initiés

Je pensais aussi, je bosse sur la documentation du projet (après tout, je suis dans les temps )... 
J'ai simplement encore quelques problèmes de présentations (CSS) à gérer... 

La dernière version me semble utilisable (faudra améliorer cela dans le futur, quand on aura plusieurs stations...)



Ainsi, actuellement... Le meilleur ciel que tu aies eu est de l'ordre de 20 (pendant une période assez courte de la nuit), et le score moyen est (hélas) cohérent avec notre modèle de PL, car s'il n'y avait pas d'éclairage (ou de meilleure qualité), tu devrais être dans la catégorie 19-21, et non pas 18-20. 

On verra l'évolution avec les éclairages... 

Rem : faudra rajouter une définition pour NELM... Qui, en soit, est plus explicite pour le visuel... 
Maintenant, il faudrait rajouter des points pour créer une vue globale...

ca me tente aussi d'en avoir un chez moi. 

Pour l'installation, j'ai pas mal de lumière, mais on peu trouver un coin a l'ombre. Faut il un ciel totalement dégagé? Ou un arbre ou deux ne gène pas? 

A+ndy

Le ciel n'a pas été fort dégagé ces dernières nuits, je ne sais pas si ça joue...

@Andy : le capteur est orienté verticalement et capte une zone de 20° de rayon...
Donc : les arbres et autres ne gênent pas...   

Je suis dans les plans et descriptions. A part la commande des éléments nécessaires,
cela ne prend que 2-3 heures pour un bricoleur... Tout compris...

J'ai un jardin sans éclairage public ni led s'il faut. Et je veux bien en mettre un chez moi

Je prends note... 

Il faudra regarder vos localisations et vos positions sur le plan de migrations de LED.
Selon le cas, cela déterminera l'urgence... 

Perso, je vais en mettre un dans un endroit de "référence PL" (chez moi, niv 9, difficile de faire pire !)...   

=> faudrait optimiser les commandes et négocier le prix... 

Petit status LPMD V6.1... (ben oui, le temps passe )

Petit post pour indiquer la situation et l'évolution du projet... 
Il faut dire que cela m'a généré du travail... 

"HW Crisis"
A peine deux semaines après son installation... Problème hardware "sévère" : on perd des données !
Un problème (hélas bien connu) dans le monde Raspberry PI : l'instabilité du fonctionnement des cartes SD... Après un temps d'exploitation, les cartes SD (qui sont le type de stockage principal de ce type de machine) se détériorent et l'écriture des fichiers devient aléatoire...   Un peu gênant pour un capteur censé fonctionner 24/24 et 7/7 !

Deux solutions :
- soit réparer (changer de carte SD et rajouter une unité de stockage externe pour les données)
- soit... Se creuser la tête ! (Car même si on est "proche", devoir accéder physiquement était en soi un échec....)

Donc, j'ai travaillé sur le problème "à distance"... De la même manière qu'un programmeur qui doit "réparer" une sonde spatiale en cours de voyage, en exploitant ce qui reste opérationnel... Et après des jours d'essais (en ne perdant pas trop de captures), je suis arrivé à quelque chose d'opérationnel. 

"6.1 evolution"
Le système fonctionne désormais avec un code à 80% réécrit, mais surtout : optimisé pour que les I/O s'effectuent correctement, même sur un support de stockage déficient ! (je vous passe les détails techniques, mais c'est fort intéressant...). Et depuis cette mise à jour, les données ont été capturées correctement... Même sans avoir changé de carte !    
    
Tant que j'y étais, j'ai donc développé la deuxième partie prévue, avec l'ajout de calcul astronomique dans chaque capture. J'intègre désormais (je conseille le livre de J. Meeus, la "bible" dans ce domaine) différentes valeurs issues des éphémérides pour la journée concernée. 

A savoir : 
http://lightpollution.beastro.be/php/lpmdV6desc.php

For each capture :
- day & night (sunrise to sunset) durations
- sunrise, civil & astronomical twilights, sunset computations
- Sun and Moon maximum elevation (in decimal degrees)
- A global Moon event (around 4 computed events) is also provided, like 'Between New and First quarter' or 'Full Moon'
are provided

Tous les fichiers  issus de la version 6.0 ont désormais été convertis en V6.1...
Je dois encore "compiler" deux trois fichiers et tout sera en ordre... 

Et des statistiques (encore expérimentales) sont extraites des données et affichées sur le site...
Il va falloir maintenant passer du temps à valider tout cela...   

Ceux que cela intéresse...

http://lightpollution.beastro.be/php/lpmdstatus.php
et 
http://lightpollution.beastro.be/php/lpmdstatus_BEFERN01.php

La prochaine phase sera l'intégration de données météo... (un autre défi)
Et le deuxième LPMD est en construction.

Donc : cela avance... 

Super Thierry,

Thierry.

Pour ce genre de problème, j'ai une solution simple et efficace pour toi... C'est la méthode que j'utilise pour ne pas tuer mes SD trop rapidement.

Je crée une partition en mémoire et j'écris les données dans la mémoire et non sur la SD. Ensuite toutes les heures, j'écris mes données dans les fichiers et je clean la partition en mémoire.

Comme çà, pratiquement plus d'IO.

En effet... J'ai essayé plusieurs solutions... (surtout "on the flight", sans perdre les infos)
- Celle que tu décris a été implémentée pendant une période (dès que j'ai détecté le problème)
- Ensuite, j'ai réutilisé les mécanismes de "logging" à mon avantage. Il s'est avéré que la deuxième méthode offre des avantages indéniables...    

En finale, j'ai découpé les traitements en deux services, un pour la capture, l'autre pour l'enrichissement (calculs complexes) et la publication. Mais j'ai toujours un problème qui reste,
(cela tourne, mais je ne trouve pas la solution élégante)... 
=> on en parlera sur le Discord...

Petite news suite à la mise en production de la dernière version du site des mesures LPMD...

En trois points :
- on sort de la phase "artisanale" rapidement développée (avec des "fichiers") et les problèmes de communications (je hais Proximus et ses "updates") m'ont littéralement poussé dans le dos pour passer à la technologie définitive...

- OK, on est désormais avec les ressources nécessaires : une base de donnée centralisée, des requêtes ciblées pour l'extraction/analyse des captures et une méthode "standard" pour l'alimenter en temps réel.    

- La nouvelle interface est fonctionnelle, le LPMD est passé à la version 2.6 du programme et déjà plus de 32000 mesures (sur 94 jours) sont accessibles. Avec tout ce que cet EAB a "subi" pour la mise au point, je prévois une "remise" à neuf prochainement (voir plus bas).

Cela permet des études du genre :
Analyse des données avec l'influence de la lune

Pour les curieux... je considère
a) la valeur moyenne par jour des mesures correspondant à la "nuit" (>= 13 mag/arcsec²)
b) le pourcentage de phase lunaire, converti en une valeur de mag/arcsec² (17 = nouvelle lune, 22 = pleine lune)
c) la courbe de tendance de la moyenne des mesures...

Cela permet de visualiser rapidement, quelques que soient les conditions météos, l'influence lunaire sur la clarté du ciel.

Rien de neuf, mais cela confirme les calculs effectués sur les mesures.  
Mais aussi une tendance à l'augmentation de la brillance du ciel alors que les nuits s'allongent... 

Et que sur 94 jours, deux soirées furent réellement "bonnes" pour l'astro, par exemple...

Evidemment, tout dépend du nombre de mesures prises pendant la période concernée (il y a eu des problèmes, donc, des "trous")

En enlevant toutes les dates où la Lune est supérieure à 50% et les dates où le nombre de mesures ne sont pas assez significatives, le graphique évolue...



Analyse avec lune max 50% et > 50 mesures/nuit

Et on distingue une "valeur moyenne" autour de 19 mag/arcsec² sur le site concerné.
Si on relie cela aux conditions météo, cela ouvre un camp d'analyse intéressant après que tout l'éclairage communal sera converti aux LED.

Pour les curieux du sujet, voir 

http://lightpollution.beastro.be/lpmd/

Rem : il y a certainement encore quelques bugs, si vous détectez quelque chose, faites signe... Merci.

Mes deux prochaines cibles :

- la mise en route de BEWELL01 (un nouveau point de capture), avec une version "optimisée" du système (remise à niveau du EAB, changement du contrôle de mise à jour, reboot quotidien pour pallier à Proximus...)
- une mise à jour de BEFERN01 ensuite avec la version "la plus récente"  
- l'intégration (avec calculs rajoutés) des mesures capturées dans d'autres endroits de la planète dans une autre table... (j'ai plus de 16M de records à convertir... ))

Et maintenant, trouver d'autres partenaires (motivés sur la PL) en Wallonie et Flandre, afin de réduire le maillage...

Commentaire : quand on est "seul" à se battre, cela fatigue, par moment...

Mais en gros, c'est ce que les GRD et politiques de tous poils désirent : que l'on baisse les bras et
qu'on se taise... 

Donc, je continue...    

BEWELL, ça le fait comme nom c'est limite un slogan "bien-être"

Super boulot en tout cas Thierry !