Panne Machine à Laver le linge

INDESIT BTW L7220 FR/N

Si vous arrivez directement sur cette page par un moteur de recherche, vous pouvez avoir accès à la table des matières et à chaque article, en page d'accueil.    L'accès se fait par l'un des deux liens en tête de colonne de droite ----->

ATTENTION à compter du 15/09/2019 les commentaires ne seront plus possibles à causes de quelques imbéciles qui font du spam pour le plaisir de nuire ! désolé  !

Préambule

 Comme toujours, il faut une circonstance particulière, une panne par exemple, pour s’apercevoir des erreurs de conception de certains appareils ménagers. (Erreurs parfois volontaires)

Ce matin 05/02/2024 ma chère et tendre m'appelle pour la machine à laver qui ne démarre pas.

Alors commence le processus de recherches, avec en premier lieu une assez réconfortante observation, rien ne se passe, aucun voyant, rien du tout ! (C'est en général plus simple pour trouver une panne). Ce n'est pas la prise de courant !

Il y a bien longtemps, du temps des programmateurs électromécaniques, c'était déjà la croix et la bannière pour comprendre ce qui se passait, mais en général ça se voyait.

Maintenant on est plutôt du genre " d'une poule qui a vu un couteau ", car il faut empoigner le problème … et commencer par pouvoir accéder ! Le démontage est toujours mystérieux et délicat si on ne veut rien casser.

• 1.Manifestation

Non, pas de manifestation dans la rue ! Mais que se passe-t-il ? Comme déjà dit, rien ne se passe et il n'y a aucun voyant allumé. On peut penser d'entrée au contact de porte défectueux (C'est déjà arrivé avec ces contacts de porte qui chauffent pendant de longues minutes avant de libérer la porte) Après plusieurs tentatives de bonne fermeture de porte, le problème reste entier ! (Souvent ce contact agit après l'interrupteur secteur)

Peut-être un fusible ? (Si jamais il y en avait un!) mais où se cacherait-il ?
Pas d'autre solution que de démonter le panneau de commande (panel !)

• 2.Démontage du panel

  

Il faut cette fois se lancer pour de vrai et comprendre ce qu'ont voulu faire les concepteurs, car avec ce satané plastique qui se déforme à souhait pour fermer les choses, il faut comprendre ce que l'on découvre pour la première fois et trouver comment démonter.
A l'arrière du panel, il faut glisser deux pattes de 1 à 1.5mm d'épaisseur pour faire échapper les deux systèmes de verrous accessibles. (deux petits morceaux de circuit imprimé de 1.5 à 2 cm de large)

Ça résiste, alors tout en surveillant que les brides soient bien déboîtées, on donne un bon coup sec dans les angles du panel et cette fois celui-ci se déboîte assez brutalement ! Le panel se déboîte ensuite tout seul vers la charnière du capot avec 2 mêmes brides qui échappent.

Le panel est maintenant dans mes mains !

C'est tout bon ! Enfin pas tout à fait, car le circuit imprimé de commande est emmailloté dans une cage en plastique avec de très nombreux petits connecteurs sur les côtés (et quelques gros, de type FASTON).
Tous ces connecteurs, petits et gros sont verrouillés toujours par un petit ergot en plastique, qu'il faudra maintenir échappé pour sortir le connecteur.

Je fais un rapide essai sous tension pour m’apercevoir que le problème est sur un mauvais contact au niveau du TRUC central de couleur brune et noire sur lequel viennent se connecter 2 fils bruns très certainement le 230V.
Comme je n'aime pas revenir 2 fois sur un même problème, je décide de tout démonter cet ensemble, et je conseille de bien repérer tous les connecteurs eux mêmes et d'inscrire la même annotation sur le circuit imprimé. (Ça évitera les erreurs). C'est un peu laborieux à faire !

Un fois le circuit imprimé en main je constate que le TRUC (photo ci dessous)

responsable du mauvais contact est finalement très compliqué, qu'il n'est pas facilement démontable sans détruire le circuit imprimé.
Je vois aussi par un petit trou qu'il y a un petit ressort à l'intérieur... Alors j'arrête là tout espoir de démontage car une telle opération équivaut à perdre quelques pièces et/ou à un massacre et à la destruction du circuit imprimé, sauf si l'on a un deuxième TRUC en secours, ce qui n'est pas le cas et ne le sera jamais, car dans ce genre de pannes on sait parfaitement que l'on change " la plaque électronique " avec un coût minimum de 100 à 200 Euros !

Alors il faut savoir dire non et adopter des solutions tierces qui permettent sans grandes contraintes de fonctionner tout de même !

• 3.Dépannage

Le remède est de dire que ça " marchotte " un peu, et une giclée de " contact 60 " dans ce TRUC va améliorer le fonctionnement. On fait avant arrière sur le bouton jusqu'à ce que les voyants s'allument (Ce n'est pas instantané car il y a une temporisation de 1 seconde environ) et on ne reviendra plus jamais sur la position OFF

Je n'ai pas d'autre solution bon marché pour " réparer ", à moins de trouver un TRUC neuf et de casser le vieux en place pour retirer une à une les broches (si c'est réellement possible, voir photo côté pistes du circuit imprimé !)

L'autre solution est l'échange standard du circuit imprimé, soit en récupération d'un modèle, soit en achetant un neuf, mais à quel prix !!!
Si tel était le cas, avec les différentes versions et révisions, il est souvent préférable de confier ce travail à un réparateur officiel qui aura l'obligation de résultats et surtout fournira en préalable un devis en bonne et due forme.

Un problème adjacent est l'absence de possibilités de faire une lessive durant un temps assez long, et là cela pose problème.

Dans cette éventualité il vaudra peut-être mieux changer de machine... ? C'est triste d'en arriver là !

• 4.Solution bricolée

Qu'elle est donc la fonction de ce TRUC ?
Il établi le 230V du secteur dans les circuits mais assure également le codage binaire des divers programmes de lavage, permettant, de compter au moins jusqu'à 14 (ou 15, mais pourquoi pas 16 sur 4 bits?)

Pour palier à ce TRUC, il faut établir le secteur 230V. ATTENTION, je n'ai pas vérifié ce qui arrive sur ces 2 fils bruns : Est-ce un simple interrupteur ou au contraire l'arrivée phase et neutre (Bleu pour N?!) Je ne sais pas ! A vous de vérifier.

Je rappelle que le 230V est mortel et qu'il faut rester vigilant

Pour couper le secteur, il faudra ajouter un interrupteur à bascule au panel, qui coupera l'alimentation secteur et ne plus utiliser la position " OFF ". Il faudra raccorder les fils en conséquence suivant qu'il s'agit d'une alimentation 230V ou d'un interrupteur 230V.

Pour ma part, je n'ai pas fait la modification car je n'en ai pas eu le temps, car la machine était remplie et ma douce épouse attendait....
La solution est donc de tirer la prise de courant et de ne jamais aller sur OFF.

En " titillant " le bouton vous arriverez certainement à rétablir le " jus " et donc la machine sera prête pour une nouvelle lessive ! Il suffira alors pour la mettre hors tension, de tirer la prise de courant. C'est bête mais simple !

(On notera un bon point qui est la présence d'un antiparasite secteur pour éviter de polluer le réseau 230V par les harmoniques de commande du moteur).

• 5.La critique

Oui, la critique est sévère car on ne coupe pas le secteur en même temps que l'on commute les circuits logiques dans un même boîtier, c'est une aberration sans nom pour l'économie d'un simple petit interrupteur standard. Voilà jusqu'où la rapacité des fabricants va se loger.

Je considère cette solution comme une " erreur volontaire " de conception, d'autant que ce TRUC est une pièce unique de ce fabricant (ou groupe de fabricants) et ne répond à aucune pièce détachée standard.

De plus, même si les isolations sont suffisantes, une telle proximité de signaux logiques de faible tension (1.8V à 5V) à côté du 230V alternatif est pour moi scandaleuse et en parfaite opposition à la réparabilité des équipements prônée par le gouvernement ainsi qu'un encouragement à l'achat d'appareils neufs et ainsi à l'augmentation du CO².
Enfin pour la maintenance des cartes imprimées, je n'ai pas vu de séparation particulière du 230V et de la logique ? Serait-ce long ruban étamé avec d'un côté des fraisages d'isolation ? Pas très clair, et aucune sérigraphie.

Au final je suis allé voir sur Internet les pièces détachées mais chez aucun revendeur, je n'ai pu trouver la fameuse carte électronique correspondant à ce modèle. Je n'ai pas plus trouvé la référence chez le fabricant, tout autant qu'un prix. Je suppose que dans ce cas on doit changer la machine directement ! Quel malheur !

Si cette pièce est commercialisée, le circuit électronique sera très certainement vers 200 € car le prix de la machine est de 400 € environ, et tout le monde sait que l'électronique c'est cher alors autant en profiter !!!

Je déconseille donc tous les appareils dont le bouton des programmes assure en même temps la coupure du secteur. Vous devrez trouver un véritable interrupteur pour le secteur sur une bonne machine !

bricolsec

Routeur photovoltaïque    

1    C'est quoi un routeur photovoltaïque
2    Rentabilité
3    La théorie
4    Le synoptique
5    Emplacement router
6    Tension et courants
6.1    La détection du zéro de tension
6.2    Principe des mesures
6.3    Les grandeurs à considérer
6.4    Le cumulus
7    Le montage
7.1    Historique
7.2    Le schéma
7.3    Entrées
7.4    Les relais
7.5    Le multiplexeur
7.6    Les LED de contrôle
7.7    Conclusions schéma
8    Le programme
8.1    Le principe du Timer 2
8.2    Le cycle de mesures
9    Conclusions
9.1    Panneaux photovoltaïques, obligations légales
9.2    Le Router

10    Annexe des Points relevés  avant et pendant la réalisation
10.1    Horloge PIC à 20 MHz
10.2    Temps de mesure ANA
10.3    Moyennes / sécurité des valeurs mesurées
10.4    Point de référence à 2.5V
10.5    Temps zéro et tension 230V
10.6    Solution avec ALT+
10.7    Essais des variateurs à TRIAC
10.8    Mesure des courants Habitation / panneau
10.9    Puissances
10.10    La régulation
10.11    Le problème du cumulus
10.12    Choix du capteur de courant
10.13    Le courant est-il symétrique ?
10.14    Stabilisation du 2.5V
10.15    Le Timer 2 du PIC
10.16    LINKY

Si vous arrivez directement sur cette page par un moteur de recherche, vous pouvez avoir accès à la table des matières et à chaque article, en page d'accueil.    L'accès se fait par l'un des deux liens en tête de colonne de droite ----->

ATTENTION à compter du 15/09/2019 les commentaires ne seront plus possibles à causes de quelques imbéciles qui font du spam pour le plaisir de nuire ! désolé  !

Préambule

Je pense qu'il faut commencer par expliquer les principes de base, car même en étant de la partie, je me suis posé des questions très techniques sur le fond, car l'électronique n'est pas tout à fait l'électrotechnique… J'ai eu des réponses par Internet avec quelques articles qui démystifient le sujet de la prise de puissance sur le réseau électrique.
https://f1atb.fr/index.php/fr/2022/12/03/realisez-un-routeur-solaire-pour-gerer-la-surproduction/  click direct
https://ptiwatt.kyna.eu/?post%2F2018%2F07%2F23%2FFabriquer-un-power-router click direct

De base vous connaissez l'électricité et les relations en courant alternatif avec l'avance ou le retard du courant sur la tension. Si cela n'est pas acquis reportez vous à quelques articles déjà écrits à ce sujet soit dans ce même blog soit ailleurs sur Internet. http://bricolsec.canalblog.com/archives/2007/10/31/6719839.html  notions

La première relation concerne la puissance électrique (Active) qui est connue suivant la formule P=UIcos phi.
Dans cette formule, il faut comprendre dans cet article, que la tension du réseau EDF est fixée avec une certaine précision et que celle-ci ne peut pas changer du tout au tout. On peut aussi comprendre simplement que LA PUISSANCE EST DIRECTEMENT LIÉE AU COURANT (En faisant l'impasse sur le cos ?).
Autre constante : la fréquence de 50 Hz pour une majorité de pays si elle peut légèrement varier, elle doit cependant répondre à des critères rigoureux de  nombre de périodes dans le temps.
Pour pouvoir devenir émetteur de puissance, il faut évidemment dépasser ou simplement compenser le courant à chaque instant de la sinusoïde du courant par un courant opposé au courant consommé, voire aller encore plus loin en dépassant ce courant consommé, on devient alors dans ce cas PRODUCTEUR D’ÉNERGIE. Pour obtenir ce courant opposé, c'est la tension qui devra légèrement augmenter tout au long de la sinusoïde originale.

C'est le principe de prise de puissance sur le réseau électrique. A chaque instant on devrait annuler voire dépasser le courant consommé par un courant en opposition fourni par la source auxiliaire de puissance (Panneau photovoltaïque par exemple).

Ce principe est du rôle de l'onduleur ou du micro onduleur.

Ces micro-onduleurs sont très complexes car ils doivent à chaque temps élémentaire (de l'ordre de la µs ou moins !) s'ajuster pour se trouver en opposition de courant tout en regardant tension et fréquence d'origine.
Étant sur une même ligne phase / neutre, on comprend difficilement comment cette double obligation est respectée.
 
Là mes connaissances s'arrêtent et je ne peux que supputer qu'il y a un temps infime consacré à la lecture de la tension d'origine, puis un deuxième temps à ajuster la tension pour un courant en opposition. Où dit plus simplement à veiller à ce que le courant "sorte" de l'onduleur ?
Ce point est certainement le plus difficile à appréhender, même pour une personne du métier, car on ne sait pas si c'est au niveau de chaque point d'une alternance, si c'est d'une alternance à l'autre ou encore autrement ?

Que se passerait-il si un fournisseur de puissance n'était pas en phase parfaitement avec ce principe ? Tout sauterait, car le pire serait d'ajouter ce courant produit au courant initial !
Ce sujet est identique à la mise en phase des alternateurs sur un réseau électrique qui est un sujet mieux connu des électrotechniciens.
Bref ce "sujet est hors sujet" car le router photo voltaïque se situe juste après l'onduleur et c'est l'objet de ce "roman", car celui-ci aura duré extrêmement longtemps.

Dans cet article on se contentera du fonctionnement impeccable de l'onduleur, mais on fera en sorte que le surplus d'énergie produit, ne soit pas réinjecté dans le réseau, mais récupéré pour chauffer de l'eau, ce qui est la forme la plus élémentaire de stockage d'énergie AU NIVEAU INDIVIDUEL.

Le dilemme est que la consommation locale d'une habitation varie en fonction des heures (machines à laver, frigo, congélateur, fours…etc), et de même l'énergie photovoltaïque change en fonction des saisons, de l'ensoleillement qui varie suivant la météo et les heures de la journée.

Le but principal d'un routeur photovoltaïque est donc de stocker le trop d'énergie produite et d'ajuster en permanence en fonction de l'ensoleillement et de la demande d'énergie de la maison. Ceci concerne donc l'autoconsommation (Sans production pour rachat d'énergie).
De fait l'autoconsommation doit couvrir au mieux des possibilités instantanées, toute consommation locale sans réinjecter d'énergie dans le réseau public.

On se souviendra aussi que le compteur LINKY mesure la puissance instantanée (Active) sur une période d'une seconde.

En ANNEXE de cet article, il y a un résumé des principaux points relatant les nombreuses difficultés rencontrées, vous y trouverez pas mal d'éléments techniques qui ne figurent pas dans l'article lui-même et sur lesquels j'avais dû ma baser pour démarrer.

Quelques Abréviations utilisées :

* "Fire" représente l'instant où l'on déclenche le TRIAC pour conduction vers le cumulus.
* Z-C, ZC ou TZ est l'instant où la tension est nulle (=0)
* ALT+ est utilisé pour un signal alternatif carré qui indique à la fois le TZ et l'alternance positive ou négative
* Lorsque l'on parle de "degrés" il s'agira essentiellement de degrés d'angles.
* 5 Vcc indique une tension crête crête de 5 volts Attention c'est aussi la dénomination de la tension d'alimentation
  des circuits logiques comme le µ contrôleur (à voir le sens qu'on lui donne à l'instant !)
* INJECT est le nom d'une variable essentielle du programme qui indique à 1 que l'on injecte du courant dans le réseau.
* Fire_Byt est la variable en degrés angulaires de commande du TRIAC (de 90° à 180° d'une alternance )

1 C'est quoi un routeur photovoltaïque

Un router permet à partir d'un trop d'électricité produite, de chauffer l'eau d'un cumulus (Ou tout autre appareil résistif de préférence). Dans notre cas ce sera par les panneaux photovoltaïques, mais ce pourrait être aussi le cas d'une éolienne.
Les panneaux photovoltaïques dans mon application compensent le talon des consommations permanentes et "inévitables" comme indiquées ci après mais peuvent souvent produire plus que nécessaire.
Ce système est seulement utile lorsqu'il s'agit d'une petite autoproduction de compensation du talon de consommation.
Dans ces petites consommations on peut citer : la ventilation mécanique, la pompe de chaudière, la box, le frigo, congélateur, les volets électriques, les petits chargeurs de téléphone, l'ordinateur, les régulations de panneaux solaire thermique, télévision, radio, ordinateur, etc…
(À l'exclusion du four micro ondes, four thermique, sèche linge, machine à laver, fer à repasser, climatisation  et des gros radiateurs électriques et d'une façon générale de tout les gros consommateurs d'énergie). (Encore que les machines à laver le linge sont maitenant très économes en énergie)

Ce router présente surtout un intérêt pour les utilisateurs de quelques panneaux (1 à 4 le plus souvent) qui sont utilisés en autoproduction avec micro-onduleur.
Tous ces petits appareils sont soit en consommation permanente, soit appelés de façon régulière et reflètent la vie d'aujourd'hui.

Le but d'une petite installation photovoltaïque est donc d'alimenter les consommations permanentes ET de compenser partiellement les appareils les plus voraces. Au-delà de tout cela, même avec seulement 500 Watts produits, il est certain qu'à certains instants, on est excédentaire et le but du dispositif  est donc de stocker ce surplus d'énergie, à priori pour le chauffage de l'eau chaude sanitaire d'un cumulus.

Ce dispositif est associé à des panneaux photovoltaïques, en général en petit nombre pour éviter de redistribuer de l'énergie dans le réseau, car en principe, ENEDIS demande qu'il n'y ait pas de réinjection dans le réseau, mais  c'est surtout pour son propre intérêt personnel, puisque tout retour d'énergie vers le réseau est une perte pour celui qui a installé des panneaux !!!. (Vous en l'occurrence !)
Alors le principe est de dire qu'il ne faut pas perdre cette énergie qui serait réinjectée sur le réseau, mais de la récupérer. Le stockage d'énergie le plus pertinent au niveau individuel est le chauffage de l'eau d'un cumulus.

En ce qui me concerne, en maison individuelle, avec un abonnement 6 KVA et compteur LINKY, je consomme 80 à 250 Watts permanents suivant les incontournables appareils d'une maison. C'est peu et beaucoup à la fois.

Il faut se rappeler qu'un talon de consommation est une consommation permanente qui existe 24 heures sur 24, et que c'est cette durée qui devient prépondérante. En ce sens effacer cette consommation durant la journée est l'assurance de réduire cette consommation permanente de moitié.
Certes cela dépend de la météo et de l'ensoleillement et tout n'est pas parfait à ce niveau et lorsque l'on achète des panneaux, on regarde la puissance maxi que l'on peut tirer de chacun.
En réalité cette puissance nominale est rarement atteinte pour de multiples raisons : région, ensoleillement faible, nuages, heure de la journée, exposition/orientation du ou des panneaux, cycle des saisons.
(J'ai en projet de faire des relevés heure par heure de la production au cours d'une année complète).

Je pense que 2 panneaux de 350 Watts sont une bonne solution pour une habitation particulière, avec la volonté de ne pas faire une dépense "hors budget" ! Cette solution est à moindre coût et sa réalisation des plus simples. Le routeur photovoltaïque présente l'intérêt supplémentaire de mieux profiter de la totalité de l'énergie produite.
Ce dispositif complémentaire est intéressant dans la mesure où vous pouvez le réaliser vous-même, car acheté, il reste assez onéreux et encore plus si vous deviez alimenter des charges autres que résistives (Moteurs par exemple)

Le modèle que j'ai réalisé est prévu pour une charge résistive, mais ne permettrait pas de profiter pleinement sur des charges avec cosinus phi différent de 1, comme des moteurs de puissance "assez importante".

2 Rentabilité

Je suis chez l'opérateur historique EDF avec un abonnement 6 KW SANS tarif de nuit et pour une utilisation moyenne de 2 personnes. J'ai été adepte il y a 50 ans du chauffage électrique, mais vu la dégradation permanente des coûts, il y a environ 25 ans j'ai opté pour un chauffage fuel associé avec une deuxième chaudière bois. (voir cet article sur ce même blog)
A ce jour, avec 2 panneaux,  j'ai réduit ma consommation de moitié avec une consommation annuelle sur facture de 1531 KWH, soit au tarif de ce jour 0.205 €/KWH (avec TVA 20%) soit 313.8 Euros par année.

Chiffres à l'appui sur seulement 1 mois, ma nouvelle consommation a diminué de moitié, soit une économie brute de 157 € et pour un coût des panneaux de 1100 €, il faudra donc 7 années pour amortir la dépense et retrouver un intérêt sur les 18 années restantes puisque l'ensemble est prévu pour fonctionner 25 ans !
Cependant avec le router, on va ajouter quelques économies au chauffage de l'eau sanitaire. Pour moi qui aie en plus un panneau solaire thermique depuis 1981, je vais un  peu moins en profiter…
Je profite de ce sujet pour dire que le chauffage de l'eau sanitaire est d'un bien meilleur rendement en solaire thermique (en tracking) que le photovoltaïque.

Je ne pense pas qu'un tel appareil acheté puisse avoir un véritable retour sur investissement en moins de 20 années, car l'énergie récupérée reste moyenne à faible, mais ce sont les petits ruisseaux qui font les grandes rivières !... Cela a le mérite de répondre à la demande d'ENEDIS ne ne pas réinjecter de courant dans le réseau. C'est aussi un geste pour la planète.

Pour le router, il y a un complément d'énergie que j'évalue à moins du quart du gain direct EDF, car avec 2 panneaux ont est souvent légèrement excédentaire. Le rentabilité est donc faible à moyenne, à la seule condition de réaliser soi-même ce router, qui ramènera à environ 4 années le retour sur investissement au lieu de 20 années si il était acheté.
Le matériel nécessaire à ce router n'est pas très cher, et pour une paire d'Euros, et quelques dizaines d'heures de travail on peut y arriver assez facilement si l'on est un peu au fait de l'électronique, électricité et programmation de micro contrôleurs et "bon bricoleur".

3 La théorie 

Le principe est d'utiliser le service d'un micro contrôleur PIC 16F886, programmé en assembleur pour la rapidité.
L'onduleur des panneaux est branché directement dans une prise de courant (Pour le principe), mais en réalité il faut seulement ajouter diverses protections, mais le principe reste très simple comme pour brancher un simple gril pain !

Ce micro contrôleur analysera en permanence le courant d'alimentation réseau (juste après le LINKY et le disjoncteur d'entrée) et l'incidence du courant photovoltaïque. Suivant le sens par rapport à la tension, il va forcer une consommation complémentaire pour que l'énergie des panneaux soit utilisée au maximum sans, retourner chez "EDF".

Si la demande est plus forte que la production solaire, alors le complément est pris sur le réseau. (Dans le cas contraire c'est le réseau qui recevrait le surplus de production).
C'est donc uniquement dans ce dernier cas que le router intervient en s'adaptant en permanence pour que la totalité de production soit utilisée pour alimenter le talon de consommation ET que le trop d'énergie produite (éventuel) soit dirigée

vers le cumulus sans jamais dépasser la capacité de production qui est variable en fonction des nombreuses conditions déjà énumérées.

Cette présentation parait des plus simples, mais les défis techniques sont importants, car pour contrôler le réseau à la fréquence de 50 Hz, il faut véritablement travailler en cycle d'instructions de base à 200ns pour réaliser presque 2 centaines de mesures analogiques durant une seule demi alternance de 10ms.

La rapidité est le premier élément à maîtriser. Le deuxième est de comprendre comment distinguer si on est en injection sur le réseau ou au contraire si on est

demandeur d'énergie au réseau.
Cette opération est traitée par le sens instantané du courant relativement à la tension. Je m'explique :

Si le courant est en phase avec la tension (Au cosinus Phi près) alors on est en consommation (Énergie prise sur le réseau). Dans le cas contraire, si le courant est opposé à la tension, alors on est en injection de courant sur le réseau. Ce dernier cas ne devrait pas se produire car cette énergie profite aux autres et non à vous qui avez investi ces panneaux.
C'est dans ce seul cas que le router est utile pour s'ajuster exactement pour que le courant devienne nul et que rien ne reparte sur le réseau ENEDIS.

Ce point de non retour de courant est demandé par ENEDIS lors de la demande de raccordement de l'onduleur des panneaux. Un retour n'est pas gênant en soi car gérer cela, n'est pas une chose technique très simple, mais malheureusement si cela existait vous ne seriez même pas rétribué pour cette fourniture d'énergie.
C'est dommage d'autant que ce n'est pas normal, car le fameux compteur LINKY est parfaitement apte à compter pour paiement ou déduction de ce retour d'énergie.
Si par décision politique, le comptage du LINKY s'avérait modifié dans les prochaines années , il est probable que le router perdrait de son intérêt, encore faudrait-il que le producteur officiel déduise ou paye à son juste prix le retour, ce qui serait alors à examiner pour choisir la solution "paiement" ou "router" !
J'ai fonctionné en retour vers EDF durant les premiers temps et bien entendu ça se passe sans problèmes, mais je n'aime pas jeter l'énergie (Ou les Euros) par les fenêtres, mais surtout je ne veux pas enrichir ces grandes sociétés par le biais de mon investissement.

Un des points délicats est la présence du 230V ~ qui est dangereux voire mortel ! Aussi tout est fait pour limiter les contacts accidentels et simplifier le plus possible. Malgré toutes mes précautions j'ai tâté à ce 230V et ça ne fait pas du bien, aussi je mets en garde les bricoleurs de la machine à bois ou les soudeurs à l'arc, car réaliser ce router est un peu plus délicat, même si le programme fonctionne déjà pas mal et que le plus gros du travail d'étude est fait.

4 Le synoptique

Il est réduit à sa plus simple expression et seulement aux éléments essentiels pour ne pas surcharger et bien saisir le principe.
Tout ce qui concerne les différentes protections (Différentiel, fusibles ou disjoncteurs etc) n'est pas représenté.

Par obligation, l'onduleur d'autoproduction n'a pas le droit de générer du courant/tension en l'absence du secteur. Ceci est confirmé par le fait que c'est la prise mâle de l'onduleur qui doit être branchée dans une prise femelle de l'habitation.
C'est surprenant mais c'est ainsi et c'est vérifié !
(C'est la raison de la représentation symbolique du fil de sortie des panneaux sur une prise mâle).

Cette prise de sortie de l'onduleur entre dans le compteur d'énergie qui est un simple énergimètre du commerce qui rempli parfaitement sa fonction. Ce modèle est intéressant car il ne perd pas la mémoire en cas de coupure secteur (Également sans pile), et permet ainsi de faire le suivi de production d'énergie solaire.

On rejoint ainsi l'installation générale, et juste avant le disjoncteur général, on insert un transformateur d'intensité (TI) qui est clipsable autour des gros conducteurs d'alimentation de la maison. (Il n'y a pas à couper l'alimentation ni à débrancher)
Dans la même zone on fera la prise de tension pour "caler" le courant correspondant (Dans la bonne alternance).

Dans la maison se trouve le cumulus qui va recevoir une alimentation électrique par un TRIAC (Interrupteur logique avec temps compté à partir du zéro de tension)
(Éventuel) C'est par ce dispositif que l'on va compléter le chauffage du cumulus par le trop  d'énergie produite par les panneaux.
Cette commande du TRIAC résulte de l'analyse du courant direct ou en opposition mesuré par le Transformateur d'Intensité  (TI en abrégé) relativement à la tension.

Ce synoptique est similaire pour tous les routers à cause du principe même de l'injection. Le but est qu'il n'y ait aucun courant au niveau du compteur EDF, pour que toute l'énergie produite soit consommée localement dans les différents équipements et dans ce cas en chauffant l'eau du cumulus grâce au router.

Dans mon système, j'ai ajouté 2 tores complémentaires, (Récupération de modèles pour CI) l'un pour détecter la fin du jour, par une intensité très faible ou nulle sur le courant issu de l'onduleur des panneaux. L'autre est en prévision sur le courant dans le cumulus seul, pour un suivi de la puissance transmise et des statistiques.
Il est en effet difficile de traiter certains problèmes aux limites, et dans une grande consommation, sans artifices complémentaires, il est impossible de savoir si il y a production (autrement qu'en lisant le compteur d'énergie des panneaux), mais sans connexion avec  de compteur d'énergie, le router ne peut deviner ce qui se passe...! et donc ne peut agir en conséquence.

5 Emplacement router

Le meilleur emplacement est situé près du disjoncteur général et près du tableau général des protections.
Le problème de la détection de la nuit et l'arrêt du router peut se faire par une horloge interne au PIC ou par mesure du courant de l'onduleur dans mon cas.
Ce dernier cas implique que l'entrée du courant de l'onduleur soit proche du tableau général.

Le router doit aussi avoir accès au branchement du cumulus, et là il y a plusieurs solutions… on verra par la suite.

Pour ma part, et très spécifiquement tout est groupé (Peut-être un peu aussi par accident ?!) et c'est une chance, car les panneaux et onduleurs sont à une centaine de mètres de l'arrivée du réseau EDF. C'était d'ailleurs une incertitude de bon fonctionnement de l'onduleur car la distance est importante et les délais de correction de l'onduleur sont allongés, ainsi que les chutes de tensions en ligne et peuvent lui poser des problèmes.
Vu les sections en place de 4 et 6mm², ces obstacles n'ont pas eu de conséquences, encore que ? Dans les oscillations qui m'ont pourri la vie, cette distance intervient peut-être un peu aussi ?

(L'observation du 230V produit par l'onduleur laisse apparaître une sinusoïde quasiment parfaite, avec une dent de scie extrêment fine, et je doute que les oscillations rencontrées sur le montage router soient issues de l'onduleur ?)

6 Tension et courants

6.1 La détection du zéro de tension

Dans la quasi-totalité des routers, on utilise un signal Z-C (Zéro cross) ou TZ (Time Zéro) pour commuter les courants à partir d'une position relative au zéro de tension.
Le problème des dispositifs bon marché de détection du zéro de tension, est qu'il y a une imprécision de l'ordre de 300 à 500µs et que cela ne me semble pas tolérable face à une demi période qui est de 10ms  soit un rapport de 1/20 alors que l'on se propose de réaliser quelques centaines de mesures.

Ces modules sont mal pensés avec de petites bornes beaucoup trop faibles, des pistes de CI incapables de véhiculer des courants en Ampères et enfin des radiateurs insuffisants sans oublier les TRIACS isolés à la plus petite tension !
Bref c'est Chinois garanti ! 
Il faut donc les améliorer avec des fils de cuivre soudés sur les pistes de puissance et serrer une fois pour toutes du fil rigide dans le connecteur et placer un bon vieux domino pour assurer des liaisons fiables. Il faut aussi percer le radiateur existant pour accoler un radiateur complémentaire.

Le signal de ces petits modules Z-C est issus d'un redressement double alternance avec résistance série en amont et (sans condensateur), ce qui crée un pic négatif qui une fois passé dans un opto-coupleur devient un pic positif.

Pour l'explication, le point précis du franchissement du zéro de tension se situe théoriquement au milieu de ce pic de 300 à 500µs, mais où précisément ? un peu plus à droite, un peu plus à gauche ???

De plus nous avons besoin de la tension pour comparer la phase du courant correspondant, alors un signal carré "alternatif" représentant la tension alternative serait bien plus utile car il contiendrait de fait par ses fronts le point précis Z-C, et par la polarité du signal on saurait exactement dans quelle alternance on se trouve ou on se trouvera juste après.

En l'absence de cette position dans une période, on devrait mesurer après un Z-C la tension sur un nombre de points suffisants pour en déduire dans quelle alternance on se trouve…mais…! J'ai vu des parasites suffisants pour faire changer d'alternance. Il peut y avoir aussi d'autres surprises avec une inversion ponctuelle du courant (Cas des fours micro-ondes par ex. photo ci-contre)

Cette opération par soft est délicate et sujette à parasites et le risque est de se retrouver dans une alternance opposée. De plus, le µ contrôleur ne peut pas passer son temps à regarder la tension pour savoir où il se trouve, car il a déjà beaucoup à faire en nombre de mesures du courant et de la gestion du "Fire".

Le décalage par seuil pour obtenir le point précis Z-C est aussi possible également par un monostable, mais ce principe souvent décrié, n'est pas trop adapté à ce milieu parasité qu'est le secteur 230V.

J'ai donc abandonné le principe du Z-C et de la détermination par soft en utilisant cette fois un signal carré, image de chaque alternance qui est ainsi modifiée. (Voici le Z-C modifié et le nouveau signal ALT ou ALT+ sur la photo ci-dessous)
Le front montant ou descendant est alors le point précis du zéro de tension.

Il existe des circuits spécialisés qui font ce travail mais il faut les commander et pouvoir les remplacer en cas de problème, alors j'ai préféré faire ma petite cuisine dont la pérennité est assurée par l'abondance des circuits très classiques.
Le signal Z-C très imprécis obtenu par redressement double alternance, a cependant l'avantage d'être déjà présent une petite centaine de µs AVANT le zéro réel. A cet instant le niveau de l'alternance sera l'inverse de celui présent à cet instant. (Oscillogramme ci-dessus)

Une bascule D 74HC74 ayant le Z-C décalé par le seuil d'un AOP pour clock (Cp) et le niveau de tension qui fait l'entrée D. La sortie ne sera pas le Q mais le Q* qui représentera l'alternance à venir.
Ce système est plus précis et pratique que ce seul signal Z-C même modifié par un décalage de tension.

Le schéma suivant représente cette amélioration.

Enfin le transformateur séparé, et dédié à la seule mesure de tension n'a plus de raison d'être puisque ce nouveau signal ALT+ représente les 2 éléments essentiels à la comparaison des niveaux  Tension/courant.
On retrouve donc deux opto-coupleurs simples pour le Z-C et la tension suivie par des AOP et la bascule D 74HC74. Certes, cela fait une petite perte d'énergie dans des résistances, mais c'est plus précis, plus sécurisant, plus fiable et en plus non impacté par le cosinus phi d'un transformateur.
Ce montage est actuellement alimenté en 5V par le circuit principal du router, mais il serait tout aussi intéressant de créer sur ce circuit l'alimentation 5V pour le router. Le transformateur présent sur le schéma est l'ancien transformateur pour la tension qui pourrait devenir le transformateur d'alimentation 5V du routeur.

Vous aurez noté la particularité des branchements qui évitent les inversions Phase/neutre, car à ce stade "l'un n'est plus l'autre" sans distinction. Vous devrez aussi lors des branchements bien repérer Phase et Neutre et maintenir cette distinction, de même pour les TI qui devront être repérés, car ils ont aussi un sens !

Le signal essentiel ALT+ est sorti, accompagné (pour l'historique), par le signal Z-C ainsi que le signal inverse ALT-.

L'alimentation du router fournit les alimentations Vcc à ce circuit.
On regrettera aussi l'absence d'un filtre secteur pour l'alimentation du router, car les perturbations secteur sont nombreuses, y compris les courants porteurs du LINKY, car à certains moments, j'aurais peut-être même pu décoder les trames !!!

6.2 Principe des mesures

C'est de loin le point le plus important car j'ai pris la décision de ne mesurer que l'alternance positive d'une période de la tension réseau. Pourquoi ?
La première raison est qu'à cette vitesse du PIC (20 MHz), je n'ai pas le temps de mesurer et calculer une moyenne au cours d'une demi période. J'ai besoin d'une demi période complète plus quelques centaines de µs pour faire ce travail y compris d'autres activités (Surveillance nuit, RS232, puissances…)

La deuxième raison et qu'il faut intégrer le signal du courant et sachant qu'il peut même y avoir des retournements (Points d'inflexions) au cours d'une demi période, (Cas des fours micro-onde par exemple) et il faut un nombre conséquent de mesures au cours de 10ms.
J'ai choisi 180 mesures analogiques par 10 ms ce qui reste possible à cumuler, mais le calcul de la moyenne ne peut se réaliser qu'à cheval sur le début de l'alternance négative.
On comprend mieux alors avec ce nombre important de mesures, pourquoi la précision du point zéro est importante pour étaler les mesures sur la totalité d'une alternance.
Ce choix du nombre 180 est très pratique car il représente la durée angulaire d'une demi période, et en même temps les unités de l'angle d'attaque du TRIAC .
L'alternance négative est disponible partiellement pour d'autres possibilités ou calculs, mais elle reste cependant active (Fire reproduit à l'identique), car la valeur de la précédente période (ou suivant les cas, et plus souvent la demi période positive précédente) définissant l'angle de déclenchement du TRIAC est conservée ou mise à jour au cours cette demi période négative en cours. (Suivant les puissances cumulus et photovoltaïque maxi))

La cadence des mesures est orchestrée par le Timer2 au rythme de 55µs par mesure. Ce timer2 lance également automatiquement l'impulsion TRIAC. Ces éléments de temps ne sont pas hyper-précis car les réponses aux INT sauvent le contexte et des petites variations sont inévitables. On maintient également l'heure JHMS pour quelques délais, mais sans la valeur absolue initiale qui n'est pas traitée, car elle n'est pas essentielle pour le fonctionnement du router.

Dans la partie de l'alternance négative, on peut insérer en fin de calcul la sortie de quelques éléments de debug en RS232, sans pour autant établir le bilan des puissances, car comme je l'ai indiqué, le temps et la puissance de calcul sont comptés chichement. Cette sortie de valeurs ne peut se faire que sur PC avec "Terminal" de Bray++ qui permet des vitesses de 115200 bps.

Je ne l'ai pas encore dit clairement, mais je ne travaille qu'avec les valeurs moyennes vraies et NON les moyennes quadratiques trop difficiles à mettre en œuvre au niveau assembleur, mais surtout trop gourmandes en temps et complexité.

Y-a-t-il un inconvénient à ne traiter qu'une seule alternance au niveau mesures ? A priori je répondrai NON.
Très peu d'appareils branchés sur le secteur ne prennent leur énergie que sur une seule alternance. J'ai bien dit énergie, car en électronique faible consommation on peut parfois ne redresser qu'une seule alternance, mais cela porte sur des mW ou µW et donc parfaitement invisible pour le router qui gère quelques dizaines ou centaines de watts.

Il faut aussi comprendre un aspect délicat qui n'apparaît pas au premier coup d'oeil et qui est de savoir si il y a injection lorsque la consommation de l'habitation est élevée, sans un capteur auxiliaire. En effet les nuages ou la nuit peuvent être tels qu'il n'y a aucune production phtovoltaïque... Mais le router ne peut pas le savoir !
La consommation "vue par le micro" est réputée sans injection, (courant en phase) alors que celle-ci compense la forte puissance. On voit bien qu'il manque un élément pour conclure Injection ou non. (Courant totalement situé dans la partie positive)

En ce sens et pour traiter entre autres le problème de la nuit et des difficiles équilibres d'égalité entre consommation et injection, qu'il m'a été nécessaire d'ajouter un capteur de courant de sortie onduleur qui me permet de savoir si on produit de l'énergie ou non. (Ce capteur ne figure pas dans le synoptique car sa fonction est accessoire mais nécessaire au bon fonctionnement).

6.3 Les grandeurs à considérer

Il faut examiner la puissance photovoltaïque installée ou prévue ainsi que la puissance électrique du cumulus. Dans ces valeurs, il faut au tout début du projet dire ce que l'on veut faire !

Si c'est seulement pour effacer le talon de consommation permanente, alors quelques centaines de Watts sont nécessaires dans la majorité des cas. (De 1 à 4 panneaux de 350 W devraient suffire. Une moyenne standard serait de 2 à 3 panneaux pour un cumulus de 1500 à 2000 W respectivement)
Si au contraire, vous voulez en plus faire de l'eau chaude sanitaire, alors il faudra plus, mais dans ce cas, cela déborde de ce sujet, encore que…. (Une fois l'eau chaude à température, que faire du surplus de watts solaires ?)

Pour ma part 2 panneaux pour mon talon de consommation et éviter de renvoyer de l'énergie sur le réseau sont mes seuls objectifs qui sont atteints et bien cernés au niveau des valeurs moyennes d'ensoleillement et de saisons (Toit capteur à 45° d'inclinaison).
J'ai donc besoin de 2 panneaux et de renvoyer le trop d'énergie vers le cumulus.
Il est également illusoire de considérer que 350W par panneau sont acquis et permanents !

C'est la spécification au mieux, et la moyenne dans une journée même bien ensoleillée est beaucoup plus faible. (Des mesures plus complètes pourraient être faites).
Mon cumulus de 200L (avec échangeur solaire thermique) a une puissance de chauffe électrique de 1500W. On considère alors que 700 W solaires MAXI ne sont qu'un petit complément, voire un simple maintien de la température du cumulus. En ce sens et pour ne pas déraper en consommation par erreur, j'ai limité l'angle de conduction (Fire) à 90° des alternances + et – et l'angle final sera à 180°, valeurs de fin d'une alternance.

Cette valeur de 90° correspond # aux 700W maxi de l'onduleur et 1500W cumulus.
Descendre en dessous de cet angle conduirait obligatoirement à une consommation certaine et serait donc absolument contraire à l'esprit d'un router.

Il faut aussi ajouter que la puissance est une fonction de la forme SIN (2wt) c'est-à-dire de fréquence double de celle du secteur ! Pourquoi ?
Simplement parce que la puissance est issue de chaque alternance et que les alternances se reproduisent au rythme de 100 Hz !
Sur les courbes on voit très bien que vers 90° en remontant vers les valeurs élevées angulaires, les variations de puissance sont lentes, mais maximales vers les 180°. La petite courbe du dessus correspond à la première zone du dessous et correspond donc à 1/4 de la puissance totale d'une période.

Comme la partie négative est également active, on peut donc (Sans aucune consommation autre) contrôler la demi puissance du cumulus par la partie négative du courant (2ème partie ) On assimilera 750W de demi puissance cumulus aux 700W maxi de l'onduleur. (Parties en blanc des courbes)

Il est donc nécessaire, avant toute décision, de mesurer préalablement son talon de consommation "moyen" pour choisir au mieux le nombre de panneaux en correspondance avec la puissance du cumulus, et la volonté de faire quoi !

J'ajouterai que de 1 à 4 panneaux il y a 1 à 2 micro-onduleurs, et qu'au delà de ce nombre de panneaux, ce n'est plus une installation simple, mais souvent une installation avec rachat d'énergie ou stockage d'énergie dans des batteries, et ce n'est plus tout à fait du domaine des amateurs, c'est pourquoi je n'en parlerai pas.

6.4 Le cumulus

("Cumulus" pour la simplicité d'écriture, c'est aussi la même chose que le chauffe eau).
Cet appareil standard est raccordé normalement sur le 230 V (Parfois en triphasé mais le principe reste identique). Il est équipé d'un thermostat qui coupe Phase ET Neutre mais habituellement on ne coupait que la phase, (comme dans un interrupteur d'éclairage).

Ce point est gênant et j'ai été obligé de supprimer cette coupure du neutre. Je ne pense pas que cette absence de coupure du neutre soit dans les normes, mais elle est indispensable, car pour diriger l'énergie en trop, provenant du router, il est nécessaire d'attaquer directement la résistance du cumulus, en ignorant le thermostat, mais encore faut-il que le retour de courant puisse se faire par le neutre ! C'est la raison pour laquelle cette coupure du neutre du thermostat doit être court-circuitée.

Attention cela ne porte pas à conséquences dans mon contexte des puissances respectives, mais dans le cas d'autres puissances cela peut être dangereux. (cas où la puissance photovoltaïque est égale ou supérieure à la puissance du cumulus, par ex...)

Quant aux températures, et dépassement possibles, dans mon installation , le risque reste très faible car la puissance solaire de 700 W (Maximum) représente # la moitié de la puissance de chauffe d'origine. Au pire, un petit thermostat 90 ou 95° pourrait être ajouté.

D'autre part, mon installation a été prévue en triphasé, mais finalement ça a été abandonné lors de la souscription initiale du contrat EDF mais les liaisons des appareils de puissance sont bien sur 5 fils : 3 Ph Neutre et terre.

J'utilise donc ces fils des trois phases séparément avec le neutre commun.
Le fil Ph 1 alimente une prise de courant standard (Non représenté).
Le fil Ph 2 arrive sur un interrupteur PAC20 de commande exceptionnelle du chauffage électrique, car ce cumulus est avec échangeur solaire thermique (non représenté), et n'a pas vocation à être électrique en permanence.
Le fil 3 est utilisée par le TRIAC du router.

Il est évident que ramener du 230V par ce PAC20 sur la sortie du TRIAC fait l'objet d'une belle détonation et du noircissement du CI. Lorsque l'on "tripatouille" dans cet environnement, on se prend parfois quelques châtaignes qui ne font pas plaisir.

Cela reste dangereux, et très technique et je me dois de décourager les bricoleurs qui n'ont pas suffisamment de compétences en ces domaines électriques, car bien que je sois au fait, je me suis tout de même fait prendre, sans dommages heureusement ! Attention aux personnes fragiles et veiller à respecter les normes C18510 (de mémoire)

Alors pour éviter ces flashs de retour de courant, j'ai du installer un contacteur sur le cumulus qui coupe le circuit du TRIAC si par mégarde on veut chauffer normalement par le PAC20 avec le router en fonctionnement. Ce circuit du contacteur n'est sous tension que par le PAC20 et isole donc l'entrée de tension issue du TRIAC par la phase 3.

NOTA : Ce contacteur repos / travail s'il est excité, coupe en premier le fil issu du TRIAC pour un groupe de contacts et quand il arrive quelques 20ms plus tard au travail, il établit le contact sur le PAC20 par un deuxième circuit.

Si votre cumulus n'a pas les 3 fils d'alimentation, alors vous pourrez choisir de passer un deuxième fil ou de choisir soit le 230V permanent ou le TRIAC sur l'unique fil, par un commutateur de puissance.
Cela ne résoudra pas cependant la légalité (?) de coupure du neutre sauf si on double les contacts !

Enfin, si cela vous parait compliqué, vous pouvez chosir de mettre un simple inverseur manuel sur l'alimentation standard (avec thermostat), mais dans cette hypothèse dès que la température sera atteinte, il y aura injection sur le réseau et perte d'énergie (pour vous)
Ce cumulus est bien compliqué à gérer avec de nombreuses contraintes. En hiver vous pourriez utiliser ce trop plein d'énergie pour un radiateur électrique, mais en été que faire si le cumulus est trop compliqué à gérer ?

La climatisation ne peut pas convenir en termes d'utilisation du trop plein d'énergie car les puissances, cosinus Phi, et les appels de courant sont conséquents et incompatibles à une faible puissance.

Une bonne solution serait qu'EDF ou ENEDIS (On ne sait plus très bien qui !) vous paye ou vous déduise ces retours excédentaires d'énergie vers le réseau.
Ceci est tellement vrai que le compteur LINKY est tout à fait en mesure de faire la différence entre la consommation et l'injection.
La façon dont EDF peut rétribuer ce retour est ultra simple, car ces retours d'énergie interviennent en soustraction des consommations. Cette possibilité résulte seulement d'un paramètre LINKY pour que cette soustraction se réalise automatiquement.
Cette mesure reste avant tout une décision politique alors sur ce point, que faire ?

Eh bien en attendant la lenteur et l'incompétence technique des politiques, il vous reste le router à fabriquer….
Passons à autre chose !

7 Le montage

7.1 Historique

Rappelez vous j'avais réalisé un boîtier d'affichage du compteur LINKY. Boîtier en liaison par fibre optique, jusqu'à l'intérieur de l'habitation avec affichage Intensité et puissance, et à l'époque j'avais regretté le manque de précision des valeurs transmises. La vitesse de transmission n'était pas bien élevée à 1200 bits/s et j'ai pu vérifier que l'affichage était loin d'être instantané. J'avais cependant prévu en cas de difficultés technique de me rabattre sur cette solution. (Voir les liens ci dessous)

http://bricolsec.canalblog.com/archives/2020/09/22/38548059.html   Afficheur LINKY_HOME (Montage N°3)
http://bricolsec.canalblog.com/archives/2020/03/16/38104053.html   Interface LINKY fibre optique USB (2 ème partie)

Je me doutais aussi que pour afficher à des vitesses folles des valeurs, j'aurais besoin d'un afficheur à 115200 bauds, ce que j'ai aussi réalisé préalablement, mais la lenteur intrinsèque des displays LCD m'a empêché d'utiliser directement cette possibilité on-line.
J'ai du me rabattre sur l'ordinateur et le logiciel "Terminal" comme d'habitude ! Cette possibilité du display reste utile, mais pour extraire un résumé de quelques valeurs, mais pas pour le "fil de l'eau".

http://bricolsec.canalblog.com/archives/2023/01/28/39794583.html  Display 115200 bps.

Enfin j'avais prévu un encodeur en quadrature pour rentrer quelques valeurs et notamment l'heure.
Sur ce point j'abandonne de rentrer des valeurs d'horloge car ce n'est pas vital et le positionnement horaire ne sert strictement à rien (Hormis pour d'éventuelles statistiques).
Cependant l'horloge interne du PIC est synchronisée au rythme de 50 Hz, avec les 1/100 de secondes, secondes, minutes et heures et même les jours, mais sans mise à l'heure de départ.
J'ai maintenant bannis cette possibilité par l'utilisation du connecteur de l'encodeur au profit du signal ALT+ non prévu à l'origine, mais il reste le switch qui pourrait permettre une entrée manuelle de valeurs en initialisation, et cette possibilité ne sera même pas vue ultérieurement car trop… ouf!

Il y a bien longtemps, j'avais récupéré des Transfos d'Intensité "VAC" (A circuit magnétique sans ouverture) et toujours en cas de difficultés j'avais aussi pensé en utiliser un pour mesurer le courant le l'onduleur ainsi que le courant du cumulus.

Cette idée répondait à l'utilisation du LINKY pour connaître la puissance enregistrée par le LINKY et agir en conséquence. Cette information de puissance transmise par le LINKY à 1200 bps est beaucoup trop lente et de plus à 10W près et ne peut pas être utilisée sans consommations de quelques secondes, et peut être avoir des difficultés pour maîtriser les oscillations.

Aujourd'hui cette utilisation du TI Onduleur est dérivée pour évaluer l'heure à laquelle il faudra couper le router le soir et éviter la consommation des deux relais. Ce point se fera simplement par la luminosité et donc le courant onduleur quasi nul  de nuit (<50mW). Pour éviter les oscillations marche/arrêt éventuelles, on regardera seulement toutes les 1 minutes si la situation a changé.
Ce Ti a aussi une autre vocation qui est de surveiller le point d'équlibre consommation/injection, point délicat qui nécessite d'arrêter temporairement la régulation car les écarts sont tellement faibles, que l'on entre en oscillations.

(Un autre TI spécifique Cumulus est mis en place et permet simplement de visualiser la conduction du TRIAC sans avoir à faire attention au 230V …) Je l'ai maintenant débranché car il perturbe la référence de 2.5V (En attendant un nouveau circuit ?...)
(Photo ci contre avec le signal ALT+ qui montre bien la fin d'une alternance sur chaque front)

Au vu de la RS232 du LINKY, d'un éventuel GPS donnant l'heure ou d'un autre circuit mais aussi d'un ordinateur pour le debug (FTDI), de l'afficheur à 115200, j'ai prévu un multiplexeur pour tout ce qui concerne la RS232.

Enfin pour les économies d'énergie, je pensais aussi à utiliser l'ULPWUE, mais c'est vraiment se faire plaisir, alors cette possibilité ne sera pas utilisée.

Pour ne pas être "serré aux entournures", j'ai tout de suite choisi un PIC 16F886 de 28 pins. C'est très large, mais je ne voulais pas être trop juste pour ce dernier projet d'envergure, et je m'en félicite, (Mais un PIC16F690 pourrait convenir avec quelques facilités en moins ?)).

Vous avez maintenant une idée des motivations qui ont conduit à la création du schéma.
Certaines idées ne serviront pas, d'autres seront détournées.

Le choix des résistances Burden a été fait en fonction des courbes relevées réellement et pour un meilleur niveau et une bonne linéarité sans saturation aux valeurs élevées de courant.
(Valeurs principalement en correspondance avec la puissance de chauffe du cumulus et celle des panneaux solaires).

Les niveaux d'entrée ANA sont tels que au-delà des 1500W du cumulus (et j'irais même jusqu'à dire des 750W maxi des panneaux), cela ne représente aucun intérêt pour le montage qui n'a d'utilité qu'aux faibles courants.

7.2 Le schéma

Ci-dessous, le schéma actuellement en place, avec des modifications faites, défaites, puis refaites...
Bref ce schéma est maintenant assez stable et on va le commenter dans les paragraphes suivants de l'article, mais aussi dans les Annexes situées en fin d'article.
(Ces Annexes ont été dès le départ des pense bêtes pour ne pas oublier, les principes sont réels, mais la réalisation a pu évoluer.)

Schéma:

Pour le circuit imprimé, celui-ci n'est pas à jour, mais n'a pas de très grandes modifications. Cette réalisation est seulement donnée comme idée d'implantation.

A noter qu'au niveau réalisation une plaque de LEXAN couvre largement les 2 relais, car il y a le 230V et c'est absolument nécessaire pour ne pas se faire prendre.
Dans le feu de l'action et principalement en mise au point, un contact avec le 230V est si vite arrivé !
Faites le, c'est essentiel et votre vie qui peut être en jeu

7.3 Entrées

J'ai repris le système des entrées, utilisé par l'association P'titWatt avec un point milieu à 2.5V qui est bien adapté au sujet, car il ne génère pas de tension de déchet.

Initialement, pour ce point milieu, j'avais utilisé une zener programmable LM385-1.2 avec résistances, mais le mieux était l'ennemi du bien et il avait été largement préférable d'utiliser un pont de résistances qui va dériver au besoin avec le Vcc sans modifier de façon appréciable les conversions AN. (Pont unique pour les 3 entrées).

Au fil des mises au point, je me suis aperçu que ce niveau de 2.5V reste bien stable alors que suite à un incident sur le 5V, il  se réduisait sensiblement. Alors je pense que j'ai repris mon schéma original qui a l'avantage d'être très stable (Dans la mesure où le
5 V l'est, ce qui est le cas normal).

Alors faire, défaire et refaire est la meilleure solution ! Désolé, je reviens cette fois à une zener programmée LM385-2.5, mais un régulateur 2.5V est maintenant très habituel. Cette fois c'est le bien qui est l'ennemi du mieux !!! Voir en annexe des propositions plus adaptées à ce sujet.

Les tensions d'entrée vont normalement dépasser les 5V cc mais seront écrêtées par les zeners tête bêche, et seule la première partie linéaire est utile au vu des puissances considérées. (Attention aux puissances des Zeners qui sont à calculer pour la puissance totale souscrite auprès du fournisseur d'énergie)

On remarquera qu'il est cependant très important de protéger ces entrées issues directement ou par un TI, des parasites, et notamment des parasites HF des CPL (Courants Porteur en Ligne) du LINKY.

A cet effet j'avais prévu un petit filtre coupe bande pour les fréquences 63,3 kHz à 74 kHz, (LINKY modèle G1) mais il y a de nouveaux systèmes LINKY G3 avec des jeux de fréquences comprises entre 35,9 et 90,6 kHz, alors encore une fois, un bon vieux condensateur de 0.1µF avec une résistance de 470K de décharge et polarisation d'une entrée ANA fera l'affaire, ainsi tout ce qui est HF sera rejeté, et les pics éventuels seront adoucis pour tous les modèles de LINKY.

L'entrée de tension est devenue maintenant inutile grâce au signal ALT+ généré sur la carte de distribution 230V.

7.4 Les relais

Ceux-ci coupent le 230V de chaque côté du TRIAC par mesure de sécurité, car j'ai eu une petite explosion d'un TRIAC dûe à un retour du cumulus sur la sortie TRIAC.
Ces relais sont assez économes en courant (36mA), mais j'ai prévu de les couper la nuit. Je regrette un peu ces relais asiatiques peu pratiques à l'implantation, car les proximités avec le 230V et l'alimentation des bobines sont évidentes, mais les marques connues étaient de dimensions trop importantes et de consommation un peu excessive.

Ces relais sont commandés par des MOSFET_N. Ces relais ne devraient pas trop s'user car ils ne coupent aucun courant (ou très faible) et sont principalement là pour assurer la continuité électrique.

Un point à souligner est la présence de voyants sur chacun. C'est simple et ça permet de savoir un peu ce qui se passe très rapidement. (Moins de 1mA de LED ne vaut pas la peine d'y renoncer…)
Ils consomment chacun 36 mA sous 12V soit 1 W pour les deux et ne sont même pas régulés en tension, mais simplement alimentés par une petite résistance chutrice.

7.5 Le multiplexeur

Son rôle est de permettre plusieurs entrées RS232, afficheur, ordinateur avec FTDI, LINKY. Un Mux 4 entrées est utilisé car il n'est pas exclu de connecter un GPS ou autre, pour faire la mise à jour de l'heure…

Un 74HC4052 fait le travail, mais pour l'instant il reste sur sa sélection 0 car il n'y a rien d'autre de connecté, et de plus la connectique reste réduite.

C'est du projet qui ne verra cependant pas le jour maintenant, mais chacun peut y penser à son aise et modifier quelque peu le schéma pour utiliser une entrée complémentaire, notamment pour mise à l'heure...etc

7.6 Les LED de contrôle

On vient de parler des relais qui sont équipés de LED.
D'origine du schéma j'avais prévu une LED D14 qui a été réaffectée au mode de fonctionnement en Injection ou Consommation. Ce voyant clignote au rythme de la régulation. (Injection allumé).

Dans les autres cas, il est allumé en permanence si on injecte du courant et éteint si on consomme au delà de la fourniture du panneau. Il clignote le plus souvent lors de la régulation.

Sur le circuit 230V le voyant bleu ALT est allumé en permanence (Clignotement à 50 Hz non visible en réalité)

Enfin, sur le module TRIAC, il ya aussi d'origine une LED "Fire" qui s’allume à chaque ordre de feu du TRIAC. Ne pas confondre cette LED avec la D14 qui représente le signal INJECT qui n'est pas tout à fait le signal Fire car ces LED écclairent souvent ensemble mais pas toujours !

7.7 Conclusions schéma

Rien de particulier au niveau matériel, tout a été largement dimensionné pour pouvoir évoluer, car les nombreuses I/O non utilisées servent au debug, car parmi les signaux affectés à des I/O de contrôle on trouve ALT+ en RB0, Z-C en RB1, Inject en RB2, et les interrupts Timer2 en RB4.
Tous ces signaux permettent de comprendre un peu mieux ce qui se passe, car les problèmes de timing sont importants et les temps sont serrés.

On peut voir sur ces deux images capturées avec le simulateur et horloge à 20.MHz le reste du temps avec PR2=67 et PR2=68.
Il serait risqué de faire mieux, (au risque comme on dit "d'aller bouffer dans la gamelle du voisin !)

Sur ces relevés, on voit les différents points cruciaux qui sont indiqués en rouge.

Le PR2 permet de figer et de répartir le comptage des mesures, tout autant de calibrer le Fire_Byt et le Z-C (non utilisé maintenant).

Sur la Première simulation, le PR2 est à 67 et laisse une bonne distance avant la fin du signal ALT+.
Cette distance permet de faire une partie des calculs et laisse une marge suffisante en cas de légère variation de la fréquence secteur.

Sur les 2ème et 3ème simulations, avec PR2=68, on constate que la sécurité n'est plus que de 45µs, ce qui est tout de même un peu "serré" en cas de légère variation de fréquence secteur.

C'est grâce à ces simulations que j'ai pu vérifier les différents timings.
De plus comme ces éléments sont reportés sur des I/O en sortie, sur la mise au point réelle, on peut également vérifier au scope ce qui se passe.

Sur l'agrandissement, on peut remarquer que le Z-C (qui n'est plus utilisé), est calculé par le ALT+ et qu'en conséquence il est décalé de quelques instructions, mais est conforme (comme le "Fire") à 5 Int TMR2.
Quand on regarde les 180 interrupts qui déclenchent une mesure ANA, on se rend compte qu'il faut réellement aller très vite pour régler de "malheureux problèmes de 50 Hz" ! C'est ainsi !

8 Le programme

Le programme a beaucoup évolué suite à des erreurs de compréhension, car j'avais pensé au départ utiliser une table pour affecter directement l'angle du Fire à la bonne valeur. Bien entendu une fois affectée la valeur du Fire, la situation était toute autre ! Stupide ! Il a beaucoup évolué aussi à cause des fonctionnements aux cas particuliers et également pour n'avoir pas bien identifié la double régulation et les conséquences.

J'avais aussi voulu différentier les brutales variations de consommation, surtout lorsqu'elles sont vers la consommation, mais cette séparation complique beaucoup les choses et j'en suis revenu simplement à réguler le Fire par des incréments ou décrément de l'angle du Fire toutes les 10 ms.
Il ne faut pas se leurrer, ces consommations ponctuelles restes anecdotiques car leur durée est très faible.
Le principal écueil est l'oscillation sur des variations importantes de courant, aussi bien dans un sens que dans le sens opposé.

Je dois avouer humblement que je n'ai pas parfaitement embrassé la totalité des phénomènes, et que le sujet est encore chaud.
Le but premier est d'utiliser le trop d'énergie, aussi, tout est fait pour ne pas consommer, même de façon légère. Ainsi les comparaisons sont toujours vers une minuscule réinjection sur le réseau plutôt qu'une légère consommation.

Là aussi, je suis revenu à cette notion de table, car lors d'un épisode brutal dans un sens comme dans l'autre (Injection ou consommation), mais surtout injection, on ne sait plus très bien à quel niveau on se situe car ce niveau oscille du mini au maxi.

Il faut donc dans une alternance appliquer rapidement la courbe de puissance correspondante pour bloquer ces oscillations et revenir à une situation de régulation par incrément/décrément.

Cette table à l'image d'une courbe de puissance est ordonnée de 90° angulaires à 180° et directement en valeur des mesures analogiques. (Voir les courbes ci-dessus au § 6.3)

Cette table est scindée en 3 parties de valeurs 16 bits et une partie en 8 bits. Ceci dans le but de trouver rapidement une valeur proche de la mesure ANA. Cette valeur trouvée donne par sa position dans la table l'angle du "Fire" par valeur supérieure pour ne pas consommer.

On peut dire que cette table est compliquée à souhait pour être rapide. Elle est creuse car toutes les valeurs ne trouvent pas de correspondance mais sont souvent encadrées par des valeurs inférieures et supérieures. La recherche est donc assez longue d'autant que l'on doit rester d'un seul côté pour ne pas consommer.

La partie de table 8 bits est organisée à l'envers pour le parcours le plus probable et gagner ainsi du temps. (Les valeurs vers 90° étant les moins fréquentes).

8.1 Le principe du Timer 2

Ce timer2 est particulièrement utile pour gérer le Fire, car il fonctionne sur la base d'une comparaison entre les registres TMR2 et PR2. Dès l'égalité une INT est générée. Le signal d'horloge du PIC Fosc/4 étant d'abord divisé par 4, puis compté dans TMR2. A l'égalité tout est remis à zéro et un nouveau cycle recommence. Ce cycle d'INT est de 55µs, et le cycle global de #10ms bien entendu !
55µs x 180=9.9 ms ! Comme ça s'arrange bien face à une demi période de 10ms.

Si le cycle est synchronisé au départ par le Signal ALT+, il est nécessairement légèrement plus court que 10ms, car autrement le fire tomberait en tout début d'alternance et là ce serait de la surconsommation, inacceptable et à l'inverse du but recherché.

Cela signifie aussi que l'on ne pourrait jamais atteindre l'extinction complète du triac...? Un blocage du fire dans quelques situations permettra de gérer au mieux cette difficulté, sans pour autant perdre le Fire_Byt qui est alors masqué.

Ce cycle de mesure doit pouvoir s'ajuster au mieux pour palier quelques irrégularités de la fréquence du réseau et c'est surtout pour cela qu'il faut être légèrement plus court.

8.2 Le cycle de mesures

La première règle consiste à ne mesurer que sur l'alternance positive car c'est plus simple de "manipuler" du positif ! On admettra le principe de la symétrie des alternances positives et négatives (Voir les points particuliers en annexe)

Dans ce sous-programme de mesure, on réalisait initialement 180 mesures de courant, mais pas seulement, car ces 180 mesures étaient faites en séquence sur 2 à 20 périodes (Variable Nb_ALT) soit de 40ms à 400ms paramétrable en EQU dans le programme.

Cette méthode avait l'inconvénient de générer une moyenne qui ne représentait plus la réalité de l'instant, car un interrupteur de baissé sur un radiateur de 1000W par exemple fait une montée en courant sur 1 à 2 périodes, cela en fonction de l'impact précis sur la courbe sinus de la tension. (voir oscillogramme ci-dessous avec une mise en marche immédiatement suivie d'un arrêt)

Cette méthode de moyennes de plusieurs mesures consécutives n'est pas bonne et je suis revenu à de la mesure instantanée avec 180 mesures sur la seule alternance positive.
Le sous-programme de mesure réalise les mesures espacées de 55µs par l'entremise du Timer2 qui donne le Top et calcule la moyenne des courants directement en pas du convertisseur ANA, sans prendre aucune décision et retourne simplement cette moyenne des 180 mesures .

Suivant la position de la moyenne des mesures par rapport au point milieu situé 2.5V, il génère le signal INJECT (Voyant D14 associé), qui s'il est à 1, témoigne de l'opposition du courant avec la tension, donc de l'injection.

A zéro,  ce signal peut témoigner différents états (dont la consommation sur le réseau EDF avec courant en phase avec la tension en régulation).

On comprend que le choix du nombre de périodes de mesures est un choix important.

Par exemple, j'ai regardé ce qui se passe sur un impact de courant de consommation, et suivant l'endroit de l'impact de charge (2 KW) dans la sinusoïde, il peut falloir 1 à 2 alternances complètes pour que le courant moyen atteigne sa valeur.
(Ceci d'autant que sur les charges résistives, le courant change avec la température) (Oscillogramme ci-contre)

La division par 180 des mesures pour avoir une moyenne, ne peut se faire qu'à cheval sur l'alternance négative suivante, car les temps ne permettent pas de tout faire à la fin de l'alternance positive, dans le, tout petit créneau de temps restant. (voir § 7.7 pour les temps restant en fin d'alternance +)

C'est durant l'alternance négative, que l'on va regarder le signal INJECT, et s'il est à 1, cela signifie que l'on retourne un peu d'énergie sur le réseau et qu'il faut donc commander le TRIAC un peu plus en avance, soit diminuer l'angle du Fire pour augmenter la consommation dans le cumulus.

Réciproquement s'il est à zéro il faudra augmenter l'angle pour diminuer le retour d'énergie vers le cumulus.
Cette nouvelle valeur du Fire sera appliquée en principe sur l'alternance négative adjacente si les temps de calculs ne dépassent pas 5ms (90° du fire)

(Il faut faire attention de ne pas se tromper car augmenter le courant dans le cumulus doit diminuer l'angle d'attaque du TRIAC et réciproquement)

Cette partie d'envoi du Fire est totalement traitée au niveau de l'INT du Timer 2, car elle demeure assez courte et ne perturbe pas exagérément le programme. (La largeur de l'impulsion de commande du Triac est paramétrée dans le programme (En modulo 55µs).
Il est certain que des interrupts vectorisées avec sauvegarde du contexte seraient géniales, mais à mon âge je ne vais pas faire une étude sur un nouveau micro-contrôleur plus performant ! Désolé ! A vous les jeunes !

C'est finalement assez simple dans l'esprit et les principes, mais des tas de cas particuliers existent et sont souvent difficiles à traiter….

A cela il faut ajouter le contrôle du jour et de la nuit toutes les 1 ou 2 minutes pour couper les relais et éviter de les griller, car ils sont actifs très longtemps, mais ne coupent jamais les courants et les contacts ne devraient pas être usés.

Un des points essentiels est de ne pas dépasser le signal ALT+ à la 180ème mesure. En ce sens le registre PR2 est calé à 67 mais pourrait être plus proche à 68, mais avec un risque en cas de petite baisse de fréquence du réseau de "taper" en dehors des limites et d'induire la consommation totale du cumulus.

(Une anecdote qui a défrayée les radios locales : Suite à l'interconnexion des réseaux électriques Européens, une baisse globale du nombre de périodes avait eu lieu il y a 1 ou 2 années, et elle avait entraîné un retard des radio réveils des usagers et un retard d'arrivée au travail !!!) Ceci témoigne que la variation de fréquence est non seulement possible mais s'est produite !

Actuellement je suis avec un quartz de 20.250 MHz, et j'ai abandonné le quartz à 20.480 MHz un peu trop éloigné du datasheet de ce PIC.
20.250 MHz est plus conforme aux spécifications d'horloge du PIC. Il sera aussi plus proche du maxi de 10 ms, tout en laissant quand même un peu de marge face aux nombreux aléas pouvant survenir. (Cette valeur peut permettre aussi un PR2 à 68)

Le fait d'être en position de nuit sera visualisé par l'arrêt des 2 relais (LED éteintes)

Dans les versions ultérieures, la mise à l'heure précise pourrait être faite par appui sur le seul switch au moment de l'initialisation, mais je reconnais que ce n'est pas bien pratique. Le mieux serait de prendre l'heure directement ailleurs (GPS, DS1307…etc) à vous de faire !
Ces nouvelles fonctionnalités, ne peuvent être réalisées qu'avec un nouveau circuit imprimé, car la connectique manque. Il serait vain de bâcler cette partie car lorsque l'on manipule le 230V, il faut rester vigilant et faire le mieux possible en évitant les "bidouilles" qui peuvent devenir des sources de gros problèmes, même avec des protections correctes.

9 Conclusions

9.1 Panneaux photovoltaïques, obligations légales

Ce projet de router fait évidemment suite à mon installation de 2 panneaux photovoltaïques en auto consommation, et comme ENEDIS n'autorise pas (En théorie) de retour d'énergie, (Alors que tout le monde sait que c'est quasiment impossible dans ce type d'installation) j'ai essayé de respecter cette obligation pour 2 raisons :

- Cette énergie qui retourne dans le réseau serait perdue pour moi qui ai payé mes panneaux et ne profiterait pas pleinement à mon investissement.

- En deuxième lieu je suis en règle avec ENEDIS, ce qui est mieux et j'évite de leur laisser de l'énergie gratuite !

Peut-être que cette interdiction est simplement voulue pour que l'on ne puisse pas réclamer d'indemnisation pour l'énergie réinjectée ? C'est ainsi plus facile et tout bénéfice pour le producteur ?

Concernant les panneaux, j'ai eu de la chance de retrouver mon certificat du CONSUEL qui date de 50 ans ! Sans ce document pas d'autorisation possible sans une nouvelle inspection (Payante naturellement).

J'ai aussi la chance pour l'instant que l'onduleur HOYMILES ait été homologué (Obligatoire au niveau ENEDIS) et fonctionne parfaitement, et cela c'est un peu grâce à la Société SOLAR COOP et au conseil de l'Association GAÏA Énergie de BELFORT que j'avais consultée avant mon installation de panneaux.

(Voici également l'oscillogramme du courant généré par l'onduleur... Il est vraiment parfait !)

Pour la prise en compte des principes, un merci aussi à l'association P'tiwatt qui a réalisé un projet en langage C sur un autre micro plus puissant, mais ma préférence est pour l'assembleur et les micro PIC que je connais bien pour les avoir largement utilisé. Les informations données m'ont permis de développer mon propre système router, certainement très différent et beaucoup plus restreint au niveau programmation des résultats.

Ce qui n'est dit nulle part est qu'il faut une Demande Préalable (DP) en mairie, même pour installer seulement 2 petits panneaux en toiture, mais que cette demande est le plus souvent retransmise aux organismes publics centralisateurs régionaux qui édictent encore des textes débiles comme l'obligation d'insérer les panneaux dans la toiture.

Heureusement mon Maire est bienveillant et parfaitement d'accord de les mettre en applique sur les tuiles, car au final c'est lui le décideur. Ces aléas administratifs sont pénibles, mais il reste encore une solution si ça se passe mal, qui est de mettre les panneaux au sol. Dans ce cas pas de DP nécessaire !

Je dois dire aussi que la solution au sol en tracking m'aurait bien plu, mais c'est trop de travail à l'aube de mes 77 ans….

9.2 Le Router

Il est encore en essais et semble bien répondre à sa fonction. Il y a encore des modifications à apporter, mais le cœur du projet est bien avancé et est déjà opérationnel , et il s'agit seulement d'améliorations ou extensions sans impact direct ou remise en cause du principe de régulation.

Un point toujours en étude est le cas où production et consommation sont presque identiques. Ce cas génère souvent des oscillations néfastes et consommatrices.

Il n'y aura pas de complément à cet article faute de temps.

Cette application reste globalement simple tant au niveau hardware que logiciel mais elle est cependant pointue sur deux parties, notamment sur la détection du zéro de la tension, car cela conditionne tout le bon fonctionnement du programme.
Elle est pointue également sur la gestion des Interruptions sur les signaux ALT+ et la gestion du Timer2.
Elle est pointue aussi sur tous les phénomènes d'oscillations qui empoisonnent tous les cas particuliers de cette double régulation production solaire associée à des consommations ménagères imprévisibles.

Le programme source assembleur dans son état au jour d'une demande sera en transmis gracieusement aux seules personnes physiques qui en feront la demande pour leur usage personnel et sous leur seule responsabilité, mais ne pourra pas servir directement de base à un projet industriel sans mon accord et ne sera jamais mis à jour par la suite.
Pour toute question sur cette application, me contacter par le lien "Contacter l'auteur".
(Les commentaires étant bloqués suite à quelques spammeurs idiots…!).

__________________________________________________________________________________________________________________

10 Annexe des Points relevés avant et pendant la réalisation

10.1 Horloge PIC à 20 MHz

Avec quartz pour la précision.
Comme les temps sont extrêmement serrés, et pour la certitude d'être bien positionné dans une demi période, j'ai utilisé plusieurs quartz : 20.000 MHz, puis 20.480 MHz à PR2 68 et maintenant 20.250, bien que cette petite augmentation soit hors limites du constructeur. C'est si faible que l'on peut considérer que c'est la seule dispersion de composants. Ces fréquences n'affectent même pas le générateur de bauds qui continue de bien fonctionner pour la vitesse prévue de 115200 bps.
Tout ce qui concerne les temps ne se trouve pas "balayé" par cette petite augmentation et rien ne sera fait par ailleurs pour compenser cette modif.
En dernier lieu le quartz est donc repassé définitivement à 20.250MHz et le PR2 à 67 ce qui semble compatible avec une meilleure répartition sur les 180° et de ce fait réduit à une valeur acceptable l'écart entre la fin des INT du TMR2 et le front descendant du signal ALT.
NOTA: Le simulateur n'accepte pas les décimales de mégaHertz.

10.2 Temps de mesure ANA

A 20 MHz, le TAQ avec Rs=2 K peut être de 3µs et le TAD à 1.6µs si Fosc/32 soit 11 TAD=20.6µs
Une mesure coûte donc en arrondi =25 µs
On utilisera ADFM=1 avec les 2 poids forts sur le deuxième octet

D'une façon générale on fera 180 mesures sur une demi période de 10 ms avec une résolution de 10 bits, soit théoriquement 360 octets (10 bits) représentant le courant au niveau du disjoncteur général.
Ce courant sera une consommation de l'habitation ou au contraire une injection de courant vers EDF suivant qu'il sera Supérieur ou Inférieur à 2.5V respectivement  .
Ce nombre de 180 ne sera plus augmenté d'un nombre d'alternances adjacentes supplémentaires de quelques unités pour moyenner les mesures car cela est néfaste aux impacts de charge ou de libération de charge.

Nous n'avons pas les moyens de stocker autant de mesures pour en faire la moyenne. On fera donc la somme instantanée des valeurs 16 bits vers un cumul 24 bits qui est rapide et on divisera ensuite par 180.
Cela représente tout de même au maxi 9000 mesures analogiques par seconde et c'est conséquent.
Le courant mesuré par un TI (Transformateur d'Intensité) est converti en tension dans une résistance (Burden) au secondaire du TI. Cette tension est limitée par des zeners avec résistance chutrice.
On choisira cette résistance pour ne pas saturer aux faibles courants mais aussi pour avoir la valeur la plus élevée possible depuis 0 Ampères jusqu'à la valeur de courant correspondant à la puissance des panneaux, soit dans mon cas, 2 panneaux pour 700 Watts soit environ 3 A sous 230V.

(On n'a donc aucunement besoin de repasser par les puissances (Multiplier par 230) puisque c'est proportionnel)

10.3 Moyennes / sécurité des valeurs mesurées

Les courants issus de l'électronique et du redressement sont des courants qui ne ressemblent plus à des sinusoïdes mais sont totalement déformés.
Aussi on est obligé de passer par des valeurs moyennes, car on peut toujours parler de valeur efficace, mais on ne peut plus la mesurer de façon simple (valeur communément utilisée par tout appareil de mesure en régime alternatif SINUSOÏDAL).

Je laisserai de côté la moyenne quadratique car je ne peux pas extraire une racine carrée et pas plus élever au carré avec les matériels dont je dispose et des contraintes de temps.
On fera donc une mesure toutes les 55 µs de la valeur instantanée du courant, et à la fin des mesures on calculera simplement la moyenne de ces 180 mesures que l'on divisera au final).

En réalité j'avais réalisé des mesures multiples sur plusieurs alternances positives, mais elles avaient l'inconvénient de reporter et de moyenner des informations cruciales.
J'ai donc abandonné cette méthode et je ne mesure qu'une seule fois une alternance positive avec application dès l'alternance négative du "Fire" (si possible !).
Ceci à condition que les temps de calcul ne dépassent pas la moitié de la demi-période négative, car c'est à partir de cet instant (90°) que l'on peut lancer le fire (Puissance cumulus environ double de la puissance photovoltaïque).
Cette mesure détermine si l'on est en production ou en consommation quelque soit la forme du courant, et c'est justement là que c'est très important.
Je m'arrangerai de toutes façons pour être toujours en petite injection, ce qui est la base, en effet, j'éviterai d'accepter la plus petite consommation, car aux limites je serai toujours perdant sur une petite variation. L'essentiel est d'avoir une bonne sauvegarde du surplus, sans viser le dernier Wh à préserver.

10.4 Point de référence à 2.5V

Tous les courants sont mesurés par rapport à une référence de +2.5V. A l'origine j'avais prévu une solution globale avec un LM385-1.2 avec pont de résistances, pour référencer à 2.5V.
Suite à un accident dans la consommation du 5V qui s'était abaissé sensiblement , je m'étais aperçu que cette tension restait parfaite à 2.5V (et que le 5V baissait). De quoi fausser totalement toutes les mesures ANA. Alors je suis revenu à la solution p'titwatt… avec pont de résistance découplé, mais....

Récemment suite aux oscillations lors des retours d'injection (Arrêt d'une forte puissance consommée) j'ai contrôlé de nouveau cette référence de 2.5V pour m'apercevoir qu'elle bougeait lentement et là aussi cela faussait les mesures ANA.
Pas question de créer un deuxième circuit imprimé, trop long, alors je suis revenu cette fois à la solution d'un LM385 mais cette fois un LM385-2.5, ce qui me garanti une tension stable. J'ai remplacé le condensateur de 47 µF par un 17µF CMS bien meilleur au niveau des pertes.

Il subsiste cependant une très légère ondulation dont je n'ai pas la certitude tant elle peut provenir aussi d'inductions parasites. (C'est trouvé, c'est l'ajout du courant cumulus qui perturbe !) Il est débranché ! voilà  une solution rapide !

Il faut cependant regarder les choses de façon pragmatique, car cette tension de référence peut avoir des courants de retour quelque peu importants, aussi je pense qu'une véritable alimentation 2.5V (en tracking du 5V ? encore mieux) ne serait pas un luxe, mais certainement la meilleure solution.

On remarquera aussi qu'une solution individuelle pour chaque point de mesure est meilleure, car elle évite des interactions lors des épisodes de variations brutales.

Dans ma réalisation j'ai trois entrées ANA pour des transformateurs d'intensité (TI), aussi 3 petits LM1117-2.5 seraient peut-être bien ?
2 entrées ANA sont réellement très utiles, la 3ème n'est que de contrôle du courant cumuls à l'oscillo . (La 3ème est l'ancienne mesure de la tension pour détection du T-Z). Cette solution reste financièrement abordable, car ces régulateurs sont LDO et bon marché en SOT223. Adieu le tracking du 2.5V depuis le 5V.

En réalité si les régulateurs font bien leur travail, il n'y a pas lieu de "tracker" depuis le 5V, c'est ma vision qui s'appuie sur le bon taux de régulation et de stabilité de ces régulateurs, mais aussi de ne pas faire une usine à gaz.

10.5 Temps zéro et tension 230V

Chaque mesure sera faite à partir de ce point zéro donné par la tension réseau.

Ce Z-C (appelé aussi T-Z) devrait être mis en forme car c'est une fausse calotte de sinusoïde sans fronts raides. (C'est précisément la conjonction d'un redressement double alternance au point zéro)

Le Z-C était initialement issu du variateur à TRIAC. C'est une impulsion positive de 300 à 500µs de large toutes les 10ms (à chaque demi période, photo ci-contre)
A l'origine, j'avais un transfo spécifique (pour éviter toute déformation) délivrant 16 V crête crête qui faisait l'affaire, mais la forme d'onde est un peu "abîmée" et pas tout à fait une sinusoïde parfaite. (Cela semble une spécificité des tous petits transformateurs.)
A ce jour, ce transformateur auxiliaire pour la mesure de tension a été supprimé et un montage spécifique résistif pur, donne un signal carré de la tension secteur. Certes il y a une petite consommation sur des résistances de petite puissance, mais on y gagne beaucoup, on verra pourquoi.
(Je suis également satisfait de l'élimination de ce transformateur, car c'est toujours un risque de dégradation de la phase du signal).

La forme d'onde de la tension est "accessoire" car la valeur plus, ou moins, et le point zéro sont seuls véritablement utiles.

-Non seulement la mise en forme est nécessaire et C'EST LE FRONT MONTANT de Z-C qui est important, car à priori il faut au moins 1.5V pour faire agir la LED de l'opto-coupleur ce qui entraîne un retard d'apparition de ce signal Z-C.

Il me semble donc important de bien mettre le premier front à la verticale par une détection précoce de la montée du signal.

En effet cette impulsion à une largeur à zéro d'environ 500 µs ce qui est énorme par rapport à une demi-période de 10 ms (1/20) et c'est à mon avis beaucoup trop.
La demi largeur est tout de même de 250µs
Une entrée trigger de PIC est aux niveaux CMOS et ça ne va pas vraiment car on perd trop de temps avant d'atteindre la moitié de hauteur.
Il faut passer par un AOP et détecter vers +0.5V cette montée de la sortie.
On ajoutera à la sortie un transistor de protection à l'OPA2348, en espérant ne pas avoir à descendre plus bas en précision de détection de zéro Volts.
Ce problème des alternances et de la détection du zéro est un point capital qui sera développé au paragraphe suivant.

L'essentiel de ce sujet réside dans le front de la détection 0V. Celui-ci doit être le plus proche de la montée du signal.
On ne peut pas espérer que l'entrée RB0 étant sur un trigger de Schmitt pour les INT soit suffisante.
On notera que l'on n'utilisera pas RB0 avec INT mais en "INT on change" pour avoir une interrupt sur les 2 changements de niveau.

J'ai abandonné cette solution du Z-C pour créer moi-même mon système de détection qui est un peu à l'inverse de la solution d'origine reprise par P'tiwatt, voir ci-dessous !

10.6 Solution avec ALT+

Initialement, je créais la polarité de la tension par programme à partir du signal Z-C, mais cela s'est révélé problématique car on pouvait se tromper d'alternance, suite à parasites, ce qui était une catastrophe !

Après une première modification de mise en forme du signal Z-C, le problème restait presque inchangé !

J'ai donc été obligé d'imaginer une nouvelle solution pour palier les problèmes issu de la détection 0 volts d'origine du module.
Je m'étais aperçu de la difficulté de synchroniser parfaitement Z-C et la polarité des alternances. Aussi, en réfléchissant un peu, j'ai pensé que créer un signal carré représentant les alternances serait bien plus pratique que cette seule détection du Z-C.

En tous cas chaque front sera directement à l'origine du signal zéro volt. En effet dans l'ancien système, il fallait faire une mesure de la tension pour déterminer l'alternance en cours, ce qui prenait effectivement un temps non négligeable.
Ce nouveau principe n'a pas cet inconvénient puisque, on sait en permanence dans quelle alternance on se trouve, par ce signal ALT+.
Le signal ALT (également nommé ALT+) est donc simplement l'image carrée de la sinusoïde secteur en 5V cc. De plus, le fait que les deux signaux soient quasiment synchrones, il sera toujours possible de mettre un offset en cas de position, incorrecte par rapport au zéro réel de la tension. C'est un gros avantage.

De plus dans l'ancienne solution, la détection du Z-C par programme n'était faite qu'une seule fois en début de programme par manque de temps, et en cas d'aléas, (Brèves coupures secteur avec rétablissement de tension non synchrone) on pouvait facilement, se trouver en opposition de tension et créer éventuellement des consommations réelles par erreur de routage vers le cumulus.

J'ai profité de cette modification pour regrouper les fils secteurs vers les disjoncteurs qui ne sont pas conçus pour serrer de petits fils ET des gros.
J'ai donc crée un deuxième signal Z-C qui ne sera pas utilisé, car il est inutile. Il est seulement possible de régler la symétrie des 2 fois 10 ms, par ajustement des seuils de basculement.
Ce signal Z-C ne sert à rien car on a le signal ALT+ qui nous indique par ses fronts le Z-C et la polarité nous donne l'alternance en cours.

10.7 Essais des variateurs à TRIAC

Le variateur  à TRIAC fonctionne bien et des courbes ont été réalisées, qui ont permis de faire avec une ampoule de 29 Watts l'extrapolation avec une résistance de 1500W qui est la résistance du cumulus.
Voici les résultats relevés et les courbes correspondantes. J'ai même regardé pour voir si on pouvait faire la compensation du cosinus Phi...!!! (On laisse de côté !)

C'est à peu près le bon endroit pour évoquer cela :
Regardez cette photo du display en connexion avec le compteur LINKY . Trouvez vous normal d'avoir un courant de 2A
et aucune puissance (Active)  ?

Eh bien oui, c'est ce qui se produit lorsque l'on envoie du courant en pics dans le cumulus. Ce courant n'est pas sinusoïdal et en conséquence il génère du réactif.
Vous pouvez le vérifier sur la photo du tableur où vous pouvez voir que plus le pic est petit, plus le cosinus Phi et petit.

C'est lors de cet essai que je m'en suis véritablement rendu compte. (le cosinus phi à été multiplié par 100 pour faciliter les échelles des graphiques)
C'est donc bien du courant réactif, mais heureusement il n'est pas facturé pour les particuliers, mais le LINKY ne devrait pas accepter à concurrence de l'équivalent de courant réactif correspondant à la puissance active souscrite... (Bien compliqué à dire).
On en sera toujours très loin en principe.
En conclusion annexe, j'ai envie de dire aussi, (mais là mes connaissances s'amenuisent), que l'onduleur ne peut pas générer du courant réactif, ce qui me semble plausible.
Je voulais par ce petit exemple, montrer combien ces sujets ne sont pas si évidents que cela, car ils touchent à de nombreux
domaines.

Le courant (Courbe verte) est pratiquement linéaire jusqu'à 80% du temps de la demi période
Il a fallu synchroniser "à la main" le générateur (Entrée sync en panne)   
Actuellement la largeur de l'impulsion unique de commande est de 270 µs ce qui n'occasionne pas de "loupés".
Il est possible d'augmenter cette valeur en modulo 55µs par paramétrage (EQU) dans le programme.
On notera que les dernières valeurs de cette impulsion seront de toutes façons tronquées par la fin d'une alternance (+ ou – d'ailleurs).

La régulation vers le cumulus se réalise entre 90° et 180° de l'alternance positive et symétriquement pour l'alternance négative.
Cependant cela laisse peu de marge de manœuvre angulaire pour rediriger l'énergie vers le cumulus, soit seulement 2x90° sur les 360 degrés d'une période.

De plus, les valeurs extrêmes (90 à 110 environ) sont à variation lente de puissance, ce qui n'est pas le cas vers 180° où c'est presque linéaire.
Ainsi une faible puissance dirigée vers le cumulus est toujours assez "binaire" car elle joue sur quelques degrés angulaires, ce qui n'est pas le cas vers les plus fortes valeurs où le réglage est plus doux.

10.8 Mesure des courants Habitation / panneau

Le signal tension est directement obtenu par le signal ALT+. Il n'y a plus nécessité de chercher dans quelle alternance on se trouve, le signal ALT+ l'indique par hardware directement, ce qui est une plus grande sécurité. Il servira à contrôler si le courant est en opposition à la tension, ce qui indiquerait que l'on réinjecte du courant dans le réseau ENEDIS.

On choisira donc l'alternance positive et on regardera alors où se situe le courant général.
De façon très simple, tout courant mesuré en dessous de 2.5V sera un courant en opposition à la tension, et donc une injection vers le réseau public.
Tout courant mesuré dont la tension est supérieure à 2.5V représentera une consommation EDF, mais à ce stade, il ne sera pas possible de savoir si, avec ce seul TI il y a ou non un complément apporté par les panneaux (Ceci est très important de le remarquer et c'est un cas que je ne vois mentionné nulle part)

Comme indiqué, il faudra faire une série de mesures du courant, on fera une adéquation fort utile entre degrés angulaires pour refouler le trop d'énergie vers le cumulus, et on fera donc 180 mesures durant 10 ms.
En dernière modification, on ne fera qu'une seule série de 180 mesures  pour mieux prendre en compte les variations brusques de consommation d'une habitation.
On pourra ainsi donner le Fire du triac en termes de degrés angulaires dans chaque demi période.
Le "Fire" sera calculé en fin d'alternance positive et à cheval sur l'alternance négative. L'alternance positive totale servira à 98% aux seules mesures du courant (En phase ou opposition).

Le capteur transformateur de courant (TI) est un 20A/20mA, ce qui donne dans le Burden de 500 ohms ±2.5V cc au maxi, avec écrêtage par zener pour les forts courants.

Je crois l'avoir déjà largement indiqué, mais on ne travaillera que sur l'alternance positive, car en 10 ms avec 180 mesures analogiques, il reste peu de temps pour faire le reste….
Il y a une grosse opération finale à faire qui est la division des 180 mesures, pour obtenir la moyenne. Cette opération dépasse le temps des 10 ms d'acquisition des valeurs et ne peut être réalisée qu'à la fin de la 180 ème mesure et à cheval sur l'alternance négative adjacente.

10.9 Puissances

P=UI(*Cos Phi) A priori, la lecture des seuls courants est une partie importante (au cos Phi près) et numériquement le courant représente la puissance au facteur tension près ainsi que du cos Phi.
Je ne sais pas encore si le simple calcul des puissances entrantes et sortantes, en d'autres termes si le panneau fournit de la puissance et qu'il y a une puissance presque nulle en sortie vers le compteur.

A ce stade, la lecture du LINKY peut permettre de vérifier les éléments calculés et de voir qu'il n'y a pas de problèmes.
Il est plus qu'important de dire que ce petit outil de lecture du LINKY m'a énormément aidé dans la mise au point.

(En réalité j'avais prévu en cas de grandes difficultés techniques pour aboutir à ce projet de router, d'utiliser cette lecture du LINKY pour réaliser tout de même ce router. Je n'en n'ai pas eu directement besoin heureusement, car la précision des valeurs données par le LINKY est misérable. De plus la vitesse de 1200 bps n'est pas "terrible" !
Une entrée 1200 bps est prévue (et même à 9600 bps ce qui aurait dû être le cas et qui m'avait nécessité de passer en fibre optique)

J'ai cru un instant que ce montage LINKY pouvait être modifié et amélioré pour faire apparaître le mot de status du LINKY qui contient des informations importantes comme les bits 8 et 9 et éventuellement l'état du contact sec.

Bit 8 : fonctionnement producteur/consommateur (On voit tout de suite l'intérêt !)
Bit 9 : Sens de l'énergie Active

En réalité ce mot de status n'est pas accessible à l'usager et seul le MOT D'ETAT est accessible mais ne contient pas ces informations

On notera la relation de puissance entre celle du cumulus et celle potentiellement disponible des panneaux photovoltaïques (au maximum).
Ainsi avec une consommation permanente de 180 à 250W (Talon de consommation) , une puissance maxi photovoltaïque de 700W et un cumulus de 1500 W, cela implique de déclencher le TRIAC au moins à partir du maximum du signal de tension sur chaque alternance (90° pour ALT+). 

Théoriquement on pourrait même limiter vers les 100 à 110° si on connait avec précision le minimum absolu du talon de consommation, mais on se contentera de considérer que le talon peut parfois devenir nul c'est plus prudent!


10.10 La régulation

J'ai d'abord commencé avec une table des puissances fonction de l'angle Fire. Pour rappel la puissance est une fonction de type y=cos 2wt c'est-à-dire de fréquence double du signal alternatif soit 100 Hz. Je l'avais un peu oublié, mais c'est très évident, car il existe une alternance négative qui compte autant que la positive pour le transfert de puissance.
J'avais simplement oublié qu'une fois la valeur trouvée et le Fire appliqué, la situation ne peut plus correspondre !!! Évidemment ! Il y a des fois où la vieillesse vous fait faire des bêtises …

Le fond du problème après maints essais m'a fait voir que je n'ai pas assez réfléchi au sujet, car cette régulation est complexe. Il y a en fait 2 paramètres qui peuvent varier très différemment :

 - Le niveau de l'énergie des panneaux est variable à l'année, au mois, au cours des minutes et secondes suivant les nuages, variable au niveau des heures de la journée et la nuit où cette fois il n'y a plus aucune énergie photovoltaïque. C'est principalement des variations assez lentes (Nuages par exemple quelques 10èmes de seconde avec vent fort).

 - Parallèlement les demandes d'énergie dans la maison peuvent survenir n'importe quand et cette fois avec des petites demandes ou de très grosses (Four micro-ondes, four, télé grand écran, chargeur ou éclairage pour les petites). (Variations de l'ordre de 40 ms maxi en établissement ou relâchement de puissance)

- Les impacts de charge sur le réseau total (réseau Habitation + Onduleur) ne sont pas instantanés, mais se répercutent sur 2 à 5 alternances (pour l'exemple avec une charge résistive de 2KW). Ce fait est très important surtout lorsque l'on recherche si un appareil de puissance vient d'être mis en marche. Si on mesure le courant sur plusieurs alternances, l'impact sera un peu plus marqué que sur une seule. (photo ci_contre ON  2KW résistifs)
 
 Les principales difficultés se concentrent à l'arrêt de l'appareil de puissance. En effet à ce moment la régulation a tendance à entrer en oscillation, et c'est la principale difficulté dans la régulation.
 
Il faut donc réguler le router pour ces deux paramètres et éviter… les oscillations ! C'est certainement le point le plus difficile à résoudre et celui qui se produit encore parfois dans des cas très particuliers.

Pour l'instant je tâtonne un peu et le simple fait de ne regarder que Injection ou Consommation n'est pas suffisant.

Il faut aussi prendre en compte les instants où les consommations sont du même ordre de grandeur que l'énergie photovoltaïque et dans ce cas on régule sur des "pouillèmes" et dans cette situation il semble préférable de couper le TRIAC vers le cumulus, sous peine cette fois de consommer, c'est à dire le but inverse du router !!!. (C'est ce point qui me chagrine à l'instant !)
Dans ce dernier cas, il n'y a pas d'autre possibilité que la temporisation d'assez longue durée en secondes ou minutes.

Il y a aussi les impacts de charge, tant en charge comme pour un four micro onde qui se met en marche, mais aussi lorsque celui-ci s'arrête (libération de charge).

Information :
Si vous ne le saviez pas, un four micro onde ne sait pas fonctionner autrement qu'à puissance nominale (ou nulle) avec le magnétron arrêté, et la durée totale est parsemée de ces deux périodes d'activité et de repos qui permettent à la chaleur emmagasinée lors de l'activité de se répartir lors des repos.
Ce système est très éprouvant pour la régulation d'autant que "le cosinus Phi  fait des pirouettes pas possibles et frôle la crise cardiaque !"

La régulation est donc un point extrêmement important que j'ai largement sous-estimé lors de l'étude.
A suivre, façon de parler car je n'ajouterai rien de plus, car c'est encore en essais.
A ce jour je pense avoir résolu les impacts de charge, mais le problème des oscillations lorsque l'injection est minimum est encore en essais.

10.11 Le problème du cumulus

Sur la photo ci-contre on peut voir le capot d'origine des arrivées de tension par la gaine noire en partie basse.
On peut distinguer l'adjonction d'une prise de courant alimentée par le cumulus lui-même (Commande par le PAC20) qui donne l'énergie à une petite alim (noire en face avant) qui commande le contacteur d'inversion Alim/pac20 ou Alim par TRIAC.
Les temps de transfert des contacts donnent la sécurité d'absence de conflit.

Au dessus une petite lampe tungstène de frigo indique si on dérive du courant vers le cumulus au lieu de le réinjecter sur le réseau.
(C'est un témoin de fonctionnement de 7 Watts qui a l'avantage d'être visible et de quantifier un peu le niveau de puissance, ce qui ne serait pas possible avec une lampe LED standard)

Cette lampe scintille, éclaire, ou rougit à peine suivant l'angle de commande du Triac et l'énergie disponible.
A noter qu'une petite LED avec 56K 1W pourrait être utilisée en lieu et place de ces 7 Watts (Des lampes tungstène de 1W 230V n'existent pas !) Mis en place sur le module TRIAC

Sur la première photo on distingue la partie basse de la régulation solaire thermique située juste au dessus, mais on voit tous les fils blindés de mesure des températures.

(C'est après un essai un peu "piquant" que j'ajoute ce sujet…J'ajoute qu'un flash important a explosé le triac à priori à cause d'un retour de tension par le thermostat).

Mon installation domestique était initialement prévue en triphasé, ainsi pour le cumulus, il y a donc 5 fils, 3 phases, neutre et terre au niveau de la boîte de raccordement.
Pour pouvoir utiliser pleinement le panneau solaire thermique dans les cas de faible consommation d'ECS et éviter la réinjection dans le réseau, du solaire photovoltaïque, il y a lieu d'utiliser le surplus d'énergie photovoltaïque en chauffant "un peu" l'eau d'un cumulus. C'est le moyen le plus logique et facile de stocker de l'énergie au niveau individuel.

Il y a cependant un problème, et particulièrement chez moi, car le cumulus cité est avec échangeur solaire (thermique) mais dispose aussi d'une résistance électrique en cas de manque de soleil.
(Un deuxième cumulus sans appoint électrique est uniquement sur la chaudière fuel  et n'a pas de résistance d'appoint)

Pour être sûr de pouvoir toujours chauffer l'eau pleinement, il y a nécessité de passer outre le thermostat en série avec la résistance (Habituellement réglé vers 60° pour les économies d'énergie).

Deux problèmes à ce stade, que va-t-il se passer en cas de surchauffe ? Alors là pour une production photovoltaïque de 700W maxi  pour 200 litres d'eau et une résistance de 1500 W, je dirai que le risque est très faible sauf en période d'été où la conjugaison thermique et photovoltaïque sera à son maximum.
Dans ce cas, ce sera au groupe de sécurité de faire son office.
Avis aux fabricants de cumulus pour placer un deuxième thermostat, je garde à cette date du 19/02/2023 la pérennité de l'idée. Dans cette optique de surchauffe, il faudra arrêter et laisser filer l'énergie vers le réseau.
Autre solution, réduire artificiellement la production thermique ou photovoltaïque !

Il existe encore une autre solution pour contrôler cette température maxi à ne pas dépasser sans s'appuyer sur le fonctionnement du groupe de sécurité, qui serait, faute d'un 2 ème thermostat de placer une sonde de température, mais cela devient vite une usine  pour régler un problème trop simple…

Il est vrai que ma maison est devenue très technique au fil des années et qu'à 77 ans il faut pour le profane une bonne dose de technicité pour comprendre ce qui est en place…
Mon épouse baisse les bras, mais je fais pour que tout soit le plus normal possible sans intervention et pour réduire au maximum les pannes.
Que faire ? Je resterai pour ma part dans la région Est où le soleil n'est que rarement au maxi, et je laisserai le groupe de sécurité faire son travail. C'est critiquable, mais j'assume. (Au pire, un mini thermostat 95°C, 10 A de quelques Euros en série avec le premier, permettra la sécurité).

Voyons maintenant un autre point de sécurité…

En faisant mes repérages de câbles électriques, je vérifiais avec le 230V par les voyants du cumulus, sur la ligne standard raccordée au tableau électrique, j'ai pris une bonne petite châtaigne sur le fil d'alimentation dédié au triac car le thermostat n'avait pas atteint la température, il était donc fermé.
ATTENTION donc à ces RETOURS dus à la présence de 2 alimentations 230V~ distinctes.
Les retours de tension sont toujours possibles d'un côté comme de l'autre quelle que soit la position des relais et suivant les thermostats ouverts ou fermés, en fonction de la température de l'eau.

C'est donc un danger permanent car la tension peut arriver par l'autre branche.
Pour éviter tout problème pour vous qui n'avez qu'un seul fil pour le cumulus, il me semble préférable d'insérer un commutateur 2 positions, l'une pour chauffage forcé (ou par tarif de nuit), et l'autre pour appoint router photovoltaïque.

Suite à cela, il faut pouvoir intervenir rapidement sur les dispositifs de coupure, aussi les anciennes protections par fusible, peu pratiques, devront être remplacées par des minis disjoncteurs.

Cette particularité a nécessité l'utilisation de 2 relais pour éviter d'injecter à l'envers une tension sur la sortie du triac. Cela a nécessité aussi un contacteur sur le cumulus pour éviter les retours lors du basculement du PAC20 et se prémunir d'une éventuelle coupure du secteur qui ne doit pas faire fondre de nouveau le TRIAC. Pour cela il a fallu une petite alim 24V sur le cumulus, qui n'est en fonction que si on veut chauffer en électrique direct l'eau, par la commande d'un interrupteur PAC20.

Je n'aime pas non plus laisser le TRIAC avec le 230V sur l'une des bornes, aussi je préfère l'isoler totalement, ce qui renforcera du même coup le retour du 230V sur la sortie. Je suis d'accord que c'est un peu idiot mais j'assume, sécurité oblige !

Voyez donc ce nouveau schéma qui devrait résister à une coupure secteur et autoriser le basculement en chauffe d'urgence par le PAC20, sans se soucier du photovoltaïque en fonctionnement ou non. (rappel ci-contre)

Encore un oubli, et toujours avant de faire l'essai réel…
Je n'ai pas fait attention au problème du Neutre commuté par le thermostat, mais aussi au niveau du combiné interrupteur PAC20.
Je suppose que c'est anormal d'un point de vue NFC15-100, mais je n'ai pas vraiment d'autre choix que de rendre le neutre commun et non commuté.

En électrotechnique, ça passe ou c'est coupé, ça ne pose pas de problème, mais en électronique c'est tout de même un peu différent, car il faut une référence des diverses tensions.
En France, cela ne pose pas de problème puisque le Neutre est toujours mis à la terre par le distributeur d'énergie, du moins pour la majorité des particuliers.
Son potentiel est normalement proche de celui de la terre, aux courants de fuite près, mais il n'y a aucun risque d'électrocution EN PRINCIPE. (En effet il peut encore exister de vieux réseaux 127/230, et dans ces cas il n'y a pas de Neutre mais 2 phases, alors vérifiez toujours. Il peut aussi y avoir des erreurs de branchement !) Ne pas utiliser ce router si il n'y a pas de Neutre

Dire que je recommande cette façon de faire est faux, mais sans faire une usine à gaz avec de nombreux relais, je ne vois pas comment me débrouiller autrement pour régler ce problème, car il faut aussi prévoir la coupure du secteur et son ré enclenchement inopiné, avec le risque que le PIC démarre sur une fausse piste !!!
Je dois dire que ne m'attendais pas à l'explosion du triac dont je n'ai pas encore la certitude absolue de la cause de sa destruction,
A bon entendeur salut, ne faites pas comme je dis, mais innovez et faites mieux que moi en respectant toutes les normes, qui réglementent la vie électrique…

10.12  Choix du capteur de courant

Celui-ci est avant tout guidé par la puissance photovoltaïque installée.
En effet pour le routeur, l'intérêt est d'utiliser le trop de puissance tant que l'on n'a pas atteint la puissance photo maximum dont on peut disposer.
A cette fin le contrôle de puissance doit être le plus précis aux faibles valeurs jusqu'à cette puissance photovoltaïque. L'idéal est un capteur qui donnera 5 Vcc pour la puissance photovoltaïque maxi.

Les valeurs supérieures ne sont pas concernées car on est certain qu'il n'y a rien à faire au niveau routeur, car il n'entre plus en jeu, vu que toute l'énergie (et d'avantage) est consommée.

J'ai tracé quelques courbes pour différentes valeurs de la résistance Burden du secondaire du TI (Transfo d'Intensité). Comme le mentionne P'tiWATT, pour les valeurs élevées de Burden, il y a saturation.
En ce, sens, il faut essayer d'avoir le maximum de tension sans toutes fois atteindre la saturation et en restant linéaire jusqu'à 5Vcc.
Aussi les valeurs de Burden entre 470 et 1K semblent les mieux adaptées.
J'ai choisi 510 ohms qui est un compromis entre linéarité, tension de sortie et saturation.
Qu'advient-il dans les fortes puissances, puisque la tension maxi ne doit pas dépasser 5V….?

Les zeners 4.7V feront l'écrêtage pour cela, sans pour autant dépasser la puissance de ces zeners de 1.3W puisqu'à 18V – 4.7 =13V soit un courant de 13/500=26mA et- une puissance zener de 0.8W au maximum.

10.13  Le courant est-il symétrique ?

Cette question est primordiale car je ne contrôle que les alternances positives  !!! Alors

J'avais initialement répondu oui à la symétrie sans trop réfléchir, mais à la lumière de certains essais à faible puissance (120 / 130 watts) du talon de consommation des appareils électroniques, je pense que c'est un raccourci un peu rapide, car on tire de la puissance tant durant l'alternance positive que l'alternance négative.

Pour preuve, que fait un redressement mono alternance ? Il tire de la puissance uniquement d'une seule alternance (soit +, soit -) Le courant devrait donc être différent suivant chaque alternance.
Cela est-il fréquent ? Cela se produit principalement en électronique faible puissance. L'impact réel ne devrait donc pas être important et le raccourci de dire que le courant est symétrique est bien vrai, au moins au niveau des utilisateurs particuliers.

Dans l'industrie où les puissances sont importantes, il est normal de penser qu'on tirera cette puissance sur CHAQUE alternance, car on redressera toujours en pont cette tension alternative. On sera donc symétrique ! Pire, en industrie on manque à ce point de puissance, que l'on travaille en triphasé et que le mono alternance semble totalement, impossible ?

Au niveau de la forme des courants, il est certain qu'il y a de quoi s'arracher les cheveux !!! On constate que l'électronique avec le redressement a une incidence importante au niveau de la déformation du courant, à cause des angles de conduction très pointus, occasionnés par des condensateurs de redressement de forte valeur.

Il y a en outre d'autres phénomènes parasites qui font que le courant correspondant au talon de consommation est d'une forme très difficile à intégrer, avec parfois des points d'inflexion, ou "des cornes", et compliquée pour en trouver la valeur sans confondre avec le point Z-C . Le point de tension  nulle peut même sembler ne plus être celui donné par le signal Z-C ?

Encore de belles heures de recherche…

Z-C d'origine, outre sa forme en fausse calotte est axé symétriquement sur la tension nulle, contrairement à ce que je pensais, aussi ce signal n'est pas très intéressant car les 2 fronts seront toujours en avance ou en retard sur le véritable point zéro.
La largeur est de l'ordre de 300 à 500 µs, ce qui est relativement important en regard d'une demi période de 10 ms (1/20 est loin d'être négligeable ! à rapprocher des 180 mesures…)

C'est intolérable si on espère faire 180 mesures uniformément réparties sur une alternance. A ce sujet je me pose la question de savoir comment "les autres" ont fait pour passer sur ce détail pourtant très important ? (Attente programme paramétrable sur le premier front ? ou autre ?)

 Alors pour cela, j'ai ajouté un nouveau montage qui ne regarde plus seulement le Z-C mais génère le signal ALT+ qui représente la sinusoïde de tension, écrêtée et mise en forme. Seul ce signal est intéressant car chaque front est un équivalent Z-C, et on dispose de la polarité de l'alternance de fait par le signal carré.

10.14  Stabilisation du 2.5V

J'avais prévu initialement un LM385-1.2 (Zener programmable), mais suite à une variation "impromptue" du 5V de référence de mesure ANA, je me suis aperçu que celui-ci ne suivait pas le 5V, (Évidemment !) et qu'il ne fallait surtout pas ! J'ai donc remis un simple pont diviseur correctement découplé pour ce point milieu, comme P'tiWatt.
Le mieux est parfois l'ennemi du bien !!!
Ce pont unique alimente tout ce qui est mesures en alternatif (Courants (et tension)). Le découplage ne doit pas être trop important pour la même raison que le LM385 mais aussi pour la retombée rapide de cette tension lors d'une coupure de tension. Un condensateur de 47µF est largement suffisant pour une constante de temps de l'ordre de la demi seconde.

De plus la tension n’est plus concernée puisque seul le signal ALT+ suffit à gérer ce qui concerne l'injection.

On a vu dans l'article que cette solution LM385 est tout de même meilleure que le simple pont diviseur, car il y a des courants qui doivent se reboucler et cela entraîne des variations qui ne sont pas gérables avec un simple découplage avec des résistances de valeur élevée.

Je préconise donc pour chaque entrée ANA d'utiliser un LM1117-2.5 qui assurera correctement et individuellement chaque entrée.

Ce point est important pour la stabilité du router et les absences d'oscillations.

10.15  Le Timer 2 du PIC

Ce Timer 2 est un outil formidable pour assurer des tâches répétitives sans se soucier de "comment le faire".
Pour cela je vous reporte à la documentation des PICs en général puisque celui-ci est souvent commun à beaucoup de PICs très connus. (16F690, 16F628, 16F684, 16F877…)
Ce Timer 2 permet ici de réaliser 180 mesures analogiques du courant toutes les 55µs, ceci aux aléas de stockage du contexte, car il faut bien entendu travailler en interrupts et cela entraîne quelques µs d'imprécision.

En un mot, 180 mesures synchronisées sur la demi période (Alternance positive) et un seul octet à traiter en réponse (Instant du "fire" pour le TRIAC) qui se réalise tout seul quelque soit l'alternance en cours.

De plus la largeur du Fire est paramétrée en modulo 55µs, ce qui permet là aussi d'être totalement détaché des contingences répétitives et de se consacrer aux seules mesures.
(Antérieurement j'avais besoin du signal Z-C (Instant de tension nulle), et celui-ci était traité de manière identique avec une largeur paramétrée. Le signal ALT+ évite maintenant de gérer ce signal inutile.)

Ce Timer 2 permet aussi de traiter les alternances négatives sur la base des mesures faites sur l'alternance positive précédente. Cette alternance négative ainsi libérée permet de terminer les opérations de calcul de moyenne de l'alternance positive, car à 20 MHz il n'est pas possible de faire 180 mesures en 10ms ET d'en calculer la moyenne en quelques µ secondes.
(On remarquera que pour gagner du temps, il n'est pas possible de dire que le premier quart d'une alternance de courant est identique au deuxième car certains appareils (micro-ondes par exemple) ne donne pas de symétrie dans une alternance).

10.16  LINKY

Le compteur LINKY a été prévu d'être lu par le router. Malheureusement le mot de status n'est pas disponible à l'utilisateur, car il contenait des informations importantes sur les bit 8 et 9. Paragraphe de la spécification ENEDIS6.2.3.14 registre de status

Cette possibilité de lecture du LINKY avait été intégrée au hardware au cas où il serait nécessaire de prendre en compte ces informations pour s'assurer que l'on est toujours au point optimum de régulation, mais la transmission des données se réalise à 1200 bds et ce temps est beaucoup trop long pour pouvoir réagir suffisamment vite.
Les 3 articles suivants seront utiles dans ce cas
http://bricolsec.canalblog.com/archives/2020/03/16/38104053.html
http://bricolsec.canalblog.com/archives/2020/08/03/38463048.html
http://bricolsec.canalblog.com/archives/2020/09/22/38548059.html

Au final cette possibilité n'a pas été utilisée dans le router, mais peut servir de contrôle du bon fonctionnement car on dispose alors du courant, de la puissance.
L'intérêt est évident car ces informations sont la base de la facturation… Toujours l'argent !
Un nouveau matériel pourrait même être alimenté en permanence par le router…et cela simplifierait un peu le hardware de cet appareil qui m'a été d'un très grand secours lors de la mise au point

On notera l'anachronisme suivant, car le LINKY affiche puissance 00000 et courant de 1 ou 2 Ampères ! (C'est vraisemblablement du réactif -non facturé pour les particuliers-) Mais il faut aussi savoir qu'il n'y a pas de puissance affichée en watts unitaires mais seulement par 10 Watts ! A quoi servent alors les unités ?

On nous cache beaucoup de choses, car au vu de la difficulté de traiter mon problème, j'ai pu constater qu'il y a d'énormes difficultés techniques et que la précision des LINKY n'est peut-être pas si "au top" que cela, car si on n'ose pas afficher des unités voire des décimales, c'est que l'on est pas très certains des valeurs ! ou que l'on veut éviter les réclamations C'est dit !!!

Bonne route à tous
bricolsec

MS309 Traduction en Français de la notice

Cet article n'a pas pu être repris directement de Word car il contient des photos qui ne sont pas passées en copier/coller en insertion WORD...

Clicker simplement sur le PDF ci-dessous pour visualiser et/ou enregistrer cette notice traduite.
Ce PDF fait 1.2 MO et le document est de 16 PAGES avec illustrations

MS309_PDF

bricolsec

Le calage dans une remorque

1    L'inertie
2    Le calage et l'histoire
3    Le cubitainer (ou poche)
4    Conclusion

Si vous arrivez directement sur cette page par un moteur de recherche, vous pouvez avoir accès à la table des matières et à chaque article, en page d'accueil.    L'accès se fait par l'un des deux liens en tête de colonne de droite ----->

ATTENTION à compter du 15/09/2019 les commentaires ne seront plus possibles à causes de quelques imbéciles qui font du spam pour le plaisir de nuire ! désolé  !

1 L'inertie

Le problème des transports dans une remorque est le bon calage des objets, car plus ils sont lourds, plus le risque d'enfoncement et de problèmes avec accidents est élevé.

Ce risque est proportionnel au poids de la charge, et l'énergie éventuellement développée est au carré de la vitesse …      (1/2 mv² C'est connu !) et c'est encore pire pour la vitesse !

Le phénomène est identique pour les passagers d'une voiture non équipés d'une ceinture de sécurité.

Dans un premier temps quand on est chargé (lourd) il faut limiter sa vitesse puisqu'elle intervient au carré et donc encore plus que le poids (la masse).

Le deuxième conseil serait d'installer des points de fixation sur le plancher d'une remorque, car cela est très utile pour  empêcher une charge de "fausser compagnie à la remorque".

La troisième réflexion est de dire que la charge peut aller soit en avant (dans le cas d'un freinage) ou au contraire vers l'arrière sur une forte accélération. (Ce dernier cas est très souvent minoritaire  car on ne dispose pas d'énergie à profusion à l'accélération).
Mais une charge peut aussi basculer sur les côtés par la force centrifuge dont les paramètres sont sensiblement les mêmes. Pour l'exemple voyez les poids lourds qui versent sur un rond-point !

2 Le calage et l'histoire

Le but de ce calage est d'empêcher la charge d'acquérir une vitesse indépendamment (relativement) de la remorque. Il faut donc bien la bloquer du mieux possible.
On a évoqué les points de fixation au plancher mais aussi toutes les autres possibilités sur le pourtour d'une remorque.

Pour l'histoire, et comment j'en suis arrivé à cette solution…
J'avais une cuisinière à transporter et incidemment j'ai pensé aux petits chapelets de ballons gonflés comme on peut en trouver dans certains colis.
Vous buvez parfois quelques verres et votre boisson peut être conditionnée en cubitainer….

Alors gardez ces peaux de plastique précieusement et voyez ce qui suit.

3 Le cubitainer (ou poche)

Vous allez maintenant gonfler à la bouche par le petit robinet du cubi juste assez pour qu'il bloque normalement la charge à transporter sur les parois latérales.
C'est un peu comme un airbag gonflé à l'origine et qui vous empêcherait de bouger.

Je n'ai rien inventé sur le principe, car certains coussins de calage de colis sont déjà des ballons pré gonflés suivant ce même principe.
Ce qui est nouveau c'est la réutilisation des cubitainers vides pour assurer la même fonction, et en plus ils sont réglables en volume.

Alors ne jetez plus ces cubis, mais gardez les précieusement, ils ne tiennent pas de place une fois pliés et seront toujours prêt en cas de besoin, et de plus ils seront réutilisables de nombreuses fois

4 Conclusion

Seul problème ne consommez pas outre mesure pour pouvoir caler votre remorque !

bricolsec

Girouette, anémomètre, pyranomètre, thermomètre
et GPS

1    L'anémomètre
1.1    La Mécanique
1.2    L'électronique anémomètre
1.3    Logiciel
2    Girouette
2.1    Mécanique girouette
2.2    Électronique girouette
2.3    Réalisation
3    Thermomètre
4    Pyranomètre
4.1    Circuit et CI du Pyranomètre
4.2    Particularités
4.3    Trames RS232 globales
5    Infrastructure générale
6    Le GPS UBLOX
7    Le mât
7.1    L'alimentation 12V vers 5V
7.2    La connectique
8    Conclusions

Si vous arrivez directement sur cette page par un moteur de recherche, vous pouvez avoir accès à la table des matières et à chaque article, en page d'accueil.    L'accès se fait par l'un des deux liens en tête de colonne de droite ----->

ATTENTION à compter du 15/09/2019 les commentaires ne seront plus possibles à causes de quelques imbéciles qui font du spam pour le plaisir de nuire ! désolé  !

Préambule

Encore une station météo ! C'est vrai, mais elle est à l'origine d'une nécessité de contrôle de la force du vent et d'avoir l'heure de façon précise pour mon petit panneau d'essai solaire photovoltaïque.
L'heure n'a pas la nécessité d'une précision de laboratoire, mais au contraire elle doit rester sans dérive notoire tout au long des jours et des années !

J'avais déjà réalisé il y a quelques années une girouette optique en code gray ainsi que plusieurs anémomètres, mais ces équipements souffrent en extérieur, et ils se dégradent rapidement au fil du temps à cause de l'eau et de l'humidité qui finit toujours par faire des dégâts. A l'époque j'avais écarté la solution magnétique car délicate à réaliser en code Gray, mais cette fois ce sera magnétique... mais autrement...

Petit à petit, d'un simple projet de 2 éléments (Anémomètre et GPS), l'effort pour aller un peu plus loin s'est mis à jour et cela a conduit à un ensemble assez complet. Ensemble qui a en plus été justifié par les câbles sous terrains existant déjà entre le point de mesure éloigné de 60 mètres de la maison.
Ces nouveaux appareils ont été revus au niveau mécanique et le principe modifié surtout pour la girouette qui a été améliorée notamment par un changement du principe : Le code gray optique a été remplacé par 8 capteurs switchs à effet Hall.

Il est clair que la mécanique et l'électronique aux intempéries représentent un vrai chalenge et il faut essayer de tout prévoir et de soigner particulièrement la mécanique, la connectique et la température... Mais le mieux est de tout mettre à l'intérieur quand c'est possible ! ça ne l'est pas à cause du nombre de fils restreint, mais c'est en projet... !
Ces améliorations ne sont pas limitées à la girouette, car la partie mécanique a été remise sur de meilleures bases, tout en sachant que le mieux "individuel" reste quelque chose de difficile…

Dans cette version d'essais (Qui reste un prototype), je n'étais pas parti pour faire tout cet ensemble de mesures, mais seulement de positionner un capteur GPS et un anémomètre pour le panneau photovoltaïque. Aussi l'électronique a été fortement bousculée en un prototype pas trop "top" qui demandera à être revu ultérieurement… Mais Quand ?

Jusqu'à Janvier 2022, le temps étant pourri et le COVID19 toujours présent, cela m'a conforté à rester un peu au chaud et à travailler pour créer un MAT MÉTÉO groupant cet ensemble de mesures qui m'est utile notamment pour "replier" le panneau en cas de vent fort. Il me faut aussi pour ce panneau, de disposer de l'heure précise à long terme pour pouvoir le replier à la tombée du jour et le remettre en marche au lever du soleil.
Le GPS ne sera pas décrit ici, car c'est un module acheté mais il fera partie du mat météo et de l'électronique générale du mât (Alimentation + gestion énergie + GPS et envoi RS232) . Pour plus d'informations sur ce GPS voir aussi mon article précédent.

Ce mât sera connecté en filaire jusqu'à la maison et véhiculera l'ensemble des mesures en ASCII sous forme de trames  RS232 à 9600 bps à plus de 60 mètres. Le nombre de fils est limité à 8 fils  y compris l'alimentation 12V.

Tout cela devant être opérationnel avec un minimum de consommation d'énergie produite par le panneau photovoltaïque lui-même.
Sur ce même panneau, il y avait une régulation d'origine dont le commun n'était pas la masse (0Volt) mais une valeur bâtarde qui m'empêchait d'utiliser le panneau et sa batterie associée pour le pilotage du panneau lui-même dont la masse est le 0V.

Ce point est résolu par un petit module convertisseur 3 à 4 Ampères avec la charge en floating d'une batterie au plomb utile à tout un ensemble de "consommateurs" dont le pilotage du panneau, cette centrale météo, la charge d'une tondeuse et une petite utilisation déportée à la maison même.
Voilà pour l'histoire de cette création qui reste incomplète car il manquera l'équipement qui regroupera et sélectionnera les différents matériels du mât.
Je devais à l'origine faire une électronique de regroupement des trames RS232 GPS et Anémomètre en une seule trame dans la boîte du mât lui-même, mais ce projet étant trop délicat à cause d'un manque de place et de fils, il a évolué en une simple alimentation et une commande pour l'alimentation du GPS. Donnons lui le nom d' "alim mât" pour clarifier car il devra avec peu de fils disponibles pouvoir réaliser quelques actions à distance.

Cet équipement complémentaire sommaire sera publié en fin de cet article, car il en est une partie incontournable.

A ce stade une seule électronique placée sur la girouette devait gérer la girouette et l'anémomètre. Depuis j'y ai ajouté le pyranomètre et le thermomètre qui sont aussi gérés par cette même électronique de la girouette. Ce n'était pas initialement prévu et il a fallu s'adapter avec beaucoup de modifs.

Le GPS au vu de sa consommation élevée a toujours été traité séparément des autres équipements.
Un PIC 16F690 largement dimensionné, mais surtout de faibles dimensions (SOIC20) a permis d'ajouter ces autres appareils, mais ne permettra pas de gérer le GPS dont la consommation est prohibitive et la commande de mise sous tension totalement déportée sur le boîtier du mât, et donc à distance depuis la maison.
Comme il sera indiqué également par la suite, ce GPS ne pourra pas rester en permanence sous tension du fait de sa consommation, aussi il devra être secondé par un autre circuit plus modeste en énergie (DS1307). Il n'y avait pas assez de place non plus dans la boîte du mât !!!

La girouette reste un consommateur d'énergie non négligeable de l'ordre de 22 mA mais elle est commandée localement pour un très court instant de 46 µs, alors que thermomètre, anémomètre et pyranomètre sont sous tension en permanence, car ils consomment assez peu d'énergie.


1 L'anémomètre

L'anémomètre mesure donc la vitesse du vent en Mètres par seconde (ou KM/h). J'avais choisi en premier  le M/s peut-être par simplification, mais j'avais fait l'étalonnage à partir de la voiture  (En KM/h). En réalité je viens de faire un revirement complet de choix, car il est certain que le Km/h est une unité qui parle à tous par la relation avec la vitesse d'une voiture, (Et beaucoup mieux que le m/s).
J'ai donc dû ajouter une multiplication par 3.6 pour convertir ces m/s en Km/h, car intégrer ce nouveau coefficient dans le calcul initial aurait fait basculer en opérations 32 bits, alors c'était plus simple ainsi et ce n'est pas le temps qui est dramatique, ni la beauté de la solution informatique !

Cet anémomètre est mécaniquement un peu mieux réalisé que les précédents car j'ai repris le guidage d'un petit ventilateur de PC (Marque FTC 12V 0.15A) avec la cloche comportant les aimants circulaires. Ce petit ventilateur est équipé d'un roulement à billes et d'une bague en bronze phosphoreux. Un contrôle de rotation par switch HALL l'équipe également. Je n'ai pas pu reprendre le capteur existant car il assurait en même temps la commande du moteur…
J'ai donc retiré (Délicatement) la partie moteur et gardé le CI  puis  placé au mieux un capteur HALL OH137.
Ce moteur utilisait un aimant circulaire ayant 2 pôles Nord et 2 pôles Sud, ce qui donne donc 2 impulsions par tour.
Du fait des aimants circulaires d'origine, plaqués contre l'intérieur de la cloche, la symétrie du signal est excellente. Ce point est très important, car cela permet  de faire une mesure de distance entre 2 FRONTS QUELS QU'ILS SOIENT.

Les impulsions seront exploitées sur un port standard, mais j'avais cependant prévu l'entrée T1CKI (PIC16F690) qui aurait pu donner plus de précision aux valeurs élevées de vitesse…
Est-ce bien utile ? Aux vitesses élevées, je ne me fais pas beaucoup d'illusions sur la robustesse de l'appareil en cas d'ouragan ! Alors j'irai au plus simple et le seul principe de mesure sera la mesure du temps entre deux fronts.
Pour évaluer les grandeurs qui seront à mesurer, j'ai donc fait un étalonnage avec la voiture et l'appareil au bout d'une latte de 40x27 pour limiter les perturbations aérodynamiques.

Open Office Calc est venu en renfort et m'a permis de constater la très bonne linéarité du nombre d'impulsions en fonction de la vitesse en KM/h. La fonction linéaire du nombre d'impulsion en fonction de la vitesse a été calculée par "Calc" et je l'applique directement à mes calculs. (Impulsions capteur ou ce qui revient au même à un coefficient près, le nombre de tours par minute ou secondes)
Elle est à peine simplifiée Y=2.6x avec Y le nombre d'impulsions et x la vitesse (Du vent ou de la voiture !)

En ce qui concerne la vitesse fonction du nombre d'impulsions de comptage du PIC (2µs de base à fosc=2 MHz), (Fonction du temps cette fois), la formule se complique un peu car elle prend l'allure d'une hyperbole de puissance, et la fonction qui sera appliquée aux calculs devient :
Y=55096 * (1/Nb impuls Timer1), avec Y en M/s et le nombre d'impulsions comptées par le registre TMR1 du PIC.
Toutes les valeurs seront élevées à des puissances de 10, pour permettre d'avoir 3 digits de partie entière et 2 décimales, ceci en tenant compte de la dernière modification exprimant les vitesses en Km/h et non plus en m/s.
Pour rappel, le nombre d'impulsions de 2 µs (PIC à 2MHz) est compté durant le temps séparant 2 fronts consécutifs donnés par le capteur Hall. (Que les fronts encadrent un signal à 1 ou 0)

Dans le logiciel, il faut également penser que le vent n'est pas toujours présent, et que dans ce cas, on peut toujours attendre …. soit un premier front, mais tout autant un 2ème front  qui n'arriverait pas ! Ce cas très fréquent doit être traité car dans le cas contraire il bloquerait irrémédiablement le programme.
De fait si le temps d'attente d'un front est supérieur à 4 secondes, on est obligé de déclarer "Vent nul" soit 0 M/s. C'est le timer 2 qui assurera ce contrôle puisque le Timer1 est affecté au comptage des 2 µs.

1.1 La Mécanique

En ce qui concerne l'élément entraîné sur l'axe, j'avais, en première approche gardé l'hélice du ventilateur, mais je me suis rendu compte de mon erreur, car un ventilateur est parfaitement directif, et même situé à l'horizontale, il ne serait vraiment sensible qu'à un flux d'air vertical. A contrario placé verticalement, il ne prendrait le vent que dans la direction perpendiculaire à l'hélice, ce qui ne convient pas non plus.

Bien entendu le vent suit un parcours quasiment horizontal (Aux perturbations du relief près !)
Alors j'ai été un peu déçu de cette idée un peu simpliste du ventilateur.
Comment faire sans refaire une usine à gaz ou un système avec coupelles ?
J'ai donc gardé la cloche plastique comportant les aimants et l'axe, mais j'ai scié toutes les pales, et j'ai ensuite fabriqué avec du petit clinquant laiton une micro éolienne "Savonius".

Elle n'est pas bien grande, et n'a pas besoin de l'être puisque le guidage se fait parfaitement par l'axe d'origine (Roulement + bague bronze phosphoreux).
Savonius : Hauteur 4 cm et diamètre des 2 demi cercles 3.2cm. Recouvrement 1/3
Les dimensions sont telles que les demi cercles ne dépassent pas trop de la cloche d'origine du ventilo. (Voir photo en début du paragraphe 1)

Autre défi mécanique… comment centrer cette Savonius sur la cloche lorsqu'il n'y a aucun point de repère de façon à éviter les vibrations voire la destruction aux vitesses élevées?
Pas de recette miracle, il faut en premier ajuster aux mieux avec du scotch double face en contrôlant le balourd (par les vibrations), puis passer après à l'équilibrage fin par des petits morceaux de scotch double face répartis au "pif". Une fois le meilleur endroit trouvé, on colle à l'Araldite et il reste à réaliser un équilibrage définitif au scotch double face avec de légers poids puis à l'aide de plots de soudure pour finaliser. (Il sera nécessaire d'ajuster le volume de soudure déposé, et on obtient avec un peu de patience et d'obstination un bon équilibrage).

Vient ensuite la question de l'étanchéité … Alors là, pas de réelle étanchéité mais il faut faire une protection par une petite jupe laiton qui sera collée sur le pourtour de la cloche de façon à abaisser l'entrée possible d'eau de pluie en partie basse, tout en permettant la sortie des fils.
La sortie des fils était difficile à élaborer avec du fil blindé toujours un peu gros, aussi je viens de modifier par de la nappe rigide au pas de 1.27. Cela me permet de modifier de nouveau cette jupe un peu trop courte à mon sens pour résister aux projections d'eau de pluie. De plus, pas de regrets, car l'ensemble était tombé par terre, et la Savonius était un peu dessoudée, alors on recommence !!!
Il faut voir que l'on ne peut pas coller le fond du ventilo contre une plaque car l'eau pourrait rentrer par l'échancrure de passage des fils (C'est d'origine de fabrication du ventilo !) Alors on fait au mieux…. on surélève l'ensemble et on descend la jupe le plus bas possible

On remettra le petit caoutchouc d'origine qui vient boucher l'extrémité de l'axe et éviter la poussière et toute projection d'eau.

1.2 L'électronique anémomètre

C'est un bien grand mot car celle-ci se résume à un capteur switch Hall OH137 comme on peut le voir sur la photo. Il a fallu "ruser" un peu pour ressouder ce capteur à la place de l'ancien et d'ajouter une petite résistance de 10 K simplement pour permettre d'essayer localement sans l'électronique connectée. (2 pattes dans un seul trou carré, voir photo)
Un Pull-up se place normalement côté extrémité utilisatrice, mais vu la distance très courte, cette résistance sera unique et suffira à cet open collector.
La distance à l'aimant n'est pas critique et 1 à 3 mm sont suffisants et permettent un fonctionnement parfait de ce capteur ayant de plus une bonne hystérésis qui évite les valeurs bâtardes en sortie. Le circuit est simplement bloqué vers le bas par un collier Rilsan (Visible sur la photo)

Ce circuit OH137 n'est pas trop gourmand en énergie et consomme environ 3 mA qui seront donc permanents sur l'alimentation générale des équipements.
Il peut également être alimenté jusqu'à 24V, ce qui ne sera pas le cas, puisque toute l'électronique est en 5V fournis par une alimentation  déportée (Dans la boîte du mât) elle-même alimentée en 12V par une batterie maintenue en charge par le panneau photovoltaïque.

L'électronique de la girouette aurait pu commuter cette alimentation, mais 3 mA restent acceptables et une seule commutation d'énergie d'alimentation a été prévue pour la seule girouette qui consomme environ 25 mA un très court instant. On se souvient aussi que l'alimentation doit avoir une petite charge... Donc cette petite consommation est finalement bien venue.

Ce capteur sera sur l'entrée RA5 (T1CKI) de l'électronique générale du PIC16F690 laissant la possibilité de compter cette fois les impulsions de l'anémomètre, lorsque la fréquence devient très élevée… Mais comme indiqué précédemment, ceci est utopique car aux fréquences très élevées (En regard de l'horloge PIC), il y a de grandes chances que l'on soit en phase d'ouragan ou de fin du monde, et dans cette éventualité, je ne donne pas cher du dispositif ! Alors la mesure du temps entre fronts reste donc largement suffisante.

1.3 Logiciel

Le logiciel spécifique anémomètre est intégré au logiciel général de la girouette. Le principe est de mesurer le temps entre deux fronts (Quels qu'ils soient) sur la base d'un temps de comptage de 2 µs donné par le PIC qui sera cadencé à Fosc 2 MHz ,  soit un Tcy de 4*0.5µs soit =2µs.
S'agissant de fronts, il est nécessaire d'utiliser un  bit IOCA de changement de niveau, avec l'interrupt correspondante. Le débordement TMR1H sur interrupt se fera dans un troisième byte externe aux registres du Timer1 (BIG_T1)
Pour les calculs, on appliquera simplement la formule déduite des essais soit Y=55096 * (1/Nb impuls TMR1). Le problème des décimales est traité par la multiplication entière, et seules 2 décimales sont traitées par décalage du point décimal dans le buffer de sortie vers la RS232.

Le changement d'unités pour facilité d'interprétation, des m/s au profit des Km/h oblige soit à multiplier 55096 par 3.6 (=198345), soit à ajouter une multiplication par 3.6 à la suite.
Avec les décimales au nombre de 2 il est plus simple d'éviter une opération 32 bits et d'ajouter simplement la multiplication par 3.6 (J'oublie volontairement la "cuisine" des zéros ajoutés pour calculer en entiers et les simplifications !)

Un affichage sans les zéros non significatifs (Zéros de tête) complique un peu ce nouvel affichage, car il est maintenant possible d'avoir un zéro au milieu des 3 digits entiers, mais c'est de la "cuisine" simple, mais incontournable !

Le logiciel ne limite pas les vitesses hautes et j'ai pu enregistrer des vitesses de 114 km/h et j'ai aussi poussé une pointe à 160 Km/h de quelques secondes et l'ensemble à tenu ! (Avec le compresseur et pas en voiture !!!)
Il faut dire qu'à ces vitesses on ne devrait pas (heureusement) en rencontrer trop souvent, car je ne sais pas si l'anémomètre supporterait très longtemps ce rythme endiablé !!!

2 Girouette

La girouette n'est pas vitale pour gérer la sécurité du panneau photovoltaïque, mais franchement faire l'anémomètre et ne pas avoir la direction du vent aurait été un peu mesquin. (Elle pourrait cependant présenter un intérêt dans certains cas de grands équipements pour orienter le panneau pour lutter contre des vents tournants).
Alors il ne faut pas recommencer le procédé optique à code Gray qui est difficile à maintenir en parfait état pour un code Gray imprimé sur papier.
J'ai donc opté pour une détection magnétique avec 8 capteurs switchs Hall. (C'est un peu onéreux mais c'est plus simple)
Pour cette girouette, le même problème de guidage se pose et cette fois ce n'est pas un ventilateur qui a servi de base mais l'axe d'un moteur de CD (ou diskette), je ne sais plus très bien car c'était déjà démonté.

Dans ce cas c'est un guidage uniquement sur bronze phosphoreux et non sur roulement.
L'électronique commune à tous ces appareils est installée sur le circuit imprimé rond de cette girouette.
Heureusement, mon vieil Eagle sous DOS n'est plus de ce monde, et c'est avec Diptrace que j'ai réalisé ce circuit imprimé assez délicat.

Comme initialement je n'avais prévu que la girouette sur cette électronique, j'avais ajouté tant bien que mal une pin pour l'entrée anémomètre, sur le seul connecteur d'alimentation de 4 pins et RS232 . Mais cela pose quelques problèmes pour loger ces câbles blindés un peu "gros" et rigides…

Et puis, comme l'esprit vagabonde un peu, je me suis dit que la température avec une CTN serait bien pour assurer une véritable mesure de la température extérieure. On verra au  chapitre Température que cela changera encore… mais que l'ensemble sera contrôlé par cette unique électronique.

Enfin comme j'avais quelques entrées libres sur le PIC, j'ai encore ajouté un appareil de plus : le pyranomètre !
Certes il est directement lié à l'énergie solaire par l'énergie lumineuse, mais est très proche de l'énergie thermique solaire. La fenêtre des fréquences de la photodiode BPW34 (ou BP104) est de 600 à 1050 nm de longueur d'onde contrairement aux pyranomètres "officiels" qui sont plus vers 300/2500nm, mais l'essentiel est d'avoir de façon simple des valeurs approchées de rayonnement en W/m².

On notera que ce paramètre d'énergie est intéressant pour une régulation solaire et qu'il a déjà été utilisé pour le panneau solaire thermique.
Une simple entrée analogique sera suffisante pour la partie pyranomètre.

Ce circuit imprimé, intégré dans l'anémomètre gère donc 4 appareils différents dont un seul est commandé en énergie par un  MOSFET_P : la girouette !

Pourquoi cette exception ? Simplement à cause de la consommation un peu élevée de cet ensemble de 8 capteurs  switch Hall  OH137 qui est de l'ordre de 25 mA, mais pour un temps très court.

2.1 Mécanique girouette

Contrairement aux modèles précédents, ayant la dérive sur le dessus et l'électronique logée dans le boîtier en dessous, le nouveau modèle est inversé avec l'électronique en partie haute et la dérive en dessous.
 Cette disposition me semble plus facile pour régler les problèmes d'étanchéité et s'adapte bien au principe d'un mât météo avec l'anémomètre au dessus.

(Il est évident qu'il ne parait pas possible de véhiculer 8 signaux vers une électronique située plus loin, aussi l'électronique doit être intégrée).

L'axe n'a pas besoin d'être sur roulement à billes car la vitesse de rotation reste faible contrairement à l'anémomètre, mais le guidage doit être correct tout de même.
Cet ensemble d'axe est celui d'un lecteur de CD, très certainement d'ancienne génération ayant une hauteur assez conséquente, avec un axe assez long que l'on conservera bien entendu tel quel et on gardera la partie circulaire en tôle (Qui portait d'ailleurs des aimants que l'on ne conservera pas) que l'on découpera au disque à tronçonner avec la meuleuse pour éviter toute contrainte forte sur cette tôle durant cette "opération chirurgicale".
On gardera donc une bande de tôle symétrique par rapport à l'axe dont un côté portera le seul aimant se déplaçant devant les 8 capteurs Hall, et l'autre côté symétrique portera une simple vis assez grosse assurant le contrepoids de l'aimant. Un petit taraudage M4 dans la tôle repliée en bout assurera la fixation de cette vis et le réglage pour l'équilibrage. (Réglage de l'équilibrage avec axe à l'horizontale)

L'aimant 10x4x2 mm tient tout seul par magnétisme mais il est préférable de le bloquer à l'Araldite.
La dérive faite en tôle d'aluminium de 0.5mm est très légère, et elle est pincée dans un trait de scie réalisé sur l'axe creux en plastique de l'équipement mobile.
Le côté opposé à la dérive doit être lui aussi équilibré. Il l'est par une vis inox de 5 avec écrou, et emmanché dans l'axe et réglée par frottement  pour l'équilibre (Toujours axe horizontal pour ce réglage).

Cette dérive n'est pas très grande pour éviter les oscillations, c'est par tâtonnement que sa surface sera ajustée pour un bon équilibre entre sensibilité et oscillations.

L'ensemble est fixé sur une tôle plane circulaire avec un prolongement de fixation, pour permettre un accès simple et une maintenance plus facile.

Des petites colonnettes appuyées sur la mécanique axiale en plastique et le circuit imprimé assurent la fixation de l'ensemble sur cette tôle plane. (Photo CI tôle retirée avec colonnettes vues de dessus)

Enfin une boîte de conserve en aluminium embouti (C'est important pour la durabilité) et de faible hauteur recouvre l'ensemble mécanique interne et électronique. Ce choix est motivé par la parfaite insensibilité de l'aluminium et l'absence de joint comme les boîtes de conserves traditionnelles. (Boîtes de fruits au sirop ou de thon au naturel ayant le fond sans rebord et/ou arrondi !!!)
Un petit joint caoutchouc collé sur la tôle, légèrement plus grande que la boîte, parfait cette partie protection. (L'étanchéité n'est pas réelle mais l'eau ne peut pas mouiller les parties électriques)

2.2 Électronique girouette

L'électronique reste simple et basée sur un PIC16F690  SOIC 20 pins. Un des points particuliers est la présence d'un connecteur ICSP "volant", par manque de place.  (Photo ci-dessus)
Cette électronique assure donc la gestion des 4 appareils : girouette, anémomètre, thermomètre et pyranomètre. (Le GPS n'est pas géré par celle-ci)

Tous les fils nécessaires à la programmation du PIC (ICSP) sont soudés directement sur des pastilles (ou pins) prévues, et mises sur connecteur volant, car il a été impossible (En simple face) d'aligner tous les signaux de programmation sur un connecteur spécifique. (Ce connecteur femelle volant pourra être laissé en place sans gêner vraiment).
Depuis ce cas prévu, 2 autres connecteurs ont été nécessaires mais ont été placés de façon peu orthodoxe en fonction de la place disponible et des dessins du cuivre existant.

Le schéma de principe est parfaitement à jour, par opposition à la réalisation du circuit qui au vu des modifs est largement modifié. Pour ce dernier schéma du CI les règles ont été bafouées totalement pour permettre de s'y retrouver. En effet les pistes peuvent se croiser, et seule la direction permet de lever le doute (associé au schéma théorique qui est lui parfaitement à jour.)

(Il faut dire que plusieurs changements d'I/O ont été faits avec le T1CKI  ainsi que des ajouts d'éléments non prévus à l'origine, et que cela a bien compliqué le circuit...)

2.3 Réalisation

Cette réalisation est faite sur un circuit simple face.
Récupérer les connexions de plusieurs appareils sur ce seul petit circuit circulaire présente une difficulté de connectique mais surtout de place.
A tel point que les connecteurs doivent être inclinés ou de taille plus réduite (Anémomètre)

Au niveau électronique, il est essentiel que les capteurs Hall soient disposés parfaitement concentriquement à l'axe (sur un même cercle).
De plus leur orientation devra être assez précise mais pourra être rectifiée par une petite torsion et éventuellement par cambrage suivant un rayon.
Une position initiale, la meilleure possible, reste la règle, mais le perçage manuel du circuit imprimé peut parfois poser quelques petits problèmes de précision de positionnement…!

Le diamètre du cercle fictif portant les capteurs est très important, de même que les caractéristiques et les dimensions de l'aimant, car dans le cas contraire on pourrait avoir 2 capteurs actifs en même temps, et tout autant, aucun capteur actif, si le cercle est trop grand. (Le diamètre du cercle portant les pins des capteurs est de 32.42mm)
Des essais préalables de distances avaient été nécessaires pour déterminer les dimensions optimales, mais contrairement à toute attente, je n'ai relevé aucune erreur en ce sens lors des essais. (Pour une fois c'est merveilleux !)

On notera qu'il aurait été possible, de traiter les 16 points cardinaux mais l'intérêt restait limité en l'absence d'un véritable amortissement de cet équipement mobile et de l'utilité d'une telle précision. De plus le diamètre du cercle porteur des capteurs aurait dû être largement augmenté, ainsi que le prix, et la consommation  !

Cependant on peut supposer que l'hystérésis devrait induire un décalage suivant que l'on parcourt dans un sens ou dans l'autre. Cela n'a pas été le cas car j'ai vérifié pour une seule direction et j'ai trouvé rigoureusement les mêmes valeurs. J'ai donc clôturé les essais sans autres vérifications supplémentaires.
Pourquoi cela ? Je suppose que la réalisation avec des pistes assez fines autorise des variations infimes de tension qui peuvent agir sur l'hystérésis en faisant basculer.

A l'origine, le seul anémomètre était raccordé depuis le boîtier d'alimentation du mât par le bais du câble d'alimentation (J1 pin 4). Ce point est délicat car il faut un 2ème câble et cela interdirait un troisième ! Alors j'ai installé non pas un seul connecteur mais 2 de plus.
Un pour l'anémomètre et un deuxième pour le pyranomètre. (De plus la situation précédente obligeait à faire transiter en aller-retour ces impulsions du signal anémomètre jusqu'au boîtier d'alimentation (boîtier du mât), avec les difficultés de passage des câbles blindés).
J'ai préféré cette situation de 2 connecteurs de plus, car l'anémomètre est par définition le plus perturbateur en temps des appareils, et comme ce PIC n'a pas grand' chose à faire, autant faire travailler les électrons !

L'anémomètre est maintenant connecté par une nappe rigide extra plate sur un mini connecteur. Rien n'était prévu de tout cela et j'ai profité pour l'un des connecteurs, de composants prévus en "spare" sur le circuit imprimé et pour l'autre d'un découpage du "Copper Pour" (Plan de masse), pour souder le deuxième connecteur. Outre ces connecteurs, les modifications restent nombreuses et nécessiteraient un nouveau circuit imprimé… Mais la tâche est trop longue, et importante alors je suis obligé d'y renoncer.

La distance des capteurs Hall et l'orientation sont des éléments importants pour la symétrie ainsi que pour la précision du positionnement.

Lors de la mise au point j'avais à bon escient gardé les pattes "signal" des OH137 à bonne longueur pour pouvoir placer une sonde de contrôle. Cela a été très utile et tient lieu de point test et permet en outre de tracer le relevé angulaire de contrôle suivant.
Ce relevé indique la position en degrés avant basculement. La position absolue n'est pas importante, seul l'écart avec le suivant l'est. La position réelle de la dérive sur l'axe permettra l'alignement sur la rose des vents.
Voici donc ce relevé  brut sans correction de position des capteurs, et dont seul les écarts sont donc véritablement significatifs :

precision_angulaire.ods

Pour dire quelques mots sur une autre solution de mesure angulaire... J'avais fait quelques essais avec 2 capteurs LINÉAIRES Hall en quadrature type UGN3503, mais la discrimination des directions était compliquée et devait être traitée au niveau d'une plage de valeurs pour chaque direction mais peut-être avec une indétermination possible. Ceci au niveau programme compliquait significativement et je me suis rangé à faire plus simple et pouvant être reproduit quelque soit le circuit UGN.

A titre d'information voici le résumé en image des essais réalisés, avec les nombreuses comparaisons à réaliser pour réaliser les 8 discriminations nécessaires.

Pour la compréhension, ce sont la conjonction  des barres rouges et bleues des courbes C et D en quadrature qui permettent de discriminer dans quelle orientation on se trouve. Vous le vérifiez par les comparaisons écrites à la main pour chaque cas.

Le sujet est délicat car il faut un équilibre entre saturation et la détection/discrimination/symétrie.
Trop compliqué surtout au niveau programmation, avec des vérifications difficiles également, alors j'ai abandonné faute de temps, mais pour ceux qui le souhaitent, ça vaut la peine de creuser le sujet surtout pour se faire plaisir !

3 Thermomètre

(Sur la photo, le circuit TO92 avec un "8" inscrit sur fond jaune est le circuit de mesure de la température).

A l'origine, ayant un nombre d'entrées assez large, j'ai voulu utiliser ce qui me restait d'entrées libres en ajoutant la température (Extérieure) avec une simple CTN, mais le problème de la linéarité et de l'étalonnage m'ont dissuadé de choisir cette solution, car trop compliquée à résoudre correctement et avec une bonne précision.

J'avais il y a quelques mois fait des essais sur les capteurs DS18B20 et j'avais crée les routines ONE_WIRE qui fonctionnaient, mais les essais de l'époque étaient réalisés à 8 MHz car contrairement à ce que l'on pourrait croire, le bus ONE_WIRE travaille à la µs et ce "simple" capteur est un véritable processeur à lui tout seul.
Alors que deviennent mes  2 MHz de vitesse d'horloge face à cela …
Il a fallu s'adapter et parfois abandonner quelques "call" pour une ou 2 macros pour gagner un peu de temps. Ceci étant ça passe avec fosc à 2 MHz !

Pour rappel ce circuit intégré de mesure de température possède en natif, un code unique sur 48 bits qui permet de dialoguer avec de nombreux thermomètres DS18B20, sur un bus d'un seul fil.
Ce composant DS18B20 étant seul dans ce cas d'emploi, on peut se passer de la commande MATCH ROM et utiliser la SKIP ROM ce qui élimine la sélection par le "serial number" de 48 bits.
Ce point garanti un remplacement par n'importe quel circuit du même type mais toujours de code ROM différent, sans nouvelle programmation.

Pour la précision, j'ai gardé le convertisseur en 12 bits, de prime abord,  parce que c'est la valeur par défaut, mais aussi par le fait qu'avec les évènements météo, on est rarement très pressé...
Il faut dire que la conversion peut être un point critique dans certaines applications, car le temps de conversion dépend directement du nombre de bits, et qu'à 12 bits il faut 750ms de temps d'attente avant d'avoir la valeur disponible.
J'avais pensé lancer la conversion en début de la boucle générale et de tester la fin de conversion le moment venu, mais il semble qu'il faille tester immédiatement après l'ordre, alors la conversion sera faite seulement à ce moment de la mesure de température. On devra donc attendre les 750ms !

Ce circuit est un réel avantage, car il est en théorie déjà étalonné à 0.5 degré près et sa résolution est de 0.0625°C (Voir un peu après cette question de précision…).
Certes le dialogue pour l'extraction de la température est un peu lourd à exploiter surtout pour un seul capteur, mais on gagne largement en étalonnage et en précision. De plus ce circuit en standby consomme moins de 750 nA ! En conversion de température la consommation monte à 1.5 mA seulement.

Ce circuit DS18B20 a été mis en lieu et place de la CTN et c'est encore une modif de plus !
Disposant du Vcc, la fonction "parasite power" n'est pas utilisée, et de mémoire, je n'ai jamais réussi à la mettre en œuvre ! ?

Dernière modification pour la prise de la température… En faisant quelques relevés sur PC et le logiciel Bray++ je me suis rendu compte que la température mettait beaucoup de temps à évoluer. Cela se comprend aisément car le circuit est à l'intérieur du mécanisme et peu sujet aux courants d'air.

Aussi j'ai dû passer un fil de cuivre de 2.5² soudé sur un petit radiateur entourant le DS18B20 et traversant la plaque de tôle support. Sur ce fil a été clipsé (Démontage oblige) un mini radiateur chargé de conduire les frigories ou les calories vers le DS18B20 !!!  (photo ci-contre)

Autre problème, à l'exploitation des températures je me suis aussi aperçu d'une erreur systématique de 2°C environ, si bien que ce que je pensais de l'étalonnage natif est en réalité faux.
J'ai cherché un bug dans mon programme et vérifié le CRC, tout est correct, et seul le bit CRC erreur n'était pas testé, l'omission a été réparée, mais sans plus de résultats. Alors je suppose que ces capteurs venant de l'empire céleste, sont de mauvaise qualité ou sont des rebuts.
Ce fait m'oblige à une addition 16 bits de plus, mais c'est un très petit inconvénient dans la mesure où l'erreur est constante.
(J'avais également vérifié qu'il n'y avait pas d'erreur de puissance de 2 en balayant toutes les gammes de températures!)

(On remarquera aussi sur la photo une tige transparente taillée en biseau... C'est un guide de lumière qui reçoit la lumière des 2 LED )


4 Pyranomètre

Ce pyranomètre mesure donc le rayonnement solaire thermique par le biais de l'énergie dans le domaine visible  (600/1050 nm de longueur d'onde) .
Cette mesure n'est pas parfaitement rigoureuse du fait du rétrécissement de la plage des longueurs d'ondes traitées, mais en est très proche au niveau résultat thermique.

Cette mesure est simple car une entrée analogique suffit, et il aurait été dommage de s'en priver, car on fera la confusion de 1024 pas du convertisseur avec 1000 pas soit 1000 W/M². Ainsi on donnera simplement la conversion décimale de la valeur 10 bits comme grandeur de rayonnement  thermique.

J'avais déjà crée un tel capteur pour ma régulation solaire thermique il y a quelques années dans un mamelon de plomberie 15x21 avec un raccord collet battu côté photo diode, et raccord collet battu droit ou coudé et bouchon caoutchouc de l'autre.
Cependant, à l'époque, le signal de la photodiode était acheminé directement à la régulation, ce qui n'est plus le cas aujourd'hui, car il y a un ampli AOP rail to rail, gain unitaire pour ne pas perturber le très faible courant de la diode et transmettre l'information en basse impédance.

Cet ensemble inséré dans le raccord était un tout petit circuit rond double face. (Ce n'est plus le cas  !)
L'AOP est le premier et il est "recouvert" par la photo diode. Les quelques composants discrets trouvent leur place sur l'autre face.
Il est plus simple de faire 2 petits CI perpendiculaires dont le premier porte la photodiode, et le deuxième l'AOP. Il est tout de même plus prudent de mettre un plastique d'isolation concentrique.
Le pyranomètre est donc refait suivant ce principe plus facilement réalisable. (Schéma et plan ci-dessous)

4.1 Circuit et CI du Pyranomètre

J'avais égaré le schéma et j'espère ne pas avoir fait d'erreur en le reconstituant d'après le circuit !

Les plans se suffisent à eux même tant ils sont simples. La photodiode BPW34 ou BP104 est parcourue par un courant très faible ce qui a nécessité l'utilisation d'un AOP.  Il s'agit d'un OPA2348 rail to rail entrée/sortie.

On remarquera l'importance du condensateur d'entrée d'alimentation pour éviter les sauts désordonnés de valeurs de conversion dus aux variations de tension, car il y a quelques longueurs de fils !!!
Le circuit imprimé est en simple face.

4.2 Particularités

Ce circuit est très sensible et il y a lieu d'interposer des filtres optiques devant la BPW34. C'est avec ces filtres que l'on règlera la sensibilité exacte. (Personnellement la valeur 10 bits de conversion me suffit largement car je n'ai pas les moyens de faire mieux sans un pyranomètre étalon)

Pour ce genre d'opération, des filtres gris neutre seraient parfaits, mais cela ne se trouve pas facilement, alors on peut tricher un peu avec certains papiers argentés qui enveloppent certains gâteaux, ou même certains emballages gris-bleutés qui enveloppent certains composants électroniques.
Il suffit d'empiler ces rondelles jusqu'à la bonne valeur. On les découpera par emboutissage ou au ciseaux.

Ces rondelles sont suivies par un petit joint torique qui assure l'étanchéité du pyranomètre. Côté fils il y aura de même un joint torique dans l'écrou collet battu. (Joint caoutchouc torique ou même joint caoutchouc plat)

Le fil blindé 2 ou 3 conducteurs est nécessaire, car c'est sa "petite rigidité" qui assure en même temps le placage de la BPW34 contre les filtres.

On notera que les filtres souffrent des rayonnements UV et se détruisent petit à petit, car le soleil brûle les pigments ou les particules non transparentes. Toutes les années je dois renouveler ces filtres qui sont brûlés par le soleil, pour avoir une valeur "réaliste".

Dernière minute :
Dans la réalisation, le pyranomètre se trouve maintenant côté Nord, car l'emplacement du mât a été revu en dernière minute pour "x" raisons... Ce fait induit de surélever ce pyranomètre car il serait trop masqué par le dôme du GPS. Il est donc monté sur colonnettes et retourné  pour garder une orientation moyenne vers le SUD (45/60° environ). (Cette modif mécanique ne change rien au sujet général)

4.3    Trames RS232 globales

Voici ci-dessous quelques trames envoyées par l'ensemble des 4 appareils (anémomètre, girouette, pyranomètre, température). L'horodatage est fait par le logiciel Bray++. (A noter que l'horodatage ne sera pas issu de ces appareils qui ne possèdent pas d'horloge de référence, mais plus après...)

L'ensemble est séparé par des ";". D'une façon générale, on trouve une valeur et immédiatement après son unité, car je me suis rendu compte que donner des chiffres sans aucune indication est suffisant dans un immédiat très proche, mais après un certain temps, on oublie tout et on se demande ce que sont ces valeurs !!!

En premier on trouve les résulats de la girouette avec les 8 possibilités de la rose des vents (S,SO,O,NO,N,NE,E,SE). Il n'y a pas d'unité pour cette donnée puisque c'est une direction sans unité particulière. Donner des degrés angulaires compliquerait encore plus les choses.

En deuxième information, on trouve la vitesse du vent en Km/h comme indiqué car cette unité est toujours bien comprise par tout le monde. à la suite on trouve donc l'unité en Km/h. Deux décimales accompagnent la valeur qui peut aller jusqu'à 999 Km/h ... Pas tout à fait le mur du son !!! L'unité rappelée suit la valeur.

La troisième information est la température en °C avec 4 décimales puisque la résolution est de 0.0625°. Cette précision reste celle du convertisseur 12 bits du circuit, et dans la réalité on a vu qu'il y avait 2° de décalage ! La limite est 99° simplement à cause de "ma" conversion BCD qui est limitée, car à moins que le CO² de l'atmosphère soit devenu fou ou que le système soit dans une cocotte minute, on ne dépassera jamais les 125°C du circuit dans cette application ! Suit l'unité rappelée le °Celsius.

La quatrième donnée est l'énergie solaire en W/m² sous forme de d'une valeur de 4 digits au maximum, suivant ce qui a déjà été dit, soit la confusion de 1000 avec 1024, ce qui affecte un peu la précision, mais il faut avouer que cette valeur est donnée en tant qu'indication et non en tant que valeur formelle.

Enfin pour terminer la trame, la révision du logiciel "anémomètre" est indiquée, car c'est important, vu le contexte, parce que  ces trames vont être utilisées, interprétées ou passer par plusieurs points...
Le tout dernier élément est un RETURN qui termine toute trame.

Terminal log file
Date: 18/01/2022 - 17:14:31
-----------------------------------------------
SE;1.08;Km/h;0.875;°C;23;W/m2;R007C
17:14:53.381>  E;0.72;Km/h;0.875;°C;0;W/m2;R007C
17:14:54.521> SE;0.72;Km/h;0.75;°C;10;W/m2;R007C
17:14:55.578>  E;0.72;Km/h;0.75;°C;10;W/m2;R007C
17:14:56.697>  E;1.08;Km/h;0.75;°C;8;W/m2;R007C
17:14:57.894> NO;1.08;Km/h;0.75;°C;6;W/m2;R007C
17:14:59.112>  N;0.72;Km/h;0.75;°C;4;W/m2;R007C
17:15:00.188> NE;1.08;Km/h;0.75;°C;10;W/m2;R007C
17:15:01.253> NE;0.72;Km/h;0.75;°C;2;W/m2;R007C
17:15:02.459>  E;0.72;Km/h;0.75;°C;24;W/m2;R007C

5 Infrastructure générale

NOTA : Le pyranomètre situé à droite est maintenant monté sur colonnettes et incliné de l'autre côté. La photo n'est pas à jour !

Une boîte étanche est placée à proximité sur le mât et comportera (Les plans viennent d'être réalisés) une petite alimentation 5 volts pour l'ensemble du mât et une redistribution des différents signaux vers la maison.
A l'origine, Je pensais regrouper en une seule trame comportant les informations anémomètre (4 appareils au total) et les informations GPS de temps, mais pour cela il fallait un autre PIC.

Alors vu le nombre de fils dont je dispose, cela aurait demandé quelques fils de plus et je ne les ai pas ! De plus je n'adhère pas du tout à l'électronique extérieure, et à une mise au point difficile.
Alors cette boîte du mât comportera le minimum et seulement l'alimentation 5V et quelques fils de commandes  distantes (Enable Alim et Power_on GPS) ainsi que les signaux attendus :

TX Anémomètre, TX GPS, 1Hz GPS, (Et Impulsions Anémomètre -qui ne sont pas nécessaire- puisque transmis dans la trame Anémomètre, mais cela utilise simplement le dernier fil disponible)

Les 2 transmissions TX sont à 9600 bps, Le signal 1 Hz issu du GPS servira à mes besoins électronique "divers et variés" comme référence précise de temps mais dont l'origine peut être décalée de quelques dizaines de nano secondes à cause des longueurs de fils jusqu'à la maison.

Les vitesses RS232 sont homogé-
néisées sur la vitesse par défaut du GPS soit 9600 bps. Ceci évite de program-
mer le module GPS très compliqué.
Le signal 1 Hz devra être testé car il est le reflet de la synchronisation du GPS sur les différents satellites. Il doit donc transiter, car même en l'absence de satellites des trames incomplètes sont émises.

Ce mât, sera également chargé de commander la mise sous tension du GPS qui est assez gourmand à plus de 49 mA par l'un des fils.
Un MOSFET_P assurera la validation d'alimentation du GPS.

Un autre fil permettra aussi la mise hors tension de la totalité du mat par le biais de l'entrée ENB de l'alimentation.

6 Le GPS UBLOX

Bien que présent sur le mât, il est traité à part des autres appareils, car c'est un gros consommateur d'énergie avec ses 49 mA au mieux.
Ce module acheté, de marque UBLOX, type NEO-6M  fournit des trames à 9600 bps par défaut.
Ces trames répondent à la norme NMEA, et pour ce qui nous intéresse en poste fixe, seules les trames $GPRMC seront exploitées, car elles renseignent la date et l'heure, éléments indispensables et nécessaires prévus.

De plus ce circuit donne des impulsions très précises, par défaut, toutes les secondes (sur la LED).

Pour plus de précisions sur le GPS voir l'article précédent sur ce GPS UBLOX NEO-6M

Les éléments de temps sont de précision extrême, puisque issus de plusieurs horloges atomiques situées dans les nombreux satellites qui se corrigent en permanence pour délivrer le temps avec une précision peut-être même plus pointue que le célèbre DCF77 , et en tous cas plus rapide que ce dernier (une fois synchronisé).

Les trames GPS seront donc envoyées vers la maison et/ou tout autre appareil (Tracker photovoltaïque par ex.) si elles sont demandées.

Ce GPS devra être paramétré physiquement par un strap CFG_GPS0 power mode permettant  une réduction significative de consommation de 63 mA vers 49 mA.

Il devra en outre être modifié par la coupure du signal RX au connecteur du module et sera remplacé par le signal 1 Hz issu de la LED témoin du circuit. (Pin 3 du NEO-6M)

A moins de vouloir programmer ce circuit très complexe, le signal RX de ce module n'a donc aucune utilité dans le cas présent et cela permet d'avoir un étalon de temps à la seconde, ce qui me semble très très utile (C'est ma conception du sujet !)

Ce signal 1 Hz est important aussi car il est le témoin de la synchronisation du GPS sur un nombre suffisant de satellites. Il sera nécessaire de consulter ce signal pour être certain de cette synchro. (Cela évite de consulter d'autres trames renseignant sur le nombre de satellites et ceux qui sont opérationnels)

Au niveau installation, l'antenne du module a été plaquée sur le circuit principal avec un élastique. (Protéger la pile par un scotch est plus prudent !) Il est évident que l'antenne fera face au ciel. L'ensemble est fixé sur une petite plaque isolante support, juste un peu plus grande que l'orifice d'une sphère en plastique, de façon à pouvoir entrer par déformation de celle-ci. Le connecteur passe au travers de cette plaque. Un trou avec écrou central permettra de tirer et bloquer plaque et module vers le bas. Après c'est de la cuisine de bricoleur...

La sphère est obtenue par démontage d'une ampoule LED "220V". Cette ampoule devra avoir une partie plastique blanche en forme de tulipe couverte par une sphère en plastique dépolie et en chauffant un peu on arrive délicatement avec un tournevis fin, à sortir cette sphère sans la casser car le mastic devient assez mou à la chaleur.
Après, la partie basse de cette sphère ira se loger dans un capuchon de bombe aérosol avec un élastique comme joint, mais le capuchon de bombe pourra recevoir un peu d'eau de pluie sans problème. Elle sera évacuée au niveau du passage des fils. Le module sera ainsi protégé. (Indice IP44 environ !!!)

Le connecteur a tendance à se sortir des pins surtout lors du montage, aussi un petit verrouillage avec un fil est nécessaire (Voir photo ci-dessus tortillon blanc).
Cet ensemble sphérique semble bien adapté pour résister aux diverses intempéries.

Au niveau configuration vous devrez réaliser straps et coupures pour mettre le signal CFG_GPS0 (Pin 16) à la masse, puis couper la liaison RX et raccorder la pin 3 (Time_pulse 1 Hz NEO-6M) sur la pin connecteur "RX". (le sommet de la résistance de LED est plus simple et moins risqué, car c'est aussi la pin 3)

Un exemple de la liste des trames GPS est donnée dans l'image ci-dessus. (Les coordonnées latitude et longitude GPS sont sans intérêt ici)
Ces trames GPS sont séparées des trames anémomètre et sont véhiculées sur deux fils différents, car il n'a pas été possible de les intégrer dans les trames anémomètre pour les raisons déjà exposées.

7 Le mât

Physiquement, le mât regroupera les 4 appareils de mesures déjà présentés ET le GPS, ainsi qu'une boîte de dérivation ("Boîte du mât") qui contient l'alimentation 12V-->5V,  et le dispatching du signal des 4 appareils d'une part et du GPS d'autre part. Les liaisons dont je dispose depuis la maison sont seulement au nombre de 3 fils simples et 3 fils dans un fil blindé. Ajouter à cela 2 fils de puissance 12V.  

NOTA : Le GPS est traité spécifiquement car il consomme "suffisamment" (49 mA en mode éco), ce qui justifie son traitement particulier.

Outre la météo, le mât est aussi chargé de donner l'heure GPS à tous les utilisateurs, mais il n'est pas acceptable de laisser le GPS sous tension en permanence.
Il devrait donner l'heure de façon parcimonieuse car il consomme un peu trop pour être toujours sous tension.
Aussi à la maison, il est prévu d'utiliser un autre petit circuit en complément en I2C cette fois : le DS1307 qui pour une consommation dérisoire sur pile CR2032 maintiendra l'heure et pourra la redistribuer rapidement sans aucun temps d'attente contrairement au GPS qui a besoin d'un temps initial de recherche des satellites (De façon standard, bien que sous certaines conditions ce temps puisse être réduit)

Le GPS serait donc activé une seule fois par jour (Ou même par semaine ?) ce qui permettrait une mise à l'heure précise d'un DS1307, heure qui serait alors considérée comme parfaitement exacte (Sans dérive notoire sur un espace de temps de 24 heures voire un peu plus).
Le GPS devrait être lancé de nuit vers 4 heures du matin, bien que celui-ci ne soit pas sensible aux heures d'été/hiver, mais cela facilitera la mise à l'heure du DS1307 aux dates de changement d'horaires été/hiver.

La boîte du mât pourrait être en permanence sous tension, car sa consommation propre reste faible mais ce mât peut cependant être mis hors tension  par l'ENB de l'alimentation (Fil issu de la maison). Cette consommation est seulement celle du convertisseur au repos (soit 2.4 mA), mais pourquoi laisser sous tension alors que l'on utilise aucun appareil ? Le blocage se fera par la mise à zéro de l'entrée  ENB du module alimentation.

Au vu de mes expériences passées, il s'avère également utile de réaliser un perchoir pour les oiseaux eh ! Oui, aussi surprenant que cela soit, les oiseaux faisaient leurs besoins sur les capteurs de la première version de mon panneau solaire thermique et cela m'avait posé des problèmes. Alors autant mettre une petite barre un  peu surélevée et décalée de tout ce qui risque en dessous.

Notez que ce n'est pas seulement les déjections mais j'ai aussi vu les mésanges attaquer le polystyrène qui enveloppe les purgeurs automatiques du panneau thermique. Voilà c'est fait, réalisé, et c'est le plus facile !

Initialement l'ensemble devrait prolonger un piquet d'étendoir à linge. Au vu des problèmes de turbulence à cet endroit, j'ai préféré créer un mat spécial en bordure de terrain.
La protection contre la foudre reste un soucis et pour ne pas "tout ramener" vers la maison, je pense qu'il faut un minimum de précautions pour évacuer les décharges à la terre avant qu'elles ne suivent les différents fils.

Le plus dangereux est certainement la fonte des fils sous terrains ou l'amorçage, car leur remplacement nécessite de gros moyens. En ce qui concerne l'électronique, je ne me fais pas trop d'illusions car il y aura certainement un  peu de casse, même avec quelques VDR, y compris avec peut-être des éclateurs à gaz ou à pointe.

7.1 L'alimentation 12V vers 5V

L'alimentation du mât est achetée sous forme d'un petit module de quelques Euros et sera incluse sur le CI futur. Elle a l'avantage de posséder une entrée de validation (En l'air ou à 1) Elle alimentera la totalité des équipements.

Un zéro bloque son fonctionnement. Elle est basée sur un circuit buck-Boost XL6009 pouvant délivrer 3 à 4A  sous 1.25 à 35V avec une entrée à 4V minimum.
Elle est de dimensions 4.8 x 2.2 cm et elle possède un réglage de la tension de sortie 1.25 à 35V qui peut dépasser la tension d'entrée.
Dans notre cas l'entrée sera en 12V et la sortie 5V  et le courant d'entrée sera bien entendu plus faible que le courant de sortie.

Comme toutes ces alimentations à découpage, cette alimentation doit être chargée au minimum de quelques mA !

En dessous de 4V en entrée, la sortie monte à des valeurs extrêmes au dessus de 50V, alors que le chimique de sortie est isolé à seulement 35V, aussi un petit circuit avec diode zener de 5.1v en série avec 15K le point milieu réunit par 10 K à l'entrée ENB du module serait une solution de préservation.
Il sera toujours possible de bloquer cette alimentation  par un 0 logique sur la pin ENB (Commande à distance !)

L'application théorique d'une tension de 12V passe nécessairement par cette étape de 4V, mais le temps de montée étant extrêmement court, cela ne doit pas perturber ? Alors cette disposition intéressera principalement la régulation pour le panneau photovoltaïque, mais par prudence je l'applique tout de même, (ou cas où la batterie soit à plat ? !) à voir sur le schéma du mât.
En réalité cette tension de 12V est une tension minimum, car c'est la tension du panneau si elle est supérieure à 14 V, mais cela ne change rien au sujet. Ceci est juste une question de fils disponibles et pour réduire les pertes, j'ai préféré transmettre la tension maximum, aussi c'est une tension variable entre 14V et 28V environ qui alimente la boîte du mât.

NOTEZ l'abus de langage "12V" ou "14V" qui est en réalité une tension variable


7.2 La connectique

La mât est aussi associé à la boîte étanche, juste en dessous des appareils, et assurant la répartition des signaux anémomètre et GPS ainsi que l'alimentation 5V de l'ensemble.
Cette boîte du mât recevra donc les connexions des 4 équipements principaux déjà cités, et du GPS et elle recevra aussi l'alimentation 14V et quelques fils de contrôle en provenance de la maison.
Deux fils de données RS232 en sortie complèteront ces liaisons avec bien entendu la référence de tension Gnd ou 0V.
Le 0V sera confondu avec le négatif de la batterie et le négatif du panneau photo voltaïque.

Outre ces RS232, deux signaux de commande, Alim et GPS, ainsi que le signal 1Hz du GPS et comme un fil était encore non utilisé, les impulsions de l'anémomètre seront également diffusées !
Pour "faire joli", 5 LED visualisent les tensions d'alimentation et les signaux TX et le 1 Hz.

NOTA : Le signal 1 Hz n'apparaît qu'après synchronisation sur les satellites.

Une connectique par bornes sera utilisée de manière à pouvoir passer par les bouchons caoutchouc de la boite et de désolidariser facilement les équipements du mat. Dans un autre cas, avec les connecteurs petits  signaux ce sera le bouchon complet caoutchouc qui sera extrait pour libérer la connectique.
Ces liaisons sont délicates, car en extérieur, et pas toujours facilement accessibles à causes des conditions météo parfois très gênantes (Neige, pluie, vent, froid, durée d'intervention trop courte en hiver, etc…)

C'est la raison pour laquelle en cas de problèmes, on emportera directement l'ensemble des équipements du mât ainsi libéré de ses câbles d'attache.

8 Conclusions

Cette centrale temps et météo devrait répondre à la demande de disposer d'un temps précis et de permettre de prendre des décisions au niveau des panneaux solaires pour les mettre en sécurité tout autant que leurs donner les informations d'heures pour les lever et coucher du soleil.

De plus la partie Pyranomètre peut éviter de lancer la régulation de position alors que l'ensoleillement ne permet pas d'être rentable énergétiquement.

Ainsi que je l'avais évoqué lors de l'étude I2C, j'ai besoin d'avoir des références de temps au niveau général, et le GPS représente un réel avantage pour la précision.

D'une façon générale, les valeurs précises et les étalons sont des éléments incontournables et cet ensemble va permettre d'y voir plus clair....

Mais il reste du travail pour mettre en forme ces différents signaux et d'assurer les commandes correspondantes pour mettre en œuvre ces équipements.
Il faudra gérer les dates été/hiver tant que la décision Française/Européenne n'est pas prise et pouvoir s'adapter par la suite.

Ce futur travail est représenté par un nouveau montage avec un PIC et une solide programmation pour que tout cela soit utilisable instantanément et facilement.
Un DS1307 disposera de l'heure GPS datant de 24 heures ou plus et pourra la diffuser à la demande en quelques fractions de secondes.

NOTA : Le circuit DS3231 pourrait aussi être utilisé, mais ceux que j'ai eus sont complètement en dehors des spécifications. Cependant comme c'est un TCXO, il devrait permettre de limiter la mise à l'heure GPS peut-être avec un peu plus de distance entre chaque update. Il présenterait un avantage aussi car il y a des alarmes de temps qui peuvent être très utiles... Mais il coûte plus cher et à priori ne peut pas être réglé contrairement au DS1307 qui peut être légèrement ajusté si la fréquence est au dessus de la valeur nominale.

La température pourra être gérée en termes de mini-maxi et avec une alarme lorsque 0°C approche dangereusement.
Bien que mon panneau solaire thermique fonctionne toujours maintenant avec de l'antigel, dans les débuts, je me suis laissé prendre et quelques tuyaux avaient gelé et éclaté, alors le ZÉRO degré est important!

Enfin, il reste encore à réaliser l'alimentation de la batterie par le panneau solaire photovoltaïque, mais ce n'est pas tout, car l'électronique de ce panneau est en panne car elle n'a pas résisté aux intempéries et j'ai en projet de la rentrer à petite distance d'un petit local pour la mettre à l'abri.
Cette alimentation sera identique à celle du mât, puisque le panneau de 12W ne peut fournir que 0.686 Ampères sous 17.5V et ces valeurs rentrent parfaitement dans les spécifications à la particularité cette fois que la tension peut se situer de 14V à 28V et que la protection >4 V utilisée pour le mât n'est pas absolument nécessaire.

Dans les points corrigés et hors du sujet principal, on notera la peinture des éléments en PVC (boîte du mât), car cette matière exposée aux UV et au temps, se détériore en une année !

Le DCF77 fonctionne quand il veut et cela est réellement horripilant, aussi avoir rapidement l'heure sera une véritable avancée.

bricolsec

Date, heure… et secondes GPS

1    Pourquoi cette nécessité de l'heure

1.1    Très peu de sémantique
1.2    Les raisons personnelles
1.3    Un but pour l'étalonnage
2    Les procédés
3    Le quartz
3.1    Les principes
3.2    Rendre un quartz plus précis
3.3    Autres sources de temps
3.3.1    GPS
3.3.2    Horloge atomique
3.3.3    EDF
3.3.4    Un PIC
3.3.5    Module DS1307
3.4    Régulation de température
4    Quelques circuits électroniques
4.1    DS1307
4.2    DS3231
5    Comment avoir du 1 Hertz
5.1    DS1307 ou DS3231
5.2    DCF77
5.3    Essais amplification 77.5 KHz
5.4    Par Internet www.time.is
5.5    Par GPS UBLOX NEO-6M
6    L'étalonnage (avec GPS)
6.1    Le montage utilisé
6.2    Schéma réalisé
6.3    Étalonnage
7    Conclusions
8    Le mot de la fin
9    Expérimentation modules UBLOX NEO-6M (article complémentaire)

Si vous arrivez directement sur cette page par un moteur de recherche, vous pouvez avoir accès à la table des matières et à chaque article, en page d'accueil.    L'accès se fait par l'un des deux liens en tête de colonne de droite ----->

ATTENTION à compter du 15/09/2019 les commentaires ne seront plus possibles à causes de quelques imbéciles qui font du spam pour le plaisir de nuire ! désolé  !

Préambule

Avec beaucoup d'humilité, j'aborde le sujet du temps, car je viens de m'y frotter avec quelques difficultés, quelques succès aussi, et quelques d'incertitudes...
Ainsi que je l'ai déjà esquissé dans quelques articles précédents comme l'I²C, le DS1307 ou le DS3231, le Tracker photovoltaïque, j'ai été souvent confronté au problème de l'heure pour mes réalisations basées sur l'heure (solaire, le plus souvent).
Ce sujet revient systématiquement et toujours avec un peu plus d'acuité lorsque l'on creuse davantage le sujet.

La notion de temps est extrêmement complexe dans la précision, et les définitions. Le temps fait appel aux technologies les plus délicates associées à la physique des particules comme pour les horloges atomiques, à l'astronomie..., mais pour ma part je reste à mon niveau et je suis seulement un utilisateur qui désire avoir la date et l'heure de façon simple et locale, sans avoir à utiliser des sources horaires distantes EN PERMANENCE.
Notez déjà que le GPS donne un temps UTC (Voir Wikipédia les différentes définitions), contrairement au DCF77 qui donne le temps légal mais dérivé du temps UTC. Ce temps UTC est déconnecté du temps de rotation de la terre (Temps universel TU) car il est issus du temps atomique (TAI) et l'un et l'autre sont mis à jour périodiquement pour suivre au mieux la réalité. Bref ce n'est pas très simple car il y a encore d'autres définitions.... et j'espère ne pas avoir dit de bêtises à ces sujets très techniques et astronomiques.

Le plus important dans ce sujet est de garder date et heure de quelque type que ce soit tout au long des mois et d'une bonne dizaine d'années, avec au maximum quelques centaines de secondes d'erreur, et encore mieux si possible !

En corollaire, je ne me suis que très rarement inquiété de la mise à l'heure précise de mes montages avec micro contrôleur PIC, car si nécessaire, je profitais de la nuit pour me synchroniser sur le DCF77, mais c'est également important, et j'ai rarement (ou jamais) utilisé le réglage OSCTUN, car toujours dans les bonnes limites pour la RS232 par exemple (Baudrate).
La réalité est que j'avais bien supposé qu'il était nécessaire de remettre à l'heure régulièrement les systèmes, qu'ils soient à quartz ou non, mais sans aucune preuve formelle, et par simple bon sens.

AVERTISSEMENTS :
Pour couronner le tout, en cherchant sur Internet le schéma des GPS achetés, je me suis aperçu que j'ai dit une bourde à propos de la tension de fonctionnement des MODULES GPS achetés. En effet je me suis aperçu après coup, que ceux-ci comportent un régulateur LDO qui assure le passage de 5V à 3.3V pour la puce GPS. Ceci permet de brancher directement sur 5V le module GPS, alors que le circuit UBLOX NEO 6M fonctionne effectivement en 3.3V. Attention donc à cette particularité avec le terme GPS souvent confondu par facilité avec le Module GPS, ce qui n'est pas rigoureusement la même chose.
Cette erreur est due à ce que les Chinois ne sont pas capables de fournir un minimum de documentation à leurs produits.
 
Ceci concerne l'inutilité, (voire l'erreur mais sans conséquence) concernant le circuit d'adaptation qui comportait un régulateur 3.3V et deux conversions de niveau pour TIMEPULSE et l'autre pour RX (Une conversion pour chaque sens).

A ce jour, et sans utiliser la pin RX qui est réaffecté à TIMEPULSE, il suffit de brancher simplement le module sur le Vcc 5V, et tout fonctionne correctement pour l'utilisation prévue (Pas de paramétrage par RX).
On fera cependant très attention à la batterie de sauvegarde que l'on protégera par un scotch épais car c'est la partie extérieure qui est le +, et une masse est vite proche, surtout si l'on empile antenne et circuit l'un sur l'autre, ce qui est possible tant physiquement que fonctionnellement.

Cette facilité de branchement ne doit cependant pas cacher la nécessité de convertir le 5V en 3.3V pour tout signal entrant vers le GPS (Cas de la pin RX si elle devait être utilisée). A l'inverse, il semble acquis que les tensions 3.3V sortantes restent compatibles avec les entrées CMOS des principaux circuits utilisés sous 5V.
Il est donc possible qu'il reste quelques bribes de ces particularités dans les textes et schémas.

NOTA : Quelques éléments de texte n'étant plus exacts ont cependant été laissés mais rayés (rayés) pour bien souligner quelque chose qui a été vrai à un instant donné mais qui ne l'est plus maintenant.

1 Pourquoi cette nécessité de l'heure

1.1 Très peu de sémantique

Lorsque je parle de l'heure en général, il faut comprendre la date et l'heure.
Par date il faut détailler le jour du mois, le jour de la semaine, le mois et l'année.
Pour l'heure il faut comprendre par dérision l'heure, les minutes, les secondes et même les fractions de secondes parfois.

Pour la date qui ne pose pas de véritable problème une fois initialisée, le jour de la semaine peut même être recalculée par différentes méthodes.
On remarquera que le jour et la nuit sont des limites qui évitent toute erreur d'interprétation.

En ce qui concerne l'heure, celle-ci est beaucoup plus petite et sujette à des DÉRIVES qui se matérialisent seulement au fil des jours. Ainsi maintenir une heure "précise" durant de nombreuses années reste un chalenge difficile, car les contraintes matérielles sont nombreuses.

Je vais concentrer mes propos sur l'heure seulement au sens général et complet englobant l'heure jusqu'aux fractions de secondes avec peut-être la création d'un système d'étalonnage. (Ainsi qu'évoqué, la date est un peu mise de côté car elle est habituellement respectée avec la précision des matériels et logiciels traditionnels).

1.2 Les raisons personnelles

Pour mes applications solaires, il y a longtemps que j'ai abandonné le positionnement par cellules, au profit des équations solaires. J'y suis venu petit à petit, en premier avec l'heure issue de vieux PC sous DOS, et j'y ai vu les limites des anciennes horloges 146818 ou DS1287.
Le principal problème de toutes ces horloges RTC est la DÉRIVE dans le temps qui pourrait amener à l'extrême limite à un changement de date.
Il faut dire en exagérant un peu, que confondre le jour et la nuit au niveau d'un panneau solaire est tout de même très gênant !!!

J'ai donc un vrai besoin d'avoir l'heure sans faire appel à une source externe de façon journalière, mais de pouvoir disposer localement des informations SANS dérive durant un délai "acceptable", c'est-à-dire de quelques semaines, mois ou années.

Pour être plus précis je dirai que je souhaiterais avoir l'heure durant 10 à 20 années sans intervention et en acceptant par exemple sur 15 ans une dérive de 5 minutes ou 300 secondes…
Pour simplifier tout, disons 473 secondes de dérive et 15 années c'est 473040000 secondes… C'est donc une précision de 1 ppm (1 partie par million)
Cette précision est plus que bonne, elle est même excellente, mais est-elle à ma portée ou à celle d'un amateur ?
(Je pense que mes prétentions devront être revues à la baisse !)

1.3 Un but pour l'étalonnage

Le seul but final pour l'étalonnage est d'obtenir une référence 1 Hertz très précise permettant de valider une fenêtre de comptage d'impulsions. (Un peu comme un fréquencemètre). Cela permettrait d'étalonner des modules DS1307 rapidement en obtenant en quelques minutes la bonne fréquence de ces modules.
Je pense que l'on peut raisonnablement rester sur des températures ambiantes vers 22.5°. Avec une petite régulation de température, peu gourmande en énergie, on pourrait obtenir à la fois une bonne référence et permettre  un étalonnage assez simple…
Cette température correspond aux quartz dits "horlogers", et il est certain qu'en période de canicule, on ne pourrait pas étalonner du fait de cette faible température (Il y a cependant une parade à cela, voir la suite). Celle-ci a cependant l'avantage d'utiliser des quartz standard peu onéreux, et au niveau amateur c'est tout de même intéressant.

2 Les procédés

Les différents procédés sont liés en premier lieu aux oscillateurs et à leur stabilité. J'ai donc fait un petit tableau des avantages et inconvénients pour mieux cerner les meilleures adaptations. ****tableau_oscillateurs.

Il est évident que certains oscillateurs à quartz sont associés à des micro contrôleurs et qu'ils apportent alors date et heure.
Cependant la précision a un grand intérêt pour le maintien A LONG TERME de la date et de l'heure, et c'est là le point le plus important.

Il faut aussi regarder si ces sources de référence sont pérennes, et à ce sujet on peut penser que les coûteux émetteurs de grande puissance en GO comme le DCF77 avec leurs immenses antennes à gérer sont appelés à disparaître à cause des coûts d'exploitation très élevés.

Les procédés de laboratoire ne sont pas  accessibles au profane, aussi pour obtenir un étalon de temps avec une sortie logique de temps (à la seconde ou à quelques KHz), je ne vois à ce jour que le GPS qui est accessible au particulier avec des coûts de quelques Euros  pour un module qui donne date et heure (Sans le jour de la semaine qui nécessite un algorithme de calcul).
Ce GPS a cependant l'inconvénient d'un démarrage à froid d'environ 27 secondes et d'une consommation de 65 mA assez (trop) importante pour le module utilisé. Un tel module en fonctionnement permanent, ne peut donc pas équiper un équipement embarqué avec peu d'énergie.

J'ai essayé des modules TCXO type DS3231 qui ne sont pas réglables et dont la fréquence de base est totalement à côté de la valeur initiale. Ils ont en théorie la stabilité en température, mais la fréquence étant fausse au départ, je n'ai malheureusement pas pu les utiliser. Cela aurait été pourtant très intéressant et certainement un bon choix, mais pour avoir des éléments de qualité il faut mettre des sommes d'argent conséquentes, ce qui est donc hors sujet.
J'ai relevé la courbe d'un DS3231 et je pense que c'est un composant foutu d'origine (Courbe ci-dessous, sans commentaires ! en X les températures, et Y le nombre d'impulsions en moins)

Alors, on peut déjà essayer un des principes que je vais mettre en œuvre pour avoir date et heure avec une bonne précision sur de longues périodes.
On calibrera donc à partir des éléments GPS des modules ajustables DS1307 dont l'accès est IMMÉDIAT et RAPIDE par I²C.

Cela nécessite plusieurs outillages malheureusement, et je suis hélas obligé de faire l'impasse sur l'aspect stabilité en température, et cela exclu de faire fonctionner les appareils en extérieur avec des variations importantes de température pour de longues périodes sans re-calibration.

Seul revers à ce principe, il faudra mettre ces équipements, dans un environnement tempéré. Je pense que c'est possible par le fait que ces modules DS1307 sont en réseau I²C et que 4 fils suffiront (avec l'alim) pour récupérer les informations. L'autre possibilité et de recalibrer plus souvent

3 Le quartz

3.1 Les principes

Le principe général à ce jour est un oscillateur électronique avec un cristal de quartz. Ce matériau oscille lorsqu'on lui applique une tension. C'est un matériau piézoélectrique.
La taille (Au sens de "tailler" comme une pierre -et non de dimensions-) d'un quartz détermine sa fréquence, mais aussi sa courbe de variation en température.
Le mot a été lâché : la température !
Voir aussi Wikipedia https://fr.wikipedia.org/wiki/OCXO

Tout serait merveilleux si ce cristal ne dérivait pas en fréquence en fonction de la température, et c'est le principal problème. Cependant la taille au sens de la taille d'un cristal définit le sommet d'une parabole dont celui-ci est calculé pour une température de fonctionnement précise.

Un autre point important concerne la fréquence de base qui malheureusement n'est en principe exacte que pour une température donnée, mais variant peu vers le sommet de la parabole.
(J'ai aperçu d'autres modèles de courbes avec variation non parabolique).
Ci-contre, mon premier relevé fait à partir de la température ambiante.
Enfin pour dorer un peu plus le sujet, le merveilleux quartz vieilli aussi, et sa fréquence dérive aussi au fil des années, en plus de la température. (Un peu comme un ressort qui s’avachit à force de fonctionner !)

A ce jour, je pense que d'autres procédés de stabilité existent au niveau mécatronique, mais là mes compétences s'arrêtent (MEMS) !

3.2 Rendre un quartz plus précis

- Une première solution consiste à installer le quartz dans une enceinte régulée en température souvent entre +50 à +75°C. Cependant la taille du quartz doit être prévue pour une telle température de fonctionnement. La taille du quartz est faite pour que la variation de fréquence soit la plus faible pour le point de température choisie (Sommet de la parabole).
Bref, il ne serait PAS judicieux de mettre n'importe quel quartz dans une enceinte thermostatée si le quartz n'a pas été taillé pour la température de fonctionnement. La précision serait même catastrophique car on se trouverait alors dans l'une des pentes de la parabole.

Cette façon d'obtenir une grande précision est malheureusement énergivore, et elle n'est pas acceptable pour un fonctionnement permanent ou en embarqué.
Elle est seulement acceptable en laboratoire pour des mesures de haute précision. Pour les équipements alimentés sur pile ou batterie, c'est donc impensable.

- Quelle autre possibilité pour rendre un quartz moins sensible à la température ? Corriger par des condensateurs en // la fréquence. C'est de cette façon que devrait fonctionner le circuit de DALLAS DS3231 (TCXO). Inconvénient, il faut mesurer la température, mais le circuit s'en charge !  Ceux que j'ai eu sont en dehors de tout et bons à mettre à la poubelle. (Voir courbe au § 2 ci-dessus)

Si on travaille à température ambiante 20 à 25°, les quartz horlogers à 32768 Hz sont une bonne solution à priori, mais j'ai quelques interrogations, car nos montres bracelets sont à température du corps humain, non à 37°,mais un peu moins vers 32/33°.

Ces quartz horlogers pour montres bracelet ne sont donc pas taillés spécifiquement pour la température ambiante de 20-25°C.
Cette autre façon de traiter la dérive en température n'est pas applicable en composants discrets car trop volumineux, mais seulement au niveau de la gravure électronique au niveau des masques des circuits intégrés spécialisés.
(Une parenthèse à dire à cet effet, est qu'il n'est pas recommandé d'utiliser le quartz d'une vieille montre pour avoir une meilleure précision).
- Je viens de penser à une solution dont je viens de voir une thèse, et qui est l'utilisation d'une diode varicap (VCXO), soit pour caler la fréquence de façon précise (à une température donnée),  soit pour corriger les variations de température et/ou les deux à la fois. Je dois dire que cette solution remporterait mes suffrages, si elle était facile, car modifier  par une tension de polarisation  permettrait de tomber exactement sur la fréquence souhaitée. Cette solution parait simple, et c'est à vérifier ! Si ça pouvait marcher …
Il faudrait cependant faire coïncider tension et variation de fréquence due à la température et ce n'est pas trop simple à priori.

Une autre question que je devrais bientôt éclaircir est de savoir si le fait de mettre des condensateurs en // sur le quartz déplace d'autant le sommet de la parabole, ou n'a aucune action sur le sommet température qui reste en place ? (Bien entendu la fréquence change)
Après essais avec et sans condensateurs, je ne suis pas en mesure de dire si on est dans un cas ou dans l'autre, car bien entendu le sommet d'une parabole est flou, avec en plus des mesures de températures moyennées et "presque au vol", mais il semble tout de même que la parabole se soit déplacée "un peu" !!! La théorie pourrait peut-être venir à mon secours ?
En réfléchissant quelque peu on peut imaginer que seul le quartz dérive et non la capacité ajoutée, mais c'est un raccourci un peu rapide, car condensateur et torsade sont certainement aussi affectés par la température et il me semble donc plausible qu'il soit difficile de statuer sur le sujet. (Voir la courbe Rouge au § 3.3.5 ci dessous)

3.3 Autres sources de temps

3.3.1 GPS

Le GPS semble une approche intéressante, car il y a de nombreux systèmes de localisation similaires, voir cet article sur wikipédia https://fr.wikipedia.org/wiki/NMEA_0183 qui présente bien le sujet pour la partie des informations disponibles dans les trames.
Les références de fréquences disponibles ne sont pas bien explicitées, car elles sont seulement le reflet des puces dédiées à l'exploitation du GPS.

En résumé, les systèmes GPS sont basés sur des satellites qui émettent des données de temps, données très précises issues d'horloges atomiques synchronisées et correction des temps de propagation. On peut ainsi par triangulation définir une position x,y,z.

Tous ces satellites ont donc des horloges atomiques de très grande précision qui se corrigent mutuellement etc…
Bref c'est très complexe et hors de mon sujet et de mes connaissances.
Ces horloges sont donc très précises, et peuvent donner date et heure tout au long des jours et années.
Un signal de temps programmable en fréquence est extrait de la réception satellite et des trames RS232 sont émises dans le protocole NMEA avec l'heure en tête de trame, ceci réalisé par les puces réceptrices des GPS .

Ce système est très fiable car largement redondant. C'est un système assez gourmand en énergie mais de faibles dimensions (Celui que j'ai utilisé est de marque UBLOX modèle NEO-6M).
C'est aussi un système qui restera toujours pérenne, car ce sont les armées de nations ou d'unions de pays qui sont au centre de ce sujet, et ce n'est donc pas demain qu'il sera abandonné car trop vital pour la sécurité défense (USA, CHINE, EUROPE…)

3.3.2 Horloge atomique

Non je ne peux pas me payer ce petit joujou…  Les horloges atomiques équipent beaucoup de laboratoires pour leur excellente précision, et elles équipent aussi tous les satellites dédiés au GPS, ce qui leur donne toute leur précision. Ces horloges fournissent le temps TAI.

3.3.3 EDF

Le secteur n'est pas très précis en instantané, mais il l'est à long terme, car le nombre de périodes est compté annuellement (je n'ai malheureusement pas retrouvé cette information officielle).
Il y a bien eu une petite dérive, il y a quelques années suite à des transferts d'énergie entre pays Européens, mais cela a été identifié et certainement corrigé pour ne plus se reproduire. (C'est ainsi que votre radio-réveil secteur a bugué, et qu'il a retrouvé sa jeunesse depuis !)
Ce réseau est très fiable mais encore faut-il pouvoir utiliser le secteur pour référence ! Dans le cas des montages embarqués sur pile ou accu, ce n'est pas le cas, mais il y a aussi un revers à la médaille qui est la coupure secteur suite à la foudre ou aux perturbations de distribution. (A noter que c'est le cas général de TOUS les dispositifs qui ont TOUS un talon d'Achille quelque part).
Ce réseau est donc fiable à la production mais un peu moins à la distribution.
En cas de coupure, il est évident qu'il faut un système de reprise pour compenser ponctuellement une coupure, ce qui est vrai aussi pour tout autre dispositif.
Ce réseau est précis à long terme mais pas en instantané, mais ne donne pas l'heure de façon formelle ce qui est très gênant pour une reprise suite à coupure.

(Même les satellites GPS peuvent être affectés par les orages solaires et les informations peuvent devenir manquantes ou peut-être erronées ?)

3.3.4 Un PIC

Il est possible d'utiliser un PIC avec son horloge temps réel bien calibrée, mais le problème principal reste sur les variations avec la température que ce soit un oscillateur RC ou un quartz…
Aussi le PIC pourrait mesurer cette température avec un  DS18B20 par exemple, et à l'aide d'une varicap corriger la fréquence du quartz par une tension asservie… Est-ce une voie ? Ou au contraire corriger par varicap en asservissement par des tables mémoire.  Tout cela parait tout de même assez délicat, car il faudra nécessairement faire appel à une régulation PID.

Sur un montage avec PIC, il ne faut pas oublier que si on passe le micro contrôleur en "SLEEP", l'oscillateur s'arrête, et c'est un problème majeur pour le maintien de l'heure.

3.3.5 Module DS1307

C'est une solution possible de garder un module DS1307 en référence de temps, après avoir beaucoup "titillé" l'ajustement de la fréquence. Mais cela reste incertain car la température d'utilisation n'est pas toujours stable, et ce qui est bon un jour, ne l'est plus le lendemain !
C'est un premier pas qui permet d'arrêter un micro contrôleur et de le remettre à l'heure rapidement, car le DS1307 est équipé d'une pile (ou accu) qui consomme réellement  très peu.
Alors…

J'ai donc réalisé une petite enceinte thermostatique avec un module PELETIER pour faire des relevés de fréquence en fonction de la température, et j'en ai donc tiré des conclusions intéressantes :

NOTA : la courbe bleue concerne le premier relevé avec correction de la fréquence de base avec condensateurs.

La courbe rouge tente de montrer un éventuel décalage de température sans correction de la fréquence (ou réciproquement)

 (*******courbe relevée DS1307_Temp_Impuls_quartz.ods).

Ces petits modules bon marché ont leur température optimale vers 22.5°C et sont peu divergents entre 17° et 27.5° de quelques 5 ppm environ.
Ces modules comportent également un emplacement pour un capteur de température de type DS18B20 et que cela peut permettre en mesurant cette température de compenser par une table, les variations de fréquence.
Cette table peut même être intégrée au circuit lui-même car il y a environ 50 octets disponibles ou si c'est nécessaire, dans une EEPROM située à côté du DS1307 sur le même module.
Le seul problème est qu'il faut ajouter un protocole complémentaire à l'I²C (ONEWIRE) pour le capteur de température, et qu'un programme spécifique devra appliquer ces corrections.

3.4 Régulation de température

On a vu que le principal problème du quartz est la température. Pour s'en affranchir, il faut une bonne régulation et on pourrait ainsi disposer d'une référence de bonne qualité, mais le problème devient vite assez onéreux avec des quartz spécifiques à commander et donc hors de prix. Ceci ne peut concerner que des étalons et non des montages d'applications.

J'avais déjà réalisé une enceinte thermostatée sur secteur et le sujet n'est pas trop difficile, car le plus délicat reste la régulation PID.
http://bricolsec.canalblog.com/archives/2013/01/13/26133974.html

Très récemment j'ai commandé un petit module à effet Peletier et je suis assez surpris de l'efficacité de ce petit carré de 4 cm de côté… J'ai choisi un modèle pouvant monter jusqu'à 6 A, mais il fonctionne très bien sous faible tension. (Cela m'a permis de descendre vers 6°C)

J'en ai tout de même réalisée une plus petite à effet PELETIER avec double radiateur chaud et froid (photo ci-contre)

Ce sujet méconnu pour moi, m'ouvre quelques horizons, principalement par le fait qu'il est possible de réguler à une température ambiante, notamment vers 20 à 25°C quelque soit la température ambiante RÉLLE, car il est possible d'inverser le chaud et le froid en inversant la polarité d'alimentation du module.
En effet pourquoi monter si haut en température, alors que l'on peut créer du froid. (Cela n'était pas possible de façon simple  il y a quelques années). Attention, cela reste très énergivore cependant !

Cela sous-entend qu'un tel module monté en pont peut tout à fait réguler une température de 20° si l'extérieur est à 25°C, ou tout à fait l'inverse soit réguler à 25° alors qu'il fait 20°C en extérieur. Attention cependant aux inerties thermiques !

Ce principe énergivore ne peut cependant servir qu'à créer un étalon de temps, mais PAS à gérer un montage utilisant un circuit de type DS1307. Ce principe permettrait de créer un étalon assez facilement soit avec des quartz 20/25°C ou même des quartz "véritablement horloger" (issus d'une montre bracelet pour être précis) qui seraient alors régulés vers 33°C comme la température du poignet.

4 Quelques circuits électroniques

DALLAS / MAXIM sont sur ce créneau de produits liés au temps avec différentes productions dont quelques unes sont très anciennes comme certains circuits intégrant directement une pile, avec l'erreur de souder le composant, ce qui rend l'ensemble inutilisable par bêtise. La bêtise revient non pas vraiment à DALLAS mais aux concepteurs utilisant les DS1287. Ce circuit est obsolète je n'en parlerai plus.

4.1 DS1307

Initialement, ce module/circuit DS1307 monté sur un petit CI m'avait séduit par son faible coût, et en abordant ce problème du temps, j'avais commis l'erreur de croire à la bonté du monde…. Il n'en est rien ! Ce circuit doit être étalonné et fonctionner dans une ambiance 15-30°C pour ne pas trop dériver.
Je ne l'ai vu qu'à posteriori.
Un élément en la faveur du module disponible chez les chinois, son prix, mais aussi un circuit sous forme de module autonome que l'on peut intégrer à ses propres montages.

Il est dommage qu'un emplacement sur le CI n'ait pas été réservé pour placer un petit condensateur ajustable de correction de la fréquence et une torsade (Queue de cochon !).

J'avais pensé à tort remplacer mon DCF77 par un tel circuit, mais j'ai dû abandonner faute d'une précision initiale suffisante (Sans parler de la dérive).
Il reste juste la place pour souder un petit condensateur CMS de 4.7 à 6.8 pf aux bornes du quartz et d'ajouter en plus une torsade pour terminer finement la fréquence. *****photo quartz avec condensateurs ajoutés.

Ce système un peu délicat est la seule manière de mettre à l'heure ce circuit pour une température "ambiante".
Il serait illusoire d'utiliser des minuscules condensateurs ajustables, car outre la visibilité de rotation, l'angle de rotation reste trop difficile à maîtriser de façon progressive (par 10° d'un coup au moins)
On notera que la torsade devra être immobilisée par un point de colle au pistolet.

4.2 DS3231

Vu la difficulté de calibration du DS1307, j'ai vu que ce circuit DS3231 était compensé en température (TCXO), ce qui n'est pas vraiment ce que je recherchais en premier, mais c'est surtout la fréquence initiale à température ambiante qui me pose problème.
J'ai cru mon problème résolu, mais il n'en était rien, car "l'AGING" (Cde interne spécifique de correction) permet d'ajuster simplement la dérive en température, mais ne permettrait pas (Du moins le datasheet semble le dire et je n'ai pas pu non plus, faire un véritable offset de fréquence). Est-ce moi qui ait mal fait ? Je ne sais pas !
Ce circuit tel quel, serait presque encore pire que le DS1307, car il est impossible de modifier par un condensateur la fréquence de base, contrairement à ce circuit DS1307.
Attention cependant de bien choisir le suffixe de ce composant pour avoir la meilleure précision. Viser le suffixe SN. J'ai bien commandé SN mais c'est l'indice M reçu ! Y-a pas moyen avec ces filous !!!

5 Comment avoir du 1 Hertz

Au final, c'est cette opération d'avoir une fréquence de 1 Hz qui m'est nécessaire pour pouvoir étalonner très rapidement des modules DS1307. Mais comment obtenir cette fréquence ?
A remarquer qu'avoir du 1 Hz n'est pas une nécessité permanente, mais seulement nécessaire le temps d'un étalonnage.
On veut donc un étalon de temps très précis durant plusieurs secondes, minutes ou heures, mais pas au-delà. Ce fait simplifie un peu le problème.

5.1 DS1307 ou DS3231

Le DS1307 étalonné est la première façon d'avoir du 1Hz à bon prix, mais la valeur précise est totalement illusoire puisque variant avec la température.
Le sujet est un peu différent pour le DS3231 qui manque de précision initiale, du moins pour les modèles reçus, qui sont très certainement des fonds de tiroirs ou de piètre qualité…
Il est possible de mettre un DS1307 dans une enceinte thermostatée et d'avoir une certaine stabilité, mais ce 1Hz peut seulement être utilisé pour un étalon, car l'énergie nécessaire reste le point critique.

5.2 DCF77

Ce DCF77 est un signal radio sur la fréquence de 77.5 KHz comme déjà largement documenté dans mes autres articles.

Ce qui m'intéresse ici est tout à fait différent puisque j'entends obtenir des secondes de référence par ce signal. Or il s'agit d'une modulation de la porteuse en amplitude de maxi -25%, mais c'est la durée des impulsions qui code en BCD les valeurs de temps.
Il y a 1 bit par seconde, et cela pourrait être intéressant pour avoir du 1 Hz précis ? Hélas c'est une vue de l'esprit, car le début d'un bit de donnée n'est pas garanti et entre 2 bits il peut y avoir un certain flottement dû au fait que l'on ne sait pas sur quelle alternance de la porteuse et à quelle position angulaire de la porteuse on va se trouver.

Le DCF77 est précis sur une longue durée, mais pas mieux que des dizaines de millisecondes entre 2 impulsions.
Sur ce sujet, on peut aussi remarquer que le décodeur peut affecter les fronts (qui ne sont certainement pas très précis à la micro seconde près) de façon anarchique car seul le contenu des données est recherché ! (Et non la position précise du bit data) De plus il faudra recréer le front manquant de la 59ème valeur.

- Ce qui est très intéressant c'est la fréquence porteuse très précise puisqu'elle est asservie à une horloge atomique. Aussi pour obtenir du 1 Hz précis, il serait possible de diviser cette fréquence par 77500 pour avoir du 1 Hz.
C'est une bonne solution, mais un peu lourde à gérer car la division est importante et très particulière. Voici la décomposition en facteurs premiers = 2^2  x 5^4  x 31.

A savoir qu'il faudra commencer par fortement amplifier cette porteuse, puis la mettre en forme, et enfin la diviser en logique traditionnelle.
Une petite idée… diviser d'abord par 775 puis par 10 et 10 de nouveau. On aurait ainsi 1/100 et 1/10 Le système est intéressant, puisqu'il permet d'avoir le calendrier par le décodage ainsi que l'heure complète, mais le plus intéressant est qu'il donnerait par sa propre fréquence porteuse un temps très précis, aux rotations de phase ou perturbations près. (Il faudrait alors synchroniser au mieux les secondes des datas codés avec les secondes issues de la HF si on voulait la totalité de l'heure).

J'ai réalisé un petit montage amplificateur qui n'a pas donné entière satisfaction et que j'ai abandonné car il fallait encore amplifier un peu plus, le signal étant trop faible. Vu la difficulté et le contexte incertain, j'ai abandonné d'autant que cela ne permettra que de créer un étalon, pour calibrer un module DS1307. Photo ci-dessous du circuit réalisé mais sans intérêt !

5.3 Essais amplification 77.5 KHz

J'avais regardé cette fréquence assez basse (GO) et j'avais décidé de l'amplifier pour obtenir  par division cette valeur de 1 Hz.
Voici le schéma réalisé avec de vieux transfos MF 455 KHz. Il faut ajouter environ 6.8 nF pour obtenir la résonance vers 77.5 KHz.
J'ai prévu 2 étages d'amplification 77.5 KHz sur circuit résonant et un étage sur résistance pour amener au niveau TTL.
2 LED ajoutées témoignent de chaque demi alternance du signal à 77.5 KHz.

Un 3ème étage aurait été nécessaire car le signal de sortie est trop faible. De plus, comme me l'avait fait remarqué un copain, un comparateur rapide aurait aussi été très utile en

sortie.
Ce montage a mal commencé, car débuté avec un  circuit imprimé de mauvaise qualité, mal soudable c'est un comble !
Ensuite, la  mise au point a été délicate, car je me suis aperçu que l'oscilloscope TEKTRO TDS 220 était un véritable générateur de champ magnétiques à la fréquence de 77/80KHz, et assez instable et trop proche de la fréquence du DCF. (Pas de chance !)

Cette perturbation est due à l'alimentation à découpage du scope et cela fausse toutes les mesures, car le rayonnement est très important et arrive à rayonner sur le cadre ferrite du DCF77.
En plus, en relisant la documentation du DCF77, je me suis aperçu qu'il y avait aussi  une modulation de phase.
Cette modulation de phase dans notre cas n'est pas intéressante car elle perturbe la précision de la HF par ce décalage, mais à notre niveau ce n'est pas trop grave..
Trop de problèmes pour cette solution juste ébauchée… Abandon !
Au niveau alimentation, c'était quelques mA et ça aurait été intéressant.

5.4 Par Internet www.time.is33

Ce site pour lequel je n'ai aucune action répondait bien à ma recherche, puisqu'il peut donner un bip de fréquence 1 KHz pour chaque seconde et un bip aigu pour les secondes 58 et 59 et encore un autre encore plus aiguë pour la seconde 0.
Si cela permet de se synchroniser en utilisant la BF sortie casque du PC, c'est tout de même très aléatoire, car le front d'onde à 1 KHz de la modulation monte progressivement et comme pour le DCF il manque également la précision de l'instant de début de la seconde.
On peut voir ce signal sur l'oscillogramme (\son_time.is_P1000973.JPG *****à insérer)
C'est le seul site que j'ai trouvé qui donne un signal BF simple pouvant permettre une synchronisation automatique sans utilisation de procédures particulières (USB par exemple)

D'autre part le site informe sur la précision du temps affiché qui est de l'ordre de 200ms dûes au principe du réseau Internet. On voit donc que le problème de front avachi n'est qu'une partie de l'imprécision.
Le même site indique aussi si l'horloge de votre PC est à l'heure ou non.
On notera que ce site fonctionne aussi très bien sur smartphone.
Sur le fond, c'est bien, mais insuffisant pour un étalon, et nécessite un PC ou smartphone.
De plus jours et heures sont données sur écran sans liaison externe au PC et cela aurait été peu pratique.

5.5 Par GPS UBLOX NEO-6M

Pour commencer voici le lien vers le datasheet de ce circuit UBLOX NEO-6M, cela permet de comprendre un peu mieux ce qu'il y a sur le module GPS utilisant cette puce.

Avec ce circuit, la Norme NMEA permet de recevoir en RS232 à 9600 bps par défaut, date et heure. (https://fr.wikipedia.org/wiki/NMEA_0183) sans aucun paramétrage.
Les trames $GPRMC sont les plus complètes puisqu'elles contiennent outre des coordonnées, l'heure et la date.
Les trames GGA contiennent l'heure mais pas la date.

Il est évident que l'envoi de trames RS232 n'est pas un gage de précision, quelque soit la vitesse de transmission, car c'est du micro logiciel qui gère l'envoi, et des fluctuations sont donc probables. C'est cependant aussi précis qu'un signal sonore de time.is.

Voir ci-dessus l'un des premiers exemples reçus. En jaune un ensemble de trames qui recommence indéfiniment au temps près.
Si j'ai bien retenu ma leçon, il y a 11 satellites en liaison dont les 3 trames $GPGSV témoignent. Trame 3,1 3,2 3,3.

La solution pour l'étalonnage est basée uniquement sur le signal "TIMEPULSE" à 1Hz  (Pin 3 UBLOX NEO-6M) qui est généré par les circuits de décodage de la modulation de phase des porteuses GPS. La fréquence de ce signal est paramétrable mais est par défaut à 1 Hz. Juste ce que j'attendais !

(Il est cependant indiqué que ce signal est le plus précis lorsqu'il est paramétré au moins au niveau du mégahertz). On peut déduire que cette division à 1 Hz se fait par interruptions, et que le temps peut fluctuer un peu. Sur plusieurs secondes, on peut l'admettre comme "suffisant". Je m'en contenterai car c'est déjà un progrès très important relativement aux autres solutions. (Fréquence très précise et indépendante de la température)

Ce signal "TIMEPULSE" pris sur la pin 3 qui alimente aussi la LED témoin de la synchronisation avec les satellites, est très précis et a un temps de montée de 15µs à 99% de l'amplitude, et à 25ns pour la descente.

Il est certain qu'un industriel ou une entreprise dont le temps est le métier ne peut pas se contenter de ce qu'un amateur peut se permettre, mais c'est ainsi, et nous, amateurs, ne pouvons pas investir des sommes considérables pour "titiller" les 2 ou 3 ns qui manquent !!!

NOTA1 : ces mesures sont faites sur le montage d'étalonnage après les 4 mètres de liaison filaire entre le GPS lui-même et le montage, ce qui est un peu normal mais souligne la nécessité d'utiliser le front descendant pour une meilleure précision.

NOTA2 : Toutes les mesures ont été faites avec en plus un régulateur 3.3V qui alimente le module GPS. (Il y a donc une petite perte de niveau du régulateur interne au module. -voir Avertissement en tête d'article-)

6 L'étalonnage (avec GPS)

6.1 Le montage utilisé

Schéma de principe *****

Je n'ai pas d'autre schéma de principe que ce gribouillis, mais il m'est familier et il est simple à comprendre, contrairement au schéma.
Voici comment ça fonctionne :
On commence par appuyer sur le switch pour débuter une session de comptage d'impulsions. La synchronisation ne peut avoir lieu qu'au front descendant du signal de référence à 1Hz.
Alors la mesure commence car le XOR exclusif 1A 1B initialement à 0 0 voit 1A passer à 1 ce qui libère la gate de comptage du TIMER1 et le T1CKI recevant la fréquence de l'appareil à étalonner peut alors compter sans discontinuer avec report sur 8 octets.

Il faut accepter que la boucle d'attente de synchronisation au départ ne dépasse pas 1 µs car on tourne sur 2 instructions et il n'y a aucune interruption.
Lorsque le comptage des 74HC4518 est atteint, une sortie poids 8 des compteurs passe à 1 ce qui bloque par le XOR la gate T1G du Timer1.
On connaît la fin du comptage par RA1 qui passe à 1. (Boucle de surveillance totalement indépendante du comptage)

Le programme reste ainsi  bloqué et affiche les résultats au display.
Le fait de repasser RA0 à 0 fait le reset du XOR 2A 2B et des compteurs et autorise un nouveau cycle de mesures par appui sur le switch.
On connaît approximativement la sortie de compteur utilisée par le temps mesuré sur RA2, signal à 1 Hz. On connaît donc le temps à +- 1seconde par cet artifice et cela évite de mettre 1 signal de + pour connaître la sortie utilisée.

6.2 Schéma réalisé

Le schéma était basé à l'origine pour un TCXO et l'arrivée du GPS a compliqué un peu les liaisons qui restent compatibles cependant, au prix que quelques "acrobaties" au niveau de la connectique. Il faut comprendre que l'on n'a pas besoin du RX du GPS puisque celui-ci donne tous les éléments dont on a besoin sans aucun paramétrage. Ainsi J7 est présent seulement pour information. De même sur J2, le connecteur principal, le signal 32KHz n'existe pas ou que sur un TCXO DS3231, et il n'est pas utilisé, sans parler de BAT du DS3207 qui n'est pas utilisé.

Il est évident que ce schéma ne peut être qu'une idée, certes qui fonctionne, mais devrait évoluer vers un ensemble plus complet permettant en plus de la calibration du module, la mise à l'heure, ce qui n'est pas le cas à ce jour.

L'utilisation d'une autre référence de temps à la seconde est possible et le câblage de J2 est fait en conséquence et permet de prendre un DS1307 ou un DS3231 en référence. La programmation de ces circuits est assurée systématiquement dans le programme de mise à l'heure qui assure le bon paramétrage pour l'étalonnage.

ATTENTION : le circuit GPS UBLOX NEO 6M est uniquement alimenté en 3V ou 3.3V. Ne surtout pas mettre du 5V !  (Ceci est vrai pour le chip, mais faux pour le MODULE puisqu'un régulateur TPS79133 régule depuis 5V pour alimenter en 3.3V le circuit UBLOX)

A cette fin le schéma de cette adaptation de tension a été réalisé en "volant" sur la plaque d'essais supportant le GPS. Le schéma est indiqué dans l'encadré en violet Il n'est donc plus nécessaire et même contre-indiqué. La sortie 3.3 du signal TX du GPS est suffisante pour le câble d'adaptation FTDI  RS232/USB.
Dans le cas improbable où vous utiliseriez le signal RX du GPS, vous devrez utiliser le réseau mentionné dans ce même encadré (10K/5.6K) en sortie TX de votre PC ou de l'équipement connecté, car tout ce qui rentre en logique directement sur le circuit NEO-6M doit être en 3.3V.

Attention au circuit, il est juste donné pour information, car il n'est pas à jour.

Je rappelle que ce schéma et ce circuit n'assurent que le comptage précis des impulsions fournies à l'entrée de mesure J11. Ce montage n'assure pas l'exploitation des trames NMEA et donc la mise à l'heure.

6.3 Etalonnage

J'avais initialement réalisé le montage ci-dessus pour l'utiliser avec le signal à 77.5 KHz du DCF77 puis avec le TCXO DS3231.
Je l'ai modifié pour le GPS, et il y a beaucoup de fils en l'air, car la connectique tient de la "bidouille", mais ça fonctionne bien, et je peux régler l'oscillateur des DS1307 à 32768 KHz par un condensateur de 4.7pf ou 6.8pf associé à une torsade qui permet d'ajuster à 2 621 440 périodes pour une durée de 80 secondes de temps de mesure. (A température ambiante)

Cet ensemble capacitif est soudé directement sur les fils du quartz (c'est assez délicat !) la position de la torsade joue aussi sur la capacité et une fois réglé, il faudra immobiliser celle-ci par un point de colle à chaud au pistolet.

Le petit logiciel simplifié sur le montage d'étalonnage avec le PIC 16F688 ne permet pas de mettre les circuits à la date du jour mais seulement d'étalonner l'oscillateur pour qu'il soit à la bonne fréquence (à la température ambiante !).
La mise à l'heure se fait cependant avec un autre montage qui utilise le DCF77. voir cet article photo ci-contre http://bricolsec.canalblog.com/archives/2021/01/05/38743002.html.

NOTA : En l’absence de GPS et si vous deviez utiliser un DS1307 ou un DS3231 comme étalon, avant de passer en étalonnage d'un autre DS1307 par exemple ou de vérifier un DS3231, il est nécessaire mettre à l'heure celui qui sert de référence 1 Hz pour valider la sortie 1 Hz.

Il aurait été intéressant, et c'est tout à fait possible, d'assurer la mise à l'heure à partir du GPS et non du montage de mise à l'heure avec DCF77, mais cela n'avait pas été prévu initialement  et le PIC 16F688 est un trop petit pour assurer cet ensemble de travaux.
Ce montage permet en outre de mesurer des nombres d'impulsions pouvant aller au delà de 32KHz
il y a de larges possibilités de comptage de 8, 80, 800, 8 000, 80 000 etc…

Ce schéma était prévu pour utiliser un DS3231 ou un DS1307 étalonné, aussi il y a un connecteur J2 qui comporte les différents signaux de ces modules.
Il y a lieu de comprendre que l'arrivée du GPS a modifié un peu cela et dans cet aspect, seul le signal TIMEPULSE est utile pour le fonctionnement, mais comme le GPS doit être extérieur à un bâtiment (le positionnement sur une fenêtre à l'intérieur semble cependant suffire).

Une liaison de plusieurs mètres est nécessaire jusqu'à ce montage. Aussi le signal TX issu du GPS transite dans cette liaison de 4 fils pour pouvoir être observé sur un PC (ou tout autre dispositif) car il serait difficile de mettre un autre dispositif en extérieur non prévu pour cela.

Le signal RX du GPS n'est pas utilisé et devrait peut-être servir à la programmation qui n'est pas nécessaire ? Je n'ai pas essayé la programmation ayant d'emblée exactement ce qu'il fallait ! Ce signal RX n'étant pas utilisé, j'ai coupé la liaison vers la pin 21 et réaffecté l'ancienne pin RX du connecteur au signal TIMEPULSE, ce qui évite des fils en l'air.

Au besoin si le signal RX devait être utilisé pour le paramétrage, il suffirait de souder une broche sur la pin 21 du NEO-6M, ce qui arrivera certainement bien moins souvent que l'utilisation du signal TIMEPULSE.

Bien entendu la partie GPS devra être rendue étanche si elle doit être mise en extérieur, mais un rebord intérieur de fenêtre en sous sol m'a permis tout de même d'avoir la synchronisation et de voir jusqu'à 11 ou 13 satellites ! Donc pas trop de problèmes !

Les trames NMEA sont donc observables sur le signal TX ainsi rapporté de l'extérieur vers ce système de comptage et permettent la mise à jour de date et heure sous réserve de créer un montage un peu plus conséquent (Sans le jour de la semaine)
(Voir le complément d'expérimentation après le  § 8 pour le calcul du jour de la semaine).

7 Conclusions

Après avoir examiné avantages et inconvénients, je suis revenu au point de départ, sans pouvoir véritablement trancher de façon définitive. C'est bien là le propre de tout regarder et au final de ne pas pouvoir prendre position en faveur d'un procédé ou d'un autre, car cela dépend aussi beaucoup des applications qui utilisent le temps.

Après quelques essais et avoir examiné beaucoup de possibilités, j'ai d'abord acheté 2 modules GPS UBLOX NEO-6M qui ont fonctionné du premier coup sans aucun paramétrage. J'obtiens donc du 1Hz sur le signal de la LED  qui correspond à la sortie TIMEPULSE du circuit UBLOX NEO-6M (Pin 3). Cela m'avait obligé à mettre un fil volant sur ce point qui n'est malheureusement pas accessible sur connecteur.  (Dommage mais je viens de le corriger en "squatant la pin RX" qui n'est pas utilisée pour l'instant !)

Il faut aussi faire la conversion de niveau pour ce signal 1Hz pour repasser en 5V, car ce module est alimenté en 3.3V. Attention à ne pas mettre du 5V sur l'entrée RX du Module, et à bien alimenter en 3.3V ou même 3.0V ce module GPS . Le signal TIMEPULSE en 3.3V répond à priori aux spécifications CMOS et est parfaitement interprété par le PIC sans aucun artifice.

De même, pour la RS232, sur le TX du module GPS, les niveaux sont suffisants pour être interprétés correctement par le câble adaptateur FTDI USB/RS232 et je ne ferai rien de plus.

En ce qui concerne le DCF77, l'amplificateur de la porteuse à 77.5KHz fonctionne "à peu près", mais un "pompage" se produit au niveau de la sortie. Ce pompage est peut être dû aux changements de la profondeur de modulation. De plus le niveau reste trop faible et la réception pas toujours facile en intérieur.
Ce montage semble un peu "capricieux" et difficile à mettre au point à cause de mon scope TDS TEKTRO dont l'alim à découpage rayonne très fort en magnétisme. Quelques inductions électriques (parasites) sont aussi la conséquence de ce rayonnement magnétique.
J'abandonne donc l'amplification du 77.5KHz

Alors ! Le sujet me semble tellement large que je n'ose pas encore me prononcer, mais surtout je vois le travail à faire si j'emprunte une solution ou une autre. Dans cette optique, je m'étais dit que finalement je suis arrivé à une assez bonne solution très empirique de posséder un étalon de temps avec un DS1307 "étalonné" en temps, mais pour une température "ambiante".

Au final et pour mes applications solaires, j'ai donc opté pour un étalon de temps basé sur la réception du signal "TIMEPULSE" du GPS UBLOX NEO-6M. Ce circuit spécialisé semble assez ancien mais il fonctionne bien. On n'en demande pas plus même si il est assez gourmand en énergie !

En parallèle j'ai réalisé une petite enceinte thermostatée avec un module PELETIER, ce qui m'a permis de relever la courbe (du quartz) d'un module DS1307 qui sera ainsi étalonné à 22.5°C et qui pourra servir d'horloge précise sur bien des montages.
Chaque module DS1307 est donc ajusté à l'aide du GPS et du petit montage de comptage décrit au § ci-dessus.

Certes la température devra rester dans des limites "convenables" déjà évoquées pour maintenir la fréquence la plus proche de 32.768 KHz, mais l'accès très rapide par I²C, le coût, la précision, la facilité d'emploi sont des arguments forts.
Il faut aussi ajouter que l'électronique en extérieur est toujours sujette à aléas par la pluie, le chaud, le froid, la condensation…etc,
C'est donc mon choix d'utiliser le GPS comme étalon pour la fenêtre de temps de comptage pour assurer des étalonnages seulement !
Il pourra servir aussi dans des montages similaires un peu plus perfectionnés à développer.

Je me pose la question de savoir s'il serait utile d'établir localement (Dans un lieu d'habitation) un GPS qui diffuserait en RS232 l'heure complète jusqu'aux secondes, pour les différents montages, ainsi la dérive dans le temps n'existerait plus, et l'énergie nécessaire à la reprise resterait très faible. L'enjeu serait  de maintenir un équipement maître en fonctionnement permanent …
(On ne prendrait pas le GPS lui-même en permanent à cause de sa consommation élevée)

Mais dans cette vision de l'utilisation d'une "centrale horaire", on n'a pas besoin d'une grande précision, puisque celui-ci peut très facilement se raccrocher à quelque chose de simple et peu consommateur et diffuser ensuite en permanence à tous ceux qui en ont besoin. Il est évident que cette centrale serait alimentée par le secteur, ce qui n'empêchera pas de réduire au minimum sa consommation. Cette centrale pourrait même être active durant seulement une dizaine de minutes une fois par jour pour que chaque montage puisse se synchroniser !
C'est presque exclusivement en RS232 / radio que cette diffusion du jour et de l'heure pourrait être faite.
Mais en suivant quelle principe ? GPS ? DCF77 ? TIME.IS ? Autres ? Étalon "maison" ?
C'est une idée à creuser !

Il faut aussi signaler que la "reprise du temps à un instant 't'" après un arrêt est un enjeu important des économies d'énergie sur les micro contrôleurs que l'on place parfois en sommeil (SLEEP) quand ils n'ont rien à faire, mais lorsqu'ils sont remis en service, il faut alors les remettre à l'heure, et dans ce cadre, le surcroît de consommation ne doit pas faire perdre tout le bénéfice d'un SLEEP bien au contraire.

Je renouvelle l'objet principal de tous ces travaux qui est d'avoir date et heure avec une précision "correcte", mais surtout de ne pas cumuler les dérives journalières et en ce sens avoir trois possibilités :
- Posséder un étalon de temps suffisamment précis sur 10 /15 années
- Se synchroniser à une fréquence à définir et/ou obtenir date et heure sur demande, pour ne pas cumuler les erreurs des dérives.

Avec tous les essais divers et les changements d'orientation, j'ai bien conscience que cet article n'est pas toujours facile à suivre, car il a été rédigé au fil des essais et la structure est assez désordonnée !!! Toutes mes excuses mais le cœur du sujet est bien présent et montre combien c'est difficile d'avoir le TEMPS !

8 Le mot de la fin

Je pense que la meilleure voie restante à l'amateur est de pouvoir se synchroniser ou recevoir date et heure n'importe quand, en direct ou au pire par les ondes radio de préférence.
 
Le GPS m'a bien intéressé, mais il est décidément très gourmand en énergie pour ce modèle (2 KWH par année) et l'impérieuse nécessité de "voir le ciel". C'est pourtant un choix d'avenir. Il peut aussi être utilisé de façon périodique pour limiter son impact énergétique, en accord avec son plus grand temps de synchronisation qui est de l'ordre de 27 secondes.

Le DCF77 est souvent délicat en réception à l'intérieur et il doit en plus être orienté, mais il a l'énorme avantage d'être très peu gourmand en énergie (109 WH par année). Il ne concerne que la zone circulaire d'environ 2000 Km autour de MAINFLINGEN  (Allemagne). Il peut ainsi faire partie d'une centrale locale fixe bien positionnée, dédiée à la date et l'heure en retransmettant  localement les données de date et heure. Tous les micro contrôleurs d'applications ont alors seulement, besoin d'un petit récepteur radio (avec cadre ferrite), pour se mettre à l'heure.
Les transmissions radio ne sont malheureusement pas toujours très bonnes et c'est un risque. On note cependant que mis à part cette fréquence porteuse très stable, il n'y a aucun signal spécifique de temps très précis ponctuellement et il ne peut donc pas servir d'étalon de temps.

Alors je livre ma dernière IDÉE…

(Je pense abandonner le DCF77 et ses modules toujours chers, mal aisés et destinés tôt ou tard à disparaître).

IDÉE qui devrait permettre de mettre en sommeil un microprocesseur (Arrêt de l'oscillateur) tout en retrouvant très rapidement l'heure "à peu près juste" avec un DS1307 en procédure I²C. Dans cette dernière vision, il faudra bien se remettre à l'heure exacte de façon régulière, par exemple tous les mois et dans ce cas on utiliserait le GPS, ce qui reste acceptable au niveau consommation, pour cette remise à l'heure.
Cette remise à l'heure mensuelle remettrait le micro contrôleur à l'heure précise mais aussi le DS1307 qui pourrait de nouveau légèrement dériver dans des limites acceptables, au fil des 30 jours suivants.

On profite ainsi de la très faible consommation du DS1307 (1.5mA en activité et 200µA standby) et de sa pile 2032 de sauvegarde (300nA), ce qui permet de tout arrêter tout en permettant de recharger l'heure très rapidement pour reprendre un cycle de travail avant un nouveau "SLEEP".
Je crois que cette manière de voir les choses est peut être la plus pragmatique, car la parfaite stabilité des horloges locales au niveau amateur est réellement inaccessible sans moyens importants.

Un récepteur GPS avec antenne vaut moins de 3€ TTC alors que le DCF77, 10 à 15€ TTC. Le choix est vite fait, d'autant que tous les µ ont un port série et que c'est un important avantage de procédure connue.

Un GPS et un DS1307 pourraient cohabiter sur un même montage, mais le GPS ne serait mis sous tension que de façon ponctuelle à cause de sa consommation élevée.
D'une autre façon, le GPS pourrait être simplement "amené" en connexion pour une mise à jour occasionnelle, mais c'est une opération manuelle toujours gênante et que l'on oublie !!!

On notera que dans cette optique de mise à jour, on peut simplement utiliser la RS232 du GPS avec recherche d'une trame $GPRMC, car date et heure sont fournies avec la précision du 1/100 de seconde, car on n'est pas dans ce cas en étalonnage.
Certes, cela fait du matériel redondant pour simplement avoir l'heure précise… Il serait également possible de perdre moins de temps en paramétrant la vitesse de la RS232 par les broches NEO-6M dédiées à la programmation de la vitesse (Voir datasheet NEO-6M)
Tout cela est à voir… (Essai réalisé voir ci-dessous §8 expérimentation)

Voilà, c'est ce que j'ai retenu des éléments décrits, mais il y a peut-être d'autres possibilités comme des clepsydres ou des horloges/cadrans solaires à gnomon !!!

bricolsec
__________________________________________________________________

Expérimentation modules UBLOX NEO-6M (article complémentaire)

Ayant reçu ma commande de 2 modules UBLOX NEO-6M, j'ai essayé et relevé quelques éléments pour comprendre et évaluer si ils pouvaient m'être utiles dans ma quête du temps. J'avais à l'époque consigné un peu ce que j'ai appris dans ce court exposé et je mets cela à la suite de l'article précédent car c'est dans la même esprit du temps, et c'est un peu plus précis techniquement que dans l'article, car je ne connaissais pas vraiment le sujet du GPS.

1 Consommation NEO-6M

Le 3.3 V est généré directement par le MODULE GPS (Vu après)
En l'absence de satellite la consommation du MODULE est d'environ 64 mA sous 5 V

Avec satellite on peut avoir 10 mA de moins toutes les secondes environ. Cela peut peut-être être accentué par l'allumage intermittent de la LED.

2 Les temps de mise en fonction

Il y a les démarrages A FROID toujours longs avec 27 secondes. Lorsque le GPS qui possède sa propre horloge considère que la situation précédente est trop ancienne (4 heures si mes souvenirs sont bons) alors il doit redémarrer à froid.
Sinon il a encore la position des satellites et peut donc en 1 seconde ou maximum 3, redémarrer et se synchroniser parfaitement.
(COLD et WARM START)

3 Trames

Dans notre cas, et synchronisé une première fois, avec ou sans synchronisation ultérieure, il y a une trame toutes les secondes. (Trames différentes suivant la synchronisation) Le temps par bit transmis correspond  environ à 100µs soit pratiquement 9600 bps ou  #1000 car/s.
On notera que ces trames 3.3V sont lues sans problème avec l'outillage FTDI/RS232 associé à Terminal de BRAY++ qui est en 5V
Ces trames ne peuvent cependant pas être utilisées en référence de temps. Elles ne peuvent servir qu'à définir la date et l'heure jusqu'aux secondes avec une précision des secondes à ±1seconde environ. (Non réalisé à ce jour)
Tout timing précis ou référence de temps ne peuvent être obtenus qu'à partir du signal TIMEPULSE.

4 contenu des trames

L'ensemble de ces trames se répète indéfiniment et dans ce cas les trames durent environ 300 à 500ms, et elles sont suivies d'un silence correspondant à 1 seconde complète de période.

Essai réalisé le 10/07/2021 avec Terminal de BRAY++, alim 3.3V  (date en $GPRMC en couleur bleue)

On peut faire quelques constatations comme l'heure en fond vert clair du programme "terminal" de la RS232 de 17:04:51.506 et l'heure de la première trame $GPRMC en lettres rouges : 150454.00. Il y a les 2 heures de décalage habituel avec l'heure d'été. La différence des minutes est due au PC qui n'est pas rigoureusement à l'heure.

Les trames $GPGSV peuvent être au nombre de 3 et ici on voit qu'il y a 9 satellites visibles et donc un maximum de 12 satellites. Ces trames sont numérotées 3,1 3,2 3,3 et sont suivies du nombre total de satellites. La suite représente les "idents" de chaque satellite. Il y a une différence entre un satellite visible (9 pour trame $GPGSV) et un satellite en poursuite (8 en poursuite pour trame GGA). (Il m'a semblé avoir lu que 4 lignes $GPGSV sont possibles ???)

La trame $GPRMC est seule impérative pour les applications de date/heure, car elle seule contient la date et l'heure. L'heure est UTC c'est-à-dire l'heure légale d'été MOINS 2 heures. (On le voit approximativement par l'horodatage trames de terminal BRAY++)

L'heure GPS est exprimée avec la précision du 1/100, mais on ne sait pas quel est l'instant de ce 1/100 !

Cependant, si l'on veut avoir une idée du nombre de satellites actifs (en poursuite), il faut lire une trame $GPGGA qui indique par ce paramètre, si la réception GPS est bonne ou moyenne ou mauvaise.
Pour aller encore plus loin dans la précision, il semble intéressant de regarder le niveau de réception de chaque satellite dans les trames $GPGSV 4ème valeur d'un groupe de 4 associé à un PRN (Jusqu'à 3 trames et 12 satellites maximum). Cela peut être utile pour choisir le meilleur emplacement pour le GPS.

5 La trame $GPRMC

C'est la trame qui contient toutes les informations nécessaires pour mettre à l'heure les horloges, mais la précision à 9600 bps reste dérisoire du fait de la transmission.
Pour la dernière trame de l'exemple en couleur, les informations sont dans l'ordre (Issu du document NMEA):

150455.00 = Heure du Fix 150455.00 UTC
A = Alerte du logiciel de navigation ( A = OK, V = warning (alerte)
4740.35409,N = Latitude 49 deg. 16.45 min North
00649.19028,E = Longitude 123 deg. 11.12 min East
0.622 = vitesse sol, Noeuds
cap (absent)
100721 = Date du fix 10 Juillet 2021
 Déclinaison Magnétique (absente)
*76 = checksum obligatoire
Non représentés CR et LF
Ces données "minimales", sont le plus souvent utilisées dans les programmes de navigation GPS simples.

Aucune trame ne contient le jour de  la semaine, qui est cependant nécessaire pour savoir quand aura lieu le changement été/hiver puisque cela a toujours lieu un dimanche, aussi il y a lieu d'utiliser l'algorithme le plus simple décrit ci-après.

6 retrouver le jour de la semaine

Méthode 2 (source WIKIPÉDIA)

Pour une date de la forme jour/mois/année où « jour » prend une valeur de 01 à 31, « mois » de 01 à 12 et « année » de 1583 à 9999, utiliser la formule :

c = (14 - mois)/12
En fait, c = 1 pour janvier et février, c = 0 pour les autres mois.
a = année - c  (année en 4 chiffres)
m = mois + 12*c - 2
j = ( jour + a + a/4 - a/100 + a/400 + (31*m)/12 ) mod 7
La réponse obtenue pour j correspond alors à un jour de la semaine suivant :
0 = dimanche, 1 = lundi, 2 = mardi,….  6=dimanche.

Remarques :
Dans toutes les divisions, on ne garde que la partie entière du résultat. Par exemple, 35/4= 8.
Enfin, mod 7 signifie « modulo la division par 7 », c'est-à-dire « le résultat est le RESTE de la division par 7 ».
(Par exemple, 23 mod 7 = 2, car le RESTE est 2). (3x7=21---> 23-21=2 cqfd)

Exemple
Sur quel jour de la semaine tombe le 13 mars 2004 ?
On calcule c, a et m :
c = (14 - 3)/12 = 0, a = 2004 - 0 = 2004 et m = 3 + 12*0 - 2 = 1.
On trouve alors :
j = ( 13 + 2004 + 2004/4 - 2004/100 + 2004/400 + (31*1)/12 ) mod 7
j = ( 13 + 2004 + 501 - 20 + 5 + 2 ) mod 7
j = 2505 mod 7 = 6 (car 2505/7 = 357 et il reste 6.)
Donc le 13 mars 2004 était un samedi.

7 Le signal à 1 Hz

Ce signal "TIMEPULSE" est une impulsion positive de 100ms de 3.3 V qui se répète toutes les secondes.
Ce signal n'existe pas en l'absence d'au moins 4 satellites actifs. Ce signal de 3.3V est disponible en pin 3 et alimente également la LED du module.
Ce signal n'apparaît que lorsque la synchronisation avec plusieurs satellites (4 minimum) est réalisée.

8 Un essai qui en dit long

Après avoir racheté plusieurs exemplaires, j'ai d'abord eu la nécessité de charger l'accu de chaque module, car il n'y avait pas grand' chose de tension restante...
Pour cela, j'ai monté sur une plaque d'essai 3 connecteurs 4 broches pour 3 modules alimentés par un petit chargeur standard 5V, et je me suis aperçu que les LED des modules clignotaient en même temps...
Certes en réfléchissant c'est parfaitement normal, alors j'ai poussé les investigations un peu plus loin en regardant les signaux TIMEPULSE au scope, et ils étaient en parfait accord jusqu'à 2 ou 300 ns soit d'un côté ou de l'autre et variant légèrement au fil du temps.

Cela confirme que chaque module "fabrique" son propre temps de référence issu des satellites et enfin que comme l'indique le datasheet UBLOX, il serait préférable de programmer un TIMEPULSE au MHz pour éviter ces petites fluctuations dues vraisemblablement aux interrrupts du circuit.
Globalement c'est tout de même de l'excellente précision du temps et je suis séduit par cette relative facilité d'avoir une référence de temps et d'avoir en plus date et heure !

Alors j'ai essayé de forcer la pin 15 CFG_COM1 du NEO-6M pour essayer de passer à 38400 bps, je l'ai fait et je suis resté à 9600 bps ! Pourquoi ? : Erreur il fallait utiliser la pin 14 ! Et là ça fonctionne comme en témoigne cette recopie d'écran.

Il ne restera plus qu'un seul essai à faire qui est d'essayer l'I²C mais je ne le ferai pas, car c'est trop de bazar, d'autant qu'il n'est pas certain que cela soit à disposition de l'utilisateur, car ce produit est programmable et ce qui est livré est peut-être une version déjà programmée par UBX ?

Simulation 1-WIRE pour DS1307 (ou TINY RTC)

1    Principes généraux
1.1    Pourquoi ce dispositif ?
1.2    Un petit schéma général
1.3    Les interruptions esclave    
1.4    Le montage réalisé
2    Conclusions

Si vous arrivez directement sur cette page par un moteur de recherche, vous pouvez avoir accès à la table des matières et à chaque article, en page d'accueil.    L'accès se fait par l'un des deux liens en tête de colonne de droite ----->

ATTENTION à compter du 15/09/2019 les commentaires ne seront plus possibles à causes de quelques imbéciles qui font du spam pour le plaisir de nuire ! désolé  !

ATTENTION : Si vous êtes très pressé, ne prenez pas la peine de lire cet article qui n'a pas abouti à une réalisation complète, mais si vous avez un peu de curiosité, vous y trouverez de l'intérêt pour quelques idées toujours bonnes à prendre…

                                                                  __________________________________

Préambule

En recherchant dans la documentation MAXIM/DALLAS, j'ai bien trouvé des RTC 1-WIRE, mais qui ne gèrent pas en totalité jours et heures ou qui sont obsolètes (le calendrier !). Par opposition il y a une certaine quantité de circuits RTC en I2C, sous toutes les "coutures"…
Quelques uns se contentent de compter seulement les secondes, mais c'est insuffisant, et je n'appelle pas cela une RTC.
Que faire ? Demander à DALLAS de faire ce qui manque ? Autant aller faire la sieste !
Le plus simple était de s'y atteler soi-même, mais pour quelles raisons précises en passer par 1-WIRE alors que le DS1307 dialogue parfaitement en I2C et rend le service d'une RTC de facture respectable ?

Ceci simplement parce qu'il existe beaucoup de petits modules RTC à base de DS1307 qui sont des produits peu onéreux et qui répondent à ce que l'on en attend si on n'a pas à "chatouiller les ppm".

Dans mon esprit, gérer 2 interfaces différentes pour une simple question d'avoir une RTC correcte me semblait anormal.

Il y a aussi des modules de haute précision DS3231 Ceux-ci sont même moins gourmands en énergie en standby mais n'ont toujours pas de bus 1-WIRE.
Ils m'intéressent aussi, car avec le DS1307, j'ai pu constater qu'il est nécessaire de les calibrer, et la tenue des performances en température n'est pas garantie, pas plus que le fait de passer d'une alim batterie à une alim standard.

Enfin, quelques anciens petits circuits RTC du commerce en I2C sont déjà équipés d'une pile intégrée à un chip et l'heure est ainsi conservée, et c'est certainement ce qui les a rendu très attractifs pour équiper les anciennes RTC des premiers PC…. Mais comment changer la pile ?....---> On changeait le pavé ! pas très écolo !

Il faudrait donc ajouter à un montage d'émulation ce petit circuit RTC DS1307 pour obtenir une RTC émulée en bus 1-WIRE.
Un des gros problèmes pour gérer l'heure RTC est LA MISE A L'HEURE. Ceci est confirmé par le nombre d'utilisateurs sur Arduino qui veulent assurer cette mise à jour d'un circuit RTC… mais comment ?
Certains le font avec le DCF77 comme j'ai fait depuis longtemps, mais ce DCF77 reste assez problématique en termes de réception et je souhaitais m'en détacher le plus possible. Mais ce n'est pas le seul...

(Il y a aussi l'émetteur France-Inter, mais sa modulation de phase est un lourd handicap pour le rendre facilement accessible à tout amateur. Sa propagation en France serait certainement mieux adaptée ?)

J'espérais aussi trouver un programme PC qui envoie la date complète sur un adaptateur USB/RS232, mais pour l'instant je n'ai rien trouvé. (Une fois encore un énorme regret des ports série des vieux PC !)

A ce jour je sais faire la mise à l'heure des modules RTC par mon dispositif spécifique, mais c'est justement cela qui me gène, car j'aurais préféré quelque chose de plus général !
Sans dispositifs spécifiques, un module RTC DS1307 doit être surveillé et corrigé durant de nombreux jours pour ne pas trop dériver, et fonctionner dans un univers de température stable.
Le mieux que j'ai pu faire est 3 secondes en 10 jours, mais en quelques années ça commence à  faire des minutes… et il faudra tôt ou tard remettre à niveau cette horloge DS1307. (Sans parler de température, car ces mesures sont faites à 20°C à peu près stable)

Une mise à jour manuelle est également possible par RS232 émulée sur USB avec le programme Terminal de Bray++ qui est toujours mon favori (Ancienne version).  Seul ennui c'est une mise à jour MANUELLE avec entrée au clavier PC des dates et heures.

1 Principes généraux

1.1 Pourquoi ce dispositif ?

Ce dispositif permettrait d'obtenir l'heure sur un réseau 1_WIRE, car à ma connaissance et à part le DS2404 ou DS2415 qui ne comptent qu'en binaire les secondes mais ne gèrent pas les jours, je ne connais pas d'autres circuits capables de répondre à ce problème en bus 1-WIRE.
On peut considérer que gérer 2 bus différents au niveau maître d'un ensemble de températures, est tout de même gênant et dommage… Mais est-ce vraiment un problème ? Je retourne, cette question en permanence et plus j'en parle plus je suis perplexe sur la nécessité d'une telle réalisation.

J'ai regardé l'ensemble des routines nécessaires à un bus et à l'autre, et je reste un peu perplexe sur la véritable nécessité de réaliser cette conversion. Certes ce serait pratique de ne traîner qu'un seul bus au niveau maître, mais va le voir ce ne sera pas simple tant ce bus 1-WIRE nécessite des timings contraignants et pour un bénéfice de "confort" de programmation au niveau du maître.

1.2 Un petit schéma général

1.3 Les interruptions esclave

Ce qui est décrit dans ce paragraphe m'a conduit à une réflexion sur le fond de ce début de réalisation…
En ayant mis de côté provisoirement cet aspect interruptions de l'esclave que je suis en train  de simuler, je m'aperçois qu'à 8 MHz les temps deviennent très serrés surtout par le travail de mise à jour de l'horloge du PIC de l'esclave. On dépasse allègrement les 50µs si on travaille uniquement en BCD avec seulement la mise à jour des secondes !

Que dire si on maintient le binaire pur ET le BCD dans l'interrupt du Timer0, comme je l'avais déjà réalisé précédemment ?
Alors j'en suis réduit, et je crois que c'est la démarche normale, à éliminer tout ce qui peut être traité autrement qu'en INT. C'est le cas des délais fonctionnels 1-WIRE que j'avais déjà appréhendés et qui sont seulement traités sur la base du flag TMR1IF en boucle courte par btfss et goto $-1.

Que faire de l'horloge PIC ? Doit-on la  maintenir ou faire une lecture du module I2C systématique à chaque demande d'heure 1-WIRE ?
J'avais espéré arriver à une première lecture I2C pour un certain laps de temps d'une journée environ  et éviter ainsi à chaque demande de temps de refaire tout un cycle I2C, et de maintenir l'heure avec l'horloge du PIC.

Cela semble compromis si on reste sur des temps d'INT aussi élevés.
Tout cela est dû au fait que l'esclave doit s'adapter aux temps imposés par le maître (conforme à la spécification 1-WIRE), et il est sage de respecter ce principe, car cela pourrait déboucher sur des cas particuliers toujours à éviter, voire de réelles impossibilités.

Peut-on accélérer les temps de réponse aux INT de l'horloge PIC ? Oui certainement et en plus si on ne traite que cette INT, il est possible d'alléger ce temps.
Le problème du temps est donc crucial uniquement lors de la réception d'une demande du Maître : c'est-à-dire lorsque l'on reçoit le ROM_CODE lors de toute commande comme MATCH_ROM par exemple.
Ce cas se retrouve également pour la réception des commandes de FONCTIONS.

Bien que dans ce cas précis on soit totalement maître du ROM_CODE, j'avais tout de même prévu une deuxième commande ROM qui serait READ_ROM. Il ne semble pas nécessaire d'en avoir d'autres.

A ce stade d'avancement de la doc que je développe en même temps que le programme, je pense que je vais arrêter simplement le TIMER0, d'autant que pour maintenir la précision du temps je réalise un délai de 40µs sur la base de comptage, juste avant d'écrire le TMR0 à -195, ce qui réalise le temps exact.
Ces 40µs d'ajustement pourraient peut-être être compensées avec OSCTUNE, mais il n'est pas certain que ça tombe dans les limites possibles.

En première conclusion : prévision de problèmes de timing, mais je ne veux pas augmenter la vitesse de l'horloge du PIC pour des raisons de consommation. J'ai mesuré le temps nécessaire pour lire le temps en I2C du module DS1307, et stocker ce temps dans le PIC, soit  2.06 ms pour 8 bytes.

Pour toute commande ROM ou Fonction de 8 bytes, il faut 3.06 ms au PIC pour rapatrier le code ROM ou Fonction dans le PIC, en dehors de toute analyse ou traitement. Pour espérer rapatrier l'heure vers le réseau 1-WIRE, il faut donc 2x3.06 ms de lecture des 2 différentes commandes ROM et fonction et quasiment autant pour envoyer les datas d'heure sur le bus 1_WIRE. Cela fait donc pratiquement 10 ms, c'est donc très long ou TROP long!

Ma démarche serait donc de tout faire sans aucune INT sauf pour la mise au point et une future mise à jour de l'horloge I2C.

1.4 Le montage réalisé

J'avais réalisé ce petit circuit à la même taille que le module I2C à base de DS1307 et enfichable sur le module DS1307. (il est d'ailleurs un peu décalé !)

La programmation en ICSP du PIC 16F688 a été simplifiée au maximum, et quelques pins ont reçu les différents signaux nécessaires, car en simple face introduire un connecteur pour cette unique utilisation complique sérieusement les tracés.
Aussi durant la phase de mise au point, j'ai simplement laissé quelques fils raccordés aux bons endroits par quelques pins avec au bout de 15 cm de fils un petit connecteur 5 broches.
(voir photo de tête d'article)

J'avais prévu la mesure de la tension pile par un petit strap sorti sur un petit connecteur 2 broches. Cette mesure aurait pu être faite uniquement lors d'une mise sous tension pour économiser l'énergie.

Un connecteur 3 broches pour I2C (SDA,SCL et GND)
Un deuxième connecteur 3 broches pour 1-WIRE (1-WIRE, GND, Vcc) est quant à lui chargé de l'alimentation de l'ensemble, du réseau 1-WIRE. Les broches ICSP sont libérées de toute contrainte par 2 petits straps qui en réalité n'ont pas véritablement servi, car la programmation a supporté les quelques composants capacitifs notamment.

composants à l'aval.
La photo de tête d'article représente ce montage fiché sur le module DS1307.


2 Conclusions

Enfin …
L'écriture simultanée de cet article avec la progression de l'écriture du programme me dirige tout droit vers l'abandon de ce projet pour traiter au niveau du programme général du Maître du réseau 1-WIRE  un deuxième réseau I2C qui sera chargé de l'horodatage des mesures de température par exemple.
Cette décision d'abandon d'un projet est toujours difficile à prendre, mais elle me semble nécessaire pour ne pas réinventer la poudre.
Cette procédure d'abandon dispose d'une motivation importante qui est la rapidité d'extraction des informations de tout module RTC en I2C, contrairement aux difficultés de temps en 1-WIRE.

C'est toujours triste d'abandonner un projet mais c'est mieux ainsi, et j'en ai tout de même tiré des éléments positifs en termes de réflexion générale sur ces réseaux, et aussi de séquences utiles au programme général maître de supervision du réseau 1-WIRE, tant qu'au niveau calcul de CRC et des différentes mesures de temps.
Une réflexion sur le temps et sa précision est également un élément très important de cette décision.

C'est donc maintenant un projet qui tombe à l'eau, mais tout le travail réalisé n'est pas perdu.

Suite à cela j'ai regardé de nouveau le site de DALLAS/MAXIM, et les quelques circuits RTC sont presque tous en I2C ou SPI.

Au vu des temps importants en 1-WIRE, je pense que DALLAS a préféré concentrer ses efforts sur des modules RTC en I2C beaucoup plus rapides et plus précis.

C'est donc la chronique d'un abandon que je publie dans le but que quelqu'un qui avait envisagé de faire la même chose ne se lance pas dans un projet qui ne mérite pas autant de travail, alors que le fabricant semble avoir délaissé le sujet et qu'une bonne solution rapide existe en I2C moyennant seulement une I/O de plus pour SCL de l'I2C. (L'I/O SDA peut même être partagée avec le bus 1-WIRE).

Pour la précision je pense qu'un module TCXO à base de DS3231 serait (pet-être) plus indiqué, et c'est plus vers cette solution que je devrais m'orienter en condition d'ambiance difficile. Un tel module éviterait de nombreuses mises à jour suite à la dérive probable du DS1307. Je dois avouer que ce module à base de DS3231 m'intéresse fortement car après de nombreuses tentatives de réglage de l'heure sur les modules DS1307, je suis persuadé qu'il est préférable de passer à la qualité supérieure en termes de précision et 2 ppm ne me semblent pas de trop pour maintenir l'heure et le calendrier durant plusieurs mois voire plusieurs années. 

On touche à cet instant à la précision du temps et on comprends rapidement que ce sujet initialement au cœur de l'horlogerie et/ou de la précision des fréquences d'émission est un vaste sujet qui mérite beaucoup d'attention, surtout si l'on réalise des montages qui sont fortement impactés par le temps :
Je pense à mon tracker photovoltaïque et à mon panneau solaire en poursuite du soleil où les temps doivent rester dans des "limites acceptables" durant de nombreux mois, voire plusieurs années.

J'en suis donc quitte d'avoir réalisé un petit CI inutile et écrit quelques lignes d'assembleur, sans avoir abouti, mais les séquences de programme ne sont pas systématiquement perdues, car elles pourront resservir et elles ont été souvent améliorées…
J'ai compris à moindres frais cette précision nécessaire du temps, et je vais regarder ce module DS3231 et ce qui s'ensuit du contrôle du temps, mais avec un œil critique car ces modules que j'ai récemment reçus ne donnent pas la bonne valeur initiale de fréquence, et il peut être parfois plus utile d'ajuster un DS1307 que de regarder bêtement un DS3231 sans pouvoir le rectifier !.

"A la bonne heure"

bricolsec

Essais  DS18B20 et bus ONE_WIRE

1 Description sommaire du DS18B20
2 Hardware
3 Première opération
4 Opérations suivantes
5 La visualisation  des résultats
6 La réalisation
7 Routines programme
8  Les "Topic's"
9 Conclusions

Si vous arrivez directement sur cette page par un moteur de recherche, vous pouvez avoir accès à la table des matières et à chaque article, en page d'accueil.    L'accès se fait par l'un des deux liens en tête de colonne de droite ----->

ATTENTION à compter du 15/09/2019 les commentaires ne seront plus possibles à causes de quelques imbéciles qui font du spam pour le plaisir de nuire ! désolé  !

Préambule

Ce circuit DALLAS En procédure Maître Esclave est toujours esclave, le DS18B20 est un thermomètre numérique et m'intéressait beaucoup principalement par son absence de nécessité d'étalonnage, et la sortie des valeurs déjà numérisées, mais il y a un revers à la médaille, la mise en œuvre du circuit m'a parue un peu compliquée au premier abord surtout par le bus ONE-WIRE.
En deuxième lieu, cela s'est vérifié, et ces essais n'ont pas été de tout repos, certes j'en suis responsable pour une bonne part par mes étourderies et oublis divers, mais il faut tout de même dire que cet ensemble avec son bus ONE_WIRE (ou 1-WIRE) n'est pas dans le domaine du traditionnel.

J'ai donc fait une petite maquette sur la base d'un PIC 16F886, et pour débuter j'ai essayé de travailler à 8 MHz seulement alors que tous les habitués du ONE_WIRE fonctionnaient à 20 MHz. Cette vitesse plus faible n'a pas été un obstacle réel et il m'a seulement fallu, dans quelques rares cas passer simplement en délais par quelques instructions en lieu et place d'une routine dédiée.

C'est en faisant des essais sur ce bus avec un circuit DALLAS, le DS18B20, que j'ai aussi relevé quelques points obscurs ou non précisés, parfois délicats, sur cet ensemble DS et bus.

J'ai "normalement" galéré en assembleur principalement par ma faute, bien que le "READ ROM" ait très rapidement fonctionné. Cette galère est seulement due à des erreurs de programmation ou des incompréhensions de ma part. Les problèmes d'erreurs de programmation sont maintenant réglés !

J'ai fait de nombreux essais assembleur pour essayer les fonctions du circuit, à chaque fois en programmant le PIC 16F886 qui m'a servi aux essais.
Je dois dire que je suis favorablement surpris par ce petit circuit dont un des gros points forts est d'éviter toute calibration de la température et de n'avoir que 3 fils (voire seulement 2), de gérer les longueurs importantes de fils où tous les capteurs sont en parallèle sur ce même bus d'un seul fil, mais aussi de délivrer une température déjà numérisée.
L'autre avantage majeur est la possibilité d'accueillir d'autres modèles de capteurs ONE-WIRE si nécessaire.
Ce principe permet en outre d'ajouter un thermomètre supplémentaire sans aucune modification de structure et sans I/O complémentaire.

1 Description sommaire du DS18B20

Il n'est pas question de recopier le datasheet, mais d'avoir une vue d'ensemble de ce thermomètre associé au bus spécifique ONE_WIRE qui reste le cœur du sujet.

Le type d'élément thermo-sensible analogique n'est mentionné nulle part et je n'ai rien trouvé à ce sujet. Il y a cependant un convertisseur A/D à résolution paramétrable de 9 à 12 bits. On remarquera que 12 bits est un peu surfait car le pas de 0.0625°C  est dans la plupart des cas trop fin d'autant que le temps nécessaire de conversion reste prohibitif à 750 ms pour 12 bits.
Ce circuit intégré utilise pour sa communication un bus à fil unique (ONE_WIRE) qui fait de ce principe quelque chose d'assez singulier.
Pour un bus unique sans horloge spécifique, il ne reste que la "gestion du temps de parole", car ce bus est bien bidirectionnel mais seulement en half-duplex.
Du fait de sa fonctionnalité basée sur le temps, ce bus est particulièrement bien adapté à la gestion d'un bus de longueur "importante". On le constate par des timings à la fois, précis et dans d'autres cas assez larges.
Ce bus doit obligatoirement être utilisé avec des OPEN-COLLECTOR ou OPEN-DRAIN (Résistances rappelées au Vcc)

Ce circuit possède un code unique (CODE  ROM) composé d'un N° de type de produit DALLAS de 8 bits, (28H pour le DS18B20) d'un numéro de série de 48 bits, et d'un CRC de 8 bits, le tout inscrit en ROM qui est l'interface d'entrée. Toute commande doit passer par la ROM pour être  suivie d'une commande spécifique à une mémoire scratchpad qui elle-même peut être associée à une EEPROM.

Je me suis "désolidarisé" de 2 commandes ROM parfaitement "imbitables" et très mal expliquées. Ces deux commandes ROM sont SEARCH_ROM et ALARM_SEARCH qui restent assez inutiles si l'on utilise les codes ROM de chaque circuit. J'oublierai donc volontairement de parler de celles-ci.

Pour les autres commandes appelées "commandes de fonctions", celles-ci permettent : de lire la température d'un device, les températures limites hautes et basses ainsi que le byte de configuration (Read_scratchpad), de faire la conversion en degrés d'un seul device ou  simultanément de la totalité des devices présents sur le bus (Cde "Convert").
D'écrire dans la scratchpad  (Cde "Write_scratchpad").
Il est aussi possible de recopier la scratchpad dans l'EEPROM ("Copy_scratchpad"), et tout autant de faire l'inverse, soit recharger la scratchpad par l'EEPROM ("RECALLE²").
Une nouvelle commande n'ayant pas toujours existé est ("Read_Power_supply") qui permet au maître de connaître le mode d'alimentation du circuit : "Parasit Power" ou alimentation standard.

A ce sujet je n'ai pas encore mentionné que ce circuit devrait pouvoir être auto-alimenté par son signal  "DQ". Malheureusement, est-ce une mauvaise série que j'ai eue, mais je n'ai pas pu le faire fonctionner en "parasit power", car le signal DQ est écroulé en permanence.
A ce sujet je suppose le pire car il existe une version spécifique "DS18B20-PAR", mais il semblerait que maintenant toutes les versions soient capables de le faire. Est-ce vrai ? Je ne sais !

Je me suis donc contenté d'une alimentation standard et il y a déjà pas mal de travail et de possibilités avec ce mode.
Cette particularité parasit power reste importante et utile suivant les cas, car elle affecte directement la possibilité de tester la fin de conversion sans s'appuyer sur le délai prévu pour la résolution demandée.
Il est aussi important de connaître le mode d'alimentation car dans le cas de parasit Power, le Maître doit disposer d'un MOSFET qui assurera "un strong pull-up" nécessité par la surconsommation du convertisseur en fonctionnement.

Dans ce sens, je pense qu'il est préférable d'utiliser le délai prévu car cela autorise d'utiliser aussi bien une alimentation normale que l'auto-alimentation par le signal DQ (Si ça fonctionne).

On remarquera un point très important qui est que la commande CONVERT peut s'appliquer à tous les éléments présents sur le bus, c'est-à-dire que toutes les valeurs analogiques seront converties au même MÊME INSTANT et stockées dans chaque device (en attente d'une lecture éventuelle).

Au début de cette étude, je me suis souvent demandé où se trouvaient les commandes READ_SLOTS et WRITE_SLOTS que je ne trouvais pas en tant que telle. J'ai compris que le nom était générique et n'obéissait qu'à une succession de timings bits spécifiques, (à respecter bien entendu !) Il apparaît que si l'on respecte ces préconisations, tout fonctionne bien.
Il est important pour pouvoir continuer sur µ, d'accepter les interrupts de la RTC par exemple (ou les autres), de voir dans les Timing R/W le paramètre Trec compris entre 1µs et l'infini, (ce tout petit signe 8 couché). C'est cette particularité qui permet d'être interrompu par une INT.

Enfin, pour clore le tout, il faut aussi comprendre qu'une commande particulière (INIT_PRESENCE PULSE), positionne les devices en écoute sur la ligne, en attente en premier lieu d'une commande ROM exclusivement. Cette commande d'INIT est très importante et permet de réinitialiser tous les devices et doit être lancée avant toute COMMANDE ROM, pour pouvoir engager une commande de fonction. Cette commande INIT met tous les devices en écoute pour une future commande ROM.

Les 2 organigrammes du datasheet sont assez clairs, mais quelque fois, l'appui par le texte de quelques commandes possibles par la commande SKIP_ROM ne serait pas inutile. Je pense particulièrement à une commande globale "Write_ScratchPAD" que j'ai essayée précédée de SKIP_ROM et j'ai pu ainsi forcer la totalité des devices en résolution à 11 bits. (SKIP_ROM est seulement mentionnée possible pour "CONVERT").
Je pense aussi que la commande globale "RECALL_E²" devrait être également possible si elle est précédée de SKIP_ROM, mais je n'ai pas eu l'occasion de vérifier. En fait toute commande ne nécessitant pas de réponse des devices devrait pouvoir être traitée avec la sélection SKIP_ROM ? (Les organigrammes ne l'interdisent pas !)

2 Hardware

J'ai donc réalisé un petit circuit avec le PIC 16F886 pour mettre en œuvre le bus et le circuit DS18B20. Il a été pensé pour une future régulation solaire, mais beaucoup de périphériques n'ont pas été installés (Pyranomètre, encodeur, connecteur...)

Comme indiqué, il faut des OPEN-DRAIN (ou OPEN COLLECTOR) et dans mon schéma initial, j'avais utilisé 2  I/O.

L'une en sortie bufferisée avec un 74LVC07 (OPEN-DRAIN), pour imposer un zéro éventuel et l'autre en lecture permanente sur la pin de sortie (DQ également la sortie du 74ALS07).
Cette première I/O était alors commandée à 1 ou 0 par le µ contrôleur suivant ce que l'on souhaitait. Le 1 étant nécessairement le niveau de repos permettant de lire (des zéros) qui provenaient du device sur la 2 ème I/O. (Seul un 0 pouvait surpasser ce 1 logique)

Au final cela obligeait à 2 I/O et j'ai fait alors ce que tout le monde faisait avec simplement les TRIS, et qui fonctionne aussi.
MAIS pour moi ce n'était pas tout à fait identique, au niveau des courants disponibles à 0 logique et surtout dans l'optique du "PARISIT POWER"… (totem-pole ou Vce Sat ???) .

Pourquoi ce mic-mac des OPEN-DRAIN ? "Simplement parce qu'il est possible de forcer à 0 une ligne à 1, et les PIC récents n'ont plus de "RB4" ou similaire en OPEN COLLECTEUR ou OPEN-DRAIN, et il faut se contenter des TRIS qui ne sont pas de véritables OPEN, ainsi que dit précédemment.

J'ai donc modifié mon schéma et mon montage en utilisant maintenant une seule I/O mais en jouant avec les TRIS, c'est tout aussi simple, surtout moins gourmand en I/O et c'est également opérationnel !!! (corrections apportées au schéma en rouge, le 74LVC07 est devenu parfaitement inutile)

3 Première opération

J'avais commandé une dizaine de DS18B20, et bien entendu ces devices arrivent sans leurs CODE ROM ce qui est normal, (puisqu'il existe une commande pour lire ce code unique), mais encore faut-il avoir la possibilité de lire ce code !!!.

Le problème est qu'en début d'essai on n'a rien et pas de programme réalisé et il faut bâtir les routines en même temps que l'on fait l'opération de lecture d'un premier code.
Cette lecture du code ROM nécessite d'écrire sur le bus puis de lire. Ce sont donc 2 opérations majeures qui doivent parfaitement fonctionner pour réaliser cette opération avec succès.
(Ces 2 opérations de base seront largement utilisées par la suite pour toutes les autres commandes).

Cette lecture du code ROM sera nécessairement réalisée avec un seul device sur le bus et par la commande READ_ROM.

Outre cela, le contrôle du CRC doit également fonctionner pour être certain de la véracité de ce que l'on lit.
La base des échanges est ainsi traitée par ces 2 routines de base Read et Write qui ne sont pas des commandes DS18B20 au sens propre mais seulement un procédé basé sur le temps qui prend le nom de read time slots et write time slots.

Il faut dire que le CRC et  le code famille 28H sont des aides qui permettent de certifier que le code ROM que l'on lit est correct.

Une fois ceci réalisé, j'ai commencé par marquer au stylo de peinture blanche le dessus des boîtiers avec un numéro en séquence de 0 à 9.
Puis j'ai ensuite relevé sur le display LCD les valeurs reçues et créer avec Word de minuscules étiquettes dont j'ai entouré les boîtiers pour ne pas tout recommencer.
La séquence de lecture ROM a été laissée en place dans le programme mais ne sera plus utilisée sauf en cas de nouveaux devices à identifier.
Je rappelle que pour lire ce code avec SKIP_ROM, il ne peut y avoir qu'un seul device sur le bus, faute de quoi tout le monde parlerait en même temps et le code lu serait faux ainsi que le CRC.

Le fait de faire ces minuscules étiquettes sous Word permet en complément, de sortir en .TXT toutes ces valeurs ou par CTRL+C/+V pour charger la partie EEPROM du programme assembleur PIC avec ces adresses de devices et d'ajouter ainsi facilement les pseudo-codes spécifiques "de" et les commentaires dont le N° de sonde croissant.
Cette façon de faire me semble simple, même si on peut, peut-être encore automatiser un peu plus pour éviter l'unique transcription manuelle. (Cela en vaut-il la peine pour 10 devices ?)

D'un point de vue organisation d'un programme de surveillance de températures multiples, il me parait nécessaire de préserver la mémoire Data d'un PIC, car celle-ci est assez limitée et de placer ainsi ces codes ROM en EEPROM du PIC.
Pour mes 10 devices, les 10 valeurs de 8 octets tiennent facilement dans n'importe quelle EEPROM de PIC qui a au moins 128 octets d' EEPROM, et la limite théorique serait donc de 16 devices ONE WIRE.
(La lecture EEPROM d'un PIC bien qu'un peu plus lente que l'accès RAM reste suffisante et ne ralenti pas réellement le programme.)

Dans l'inconnu des valeurs d'étalonnage de température, j'avais réalisé une première affectation de N° sans précaution particulière avec un N° de sonde de 0 à 9 correspondant à un code ROM.
Par la suite, après avoir été jusqu'à la lecture de toutes les températures, j'ai préféré réaffecter ces N°de Sonde à des températures les plus proches les unes des autres et en ordre croissant.
Les écarts sont bien dans la spécification, mais pour des applications plus pointues, cela permettrait d'affecter des corrections plus facilement et une gestion plus homogène des devices.
La table des codes ROM du DS18B20 en EEPROM du PIC est donc organisée  en numéro croissant de Sonde et de température proches quelque soit le code ROM, qui sera simplement lu à chaque appel d'un device.
(Cette organisation pourrait permettre de compenser éventuellement et plus facilement par un petit offset, l'écart intrinsèque de chaque device).

Inutile de dire que seule la commande READ_ROM a fonctionné rapidement mais que pour le reste cela n'a pas été sans quelques erreurs de programmation et erreurs dues à une mauvaise compréhension.
Inutile aussi de rappeler qu'initialement j'ai fait au plus simple et qu'un seul device était connecté. Par la suite j'ai relevé le code ROM pour chaque device. J'avais également supprimé les interrupts pour ne pas être gêné.

4 Opérations suivantes

Dans la suite des opérations, j'ai fait des essais pour deux devices et utilisé la commande MATCH_ROM au lieu de SKIP_ROM.
J'ai ensuite mis les 10 devices en //.
Bien entendu l'affichage des résultats se fait sur LCD (4 lignes c'est + facile avec autant de capteurs)

J'ai profité de l'instant pour vérifier l'incidence de la longueur du bus… Certes le signal devient moins "beau", mais avec 20 mètres de fil, ça fonctionne toujours !

J'ai donc pu lire la température sans modifier la résolution d'origine à 12 bits. Cette lecture d'abord en hexadécimal a ensuite été améliorée par conversion ASCII. Le format du registre de température est particulièrement pratique avec la position fixe en bit 4 du 2 puissance 0.

(On peut voir en ligne 1 de la photo, la lecture du code ROM avec le CRC lu et calculé à la fin 2C/2C.
En ligne 2 la lecture scratchpad avec une température EA90 (PF/pf) soit -343°, ce qui est naturellement faux. Le registre de configuration est de 55H alors qu'il ne pourrait être que 1FH, 3FH, 5FH ou 7FH. Le CRC est bien entendu faux 7F/F7).
ATTENTION, la scratchpad est de 9 octets !!!

On écrit maintenant les TL et TH et surtout une résolution plus faible à 11 bits, car 12 bits en température est réellement trop sensible et cette valeur de 6.25/100 de degrés est trop pointue dans la quasi totalité des cas d'emplois.

Suite à cette écriture de la SCRATCHPAD, il faut maintenant vérifier par la lecture que tout s'est bien passé.
Enfin, après avoir mis la résolution  à 11 bits, il est maintenant possible de réduire le temps de conversion à 375 ms, ce qui sera fait avec succès, car 12 bits et 780 ms c'est vraiment trop.

J'ai également essayé avec succès la conversion de la totalité des 10 devices lors d'une unique commande CONVERT.

Il me restera à réintroduire les interrupts que j'avais invalidés pour "y voir plus clair" dans le débroussaillage des problèmes.
Il est certain que les INT doivent être bloquées à certains instants, et qu'à 8 MHz de fréquence horloge du PIC, il faut aller très vite pour répondre dans les temps sans perturber le bus ONE_WIRE qui demande seulement quelques timings précis.

On notera que la totalité des développeurs travaillent à 20 MHz par sécurité, mais sans trop de gymnastique, on peut fonctionner sans problèmes à 8 MHz. Je pense même que ce serait possible à 4MHz.
Cette obsession de réduction de vitesse est seulement motivée par l'aspect économies d'énergie et un fonctionnement possible sur pile ou accu.

5 La visualisation  des résultats

J'ai utilisé un afficheur 4 lignes de 20 caractères qui me permet d'afficher 8 résultats sur un seul écran, mais en limitant à 3 décimales, tout en affichant le signe et le numéro de sonde.

(Attention, cet afficheur utilise un registre à décalage avec un seul bit data et des tops d'horloge avec une commande réelle du display en 8 bits. Ce principe a fait l'objet d'un de mes articles il y a quelques années. J'ai seulement standardisé une liaison connectique 2x5 en une liaison 1x6 + détrompeur. Cela évitera les habituelles erreurs de connexions voir photo ci-dessous)

Au début, et avant de modifier la résolution, j'avais limité à 3 chiffres après la virgule en 12 bits pour pouvoir afficher toutes les sondes.
(Même limité on peut reconstituer ce 4 ème chiffre qui ne peut être que 5 ou Zéro si il existe. De fait pour certaines valeurs numériques correspondantes à un pas de 0.0625, il  est possible de reconstituer ainsi le chiffre 5 manquant en 4ème position).

Mais un 4ème chiffre significatif est-il vraiment nécessaire lorsqu'il ne peut être que 0 ou 5 soit 5/1000 de degré !?
Un souffle ou un simple courant d'air est suffisant pour modifier une température, alors 11 bits me semblent suffisants.

J'ai réalisé en premier lieu l'affichage en Hexa comme représenté sur une photo précédente, puis pour mieux cerner les éventuelles erreurs, il a fallu afficher en clair, et pour vérifier certains points comme la résolution, il a été préférable d'avoir aussi l'hexadécimal que j'avais remis provisoirement en ligne 1 du display….!

Suite à, différents essais, j'ai constaté que l'incidence thermique se réalise fortement par le biais des 3 broches de sortie du boîtier TO92. Y penser !

6 La réalisation

J'avais préparé les I/O en fonction d'une éventuelle application pour la régulation solaire thermique.
Ainsi qu'indiqué, j'ai d'abord commencé avec 2 I/O, puis je suis repassé à une seule I/O avec l'utilisation du TRIS.

Pour les 10x DS18B20 utilisés, j'ai réalisé avec des supports "tulipe" une série de 10 éléments de 3 pins pour enficher les devices tous en // sur une plaque de CI d'essai. Rien de bien difficile.

Les essais avec un bus assez long (non mesuré mais environ 20 mètres) sont concluants et sans erreur, en particulier pas d'erreur de CRC et mesures parfaitement vraisemblables.

Ce bus d'essais est constitué de 6 petits fils torsadés de 4/10 dont seulement 3 sont utilisés, les autres étant "en l'air", ce qui est de plus assez défavorable au niveau bruit.

Dans les différents essais, j'ai ajouté de plus les inter-actions RS232 à 2400 bps, puisque tous les résultats sont envoyés en même temps en TX et au display avec seulement un return au 10ème device pour des lignes RS232 de longueur "acceptable".

7 Routines programme

Ces routines de base décrites ci-dessous permettent de réaliser toutes les opérations sur le DS18B20 à l'exception de SEARCH_ROM et ALARM_SEARCH que je ne traiterai pas.
Les routines de délais sont scindées en 2 groupes pour petits délais et grands délais.

La routine READ_ROM est indiquée comme modèle de commande ROM, mais les autres commandes ROM sont identiques au code près et rejoignent la partie commune de READ_ROM. (étiquette "Common_CDE")

Des goto sont situés juste après les initialisations du PIC et permettent l'une ou l'autre des séquences (C'est un essai sans but immédiat)

La routine de lecture EEPROM du PIC a été intégrée directement dans la boucle de lecture des 8 octets de ROM (repère ; ¤¤¤ dans le programme) dans le but de gagner un peu de temps mais aussi et surtout pour toujours limiter cette profondeur d'entrée dans le stack, car je ne compte pas réellement, mais je me limite volontairement.

(On rappelle également que si je n'ai pas traité les 2 commandes  SEARCH_ROM et ALARM_SEARCH, la conséquence est que les valeurs TH et TL n'auront plus aucune utilité, et qu'il faudra traiter le sujet au niveau PIC ou autre processeur).

Dans cet aspect de TH et TL inutiles, ces deux valeurs pourraient par exemple être réaffectées à un offset permettant d'augmenter la précision d'origine à ±0.5°C de façon plus précise ?

Les routines de délais sont traitées avec le TIMER1 mais sans les interruptions en scrutant seulement TMR1IF.

Ci-dessous les macros utilisées. On remarquera que le forçage à 0 de DQ est fait une seule fois pour toutes en début de programme. Le passage à 1 se faisant simplement par la commutation du TRIS 4 en entrée et celle-ci étant rappelée au Vcc par la résistance de pull-up qui "fabrique ainsi le 1 logique".

Pour des questions de timing et de passage avec PCLATH du PIC, il y a 2 routines différentes de calcul du CRC car pour la ROM, il y a 8 bytes à traiter et pour la Scratchpad c'est 9 bytes.

; Les macros utilisées

 BK1_0       macro    ; ATTENTION nécessité de partir de BANK1 1 to 0
            bcf        STATUS,RP0    ; BANK0 par 1 bit
            endm

BK0_1       macro    ; nécessité de partir de BANK0
            bsf        STATUS,RP0    ; BANK1 par 1 bit
            endm

#define    ONE_WIRE        PORTC,Bit4    ; adresse PORT pour écriture

;__________________________________________________________________________________________________

; ATTENTION DQ LOW doit mettre préalablement PORTC BiT4 à 0 définitivement
;
DQ_LOW       macro
        BK0_1                    ;  BANK1 = TRIS à 0=OUT (PORTC à 0 dès le début programme)
            bcf        ONE_WIRE
        BK1_0
            endm

DQ_LOW1.5us     macro        ; Pour test fin de conversion en alim permanente (Non utilisé)
        BK0_1
            bcf        ONE_WIRE
        BK1_0
            endm

DQ_HIGH        macro
        BK0_1
            bsf        ONE_WIRE    ; forçage DQ à 1 pour lecture de l'esclave par le TRIS
        BK1_0
            endm

DQ_Tst            macro
        BK0_1
            bsf        TRISC,Bit4    ; mise en read
        BK1_0
            btfss    ONE_WIRE        ; Portc,bit4
            endm


___________________________________________________________________________


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Read_ROM_33 lecture ROM code 0x33 permet d'adresser tous les devices mais un seul
; doit être utilisé car il y aurait collision.
;
Read_ROM_33
            movlw    0x33            ; Cde read_rom
Common_CDE
            movwf    One_DATA
        call    WRITE_DATA8            ; écriture sur l'esclave de 8 bits
        RETURN

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; séquence de petit délai avec valeur en TMR1L mais avec +1.6 µs systématique à 8 MHz
; TMR1L est utilisé pour homogénéité des délais mais TMR1 n'est pas utilisé (Init trop lente)
; A 8 MHz pas possible de paramétrer en fonction vitesse horloge
; TMR1L=0 INTERDIT utiliser Wait_2us
; ATTENTION : Appel avec valeur divisée par 2 en W à cause vitesse de 8MHz et nb instructions
;
Waitus_8                    
            movwf    TMR1L        ; save valeur NON NULLE

Waitus_82    
            nop
            decfsz    TMR1L,f
            goto    Waitus_82

        RETURN                ; Retour pour tous les autres

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; délay paramétrable sur 16 bits avec valeurs en µs jusqu'à 65535 (ou 65 ms)
; Le timer 1 est utilisé sans INT et avec prescal fixe de 2 pour compter en µs
; utilise TMR1L et TMR1H comme paramètre qui devront être chargés préalablement
; Ces valeurs seront complémentées vraies (à 2) avant d'être utilisées par le TIMER1
; permet des délais jusqu'à 65.535ms par pas de 1 µs avec #11 µs de plus
;
DLY_PAR
        movwf    TMR1H        ; save High
        comf    TMR1L,F        ; Complémente
        comf    TMR1H,F    
;                ; N + 1 -> N
        incf    TMR1L,F            ; N0 + 1 -> N0  [Complément à 1 de N]
        btfsc    STATUS,Z        ; Skip si pas de retenue
        incf    TMR1H,F            ; Report de la retenue

        bsf        T1CON,T1CKPS0    ; set 1 impuls ttes les µs
        goto    Com_Par

 ; suite Com_TMR1
;
; partie commune routines de délais avec return et resets (sans prescaler pour long délais setup prescal)
;
Com_TMR1    
            movwf    TMR1H            ; point commun pour les TMR1H écrit 1 seule fois ici
Com_Par
            bsf        T1CON,T1SYNC        ; ne pas synchroniser
            bsf        T1CON,TMR1ON        ; run timer1 - partie commune -
            btfss    PIR1,TMR1IF        ; Interrupt flag
            goto    $-1                ; loop until flag=1

           clrf    T1CON            ; Stop/INIT sans RAZ counter for next updt sans reset counter
            bcf        PIR1,TMR1IF        ; reset interrupt flag

        RETURN        ; (End all DLY2 et Com_TMR1 partie commune aux délais)
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; INITIALISATION Reset présence
;
INIT_PRESENCE

        DQ_Tst                            ; test ligne DQ à 1 btfss
            goto    INIT_PRESENCE    ; =0 : il y a un forçage qui n'est pas le PIC. On attend

        call    Wait_2us            ; delai 2 µs
        DQ_LOW                        ; forçage à 0 DQ
            movlw    low(500)        
            movwf    TMR1L
            movlw    high(500)        ; delai 700 µs TMR1H fait en DLY_PAR
        call    DLY_PAR                ; délai paramétré
        DQ_HIGH                        ; remise à 1 DQ
            movlw    70/2
        call    Waitus_8            ; delai 71.6µs    
        DQ_Tst                            ; test ligne DQ à 1 btfss
            goto    Finish_INIT        ; OK Ligne DQ = 0 = présence pulse OK

            goto    INIT_PRESENCE    ; not ready pas de réponse à 0
Finish_INIT
            movlw    low(500)        ; délai de 500 µs
            movwf    TMR1L
            movlw    high(500)        ; TMR1H fait en DLY_PAR
        call    DLY_PAR                ; délai paramétré
        
        RETURN         ; (Return INIT_PRESENCE)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; WRITE 8 bits en WRITE TIME SLOT
; DATA à envoyer dans le byte ONE_DATA
; CNT1 utilisé pour comptage des bits, Waitus_8 utilisé pour les délais TMR1L durée de délai
; macros DQ_Low et DQ High pour le forçage ligne DQ
; :!
WRITE_DATA8
            movlw    0x08
            movwf    Cnt1            ; comptage des bits
LOOP_shft
            btfss    ONE_DATA,Bit0    ; test du bit 0
            goto    WR0                ; Write Zéro

; write 1
            bcf        INTCON,GIE        ; arrêt des INT
        DQ_LOW
        nop
        nop

        DQ_High                        ; set 1
            movlw    60/2            ; 60 µs
        call    Waitus_8            ; délai 60 µs
            bsf        INTCON,GIE        ; autorisation INT
            goto    Shift_8

; Write 0
WR0
            bcf        INTCON,GIE        ; Arrêt INT
        DQ_Low
            movlw    60/2
        call    Waitus_8            ; délai 60 µs
        DQ_High
            bsf    INTCON,GIE            ; restore INT possible

; décalage pour bit suivant
Shift_8
            rrf    ONE_DATA,f            ; déclage
            clrz
            decf    Cnt1,f
            btfsc    STATUS,Z
        RETURN

            goto    LOOP_Shft
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; READTIMESLOTS lecture de données de 8 bits Il est possible d'enchaîner cette séquence
; plusieur fois suivant les types de commandes précédentes
; fait suite à Read ROM, Read_scratchpad (0xBE) ou read Power Supply (0xB4)
; ou Convert T (0x44) ou recall E2 (0xB8)
; préparer FSR pour enregistrer également en INDF
; FSR est incrémenté et la dernière valeur 8 ou 9 bits est en ONE_DATA
; Le temps entre lecture va de 1µs à l'infini
;

READTIMESLOTS
            movlw    8                ; 8 bits
            movwf    Cnt1            ; comptage 8 bits pour 1 octet
            clrf    ONE_DATA
RdTSL
            bcf        INTCON,GIE        ; inhibit INT

        DQ_Low1.5us                    ; 1.5µs à zéro    (bcf    PORTC,Bit4)
        DQ_High                        ; repasse à 1    (bsf    PORTC,Bit4)            

            movlw    10/2                ; pour atteindre 12µs avant de tester (2x5=10++)
            nop
;            nop
        call    Waitus_8            ; 13.5 µs
        DQ_Tst                            ; Test si ligne DQ à 1 (btfss PORTC,Bit2)
            goto    rot                ; Zéro par le CLRF entete

            bsf        ONE_DATA,Bit0    ; DQ=1 set Bit0
rot
            rrf        ONE_DATA,f        ; décalage 1 bit
            bsf        INTCON,GIE        ; Valid INT
;
            movlw    50/2                ; délai 50 µs (35x2)
        call    Waitus_8

            decfsz    Cnt1,f            ; ,f non mentionné ?? à voir
            goto    RdTSL            ; loop until 8 / 9 shift

            rrf        ONE_DATA,W        ; rot valid data en dehors du carry
            movwf    INDF            ; mise en W résultat
            incf    FSR,f

        RETURN
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; read_1_timeslots unique (fin de conversion) attente d'un 1
;
Wait_1_TIMESLOTS
            movlw    50/2                ; délai 50 µs (35x2)
        call    Waitus_8
            bcf        INTCON,GIE        ; inhibit INT
        DQ_Low1.5us                    ; 1.5µs à zéro (bcf        PORTC,Bit4)
        DQ_High                        ; repasse à 1
            movlw    10/2                ; pour atteindre 12µs avant de tester (2x5=10++)
            nop
            nop
        call    Waitus_8            ; 13.5 µs
            bsf        INTCON,GIE
        DQ_Tst                            ; Test si ligne DQ à 1 (btfss ligne DQ)
            goto    Wait_1_TIMESLOTS    ; attente fin de conversion                     
        RETURN

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Calcul CRC_8 avec table pour 7 octets ou 8 octets
; Exemple : 00 00 00 01 B8 1C 02    54 cycles sans sauvegarde des CRC entre 2 opérations
; FSR doit pointer la zone à calculer le CRC poids faibles en premier (02 en premier et en adresse faible)
; résultat en CRC et 62 cycles dans cet exemple de CRC sur 7 octets
;
CAL_CRC8
            clrf    CRC                ; clear CRC
            bcf        ERR_CRC            ; Init fllag erreur CRC
            movlw    high(TBL_CRC8)    ; init pointeur
            movwf    PCLATH
            movfw    INDF            ; pf PIC et premier octet pf à calculer

        call    TBL_CRC_Add    
            INCF    FSR,f
            xorwf    INDF,W
        call    TBL_CRC_Add    
            INCF    FSR,f
            xorwf    INDF,W
        call    TBL_CRC_Add    
            INCF    FSR,f

            xorwf    INDF,W
        call    TBL_CRC_Add    
            INCF    FSR,f

            xorwf    INDF,W
        call    TBL_CRC_Add    
            INCF    FSR,f

            xorwf    INDF,W
        call    TBL_CRC_Add    
            INCF    FSR,f

            xorwf    INDF,W
        call    TBL_CRC_Add    
            INCF    FSR,f

            xorwf    INDF,W
        call    TBL_CRC_Add    
            INCF    fsr,f        ; pointe maintenant sur le CRC déjà lu
            movwf    CRC            ; save CRC (Exemple : Résultat 0xA2)
        RETURN
;

CAL_CRC7
            clrf    CRC                ; RAZ CRC
            bcf        ERR_CRC            ; init Flag erreur
            movlw    high(TBL_CRC8)
            movwf    PCLATH
            movfw    INDF            ; pf PIC et premier octet pf à calculer
        call    TBL_CRC_Add    
            INCF    FSR,f
            xorwf    INDF,W
        call    TBL_CRC_Add    
            INCF    FSR,f
            xorwf    INDF,W
        call    TBL_CRC_Add    
            INCF    FSR,f

            xorwf    INDF,W
        call    TBL_CRC_Add    
            INCF    FSR,f

            xorwf    INDF,W
        call    TBL_CRC_Add    
            INCF    FSR,f

            xorwf    INDF,W
        call    TBL_CRC_Add    
            INCF    FSR,f

            xorwf    INDF,W
        call    TBL_CRC_Add    
            INCF    fsr,f        ; pointe maintenant sur le CRC déjà lu
            movwf    CRC            ; save CRC (Exemple : Résultat 0xA2)

        RETURN
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Séquence lecture EEPROM pour obtention de 8 octets ROM DS18B20
; la séquence de base a été incluse dans le code sans call
; 185 cycles ou 92.5 µs
; en W N° de sonde de 0 à 9 (ou plus jusqu'à 32 maxi)

Read_EE_Num                            ; Read ROM=F(N°sonde)
            movfw    N_sonde            ; N°
            movwf    MAN3
            clrc                    ; clear carry
            rlf        MAN3,f
            rlf        MAN3,f
            rlf        MAN3,f
            clrf    MAN1            ; index octets
LoopEE
            movlw    low(eeADR_debut)        ; 1ère adresse >EEPROM et BANK2 table
            addwf    MAN1,W            ; index
            addwf    MAN3,W        ; Nsonde x8

; ¤¤¤       call    EE_READ                ; séquence de base de lecture EEPROM PIC
; séquence incluse et obligatoire (pour limiter les call)
;
        BK0_2
            movwf    EEADR        ; registre adresse EEPROM en BANK2
            bsf        STATUS,RP0        ; BANK3 en 1 seul instruc.
            bsf        EECON1,RD        ; ordre read en BANK3
            bcf        STATUS,RP0        ; Repasse BANK2 depuis BANK3
            movfw    EEDAT        ; donnée lue en W
        BK2_0
; ¤¤¤¤
            movwf    MAN2            ; save valeur lue en EEPROM PIC

            movlw    ROM_DAT            ; transfert en bank1 ROM_DAT indexé
            addwf    MAN1,W
            movwf    FSR
            movfw    MAN2
            movwf    INDF            ; store en ROM_DAT
            incf    MAN1,f
            movfw    MAN1
            sublw    8                ; 8 - MAN1
            skpz
            goto    LoopEE

        RETURN        ; (End of Read_EE_1)

;
; Ci-dessous les tables pour le calcul CRC et l'exemple de ma table des ROM_CODE que vous ne pourrez bien entendu pas utiliser, car vous aurez d'autres valeurs bien naturellement



        ORG    0X0EFF

TBL_CRC_Add    
        addwf    PCL,f
TBL_CRC8
        dt    0, 94, 188, 226, 97, 63, 221, 131, 194, 156, 126, 32, 163, 253, 31, 65
        dt    157, 195, 33, 127, 252, 162, 64, 30, 95, 1, 227, 189, 62, 96, 130, 220
        dt    35, 125, 159, 193, 66, 28, 254, 160, 225, 191, 93, 3, 128, 222, 60, 98
        dt    190, 224, 2, 92, 223, 129, 99, 61, 124, 34, 192, 158, 29, 67, 161, 255
        dt    70, 24, 250, 164, 39, 121, 155, 197, 132, 218, 56, 102, 229, 187, 89, 7
        dt    219, 133, 103, 57, 186, 228, 6, 88, 25, 71, 165, 251, 120, 38, 196, 154
        dt    101, 59, 217, 135, 4, 90, 184, 230, 167, 249, 27, 69, 198, 152, 122, 36
        dt    248, 166, 68, 26, 153, 199, 37, 123, 58, 100, 134, 216, 91, 5, 231, 185
        dt    140, 210, 48, 110, 237, 179, 81, 15, 78, 16, 242, 172, 47, 113, 147, 205
        dt    17, 79, 173, 243, 112, 46, 204, 146, 211, 141, 111, 49, 178, 236, 14, 80
        dt    175, 241, 19, 77, 206, 144, 114, 44, 109, 51, 209, 143, 12, 82, 176, 238
        dt    50, 108, 142, 208, 83, 13, 239, 177, 240, 174, 76, 18, 145, 207, 45, 115
        dt    202, 148, 118, 40, 171, 245, 23, 73, 8, 86, 180, 234, 105, 55, 213, 139
        dt    87, 9, 235, 181, 54, 104, 138, 212, 149, 203, 41, 119, 244, 170, 72, 22
        dt    233, 183, 85, 11, 136, 214, 52, 106, 43, 117, 151, 201, 74, 20, 246, 168
        dt    116, 42, 200, 150, 21, 75, 169, 247, 182, 232, 10, 84, 215, 137, 107, 53


;
;********************************************************
; EEPROM
;********************************************************
; preloading EEPROM locations
;
    ORG    0x2100        ; Adresse début EEPROM
; ROM code des 10 x DS18B20 soit 80 valeurs

eeADR_debut
            de        0x28,0xE7,0x78,0x76,0xE0,0x01,0x3C,0x5E    ; DS18B20     0    
            de        0x28,0xE0,0xC4,0x76,0xE0,0x01,0x3C,0xB5    ; DS18B20     1    
; etc

8  Les "Topic's"

¤ Tous les DS18B20 (Sans –PAR) sont-ils capables de réaliser du "parasit power" ? Cela n'est pas certain, car de plus j'ai essayé en mettant bien le VDD à la masse comme indiqué, mais le niveau de sortie est quasiment 0.

Autre point adjacent : En "parasit power", d'où vient l'alimentation Vcc, lorsque l'on utilise les TRIS pour régler le problème d'une absence d'open drain ou de collecteur ouvert ?
(Nota le niveau 0 en OUT est permanent sur le port utilisé et disparaît par la simple commutation du TRIS correspondant et le rappel pull up)
Je répondrai simplement que cette alimentation est seulement issue de la résistance de PULL UP de 4.7K quelque soit le cas avec un véritable OD ou avec TRIS!

En fait 4.7K et 5V cela donne #1mA maxi à voir avec la consommation de 5 µA de chaque device (Sans Conversion ou copy de ScratchPad). Cela permettrait d'alimenter en théorie de nombreux devices à une tension "acceptable" de 3V soit 2 V maxi à chuter et 425 µA soit 85 devices en théorie et pour le seul courant DQ.

¤ De plus la puissance nécessaire à la CONVERSION en alimentation continue avec le principe Tri_State risque d'être totalement insuffisante puisque l'on sera déjà avec un seul device à 1.5mA  Que penser alors ? Faut-il dans ce cas réaliser tout de même un strong pull_up avec un MOSFET ? Mais dans ce cas le mode d'alimentation lu au test "parasit power" serait faux et tester la fin de conversion ne servirait plus à rien !
Je comprends mal en ce sens la préconisation de résistance de pull-up de 4.7K qui ne permet même pas les 1.5mA sous 3V mini pour la conversion. Est-ce que je fais une erreur de raisonnement ?

¤ Dans les imprécisions, on peut être raisonnablement déçus de la manière dont est présenté la fonction SEARCH_ROM.
Le datasheet  est quasiment muet sur les raisons profondes de cette torture intellectuelle, et la note 937 est confuse et je cite "le master lit un zéro. …le complément"….???
J'ai retenu la seule explication claire : "Each stage of selection consists of two read time slots and one write time slot".
Dans ce write time slots, cité ci-dessus, si l'on ne connaît pas le numéro de série d'un (des) device, comment le repérer dans un environnement à multiple devices ? Pas très clair !
Cela s'applique également à la recherche d'une alarme qui traite suivant le même principe.

¤ Associer la documentation du DS18B20 avec le iButton est toujours pénible car on ne sait jamais avec certitude si cela peut s'appliquer au produit DS18B20.

¤ Il faut également bien comprendre que mettre en œuvre ce bus et ce produit qui par ailleurs reste très intéressant, reste délicat et que vu la difficulté, il n'a d'intérêt que dans l'aspect de nombreux devices ou produits répondant au même protocole ONE_WIRE sur un même réseau très simple à 2 ou 3 fils ou tout est en //.

¤ Il est un élément qui m'échappe complètement, qui est celui-ci : A priori (et sans préjuger de mes lacunes ou incompréhensions) tout acteur qui construit un réseau de mesures connaît les points qui seront mesurés et aura donc fait le relevé des numéros de série (code ROM), et leur aura affecté un numéro entier de sonde, beaucoup plus simple… et surtout permettra une localisation physique, ce qui parait impossible avec la commande search.

Ainsi si un device devient muet pour cause de panne ou qu'il est absent, comment le savoir de façon simple, puisque en lançant une commande MATCH_ROM, celle-ci ne se réalisera pas, et je ne vois pas comment on serait informé de cette action avortée.
Dans la même ligne d'idées, le remplacement d'un device défectueux revient au mieux à placer le code du nouvel élément comme les autres en mémoire PROM d'un µ contrôleur, ce qui éviterait de modifier le programme de traitement.
(Le PIC 16F886 permettrait cependant de rentrer par un organe d'input quelconque le code ROM et de l'écrire en EEPROM par programme. Ce serait une façon qui éviterait de passer en codage de PIC, ceci dans le cadre d'un développement industriel).

La réalité de ce qui vient d'être dit trouve son explication assez simplement en réfléchissant un peu mais surtout en l'ayant vérifié !!! :
Supposons un device absent (Absent signifie sans alimentation ou sans DQ connecté). On envoie la commande MATCH_ROM correspondante à ce device non branché. "Personne" ne s'est reconnu sur le réseau, mais à cet instant, Le maître ne le sait pas, on envoie ensuite par exemple une commande de fonction lecture de scratchpad que l'on pense valide… Mais à chaque read time slots, "personne" ne modifie le niveau de sortie qui reste désespérément à 1 logique puisque aucun (autre) device ne s'est reconnu !
Alors tout device absent ou n'ayant pas reconnu son ROM_CODE est ainsi perçu avec tout à FFh !
Que dire du CRC d'accompagnement ? Il est également faux !

¤ En commande CONVERT et mode d'alimentation standard par Vcc, il est possible de lire un slot à 1 ou 0 indiquant la fin de la conversion. En Mode "parasit power", il est nécessaire d'appliquer les temps de conversion correspondants aux résolutions sélectionnées, car un strong pull up doit être actif durant tout le temps de la conversion.

Ce n'est pas très homogène ! Certes cette partie est bien expliquée, car durant le strong pull up le DQ est bloqué au Vcc, mais la commande READ POWER SUPPLY (B4H) n'existait pas, et le test de la power supply a été ajouté par la suite pour permettre de tester la fin de conversion en mode power permanent au lieu d'appliquer un délai. (Un petit gain de temps vraisemblablement ?)
En ce sens j'avais utilisé des routines de délais "très larges" pour le temps de conversion (800ms pour 750ms), mais j'ai pu vérifier que les temps maxi indiqués sont respectés.

¤ Le mode d'alarme par franchissement TH ou TL (ALARM SEARCH_ECh) est une commande calamiteuse qui est aussi délicate que la commande SEARCH. Un read slot sur  cette commande ROM ou un bit de la scratchpad auraient étés certainement bien plus adaptés ! Je rappelle que l'on devrait connaître ses devices par leur numéro unique et que cette nouvelle complexité est bien trop lourde à gérer.

¤  Les commandes SEARCH_ROM et ALARM SEARCH outre qu'elles sont complexes, sont de véritables mangeuses de temps pour des résultats au final peu utiles, car les mêmes informations peuvent être obtenues bien plus facilement sur un µ contrôleur

¤ Dans les évolutions, j'ai aussi noté l'évolution au cours de la vie du produit, de la plage de températures de -55°C à 100°C vers -55°C à  125°C avec quelques restrictions de précision.

¤ Enfin dans la commande Read Time Slots il est dit dans le Datasheet que le maître doit générer la Read Time Slots "IMMEDIATELY" après la "READ SCRATCHPAD"… Que cela signifie-t-il précisément ? Pour ma part je reste perplexe face à cette imprécision ! Sur un réseau basé sur le temps, il serait normal que l'on fixe cette valeur ou un maximum, ce serait plus professionnel. Je n'ai pas eu le courage de faire des essais de temps sur ce sujet. Logiquement serait peut-être  simplement pour le premier bit/slot puisque pour les suivants il y a le signe infini ?

9 Conclusions

    Bien que j'aie eu parfois quelques doutes et récriminations sur ce produit, il reste vraiment très intéressant par son principe novateur, mais manque d'une formalisation certaine et d'une documentation suffisante, allant au-delà du simple exposé, plus précis, et expliquant les raisons  des choix, ainsi que les cas particuliers ou aux limites. On peut comprendre la difficulté technique d'un tel ensemble produit, mais il faut impérativement expliquer les raisons.

Cet ensemble DS18B20 et bus ONE_WIRE en 3 fils fonctionne bien, mais je n'ai pas pu mettre en œuvre la partie "parasit power".
Ce produit et son bus sont pourtant très intéressants pour de petits systèmes et pour les particuliers.
Intéressants surtout par la température déjà étalonnée à ±0.5°C près. Cela est un élément très important pour le particulier, car l'étalonnage est toujours une difficulté de premier ordre.
On peut regretter seulement ±0.5°C de précision, et ±0.1°C aurait été vraiment mieux relativement à la précision du pas du convertisseur 12 bits : 0.0625°C. Le drift reste non négligeable à ±0.2°C. On suppose aussi une bonne linéarité intrinsèque de la numérisation (Sans aucune information spécifique malheureusement...)
On a vu aussi que les évolutions techniques du constructeur ont été un peu décousues et incertaines, car celles-ci interdisaient parfois les devices multiples sur un bus… Or c'est justement cela qui était intéressant !

La résolution de 12 bits est une confortable résolution, on peut regretter un temps de conversion de 750 ms dans ce cas ainsi qu'une valeur du 12ème bit de 0.0625°C

Le format des températures est très pratique à exploiter avec peu d'opérations mathématiques

Le boîtier TO92 est bien adapté à une sonde, et c'est un bon choix, même si un plus petit format TO92S aurait été plus adapté. Les hésitations et modifications du produit DS18B20 et du bus ONE_WIRE sont un peu aléatoires et donnent un sentiment d'incertitude .

On est conscients qu'un tel bus et produit DS18B20 sont à la limite de ce qui est faisable avec un tel principe de bus. On vise ainsi les produits d'automatisme avec des capteurs 2 ou 3 fils, mais les automates standard devraient être un peu gênés par les timings imposés.
Ce produit DS18B20 et le bus ONE_WIRE travaillent au niveau de la "couche physique" et sont fortement impactés par les timings, mais c'est nécessaire. Ceci étant il m'apparaît que ce bus reste malgré ses  imperfections intrinsèques plus accessible encore que le bus UNI/O qui semble au premier abord encore plus complexe, mais peut être plus rationnel et avec plus de possibilités ???

Je n'ai pas trouvé beaucoup de développements complets en assembleur PIC, mais surtout des développements en C, et j'ai lu qu'il y avait quelques problèmes de drivers spécifiques suivant les machines. Des programmes qui fonctionnaient "avant" puis ne fonctionnaient plus "après" des modifications d'O/S ou de drivers sont souvent mentionnés.
Ceci me conforte dans mes idées que ce bus de très bas niveau est un peu délicat à maîtriser en langage évolué.

Je vois dans ce produit, associé à quelque micro contrôleur des outils de surveillance de la température des produits alimentaires, (chaîne du froid) qui pourraient être recyclés, ce qui ne semble pas le cas à ce jour car ceux-ci sont d'utilisation unique et sont jetés au recyclage  !

Je remarque également que cet ensemble DS et bus est déjà un data logger réalisé à 50% et qui peut permettre des vérifications thermiques en de nombreux points simultanément.

Le gros avantage du DS18B20 est sa précision de 12 bits, mais il mériterait peut-être d'avoir une meilleure précision de base que  ±0.5°C.
Son coût reste plus élevé par rapport à une banale thermistance, mais sa principale force est aussi dans le réseau ONE_WIRE qui réduit à souhait tous les câblages et divers convertisseurs A/D. Sa force est conjuguée également dans l'aspect de la mesure déjà  numérisée .

Je vois aussi dans ce bus et ce device DS18B20 une façon ingénieuse de mettre en // de nombreux devices associés à de nombreux switchs, ce qui évite à chaque fois une I/O, à la condition que l'on ne soit "pas trop pressé".
Dans une telle utilisation on pourrait réduire la résolution à 9 bits ce qui gagnerait un temps précieux.
Pour faire  ces switchs multiples sur une seule I/O, il suffit d'alimenter ou non le device par le switch, ou de placer le switch en série sur le bus DQ. J'ai remarqué cette excellente application dans la littérature Internet. (Ce switch à l'état Ouvert retournera tout FFH à la read_scratchpad. Fermé il retournera des valeurs à la read_scratchpad)

Pour terminer cette conclusion, je citerai la commande CONVERT qui peut par le biais de SKIP_ROM s'adresser à tous les devices à la fois, et qui permet des mesures de température synchronisées. Elle a le grand mérite de se faire à la µ seconde près pour tous les devices, ce qui permet de COMPARER des valeurs à un MÊME INSTANT.

Il n'est pas exclu que je l'utilise pour une nouvelle régulation de mon chauffe eau solaire thermique, car il est bien adapté à cette fonction avec 7 mesures importantes et utiles (Haut panneau, bas panneau, Température "tank" (emplacement sonde d'origine), température haut échangeur, bas échangeur, arrivée EF, départ EC).
J'avais fait la maquette dans cette idée, et pour information, les dernières évolution du tableau d'affectation des I/O du PIC, avec 2/IO récupérées par le biais du réseau ONE_WIRE (pressostat et opto coupleur pompe qui ne nécessitent pas une rapidité importante).

bricolsec

N.B. Pour ceux qui souhaitent des compléments d'informations, n'utilisez pas le "contacter l'auteur", car je ne réponds pas, utilisez seulement les commentaires de la page d'accueil de mon autre blog "lokistagnepas" (lien en colonne de droite).

 

Programmateur Tiny DS1307  pour PIC (ou Autre µ)

CHAPITRE  1

1      Diagramme général du procédé
2      Particularités
2.1     Principes
2.2     Open Collector ou Drain (OC / OD)
2.3     Les accus
2.4     Convertisseur de tension
2.5     ICSP
2.6     Le DCF77
2.7     U4224B et DCF77
2.8     Le programme PIC16F690 avec OD
2.8B  Le programme PIC16F690 avec "TRIS"
3      Le Tiny Module DS1307
3B   Le Tiny Module DS3231
4      Schéma de l'outillage ancien modèle
4b    Schéma avec les "TRIS"
5     Montage avec DS1307 Seul
6     Conclusions

CHAPITRE  2

1      Conventions I2C
2      Conventions DCF77
3      Les routines I2C
4      Lecture date heures DS1307

Si vous arrivez directement sur cette page par un moteur de recherche, vous pouvez avoir accès à la table des matières et à chaque article, en page d'accueil.    L'accès se fait par l'un des deux liens en tête de colonne de droite ----->

ATTENTION à compter du 15/09/2019 les commentaires ne seront plus possibles à causes de quelques imbéciles qui font du spam pour le plaisir de nuire ! désolé  !

Avant Propos

En terminant la mise au point du tracker photovoltaïque, j'avais évoqué la possibilité de mettre le processeur PIC en mode SLEEP durant la journée, entre 2 commandes moteurs distantes de 4 minutes….

(SLEEP = état inactif, faible consommation d'un processeur)

Et ce n'est pas la première fois que l'on n'a aucune raison de rester "éveillé", mais le grand problème est que si on passe en SLEEP, l'horloge du PIC avec Timer 0 est arrêtée, et on perd donc l'horloge !

 La seule solution est d'avoir une horloge temps réel externe et particulièrement économe en énergie. Cependant cette horloge doit aussi être permanente, rapide d'accès, secourue et durer de nombreuses années tout en gardant tous les éléments de calendrier et d'heures sans avoir à les calculer ou les recharger durant un temps très long.

 Cette possibilité existe avec des petits modules à base de DS1307 (Tiny module RTC), et qui pourraient seconder très efficacement un PIC "en mal de sommeil". On trouve ces modules chez les Chinois et ceux que j'ai commandés sont de bonne facture… Dommage que l'on ne soit pas en mesure de les acheter chez nous (Le seul magasin de composants de mon secteur a fermé ses portes, quel dommage !)

 Ces modules sont en protocole I2C, protocole que je connaissais seulement de nom. Mais ce protocole n'est pas trop facile à priori, tant en hard que soft, et de plus il faut pouvoir prendre (Physiquement) un tel module horloge ayant déjà eu sa programmation du temps en dates et heures et l'implanter dans le montage cible.

 Des circuits déjà programmés peuvent parfois exister dans le commerce, moyennant un surcoût bien évidemment, mais sur une fausse manip, tout serait à recommencer et obligation d'en racheter un autre !

Non, je crois qu'il faut réellement maîtriser cette programmation initiale et du côté d'une application, il faut les routines pour LIRE en I2C ces données, particulièrement sur des petits PIC ne possédant PAS les modules spécifiques SSP ou mieux MSSP. Un outillage permet aussi de ne pas multiplier les routines spécifiques pour acquérir les données de date et heures avec la précision du DCF ou toute autre référence de radiodiffusion du temps, sur des montages particuliers à base de micro contrôleurs.

Cette programmation a pour but de rentrer les données de date et heure dans le Tiny module qui sera ensuite exploité, sur tout autre montage spécifique qui l'utilisera comme horloge RTC (Si c'est sa vocation ?) Cette utilisation permet alors l'arrêt en SLEEP d'un processeur avec de bonnes économies d'énergie en pouvant relire très rapidement l'heure sur le module.

 Enfin cette façon de voir les choses est également le fruit d'une expérience toujours délicate concernant la réception du DCF77 suivant les conditions de propagation, qui sont assez variables et particulièrement en intérieur. (On peut ajouter que le DCF77 à 77.5KHz n'est pas présent partout dans le monde car il y a d'autres étalons mondiaux de temps, (Tous ne sont pas accessibles : WWVB 60 kHz, JG2AS 40 kHz…et certains arrêtent de fonctionner comme HBG en Suisse, car trop coûteux !)).
Quoi de plus simple que de garder en permanence l'heure et la date sans avoir à tout refaire les calculs de dates, jour de semaine et heures, durant une bonne dizaine d'années sans rien faire d'autre que d'utiliser une petite pile CR2032 et la lecture de 8 octets...(Encore que...à vérifier !... On verra qu'il y a d'autres problèmes...)

Je pense que c'est réellement très utile, avec la petite restriction que dans le cas d'un PIC sans les modules I2C (SSP et MSSP ), il faut 2 I/O standard en OPEN COLLECTOR (OC), pour l'I2C mais parfois en plus une I/O supplémentaire (Pour lire les ACK ou NACK sur la ligne SDA), mais avec la possibilité de connecter d'autres périphériques I2C !)

 Il y a donc deux volets à cet article :

- La partie création d'un outillage de programmation des modules I2C DS1307 sur la base d'une mise en œuvre initiale du temps par le DCF77 (On pourrait cette fois choisir un endroit de bonne réception avec un outillage mobile et autonome). On évoquera aussi pour l'occasion, la réparation d'un  récepteur DCF77 avec un  circuit existant évitant le rebut du récepteur en panne.

 - Le deuxième volet consiste en la mise à disposition des séquences de lecture du temps sur le Tiny RTC DS1307 sous forme de routines à inclure, mais avec une conversion BCD binaire de toutes les valeurs, car le DS1307 stocke des valeurs BCD.

 Dans ces conditions rien n'empêchera alors de placer un PIC en SLEEP, lors de son réveil par une INT ou par le biais de l'ULPWUE et de le remettre à l'heure en quelques centaines de µs. Les valeurs internes de l'horloge du PIC, et les valeurs BCD seront mises à jour, sans attendre de longues minutes la synchronisation du DCF77 (Quand il veut bien fonctionner en intérieur des habitations !).

 Il y a donc lieu de commencer par la création d'un OUTILLAGE de programmation à base d'un PIC 16F690 et d'un récepteur DCF77, pour un premier Tiny module DS1307 et d'obtenir sans erreur et avec précision les valeurs de date et heures. Ces valeurs pourraient alors être maintenues par quartz sur l'outillage, sans avoir à reprendre le DCF77, (Au moins durant une journée).

A l'extrême limite, (Mais ce serait un peu moins précis) il devrait être aussi possible de rentrer dates et heures manuellement à l'aide de l'encodeur en quadrature et de se passer ainsi du DCF77. cette possibilité a été implémentée !
(Cette possibilité se serait révélée très utile lors de la mise au point du "tracker photovoltaïque" pour simuler toutes les dates clefs de l'année et vérifier le bon fonctionnement)

 Cet outillage servira donc à programmer en I2C sans les facilités des modules MSSP, ce qui permettra avec peu de travail de mettre en œuvre les routines de lecture des modules utilisés dans des applications avec de petits PIC.

En écriture I2C, le module SSP ne servant pratiquement à rien (Aux dires de quelques commentaires glanés sur le Net), je m'en suis passé ce qui m'a évité de potasser les registres pas toujours trop explicites pour le profane de l'I2C dont je fais partie.

 Cet outillage peu utilisé (Pour nous particuliers bricoleurs) sera simplement alimenté par un accu Lithium 18650 avec un petit convertisseur 3.7V vers 5V et devrait cependant confirmer visuellement sur écran LCD, les bonnes valeurs reçues du DCF77, avant de lancer des programmations de modules DS1307.

 Cet article traite donc en chapitre I cet outillage chargé de récupérer l'heure par le DCF77, de l'afficher et de programmer en I2C les Tiny modules DS1307.

Il décrira en chapitre 2 les routines programme de lecture du module I2C DS1307 en assembleur sans l'utilisation des facilités des modules PIC MSSP.

Plusieurs programmes assembleur pour des PIC 16F628 existent sur le NET et je m'en suis largement inspiré pour ne pas refaire le monde et j'y ajouterai les routines de conversion. C'est sur un site non retrouvé depuis, que j'ai eu le plus d'éléments assembleur issus de l'auteur Pierre COL. Un Merci particulier à lui ! Malheureusement dans le désordre Internet je n'ai pas pu retrouver le site d'origine des routines publiées ! (Son nom et des adresses inactives figure en tête des routines)

J'ai aussi lu avec intérêt l'introduction au bus I2C de Camille DIOU. Merci également à lui et à d'autres sites comme http://projet.eu.org/pedago/sin/term/8-bus_I2C.pdf qui démystifient le sujet.

 Cet outillage assure la programmation des modules enfichés sur l'outillage, la vérification par lecture de ces mêmes modules. Il devra y avoir aussi des possibilités de rentrer des valeurs ou des commandes, ainsi que d'afficher différents éléments. Pour cela un encodeur en quadrature permettra de prendre le contrôle de l'outillage et de lancer les différentes commandes.

Tant que l'on y est, on réservera une sortie RS232 peut-être simplement pour la mise au point et si besoin en était de récupérer l'I/O ...?

Le tout sera agrémenté peut-être d'une simple LED pour attirer l'attention en cas de problème. Cela conduira à établir le diagramme général du paragraphe suivant…

Enfin tout ceci implique que le Tiny module soit enfichable… sur le codeur mais aussi sur le montage destinataire !

NOTA : Lorsqu'il sera fait référence à un Open Collector cela vaudra tout autant pour un OPEN DRAIN dans le cas des CMOS.

 1         Diagramme général du procédé

2         Particularités

2.1                 Principes

 Je rappelle que le but de cet outillage est de programmer date et heure sur un Tiny module équipé d'un circuit intégré DS1307 avec sa petite pile CR2032.

Voir le datasheet de ce circuit : https://datasheetspdf.com/pdf-file/925278/Maxim/DS1307/1 pour les différentes adresses internes du circuit. (Une seule adresse (Zéro) suffira cependant pour recevoir en séquence les 8 octets nécessaires).

Le module sera ensuite retiré de l'outillage codeur et rejoindra un appareil cible quel qu'il soit et permettra à ce nouveau circuit cible de disposer des dates et heures en un temps très court de quelques centaines de µ secondes sans avoir à les rentrer ou attendre la synchronisation (Aléatoire*) DCF77 de quelques minutes. La seule obligation est de lire en protocole  I2C, 8 octets sur le module "Tiny RTC" pour obtenir date et heure en format BCD.

On considèrera que le Tiny module équipé aussi d'un quartz horloger est suffisamment stable et précis pour tenir les valeurs de temps sur de longues périodes...(On verra par la suite, qu'il y a beaucoup de divergences...)

 C'est un PIC 16F690 qui va être le chef d'orchestre de cet outillage. Le module à programmer, sera obligatoirement amovible par un  petit connecteur au pas de 2.54 qui équipe aussi l'outillage lui-même et le montage cible. (L'outillage sera toujours maître et le Tiny l'esclave tant sur l'outillage que sur la cible).

 Il aurait peut-être été possible d'utiliser le module SSP du PIC 16F690 pour traiter, mais devant le manque d'habitude et de clarté des opérations j'ai préféré déclarer forfait. Les I/O ont malgré tout été prévues en ce sens et pourraient devenir les bonnes I/O en SSP.

Je n'ai pas utilisé ce module SSP du PIC car cela me paraissait trop "indigeste", et cela permettait aussi de préparer les sous programmes pour les petits PIC sans SSP ou MSSP, et un excellent exercice au novice que je suis pour appréhender le sujet I2C au niveau le plus bas.
(Je vais cependant reprendre un peu ce sujet maintenant que l'outillage est terminé, car le fait d'être en SSP crée de fait des Open Drain et cela facilite largement le Hardware)

 L'outillage équipé (ou non) d'un premier module à programmer devra être mis à l'heure une fois par jour à partir du DCF77 ! Plusieurs modules pourraient ainsi être programmés en séquence, et à priori sur une seule opération journalière DCF77. La continuité de précision du temps étant alors assurée par le quartz du PIC et la gestion précise des Interrupts horloge PIC. (La précision de programmation ne pourra être assurée que par une synchronisation toutes les secondes avec le léger retard de quelques dizaines de µs dû à la réponse aux interrupts)

 La RS232 servira seulement à la mise au point de l'outillage et éventuellement pour diffuser date et heure sous ce protocole Asynchrone.

 L'afficheur sera le contrôle visuel des bons éléments programmés mais servira aussi au dialogue pour assurer les différentes fonctions liées au codage/programmation.

 Bien entendu, les différentes opérations se dérouleront de façon séquentielle, et seule les INT du Timer0 seront toujours acceptées en plus des différentes autres correspondant à une opération spécifique. En d'autres termes tous les périphériques ne fonctionneront qu'un seul à la fois.

* J'ai remarqué que le DCF77 est assez sensible aux conditions météorologiques, et à cette fréquence, la propagation des ondes radio est presque toujours en ligne directe sans rebond sur les couches atmosphériques.

 2.2                 Open Collector ou Drain (OC / OD)

 L'I2C utilise des open collector qui peuvent devenir rapidement des entrées et des sorties à la fois, avec la particularité de pouvoir être potentiellement forcés à la masse, mais ne pouvant jamais être "tirés" vers le +.

C'est ce forçage à 0 sur une sortie que l'on devra pouvoir lire rapidement sur la ligne SDA ! c'est le ACK ou NACK suivant le cas...

On remarquera que l'horloge SCL n'est en principe jamais forcée à zéro, et qu'une sortie standard en mode maître (Sous réserve de créer à la suite un simple open collector -sans possibilités de lecture-) est tout à fait possible, (c'est ce qui est réalisé pour l'outillage).

 En effet si on recrée un open collector en externe à un  PIC, au niveau de la commande en OUT, il faut pouvoir recevoir en même temps les ACK, et cela n'est possible qu'avec une entrée en // sur l'open collector, d'où ces 3 I/O nécessaires.

On verra par la suite que j'ai abandonné ce principe des Open Drain et refait le hardware et le programme en conséquence, voir §4B

Certains PIC 16873 16F877 16F628 et 16F84 (et tous ceux que je ne connais pas…), ont UNE sortie OC et peuvent donc avec un simple buffer OC pour SCL, traiter le problème de lecture écriture sur la ligne SDA, par un simple retournement du TRIS correspondant. L'OC manquant pour SCL devra être traité par un buffer non inverseur OC. (Dans cette situation 2 I/O suffisent mais avec un buffer OC non inverseur en plus pour SCL). En réalité il n'y a même pas besoin d'un OC pour SCL, car on procédera comme pour SDA avec les "TRIS"

 Il reste à vérifier que dans le cas d'un PIC avec au moins le module SSP, le simple fait de passer en I2C permet de valider les deux I/O I2C en open collector et de permettre ainsi de se passer d'une I/O supplémentaire ainsi que de l'utilisation d'un circuit complémentaire non inverseur en OC. Ceci est indiqué dans le data sheet du 16F690....

J'ai développé l'ensemble du premier logiciel avec 2 MOSFET_P en OC dont l'un est doublé en sortie d'une entrée pour SDA pour les raisons qui suivent :

 Si toutes fois on pouvait se passer de ces 2 MOSFET_P ce serait très bien car il subsiste vers le niveau zéro, 0.7 à 0.8 V de déchet, ce qui me gêne dans le principe, mais cela n'affecte pas le fonctionnement heureusement. Je crois que je vais faire cet essai en faisant très attention de ne pas me prendre les pieds dans le tapis et en créant une version séparée…. A suivre !...

 C'est fait ! Après quelques essais, il semble qu'il faille également composer avec les obligations afférentes à L'I2C, car je n'ai pas pu en "pseudo statique" vérifier que l'on était en open collector en utilisant le SSP.

Avant de commencer les essais je me suis posé la question de savoir comment reconnaître réellement si une sortie est bien positionnée en open collector ? Cela ne me semblait pas trop évident à moins que…

 Les résistances Open sont dans notre cas situées sur le Tiny module, aussi si l'on considère une sortie Open Collector sans rappel au Vcc, le fait de lui adjoindre une résistance "pull down" à la masse et de commander la sortie à 1 logique ne devrait rien donner en tension de sortie. On ne travaille donc que sur l'outillage sans Tiny

 Le principe des MOSFET_P en tête des pull up (côté Vcc), pour éviter de doubler un étage afin de retrouver la bonne polarité n'est pas parfait, mais j'ai commandé des 74LVC07A qui peuvent permettre avec des petits PIC de fonctionner sans SSP, car pour éviter cette tension de déchet, je n'ai pas d'autre solution que d'utiliser de véritables buffers MOSFET non inverseurs Drain ouvert. Ce circuit ultra faible consommation convient parfaitement à cette opération.

Dans cette idée d'utiliser une partie du SSP uniquement pour la mise des I/O en collecteur ouvert, après quelques essais succins, j'ai donc constaté que les sorties ne fonctionnent pas correctement si on essaye de les faire "bagoter" en statique.

Alors mauvaise manip ou réalité ? Je ne sais pas vraiment, aussi j'ai persisté à tort d'utiliser le mode programmé avec 3 I/O, ce qui m'évite de m'engluer dans des registres particuliers avec des restrictions et obligations assez compliquées et inconnues.

On connaît le principe de l'I2C, alors autant le réaliser en mode programmé, d'autant que ce n'est que pour 8 octets, et de façon très occasionnelle, tant en écriture du module que pour sa lecture.

Le fonctionnement avec MOSFET_P ou transistor PNP est opérationnel, mais n'est pas électriquement satisfaisant. Aussi je préconise d'utiliser un 74LVC07A en lieu et place de ceux-ci, mlais plus encore il s'avère nécessaire de simplifier en utilisant les "TRIS".

 2.3                 Les accus

J'ai prévu que cet outillage fonctionne sur un seul accu Li-ION de 3.7V et qu'il soit mobile (Pour recevoir le DCF77dans de bonnes conditions). Il utilise un petit convertisseur 3.7 vers 5V. Cette tension de l'accu sera contrôlée à l'allumage de l'outillage.

(On peut voir sur la photo ci-contre le gros élément 18650 qui alimente l'outillage et la pile du petit module Tiny en place. On peut voir aussi le quartz 8MHz, un condensateur de découplage de 10nF sur le PIC, ainsi que les 2 gros chimiques de l'alim et l'interrupteur général)

 Un autre accu cette fois beaucoup plus délicat était prévu sur chaque module Tiny DS1307. J'ai bien dit ACCU et NON PILE. Pour l'utilisation d'une simple pile, j'ai pu trouver une parade sur Internet avec une modification (partielle) mais insuffisante dans la mesure où le test de la pile devrait être réalisé tant sur l'outillage, qu'éventuellement sur l'appareil destiné à recevoir le module Tiny DS1307. (Voir § précédents)

 La raison principale est qu'à l'origine ce module est prévu pour un ACCUMULATEUR LI-ION (LIR2032) et NON pour une pile CR2032.

Dans le cas d'une pile, ce qui est le plus courant, celle-ci conviendrait largement pour une bonne dizaine d'années.

Dans le cas d'une pile il faut donc modifier ce circuit Tiny suivant le plan trouvé sur …. ces sites ou suivant le schéma repris pour être plus explicite.

https://www.electronique-mixte.fr/wp-content/uploads/2018/07/Formation-Interface-communication-50.pdf

https://www.pleguen.fr/index.php/arduino/modules/horloge-temps-reel-ds1307

https://www.vs-elec.fr/fr/minuterie-horloges/2109-module-horloge-temps-reel-ds1307-3665662013811.html

Mais ATTENTION cela ne suffit pas dans le cas où l'outillage ou l'appareil destinataire du module est hors tension. Dans ce cas précis c'est la pile qui réalimente partiellement l'outillage ou l'appareil si vous aviez pris le loisir de contrôler la tension de la pile avec une entrée ANA. ( Cette entrée ANA n'est plus réellement une entrée ANA lors d'une mise hors tension ! C'est simplement quelques composants sans fonction réelle avec des fuites à tous les niveaux)

Je m'en suis rendu compte accidentellement en ayant des difficultés pour une remise sous tension avec un re-départ incorrect du PIC réalimenté faiblement par la pile du Tiny module (par l'entrée ANA)

Si on veut mesurer par une entrée ANA la valeur de la pile, il est donc nécessaire de limiter ce courant de fuite par une résistance suffisante (510K) qui permette cependant la mesure de tension mais ne pouvant réalimenter tout montage (par une entrée !)

La mesure de la tension ANA ne peut se faire qu'en prenant un "TAQ" très important et de placer un condensateur réservoir aux bornes de l'entrée BAT (côté outillage et/ou montage cible).

Je pense que le contrôle de cette tension de pile est un peu superflu et n'a pas lieu d'être réalisé sur le montage cible recevant le module DS1307.

Tous les 10 ou 15 ans on change la pile et ça devrait suffire.

(Les changements de pile du Tiny peuvent (Et doivent) se réaliser avec les montages sous tension si l'on ne veut pas perdre date et heures).

Il est seulement important et suffisant de contrôler cette pile lors du "codage" du module, pour garantir sa longévité de 10 à 15 ans.

 La stabilisation de la tension après les 510K sur le Tiny module est maintenue par un petit condensateur de 10nF sur l'outillage qui permettra au PIC de charger son propre condensateur de mesure ANA sans faire chuter la tension à mesurer.

Pour plus de précisions sur cette correction pour pile CR2032 voir au § 3

Un petit complément cette fois l'autre composant RTC : le DS3231 qui lui aussi est alimenté par un accu de secours LIR2032, mais si vous utilisez une pile CR2032, il faut enlever la diode de charge minimelf.

 2.4                 Convertisseur de tension

 L'outillage est alimenté par un seul accu LI-ION type 18650 de 3.7 à 4.2V mais doit être alimenté en 5V, aussi un convertisseur est nécessaire. Cet accu est situé sous le CI et est visible sur les photos (couleur rose sur la photo précédente)

La tension de 5V est nécessaire tant pour la norme I2C que pour le display qui est en 5V.

Ce petit convertisseur d'origine Chinoise de quelques Euros a cependant un inconvénient sérieux, car il lui faut un excellent filtrage, tant les spikes de tension sont importants. Il faut également doubler l'accu LI-ION par un condensateur, car bien que la résistance interne d'un tel accu soit excellente elle reste insuffisante pour des pics de courant très étroits.

L'angle d'ouverture de conduction est très étroit et l'intensité (Non mesurée) certainement très importante également.

Il y a donc 470µF en // sur l'accu et 1000µF sur le 5V (+ 0.1µf pour la HF). C'est du sérieux pour quelques mA seulement !

La règle empirique de 1µF par mA est totalement bafouée, mais ce n'est pas grave en soi, dans la mesure où le convertisseur accepte les pics de courant sans "broncher", ce qui semble le cas.

En effet, au pire si ce circuit venait à griller, le risque est seulement de retrouver une tension moindre, c'est-à-dire environ 3.7V à 4.2V ! Donc pas de quoi s'affoler !

2.5                 ICSP

 L'ICSP est prévu par un connecteur mais ne m'a pas servi. En effet j'ai utilisé un PIC 16F690 DIP20 et ça été plus facile de coder  directement le PIC sur un support ZIF, car en ICSP il faudrait retirer impérativement les modules encodeur et DCF77 car ils utilisent les lignes de l'ICSP (Vpp, ICSPDAT et ICSPCLK).

Cela reste possible si on a mis l'encodeur et le DCF sur connecteur. C'est toujours le cas pour le DCF mais il fallait penser à l'encodeur et ne pas le souder !!! !...

2.6                 Le DCF77

C'est l'organe d'entrée de la date et de l'heure qui garanti l'exactitude des valeurs et la précision. (Photo du modèle revisité photo ci-contre et voir aussi le § suivant)

J'avais développé ce module programme DCF77 depuis très longtemps et il avait nécessité pas mal de travail. Je l'ai repris dans ce contexte avec simplification en page 0  et surtout pour ajouter une sortie complémentaire impérative en mode BCD dans un buffer pour pouvoir être introduit dans le Tiny module DS1307 qui demande ce format de données.

En outre par rapport au DCF, il faut entrer les secondes qui ne figurent pas en clair en DCF77, mais elles seront mises à zéro lors de la 2^ème impulsion manquante avec la minute+1 (au front suivant).

De plus, les jours de la semaine et les jours du mois sont inversés dans les deux systèmes, DCF et Tiny DS1307. Il faut donc les remettre en ordre pour le Tiny module.

Enfin, les valeurs du DCF77 restent converties en binaire à partir du label "minutes" pour le programme du PIC.

 L'horloge PIC reste bloquée lors de l'exécution de la routine DCF, mais est validée à la fin de la trame synchronisée pour maintenir l'heure sur le PIC.

 Les valeurs binaires et BCD seront maintenues (Seulement durant une seule journée) par l'outillage PIC pour permettre le codage de plusieurs Tiny modules sans avoir à reprendre une synchronisation DCF. (Ceci est nécessité par la non gestion de la date)

L'étiquette du Buffer BCD est "BUF77" avec l'ordre des données du circuit DS1307 remis dans le bon ordre juste au moment de l'impulsion manquante de fin DCF77.

 Le byte de contrôle d'adresse 0x07 du Tiny module, est prévu en écriture pour que le module fournisse en plus un signal à 1 Hz sur la sortie SQW/OUT en pin 7 du DS1307 ou sur la borne "SQ" du Tiny module.

2.7                 U4224B et DCF77

 Ce paragraphe mériterait un petit article, mais on fera au plus simple et en complément logique de cet article ...

J'avais malencontreusement fait un mauvais branchement sur un module DCF77 complet avec antenne ferrite, et il n'a pas résisté !
Vu le prix élevé de ces modules DCF77,  j'ai voulu réparer mon erreur et je me suis tourné vers un circuit intégré existant qui est capable de s'adapter à tous les émetteurs de 77.5 KHz à 40 KHz.

Ce circuit est le U4224B de TEMIC ! Le principe est quasiment le même que feu le module acheté, aussi cela me permet de garder l'antenne ferrite et le quartz à 77.5 KHz, éléments que l'on ne trouve pas facilement ou à des prix prohibitifs. (Y compris le condensateur d'accord de l'antenne ferrite qui est apparié avec celle-ci).

J'ai donc réalisé un tout petit circuit imprimé avec le U4224B avec les principaux éléments n'ayant pas souffert du défunt DCF77 : antenne ferrite accordée et quartz pour les principaux ! Tout marche bien !

Ce circuit consomme très peu (21µA mesurés) et demande seulement 2 secondes de temps de démarrage. Il a de plus une pin POWER_ON (PON) qui permet de réduire encore la consommation à 100nA !

 J'ai seulement appliqué avec succès le montage indiqué sur la documentation spécifique au DCF77, car ce circuit est compatible avec plusieurs émetteurs mondiaux en très basse fréquence.

J'ai ajouté un MOSFET_N pour avoir la sortie inversée. Ce montage donne donc au choix une sortie normale ou inversée.

(A noter que la sortie "normale" doit être bufferisée par un MOSFET  car le courant pouvant être fourni est très faible (Il écroule le signal sur un simple transistor avec une résistance de base de 100K !))

 Le circuit correspond exactement à la notice du U4224B, je n'ai donc pas fait de nouveau schéma, et j'ai juste ajouté le MOSFET_N (U2) avec 1.5K en gate et 10K à 33K en drain, comme c'est d'ailleurs indiqué dans le datasheet. Voici le lien pour ce datasheet :

https://datasheetspdf.com/datasheet/U4224B.html

Voici le schéma du circuit et le typon (1000 dpi en miroir) pour ceux qui veulent le reprendre tel quel.

Ainsi que je l'ai indiqué dans l'article sur le tracker, je recommande un MOSFET en lieu et place d'un transistor NPN, car cela écroule trop le signal ! Il faut une entrée MOS dans le cas où on veut utiliser le signal direct.

Ce circuit donne sur le connecteur la sortie normale et la sortie inversée ainsi que la commande POWER_ON* (Active à 0)

(Si vous n'utilisez pas cette commande POWER, mettre cette pin à la masse par un petit strap sur le run juste au dessus)

(Le Quartz est prévu dans 2 positions, soit comme représenté couché sur le U4224 ou perpendiculairement couché sur le transistor MOSFET. Ceci à cause des longueurs de fils pas toujours faciles à reprendre des anciens montages).

 2.8                 Le programme PIC16F690 avec OD

 Il est maintenant terminé et j'ai mis 6 commandes en 2 groupes, choisies par l'encodeur en quadrature. Les routines I2C sont figées et ont fonctionné du premier coup, ce qui est assez rare dans une première réalisation... Mais il faut l'abandonner pour la partie I2C !
J'ai en effet abandonné le hardware avec OD pour utiliser les "TRIS". C'est dommage mais c'est ainsi, car j'ai eu beaucoup de difficultés avec les nouvelles routines I2C....

Actuellement il était donc composé d'un premier menu à 4 possibilités à savoir lire l'heure au DCF77 écrire en I2C le Tiny module, le lire en I2C et "AUTRES" qui renvoie vers le deuxième menu.

Ce deuxième menu comporte seulement 2 entrées : Affichage du buffer BUFF77 et Entrée manuelle de date et heure y compris le byte de contrôle du Tiny/DS1307.
Le programme débute par une initialisation et la mesure de la tension de l'accu de l'outillage. La valeur est affichée au display. Une deuxième mesure est faite en séquence avec la mesure de la tension de la pile du Tiny module. La tension du Tiny module n'est pas rédhibitoire. Cette valeur sera également affichée au display mais dans le cas où elle se situe en dessous de 2.0 volts, un message "Pile low" est affiché. (Valeur limite indiquée par le datasheet)

Le programme a été modifié pour aller directement sur le menu, car cela permettra d'interroger un Tiny module sans avoir à se synchroniser sur le DCF77. 

Il est maintenant possible de rentrer manuellement date et heure avec l'encodeur, pour pouvoir vérifier certains programmes avec des dates précises, ce qui me semble très utile, notamment dans la partie des calculs solaires ou astronomiques.
Les 3 entrées principales du menu génèrent un affichage clair de l'heure. Le DCF77 affiche en cours 2 digits par 2 digits des informations reçues, avec dans l'ordre un S pour indiquer la synchronisation suivi des minutes, heures, jour du mois, jour de la semaine, mois et année. La fin est clôturée par un "Z". L'ordre est donc spécifique du DCF77, mais le buffer BUF77 est chargé avec les bonnes valeurs (BCD) et dans le bon ordre pour le Tiny et son circuit DS1307
J'ai pu contrôler la précision de l'heure maintenue par le PIC de l'outillage grâce au quartz. J'ai constaté 2 à 3 secondes de décalage en 12 heures de fonctionnement. Cet écart de temps semble incontournable et est donné par la seule précision du quartz. Ce fait me conforte dans l'aspect évoqué de se resynchroniser au moins une fois par jour sur le DCF77. Je pense que ce sujet de la précision des quartz fera l'objet d'un petit complément, car avec 4.7 pf en // sur les quartz, j'ai déjà fortement amélioré cet écart (C'est en cours d'essais actuellement)
Le Quartz du Tiny module est dans le même sujet et j'espère aboutir à une solution acceptable.

Le menu d'affichage ainsi que le menu d'écriture se font juste après le changement de seconde sur  le temps du PIC pour la meilleure précision possible relativement à l'origine DCF77. Le timer zéro est remis à zéro ainsi que le comptage de base en 25ms. Toute éventuelle interruption pendante est également fermée.
Toute écriture I2C commence par le contrôle de la pile CR2032 et après synchronisation à la seconde, l'écriture réelle I2C. Il n'est donc plus nécessaire de contrôler la pile en début de programme, mais seulement à cet endroit. Cela permet de débuter le programme sans la présence d'un Tiny module. Ce contrôle initial a cependant été maintenu, mais une tension faible n'est plus bloquante et est seulement indiquée (Absence Tiny module).
Le menu d'affichage est devenu "Autres" avec 2 sous menus dont l'affichage et l'entrée manuelle des données de date et heures avec l'encodeur en quadrature.

 2.8B                 Le programme PIC16F690 avec "TRIS"

Ce programme structurellement est très peu différent de celui d'origine au niveau des commandes, mais il a nécessité beaucoup de temps pour sa mise au point à cause d'une particularité qui est la suivante :

Il est évident que les retournements d'entrée et de sortie de bits de ports sont récurents et que l'on est tenté de créer des macros. C'est ce que j'ai fait, mais mal à propos. En effetlorsque vous utilisez une macro, votre programme indique une seule ligne pour peut-être plusieurs lignes et instructions.
Si vous ne faites pas attention à cela, vous allez aller droit dans le mur, ce que j'ai fait en toute confiance, car après avoir modifié le hardware en supprimant les open-drain et confiant dans ce programme qui fonctionnait bien, j'ai longtemps cherché ...

Le sujet est simple, derrière un test on ne peut pas pas mettre une macro, car suivant le résultat du test on ne fait pas dfu tout ce qui est prévu ! mais n'importe quoi en sautant ou non la première instruction du groupe d'instruction macro.

J'ai également préparé la programmation pour obtenir les signaux SQW ou SQWE et 32K pour les modules DS1307 et DS3231. Ce programme est donc tgalement compatible pour ces deux modules.
Inutile de dire que la version Open Drain est obsolète !

  3         Le Tiny Module DS1307

Il vient de Chine et outre le circuit DS1307 d'horloge, il comporte également une EEPROM 24C32 accessible suivant le même principe I2C à l'adresse 0x50 (7 bits)  (ou 0xA0 8 bits en écriture)

Le DS1307 est accessible à l'adresse I2C 0x68 (7 bits) (ou 0xD0 8 bits en écriture)

La modification pour traiter la sauvegarde avec pile CR2032 a été indiqué précédemment.

Il faut supprimer les résistances R4 et R5, remplacer R6 par une résistance 0 ohms, et insérer sur la sortie BAT la résistance de 510K.La diode doit également être supprimée. Quoi de mieux qu'un schéma plus précis que ceux que j'ai pu voir...

 Vous pouvez aussi utiliser le circuit en natif si vous utilisiez un accu LIR2032 qui est la version rechargeable du CR2032, mais dans ce cas le Tiny module devrait être mis plus souvent sous tension pour recharger ce mini accu, car au final, c'est la consommation du pont diviseur 510K 1.5M qui obèrera la longévité du maintien de la date et de l'heure. Cette consommation n'est pas négligeable.

L'esprit de ce montage (pour "bricoleurs") fait qu'il sera utilisé une ou 2 fois par année ??? Peut-être ? Et qu'une pile est quasiment rendue obligatoire (Dans ce contexte !)

La modification suivant le schéma relevé est tout à fait correcte SI le circuit "BAT" reste en l'air, car autrement il risque de RÉalimenter l'outillage ou un autre circuit d'utilisation, par le biais de l'entrée ANA (d'un appareil hors tension). (Ce fait a été mis en évidence par un mauvais départ du PIC sur l'outillage !!!)

 Si toutes fois vous ne vouliez pas mesurer la tension de la pile, alors le montage avec la modification de base suffit.

Pour insérer la nouvelle résistance de 510K sur la sortie BAT, il faut le faire à raz de la pin de sortie, car autrement le DS1307 serait alimenté au travers de 510K !   (Voir photo ci contre cercle rouge)

 On notera que le circuit comporte une sortie "DS" prévue pour un capteur de température DS18B20 (Non présent sur ce module).

Les résistances sur SDA et SCL sont déjà présentes sur le Tiny Module et n'ont donc pas à être installées sur l'outillage.

Le Tiny module dispose d'un double connecteur dont l'un n'a que 5 broches et est plus destiné au capteur de température.

Un lien utile également pour tout ce qui peut se connecter en I2C :

https://www.aurel32.net/elec/i2c.php

3B      Le Tiny Module DS3231

Pourquoi un autre module ? Je pense que vous avez pu saisir un élément important qui est la précision du temps. Or ce module DS1307 n'est pas très précis tant en valeur absolue, qu'en dérive en fonction de la température. Le module DS3231 est un oscillateur à base de TCXO, c'est à dire compensé en température. La fréquence d'un quartz diminuerait en fonction de l'élévation de la température, mais ce module à base du DS3231 corrige automatiquement la fréquence en fonction de la tempértature.
Il va de soi que le prix de ce module n'est pas comparable à celui du DS1307.

Mais !...

A ce stade des expérimentations sur le temps, je ne suis plus tout à fait enchanté par le module TCXO, pour de multiples raison. Sa fréquence de base n'est pas suffisamment précise, et je suis arrivé à des valeurs bien meilleures en ajustant le DS1307. Ce DS3231 a le grand désavantage de comporter un élément oscillant interne au circuit intégré, certes compensé en température, mais inaccessible pour ajustement par des condensateurs en // comme pour le DS1307.
Au niveau amateur, la dérive en température a moins d'importance que la précision intrinsèque du temps pour le long terme. Aussi je reste très "mitigé" sur le DS3231.
j'ajoute que le 2 ppm n'est l'objet que de certains modules et que sans faire attention aux indices des composants, on se retrouve vite avec 5 ou 10 ppm, ce qui devient problématique pour des durées de nombreux mois ou années.

4         Schéma de l'outillage ancien modèle

Ce schéma reste simple. On peut y voir les résistances d'Open Collector mises en dehors du circuit puisqu'elles sont sur le Tiny module, on remarque également les 2 MOSFET_P sur les sorties PIC  et la lecture sur la sortie SDA avec la 3ème I/O.

 En ce qui concerne l'encodeur en quadrature, j'en avais réalisé un sur la base de petits PIC, mais j'ai retenu celui de la revue Elektor d'octobre 2016, et je vous y renvoie pour ne pas plagier ce montage qui a le mérite d'être simple et de bien cadrer avec le principe des petits encodeurs à switch du commerce.

4B       Montage avec les "TRIS"

Ce schéma est peu différent de l'autre et comporte principalement les modifications pour SDA et SCL

5    Montage avec DS1307 Seul

Si vous aviez déjà installé le seul circuit DS1307 sur votre montage, alors vous pouvez éviter de traiter la mise à l'heure dans votre programme en utilisant simplement quelques fils depuis le bus I2C de votre montage vers le bus de l'outillage. C'est en quelque sorte un "pseudo ICSP" pour la mise à l'heure.
Si vous aviez déjà un DS1307, c'est que vous pratiquez l'I2C peut être pour d'autres périphériques. Il est fort probable que vous ayez déjà les résistances des Open Collector. Si ce n'était pas le cas, alors il faudra les mettre, peut être au niveau des fils de raccordement.

Il va de soi que vous devrez mettre un connecteur sur votre montage qui donnera accès aux deux lignes SDA et SCL référencées à la masse et il serait bon également, outre la masse, de prévoir un fil pour le Vcc pour raccorder les 2 résistances au cas où… !

 Cette possibilité reste très marginale, car en principe vous avez du prévoir la mise à l'heure, mais on ne sait jamais, car ce programmateur peut éviter quelques lignes de programme et cela peut être intéressant pour disposer d'une mise à l'heure précise issue du DCF.

 Il est évident que dans ce cas, il sera nécessaire que le montage de l'utilisateur ait prévu le maintien de l'énergie pour garder les éléments de date/heure. Cette  énergie pourra dans ce cas être soit une pile CR2032 soit un accu LIR2032 et la méthode d'alimentation de l'entrée BAT du DS1307 devra avoir été prévue.

6         Conclusions

D'une façon générale, je crois que les électroniciens n'aiment pas trop voir la "partie énergie" se trouver sur les circuits imprimés, du moins (c'est mon cas !). Alors utiliser un module externe sur le circuit imprimé d'une application est une solution acceptable. C'est la raison pour laquelle je trouve cette solution du Tiny module intéressante pour plusieurs raisons.
J'ai parlé d'années voire de dizaines d'années avant de changer de pile, et c'est peut-être vrai pour cette partie énergie, mais au bout de ces années qu'en sera-t-il de la date et de l'heure ? Combien de minutes, heures, voire de jours de décalage se seront produits ? C'est là le principal écueil auquel je n'avais pas véritablement songé, mais qui m'est revenu avec acuité lors d'une vérification faite seulement 12 heures après une mise à l'heure sur l'outillage !

Certes, ce n'est pas encore le drame absolu, mais c'est un vrai problème que j'avais souvent supposé sans jamais avoir mis véritablement le doigt dessus. En effet sur les panneaux solaires, j'avais toujours prévu de faire la mise à l'heure journellement, car je pensais que l'horloge PIC (Horloge interne de type RC) n'était pas suffisamment précise et stable pour calculer les équations solaires. (Vrai ou faux ? je n'en sais rien à ce stade)

Cette fois, pour la mise à l'heure pour de nombreuses années, j'avais mis les moyens avec quartz sur le PIC et je m'aperçois de  déviations du temps par rapport au DCF sur une période de seulement 12 Heures, et cela m'a inquiété (3 secondes). J'ai toujours cru le quartz comme remède absolu à la précision, mais il n'en est rien et j'avais simplement oublié les particularités des quartz !!! Avec une double résonance série et //.

Qu'en est-il réellement de la précision ? J'ai voulu m'en rendre compte au réel en laissant tourner durant 12 heures environ le montage sous tension et en regardant le basculement de la minute avec une autre horloge DCF. J'ai constaté une avance d'environ 3 secondes de décalage pour l'horloge du PIC avec un quartz de 8 MHz et une précision rigoureuse au niveau du TIMER1.

J'ai également constaté 8 secondes de décalage sur le Tiny toujours avec cette même horloge DCF et le même temps d'observation mais le Tiny étant alimenté par l'outillage durant ces 12 heures.

Il reste à vérifier le décalage Tiny hors tension cette fois, et seulement alimenté par la pile... Lors d'une deuxième mesure je n'ai trouvé que 2 secondes !...? Je pense que pour le Tiny module, le problème est encore plus compliqué, du fait qu'il est alimenté parfois par une alim externe, et parfois par la pile CR2032.

Que penser de ces écarts de temps imprévus ? Rien de bon ! Cet outillage serait-il un coup d'épée dans l'eau ? Peut-être pas. au niveau des écarts, cela reviendrait pour 3 secondes à un rapport de 1/14400, ce qui reste non négligeable mais interdirait toute exploitation réelle au delà de 8 à 10 jours.

En résumé 3 secondes pour 12h cela reviendrait à 1 minute de décalage en 10 jours, ou 6 minutes en 2 mois ce qui devient  inacceptable.
Alors que penser ? Il y a (presque) toujours une solution  à un problème !

Il me semble que la vérité se situe à mi chemin et que sans aucune modification, le système permettrait de faire des pauses dans la journée, mais nécessiterait cependant une remise à l'heure périodique comprise entre 24 h et 2 mois suivant la précision que l'on demande.
Il est évident que durant une dizaine d'années, et dans ces conditions, il n'est pas possible de maintenir l'heure à un niveau de précision satisfaisant.

Concernant l'horloge du PIC, actuellement fonctionnant sur la base d'un quartz de qualité à 8 MHz, la précision n'est pas satisfaisante, bien que la fréquence soit "exacte" (au scope !), je ne savais plus comment expliquer cette différence, car la remise à zéro du registre du Timer 0 est faite au bon instant et le décomptage ajusté rigoureusement à la bonne valeur, à l'instruction près. Il semble évident que le PIC n'est pas en cause et que c'est le quartz qui est  la cause, car il oscille sur la mauvaise fréquence de résonance et qu'il doit être compensé par un condensateur en // pour abaisser légèrement la fréquence.

Au sujet des quartz, il reste à investiguer la modification de la fréquence des quartz avec des condensateurs et de voir si c'est véritablement envisageable. C'est une opération que je n'ai jamais eu l'occasion de réaliser.

Je viens de faire plusieurs essais avec 10 pf en // mais c'est trop car on bascule de l'autre côté, et l'oscillateur est alors trop lent.
Il faut donc ajuster au plus fin avec quelques Pf en // sur le quartz, et pour cela une simple torsade de 2 petits fils isolés téflon peut faire l'affaire.
A savoir qu'un mètre de cette torsade représente 110 pf mesurés. Il faudra donc quelques centimètres à couper en vérifiant la dérive après un certain nombre d'heures (ou de jours).
Cette corection s'applique également et SURTOUT au Tiny module et après avoir placé un condensateur de 6.6 pf, l'écart sur 12 heures semble assez petit, sans pour l'instant savoir de quel côté je me situerai après un nombre d'heures plus conséquent.

Cette précision de l'heure est réellement un point important et je pense qu'il faudra réellement ajuster la fréquence des quartz aussi bien sur l'outillage mais surtout sur les Tiny modules si l'on veut éviter de corriger trop souvent l'heure sur le montage destiné à recevoir le Tiny module.
Le problème de ce condensateur d'ajustage est principalement sur le Tiny module, car il n'est pas question de mettre un petit trimmer vu que le circuit est déjà réalisé, aussi ce système de la torsade est le plus simple (après avoir déjà installé un condensateur qui fera le plus gros du travail.

Sur l'outillage ça poura être un trimmer si vous refaites le circuit, c'est un peu plus "pro" !

(Sur la photo, les flèches rouges pour la torsade faisant office de condensateur de faible valeur.  Celle-ci est branchée directement en // du quartz situé en dessous du CI.
En jaune, le condensateur de 5.9 pf, base du réglage. L'affinage sera réalisé par la coupure de la torsade et son immobilisation finale par de la colle (à faire)).

L'autre possibilité sur laquelle j'ai quelques doutes, serait d'utiliser l'oscillateur RC interne du PIC qui reste tout de même assez stable et qui a le mérite de pouvoir être ajusté grâce à OSCTUNE. Cela pourrait règler le problème côté PIC mais pas côté Tiny où seule la modification de la fréquence du quartz reste envisageable.
Au niveau des quartz, je maîtrise assez mal le sujet et les possibilités réelles et j'ai seulement quelques bribes concernant les fréquences séries et //. Je dois faire encore quelques recherches à ce sujet.

La dernière remarque est que si l'horloge du PIC n'est pas parfaitement précise, ce n'est pas très grave dans l'emploi, car il peut être très facilement re-mis à l'heure (du DCF). Il n'en serait pas de même sur un montage en pleine nature à des kilomètres ou dans des conditions difficiles et équipé du Tiny module.

Il faut donc rectifier et ajuster en premier lieu la fréquence du Tiny module, ce que je n'avais jamais envisagé une seule seconde !

Le montage permet cette gymnastique même avec son oscillateur non rigoureusement calé avec précision. En effet la première opération consistera à lire le DCF, puis juste après à écrire un Tiny module. Enfin après un certain temps de mesurer des écarts de temps d'au moins une seconde, de relire le Tiny module, d'afficher le Buffer puis de comparer avec un DCF externe (pendule par ex) si il y a des différences conséquentes.
Cette approche par tâtonnements nécessitera de longs moments de réglages, mais cela n'a plus rien à voir avec mon outillage qui m'a seulement permis de débusquer ce lièvre.

Au final je vous invite à compulser ce lien vers Wikipédia https://fr.wikipedia.org/wiki/Quartz_(%C3%A9lectronique)  où vous pourrez comprendre comme moi que rien n'est acquis au niveau de la fréquence et que c'est finalement à nous de faire le nécessaire pour que le quartz du Tiny oscille à la bonne fréquence. Il apparait aussi à la lumière de cet article qu'il est facile de diminuer la fréquence de résonance, et que heureusement ces quartz semblent avoir été prévus en ce sens.
Cependant on comprendra aussi que la fréquence de résonance dépendra aussi de l'électronique pure du Tiny et des capacités parasites qu'il présente sur l'entrée oscillateur.

Donc ajustez au mieux les quartz et n'oubliez pas que la température joue aussi un rôle non négligeable. Regardez également sur un moteur de recherche "réglage précision d'une montre à quartz", et vous aurez compris que ce qui vient d'être dit est une réalité. Un quartz est précis mais il faut l'ajuster et le maintenir en température constante.
Une montre à quartz est beaucoup moins sensible à la température, du fait qu'elle est à la température du poignet, (pour les bracelets)
J'ai lu sur Wikipédia que les Quartz sont taillés pour une capacité // d'entrée du montage oscillateur de 6 Pf. La capacité à ajouter est donc très faible et je pense que c'est mécaniquement réalisable avec une simple vis de réglage ou une torsade comme c'était déjà réalisé dans les très anciennes télé avec rotacteur, ou mieux un trimmer si ça a été prévu !

Voyez également sur ce site (https://www.forum-mdp.com/t6343-ajuster-un-calibre-quartz) quelques commentaires propres au réglages des montres à quartz mais qui s'appliquent rigoureusement à ce Tiny module qui ne fait pas exception aux quartz en général.

 En conclusion ultime, je dois dire que ce montage avec les TRIS a été nécessité par le fait que je ne pouvais plus programmer les sorties 1 herz sur DS1307 et 32 KHz sur DS3231 suite à des erreurs. J'ai donc pris la décision de revenir à plus simple, même si au niveau concept Open Drain et TRIS cela semble un peu différent. Cette reprise du programme a été laborieuse ainsi que déjà évoqué.
Ces sorties 1 HERTZ me sont nécessaires pour un montage en cours qui devrait s'appeler "montage pour l'étalonnage du temps", qui s'appuiera sur un pseudo étalon de temps élaboré sur de nombreux jours et permettant d'étalonner de nombreux modules DS1307. Les modules DS3231 ne sont pas concernés car non mùodifiables. Ce montage permettra de cerner RAPIDEMENT les variations en quelques minutes ou heures contrairement à plusieurs jours.

_______________________________________________________________________________________________________________

CHAPITRE 2