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

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.

Merci @bricoleau d'avoir pris le temps de répondre en détail.
Oui, mon câblage est comme tu l'indiques.
Oui, l'antenne du DCF ne bouge (fixé au scotch sur la table en marbre).
Avec une alimentation par pile ou par cable USB seulement depuis le PC : ca marche.
Avec alimentation par transfo (pas à découpage), ca marche pas.
Quand j'alimente le DCF par une pile 3V, l'arduino par transfo, en reliant les masses, ca ne marche pas non plus.
Idem avec alim transfo 12v ou 9v sur la prise jack ou alim transfo 9v+7805+condo sur port 5V ou par transfo USB 5V sur port 5V.

Je vais ce WE refaire tous les tests à l'oscillo pour capturer les différents ports. Je me demande si la perturbation passe par la masse ou par le port DATA, je vais donc déconnecter le DATA de l'arduino et le mesurer à l'oscillo. Il n'y aura que la masse de commune. Le résultat permettra d'orienter les recherches.

Pour tester, j'utilise mon programme complet de pendule (plutôt chargé avec LEDS en pagaille, écran LCD, vumetres, DS3107). Et je vous confirme que j'ai exactement le même comportement avec un arduino nu et le sketch de démo de la librairie DCF77. J'utilise le sketch qui affiche la durée des cycles. Pour ne pas perturber le montage avec le port série branché en USB, j'ai une led qui ne s'allume que si j'ai un cycle d'une seconde (quand ca foire, le cycle est chaotique et donc la led clignote vite et pas au rythme de la seconde).

Tout me laisse penser que le problème n'est pas radio mais électrique et passe par la masse ou par la DATA.

A suivre d'ici quelques jours.

Bonjour

Pas sûr de pouvoir t'aider beaucoup. Cela ressemble quand même bien à un problème lié à l'alim elle-même.

Je ne maîtrise pas bien la différence entre alim avec et sans découpage, en terme d'effet sur un montage arduino et donc de périmètre d'usage. Je suppose que toi non plus.
L'oscillo devrait te permettre d'éclairer le sujet de manière expérimentale, à défaut d'avoir un avis d'expert.
Mais la réponse m'intéresse aussi.
D'ici ce week end je vais essayer de faire un test sur transfo.

Enfin, au risque de me répéter et d'avoir l'air d'insister lourdement, tu devrais VRAIMENT essayer mes programmes exemples.
Tu n'as aucun programme à écrire. Juste installer la lib, charger les programmes exemples et les exécuter.
Le test sera très rapide.
Outre les infos supplémentaires que cela pourrait te donner, je pense que mon traitement de décodage du signal est un peu plus résistant aux parasites, par rapport à celui que tu utilises.
Donc si les parasites auxquels tu dois faire face ne sont pas trop importants, la solution pourrait être logicielle.

bricoleau:
Je ne maîtrise pas bien la différence entre alim avec et sans découpage, en terme d'effet sur un montage arduino et donc de périmètre d'usage.

Sur l'arduino l'effet n'est sans doute pas très important. Il n'en est pas de même avec le récepteur DCF77. Ce machin fonctionne avec des niveaux assez faibles et les perturbations conduites et rayonnées peuvent perturber la réception.
Pour les perturbations conduites, un filtres sur l'alimentation du module DCF77 peut être la solution (self + capa) pour couper les fréquences liées au découpage. les perturbations conduites peuvent aussi remonter par les I/O et donc des filtres sur les lignes d'I/O entre l'arduino et le récepteur DCF77 peuvent être envisagées.
Pour les perturbations rayonnées, c'est plus difficile car on ne peut pas blinder le récepteur DCF77. Dans ce cas il faudrait plutôt blinder l'alimentation.
Les essais réalisés jusque là tendraient plutôt à accréditer la possibilité de perturbations conduites.

Dans tous les cas, la réception du signal étant assez aléatoire, une horloge ne doit pas reposer entièrement sur DCF77 pour fonctionner. Ce système ne doit être envisagé que comme moyen de resynchronisation de l'heure.

Hello,

Voila de quoi alimenter la discussion :

Le montage est le suivant :

Le module DCF77 (pollin.de) est alimenté par une pile CR2032 lithium qui délivre du 3,3V.
Les pin PON et GND sont reliés au -
Le pin VCC est relié au +
Le pin DATA est relié à l'oscilloscope (le - de l'oscillo est relié au - de la pile).

Mesure faite à 20h, le signal est encore perturbé mais suffisamment clair pour permettre une synchro (ce qui n'est pas le cas à 19h...).

Image du haut : DCF77 - Album on Imgur

Ensuite, je branche un arduino uno tout seul avec chargeur 9v sur la prise jack. et je relie la masse de l'arduino au - de la pile. C'est tout. Le seul lien entre les 2 montages, c'est le fil qui relie les masses.
On obtient l'image du bas : DCF77 - Album on Imgur
==> on distingue bien le signal DCF, mais il est entièrement haché

A vos plumes...

D'après mes propres observations :

Le signal du bas est caractéristique d'un signal affaibli : les niveaux hauts ne sont pas stables, mais remplis de micro-coupures à la masse.

Dans cette situation, on peut encore théoriquement le décoder avec un filtre passe-bas rudimentaire. Le seul risque que j'ai observé, c'est que si le signal s'affaiblit encore plus, la largeur du niveau haut se réduit également. C'est embêtant car c'est cette largeur qui détermine si on reçoit un bit à 0 ou un bit à 1.
Mais d'expérience je dirais que le signal est encore assez bon pour le décoder.

J'ai regardé la librairie DCF77 proposée sur le site arduino. Celle-ci est bien prévue pour passer outre ces micro-coupures.

Le problème, ce sont les impulsions parasites occasionnelles que l'on voit sur les niveaux bas.
Sauf mauvaise analyse de ma part, la librairie que tu utilises ne gère pas bien ces parasites.

Alors que la mienne, si !
Tu as un problème à l'utilisation de ma librairie ?

@bricoleau : Non, aucun problème a utiliser ta librairie. Je vais tenter le coup ce we.

Mais je suis un peu obstiné et brancher l'arduino sur un chargeur 9V me pourri la masse. J'aimerai bien comprendre pourquoi et savoir si on peu régler le problème électriquement.

Petite question, si je met un optocoupleur pour remonter le signal du DCF vers l'arduino, suis je obliger de relier les masses ?

Pour l'opto coupleur je ne sais pas.

Mais bon c'est sûr, tu peux aussi aller jusqu'à mettre une liaison 100% optique entre la sortie du module DCF1 et l'entrée de l'arduino, et là ça marchera ;D

Juste un point que ces courbes montrent peut-être et qu'il faut garder en tête : indépendamment du montage, la qualité du signal évolue de manière non maîtrisée entre deux expérimentations. Les modifications de cablage entre deux tests, ne sont pas forcément la seule différence.

Tarasbulba:
Les pin PON et GND sont reliés au -

il faut peut être essayer de relier la pin PON au GND directement sur le module DCF (sans passer par l'Arduino)

Tarasbulba:
Petite question, si je met un optocoupleur pour remonter le signal du DCF vers l'arduino, suis je obliger de relier les masses ?

Cela peut aider mais attention selon la spec du module DCF77 la sortie ne peut délivrer que 5µA.

Bonjour

Comme promis, j'ai fait un test avec une alim externe.

Résultat : je n'ai trouvé aucune différence avec l'alim via l'USB du PC.
La qualité du signal calculée par l'arduino est la même.
Le décodage s'effectue normalement.

J'ai utilisé ce type d'alim, réglé sur 7,5V :