TRACKER PHOTOVOLTAÏQUE

TRACKER PHOTOVOLTAÏQUE

1    Choix techniques
1.1    SINUS, Arrondis et Arcsinus
1.2    Date et heures, angle horaire
1.3    Moteurs et réversibilité des démultiplicateurs
1.4    Sécurités enroulement et limites
1.5    Batterie, énergie, heures
1.6    Vent
1.7    ULPWUE
1.8    Signalisation
1.9    Les 4 Formules solaires
2    Références et sites
3    Choix des I/O
3.1    Relais
3.2    DCF77
3.3    Anémomètre et tension 12V
4    Principes généraux programme
4.1    Moteurs
4.2    Consommations et fonctionnement
4.3    Capteurs ANA
5    Organigrammes
6    Schéma complet
7    Réalisation
8    Conclusions
9    Si c'était à refaire…
9.1    Ce qui est bien
9.2    Ce qui serait à revoir
10    Problèmes rencontrés

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

Ce projet devait être l'affaire de quelques semaines, mais au final cela aura duré un peu plus d'une année. En effet pas mal de routines pouvaient être reprises du programme du panneau solaire thermique, notamment les routines de calculs de position, mais cela a été plus compliqué qu'il n'y paraissait à l'origine. J'ai en effet voulu simplifier mais parfois ou oublie beaucoup de choses rendues nécessaires par des réalisations mécaniquement difficiles.
L'essentiel est d'arriver au terme et je pense que c'est le moment tant attendu. Alors bonne lecture, même si par moment vous ne pourrez pas vous raccrocher aux péripéties d'une version qui ne rendait pas le service attendu.
Il y a aussi eu beaucoup d'erreurs de ma part, mais à ma décharge, je suis tombé pour la première fois sur un PIC partiellement HS, et cela n'a pas été facile de lever le doute, car j'avais pris l'habitude de me rendre seul coupable d'une erreur, car jamais un PIC n'avait réellement été mis en défaut.
Le programme tournait avec 2 PIC en alternance ainsi qu'en simulation, mais le 2ème PIC fonctionnait mal, sans que j'arrive vraiment à comprendre le problème. Alors j'ai été obligé de conclure sans véritables preuves !

N.B. Pour bien suivre ce projet, je vous invite à tirer le schéma en §6 sur papier ou de le charger dans une autre fenêtre ou un autre onglet.

1 Choix techniques

En "survolant" le programme assembleur de poursuite solaire de mon vieux panneau solaire thermique, je viens de me rendre compte combien c'était imbuvable après plusieurs années d'oubli, et même quelques semaines après. Bien que les commentaires soient nombreux, (malheureusement pas toujours mis à jour) mais c'est l'esprit général qui est oublié .(http://bricolsec.canalblog.com/archives/2012/01/23/23315672.html)
Aussi j'ai pris la décision d'essayer de faire plus simple et plus structuré, pour pouvoir reprendre éventuellement en cas de problèmes, mais aussi parce que les années passent et je vois la masse de travail à faire, à une vitesse certainement moindre…
Alors pour suivre (ou poursuivre) le soleil, comme cela a été dit dans les autres articles, la précision de position n'est pas absolument vitale, car les conséquences sont de quelques pourcents d'énergie en moins pour un écart de 10°.
Les formules trigonométriques utilisées dans cet ancien système ont été réutilisées partiellement car modifiées pour plus de simplicité et une précision peut-être moindre, mais pas certain …!

1.1 SINUS, Arrondis et Arcsinus

En premier lieu, le problème des calculs de sinus, arcsinus et autres est un point incontournable dans cette application de tracking. Il faut cependant minimiser les calculs en termes de temps, car je ne veux pas travailler à 20 MHz mais seulement à 8 MHz au maximum, et surtout réduire la complexité des calculs décimaux.
Pour rappel de conversion : radians=degrés*pi()/180.
Les relations trigonométriques permettent de ne traiter les angles et valeurs associées, que sur l'espace angulaire de 0° à 90°, 100 grades ou Pi/2. Mon choix définitif d'unité a été le degré à cause des unités des formules exprimées le plus souvent en degrés (et fractions) et je ne voudrais pas changer ces habitudes au risque de rendre encore plus imbuvables les calculs par des conversions supplémentaires.

Je vais utiliser une table des sinus de 0 à 90°   WORK\TEMPORAIRE\sinus_deg_rad.ods qui est réduite à 3 décimales après la virgule.
Rappel : le sinus d'un angle est toujours <=1. On travaillera donc sur le sinus x1000. avec pour maxi 999
Ces 3 décimales obligent cependant à calculer sur 2x8 bits soit 16 bits, mais les calculs seront plus rapides en 10 bits (Quand les routines 10 bits existent) puisque le sinus maxi sera de 0.999x1000=999 et que 10 bits suffiront.
Ce paragraphe est extrêmement important car il va conditionner la précision du pointage et la difficulté des calculs en assembleur.
On notera que les sinus des angles supérieurs à +-80° varient très peu et que ce sera une petite source d'erreur lors des calculs, avec une précision moindre. Cela pourrait se sentir effectivement par des mouvement parfois inverses, alors que le soleil ne va jamais en marche arrière ! Cette manifestation bizarre à priori est cependant normale, au vu des choix effectués, et les conséquences se manifestent au lever et au coucher du soleil au niveau de l'azimut.

Sur les 4 grandes formules de calcul des équations solaires (voir §1.9), les incertitudes seront comme par le passé, assez importantes, car les formules cumulent additions, multiplications et divisions. Il est utile que ces calculs ne soient pas entachés de trop de pertes de décimales, c'est pourquoi il est peut être préférable de simplifier au départ les fonctions trigonométriques et de ne pas impacter les calculs par des pertes de décimales.

Dans les concepts, les cosinus utilisés dans 3 formules seront obtenus simplement par la relation :
Sin a = Cos (90-a), ce qui permet d'éviter les élévations au carré puis l'extraction de racine carrée très délicate en assembleur.

Les autres formules utilisées dans les différents cadrans sont :
Sin 180-a = Sin a
Sin 180+a = -Sin a
Sin 360-a = -Sin a     ou    Sin –a = -Sin a

Les cosinus correspondants à ces formules seront toujours donnés par la formule citée juste avant avec pour "a" une valeur comprise entre 0 et 90°

Toutes les approximations affectent principalement les toutes premières valeurs des cosinus, ou les dernières des sinus. Mathématiquement on a l'habitude de dire que la valeur du sinus d'un angle de 0 à 7 ou 8° est très proche de la valeur exprimée en radians de l'angle ! (Ce sont des approximations admises en calcul rapide et en l'absence de tables, car la variation du sinus est rapide. Cette méthode ne sera pas utilisée car non homogène avec le reste des calculs)
Les sinus vers 90° varient peu, et proportionnellement les valeurs restent assez bonnes car ce sont 1/1000 et 1/10000 qui sont affectés.
Ainsi, pour 89 et 90° le sinus sera identique à 1. Pour 87 et 88° il sera 0.999. Ces valeurs se retrouvent aux débuts et fins de journées.

Jusqu'à 10° angulaires, un sinus exprimé sur 3 décimales seulement, induit des erreurs de 0.5% maximum SAUF pour 1° où l'erreur est de 2.59%, et à 10°, c'est 0.2%, et à partir de 11° les erreurs ne dépassent plus 0.13% (Toutes valeurs absolues).
Alors ceci étant clairement dit, je crois qu'il n'y a pas de honte à procéder ainsi pour exprimer un sinus avec seulement 3 décimales soit 10 bits maxi.

Voici quelques éléments hyper importants qui font partie des lignes du logiciel…
Les degrés négatifs sont toujours indiqués en vrai complément à 2, mais les valeurs des sinus et cosinus s'ils sont négatifs sont en faux complément à 2 car la valeur absolue reste positive en binaire pur, mais le bit 15 du 2 ème octet indique s'il est à 1, une valeur négative.
NOTA : Les degrés (négatifs) ne dépassent jamais 90° (avec les relations trigo) aussi ils peuvent rester sur 8 bits !

(Commentaires inclus dans le programme)
; L'angle Deg0 et Deg1 sera en complément à 2 si négatif
; ATTENTION les sinus négatifs n'ont que le bit 7 de SIN1 positionné. Les autres bits représentent la valeur
; les valeurs données en sinus pour calculer l'arc sont quelconques et ne tombent pas sur des
; degrés exacts.
; Le principe de calcul repose sur une recherche de valeur sinus en table avec une recherche au
; maxi sur environ 9 valeurs maxi et arrêt sur le sinus le plus petit avec en correspondance les degrés
; voir le fichier CALC avec \WORK\PIC\loi_arcsinus.ods
; 2 droites constituent le principe. les équations sont les suivantes.
; Le point commun des 2 droites est le sinus 839(10) pour 57° ce qui correspond à 9 recherches maxi
; pour l'équation haute et 7 maxi pour l'équation depuis zéro
; depuis 0 la première droite est Y=0.068x avec Y degrés et X le sinus ou Y=x/14.7 arrondi à 14.
; (L'arrondi affecte seulement le nombre de recherches)
; depuis 57° la deuxième équation est  Y=0.20x-111 avec Y degrés ,et x le sinus
; cette équation se simplifie en Y=x/5 -111
; en théorie c'est -114 mais pour le raccordement des 2 droites il faut mettre -111 à cause des approximations de calculs
; suivant la valeur < ou > que 839 on utilisera l'une ou l'autre des équations de droites.
;
; RAPPEL les degrés négatifs sont toujours en COMPLEMENT VRAI à 2
;
; les sinus négatifs ont seulement le bit 7 positionné. la valeur + est inchangée SANS le complément à 2
; NOTA : Le point 57° permet d'avoir un nombre d'itérations maxi de 9 quelque soit l'équation utilisée
; les temps pour 9 itérations sont 1416 cycles ou 708µs

 
Le principe du calcul des arcs sinus ou cosinus repose sur la base de l'équation de 2 droites inscrites au plus près des courbes sinus ou cosinus (Voir courbes ci-contre).
Le nombre d'itérations est équilibré au mieux pour ne pas dépasser 9 itérations de calcul soit au maxi 708µs. Le point d'articulation des 2 droites est situé à 57°.
On comprendra que dans cette recherche de la valeur d'un angle à partir de son sinus et sans cet artifice, on peut à l'extrême limite avoir besoin de 90 itérations dont le temps serait prohibitif.
Ce ne sera donc pas le cas et l'approche par l'équation de 2 droites me semble une bonne solution qui allie simplicité et rapidité.

1.2 Date et heures, angle horaire

Là aussi je veux simplifier le hardware et éviter un oscillateur à quartz, car pour limiter toute explosion de lignes de code, je vais utiliser un récepteur DCF77 qui me donnera une fois par jour la bonne heure et la bonne date, sans avoir à faire des calculs toujours pénibles. (D'autant que dans les prochaines années, l'histoire des heures été/hiver pourrait bien changer…) Voir également un nouveau projet d'horloge réel avec DS1307, mais qui ne sera pas appliqué faute de temps.

L'angle horaire sera lui aussi simplifié au maximum.
En définition, l'angle horaire correspond à une rotation de la terre sur 24 heures, soit un angle parcouru sur 360°, soit en minutes 1440 minutes (horaires) pour 360° (angulaires)…
Si on ne veut pas avoir une précision "astronomique", on peut admettre que 1° angulaire étant assez faible en termes de suivi de rotation d'un panneau, il semblerait qu'il soit suffisant de corriger l'orientation chaque fois que l'angle de rotation évolue de 1° (en plus ou en moins).
Ce n'est pas par hasard que je propose cela, car cela correspond exactement à 4 minutes de temps. (1440/4=360), mais la réalité sera toute autre car 1° étant vraiment très petit, je m'étais finalement rabattu sur un temps de 10 minutes, puis à la lumière des valeurs de delta d'impulsions sur le mouvement, je suis naturellement revenu à 4 minutes qui correspond mieux à une meilleure adéquation de temps, énergie et précision.
Là aussi, ces simplifications vont laisser du temps libre au processeur et permettre de surveiller d'autres paramètres et surtout de libérer la consommation des auxiliaires, car durant la journée, il sera nécessaire de maintenir l'heure avec le timer0, et donc impossible de passer en "sleep".
Il ne serait pas facile d'utiliser le timer 1 comme horloge, car il est trop utilisé à d'autres tâches qui nécessitent plus de 8 bits et cela compliquerait beaucoup le programme que je préfère garder le plus simple possible.
A ce jour des essais réels, après bien des modifications et à la lumière des consommations, je pense que l'on pourrait largement travailler à 4 MHz en standard, et peut être même un peu moins. Cependant, je ne ferai pas cet effort, car il faudrait reprendre la partie MLI ainsi que tous les temps des routines de délais ainsi que toutes les vérifications associées. Il fonctionnera ainsi en consommant environ 4.3 mA sur son  alimentation, sans compter les séquences moteurs.
En mode de nuit sur ULPWUE en SLEEP, la consommation passe à 2.5 mA
En complément de cette non réduction de la vitesse du processeur, j'ajouterai que le temps des vérifications au niveau des heures minutes secondes, même en accéléré reste toujours long et délicat et que je ne veux pas risquer d'erreurs par une vérification trop sommaire.

Cette méthode sur la base du module DCF77 pourrait être améliorée avec mise en sommeil du PIC en journée pour gagner un peu d'énergie (Voir § 9 "Si c'était à refaire")

1.3 Moteurs et réversibilité des démultiplicateurs

Voir également l'article sur les réducteurs épicycloïdaux Somfy (http://bricolsec.canalblog.com/archives/2019/02/01/37066460.html)

L'équilibrage du panneau qui pèse une petite dizaine de kilos, n'a pas pu être réalisé pour des questions de difficultés de réalisation mécanique pure, mais l'axe "hauteur" a tout de même été déporté pour limiter un peu les efforts en position montée vers 90°.
Je pensais que les réducteurs épicycloïdaux n'étaient pas réversibles tant le rapport 1/175.45 est important… Eh bien non et j'en ai fait les frais, car j'avais dû réaliser pour la partie "Montée" un frein à ferrodo pour maintenir la position, mais la vitesse en montée était bien trop rapide, alors j'ai dû installer un deuxième réducteur en série, celui d'un micro-moto-réducteur, gros comme une "tête d'épingle", et cette fois il a fallu démonter le frein et adapter, car on est un peu dans l'excès inverse, mais c'est mieux ainsi.
La régularité de positionnement en fonction de la température est cette fois traitée par l'adjonction sur les deux mouvements de 2 capteurs switch HALL en entrée du réducteur Somfy.
Ces capteurs sont surveillés pour compter les impulsions. (2 impulsions par tour) Les éventuels mouvements non commandés, notamment en azimut ne seront pas contrôlés et pourraient amener une désynchronisation horaire, mais ce cas est un faux problème car en l'absence de commande, l'alimentation des capteurs HALL étant coupée, il ne peut pas y avoir d'impulsions comptabilisées.
 
Ce point de variation de vitesse moteur était resté un problème sur le panneau solaire thermique, car suivant la température extérieure, les moteurs avaient plus ou moins de "vivacité", et la position n'était pas parfaite. Ce problème est résolu dans cette réalisation par le comptage des impulsions.
Dans le cas présent, les deux moteurs seront commandés en MLI, car en Azimut (EO) la démultiplication par 476.22 est encore insuffisante et il sera nécessaire de gérer la masse non négligeable du panneau en faisant une pseudo régulation PID improvisée pour compenser les masses en mouvement. Cela restera assez simple en MLI, et permettra en plus d'avoir des vitesses de repli élevées, (Important en cas de brusque coup de vent) ce qui n'était pas le cas pour le panneau solaire thermique.

Le principe de la modulation de vitesse fera que l'on accélèrera durant la première moitié des parcours moteurs, (moitié des impulsions) puis suivra une décélération jusqu'au compte final d'impulsions.
Il y aura une vitesse minimale pour chaque moteur ainsi qu'une maximale.
On notera un point important éventuellement à améliorer, qui est qu'en fonctionnement durant une journée, les déplacements toutes les 4 minutes sont toujours très faibles de 2 à 5 impulsions au maximum et que dans cette vision, il est parfaitement inutile, voir néfaste de réguler une vitesse en accélération/décélération. C'est une simplification logiciel à évaluer.

L'électronique pour les deux moteurs sera partagée et le mouvement sera donc exclusif en hauteur OU azimut. Ceci pour raisons de simplification du hardware, mais aussi car il n'y a pas de double commande MLI full bridge, et il est beaucoup plus simple de mettre un relais qui commutera azimut ou hauteur, car cela serait aussi un peu dommage de doubler un full bridge uniquement pour le plaisir, alors que le temps ne presse pas, et que la rotation de la terre nous attendra bien !
La réalité aurait pu être différente car sur le PIC16F886 il y a bien 2 MLI potentielles mais les démultiplications sont différentes entre hauteur et azimut, aussi on gardera les deux relais et une seule commande MLI. Le sens sera alors obtenu par un relais d'inversion de polarité et non par un montage full bridge.
(NOTA : Il y a bien 2 MLI sur ce PIC mais half bridge ou full bridge ne sont possibles que sur CCP1)
De plus il y a une seule alimentation 12V et half bridge push pull n'est pas possible.

Cet ensemble de commande des moteurs décrit, reste tout de même relativement compliqué et je pense qu'il est possible de faire encore plus simple. Je préconiserais d'avoir seulement deux vitesses. Pour quelle raison ?
-Il faut une vitesse moyenne pour amener le panneau du repli à sa position horaire, et réciproquement en fin de journée, mais aussi pour le repli en cas de vent violent ou de défaut, avec cependant le passage en faible vitesse lorsque l'on est à moins de quelques impulsions de l'arrivée.
-Il faut ensuite une vitesse faible, car en poursuite on fait seulement 2 à 5 impulsions au maximum pour atteindre la position suivante (déjà évoqué !).

Cette vision simpliste est pourtant une réalité et le fait de créer des accélérations et décélérations est strictement inutile dans 99% des cas ! Dommage de n'avoir pas été plus pragmatique et d'avoir visé la performance technique qui n'apporte quasiment rien "mea culpa".
Cependant la réalisation est ce qu'elle est et elle doit (et devra) vivre ainsi !

1.4 Sécurités enroulement et limites

L'enroulement catastrophique des câbles et tuyaux, suite à des faits extraordinaires ou panne est quelque chose que j'avais déjà "expérimenté" une fois, mais cela m'a motivé pour ne plus recommencer de telles erreurs !
Aussi il y a sécurité absolue avec des switchs qui coupent l'alimentation des moteurs dans le sens du dépassement de limites, mais qui autorisent le sens opposé pour revenir en arrière.
De simples diodes en // sur les switchs permettent cette gymnastique et surtout le re-départ dans le sens inverse. Je confirme que les switchs standard utilisés en outdoor sont très résistants aux intempéries et que depuis de nombreuses années, je n'ai eu aucun problème de ce type.

Dans le sens EO (azimut), un switch divise l'espace EST/OUEST en deux parties, et fait une référence, si bien que l'on sait toujours dans quelle zone on se trouve (relativement au midi solaire qui est à l'origine 0°). En principe ce sera le sud où les vents dominants d'ouest soufflent sur la tranche du panneau. La référence 0 en azimut (midi solaire) est exactement au basculement de ce switch (toujours dans le même sens).
Ce midi solaire perpendiculaire aux vents dominants d'ouest, sera également la position de repli pour offrir le moins de prise au vent.
Pour la partie montée/descente, ce sera le même principe, mais sans position intermédiaire, aussi on doublera le switch bas pour la partie coupure moteur, par un switch logique qui indiquera position basse du panneau.
Il n'est pas possible de reprendre l'information de sécurité de coupure moteur au niveau logique (switchs de coupure de puissance), car les moteurs ne sont pas alimentés en permanence et lorsqu'ils le sont, c'est en 12V et en tensions parfois inversées et les tensions logiques seraient plus compliquées à établir de ce fait.
Le doublage du switch bas est donc beaucoup plus simple à établir pour assurer les deux fonctions distinctes de logique et de sécurité.
La position basse en référence de position est hautement préférable en cas de grêle par exemple. C'est aussi beaucoup plus facile de manipuler des données toujours positives !!! (0 à 90°)

Dans le cas de vent fort détecté, on assure toujours le mouvement E/O en premier pour limiter la prise au vent, puis on effectue après la descente vers le bas.

J'ai voulu ne pas laisser de composants en externe au CI, mais cela oblige à ramener les diodes en // sur les switchs, sur le CI !
C'est un peu lourd à gérer d'autant que cela pourrait être du fil un peu plus gros en section suivant ce que l'on veut faire… Le mieux serait de faire un petit CI sur chaque switch comportant la diode, mais je n'ai pas eu le courage de le faire, alors … C'est ainsi !

1.5 Batterie, énergie, heures

Il est prévu que le panneau fonctionne directement sur le 12V d'une batterie plomb ou 3 x Li-Ion mais la partie régulation d'énergie du panneau sera totalement indépendante, (Ceci à cause de liaisons de la régulation solaire déjà existantes qui ne sont pas à priori directement référencées au négatif batterie).
Ce fait interdit de faire une mesure de luminosité (Détection du matin) directe à partir du panneau photovoltaïque lui-même pour deux raisons : En repli, le panneau est orienté vers le sud (C'est moins bien que l'Est), et surtout il serait nécessaire de mettre un opto-coupleur pour assurer l'isolation des deux alimentations. C'est à évaluer !

Une cellule photo photorésistance sera donc utilisée pour permettre de détecter le lever du soleil sans avoir à maintenir le processeur en éveil permanent, qui sera seulement réveillé lorsque le niveau d'éclairement sera "suffisant". Une temporisation par vraisemblance d'un nombre de fois de confirmation sera faite pour éviter les oscillations.
Le processeur sera donc en sommeil périodique durant toute la nuit et ne sera réveillé qu'à intervalles très éloignés par le biais de l'ULPWUE, qui surveillera périodiquement le niveau d'éclairement. Il perdra donc sa fonction du Timer 0 affecté à l'heure système. Le maintien du fonctionnement obligerait à gérer les heures de lever (et coucher) du soleil, ce qui représente encore des calculs complémentaires et ne prend pas en compte la réelle luminosité, mais surtout augmente beaucoup la consommation puisque l'on ne sera pas en SLEEP. Ce choix me semble le plus facile et est assez économe en énergie.

Une parenthèse dûe à une erreur de ma part, m'avait empêché d'utiliser véritablement l'ULPWUE. J'avais mis une résistance trop élevée dans le circuit ce qui empêchait le circuit de fonctionner. Je m'étais alors rabattu sur l'INT RB0 pour faire un pseudo ULPW et permettre la mise en sommeil du PIC pour environ 42 secondes. A cet- instant il suffisait alors de vérifier le niveau d'éclairement de la cellule. Si celui-ci est suffisant, on remet alors en fonction le récepteur DCF77 pour se remettre à l'heure et débuter ainsi une nouvelle journée, mais depuis j'ai modifié et remis en ordre cette erreur en utilisant la véritable ULPWUE avec cette fois un condensateur de 22µF qui permet d'atteindre un temps de 18 minutes.

Suite à des problèmes liés à des niveaux indéterminés lors de l'absence d'alimentation d'auxiliaires, j'ai dû encore une fois modifier ces alimentations :
Un switchs MOSFET_P de contrôle de l'alimentation d'auxiliaires est prévu : il commandera seulement l'alimentation du DCF77. Les autres alimentations seront prises directement par des sorties du PIC et permettront d'alimenter séparément chaque capteur HALL des deux moteurs lorsqu'ils seront en rotation, et de compter ainsi les tops, et l'autre alimentera le capteur HALL du détecteur de vent.
Le ventilateur en mesure de vent est alimenté par une simple sortie à 1 logique par RA2. De la même manière les deux capteurs HALL d'impulsions moteurs sont maintenant séparés pour raison d'économie d'énergie et sont alimentés séparément par RA5 et RB5 respectivement pour HB et EO.

La surveillance de lumière sera inutile le jour puisque les équations solaires déterminent l'heure de coucher du soleil. (Angle de hauteur inférieur ou = à 2°) Cette cellule consommera seulement une petite centaine de µA en continu de jour, sauf la nuit. Une surveillance périodique est nécessaire durant la nuit, car dans cette situation le processeur est périodiquement à l'arrêt et le temps n'est plus géré. (Le réveil a lieu toutes les 18 minutes).
La véritable gestion du temps en heures minutes secondes (Temps solaire) n'est réalisée qu'à partir du matin, instant où la luminosité devient suffisante, et immédiatement après, on lance la procédure DCF77 pour avoir l'heure réelle qui restera acquise pour une journée entière.
Bien qu'il soit possible d'ajuster toutes les 4 minutes sur le DCF77, cela ne sera pas fait ainsi, car il y a souvent des difficultés à synchroniser, et le risque est trop important de se trouver sans l'heure réelle ou d'avoir des corrections pas toujours bien gérables suivant l'instant. La réception DCF77 est souvent un problème dont je compte bien m'affranchir ultérieurement…

Les capteurs HALL des moteurs ne sont alimentés, que durant le fonctionnement des moteurs par deux sorties spécifiques du PIC. Il n'y a donc pas d'impulsions parasites possibles en dehors du mouvement. Le rappel initialement prévu au Vcc a dû être repris à la masse, pour fixer les potentiels en l'absence de tension d'alimentation des capteurs HALL

1.6 Vent

Comme pour le "grand frère", mon panneau solaire thermique, (Celui-ci n'ayant pas encore son capteur de vent fort !), la sensibilité au vent doit être prise en compte et c'est à l'aide d'un petit ventilateur 12V modifié que cela a été fait.
C'est suite à un article paru que j'ai démonté et installé ce ventilateur en capteur de vent, mais j'ai malheureusement perdu la trace de l'auteur de ce très intéressant article, mais j'ai trouvé une vidéo dont voici le lien :
https://www.youtube.com/watch?v=uqOEHOTrdho
mais avec un autre type de ventilateur assez différent.

En deux mots, et avec de la chance, il faut sortir le circuit magnétique qui est normalement glissé à force autour d'un canon plastique, mais sans rien casser !
Cette opération chirurgicale est nécessaire pour ne plus avoir les attractions magnétiques qui génèrent un frein très sensible aux faibles vitesses.
On placera un switch à effet HALL ou on réutilisera celui déjà en place qui donnera avec l'aimant concentrique aux pales, les impulsions de vitesse de vent. On modifiera certains appareils qui ont un circuit un peu spécial avec deux résistances et on câblera au mieux avec un strap et une résistance d'open collector de 47K. La constante de temps est voisine de 100µs
Anémomètre_étalonnage.ods (étalonnage ventilateur)
Ce ventilateur sera alimenté par une sortie directe du PIC (RA2).

Les aléas du relevé témoignent de la difficulté d'être précis, mais il faut bien entendu prendre la droite comme modèle.

1.7 ULPWUE

Ce dispositif d'économie d'énergie est utilisé la nuit lorsqu'il n'y a pas de tracking à réaliser. Cela permet d'économiser un peu d'énergie.
Le condensateur de 20µF environ se charge à travers 220 Ohms à un courant maxi de 20mA. La constante de temps est de 4.4ms, donc au bout de 5 téta on a 99% de la charge. Une mesure externe à courant limité à 20mA indique qu'il faudra, pour avoir une charge complète, environ 40 ms que l'on établira à 50 ms par sécurité . La décharge se fera par les circuits de l'ULPWUE à 135 nA à courant constant à 25°C.

Après bien des essais, et la documentation ULPWUE fausse du PIC16F886 pour cela (DS4-1291D), j'ai du me rabattre sur la note AN0879D qui ne fonctionne pas non plus. Après avoir séché par tous les bouts sur ce problème, le bit ULPWUE du registre PCON, ne peut pas être écrit avec le simulateur (simulation non supportée) et à priori pas plus en programme réel. Alors je cale !
* NOTA : la résistance employée était trop élevée, mais je ne l'ai vu que bien après.

Initialement voici ce que j'avais fait à tort : Ayant RBO/INT libre, je me passais du courant constant et je génèrerais une INT qui réveille le PIC… A voir si il est possible de tout combiner sur RBO comme pour RA0, à la seule différence qu'il n'y aura pas de courant constant, mais simplement le trigger de Schmitt de cette entrée. On choisira dans Option_Reg le front descendant de cette INT0.
A essayer !
Voilà c'est fait et ça fonctionne avec la seule I/O RB0, mais si j'avais essayé de mettre la résistance de fuite à 22 Megohm en // sur le condensateur, c'était beaucoup trop, et seulement 2.2 Megohms permettent de fonctionner avec # 22 µF. Si ce n'était pas le cas il faudrait encore diminuer pour permettre aux courants d'échange de passer sous le seuil bas de l'entrée trigger de schmitt.
Alors après cette erreur,  l'ULPWUE officielle fonctionne, mais c'est trop tard Pour le CI qui sera encore modifié ! !
Attention aussi à la température qui pourrait fausser et bloquer le programme.
Le but recherché de consommer le minimum est atteint.

1.8 Signalisation

Il est important de savoir ce qui se passe dans le cœur du programme, car il n'est pas prévu d'affichage permanent des données d'orientation.
Aussi il avait été installé 9 micro-LED (à 100µA) pour indiquer ce qui se passe, avec seulement 2 I/O sur un registre à décalage CD4015. Ce système qui sur le fond est intéressant en termes d'I/O ne présente que peu d'intérêt réel, aussi j'ai supprimé totalement le circuit U3 (4015) que je n'ai jamais réellement utilisé, ainsi que les "LED 3 en 1" (3 petites LED dans un boîtier à 6 pins).

J'ai enlevé les LED et utilisé seulement une seule LED mise directement sur la sortie DCF77, car durant la mise au point en intérieur, j'ai eu des difficultés de réception du DCF77, et une LED directement sur la sortie du récepteur est une aide particulièrement précieuse
Pour la mise au point, et éventuellement le contrôle, il est prévu de surveiller avec la RS232 pour avoir de plus nombreuses informations que les LED ne sauraient donner.
Il avait également été prévu de modifier des valeurs en réception "RX", mais je ne l'ai pas réalisé et cela s'est avéré inutile.
Suite à la modification ci-dessus concernant RB0, j'avais utilisé RA0 pour piloter une LED (rouge) de signalisation à 100µA pour usage de mise au point, car les autres LED, peu utiles cependant, ne sont pas assez discriminables facilement (3 LED groupées dans un seul boîtier) et ne sont là que pour repérer ponctuellement les problèmes en phase réelle de fonctionnement.
En résumé, il n'y a plus que 2 LED, une rouge pour la sortie data du DCF77 et une blanche pour les problèmes logiciel ou hard connectée maintenant sur RB0.
On notera que la LED du DCF77 est éclairée le temps des impulsions DCF et qu'un rappel au Vcc (ou d'un transistor pour inverser le signal) permettrait de "gratouiller" quelques µA/h. Ceci à la condition de ne pas surcharger le module. La LED (rouge pour ne pas trop perdre en niveau logique 1) pourrait être insérée dans la résistance pull-up de l'Open collector du module. C'est ce que je viens de faire, mais attention cela diminue d'autant le niveau 1 logique et la couleur rouge est impérative pour cette raison. Encore une minuscule économie d'énergie !
(Une majorité de modules DCF77 sont en logique négative et le signal actif est à zéro)

1.9 Les 4 Formules solaires

Ce sont les mêmes que pour le panneau solaire thermique, puisque la terre et le soleil sont toujours là !
Teta         Latitude du lieu dans l'hémisphère NORD (toujours positive)
Delta        Déclinaison journalière. Angle calculé seulement une fois par jour séquence "cte_sol"
Omega      Angle horaire centré au midi solaire avec angle négatifs le matin, séquence "angl_hor"
h             Hauteur du soleil depuis l'horizon
a             Azimut Est ou Ouest (Est négatif)
J             Quantième du jour de l'année compté depuis solstice de printemps (80 en principe)

Formules de base utilisées :

Formule 1 (Constante solaire du jour de l'année : déclinaison)
Sin delta= 0.4 * sin (0.986 * (J-80))     (0.4 est le sinus 23.4° ou 0.39714 exactement)

 80 est le jour du solstice de printemps
Formule 2 (Obtention du sinus de la hauteur)
Sin h = sin delta*sin teta + cos omega * cos delta * cos teta

(avec z=90 –H et donc cos z= sin h)
Formule 3 (Obtention du sinus de l'azimut brut non corrigé)
sin a = sin omega * cos delta / cos h
Formule 4 (Correction de l'angle d'azimut)
cos z = sin h = sin delta / sin teta
si cos z < sin delta/sin teta
      alors
         si a   <0  alors a= -180-a
             sinon  a= 180-a
        sinon a n'a pas besoin de correction

ATTENTION :
A utiliser des formules sans faire très attention, j'ai failli supprimer le coefficient 0.986 de la formule 1 qui est en réalité un rapport angulaire en RADIANS. Je m'en suis aperçu en vérifiant sous CALC les erreurs engendrées si on le supprimait !!!
Évidemment les écarts sont assez fantastiques !!! A ne pas faire !
2 Références et sites
SINUS, COSINUS et ARCSINUS ou ARCCOSINUS http://bricolsec.canalblog.com/archives/2011/04/27/20993534.html

Panneau solaire thermique piloté aux équations solaires
http://bricolsec.canalblog.com/archives/2012/01/23/23315672.html

3 Choix des I/O

Bien entendu, les points encore en suspens, comme la cellule par exemple, peuvent modifier ces choix, mais les principales I/O sont maintenant stabilisées !
Après c'est une question d'organisation de programme, de choix d'interruptions et de facilités pour rester le plus simple possible tout en manipulant le moins de variables octets possible pour passer d'une I/O à l'autre. L'organisation est donc choisie pour obtenir le "mieux" et le plus facile.
Les I/O ont beaucoup subit de modifications et sans rentrer dans les détails, le schéma est à jour, mais par opposition le typon est totalement à reprendre ! désolé !

3.1 Relais

Au départ, je comptais bien faire un pont pour attaquer les moteurs (séquentiellement) avec un relais d'inversion de sens pour les moteurs, car les PIC que j'utilise habituellement n'ont pas 2 MLI en full bridge. Alors je me suis résigné à faire au plus simple et mettre un relais de croisement des moteurs E/O ou H/B. Les tops moteurs resteront cependant différentiés ainsi que les paramètres des commandes moteurs.
Quand j'ai commencé le schéma et que j'ai vu ce qui m'attendait pour quelque chose de simple, alors j'ai craqué devant la difficulté mais aussi en rapport à la simplicité.
Je dois rappeler que mon panneau solaire thermique en poursuite est équipé ainsi et que cette partie est bien fiable.
Alors je vais recommencer, mais cette fois avec un plus par une commande MLI avec contrôle de rotation par tops et non plus une commande basée sur le temps de rotation moteur. (Cela aide énormément à la maîtrise des masses en mouvement, mais seulement pour les grands déplacements …du matin et du soir !)

Au final il y aura deux relais inverseurs, l'un pour le choix moteur, et l'autre pour l'inversion du sens. Cela implique des relais avec inverseur double.

Ces relais seront commandés par des I/O standard avec chacun un transistor de commande, car c'est quelques dizaine de mA que ne pourrait supporter une sortie PIC.
Pour la mise au point, il aurait été souhaitable qu'une LED témoigne du collage ou non de chaque relais. C'est presque impératif lors de la mise au point ! J'ai profité d'une autre modification pour réaliser la mise en place de 2 LED sur chaque relais

3.2 DCF77

Ce petit récepteur équipé d'une antenne ferrite sera raccordé par un petit connecteur à 3 pins au pas de 2.54 Il a été placé en sommet du panneau pour bien recevoir le 77 KHz.
Pin 1 GND (côté externe)
Pin 2 Signal (logique négative)
Pin 3 alim + par le MOSFET_P Q4

Cette recherche DCF77 de la date et de l'heure sera faite 1 seule fois par jour dès que le jour se lève, par le biais de la cellule, mais également à toute mise sous tension, dès que les références de position E/O et H/B auront été atteintes.
Le choix de gérer uniquement l'heure solaire est un peu embêtant lors de la mise au point, car un oubli de ce choix est vite fait et un départ vers une "fausse erreur" !!! est vite fait.
Ce choix à ce jour de l'année 2020 est justifié car on ne sait toujours pas quelles seront les décisions Européennes retenues. Ainsi quelques soient ces décisions, on ne sera pas impacté.
On notera que le DCF77 utilisé (Comme une grande majorité) fournit les signaux en mode inversé (5V=0 logique 0V=1 logique)

Suite à une erreur de branchement, et mise HS d'un récepteur, je viens de récupérer les composants : quartz et ferrite et utilisé un circuit U4224B qui donne toute satisfaction et ne consomme que 21 µA et possède en plus une pin POWER_ON. C'est une solution dans ce cas précis, car le quartz 77.5 KHz ne se trouve pas facilement et l'antenne ferrite est déjà toute faite et accordée. Peut-être un article sur ce nouveau circuit ....

3.3 Anémomètre et tension 12V

Le fichier d'étalonnage effectué avec les moyens du bord (photo au §1.6 plus avant) . L'équation approximative est :
f(x) = 0.11x + 0.42 avec f(x) en m/s et x en Hertz ce qui permettra de rentrer en numérique directement sur le timer 1 et d'avoir rapidement une valeur de fréquence et donc de vitesse.
On considèrera que 60 Hz sera la fréquence  qui représente un vent qui n'est pas habituel dans la région et qui témoigne d'un début de coup de vent ou de tempête (soit environ 25 Km/h).

Avant toute commande de position toutes les 4 minutes, on contrôle durant quelques secondes le vent et le reste du temps est une simple attente sur Timer ce qui diminue la "consommation" du ventilateur de quelques mA pour l'alimentation de son capteur HALL.

La tension d'alimentation  de 12V est contrôlée avant toute nouvelle commande de position. Elle a été figée à 9.75V minimum uniquement pour éviter la décharge profonde d'une batterie 12V.

Pour ces deux contrôles, et en cas d'erreur, le panneau sera mis en positions de repli 2 axes et le processeur mis en SLEEP sans possibilité de redémarrage, ce qui obligera à une intervention manuelle.

4 Principes généraux programme

La grande difficulté de l'amateur électronique et programmation est qu'il manque cruellement de machines pour réaliser toute mécanique et qu'il est obligé d'adapter le logiciel en fonction de ses seules ressources de réalisation mécanique. Les choix ne sont pas toujours simples et doivent souvent être compensés par la programmation.

4.1 Moteurs

Le cas le plus criant se situe au niveau des moteurs et de leur commande : Le panneau pèse tout de même une petite dizaine de kilos ? (à vérifier), aussi mettre en mouvement une masse de cette valeur nécessite quelques précautions car le plus dramatique ce sont les jeux inéluctables et les à-coups engendrés, tant au démarrage qu'à l'arrêt.
Je ne dispose que de 2 réducteurs 1/175.5 et d'un renvoi d'angle de rapport 2.71 soit pour E/O (Est/Ouest) une réduction de 1/476.22 alors qu'en H/B (Haut/Bas) ce sera simplement 1/175.5
En E/O le renvoi d'angle d'une petite meuleuse a pas mal de jeu et ne rend pas les commandes faciles.

Lors d'un épisode tempétueux il est utile de pouvoir "replier" le panneau rapidement dans le sens parallèle aux vents dominants.
Le principe retenu pour les 2 mouvements est de travailler en MLI (ou PWM) de façon à démarrer doucement en allant de plus en plus vite jusqu'à la moitié du parcours puis de ralentir pour la deuxième moitié. Chaque paramètre pour chaque mouvement est nécessairement différent du fait des couples à mouvoir ainsi que des rapports des réducteurs qui sont différents.
Les moteurs doivent pouvoir tourner dans les deux sens, et pour simplifier j'ai gardé la solution la plus simple des relais pour croiser les tensions sur les moteurs.
Les moteurs fonctionneront toujours séparément, et là aussi c'est un relais qui fera le choix du moteur à commander.

(Le très ancien panneau solaire thermique lors de sa mise en marche en 1984 s'était enroulé sur les tuyaux et les câbles, car n'ayant pas détecté la fin de course avec des magnéto-résistances...!!!).
Ici il y a des contacts de sécurité sur toutes les extrémités des mouvements. Ces butées sont de simples switchs avec en // une diode qui coupe le mouvement sur la butée mais autorise le mouvement inverse à une tension de diode près.
Pour ne pas exposer ces diodes aux intempéries, je les ai placées sur le circuit imprimé, mais il faut alors rapatrier en aller/retour un courant de petite puissance tout de même, et mettre les sections en conséquence. La connectique n'a pas suivi cela et les petites pins Berg sont mal adaptées (et mal placées!!!) Je pense qu'il aurait été préférable de laisser les diodes directement en // sur les switchs. (Précaution excessive)

Les moteurs sont alimentés en traditionnel 12V non régulé, en MLI par Q3, un transistor darlington ainsi que les 2 relais. Le 12V pourrait être celui de la batterie que le panneau pourrait charger, mais ce n'est pas certain suivant l'utilisation prévue, mais aussi le type de régulation solaire, alors ce 12V peut être issu d'ailleurs…
Dans le cas présent, c'est simplement 3 bâtons accumulateurs lithium 18650 qui assurent le pilotage (tracking). (Ma régulation solaire existante semble ne pas avoir de référence au zéro Volt ?! dommage !)

Le contrôle de position par rapport au soleil se fera, toutes les 4 minutes, car c'est amplement suffisant, du fait que ce sera seulement quelques degrés de variation.

La référence initiale pour les deux mouvements est assurée par deux switchs.
Pour E/O, c'est la position médiane SUD qui est retenue et qui lutte efficacement contre les vents d'OUEST.
Pour E/O c'est la position basse (Panneau vertical) qui est retenue et qui évite la grêle éventuelle en cas d'orage. (Ce positionnement bas logique est légèrement en avance sur le switch de coupure moteur)

Le non cumul des erreurs de positionnement est assuré ainsi : chaque nouvelle valeur d'angle est calculée en nombre de pas, puis la valeur précédente de position en pas lui est retranchée, et la différence représente alors la valeur en nombre de pas du prochain mouvement.

4.2 Consommations et fonctionnement

La consommation de l'électronique de positionnement est un point important car si le panneau peut donner 12W sous un courant de 0.686A, il est important que le circuit de tracking reste économe, aussi la nuit lorsqu'il n'y a plus de soleil, le panneau devra être replié, puis le processeur sera mis en sommeil (SLEEP) et ne sera réveillé que par une cellule spécifique (qui ne sera PAS le panneau photovoltaïque lui-même pour un problème électrique de masse non commune).
A cet instant, toutes les 8 minutes, l'ULPWUE réveillera le PIC, et si l'éclairement reste faible, relancera l'ULPWUE pour 8 nouvelles minutes.
Dans le cas contraire, si l'éclairement est suffisant, (lever du soleil) on mettra à l'heure l'horloge du processeur par le DCF77, ce qui permettra le positionnement à l'aide des équations solaires.
Le DCF77 a une alimentation unique par un MOSFET_P.

La tension d'alimentation du circuit sera contrôlée au cours du fonctionnement de la journée (Mais pas en début de journée), et en cas de faiblesse, le panneau sera mis en position de repli. Cette tension sera également moyennée 4 fois toutes les 4 minutes à fin que la batterie ne descende jamais en dessous de 9.75V (ou 0xAC 8 bits de précision).

Les différents organes sont mis sous tension à la demande pour limiter la consommation : DCF77 (Une fois le matin au réveil) et toutes les 4 min. pour le vent, Les relais, gros consommateurs, sont toujours mis au repos après un mouvement (Moteur E/O et sens OUEST par défaut)

Chaque capteurs HALL de moteur n'est alimenté, qu'en cas de lancement d'une commande du moteur, car c'est encore 7 à 10 mA de réduction de consommation. Après vérification j'ai pu vérifier qu'une sortie PIC est capable d'alimenter directement  pour 7mA ces capteurs HALL. Les MOSFET_P prévus d'origine ont donc été supprimés (De même pour le capteur de vent).

La mise au point a nécessité d'utiliser la RS232 pour mettre au point le programme. Un strap sur pins permet d'alimenter une RS232 ou radio de contrôle éventuelle. Ce strap permet l'alimentation  de la RS232 et est contrôlé par RC1 qui permet de sauter les séquences RS232 inutiles en fonctionnement établi.

Voici le tableau des mouvements car avec toutes ces commutations, on a vite fait de ne plus savoir ce que l'on fait ou que l'on a oublié…

Directions et Cdes    OUEST  EST  MONTÉE   DESCENTE
PORTC3 Choix Mot        0     0     1         1
PORTC4 Sens             0     1     0         1

4.3 Capteurs ANA

Le contrôle de la tension de 12V est réalisé sur PORTA RA2 et on contrôlera que l'on ne descend pas en dessous de 9.75 V comme pour une batterie de 12V au Plomb. Ceci correspondra en fonction du pont de résistances 18K /8.2K ou AC hexa sur 8 Bits. (ADFM=0)

La cellule photoélectrique est mesurée sur PORTA RA3. Elle est installée directement sur le CI, mais le connecteur J14 permettra de la placer ailleurs si nécessaire.

C'est une cellule photo résistance cds et suivant son montage direct, il ne sera pas possible d'avoir une précision fantastique. Je n'ai d'ailleurs pas pu faire un étalonnage sérieux avec un luxmètre tant les valeurs sont difficiles à stabiliser. C'est une courbe d'allure logarithmique (voir ci-après courbe d'une photodiode de caractéristique sensibilité proche ).
Les valeurs en Lux de seuils sont de l'ordre de 1000 à 2000 Lux.

Dès que la cellule reçoit un peu de lumière, la tension récupérée descend très vite vers 0.1 ou 0.2V. Il semble qu'environ 4V corresponde à un éclairement de début de jour. (Ce sera peut être à ajuster), mais plusieurs mesures devront le confirmer pour éviter des parasites lumineux (phares de voiture…etc).
On évitera aussi l'exposition directe vers le ciel à cause de la pleine lune possible. Le nombre de pas à comparer sera de l'ordre de 800 et tout ce qui est inférieur à cette valeur indiquera le début du jour.

La mise au point a permis de mettre en évidence la nécessité de masquer par un cache à microperforations pour diminuer la trop forte sensibilité .


5 Organigrammes

Outre le fait que de nombreux sous programmes mathématiques font le cœur de ce programme, pour la simple raison que multiplier 2 nombres de 8 bits est beaucoup plus simple que de multiplier deux nombres de 16 bits. Aussi chaque opération particulière aura son type de calcul.
Les nombres décimaux sont transformés en nombres entiers par multiplication pour pouvoir être traités comme des nombres entiers, qui seuls sont assimilables par le processeur. Une division finale ou plus simplement un positionnement de la virgule rétablira la réalité du nombre.

L'organigramme ne fait donc pas la distinction complète des calculs mais représente seulement la fonction réalisée.

Voici les organigrammes, avec en premier l'organigramme principal qui résume le passage en SLEEP du processeur et son réveil par la luminosité ambiante qui croit avec l'aube et la poursuite du soleil tout au long de la journée par pas de 4 minutes.

On pourra voir que la déclinaison du jour est faite... une seule fois par jour (case "constantes journalières"). Cela reste approché tout de même car la déclinaison se poursuit au long des heures, minutes et secondes du jour, mais de façon très faible, ce qui explique que ce calcul n'est fait qu'une fois par 24 heures et que cette approximation est encore beaucoup plus faible que bien des arrondis ou manques de décimales.

Le deuxième organigramme représente le principe de la MLI qui assure une accélération jusqu'à moitié des impulsions prévues, puis enclenche la décélération jusqu'au point où le décomptage d'impulsions passe à zéro.

Ainsi que cela sera un peu développé ci-après, ce principe s'il est très bien pour éliminer les à-coups dus à l'inertie, reste bien compliqué pour ne servir que DEUX fois par jours !

Je m'explique :
Tous les mouvements au cours d'une journée sont seulement de quelques impulsions, pour compenser les quelques degrés de variation toutes les 4 minutes. Dans cette situation, les accélérations restent quasi nulles. Les seuls instants sont le début et la fin de journée pour le départ et le retour à la position de repli.

NOTA : Pour voir en grand ces organigrammes faire clic droit et "affichage dans une nouvelle fenêtre ou un autre onglet".


6 Schéma complet

La commande d'alimentation du DCF77 est seule réalisée par un MOSFET_P de faible puissance. Les autres alimentations sont maintenant réalisées directement à partir de sorties du PIC qui peuvent fournir sans problème les 7 mA des capteurs HALL pour les impulsions moteur ainsi que le capteur de vent.
La MLI de puissance est fournie par un BDX53B, ce qui est largement dimensionné.

Une "petite folie" avait consisté à utiliser des LED triples, très petites pour signaler des éléments importants, mais je ne crois pas que ce soit une très bonne idée, car celles-ci sont mal placées, trop fines et la mise au point se fait essentiellement en RS232 beaucoup plus adaptable pour visualiser la recherche des problèmes. Précédemment une seule LED de présence 5V était allumée en permanence pour quelque centaines de µA ce qui était tout de même assez "discret".
Cela ne me paraissait pas nécessaire aussi j'ai préféré modifier

cette fonction en la reportant directement sur le DCF77, car suivant les endroits de la maison, le signal DCF passe mal et comme c'est le principe même qui est en cause, alors cela m'a paru plus utile et moins gourmand en énergie, si toutes fois 100µA est une gourmandise !!! Toute la partie visualisation est réduite maintenant à 2 LED déjà décrites.

7 Réalisation

ATTENTION ce circuit est juste pour information car il n'est plus à jour !

La réalisation se fera sur un circuit imprimé placé à proximité immédiate du panneau sur la partie fixe de l'axe. Tous les éléments techniques tels que les capteurs, les moteurs seront regroupés sur plusieurs connecteurs d'entrée situés sur le circuit imprimé. (Connecteur type Berg au pas de 2.54 )
L'énergie de l'électronique de tracking sera fournie par une batterie (Li-Ion (ou plomb)) avec le négatif à la masse . Cependant la régulation solaire d'énergie pour la charge d'autres batteries ou utilisations sera totalement indépendante, aussi le négatif de régulation ne devra jamais être mis à la masse (ou utilisé comme commun).
L'énergie du panneau sera gérée avec la régulation (livrée avec le panneau), avec en projet en "futur très lointain", une régulation MPPT...

Les moteurs ne consomment qu'une petite centaine de mA moyens, voire moins et durant de très courtes périodes.
Ceci devrait donner un rendement beaucoup plus intéressant relativement à un panneau en position fixe, et c'est le seul but du tracking, d'augmenter de façon significative l'énergie récupérée.

Ce tracking pour un panneau de petites dimensions est prévu pour être adaptable aux plus grands panneaux. Les rapports de réduction des moto réducteurs sont paramétrables ce qui permettrait la généralisation du système quelques soient les dimensions.

Vous pourrez largement critiquer ce sujet car, effectivement j'aurais hautement préféré avoir des réducteurs appropriés et simplifier largement cet ensemble, mais c'est ainsi lorsque l'on fait avec les moyens du bord.

8 Conclusions

Encore faut-il pouvoir stocker cette énergie électrique reçue, car on en a pas besoin tout le temps au fil d'une journée, et c'est certainement là le plus gros problème, car l'énergie ne se stocke pas facilement, et en tous cas pas sans d'importantes pertes !

Concernant ce problème de l'utilisation (de 12W de puissance), j'ai pensé connecter de petits appareils qui sont en permanence sous tension comme mon modem ADSL ou une petite pompe de circulation du chauffage central.
Encore faut-il qu'il n'y ait pas de nécessité de refaire une conversion d'énergie, et que l'on puisse utiliser le 12V directement, car toute nouvelle conversion, si bonne soit-elle a un rendement qui obérera l'utilité de ce très petit panneau.

Certes un tel panneau même en tracking représente une goutte d'eau dans la mer, mais c'est un prototype, et c'est ainsi lorsque l'on est devant une réalité que l'on peut se projeter dans le futur et évaluer le bénéfice réel de tels dispositifs, à plus grande échelle.

Faut-il mutualiser l'énergie ? La revendre à ceux qui en ont besoin quand le soleil est présent ? Et pour nous usagers payer notre fournisseur habituel lorsque la nuit arrive ?

Beaucoup de questions sans véritables réponses se posent mais de tels essais restent utiles pour bien appréhender ce que l'on peut faire ou espérer.

D'autre part un nombre important de panneaux peuvent être commandés par un seul dispositif et des groupements de panneaux peuvent mécaniquement être solidaires et obéir à un unique dispositif de commande d'orientation.

Je pense aussi qu'il y a (Peut-être) moyen de simplifier encore le dispositif en utilisant une monture équatoriale qui ne nécessite qu'une seule commande horaire mais j'ai de très gros doutes sur l'opportunité de cette simplification. En effet la commande de déclinaison peut être rectifiée manuellement et journellement ou encore moins si nécessaire avec une intervention manuelle hebdomadaire seulement, mais cela me parait dommage de ne traiter que la moitié d'un automatisme.

Cette façon de faire ne semble d'ailleurs jamais utilisée en production d'énergie ?, mais seulement en astronomie.
Le problème de tous ces groupements de panneaux sera de collecter les rayonnements d'ouverture d'EST en OUEST, car les dispositifs pourraient certainement se masquer mutuellement, mais là c'est l'industrialisation, et de plus, à ces angles d'ouverture, l'énergie disponible reste faible, alors le bilan énergétique pourrait même être négatif ?
Je pense que sur 120 à 150 ° angulaire d'ouverture on récupère réellement une bonne quantité d'énergie, et les panneaux en terrasse sont une bonne solution qui évite ces problèmes comme à Odeillo.

En ce qui concerne l'énergie nécessaire à cette orientation ... je pense que la création d'une horloge séparée du PIC avec un DS1307 par exemple, qui ne consomme que quelques dizaines de µA en veille serait une bonne idée qui éviterait les problèmes de transmission DCF77 et qui de plus fonctionnerait 10 ou 15 ans. Seul problème utiliser la lecture I2C depuis les programmes. Il faudrait aussi obtenir des modules temps réel préprogrammé au jour et à l'heure.

Cette programmation de modules existe déjà au niveau achat, mais avec un surcoût assez élevé, mais je crois que vu les quelques problèmes de DCF77, mais surtout le maintien de l'heure hors tension, ce dispositif me parait très intéressant... Je réfléchis à un programmateur I2C pour DS1307, et à la future utilisation d'une Tiny RTC, car ce n'est pas la première fois que ce problème du maintien de l'heure se pose pour faire des économies d'énergie. (Cette réalisation ne sera cependant pas mise à jour avec ce système)

A ce jour le sujet semble stabilisé et le positionnement est bien à 1 ou 2 degrés près, ce qui au vu des choix initiaux me parait bien.

9 Si c'était à refaire…

9.1 Ce qui est bien

Les relais sont très bien et simples pour l'emploi considéré. Il faut leurs adjoindre des LED témoins
La MLI fonctionne correctement et évite les à-coups mais c'est une complexité importante avec la variation de vitesse
Le PIC16F886 est un choix très confortable qui autorise d'éventuelles évolutions.
La commande par MOSFET_P du DCF77 est efficace et réduit un peu la consommation (2 minutes maxi à 7 mA)
La commande d'alimentation à partir d'une sortie PIC pour 7mA fonctionne parfaitement
Les économies d'énergie en général et la nuit avec l'ULPWUE est bien.
Le DCF77 et les calculs angulaires en fonction du jour et de l'heure sont précis à 1 ou 2 degrés.
LED sur le signal inversé du DCF77, (mais à inverser pour économie d'énergie).
Le contrôle de rotation des moteurs par des switchs HALL permet un bon positionnement
Les switchs de limite et de contrôle de position initiale (Fiabilité déjà vérifiée)
La mise en marche par l'éclairement réel et l'arrêt sur l'heure de coucher du soleil sont assez "moyens" pour la mise en marche
La connectique ICSP bien que non utilisée sera utile pour un PIC SOIC28.
Le positionnement tout au long d'une journée est de l'ordre de +-2° ce qui me parait très bien avec des jeux mécaniques de 5 à 7 degrés ! (J'ai dû insérer un ressort de rappel en E/O)

9.2 Ce qui serait à revoir

Séparer alimentation DCF77 et alimentation Ventilateur (vitesse du vent) avec sortie PIC (fait)
Supprimer les LED triples, et le CD4015 qui sont peu utiles (fait)
Mettre des LED sur chaque relais (en // sur bobine) (fait)
Une LED de visu directe DCF77 (Fait à ce jour et modifié pour allumage inverse)
Placer les LED en face avant (Fait)
Connectique moteur fragile sur pin Berg pour les limites à cause de la section des fils.
Refaire un design complet du circuit et inclure les diodes près des switchs de fin de course.
Supprimer la partie RX qui ne sert à rien au réel.
Trouver des petits moto-réducteurs à coupler sur les réducteurs épicycloïdaux (SOMFY)
Essayer d'avoir des réducteurs identiques pour simplifier le programme.
Fixer le potentiel des entrées non utilisées
Ajouter un switch de repli manuel.
A voir peut être pour placer l'électronique sur l'arrière de la barre transversale pour plus d'accessibilité. NON !
Voir très certainement la partie étanchéité du montage au fil du temps et des tempêtes car les CMOS demandent très peu de courant et des commandes erratiques avec l'humidité sont toujours possibles.
Utiliser réellement l'ULPWUE au lieu de l'INT sur RB0 (fait)
Avec un DS1307 traiter le lever du soleil par les équations solaires avec le temps maintenu par ce circuit. (Ne sera pas fait car trop de modifs!)

10 Problèmes rencontrés

Un des gros soucis est de couper la tension d'alimentation sur les capteurs d'impulsions. Quelques soit le rappel +ou -des liaisons "signal" des capteurs à effet Hall des moteurs, les liaisons HB et EO peuvent produire des erreurs de positionnement. Plusieurs bugs ont eu cette action et la mécanique avec jeu présente un réel défi.
Ce point précédent des sorties de composants non alimentés a été mal appréhendé, car couper une tension d'alimentation peut laisser des entrées PIC en flottant ou à un niveau non souhaité ou au contraire permettre de réalimenter par des I/O et c'est un point à surveiller.
Il y a aussi la possibilité de l'inertie qui peut fausser les interprétations.
Les erreurs de positionnement HB et EO ont été revues et corrigées à plusieurs endroits.

J'ai aussi eu un gros problème de blocage de la MLI par le fait que tous les registres liés à CCPR1 ne soient pas remis à zéro. A priori ce serait TMR2 avec reprise de la dernière valeur, soit Zéro ce qui causait un blocage en fin de jour.

Les rappels des capteurs HALL moteur ont été mis à la masse pour qu'ils ne soient pas "en l'air" et cela semble donner satisfaction. (C'est le problème des éléments hors tension qui restent connectés)

Lors des mesures de courant, la RS232 de contrôle utilisée à l'aide d'un câble FTDI induit une consommation de plusieurs mA supplémentaires lorsque l'ordinateur d'enregistrement des valeurs est à l'arrêt. Cela ne correspondait plus au courant de repos en SLEEP. C'est la réalimentation par le biais d'entrées !

Enfin le fait que le programme ait été mis au point avec 2 PIC (en bascule de l'un à l'autre) ainsi qu'en simulation, m'a donné pas mal de soucis. J'ai trouvé un des PIC qui fonctionnait mal, c'est très rare, et la situation après des modifs était souvent incompréhensible !.
On ne comptabilisera pas les erreurs banales de branchements ni une ou deux bavures de soudure. Il y a aussi le fait que dans ces applications à durée longue, il est difficile de reproduire les erreurs entrevues, ce qui n'est pas le cas dans des applications purement électroniques où la rapidité est de l'ordre de la fraction de seconde ou moins.
Tout ceci étant dit on comprendra mieux le temps nécessaire, d'autant qu'il n'y a pas que cela à faire mais aussi le "tous les jours habituel"...

Ce 27 Décembre 2020, je viens de rencontrer un nouveau problème, sans conséquence dans l'immédiat, mais qu'il faudrait traiter... En E/O, lors de coups de vents importants, il peut y avoir réversibilité du réducteur, ou lors d'une manipulation du panneau en forçant. Dans ce cas je me suis aperçu que le moteur E/O devenait générateur (car sans aucune batterie, les 2 LED s'allumaient en forçant sur le panneau !)
J'ai été très surpris il va sans dire. Il faudra donc ajouter une diode Schottky dans la ligne d'alimentation + des relais moteur. Cela me semble important tout de même, car la tension pourrait dépasser les 5V sans aucune limitation possible et faire quelques dégâts !

Faire mieux est toujours possible à l'amateur, mais à un moment donné, il faut savoir arrêter…

bricolsec