Go Down

Topic: [Résolu] Mettre mon ds1307 à l'heure (Read 7938 times) previous topic - next topic

Uzuma

#15
Apr 02, 2014, 12:43 am Last Edit: Apr 02, 2014, 01:30 am by Uzuma Reason: 1

Bon... j'ai tout ressorti, enlevé la poussière  :smiley-mr-green:

Mis en configuration sans lcd (tout viré ce qui s'y rapporte), branché mon ds1307 sur les pin A4 et A5 (Duemilanova atmega168).

Je téléverse le sketch pour la version 1.xx (j'utilise la 1.04), lance le sketch Processing (1.5.1),cette fois je suis en position 4 de la liste des ports disponibles, je change la position du port dans le sketch, débranche mon arduino, lance le sketch Processing à nouveau, rebranche l'Arduino.... j'attends, dans la console série Processing une série de chiffres s'affiche signe qu'il s'est passé quelques chose, je sors du sketch Processing en appuyant sur le carré, Je lance la console série sur l'IDE Arduino.... et l'heure de mon ds1307 est au 10ème de seconde près le même que l'horloge de mon ordi.

mon ds1307 n'a pas de pile, donc c'est pas une heure qui reste en mémoire.

Voili voilou



Merci mon modo  XD  (et pardon si je t'ai fait perdre du temps) J'ai refais comme tu l'as si bien décrit mais je n'y arrive toujours pas. Mais comme je l'ai dit, j'ai réussi à le faire avec le code d'Adafruit(faut dire qu'avec les librairies toutes prêtes, c'est encore plus aisé). Le seul truc qui me turlupine encore c'est qu'il y a un décalage assez instable de temps.
Voici le code :

Code: [Select]


// Date and time functions using a DS1307 RTC connected via I2C and Wire lib

#include <Wire.h>
#include "RTClib.h"

RTC_DS1307 RTC;

void setup () {
    Serial.begin(57600);
    Wire.begin();
    RTC.begin();

  if (! RTC.isrunning()) {
    Serial.println("RTC is NOT running!");
    // following line sets the RTC to the date & time this sketch was compiled
    RTC.adjust(DateTime(__DATE__, __TIME__));
  }

}

void loop () {
    DateTime now = RTC.now();

    Serial.print(now.year(), DEC);
    Serial.print('/');
    Serial.print(now.month(), DEC);
    Serial.print('/');
    Serial.print(now.day(), DEC);
    Serial.print(' ');
    Serial.print(now.hour(), DEC);
    Serial.print(':');
    Serial.print(now.minute(), DEC);
    Serial.print(':');
    Serial.print(now.second(), DEC);
    Serial.println();

    Serial.print(" since 1970 = ");
    Serial.print(now.unixtime());
    Serial.print("s = ");
    Serial.print(now.unixtime() / 86400L);
    Serial.println("d");

    // calculate a date which is 7 days and 30 seconds into the future
    DateTime future (now.unixtime() + 7 * 86400L + 30);

    Serial.print(" now + 7d + 30s: ");
    Serial.print(future.year(), DEC);
    Serial.print('/');
    Serial.print(future.month(), DEC);
    Serial.print('/');
    Serial.print(future.day(), DEC);
    Serial.print(' ');
    Serial.print(future.hour(), DEC);
    Serial.print(':');
    Serial.print(future.minute(), DEC);
    Serial.print(':');
    Serial.print(future.second(), DEC);
    Serial.println();

    Serial.println();
    delay(3000);
}



Alors s'il y a moyen d'ajuster cela pour avoir ne serait-ce qu'une différence assez négligeable ...

gunsman76

Quand tu dis décalage de temps, elle avance ou retarde, c'est ça ?
Si c'est le cas, cela provient du quartz qui n'est pas de bonne qualité.  Pas grand chose à faire,  changer de module. Il faut éviter les ds1307 bas de gamme,  prendre un module chez gotronic par exemple, la qualité est nettement meilleur.

jfs

#17
Apr 02, 2014, 07:29 am Last Edit: Apr 02, 2014, 08:00 am by Jean-François Reason: 1
Pas de soucis  ;)

Une chose encore, la console série Arduino et le sketch Processing ne doivent pas être lancé en même temps.
Pas d'aide par MP !!!

Concernant le fonctionnement du forum tout se trouve dans les messages épinglés en tête de page.

haifger


Alors s'il y a moyen d'ajuster cela pour avoir ne serait-ce qu'une différence assez négligeable ...

Ce décalage de quelques dizaines de secondes est normal et il n'y a pas grand chose que tu puisse y faire avec cette méthode.

Pour détailler un peu, cette ligne de code :
Code: [Select]
RTC.adjust(DateTime(__DATE__, __TIME__));
utilise des macros prédéfinies du préprocesseur qui permettent d'enregistrer dans le programme la date et l'heure de la compilation, ou pour être encore plus précis le moment ou le préprocesseur a analysé le code.

Grosso modo l'enchaînement des opérations est le suivant :

  • Le préprocesseur remplace __DATE__ et __TIME__ par l'heure actuelle du PC

  • Le compilateur compile

  • Le programme compilé est téléversé dans le microcontrôleur

  • Le programmeur vérifie que le téléversement c'est bien passé

  • Le microcontrôleur redémarre

  • Une fois arrivé à l'instruction citée ci-dessus dans son processus d'initialisation, le microcontrôleur met à jour la puce RTC avec l'heure définie à l'étape 1.

Il n'est donc pas très étonnant qu'il y ait au final un décalage de plusieurs (dizaines de) secondes entre l'heure effectivement installée dans la puce et l'heure théorique du PC.

D'un autre côté, comme l'a dit gunsman76, la plupart des cartes « à-pas-cher » contenant des DS1307 ont des dérives journalières de plusieurs dizaines de secondes, voire minutes. Ce décalage initial devrait donc assez rapidement devenir le dernier de tes soucis :)

Artouste


Quand tu dis décalage de temps, elle avance ou retarde, c'est ça ?
Si c'est le cas, cela provient du quartz qui n'est pas de bonne qualité.  Pas grand chose à faire,  changer de module. Il faut éviter les ds1307 bas de gamme,  prendre un module chez gotronic par exemple, la qualité est nettement meilleur.

bonjour
Il n'y a pas de DS1307 "bas de gamme"  :smiley-mr-green: , ce qu'il peut y avoir ce sont des modules de provenance differentes equipés avec du QZ horloger "tout venant" ,  le DS1307 lui ne fait que compter en fonction de la qualité de sa BdT .

un "mauvais" module à l'origine et equipé ensuite d'un QZ "serieux"  deviendra un module bien "meilleur"

pour anecdote :  j'ai un four à micro-ondes dont l'horloge prend allegrement une avance de  5 mn/semaine  :smiley-mr-green:

je pourrais surement changer le QZ , mais quel interet  ?  :

- Pour ce qui est des temps de cuisson , le decalage final est relatif au temps de depart , l'influence est là  ?
- Meme si je fais regulierement une exacte remise à l'heure, je sais que je ne serai jamais en retard  :smiley-mr-green:



Uzuma

#20
Apr 02, 2014, 03:27 pm Last Edit: Apr 02, 2014, 03:33 pm by Uzuma Reason: 1
Quote

Une chose encore, la console série Arduino et le sketch Processing ne doivent pas être lancé en même temps.


Je n'avais pas fais trop attention à ça.


Grosso modo l'enchaînement des opérations est le suivant :

  • Le préprocesseur remplace __DATE__ et __TIME__ par l'heure actuelle du PC

  • Le compilateur compile

  • Le programme compilé est téléversé dans le microcontrôleur

  • Le programmeur vérifie que le téléversement c'est bien passé

  • Le microcontrôleur redémarre

  • Une fois arrivé à l'instruction citée ci-dessus dans son processus d'initialisation, le microcontrôleur met à jour la puce RTC avec l'heure définie à l'étape 1.

Il n'est donc pas très étonnant qu'il y ait au final un décalage de plusieurs (dizaines de) secondes entre l'heure effectivement installée dans la puce et l'heure théorique du PC.



Merci pour ton explication. Mais je me demandais si, connaissant approximativement le décalage qui survient, il ne serait pas possible dans le code de dire : Après avoir recueilli l'heure, faire (+ 10 secondes) par exemple afin d'ajuster l'heure. Le décalage étant connu.

Aussi tu as dit :
Quote

Ce décalage de quelques dizaines de secondes est normal et il n'y a pas grand chose que tu puisse y faire avec cette méthode.


Mis à part les deux méthodes que j'ai expérimenté, connaîtrais-tu une autre ?

gunsman76

Après il y a la méthode DCF77. L'heure est synchronisée sur l'horloge atomique.

Seulement chez moi en fonction de la couverture nuageuse et du positionnement du capteur ça ne marche pas. Mais ça marche dans de nombreux cas (je dois être l'exception...).

patg_


Après il y a la méthode DCF77. L'heure est synchronisée sur l'horloge atomique.

Seulement chez moi en fonction de la couverture nuageuse et du positionnement du capteur ça ne marche pas. Mais ça marche dans de nombreux cas (je dois être l'exception...).


Chez moi ça marche souvent, mais pas tout le temps.
Mon horloge s'est bien mise à l'heure suite au passage à l'heure d'été mais certains jours je la retrouve complètement déréglée. Je n'ai pas implémenté l'algo de décodage DCF77 moi-même, et pas envie de m'y pencher. J'ai une LED à l'intérieur qui clignotte au rythme des impulsions reçue, qui me permet de vérifier la réception du signal (très dépendant de la position de l'horloge, heureusement que mon mur est bien orienté...).

Pour la V2, j'opte pour un DS3234 et un codage manuel de l'algo de changement d'heures. Avec mise à jour manuelle une fois par an pour compenser la dérive d'1 à 2 minutes annuelles de ce type d'horloge RTC.  Je vais aussi utiliser l'EEProm pour mémoriser la date et permettre de changer la pile de l'horloge sans devoir passer par des boutons de réglage de la date. C'est implémenté mais pas encore testé (donc ça ne fonctionne pas encore ;) )

Si l'Arduino est relié par USB au PC il est toujours possible de définir un protocole par lequel l'Arduino demande l'heure au PC lors du démarrage du sketch ou à intervalles réguliers. Y'a un peu de boulot des deux côtés mais ça pourrait être une solution envisageable.
Mes Arduineries: http://breizhmakers.over-blog.com/

gunsman76

Je rebondis sur ton changement d'heure été/hiver, je suis super intéressé par l'avancement de ton code.

J'avais commencé à cogiter la dessus, mais par manque de temps je n'ai pas été jusqu'au bout. Bref je pense que je vais m'y remettre rapidement car c'est vraiment super utile.

john_lenfr

#24
Apr 02, 2014, 04:17 pm Last Edit: Apr 02, 2014, 04:33 pm by john_lenfr Reason: 1
Non tu n'es pas l'exception, chez moi je n'ai jamais réussi à capter quoi que ce soit étant orienté Nord en zone urbaine.
Donc j'ai de suite oublié le DCF trop "fragile".

Le NTP fonctionne très bien avec mon DS1307 :)

john_lenfr


Je rebondis sur ton changement d'heure été/hiver, je suis super intéressé par l'avancement de ton code.

J'avais commencé à cogiter la dessus, mais par manque de temps je n'ai pas été jusqu'au bout. Bref je pense que je vais m'y remettre rapidement car c'est vraiment super utile.


Pas la peine de chercher il est déjà ici:
Equations by Wei-Hwa Huang (US), and Robert H. van Gent (EC)
Code: [Select]
int adjustDstEurope(DateTime t)
{
/*You can use the following equations to calculate when DST starts and ends.
The divisions are integer divisions, in which remainders are discarded.
"mod" means the remainder when doing integer division, e.g., 20 mod 7 = 6.
That is, 20 divided by 7 is 2 and 6/7th (where six is the remainder).
With: y = year.
        For the United States:
            Begin DST: Sunday April (2+6*y-y/4) mod 7+1
            End DST: Sunday October (31-(y*5/4+1) mod 7)
           Valid for years 1900 to 2006, though DST wasn't adopted until the 1950s-1960s. 2007 and after:
            Begin DST: Sunday March 14 - (1 + y*5/4) mod 7
            End DST: Sunday November 7 - (1 + y*5/4) mod 7;
        European Economic Community:
            Begin DST: Sunday March (31 - (5*y/4 + 4) mod 7) at 1h U.T.
            End DST: Sunday October (31 - (5*y/4 + 1) mod 7) at 1h U.T.
            Since 1996, valid through 2099
(Equations by Wei-Hwa Huang (US), and Robert H. van Gent (EC))

Adjustig Time with DST Europe/France/Paris: UTC+1h in winter, UTC+2h in summer

*/

  // last sunday of march
  int beginDSTDate=  (31 - (5* t.year() /4 + 4) % 7);
  //Serial.println(beginDSTDate);
  int beginDSTMonth=3;
  //last sunday of october
  int endDSTDate= (31 - (5 * t.year() /4 + 1) % 7);
  //Serial.println(endDSTDate);
  int endDSTMonth=10;
  // DST is valid as:
  if (((t.month() > beginDSTMonth) && (t.month() < endDSTMonth))
      || ((t.month() == beginDSTMonth) && (t.day() >= beginDSTDate))
      || ((t.month() == endDSTMonth) && (t.day() <= endDSTDate)))
  return 7200;      // DST europe = utc +2 hour (summer time)
  else return 3600; // nonDST europe = utc +1 hour (winter time)
}

gunsman76


haifger


Après il y a la méthode DCF77. L'heure est synchronisée sur l'horloge atomique.
Seulement chez moi en fonction de la couverture nuageuse et du positionnement du capteur ça ne marche pas. Mais ça marche dans de nombreux cas (je dois être l'exception...).



Non tu n'es pas l'exception, chez moi je n'ai jamais réussi à capter quoi que ce soit étant orienté Nord en zone urbaine.
Donc j'ai de suite oublié le DCF trop "fragile".


(hors sujet) C'est drôle, j'ai souvent lu sur ce forum des personnes se plaignant de difficultés d'utilisation du signal DCF77, mais personne ne semble avoir essayé d'utiliser le signal émis par Allouis[1] ?
Est-ce parce que la démodulation de phase est plus compliquée que la «simple» modulation d'amplitude ? Et/ou parce qu'il ne semble pas exister de modules tout prêts comme pour le DCF77 ?
J'avoue n'avoir personnellement jamais utilisé ni l'une ni l'autre méthode.

[1] http://fr.wikipedia.org/wiki/%C3%89metteur_d%27Allouis#Signaux_horaires

gunsman76

Je ne connaissais pas du tout.

Si quelqu'un l'utilise, un petit retour serait bien sympa.



john_lenfr

http://forum.arduino.cc/index.php?PHPSESSID=478i4am8h72la6ki460lab7s13&topic=33585.msg245483#msg245483

Go Up