Problème de précision d'horloge

Bonjour,

Pour un montage (compteur moto) je souhaite avoir une horloge en temps réel.

Mon montage est basé sur un microcontrolleur (atmega168). L'heure est conservée par un DS1307 (horloge tems réel). A la mise en fonction du microcontrolleur, il interroge via i2c le DS1307 et gère ensuite l'heure pendant tout le temps qu'il est allumé.

Pour cela, j'ai un quartz de 32.768kzhz branché directement entre TOSC1 et TOSC2 (sans condensateur, selon le datasheet du atmega168) qui cadence un timer de 8b. Le timer génère une interruption par owerflow (avec un prédiviseur de 16, car j'utilise aussi cette base de temps pour calculer la vitesse). A la mise sous tension, avant d'enclencher les interruption j'attends 1s pour "stabiliser" le quartz (j'ai vu quelque part qu'il fallait faire ça).

J'ai testé le quartz hier, et je constate une "grosse" erreur de décalage (-15s en 15mn).

Selon votre expérience :

- le quartz peut-être défectueux

- c'est normal

- une erreur de programmation

- il faut quand même mettre des condensateurs

- aucune idée

- autre problème courant...

Merci de votre aide (éventuelle)

Franssoa

--
débutant inside(c)
Reply to
Franssoa
Loading thread data ...

Hello,

Si Maxim dit qu'il ne faut pas de condensateurs, c'est que les capacités des papates d'entrée doivent suffire, je pense qu'ils savent ce qu'ils font.

Un quartz standard a une précision de 50ppm, et un bon quartz de 20ppm (environ). Là si on fait le calcul on tombe sur 17000ppm ... Je ne pense pas qu'un quartz puisse être deffectueux à ce point.

Regarde le document suivant de Maxim pour les causes possibles d'un retard :

formatting link

Une expérience à faire est de laisser tourner le DS1307 seul, avec une alim propre pour déjà éliminer un éventuel parasitage (surtout si c'est branché sur le circuit d'une moto en marche). Ca te permetra de cerner le problème.

Quand à l'erreur de programmation, c'est possible ... 15s sur 15minutes c'est du même ordre que 1024/1000. Vérifie s'il y a un décalage entre le temps conservé dans le DS1307 et le temps que tu calcules dans ton PIC.

v.

Reply to
vic

Ca sonne comme une seconde "oubli=C3=A9e" chaque minute. Un 59 pour un 60 ... ?

Reply to
Richard

vic a écrit :

Document intéressant (un peu long à lire avec ma maitrise de la langue des Monthy Python, mais bon, ça va)

J'ai essayé de donner les détails important, mais je savais bien que j'allais en oublier quelques-uns. Le décalage se produit sur le uC. Je n'ai pas encore réalisé/testé l'interface avec le DS1307

D'autre part, tout est sur plaque d'expérimentation (pas soudé).

Même idée que Richard, donc. Je vais donc me repencher sur mon code ce soir.

Franssoa

--
débutant inside(c)
Reply to
Franssoa

Franssoa a écrit :

Je ne comprend pas bien la question, de quel quartz parles tu ?

c'est le ds1307 qui se décale dans l'absolu ? c'est l'horloge soft que tu as fait dans le atméga qui se décale?

merci de préciser la question

JJ

Reply to
jj

jj a écrit :

Un quartz de type horloger de 32.768khz cadençant le timer2 de l'atmega168

C'est bien l'horloge soft de l'atmega

Franssoa

--
débutant inside(c)
Reply to
Franssoa

Franssoa a écrit :

ok, c'est plus clair comme cela.

perso j'ai mis en ?uvre des DS1337 sans aucun condo autour du quartz et l'erreur est minime.

15 secondes / 15 minutes, cela est beaucoup trop pour un pq de compensation du quartz, cela sent le bug à plein nez!!

en effet cela fait juste 1/60 !

cherches dans ton soft ou tu as fait de décompte des minutes à partir des secondes, je pense qu'il y a un pb soft (test à 59 au lieu de 60, ou bien test à 60 avec des valeurs qui commencent à 0, donc division par 61 en réalité...)

si tu peux mettre le code, je pourrai te dire si je détecte qq chose.

perso, dans mon appli, le ds1337 sort un signal à 1HZ, par scrutation je regarde si le bit est passé de 0 à 1 et je vais lire le ds1337 en i2C.

JJ

Reply to
jj

"Franssoa" a écrit dans le message de news:

4afa9375$0$4044$ snipped-for-privacy@news.sunrise.ch...

=========== Le µC tourne donc également à 32.768 khz Pourquoi ne pas avoir intégré le 1307 à la platine du µC tournant à xx mhz

Quoi qu'il en soi, ce qui est surtout important est le calcul de la valeur "ips" On suppose que la routine d'interruption ressemble à cela : ips = xxx; (32768/16 pour l'atmega ? )

#int_rtcc ou _Timerx clock_isr(){ if(--compteur == 0) { ++secondes; compteur = ips; } } Apres quoi, la routine introduisant elle-même un retard, on modifie ips en fonction de l'erreur constatée

Reply to
maioré

jj a écrit :

Oui,je me rend compte....

Je vais regarder ce soir mon code, je ne l'ai pas sous la main.

Je n'ai aucune expérience en la matière : combien de temps pour demander l'heure au DS et lire la réponse complète par i2c ?

Franssoa

--
débutant inside(c)
Reply to
Franssoa

pourquoi vous embeter à gerer l'horloge par le atmega ??? il suffit de nourrir le ds1307 avec un signal à 32768khz, de laisser l'heure se gerer toute seule quand on a besoin de l'heure, on va lire le ds1307 non ??

--
Jean-Yves.
Reply to
Jean-Yves

Jean-Yves a écrit :

Bien sur, mais je me sert aussi du temps pour calculer la vitesse de la moto (temps d'1 rotation de roue * périmètre). En utilisant un quartz de 32.768 je pensait être plus précis dans ce domaine qu'un utilisant l'oscillateur interne de l'Atmega.

Franssoa

--
débutant inside(c)
Reply to
Franssoa

jj a écrit :

Je sèche... ça doit être super évident, mais je passe à côté. Si tu veux jeter un oeil au code :

formatting link

Dans le pire des cas, je ferais avec ce décalage... Franssoa

Reply to
Franssoa

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.