Pertubation d'un DCF77 lié à l'alimentation (Arduino Uno)

tu peux utiliser un Tore et enrouler le fil d'alim autour, ou des ferites,

Tout à fait .

Ou on fait les 2 mon capitaine ?

C'est à toi de voir : c'est toi qui es aux manettes.
Cette bébette a l'air capricieuse ce qui rend les conclusions délicates.
Si j'ai 1 conseil à donner : en environnement de mise au point aussi mouvant il ne faut jamais hésiter à remettre en question les conclusions passées.

Hello,

Pour l'alim c'est un petit transfo noir avec une led verte dessus.
Au dos, on peut lire :
AC/DC adapter,
model SP-888
Input 100-240 VAC 50/60 Hz 0,3 A
Output 9V DC 1A

Rien de bien précis de plus à vous communiquer.

Je vais essayer une ferrite que j'ai dispo et je vous dis.

tu aurais pas un petit transfo de telephone en USB genre samsung ou iphone ou autre, tu le branche sur le secteur d'un coté et de l'autre a l'arduino... que ce passe t-il?

hazerty565:
tu aurais pas un petit transfo de telephone en USB genre samsung ou iphone ou autre, tu le branche sur le secteur d'un coté et de l'autre a l'arduino... que ce passe t-il?

==> Quand j'alimente par USB depuis le PC ou par un transfo 220->USB, ca marche nickel.

Quand j'alimente par pile sur la prise jack, ca marche aussi nickel. Donc c'est pas la conversion de tension qui foire mais bien le transfo.

Je vais avoir un oscillo sous peu, je vous posterai le screenshot du signal d'alim.

Bonjour,

Voici le screenshot de la tension 3,3v entre l'arduino et le module DCF : 3,3 v - Imgur

Le signal est le même que j'alimente en USB ou avec mon transfo chinois.

Je ne suis pas expert mais je ne vois pas de différence et je n'ai pas l'impression que le signal soit perturbé !

Vous en pensez quoi ?

PS : le signal 9V a vide et en charge du transfo chinois a exactement la même tête.

comme je dis, la tension peut être bonne, la même, mais comme ton module DCF c'est de la "radio" ils se peut qu'il soit perturber, par un signal parasite.

Tu dis qu'avec l'USB ou avec une pile il n'y a aucun soucis.

ESt ce que tu as tester la même chose, en alimentant ton module avec l'usb ou une qui marche, et avec ton alimentation chinoise allumé a coté, mais pas branché sur ton installation.

il faudrait que tu alimentes quelque chose d'autre, peut importe, avec ton alimentation chinoise, qui se trouve juste a coté de ton module voir si c'est ton alim chinoise qui perturbe ton module ou pas.

La fréquence porteuse est de 77,5 kHz (désignée aussi par sa longueur d'onde de 3,868 km). Le seul défaut de cette fréquence est d'être très sensible aux parasites.

On le remarque notamment avec l'augmentation de la portée à 2 000 km3 la nuit (car il y a beaucoup moins de parasites la nuit que le jour, et la nuit, l'ionosphère devient réfléchissante pour cette fréquence).

Bonsoir,

Pour le transfo, il est sous la table, a environ 70cm de l'arduino et est tjrs dans la prise multiple. J'ai un deuxième arduino alimenté avec la même alim posé à coté et aucun soucis quand j'alimente en usb. Donc pas d'effet parasite hors branchement.
Je vais continuer de tester les differente combinaisons en essayant d'isoler le parametre en cause. Merci pour ton aide.

Et je confirme, je capte un bien meilleur signal la nuit que le jour.

J'ai branché l'oscillo sur la sortie du module DCF77. On voit bien le pulse de 100/200 ms toutes les secondes, mais c'est bardé de parasites.

Vu qu'on est en train de travailler sur le même sujet, je me suis dit que c'était le bon moment pour sortir le tuto DCF77 que j'avais en préparation.

Si tu as l'occasion de tester la librairie proposée, ça m'intéresse d'avoir ton retour.

Bonjour,
J'étais au début très enthousiaste à propos du DCF77, mais j'ai bien galéré.
J'ai utilisé la lib funkuhr, modifiée pour utiliser les interruptions (si j'ai bonne mémoire, ça date un peu).
Mais la réception est très dépendante de l'orientation de l'antenne, entre autres. Heureusement, mon mur est bien orienté.
J'ai une matrice multiplexée qui brouille aussi la réception. Je n'active donc le récepteur que la nuit quand la matrice est éteinte, mais ça n'empêche pas le truc de décoder des mauvaises trames de temps en temps.

J'ai fini par abandonner le DCF77 au profit d'horloges RTC plus stables à base de DS3231. La précision est largement suffisante et je gère le changement d'heure été/hiver de façon logicielle.

Bonjour,

Effectivement, quand on s'embarque dans le DCF77, il vaut mieux avoir conscience de ses limites dès le départ. Ce que tu décrits est largement partagé sur la toile.

Mais c'est justement pour ça que j'ai décidé de mettre en ligne le tuto user-friendly que j'aurais aimé trouvé quand je me suis lancé.

Ce tuto commence d'ailleurs par rappeler les limites du DCF77.
Il apporte aussi des librairies faciles d'utilisation, pour moins galérer.
J'espère vraiment qu'il aidera tout un chacun à actualiser son RTC facilement une fois par jour.
Les décodages erronés sont aussi abordés dans le tuto.

C'est vrai que le besoin est moindre avec un DS3231, bien plus précis que le DS1307 de base.

Mais personnellement j'utilise d'avantage le DS1307, à cause d'une fonctionnalité supplémentaire que le DS3231 n'a pas : 56 octets de RAM non volatile, persistants grâce à la pile, d'usage libre et sans limite de réécriture. J'y stocke jusqu'à 14 timestamp, qui me permettent de tracer les derniers arrêts/démarrage de mon arduino, ou autres événements de fonctionnement.
Et à partir du moment où le RTC peut être actualisé régulièrement, l'avantage du DS3231 s'estompe.

Heures d'été / d'hiver effectivement c'est hors sujet. Il serait aberrant d'utiliser un DCF77 juste pour ça, là où quelques lignes de code suffisent.

J'utilise cette breakout board qui a l'avantage d'avoir en plus du DS3231, une pile rechargeable et 32 KB d'EEprom. http://www.dx.com/fr/p/ds3231-high-precision-real-time-clock-module-blue-3-3-5-5v-222910#.VjH7FSuVP6l

Mais bon, c'était quand même sympa d'extraire le récepteur DCF77 d'une station météo et de l'utiliser dans une horloge :slight_smile:

Malheureusement pas suffisant.

Lorsqu'un arduino redémarre après un coupure électrique intempestive, le seul moyen que j'ai trouvé pour savoir à quelle heure il s'est arrêté, c'est de sauvegarder l'heure courante chaque seconde dans une mémoire persistante.
Cela représente 86400 écritures par jour. Une Eeprom ne convient pas pour cela.

Quoique...

En répartissant la charge d'écriture sur toute l'eeprom de 32 kb.
Un timestamp = 4 octets = 32 bits
L'eeprom peut donc être gérée comme un tableau de 1000 timestamp.
Cela fait 87 écritures par jour et par bit de l'eeprom
Soit 32.000 écritures par bit et par an.
A voir en fonction du cycle maximum d'écritures supporté par l'eeprom.

Un peu compliqué quand même, pour juste un seul timestamp, comparé à la NVRAM d'un DS1307

J'avais aussi réfléchi au truc pour le pilote d'horloge Bodet que je viens de terminer (article à venir dès que j'ai mis le schéma et le typon au propre).
Ce que je voulais faire c'est mettre un gros condensateur sur l'alim de l'ATMega, une diode anti-retour entre l'alim et le condo et mesurer la tension d'alimentation avant cette diode pour déclencher une interruption en cas de coupure de courant, pour que l'ATMega sauvegarde l'heure courante dans son EEProm.
L'idée étant de disposer d'assez de temps pour écrire les données avant la coupure.
J'ai fini par abandonner cette idée car ça ne me semblait pas fiable.
Je crois aussi qu'il y a des risques de corruption de mémoire si l'alim disparait en cours d'écriture de l'EEProm.

Oui pour le risque de corruption quand l'arduino s'éteint au milieu d'une écriture.

C'est pareil quand j'écris dans la NVRAM du DS1307.
Pour faire propre, il faut prévoir deux zones d'écriture, avec une gestion de flip flop et un flag qui indique quelle est la dernière zone mise à jour.

J'écris dans la zone A, puis je mets à jour le flag pour indiquer que la zone valide est la A.
Le coup suivant, j'écris dans la zone B, puis je mets à jour le flag pour indiquer que la zone valide est la B.
etc.

Comme ça au redémarrage, le programme est capable de retrouver la dernière valeur sauvegardée, même si l'arrêt brutal a eu lieu au milieu d'une écriture.

Hello,

Un petit up sur ce problème qui continue de me pourrir la vie.
J'ai essayé plusieurs combinaisons d'alimentation, avec des capa avant et après.
J'ai même alimenté directement l'arduino en 5v sur la pin 5V. Rien n'y fait, ca ne marche qu'avec une pile. Dès que j'alimente à partir d'un transfo, je perds le signal DCF.
J'ai aussi tenté d'alimenter le module DCF77 directement par pile, indépendamment de l'arduino, mais avec une masse commune bien sur.

Le symptôme est le suivant. Quand je suit en alim par pile, j'ai un cycle de signal DCF d'une seconde, ce qui est bon. Quand j'alimente par transfo, le cycle passe à qq dizaine de ms.

J'en déduit donc que la perturbation se reporte directement sur le port data.

J'aurai bien alimenté ma pendule par pile, mais la conso est trop importante et j'ai 1j d'autonomie, donc c'est pas jouable.

@Bricoleau, je n'ai pas encore testé ta librairie car je souhaite régler mon problème d'alim avant.
As tu testé le module DCF77 avec une alimentation transfo sur l'arduino, sans passer par l'USB du PC ? Est ce que ca marche bien pour toi ?

Bonsoir,

Non pas encore testé sur transfo, désolé. C'est pour dans la semaine. Je te dirai

As-tu essayé plusieurs alim externes ?
As-tu essayé de changer d'arduino ?
Ton module DCF1 a bien la broche PON à la masse ?

Si c'est un problème de tension, tu dois pouvoir le mettre en évidence avec ton oscillo.

Jette quand même un oeil aux programmes exemples de ma lib. L'enregistreur de trace ou la barre de qualité du signal pourraient t'aider.

Oui, idem avec plusieurs alim et plusieurs arduino. La PON est bien à la masse.
Je vais continuer mes analyses et je vous dis ou j'en suis.
Je suis impatient de ton retour avec transfo.
Cdlt.

Tarasbulba:
J'en déduit donc que la perturbation se reporte directement sur le port data.

Je dirais plutôt que la perturbation se reporte sur le signal radio. La perturbation peut être rayonnée pas conduite. Le transfo dont tu parles, c'est une vrai alimentation à transformateur ou une alimentation à découpage?

Il manque des détails périphériques, dont tu ne parles pas donc je suppose que c'est maîtrisé.
Néanmoins à ce stade un petit check n'est pas forcément inutile.

Merci de confirmer le topo ci-dessous :

Si je résume, l'expérience la plus significative est :

  • alim externe + arduino + module DCF1 => ne marche pas
  • alim externe + arduino + module DCF1 alimenté par piles avec GND reliés => marche

Entre les deux montages, tout est identique jusqu'au positionnement de l'antenne
Ceci aurait tendance à prouver que la perturbation n'est pas radio mais bien électrique.

remplacement d'alim : même résultat
remplacement d'arduino : même résultat

Par ailleurs, tu as un oscillo et tu ne vois rien d'anormal sur la sortie 3V3 de l'arduino, qui alimente le DCF1

Ton cablage exact est :
DCF1.PON ------ arduino.GND
DCF1.GND ------ arduino.GND
DCF1.VCC ------ arduino.3V3
DCF1.DATA ----- arduino.Pin numérique (laquelle ?)

Est-ce que tu as autre chose de branché sur ton arduino ?
Comment fais-tu pour savoir si la réception DCF77 fonctionne bien ? Terminal Série ?

As-tu fait un relevé exact (à l'oscillo) de la sortie DATA du DCF1, avant interprétation par ton programme arduino ?
Est-ce que tu peux poster une image de ce relevé ?

Quel est ton code source de test ?

Dans la librairie que j'ai mise en ligne, il y a plusieurs programmes exemples prêts à l'emploi.
Il te suffit d'installer la lib pour que ceux-ci soit proposés dans l'IDE arduino (menu exemples), directement prêts à téléverser, avec résultat sur le terminal Serie.
Il y a un indicateur de qualité du signal, qui te permettrait peut-être de mieux cerner ce qui cloche.