Problème de connection d'horloge RTC

Bonjour 68tjs

Ma remarque à Kammil est basée sur mon expérience du bus i2C qui me dit que si

Le bus fonctionne et que SDA et SCL ne peuvent en aucun cas inversés comme tu sembles le préconiser et te "cacher" derrière des décennies d'expériences ne va pas te rendre plus convaincant à mes yeux.
Je persiste à dire que scanner le bus n'était pas utile.

C'est curieux que sur ce forum, il est impossible de "contrer" l'avis d'un aidant "récurant" sans se faire allumer!, tout le monde peut se tromper!!

Cordialement
jpbbricole

@fpaude dit dans son 1er message
"Erreur de communication" et deux lignes plus bas nous dit que l'horloge compte (comment il a vérifié?)
Ca nécessite pour le moins une clarification!

Bonjour Kammil

Oui, certainement.

Cordialement
jpbbricole

Ne confond pas tout.
Tu as le droit d'avoir et d'exposer une opinion divergente .
Par contre, dire qu'une vérification est inutile là je dis non, et je dis non aussi par expérience.
Le nombre de renseignements incomplets ou faux est trop importants.

On ne peut pas demander à un débutant d'être précis comme un vieux de la vieille, il faut lui laisser le temps pour apprendre.
Mais quand quelqu'un demande des vérifications ou des précisions même si elles paraissent bizarre, c'est que le quelqu'un soupçonne une piste ou une "couillonnade" donc on ne dit pas au demandeur : ne fait pas cela ne sert à rien.

C'est différent que d'avoir des idées différentes sur des solutions techniques.

Quand tu dis que tu préfères une bibliothèque antirebond à un condensateur, je ne dis pas que tu n'as pas le droit de le dire.
Je dis juste que les deux méthodes doivent être exposées honnêtement et je ne dis pas qu'il faut impérativement utiliser un condensateur même si j'en suis convaincu.

Quand j'ai débuté en langage C en 1987, j'étais le seul à pratiquer ce langage dans la boîte, et j'étais nouveau dans l'entreprise. Autant dire un noob, mais les développeurs assembleur de l'équipe trouvaient que j'avançais bien plus vite qu'eux. Donc j'ai vite gagné mes galons de gourou, et il m'ont confié l'écriture de leur OS.

6 mois avant de partir en retraite j'ai intégré une équipe de vrais gourous très poilus sur un projet de haut niveau en PYTHON sur processeur de mobile SAMSUNG.
Qu'est ce qui les intéressait chez moi ? mon expertise dans le monde des lecteurs de cartes bancaires, rien de plus.
Par contre question codage et méthodes je repartais de ZÉRO ou presque. A 6 mois de la retraite ça fait rigoler. J'ai accepté en sachant que j'allais en baver comme jamais dans ma vie.
J'ai appris quelques petites choses essentielles durant ma carrière :

  • l'humilité. On peut être un noob quelque soit son niveau
  • travailler en équipe, pratiquer le consensus
  • en cas de problème, toujours douter de son propre code, pas de celui des autres
  • tester, re-tester, et tester encore

Je ne m'appelle ni Linus Torvalds, ni Richard Stallman, et je n'atteindrai jamais leur niveau.

Bonjour hbachetti

De ce côté là, je suis entièreement d'accord avec toi!

Cordialement
jpbbricole

Quel exemple SetTime ?
Quelle librairie ?
Quelle exemple de librairie connue affiche "Erreur de communication", en français ?

Quand une question aussi pauvrement documentée tombe sur le forum, je ne répons pas, je passe mon chemin.
Je vous invite à faire de même.

Bonsoir,
Je ne pensais pas avoir une "déclaration d'hostilités "entre personnes compétentes.
Veuillez m'en excuser!
Je me suis certainement très mal exprimer face à des personnes qui pratiquent depuis longtemps et dont c'est également le métier.
Si vous me donner un bout de bois, je vous montrerais comment en faire un simple tasseau ou pourquoi pas une sculpture.
J'ai aussi la passion de la spéléologie, alors me parler de sécurité, d'évolution sur corde avec beaucoup de vide sous les pieds, je suis très à l'aise pendu sur un fil, mais dans le domaine de l'Arduino, je suis novice....
En tant que spéléologue, nous (le club) avons entrepris une étude scientifique sur les variations de niveaux d'eau d'un lac situé à 80 m sous terre.
Des mesures en surface sous forme de station météo est important pour mesurer le temps de réponse entre la pluie extérieure et la variation du niveau du lac est le sujet de cette étude.
Une horloge est donc souhaitable. Mais malgré beaucoup d'essais divers, rien n'est concluant.
Des sondes spécialisées seront installées dans le lac pour les variations de pression, T°

Nous avons à disposition une carte Méga2560 avec un shield grove pour connecter le pluvio, l'anémo, la girouette, la T° , pression et humidité. A cela, vient s'ajouter une carte SD pour enregistrer toutes ces mesures. l'alimentation sera solaire car loin de la civilisation (Si, si, c'est possible en France)
Tous ces modules fonctionnent correctement séparément actuellement. Il faudra assembler tout ce petit monde dans un seul croquis par la suite....
Le module RTC nous pose effectivement un soucis, car en utilisant simplement les très diverses librairies ou croquis trouvées, rien ne fonctionne vraiment.
Nous avons scanné une carte UNO avec les ports 4 et 5 qui semblent correctement branchés et la Méga sur I2C qui est également correct. Les résultats sont identiques.
Avec :
Time_RTCSet.pde, l'horloge défile correctement, mais la date est mauvaise malgré la mise à jour du Default_Time
Time RTCLogger.ino,rien ne s'affiche dans l'IDE
DS RTC Read Test m'indique : 1307 read error! Please check the circuitry
D'autres exemples me permettent de choisir la date et l'heure, mais rien n'est concluant, sans plus.
Nous pensons que cela fonctionne (presque) soit sur UNO ou Méga2560, mais il y a des paramètres qui nous échappent complètement.
La version d'Aduino est 1.8.5
L'horloge provient de: Module Grove Horloge temps réel 102020083 pour arduino et Raspberry
Nous recherchons simplement une aide pour une étude scientifique totalement bénévole réalisée par des bénévoles passionnés dans la spéléo et son aspect scientifique au même titre que vos connaissances en programmation Arduino.
Merci de ne pas passer votre chemin.
Merci d'avance, et nous restons à votre écoute pour affiner notre démarche.
Cordialement

J'en conclus que "1307 read error! Please check the circuitry" est équivalent à "Erreur de communication". Une sacrée piste ...

Time_RTCSet.pde : une recherche donne Time/TimeRTCSet.ino at master · PaulStoffregen/Time · GitHub

Time RTCLogger.ino : Time/TimeRTCLog.ino at master · PaulStoffregen/Time · GitHub

DS RTC Read Test : ? ? ? ? ? ?

Je ne sais pas si certains se rendent bien compte des efforts qu'il faut faire parfois pour aider des demandeurs qui ne sont même pas foutus de fournir un lien sur les fichiers dont ils parlent.

Bonjour fpaude

Surtout pas!
Magnifique projet, mais il va falloir "se crocher" pour tout faire fonctionner ensemble.
Je fais aussi de la spéléo, oui, oui!, :rofl: quand je cherche quelque chose dans mon b....l, pardon matériel, et j'ai trouvé un datalogger qui a un ds1307, je vais pouvoir te guider.
Tout d'abord, si tu as d'autres périphériques i2C connectés, déconnectes les. Fait une liste avec des liens de tout ce que tu veux connecter à ton système
En suite, pour la RCT la bibliothèque, ici, dans les exemples il y a SetTime.ino, pour mettre l'horloge à l'heure. Déconnecte ta RTC du système, sort, la pile bouton de son logement, après quelques instants, remets la puis reconnectes le module , puis charges SetTime.ino avec la console à 9600, tu devrait voire la mise à l'heure.
!!! Attention à ne pas laisser le sketch SetTime.ino dans ton Arduino, charges immédiatement ReadTest.ino par exemple, en effet si ce sketch reste à chaque redémarrage de ton Arduino, il reprendra l'heure du téléchargement du sketch.
Ensuite charges l'autre exemple ReadTest.ino. pour voire le fonctionnement de ta RTC.

Donnes moi des nouvelles.

Cordialement
jpbbricole

Vu le projet et sans doute une installation dans la durée, une DS3231 serait plus appropriée.

Bonjour J-M-L

Je connais "l'imprécision" de la DS1302 mais pas la précision DS1307, où trouver l'info?

Cordialement
jpbbricole

Tout à fait mais il faut dire pourquoi.
Le module DS1307 subit les dérives du quartz externe et avec un module à 1 € il ne faut pas espérer un quartz de compétition.
La DS3231 n'utilise pas de quartz externe mais un système interne dans la puce (MEMS) qui est compensé en température. L'ensemble est beaucoup plus précis et dérivera infiniment moins.

Pour des utilisations sur le long terme un étalonage est possible ainsi me semble-t-il qu'une calibration (je n'ai pas actuellement une datasheet de ds 3231 sous la main pour vérifier, je parle de mémoire).

Précision de vocabulaire ;
Etalonage : mesure des écarts par rapport à un étalon de grande précision.
L'affichage de l'appareil n'est pas corrigé.

Calibration : correction de l'affichage pour :

  • tenir compte de la courbe d'étalonnage
  • faire en sorte que la mesure affichée entre dans la précision annoncée.
    Un appareil de mesure est toujours annoncé avec une précision ; 1%, 5%,10 %...

Pour l'étalonnage on peut se servir du temps délivré par les serveur NTP (temps du réseau internet).

1 Like

Le circuit intégré DS1302 tout comme le DS 1307 est parfaitement précis ; ce ne sont que des compteurs.

Leur dérive est celle du quartz.
Défaut de coupe du quartz qui provoque un décalage de sa fréquence centrale
Dérive en température.

Les quartz des fréquencemètres de laboratoire sont dans des enceintes thermostatées qu'il ne faut jamais débrancher.
Les produits Made in China ont des quartz bas de gamme.

Maxim garanti les dérives du ds3231 car l'horloge est obtenue par un autre principe (MEMS) qui est corrigé en température. Maxim est maitre de la chaine.

Maxim ne garantira jamais les dérives des 1302 et 1307 (même CI il n'y a que la communication qui change) car la précision et les dérives dépendent de celui qui met le circuit en oeuvre.

Exactement :slight_smile:

Résoudre le problème RTC est un petit pas, nécessaire, mais un tout petit pas.

  • alimentation :
    • solaire, OK, mais quid de la batterie et du chargeur ?
    • autonomie souhaitée ?
    • fonctionnement en hiver ?
  • humidité = oxydation -> protection envisagée ?
  • MEGA : pourquoi un tel bazooka pour abattre un moucheron ?
  • pour info une MEGA consomme 7mA en mode veille
  • et il faut du 5V !
  • connecteurs femelles de la MEGA = usine à faux contacts
  • SD : pas forcément fiable. Il faut sélectionner un modèle et le tester à fond
  • de plus il faut prévoir un emplacement SD sans possibilité d'entrée d'humidité
  • et une SD consomme aussi !

Personnellement je verrais plutôt un ESP32 :

  • alimentation 3.3V : une batterie LIFEPO4 suffit, ou une LITHIUM-ION + regulateur 3.3V
  • même si le WIFI paraît inutile, il peut servir à relever les données (download d'un fichier)
  • FATFS émulé en FLASH : en remplacement de la SD
  • en mode veille un ESP32 consomme moins qu'une MEGA

Comme on le voit dans ce projet : Enregistreur pluviomètre
La RTC est le cadet des soucis.

Bonsoir et merci de vos réponses.
Effectivement ce montage a pour objectif d'enregistrer la météo de façon totalement autonome (pas de wifi, ni Internet ) la station sera dans la garrigue Narbonnaise à 450 mètres d'altitude. Le soleil est très généreux, d'où l'idée de l'alimentation par panneau solaire qui devrait largement suffire à entretenir la charge d'une petite batterie (moto par exemple). Malgré tout, même si l'accès n'est pas simple (4x4 obligatoire et long + marche d'approche) changer la batterie, récupérer les données ou simplement vérifier que les sangliers ne se sont pas frotter sur l'installation sera réalisé régulièrement.
L'idée d'utiliser des batteries 18650 est envisageable avec une alimentation usb le temps de l'échange des batteries.
Nous avons choisit une Méga 2560 car elle nous a semblée appropriée. Nous l'avons, elle devrait faire l'affaire. sur cette Méga, il y a un shield avec des connections Grove pour l'aspect pratique des branchements. Il est vrai toutefois que la connexion du module SD se fait sur les broches 50 à53 et 5v par fils Dupont (cela nous semble être un point faible)
L'ensemble des composants sera installé dans un boîtier étanche et de préférence tropicalisé, mais la météo est souvent très clémente malgré quelques épisodes pluvieux intenses.
Vos conseils pour enregistrer les données autrement que sur SD seraient précieux.
Lors de nos réflexions, il est apparu le problème de dérive de l'horloge interne de la Méga. C'est pour cela qu'une horloge plus précise nous a semblée utile. La DS 1307 était indiquée comme performante...
La précision est toute relative, car il nous faut savoir à quel moment il pleut (avec d'autres paramètres bien sûr) et combien de temps après le niveau du lac varie, puis se vide. La précision est importante surtout sur la durée, mais cela doit rester cohérent. En période normale de météo cela n'est pas très important, par contre lors des épisodes Cévenols d'automne, là cela devient primordial, d'où l'idée de l'horloge.
Cette installation n'a pas pour objet de rester quelques semaines, mais 2 cycles annuel de météo nous semble utile pour moyenne significative (au minimum)
Pour info, les sondes qui seront mise au niveau du lac enregistre la pression, la T° et l'heure en continue. voir :ReefNet Inc. | Sensus Ultra
Merci de vos conseils

Bonjour, Voilà ce qui est disponible et essayé actuellement. Nous les avons essayées à chaque fois sur UNO ou Méga avec les mêmes résultats.
A professional collaborative platform for embedded development · PlatformIO / résultat : erreur de compilation pour les deux exemples.
GitHub - PaulStoffregen/DS1307RTC: Use a DS1307 Real Time Clock chip with the Time library / résultat : les deux exemples indiquent de vérifier les branchements.
GitHub - Seeed-Studio/Grove_High_Precision_RTC_PCF85063TP: Grove RTC base on PCD85063TP / Le module en photo est celui que nous avons actuellement. Résultat : l'heure défile, mais n'est pas correcte, la date est au 1.1.2000
Grove_High_Precision_RTC_PCF85063TP/PCF85063TP.cpp at master · Seeed-Studio/Grove_High_Precision_RTC_PCF85063TP · GitHub / résultat : affiche 45:165:85 165:165:2165:165
[partage]Librairie simpleRTC (DS1307 / DS3231) avec heures été/hiver / résultat des 3 premiers exemples corrects soit en automatique ou manuel, puis cela indique un problème d'accès à l'horloge.
Sur les deux cartes, nous avons également fait un scanner et tous les branchements sont indiqués corrects.
Les autres modules sont la station météo : GRLEX007 - Grove Station météo pour arduino et Raspberry Cela fonctionne bien.
Le baromètre : 101020068 Capteur Grove Baromètre pour arduino et Raspberry
Température humidité : Capteur Grove humidité et température SHT35 101020592
Carte SD : Module pour carte mémoire SD™ pour arduino.
Tous ces modules fonctionnent actuellement de façon indépendante. Il faudra les regrouper, puis écrire sur la carte SD ou les mettre en mémoire de façon différente. Une mesure par quart d'heure est envisagé.

Bonjour,
Comme indiqué déjà ici, je m'orienterai vers une horloge DS3231 en utilisant la bibliothèque de RinkyDink.
Rinky-Dink Electronics.
Elle est très complète et gère unixtime, ce qui est très pratique pour l'enregistrement des mesures.
Selon le nombre de données pourquoi ne pas utiliser une eeprom du genre 24LC512 ou 1024, il existe également une bibliothèque de RinkyDink.
Des notices pdf sont fournies avec.

JChristensen a également écrit des bibliothèques : GitHub - JChristensen/DS3232RTC: Arduino Library for Maxim Integrated DS3232 and DS3231 Real-Time Clocks
et GitHub - JChristensen/extEEPROM: Arduino library to support external I2C EEPROMs.
Beau projet, bonne continuation à toi.

1 Like

La RTCLib de adafruit est fonctionnelle aussi et offre 2 classes pour gérer le temps et faire des calculs qui simplifient la vie). Il y a du choix mais dans tous les cas il faut mettre l’heure à jour au moins une fois :slight_smile: