boudha

la proximité d'éléments rayonnants est vraiment nuisibles à la mesures de la températures, c'est pourquoi la norme prévoit d'installer une sonde de température au dessus d'un sol engazonné... A mon avis, tant qu'elle sera implantée sur ton toit, tu auras en permanence des erreurs. La ventilation est également un élément prépondérant. vérifie sur les relevés dont tu parles si le vent n'a pas molli au moment où tu constates les surchauffes.

je sais pas, mais ça coûte pas grand chose d'essayer...

Perso ma station fonctionne au poil et qqsoit sa position dans la maison, proche d'une fenêtre ou pas, branchée ou non... En général c'est plutôt la réception des capteurs qui décroche lorsque la position ne convient pas. Pour savoir si le pb vient de ta station ou de son emplacement, tu peux tout simplement dé-règler l'heure et mettre en fonction l'horloge radio pilotée. Puis tu sors la station de la maison et tu patientes environ 1 à 2h. Tu verras ainsi si la synchronisation se fait ou non... Tu perdras les infos sur ton site pendant 2h, mais tu seras fixé! Également, tu peux sélectionner 2 émetteurs, peut être que le second conviendrait mieux?

il ne reste plus qu'à te souhaiter bonne chance

Il faut supprimer les précipitations inexactes dans le log xnet, ensuite mettre les stas de GW à jour à compter de la date où l'erreur s'est produite. Dans la config de GW, il ne faut conserver que les précipitations relatives pour l'édition des graphs, ça évite pas mal d'erreurs et Gw fait lui même les calculs de précipitations sur 1h et sur 24h. Il en est de même pour le windchill, qui sera alors calculé de manière plus précise

En fait la borne positive des piles lithium est un tout petit peu plus courte que celle des alcalines. Or la thermo/hygro d'OS et en particulier le logement des piles bloque celles-ci et nuit à la connexion de la polarité positive... Au sujet des température froides de la nuit, mon record est proche de -10°C l'an passé, et mes alcalines ont largement tenu le coup (+ de 2ans de fonctionnement, sans que la sonde ne soit reliée au panneau solaire...).

Aucun soucis /emoticons/wink@2x.png 2x" width="20" height="20"> D'autant que comme JuTs le précise, il utilise des piles Lithium, sujettes à mauvaises connexions électriques (en tout cas avec les sondes thermo). Du coup, la solution que tu proposais mérite d'être tentée: ne connaissant pas bien la réelle utilisation de la batterie du capteur solaire, on peut imaginer qu'elle alimente pendant un temps limité la sonde de manière autonome, puis n'arrive plus à étaler et provoque les déconnexions (si tant est que les piles ne fassent pas bien contact, ce qui est courant avec les lithium). Personnellement, je commencerais par là... Également, on peut te conseiller de placer la base de la station à l'extérieur, et de vérifier qu'il y a ou non les même pb (tu parlais notamment d'une cabane de jardin, elle peut servir d'abri pour ta base...). Le but est de mettre en évidence une panne de ta station, ce qui sera le cas si les mêmes déconnexions sont constatées. Si en revanche il n'y a aucun pb, on pourra alors penser qu'il y a un simple pb de "propagation" (perturbation ou autre), et il faudra trouver un autre emplacement. Une simple fenêtre peut être source de perturbation, de part les matériaux dont elle est constituée...

Attention de ne pas tout mélanger... Si on a déjà conseillé de placer un petit morceau de papier alu entre les piles (lithium) et les contacts de la sonde, c'est pour remédier à un pb "électrique", mais en aucun cas de transmission (c'est bien à ça que tu fais allusion Orage99?). @ JuTs: - Comment est alimentée ta sonde: panneau solaire, piles alcalines, lithium, etc... - As tu vérifié le branchement de la batterie du panneau solaire? - A quels moments apparaissent les déconnexions? - A quelle distance de la base se situent les capteurs? - As tu tenté de placer la base à l'extérieur de ta maison, en champs libre?

Constates tu des différences de "réactivité" ou de précision dans tes mesures entre tes 2 sondes thermo?

GW aussi, sans aucun pb...

Accessoirement, l'extension .csv ne sert à rien... tu enregistres sous .txt, c'est aussi simple, de plus à l'ouverture tu ne risques pas d'utiliser excel (qui modifie le contenu). Pour pouvoir visualiser les graphs correspondants, tu devras tout de même ajouter tes nouveaux logs dans les sources de GW. Un petit conseil: moins les fichiers sources sont nombreux et volumineux, plus GW se lance et se rafraichit rapidement...

Fais l'expérience toi même et tu verras facilement ce dont je parles avec Xnet, la mise à jour des rafales est faite avec un pas aléatoire comme je te l'ai déjà expliqué. En ce qui concerne le vent moyen, c'est une vitesse calculée sur 1 min, et en réalité sur la minute précédente, ce qui explique que l'expérience d'Asperatus donne ce résultat. Concernant le calcul d'une vitesse qqsoit, c'est forcément le rapport d'un déplacement sur un temps donné. Plus le temps est court, et plus on sera capable de "discriminer" un éloignement par rapport à la moyenne. Par exemple pour une vitesse moyenne de 30kmh, il peut y avoir une évolution des vitesses "instantanées" (qui reste une notion théorique...) entre 25 et 35 kmh. Ces évolutions ne seront visibles qu'en effectuant le plus de mesures possibles sur un temps données, ce qui revient à diminuer le pas de mesure. En météo, on considère souvent qu'une rafale ne dure que 2 à 3 sec, d'où certainement le choix de Davis d'effectuer une mesure toutes les 2.5 sec. Or dans une même rafale de 3 sec, la vitesse du vent n'est pas "stable", et les anémos ultrasoniques notamment sont capables de percevoir ces évolutions dans la rafale elle-même (plusieurs dizaines de mesures par seconde...). Pour la wmr200, comme tu le dis très justement, lorsque le pas de mesure est long (>20sec) la mesure n'a plus rien à voir avec une rafale au sens météo du terme et c'est dans ce cas un "abus de langage"... Toujours est il qu'une rafale "noyée" au milieu d'autres rafales n'a que peu d'importance, même si elle n'est pas mesurée la prochaine le sera certainement... Egalement en meteo on parle généralement de vent moyen plus que de rafale, celle ci n'a bien souvent qu'un aspect "spectaculaire" dans la tête des non-initiés...

En fait l'anémo comptabilise un nombre de tour sur un temps donné, ce qui revient à une moyenne. Plus ce temps est long (je me répète, certaines mesures sont effectuées sur 50sec), et plus cette vitesse appelée (maladroitement dans ce cas) "rafale" sera proche de la vitesse moyenne sur la minute (normalisée). En revanche, lorsque l'intervalle tombe à environ 2sec, les deux vitesses ne sont plus du tout similaires, et on parle bien de rafale. Pour répondre précisément à ta question, si l'intervalle de mesure est de 10sec, la vitesse sera mesurée "pendant" 10sec, ce ne sera donc pas la vitesse max sur les 10sec, mais bien une vitesse moyenne sur 10sec. Toutes les stations ou presque fonctionnent ainsi, avec des pas de mesures d'environ 2.5 sec pour les Davis, c'est pourquoi elles mesurent de "vraies" rafales. Très peu de stations font évoluer le pas de mesure comme le fait la WMR200, qui en moyenne effectue 4 à 5 mesures par minutes. En réalité certaines minutes comportent jusqu'à 15 mesures et d'autres seulement 2. L'intérêt est certainement de manquer des rafales certaines minutes pour mieux les mesurer la minute suivante, tout en conservant un nombre de transmissions limitées (économie de piles??). Au bilan après + de 2ans d'utilisation, les rafales max mesurées par ma station (sur de nombreuses comparaisons) sont très proches de celles mesurées par une station pro installée près de chez moi...

Non, le pas de mesure n'est pas de 14s, il est variable, de 2 à 45sec environ... Réponse apportée : la valeur max des rafales sur la dernière minute est enregistrée uniquement si la console est reliée à l'ordinateur avec Xnet. Sinon, c'est la valeur de la dernière rafale enregistrée. Avec Xnet, c'est bien la rafale max de la dernière minute qui est conservée, sans Xnet c'est la valeur de la rafale affichée à la minute ronde (+00sec) qui est mémorisée.

Pas seulement... Pour revenir à ton pb, tes données sont définitivement perdues. Ce qui se passe de temps à autre avec certains datalogger: Des données, bien que transférées (et donc théoriquement effacées de la mémoire), restent dans le datlogger, et lors d'un transfert ultérieur repassent par Xnet. Or Xnet empêche que des données plus anciennes que la dernière ligne du log soient enregistrées et les supprime (message d'erreur). Ces données "persistantes" sont aussi appelées "fantômes" et Xnet a justement été programmé pour les éliminer. En fait ce sont certainement les bonnes mesures mais avec une date erronée, et pour éviter tout conflit entre 2 dates similaires mais des mesures différentes elles sont supprimées. Pour éviter ce pb il faut faire des transferts réguliers et systématiquement effacer manuellement le datalogger!

D'abord 2 choses à ne pas confondre: la mémoire de max et le datalogger... La rafale maximale est enregistrée dans une mémoire spécifique et indépendante du datalogger. Une rafale supérieure écrase et remplace cette dernière. Le datalogger ne travaille que lorsque la station n'est pas connectée à un pc (via xnet ou w200 par ex). En fonction du pas d'enregistrement, c'est la valeur à la minute ronde (+00sec) qui est enregistrée, il en est de même pour les autres capteurs... C'est le cas le plus défavorable, car on risque fort de louper pas mal de rafales, le vent moyen quant à lui sera cohérent. En revanche, lorsque la station est connectée à un pc, plus rien ne s'enregistre dans le datalogger, tout est inscrit dans le log par le logiciel utilisé. Xnet conserve la plus forte rafale sur la minute, je crois me souvenir que w200 en fait autant. Cette rafale, contrairement à ce qui est écrit dans la notice, n'est pas mesurée toutes les 14sec, mais avec un pas aléatoire, variant de 2 à 45sec. A ce jour, je n'ai toujours pas d'explication sur une éventuelle "logique" liée à la vitesse du vent elle même. Je pense donc que pour éviter de louper des rafales à cause d'une fréquence d'enregistrement trop faible tout en économisant la vie des piles(?) le capteur transmet de manière "pseudo-aléatoire". En observant la station sur un temps assez long (environ 30 min), on constate en moyenne 4 à 5 transmissions par minute ( soit environ 1 / 14sec..), mais parfois beaucoup plus et d'autre beaucoup moins! Je pense que de cette façon, lorsque le vent est fort on laisse passer quelques rafales certaines minutes, puis on accélère le pas de mesure sur la suivante. De cette manière peu d'erreur sur la valeur max des rafales, tout en ne les mesurant pas toutes ... C'est un peu "capilo-tracté" mais c'est la seule explication "rationnelle" que j'y vois. Au bilan depuis plus de 2ans d'utilisation on observe des valeurs très proches (et cohérentes) de stations pro. Encore une fois, je suis persuadé que l'environnement est bien plus important que le pas de calcul de la station, le meilleur anémo mal implanté ne donnera jamais de mesures cohérentes, bien qu'au final ce soit le plus important...

C'est en tout cas ce qui est écrit... Je possède depuis ans une WMR200, je peux te garantir que le pas de mesure n'est pas de 14s, il n'est d'ailleurs pas figé. En observant la station, on constate un rafraichissement des valeurs entre 2s et 45s (en live)... On n'a jusqu'à présent jamais réussi à déterminer une quelconque logique là dedans, pas même une relation avec les vitesses de vent. Ce que j'ai pu constater en revanche c'est que les rafales max mesurées par la ma station sont généralement très proches de celles des stations pros, et souvent même plus proches que celles de station Davis (VP et autres) installées dans un environnement "non optimal". Ce qui est primordial, plus que le modèle de station et son pas de calcul, c'est (selon moi) l'emplacement de l'anémo, qui aura beaucoup plus d'influence sur les mesures que toute autre considération... La meilleure des stations, mal implantée, aura des résultats aussi mauvais (voire pires) qu'une station familiale bien installée!

J'ajouterais simplement qu'il faut que le logiciel Xnet soit coupé avant d'ouvrir et modifier le log...

Le heatindex comme le windchill ne sont qu'un "ressenti" par le corps humain de la température, en fonction de la tempé effective et d' éléments extérieurs ( humidité ou vent). En dessous de 25/30° l'humidité n'a que très peu d'influence sur le "ressenti" par le corps. De même pour le windchill, il n'est généralement calculé qu'en dessous de 5/10° avec un mini de 5kmh de vent. Le calcul peut être effectué sur une plage bien plus importante, mais n'est que très peu représentatif du sentiment éprouvé par le corps humain...

Si pour une raison ou une autre les données ne se sont pas inscrites dans le log, GW relie les dernières mesures valides avec le temps réel. Ce qui pourrait expliquer que les tracés soient plats... En revanche il faut déterminer pourquoi les données n'ont pas été inscrites afin que le pb ne réapparaisse pas. Première piste: fais tu un effacement manuel de ton datalogger après chaque transfert?

Ce genre de commentaire suscitera certainement pas mal de commentaires... Je préfère dire que nous sommes nombreux à en être satisfaits!

Pour t'aider dans ton choix, jette un oeil ici... Il faut savoir ce que tu comptes faire de ta station, ce que tu souhaites mesurer, avec quelle précision, etc... De plus, la meilleure des stations installée dans un endroit mal adaptée n'aura qu'un résultat médiocre. Le meilleur des emplacements est un endroit dégagé de tout obstacle (mur, haie, arbre, etc...), exposé au soleil, avec un sol engazonné. Il faut aussi savoir si tu souhaites connecter ta station à un pc, et si tu souhaites qu'en ton absence les mesures soient enregistrées dans la station afin d'être exploitées plus tard.

Ce qui est sûr, c'est qu'en observant la console, les précipitations ne sont pas identiques à chaque basculement d'auget. En fait 2 basculements correspondent à 2,1mm décomposés en 1,1 puis 1mm. Xnet quant à lui comptabilise 1,016mm à chaque basculement, j'imagine qu'il s'agit de la conversion de l'unité (anglo-saxonne?) dans laquelle sont enregistrées les précipitations directement dans le datalogger, et qui ressort donc dans les trames. Il y aurait donc une différence de mesure après plusieurs basculements, pourtant Xnet ne fait que décoder les trames du datalogger (donc mesurées par la station...). Il se peut donc que la station après un certain nombre de basculements régularise la situation en ne mémorisant plus 1,016mm mais 1,3 ou 1,4mm (suivant le moment où interviendrait cette régularisation). Par exemple pour 10 basculements la station affiche (toujours) 10,5mm. Xnet en déchiffrerait normalement 10,16 (c'est ce qui apparaît dans les trames). La différence est donc d'environ 0,3mm. Il se pourrait donc qu'au 10ème basculement la station mémorise 1,4mm (régularisation), ce que tu constates alors dans tes graphs. Cette régularisation n'étant pas totalement exacte, il se pourrait que la station en tienne de nouveau compte pour sa prochaine régularisation qui interviendrait alors après 8 ou 9 basculements (au lieu des 10 précédents), ce qui pour le coup expliquerait que cette régularisation n'intervienne pas toujours après le même nombre de basculements (pas régulière)... Ce n'est en aucun cas une certitude, mais juste l'explication que j'avais trouvée après m'être moi-même posé la question...

Je ne connais pas le bug lié au changement d'horaire, mais en principe tu ne devrais pas rencontrer de pb particulier. Ce fameux changement d'horaire ne crée pas de données fantômes, mais recrée une tranche horaire déjà existante qu' Xnet supprimera (transparent donc pour l'utilisateur). Il ne faut absolument pas effacer le datalogger, mais trouver une solution pour le vider, sinon toutes les données seront perdues!

Rien à voir avec Xnet ou presque! Comme je te l'ai dit, ce changement d'horaire a artificiellement créé une seconde tranche horaire entre 2h et 3h du matin, qui n'existe que virtuellement dès lors qu'on travaille en heure locale. Ce pb n'existe pas si tu utilises l' UTC... Les pros travaillent comme ça dans bien des domaines. De plus, les données fantômes n'existent que dans le datalogger de ta station, xnet fait ce pour quoi il a été programmé: supprimer ces données fantômes. Sans vouloir en rajouter, il est plus facile de vider le datalogger régulièrement que de modifier un logiciel qui de plus fonctionne impec /emoticons/wink@2x.png 2x" width="20" height="20">