PANNEAU SOLAIRE THERMIQUE piloté
aux équations solaires papilot6r PIC 16F

1 Principales caractéristiques
2 Les grands principes
2.1 Les modifications du panneau
2.2 La modification de la partie électronique
2.3 Le temps et la rotation de la terre
3 La carte avec PIC 16F886
3.1 CI principal
3.2 Schémas
3.3 L'entrée anémomètre
3.4 L'entrée grêle
3.5 La RS232 et la Radio
3.6 Les switchs poussoirs
3.7 Le DCF77
4 Paramètres programme (Menu paramétrage)
5 Commandes disponibles
6 Automatismes
7 Affichages
7.1 Autres affichages et LED
7.2 Variables, particularités
8 Fonctions SINUS / COSINUS et Arcsinus
9 Quelques consommations d'énergie
10 Le DCF77 et l'affichage LCD
11 Les essais du PORT RB
12 Pourquoi calculer en permanence ?
12.1 La fréquence du calcul azimut et hauteur
13 Temps de fonctionnement Moteurs
14 Les calculs "astronomiques" et quelques astuces
14.1 Le système solaire et les équations
14.2 Dénominations des variables solaires et équations
15 Trucs sur MPLAB
16 Conclusions
17 Annexes

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 ----->

Les questions correctes en fin d'un article recevront toujours une réponse, mais pas les questions par "CONTACTER L'AUTEUR" qui n'auront pas de REPONSE (car je suis obligé de répondre par mail).

A voir aussi  en colonne de droite (lien direct) ------> les articles "BONJOUR" ainsi que "INFOS rapides"...
Il est déconseillé d'indiquer dans les commentaires ses coordonnées (mail, adresse ou téléphone).
Ce blog est modéré et vous pouvez demander simplement en tête de question à ce que vos informations restent confidentielles si nécessaire. Rien ne sera publié, mais ma réponse sera faite sur l'article correspondant (et non par mail).


 Avant propos

Ce nouvel article, tout comme la "régulation solaire nouvelle génération du chauffe eau", fait partie de mon projet d'ensemble "solaire". (Voir l'ensemble des liens en fin d'avant-propos)

Le chauffage de l'eau par le soleil me semble une évidence incontournable pour réaliser des économies d'énergie, car c'est effectivement un procédé simple et à la portée de tout un chacun, particuliers en pavillon, Syndic d'immeuble et HLM, et même des usines désireuses d'investir pour l'avenir.

Je pense que le confort de l'eau chaude doit nécessairement passer par le chauffage solaire de l'eau sanitaire.
L'eau chaude sera en chauffage direct dans les régions le permettant, ou en PRÉ-chauffage dans les régions moins favorisées, comme dans l'Est de la France où je suis avec appoint de chaudière (ou électrique, mais c'est dommage !).

Je crois qu'il faut dire aussi, en ces périodes de crise, que l'énergie est une denrée extrêmement précieuse, et que l'énergie fossile bon marché représente une période révolue, car on a maintenant conscience que les ressources fossiles s'épuisent.
Les marchés financiers ne peuvent contenir cette pression inéluctable du coût et il faudra des solutions d'économies pour demain ainsi que des modifications de nos habitudes.
Économies en tous genres, tant dans l'énergie que dans les matières premières car ces dernières sont toutes aussi pour une très grande part, élaborées grâce à l'énergie fossile, et sont elles-mêmes épuisables.
(Les matières premières sont en quelque sorte précieuses au carré !)
Ceci signifie aussi que nous entrons dans une ère où chaque chose a une réelle valeur intrinsèque mais aussi énergétique de fabrication.

Voir l'article Pétrole énergie défaillante 

voir aussi : Énergie, Société, commerce et Nucléaire

L'eau chaude solaire individuelle est facile à produire avec une très faible énergie auxiliaire, relativement à l'énergie recueillie. (Régulation, pompe, pilotage…)

Pourquoi cette réalisation si particulière d'un panneau solaire thermique qui suit le soleil ?

Cette réalisation est la remise à niveau technique d'un panneau mobile en poursuite du soleil dont l'origine remonte à 1981, date du permis de construire de cet équipement mobile. Il y a donc 30 années de recul et d'expériences diverses à ce jour.

A l'origine, le toit de la maison n'est pas orienté de façon correcte pour cause de contraintes de placement dans le terrain, aussi la solution (La moins mauvaise) consistait à mettre un panneau au sol, en terrasse et comme la vue d'un panneau solaire n'a rien de poétique, il a été nécessaire de réduire sa surface au strict minimum soit 2 M² pour 150 litres d'eau chaude solaire. (200 litres à ce jour suite au chauffe eau d'origine percé !)

Les premiers temps ont été laborieux, avec une électronique analogique et des cellules,  le tout embarqué sur le panneau lui-même…Bref reportez vous à l'article initial, et aux photos en ANNEXES en Fin d'article, car les araignées, les oiseaux et "autres" (Dont mon inexpérience du sujet) ont fait quelques dégâts. C'est l'expérience du terrain, qui s'acquiert au fil du temps !!!

En 2006, enfin de retour sur place après 10 années d'abandon de l'habitation suite à un changement de travail, j'ai repris en urgence le pilotage sur une base logique par le calcul de position avec les équations solaires.
Qui dit calculs astronomiques, dit calculateur, alors quoi de plus facile et rapide qu'un PC et en langage évolué PASCAL pour aboutir rapidement, avec le port // LPT ?
Ce programme en langage évolué de 1700 lignes et ce principe ont donné satisfaction, mais avec quelques petits ennuis dus à la vétusté du matériel (Alimentation à découpage du PC qui rend l'âme) et surtout des lecteurs de disquettes 3"1/2 qui se fatiguent et qui deviennent de plus en plus rares et qui ne sont pas toujours tous compatibles.
De plus ce petit PC (PSE30 disquettes seulement) ne pouvait démarrer automatiquement sans intervention pour la date (Panne d'origine mais batterie de sauvegarde OK). Il consommait surtout un peu trop à mon goût, environ 35 à 45 W sans l'écran.

Alors pour régler définitivement (Ou presque, car rien n'est jamais acquis), j'ai décidé de remplacer ce PC par un micro contrôleur PIC en 2011. Je suis parti sur la base de l'installation existante, principalement pour la partie puissance et moteurs et c'est donc l'objet de cet article.

Remplacer 35 à 45 Watts par 2 W est un réel progrès, car un rapport de 20 est conséquent.
De plus, au niveau ergonomie, il était nécessaire que toute personne "non initiée" puisse utiliser cet équipement sans avoir obtenu un diplôme de "maternelle supérieure" ! C'est maintenant possible !

L'équipement est donc entièrement automatique, et pourrait être laissé en permanence sous tension, et sera capable de se mettre en sécurité lors de phénomènes météorologiques dangereux (Vent, grêle). Ces sécurités ne seront mises en place qu'au printemps à cause de la nécessité de reprendre un peu de câblage en extérieur.

Le plus important étant certainement l'économie d'énergie réalisée et l'opérabilité améliorée.

Cet article fait également référence à plusieurs autres articles qui traitent de sujets adjacents et complémentaires :

- Eau chaude solaire en poursuite du soleil : la base de départ
 http://bricolsec.canalblog.com/archives/2007/08/09/5847814.html

- Régulation solaire nouvelle génération
http://bricolsec.canalblog.com/archives/2011/03/22/20699575.html

- Mesures sur un panneau solaire thermique
http://bricolsec.canalblog.com/archives/2010/05/28/18032299.html

- Anémomètre
http://bricolsec.canalblog.com/archives/2011/05/28/21248056.html

- Détecteur de grêle
http://bricolsec.canalblog.com/archives/2012/01/17/23269277.html

- Modifier un afficheur LCD // en série
http://bricolsec.canalblog.com/archives/2011/06/30/21517872.html

- Sinus et cosinus et arcsinus en assembleur PIC
http://bricolsec.canalblog.com/archives/2011/04/27/20993534.html

Ce nouvel équipement avec micro contrôleur est logé dans le coffret de puissance existant, partiellement à la place des amplificateurs de magnétorésistances qui ont été retirés. Ce nouvel équipement est si peu encombrant qu'il tient même dans la porte du coffret !

Vous n'aurez pas la chance d'avoir des plans "corrects" de la "partie puissance qui date un peu". (Le schéma actuel est par contre à jour, ainsi que le plan du CI. (Les zones de masse restent à ajouter))
La partie Puissance a cependant fait ses preuves, et je me suis donc adapté à l'existant pour ne pas tout reprendre, et surtout éviter de la mécanique complémentaire dont j'ai horreur, car trop peu équipé en ce domaine.

1 Principales caractéristiques

- PIC 16F886 à 20MHZ choisi à cause des nombreux calculs "astronomiques" et du nombre d'E/S nécessaires
- Régulateur 5V LP2950 retenu pour économie de courant (LED à 7.4 mA)
-  2 voyants existants et reconduits avec ajout de 6 autres
- Clignotement rapide voyant RUN de jour et lent la nuit
- DCF77 appelé tous les jours à 4 heures (APRÈS les heures de changements été/hiver)
- Passage automatique heures été / hiver issu du DCF77 ou entré en paramètre au clavier.
- Années bissextiles traitées par le calcul
- Heure Interne System calée sur l'heure solaire.
- Entrées des heures et affichage en heures légales
- DISPLAY Série utilisé (suivant schéma bricolsec)
- RS232 utilisée en contrôle à distance par radio (émission seule)
- RS232 et radio alimentés séparément par un switch au panel (Anciennement Sync)
  (Réception non implémentée)
- Alimentation 12V 100mA maxi pour l'ensemble
- Résolution en temps angulaire de 12 secondes et 5/100 de degré
- Deux capteurs de position logique de repli (souvent appelés à tort Fins de course)
- Quatre micro-switchs de coupure puissance en limites extrêmes de fins de course.
- Trois boutons poussoirs au panneau de commande pour le repli immédiat, la reprise au vol et la modification des paramètres.
- Entrée logique pour anémomètre
- Entrée logique pour détecteur de grêle
- Deux E/S encore disponibles
- Possibilité de manœuvre manuelle ou automatique (comme précédemment)
- Ajout d'une position de nettoyage de la vitre lors de la pluie en position de repli (paramétrable)
- Grand nombre de paramètres calculés de manière généraliste pour les deux hémisphères (un basculement dans l'hémisphère SUD serait facile à réaliser).

2 Les grands principes

De quoi s'agit-il ? Il s'agit de piloter un panneau solaire thermique de 2 M² avec un PIC 16 F886, mais tout PIC convient si on n'a pas besoin de trop d'entrées. Il n'y a aucune entrée analogique utilisée et un PIC 16F873 pourrait aussi bien convenir. Un PIC 16F628 pourrait même éventuellement convenir si on abandonne quelques signaux. –à voir-.

La version précédente de pilotage du panneau solaire fonctionnait avec un PC ayant un simple lecteur de disquettes, et l'ensemble arrive en fin de vie… Pensez donc un Ordi EPSON PSE30 qui date au moins de 20 années mais qui rendait toujours le service !!!
Après avoir eu une alim grillée et réimplanté une alim réparée n'ayant pas le signal de démarrage qu'il a fallu recréer, ce PC fonctionne encore, mais je ne pourrai plus le maintenir en l'état à la prochaine nouvelle panne.

Alors, comme c'était prévu, je suis "passé" comme je l'espérais avec un PIC et un programme assembleur.
J'ai espéré car c'était un gros travail en langage assembleur, mais c'est gagné à 99,9% à l'heure actuelle, car il ne reste plus que les éventuels derniers petits bugs qui ne remettent pas en cause la structure même.
Autant dire que c'est la fin, car l'ensemble est en essais réels !

La RS232 et la radio n'est pas impérative, mais elle me permet dans les premières journées d'essais de vérifier à distance si le fonctionnement est correct, et de surveiller de temps à autre, des valeurs pour les années bissextiles, les changements d'horaires, les équinoxes… Bref, tout ce qui peut arriver dans les cas particuliers aux limites.
Naturellement ces cas sont en principe vérifiés en statique, mais je confirme que des erreurs subsistent toujours dans ces programmes assembleur et ne gênent pas dans 99% des cas, mais elles sont tapies et prêtes à se déclarer dans un autre environnement ! 

Alors quoi de révolutionnaire ?  Rien réellement mais beaucoup de travail et 8 mois représentant environ 1700 heures de programmation et à ce jour 8777 lignes de programme pour 5155 octets de programme.
La partie hardware est relativement simple et nécessite seulement une bonne quinzaine de jours de conception, montage et essais sommaires en plus.

Alors ce montage va remplacer l'ancien PC trop gourmand en énergie  35 à 45 W et n'aura une puissance que de 1 à 2 watts !
Le plus grand défi est certainement de travailler en assembleur et de manipuler des nombres sur 24 et 32 bits, avec des opérations signées qui ne sont pas en séquence et avec des signes à "reprendre" sans arrêt.
Les problèmes de précision sont également importants, non pour l'application elle-même, car c'est le cosinus de l'angle de la normale au panneau avec la direction du soleil qui dirige la puissance thermique reçue. A ces faibles valeurs angulaires, la surface vraie varie très très peu.
Mais cette précision est surtout importante pour ne pas cumuler les erreurs tout au long de la chaîne de calcul réalisée sur une journée complète.

La carte avec le PIC est placée dans la porte du coffret de puissance qui deviendra alors le seul boîtier de commande du panneau solaire.

2.1 Les modifications du pannefig_P3au

J'avais à l'origine des butées LOGIQUES Est/Ouest Haut et Bas. J'avais même des capteurs de tops avec magnétorésistances et amplificateurs correspondants sur les deux couronnes dentées…

C'est un luxe inutile et cela avait été abandonné aussi, y compris dans la version PC, car le lien avec les équations solaire reste délicat à cause des différents problèmes de précision des calculs, des jeux mécaniques et de la difficulté des calculs en assembleur.
Trouver des solutions simples est souvent difficile et résulte des échecs rencontrés suite à des visions plus compliquées. Ça a été le cas !

Tout cela est donc largement amendé par l'expérience. Il suffit d'avoir un contact au niveau de la position de repli Est/Ouest pour lutter contre les vents dominants en azimut, et d'un contact bas pour la hauteur pour éviter la grêle par exemple, cela donnant les deux références dont a absolument besoin.

Ces deux seuls contacts sont la base de tous les calculs de positonnement

Nota : Le capteur repli E/O est maintenant un simple switch à galet qui remplace la magnétorésistance sur la photo ci-dessus.

Mais alors les araignées et les petites bêtes des champs ne vont plus pouvoir faire des "farces" et enrouler les tuyaux ? Non, puisqu'il n'y a plus de capteurs optiques et autres capteurs délicats, mais on gardera les switchs de coupure PUISSANCE aux 4 limites azimut et hauteur. Cette précaution est vitale et ne peut souffrir de remise en question, surtout avec la suppression des autres capteurs.
(En complément, je rappelle que les dents inutiles des couronnes dentées d'entraînement avaient été meulées et que je considère cela comme "la toute première des premières" protections.)

Les positions précises seront calculées par le PIC à partir des positions initiales de repli, (EST/OUEST et HAUT/BAS) et sur la seule base d'un temps moteur pour le dépassement d'un certain angle relativement à la précédente position. (Résolution angupilot12laire)

A ce jour, et sur ce sujet, je concède très volontiers que des petits moteurs à courant continu, ne sont pas des modèles de précision en vitesse de rotation et donc en positionnement (Principalement avec la température, photo ci-contre).

Mais je ne veux pas tout reprendre, car c'est trop de travail. J'avais trouvé il y a quelques années des petits moteurs asynchrones 48V à double sens, et ils auraient certainement fait merveille.  (3 fils et condensateur). L'ennui est qu'il faut refaire de la mécanique ainsi que la partie puissance, alpilot8ors je jette l'éponge !

En résumé 4 switchs de coupure de puissance moteur aux extrêmes et deux switchs logiques de position repli E/O (position médiane) et Bas sont les seuls éléments qui constituent les capteurs du panneau.

Nota 1 : En butée, les switchs s'ouvrent avec une diode en // et en inverse qui accepte donc seulement l'autre sens.
Nota 2 : Lorsque l'on parle "puissance", celle-ci ne dépasse pas 900mA pour le courant moteur, ce qui reste tout de même modeste.


Dans les modifications du panneau on ajoutera (Lors des beaux jours seulement) la reprise correcte du câblage qui a mal vieilli aux UV car certains fils apparents, pourtant UL/CSA… ont viré de l'orange au blanc et sont devenus cassants.
(Je mettrai peut-être aussi une petite couche de peinture verte car l'ensemble souffre et certains inserts de vis (cadmiées) de fixation du panneau sont déjà bloqués par la rouille, cela faisant le panneau lui-même, n'est plus démontable de façon simple).

On ajoutera aussi les deux nouveaux équipements que sont l'anémomètre et le détecteur de grêle, sur un petit mat à une extrémité du panneau. (Pas de photo pour l'instant puisque ce n'est pas réalisé).

2.2 La modification de la partie électroniqupilot2e

Les entrées faibles niveaux de la partie puissance sont simplement raccordée à la carte PIC qui ne possède aucune partie puissance.
Lors de la conception du CI de la carte PIC, j'avais pris en compte ce câblage, ce qui a permis d'utiliser du câble en nappes en liaisons.
(Les commandes ont toutes un étage d'interface/puissance situé sur la carte puissance)
La partie des capteurs logiques est devenue très simple puisque deux simples microswitchs sont utilisés. Des petits réseaux RC sont placés systématiquement sur la grande majorité des entrées PIC.

2.3 Le temps et la rotation de la terre

Le temps par sa précision à long terme, joue un rôle important dans cette application.
Point tant la précision instantanée, qui pour rappeler la variation du cosinus, n'induit pas de grandes variations de la surface exposée, mais seulement par sa dérive potentielle au fil des heures et des jours.

Aussi pour pallier cet éventuel problème, une synchronisation journalière DCF77 réalisée de nuit à 4 heures du matin est utilisée. Cette synchronisation assure également les changements d'heures été/hiver, mais donne aussi les jours de la semaine. (Capot de protection violet au dessus du coffret, sur la photo ci-dessus)

Le DCF77 a deux raisons d'exister. Celle qui vient d'être dite, mais aussi une raison de développement hardware, je m'explique :
Cette deuxième raison est due au principe même du Timer 0 sur les PIC. En effet le quartz de l'horloge devrait être tel que l'horloge dont la division par puissance de 2, donne des valeurs entières en unités de temps (1 ms, 10 ms, 100 ms, secondes).
Dans cette vision, la base de temps horaire est malheureusement issue de la base de temps générale à Quartz de 20 MHZ (Qui n'est pas une puissance de 2). On peut remarquer une mauvaise "habitude" qui consiste à utiliser des valeurs exactes de fréquence. (A ma décharge, c'est la croix et la bannière pour s'approvisionner en province !)

Ces valeurs ne donnent pas la précision de temps pas plus que la précision au niveau RS232 qui nécessite aussi des valeurs différentes.
Le mieux serait d'utiliser au moins une valeur réputée parfaite soit pour l'horloge soit pour la RS232.
(Cette mauvaise habitude est due aussi au fait que l'on souhaite aller le plus vite possible !)
Je n'ai pas manqué à cette tradition de peur de ne pas avoir assez de temps pour les calculs, car à l'origine on part tout de même un peu "à l'aveuglette" au niveau des temps de calculs…

Pour résoudre le problème, le Timer zéro chargé du temps solaire est préchargé par valeur juste toujours inférieure à 10 ms et un petit retard est ajouté juste avant le rechargement du registre TMR0 à la valeur requise, pour tomber avec un écart le plus faible possible.

La raison en est due à l'écriture du registre TMR0 qui réalise en même temps la remise à zéro du pré-diviseur. C'est donc un ajustement presque statistique du temps pour obtenir la véracité la plus proche du réel.
Ici la base de temps la plus fine sera de 10 ms. C'est-à-dire qu'une interrupt sera générée toutes les 10 ms.

Encore un mot sur le temps… On réalise dans la boucle principale des centaines de calculs de position du soleil par seconde, pour déterminer si un écart de position devient suffisamment significatif pour être transmis aux moteurs.
Aussi le temps sera calé sur le temps solaire et non sur l'heure légale.
C'est un changement très logique par rapport à la version précédente, avec un petit inconvénient qui implique des conversions lors des affichages, (ou des entrées manuelles) mais le nombre en est plus réduit. C'est une petite économie de temps system, mais surtout une meilleure structuration.

Une dernière information importante sur le temps…
Le temps est calculé pour qu'il y ait un passage rapide entre l'heure solaire et les angles horaires sans alourdir les calculs (Angles correspondants aux différentes heures de la journée). Ainsi il s'agit d'un compromis (Genre de PGCD/PPCM) visant à réduire les conversions et la difficulté des calculs en assembleurs SANS l'utilisation des nombres réels.
Le temps solaire du plus fin déplacement de l'astre sera de 1/7200 de jour, soit de 12 secondes en temps, ce qui représente au niveau angulaire en azimut 5/100 de degré. (86400/12=7200)
Ce point est très important pour comprendre le fonctionnement, car si les calculs sont nombreux et ne dépendent que de la vitesse du PIC, les résultats réels de valeurs angulaires ne pourront changer au mieux que toutes les 12 secondes.

La précision de positionnement ne devrait donc pas changer beaucoup pour une variation de quelques dizaines de secondes (de temps) au maximum au cours d'une journée. Cela fera seulement 5 à 10/100 de degré angulaire en azimut ce qui me semble parfaitement acceptable dans cette application.

Dans les calculs astronomiques on remarquera que ce sont les équations simplifiées qui sont utilisées. On ne s'occupera donc pas de la déclinaison journalière qui sera acquise une seule fois par jour. (Voir § 14)

Ceci est incorrect en théorie pure, car la déclinaison évolue tout au long d'une journée, mais à notre niveau cela serait largement superflu. (La terre continue sa course annuelle autour du soleil -tout en tournant sur elle-même durant la journée-)
De même un coefficient de la déclinaison n'est pas corrigé pour les années bissextiles, mais le sinus delta est peu affecté.
(Voir les formules utilisées dans les paragraphes suivants)

Dernière information enfin... La nuit les valeurs angulaires sont calculées mais représentent des angles "délirants" tels que le panneau "viserait la Chine ou l'Australie" et toujours en dehors des limites mécaniques. On affiche donc pas les angles la nuit mais la date complète, et le panneau reste bien entendu en position de repli.

Pourquoi calculer la nuit ? Simplement parce que après la nuit il y a le jour !!! Ce n'est pas que je sois disciple de LAPALISSE, mais simplement du au fait qu'il faut pouvoir détecter le lever du soleil. Comme il change tout le temps, d'heure de lever et coucher, c'est une obligation de calculer en permanence.

3 La carte avec PIC 16F88pilot76

3.1 CI principal

Ce CI comporte le PIC 16F886, un classique circuit CMOS 4015 pour les 8 LED, ainsi qu'un MAX232 pour la conversion de niveau RS232.
Le circuit comporte aussi les réseaux RC fabriqués à la demande, l'émetteur radio 433.92Mhz, et de multiples connecteurs pour tout raccorder. (Les réseaux RC adjacents sont parfois différents)
Le circuit est alimenté en +12V et régulé avec un LP2950 pour du 5V qui constitue la seule tension logique de l'ensemble.
On notera que l'anémomètre est cependant alimenté en 12V mais qu'il donne directement une tension de 5V logique.
Un buzzer est prévu sur la LED erreur. Un potentiomètre permet de régler le contraste de l'afficheur.
On trouve enfin en bas de la carte le connecteur DB9 de la RS232.

Le connecteur pin Berg d'antenne tout en haut juste à droite du carré blanc nécessiterait de sortir en façade un petit fouet d'antenne, et non pas sur le dessus de la porte comme actuellement car l'émetteur est largement désaccordé par la traversée du coffret.

Le schéma n'a rien de particulier mis à part le fonctionnement série de l'afficheur et des LED.
Voir les petits ronds blancs sur la droite, des LED dont on reparlera ci-après.

3.2 SchémaPILOT2s

Les typons issus d'imprimante jet d'encre sont doublés comme d'habitude pour l'insolation, tirés de façon normale. Le CI est traité à l'étain chimique. Cette méthode donne de bons résultats.
Dans la réalisation, on notera les LED montées côté cuivre, ainsi que les "switchs panel".

Selon la méthode à "Riri", des petites fibres optiques donnent également l'information des petites LED côté composants, sans avoir à retourner la porte pour voir, mais la lumière au "cul" des LED 3 mm reste faible et cela reste un peu léger (Petits cercles blancs de gaine thermo qui serrent les fibres, photo ci-dessus à droite du CI).

(Il aurait été possible de doubler les switchs panel pour les avoir des deux côtés de la porte, mais le coffret n'est pas si "grand", aussi j'y ai renoncé)

Il reste 2 E/S qui pourront être utilisées à "discréPILOT2_4tion".
Le calque du plan de placement visible en haut sur les photos de la porte a servi de plan de perçage de la porte !
Voici donc les schémas de principe (À jour) et les typons (Mis à jour mais non vérifiés)

Deux emplacements CI en spare ont été mis mais ne servent pas. Ils sont prévus pour des modifs que je n'imagine pas encore à ce jour...

3.3 L'entrée anémomètre

Cette entrée doit obligatoirement être traitée en interrupt pour compter automatiquement les différents tops. Ce nombre est évalué toutes les secondes très précisément, et en cas de dépassement le repli du panneau est commandé et la LED alarme est alors déclenchée.

Le connecteur baptisé "Girouette" (à tort) fournit le 12V permanent à l'Anémomètre, nécessaire pour un courant de 10mA (5 fois plus élevé que celui du processeur PIC !)
Le moteur E/O est commandé en premier sur détection de vent fort.

3.4 L'entrée grêle

Cette entrée en revanche n'a besoin d'aucune alimentation et fournit directement un signal logique 0 5V. Le repli H/B est commandé en premier.

3.5 La RS232 et la Radio

Entrée et sortie sur les ports spécialisés RC7 et RC6 pour lesquels seule la partie TX est utilisée.
Pour les économies d'énergie, la RS232 et la radio ne servent que pour la mise au point ou pour les enregistrements de position.
Un switch à bascule J11 au tableau alimentera en 5V ou mettra à la masse ces circuits tout en donnant l'information sur une entrée PIC pour permettre de sauter les boucles spécifiques.
Ainsi pour une version "dépouillée", il conviendrait  de mettre à 0L cette entrée.

Cette partie, crée à l'origine pour vérifier le bon fonctionnement de position, pourrait être supprimée en totalité, car cette réalisation est absolument binaire et il n'y a pas de surveillance particulière à créer dans la mesure où on sait calculer avec exactitude les positions du soleil, ce que l'on fait en principe  ! Cela gagnerait encore en simplicité.

3.6 Les switchs poussoirs

Ils sont traités anti-rebonds par des réseaux RC 470K 10  nF.

Le switch Reprise au vol doit être maintenu lors de la MST si on désire une mise sous tension  sans réinitialisation du panneau. Dans ce cas, il y a lieu que le panneau soit dans la bonne orientation qui sera ajustée en manuel. (C'est une reprise sur coupure secteur par exemple)

Le switch RAZ commande directement le repli

Ces deux commandes directes implémentées sont cependant soumises à validation par le switch Validation, car un appui inopiné peut en être la cause.

Un message display invite à cet appui ou à l'abandon en cas de fausse demande. (Appui long pour valider et appui court pour abandonner)

3.7 Le DCF77

Ce petit module possède une sortie en Open collector et il y a lieu de mPILOT11ettre la résistance de charge préconisée de 470K au VCC. Les informations des données série au rythme de la seconde sont traitées par des délais et scan, mais pas en interruption.

A la MST (Mise Sous Tension) Ce module donne un zéro logique durant 7 à 10 secondes avant de délivrer les impulsions. Cela permet après 15 secondes de déterminer si ce circuit est présent ou non.
De mémoire la consommation est de l'ordre du mA.
Pour rappel les jours sont numérotés de 1 à 7 et le jour 1 est définit comme étant le LUNDI.
Nota :
La séquence  DCF77 ne considère pas comme valable une trame ayant une correction des secondes ainsi qu'une trame ayant l'annonce d'heure d'hiver, par simple mesure de précaution.

(Ce module est protégé sous le capot plastique violet situé au dessus du coffret métal, car il ne reçoit pas dans cette cage de Faraday. C'est un gobelet de camping coupé !)

4 Paramètres programme (Menu paramétrage)

Ces paramètres sont stockés en EEPROM et sont rechargés à l'initialisation de la MST et tous les jours après la mise à jour à 4 heures par le DCF77.
Ces paramètres sont modifiables au pupitre et sont alors réécrits en EEPROM sans toutes fois être actifs dans la session en cours.

Liste des paramètres
Octet de paramétrage CTRL4 comprenant des bits logiques de paramétrage :
  Bit0 inhibit contrôle du vent
  Bit1 Position de nettoyage validée ou non
  Bit2 Signe de la position angulaire de repos E/O
  Bit3 Signe de la de la limite angulaire EST
  Bit4 Heure Hiver=0 Éte=1 (Pour Saisie manuelle date)
Minutes et Heure de départ le matin = 8bits+ 8bits
Minutes et Heure de coucher le soir = 8 bits+8bits
Limite logique angulaire EST=8 bits
Limite logique angulaire OUEST=8bits
Limite logique angulaire Basse=8bits
Limite logique angulaire Haute=8bits
Position hauteur de nettoyage correspondant à un temps de rotation moteur en sec= 8 bits
Angle de repos E/O en degrés seulement=8bits
Angle de repos H/B en degrés seulement=8bits (idem la limite dans ce cas)
Valeur limite du vent avant repli=8 bits
Angle et 1/100 mini EO pour moteurs=16bits+8bits
Angle et 1/100 mini HB pour moteurs=16bits+8bits
Récurence des émission radio (Non utilisé)=8bits
Constante Angulaire en ° / temps moteur Azimut (Résolution en sec*100/°)=16 bits
Constante Angulaire en ° / temps moteur Hauteur BH (Résolution en sec*100/°)=16 bits
Constante Angulaire en ° / temps moteur Hauteur HB (Résolution en sec*100/°)=16 bits

Nota 1: La constante angulaire Haut/Bas est différente pour la montée et la descente à cause de l'équilibrage qui est loin d'être parfait… (Cela à cependant l'avantage de rattraper les jeux toujours du même côté, ce qui est une bonne chose)
Cette anomalie ne se présente pas en rotation E/O et les jeux peuvent prendre tout leur sens, mais ne mettent pas en cause le positionnement absolu. La RAZ positonne toujours du même côté le panneau.

Nota 2 : On notera aussi que les angles de repos E/O et H/B set les limites sont seulement définis en degrés entiers et non en degrés et 1/100. Cet ajustement précis est à traiter au niveau mécanique, mais la réalité s'affranchit facilement de ces quelques 1/100 non définis… !

5 Commandes disponibles

Au niveau puissance : MANUEL / AUTOMATIQUE. En Manuel le panneau peut être mis dans toutes les positions et toutes les fonctions automatiques sont coupées. En AUTO le panneau est sous contrôle du PIC et les autres switchs du pupitre sont inactifs.

Au niveau logique :
Marche, suite à Arrêt par appui court sur VALIDATION
Marche, avec reprise à la volée sur la position en cours (Suite coupure secteur par exemple)
Arrêt/REPLI immédiat sans re-départ ultérieur (Approche orage par ex)
 (Nécessité d'intervention opérateur pour la reprise par mise hors tension)
Repli avec position nettoyage à 30° angulaire par paramétrage
Entrée date et heures + été ou hiver (Pour éviter algorithme) Joursem (Jour de la semaine) est inutile dans ce cas !

La touche validation est à la fois reconnue pour un appui court ne dépassant pas 800ms OU un appui LONG dépassant 800ms. Ceci est exclusif entre long ou court. Cette touche de validation n'a aucune fonction "repeat" contrairement aux deux autres touches + et -
Les deux autres touches ont l'action à l'appui en cas de paramétrage, avec une action repeat exponentielle utile pour les paramètres 16 bits, mais aussi un rôle de commande immédiate qui sont (hors paramétrage):
- Le repli immédiat (à valider)
- La reprise au vol (La synchronisation se fait de visu en manuel et la suite se poursuit normalement suivant le programme). Cette fonction est un chemin rapide pour éviter de refaire la RAZ Est /ouest et Haut /Bas.
Ce peut être le cas d'une coupure de courant avec présence humaine qui permet les fonctions de positionnement manuel (Fonctions moteurs manuelles exclusivement hardware, par inverseur AUTO/MANU))

Nota 1 :Lors d'un fonctionnement normal, l'appui sur "reprise à la volée" est un peu surfait car la mise en manuel durant le traitement réalise parfaitement cette fonction. Cela est surtout utilisé pour une reprise après coupure secteur pour ne pas refaire tout le cycle d'initialisation.
(La synchronisation optimale (si elle ne l'était pas) sera réalisée lors du repli de fin de journée).

Nota 2 : La fonction nettoyage peut être validée ou annulée par paramétrage, mais pourra être annulée pour la journée sur une détection de grêle.
Une information concernant ce principe, je n'ai malheureusement pas eu de réponse à une demande formulée à Mr QUERE de l'école polytechnique concernant l'angle optimum permettant le nettoyage le plus efficace d'une vitre lors des pluies, aussi j'en resterai à faire des essais entre 30 et 60° environ. (Problèmes très pointus liés aux tensions de surface et à l'action mécanique des gouttes d'eau)

Nota 3 : La détection d'appui long est transmise avant le relâcher de la touche, dès le temps de 800ms dépassé.

6 Automatismes

  • Recherche du DCF77 pour date et heures à la MST ou en réinitialisation :
    -  À la MST
    -  À 4 heures du matin tous les jours (synchronisation)
     
  • Repli Azimut sans reprise possible

    sur erreur de calculs
    Sur vent fort détecté, actions ci dessous :
    - Aucun changement haut/bas avant rotation (aucune commande moteur H/B)
    - Rotation Vers position médiane en E/O
    - Mise finale à la verticale (H/B repli)

    Sur grêle repli Haut/bas puis seulement EST/OUEST
  • Heure de départ du matin indépendante du lever du soleil mais nécessairement postérieure.

  • Heure d'arrêt le soir indépendamment des heures de lever et coucher soleil, nécessairement antérieure à l'heure de coucher du soleil.

  • Synchronisation Azimut au coucher le soir

  • Synchronisation Hauteur au coucher le soir et mise en position H/B basse ou de nettoyage suivant l'option choisie en CTRL4.

  • Si un nettoyage a été choisi, alors synchronisation H/B seulement à l'heure de départ atteinte.
     
    7 Affichages

Le contrôle par affichage des données de bon fonctionnement a été nécessairement réduit par rapport au PC équipé d'un écran couleur et ses centaines de caractères affichables, et il a été réduit par obligation aux seules valeurs indépendantes de tout process qui sont les angles et les heures dans la limite de 32 caractères !

Ainsi on affichera en fonctionnement les angles d'azimut avec signe et les angles de hauteur (Signe + toujours forcé quelque soit l'hémisphère).
(Une position display est utilisée pour indiquer par un pavé noir la nuit en Ligne 1 col 1)

Il est nécessaire d'afficher les angles en degrés et 1/100, aussi bien en Azimut qu'en Hauteur. Il faut aussi afficher les heures minutes et secondes et 1/10 de secondes. Il faudra 2 lignes pour cet ensemble.

Des changements d'écran seront nécessaires en début et fin de journée. On affiche alors la date complète et le voyant RUN arrête de clignoter rapidement.
Le voyant RUN limite sa consommation de nuit. La date et l'heure continuent de fonctionner à l'écran LCD.
La deuxième ligne de l'écran indique l'heure complète au 1/10 de seconde avec un E ou un H suivant que c'est l'heure d'Été ou d'hiver et reprend le jour et le mois (Disparus de la ligne 1 après l'initialisation). (Il n'y a pas la place pour l'année !)

Pour accéder à d'autres affichages, un appui sur Validation permettra d'atteindre d'autres informations et d'accéder au paramétrage.
L'affichage en cours de fonctionnement est le suivant sur les deux lignes :

Z-024.33 H+18.28
11:21:01.9H19/01

Les autres affichages sont l'auteur, avec la révision du programme sur 4 caractères+1   bricolsec 03-3P lors de la MST (Le P indique la donnée de révision inscrite en zone programme et non en EEPROM).

Juste après l'affichage temporaire de l'auteur et de la révision, la ligne est remplacée par la date complète avec le jour de la semaine en clair sur 3 caractères (Jeu, Sam…etc)
Ce dernier affichage est également repris durant la période de non activité solaire, la nuit avec affichage d'un pavé noir en colonne 1 ligne 1

Nota : On peut également considérer que l'afficheur est inutile dans la mesure ou le paramétrage est réglé. Cela est tout à fait réaliste, car il subsiste les LED qui sont suffisantes pour indiquer ce qui se passe. C'est certainement un peu moins confortable, mais c'est possible de reprendre l'afficheur, (sans toutes fois supprimer le hardware de sa connexion ni sa partie programme). On notera dans cet esprit que la suppression de lecture du signal Ready autorise de fait simplement de supprimer l'afficheur sans aucun incident. 

7.1 Autres affichages et LED

Un afficheur LCD ne remplace pas directement des LED ! Bien qu'il y ait cet afficheur, 8 LED ont été ajoutées pour afficher différents évènements dont la liste figure ci-après.
L'attention est attirée par la lumière et la couleur mais aussi le clignotement.

J'ai utilisé un procédé spécifique pour la première fois, qui est un registre à décalage CMOS de type 4015, un peu dans le même principe que l'afficheur LCD, mis à part que chaque sortie est une LED et qu'il n'y a plus aucun fil de commande.
Les LED sont mémorisées dans un octet mémoire qui est décalé (très rapidement) bit à bit dans un registre 4015.
A 20 Mhz, il y a des délais à respecter pour ne pas dépasser les caractéristiques de prise en compte de ce circuit CMOS qui est juste en limite à cette fréquence. (Quelques instructions suffisent)
Par programme, il est également possible de faire clignoter certaines LED en laissant les autres en normal. Cette possibilité est utilisée pour indiquer un mouvement moteur lors des positionnements sur les LED fin de course.

Je considère cette solution des LED comme très intéressante, car elle permet pour un coût dérisoire d'avoir une information de surveillance de qualité, visible à distance.
On remarquera que le décalage peut parfois être perceptible sur des LED haute sensibilité, mais utiliser un registre à décalage avec validation des sorties éliminerait cette simplicité voulue et cette économie. d'E/S

Cette solution utilise au réel une seule sortie supplémentaire sur le PIC (Clock spécifique de décalage mais avec la sortie data commune déjà existante pour l'afficheur LCD)
Pour l'utilisation optimale des E/S PIC, je crois que l'on ne fait pas mieux, car c'est un gain d'E/S fort appréciable !

Description des LED

(LED 5mm déjà existantes)
D7 RUN couleur verte clignotement lent ou rapide suivant jour ou nuit
D0 ERREUR couleur rouge vif

(4 autres LED existent en plus et sont directement attachées au circuit de puissance moteur, qui indique le sens et le fonctionnement moteur).

(LED 3mm sur CI)
D6 F_COU_HB couleur verte fixe ou clignotante lors des positionnements.
D5 F_COU_EO couleur verte fixe ou clignotante lors des positionnements
D4 Vent ou Grêle, couleur ROUGE vif nécessite une remise en marche
D3 RS232 et RADIO, couleur jaune indique le switch alimentant Radio et RS232
D2 AUX1 et AUX2, couleur JAUNE indique l'état de ces E/S
D1 Pluie, couleur jaune indique si pluie

7.2 Variables, particularités

Une grande majorité de variables sont de type courant, c'est-à-dire Bit, octet, 16 bits 24 bits (et 32 bits en calculs intermédiaires seulement).

Des variables temporaires sont parfois utilisées et sont dans des unités incohérentes car à un coefficient 2 près ou d'une structure particulière. Certaines valeurs pour garder un maximum de précision, et dont on connaît de façon précise les limites  peuvent être représentées temporairement pour moitié pour éviter de monter en nombre de bits de résultat.

Certaine variables sont scindées en 2 parties : Partie 16 bits et partie 8 bits, c'est le cas des angles par exemple.

Dans certains cas, la représentation des nombres signés sera réalisée suivant 2 techniques très différentes :

La première consiste à représenter les angles négatifs en complément à 2 de façon très habituelle.
Cependant les sinus et cosinus qui sont utilisés dans les équations solaires représentent trop de complications lors des opérations différentes d'addition ou de multiplication de sinus et cosinus entre eux.
Aussi, pour les rapports trigonométriques, une autre convention a été utilisée. (Cette convention modifie un peu la présentation des résultats des séquences sinus et arcsinus décrites dans l'article dédié)

Les sinus et cosinus sont les seuls rapports trigonométriques utilisés. Ils sont multipliés par 10000 et ne dépasseront donc jamais ce chiffre de 10000 puisque dans leur acceptation d'origine ces rapports vont de 0 à 1.

Or cette valeur de 10000 peut être représentée sur seulement 14 bits. On a donc toute liberté d'utiliser le 16ème bit (Bit15) du poids forts des 2 octets comme bit de signe SANS complémenter la valeur de la partie numérique.
Cela est une simplification très forte lors des calculs (presque toujours effectués en valeur absolue) mais n'affecte pas la précision des calculs.

Ainsi les valeurs de sinus et cosinus seront codées sur 16 bits signés mais sans être en complément à 2.
Cela est très important car la quasi-totalité des opérations mathématiques assembleur proposées par le constructeur ou diffusées par des internautes avisés, sont en valeur absolue.

Pour les Angles :

Les angles pouvant aller au moins jusqu'à 360° nécessiteront 2 octets, mais de part la résolution horaire qui donnerait des angles en 1/100 de °, cela reviendrait à compter jusqu'à 360*100 soit 36000.

Ce chiffre théoriquement signé ne tient plus sur 16 bits ! Alors les angles seront représentés d'une autre manière, permettant de stocker le signe, mais permettant surtout de réaliser les pointages et interpolations nécessaires dans la table des sinus.

Ainsi 16 bits seront assignés à la partie décimale d'un angle (0 à 360) et un octet sera assigné à la partie des 1/100 de degrés angulaires.

Cette façon de traiter présente tout de même des difficultés car le signe est seulement porté par les 16 bits des degrés entiers. La partie fractionnaire des 1/100 à le même signe que les 16 bits de la partie entière.
Cela entraîne parfois de complémenter à 100 la partie fractionnaire pour retrouver une valeur exacte.

Mais pas de souci, ceci est traité dans les séquences sinus cosinus et arcsinus qui ont déjà fait l'objet d'un article complet (voir les liens).

Avant tout calcul d'angle, il sera nécessaire de rechercher le signe puis de multiplier les 16 bits par 100 et d'ajouter la partie fractionnaire ou son complément à 100 suivant le cas

Nota 1 : L'obligation d'utiliser des angles horaires centrés sur le midi solaire (Valeur 0°) aurait pour conséquence de limiter à ±180 ° l'azimut sur une journée. De ce fait cet angle de 180° tiendrait sur un seul octet en valeur absolue seulement, MAIS le signe ne serait pas inclus !
De plus l'élaboration de l'angle horaire à partir des heures, minutes et secondes, passe par des valeurs de 0 à 360°, ce qui empêche de réduire la taille des variables.

8 Fonctions SINUS / COSINUS et Arcsinus

En première approche, j'avais regardé pour voir s'il était possible de calculer sinus, cosinus et arcsinus à partir de formules mathématiques de séries ou autres, mais c'est un réel casse tête au niveau assembleur et un travail que très peu de personnes ont du réaliser, tant c'est compliqué. Inutile de dire que je n'ai pas été plus loin que l'examen des références des ces possibilités sur Internet !
Cela aurait également posé le problème des temps de calculs, car si vous regardez votre calculette, vous verrez qu'elle met du temps avant de vous donner un Sinus ou un autre rapport trigonométrique.

J'ai donc retenu bien évidemment une table. Ces séquences de travail sur table à ont déjà fait l'objet d'un article dédié et sont donc vérifiées sur le fond. Elles seront utilisées avec les quelques modifications de présentation des résultats indiquées précédemment, pour faciliter les calculs.

Se reporter à cet article pour comprendre les fonctions sinus cosinus et arcsinus. En quelques mots sur le principe seulement, les valeurs de sinus, et cosinus sont obtenues à partir d'une table de 0 à 90° (91° en réalité). Cette table a été générée automatiquement par scan et ROC d'un "bouquin d'école" avec mise en forme.
Les valeurs de sinus sont sur 4 digits et sont donc exprimées sur 14 bits (16 bits réellement).

Les valeurs intermédiaires des 1/100 de degrés sont obtenues par interpolation linéaire entre 2 degrés consécutifs.

La fonction arcsinus est exactement l'inverse avec une particularité qui est de rechercher par groupe avec un maximum de 10 recherches (si je me souviens bien ?) La fraction finale est faite également en interpolation inverse pour retrouver la fraction d'angle.

Cette structure de recherche en table nécessitait donc de traiter séparément les degrés et les fractions de degrés. Tout s'explique donc, pourquoi tant de formats apparemment si bizarres.

On remarquera que le rapport trigonométrique de la tangente est un "poison intellectuel" puisque le résultat peut être infini. De même que l'extraction d'une racine carrée est une difficulté complémentaire, aussi les sinus et cosinus sont donc les  seuls rapports privilégiés utilisés.

Nota 1 : La fonction arcsinus est dite fonction trigonométrique inverse et consiste à rechercher un angle dont on connaît le sinus.

Nota 2 : la table est constituée de façon unique pour des angles de 0 à 90° avec pour adresse les degrés et les contenus en valeur sur 2 octets. La recherche d'un sinus à partir de l'angle est donc très facile.

La recherche inverse de l'adresse à partir du contenu est plus difficile, mais pourrait surtout être très longue, car elle nécessiterait de balayer jusqu'à 90 fois pour trouver deux valeurs d'encadrement. Elle a donc été découpée en plusieurs zones pour ne pas dépasser une dizaine de recherches dans tous les cas.

Nota 3 : Les recherches d'arcsinus fonctionnent également en interpolation linéaire pour retrouver l'angle en degrés et 1/100 de degrés

9 Quelques consommations d'énergie

Créer un nouveau système plus économe, vu le travail engendré doit être justifié et voici donc quelques chiffres qui parlent d'eux-mêmes :

Sous 12 volts d'alimentation générale du CI principal, le courant est de :

  • 26.2 mA avec 6 LED allumées, l'afficheur LCD
  • 29.7 mA avec 6 LED allumées l'afficheur et les circuit RS 232 et radio
  • 9.63 mA avec afficheur et RS232+Radio
  • 6.11 mA avec afficheur seul (Processeur et 4015)

La puissance dissipée par le régulateur 5V à 30mA est de 0.24W soit un total de puissance de 0.36W
La puissance utile est donc de 0.15W maxi. C'est sur point qu'il faut apprécier la poursuite du soleil à si faible puissance d'alimentation pour les calculs.

On constate qu'à ce stade, une partie importante de la puissance est perdue en régulation et signalisation, et la puissance consommée pour le process est extrêmement faible.

La puissance nécessaire aux moteurs est un peu oubliée mais je pense assez faible car elle varie avec les nombreux démarrages et arrêts pour suivre le soleil.
On peut l'évaluer en continu sur la base de 700 mA en 24 volts. (Valeurs mesurées sur table et variant de 400 mA à 900 mA en charge) A cela il faut opposer un double réducteur de vitesse qui fait que le couple résistant reste faible.

Pour fixer les idées, prenons 600mA comme valeur moyenne sous 24 V, ce qui donne environ 15 W de puissance ou pour 15 minutes de rotation cumulée Est/Ouest par jour, 3.75 Wh et un peu moins en Haut/Bas évalué à 2Wh soit arrondi 6 Wh  PAR JOUR pour l'asservissement motorisé.

Ces calculs semblent assez cohérents pour ne pas s'affoler plus sur cette consommation qui a toujours existé… et qui continuera, et qui représente "epsilon" par rapport au gain calorifique équivalent récupéré !

A titre comparatif, la partie calculs dont on vient d'évaluer la puissance seule à 0.36W  consomme sur une journée (solaire) moyenne de 10 heures, 3.6 Wh (et 4.8Wh si on laisse l'appareil sous tension la nuit).

Cette consommation est à rapprocher par exemple de la consommation d'un volet roulant motorisé (au repos) qui de mémoire est du même ordre de grandeur.

Pour rester honnête, il faut tout de même dire que la partie alimentation générale et moteurs possède un transformateur avec deux régulateurs 24 V et 12V et que les pertes de cet ensemble sont plus importantes que toute l'électronique confondue.
Je viens de mesurer le courant général du coffret, soit 38 mA sous 220 V au repos moteurs, ce qui donne une puissance apparente de 8.6 VA et on peut estimer (Courant non sinusoïdal) cette puissance active avec un cos phi équivalent de 0.5, à 4 W, ce qui reste tout de même très acceptable, (Et qui existait déjà préalablement).

10 Le DCF77 et l'affichage LCD

La séquence DCF77 a été reprise telle qu'elle, du programme de la régulation solaire nouvelle génération, ajustée à la fréquence utilisée pour le PIC. (Bien entendu tous les éléments de délais sont à ajuster en fonction de la fréquence du processeur puisque le DCF77 envoie ses données au rythme de la seconde).

Cependant lors de la mise au point est apparu un nouveau problème du cette fois au driver série du display.
Pour la petite histoire avec le display LCD on visualise l'avancement des bits reçus au sein même de la séquence DCF77.
Anecdote d'un petit problème du au transfert d'informations sur W, ET sur le carry. En effet les "Rotates" nécessitées par la transmission série vers le display affectent le carry, contrairement à la méthode 4 bits qui effectue des "swapf". Le carry servait précédemment lors de la recherche du bit 20 (Start bit) ainsi qu'à la fin de trame pour l'année, où un 9ème était nécessaire.
Il s'agit simplement d'un mini problème qui consiste à sauvegarder ce carry et à le restituer en fin de séquence ENB_DISPx (Séquence d'envoi de valeurs au display). Ainsi ce sous- programme est plus indépendant des conditions externes et c'est meiux ainsi.

La séquence ENB_DISPx a été scindée en 2 entrées différentes, l'une pour le mode de commande (Enb_DispC) et l'autre pour les datas (Enb_DispD).

L'affichage LCD avec le display série décrit dans l'article cité permet de n'utiliser que 4 signaux. (DIS_RS, DISP_ENB, clock et DATAS).
Les datas sont communs avec l'affichage des LED. Quand je dis "les" datas il ne s'agit en fait que d'un seul bit d'un port).
Avoir 8 LED, un afficheur 4 sorties pour moteurs et 2 entrées fin de course, 3 switchs de panel, un détecteur et un anémomètre, 2 E/S en spare, la RS232 RX et TX ne serait pas possible en standard avec ce PIC, car cet ensemble dépasserait alors largement la capacité d'E/S du PIC. La solution retenue est donc excellente.

11 Les essais du PORT RB

Les résistances et condensateurs d'entrées sont toujours oubliés, peut être aussi à cause de la structure même du schéma qui les représentent de façon plus que symbolique par un trait !
470K et 10nF font tout de même une constante de temps de 4.7 ms (charge du condensateur en 5 téta (s?) soit 20 ms)
Pour la décharge ce sera 10nF et 22K soit une Cte de temps de 0.22 ms et une décharge en 1.1 ms.

Ces éléments concernent les entrées Fins de course (Positions de repli, c'est un abus de langage) en provenance du panneau soit FC_HB, FC_MED.

En réalité ceci ne présume pas de l'impédance du signal de commande (Quasi nulle pour les FC) et la seule constante de temps est donc de 22K*10nF pour les fins de course seulement.

Pour les touches du panel, la constante de temps est bien de 4.7 ms à la charge et quasi nulle à la décharge. Chaque touche répondra à 1 au relâché au bout de 4.7 ms environ. Il n'y a pas de rebonds.

Pour les tests généraux de vérification du CI, j'ai réalisé un petit câble plat allant des sorties moteurs vers les entrées fins de course et grêle. Ce test permet d'assurer en même temps les essais de 4 LED.

Une parenthèse concernant toutes les résistances de pull-up, et la raison pour laquelle je n'en ai pas utilisé une seule…
Celles-ci consomment un peu trop de courant, alors j'ai préféré mettre les résistances moi-même. De mémoire, et seulement pour le PIC 16F628, j'ai trouvé l'information d'un courant de 200µA.
Je n'ai pas trouvé l'information pour le 16F 886, aussi j'ai préféré convenir d'un courant de 10 µA qui me semble largement suffisant pour maintenir dans un état stable les entrées.
Il y a de toutes façons de multiples valeurs (De résistances au moins) sur une même ligne d'entrées et la seule solution est de réaliser à la demande. (d'autant que les circuits SIL ou DIL de réseaux de résistances seules ne conviennent pas).

12 Pourquoi calculer en permanence ?

Le calcul permanent permet d'avoir immédiatement le dépassement d'une valeur angulaire FIXE. Ce point est important pour quelle raison ?
Ce point est important car le déplacement du panneau se réalise sans contrôle de position à posteriori. Toutes les positions ont comme seule référence l'initialisation E/O et H/B (Mais aussi chaque valeur précédente).
Donc seul le temps est le garant de la position angulaire.

Calculer en permanence permet de détecter soit l'heure de lever ou coucher du soleil ainsi que les heures limites paramétrables.
Calculer en permanence permet aussi de tourner dans une boucle qui permet de scanner les éléments ne générant pas d'interrupt comme la pluie ou les auxiliaires.

Nota : Un mot sur la durée maximum d'une séquence de réponse aux interrupts. Toute réponse est unique pour une seule sollicitation et ne doit pas dépasser en temps, le temps entre deux incréments du TMR0. On ne doit traiter en Interrupt que l'urgence, le reste moins urgent, doit faire l'objet d'un scan

Le démarrage d'un moteur est toujours un élément de temps non linéaire qui déb.ute à 0 et se termine à x tours/mn.
Plus ce temps de démarrage devient important, relativement au temps total de fonctionnement, plus les déviations de vitesse moyenne de rotation augmentent.

En termes plus concrets, un temps de démarrage dure quelques dizaines ou centaines de millisecondes à quelques secondes pour les plus gros moteurs. Le temps de fonctionnement réel devra être au moins de plusieurs secondes pour ne pas être trop affecté par le temps de démarrage qui est assez incertain.
Il est donc important de "bouger" le panneau toujours pour un même quantum de temps qui permettra d'avoir une bonne (meilleure) relation linéaire du temps par degré angulaire.

En réalité c'est un peu plus compliqué, car il faut en plus prendre les jeux en compte et accepter une certaine liberté angulaire.

Oui la liberté est très à la mode, et elle est vraie aussi pour un panneau solaire qui poursuit le soleil sur des "bases motorisées bricolées" et un tel panneau peut être rapidement pris d'une forte envie d'indépendance…!!!

Il faudra par exemple, rattraper les jeux inévitables lors de l'initialisation.

De plus ces petits moteurs à courant continu qui sont en extérieur, sont sensibles à la température, et leur vitesse de rotation change légèrement avec la température…

Ultérieurement à la réalisation initiale, j'ai trouvé des petits moteurs asynchrones 48V avec condensateur de démarrage de 0.1 µF ayant le double sens de rotation…(Voir photo en 2.1)
Trop tard ! Car le circuit de puissance existe depuis plusieurs années, ainsi que le transformateur 24V, et je ne referai pas tout.
J'assurerai simplement le passage de l'ordinateur avec ancien programme en turbo-PASCAL-4 au PIC 16F886 qui consommera environ 20 fois moins soit 2 watts contre 35 à 45 Watts pour l'UC seule (L'écran CRT fait lui-même 46 W ! mais il était arrêté dès la mise en marche effectuée).
Les relais de sens de rotation seront tous désexcités durant le repos des moteurs. Cet aspect avait été omis lors de la précédente réalisation, et il a été corrigé.

Tous les relais sont au repos et pré positionnés pour la durée la plus importante.
Ainsi le relais de sens E/O est au repos dans le sens EST ---> OUEST, et il a donc fallu inverser le sens de ce moteur, (Cela n'a eu pour conséquence que de retourner un switch de commande manuel).

Le relais H/B est excité à la montée, qui en temps est beaucoup plus court le matin que l'après midi, (dans mon seul cas) mais l'incidence est faible puisque de toutes façons le chemin parcouru sera identique depuis la position basse jusqu'au zénith puis redescente jusqu'à la même position basse. Seuls de nombreux démarrages intermédiaires seront évités.

Enfin point important, le scan sera réellement permanent et pas seulement toutes les 12 secondes pour des raisons de calculs et de précision des instants de détection de changement. Cette manière permettra de simplifier les calculs astronomiques tout en gardant à chaque calcul sa précision.

12.1 La fréquence du calcul azimut et hauteur

Mesurée le 8/12/2011, la période de boucle sans RS232 était de 34 ms au stade de développement dont la partie calcul est figée.
Cette période comprend les calculs du jour à la vitesse maximum comprenant également les affichages au display de l'heure et des degrés angulaires d'azimut et de hauteur. (Cela comprenait également les comparaisons de résolution angulaire)

L'angle horaire Omega a seulement la précision de 1/7200 de jour exprimé en secondes soit 12 Secondes angulaires (en temps), correspondant à 5/100 de degrés angulaires.

(En réalité dans le temps de boucle il y a quelques "délais qui traînent un peu dans tous les coins", car pour que l'affichage reste correct, il ne faut pas distraire trop souvent l'afficheur LCD, car l'affichage devient "tremblotant" et de mauvaise qualité. Cela n'empêche pas cependant la précision des 12 secondes).
Cela donne néanmoins une bonne idée de la rapidité des calculs en général, cette vitesse dépasse largement mes prévisions pessimistes de départ et j'en suis satisfait.

Concernant l'affichage, le principe retenu est de faire le remplissage complet d'une ligne sans se soucier des éléments qui ont pu évoluer. C'est la formule la plus simple et la plus sécurisante, car elle évite d'oublier des cas où il y a plusieurs caractères qui changent.
L'analyse de ces cas consommerait également du temps system et rendrait la simplicité un peu moins évidente…Alors si on change tous les caractères cela prend aussi un certain temps, mais c'est plus simple… !

13 Temps de fonctionnement Moteurs

Les moteurs 24V hauteur et azimut, comme tous moteurs, ont un temps de démarrage et nécessitent de fonctionner pour une durée relativement longue par rapport au temps de démarrage.

Les temps de fonctionnement doivent aussi être paradoxalement assez courts pour approcher au plus près les courbes de "déplacement du soleil". Ce sont donc des compromis qui sont mis en œuvre, et la durée la plus petite est de l'ordre d'une dizaine de secondes.

Cette durée assez courte détermine donc directement la précision nécessaire au temps de fonctionnement. Le temps de commande moteur est précis à 50ms pour conserver l'ensemble des précisions des calculs.
(On remarquera que la mise en fonction des moteurs n'est pas affectée par le temps de réponse d'un relais. La commande est réalisée par un transistor. (Seul le sens nécessite un délai d'établissement, mais il n'intervient pas puisque situé avant les commandes ON/OFF.)
Ce ne serait pas le cas avec les petits moteurs asynchrones cités qui seraient commandés par relais très certainement.

Lors du système piloté en turbo pascal, la précision était du 1/100 de seconde, mais je pense que vu le processeur 8086, celle-ci devait être assez subjective surtout en langage évolué.

En tous cas, pour conserver un écart possible en degrés angulaires (positifs ou négatifs) et une précision suffisante, la résolution du temps moteur retenu est de 50ms, ce qui parait suffisant puisque cela fait donc 5/100 de secondes sur une dizaine de secondes soit un rapport de 200 qui est déjà bien. Ce ratio théorique reste cependant affecté par la mise en vitesse des moteurs, ainsi que déjà exposé.

(On remarquera aussi que ce temps de 50ms pourrait représenter en valeur angulaire E/O de 1/80 de degré, ou 1.25/100 de degré, ce qui est faible mais pas tout à fait négligeable face à la résolution angulaire de 12 secondes de temps Oméga pour 5/100 de degré angulaire.

Le temps maximum de rotation doit autoriser un débattement de plus de 180° angulaires sur la base d'une résolution de 50ms. Il faudrait donc plus de 16 bits pour compter avec le Timer1 et son pré diviseur au maximum. Cette solution ne fonctionne donc pas sans des opérations de comptage intermédiaires.

Nota : Entre le solstice de printemps et celui d'automne, l'excursion de l'angle horaire dépasse en valeur absolue les 180° pour atteindre son maximum au solstice d'été. 

Aussi pour le temps maximum de rotation (Conséquence de l'angle à parcourir) c'est une petite séquence dépendante du Timer0 qui sera utilisée.
Le positionnement de la valeur de temps à réaliser démarrera automatiquement le comptage du temps. Un bit d'un octet de contrôle (CTRL3) contrôlera l'arrêt du temps qui s'auto-bloquera au temps prévu. dans la séquence des interrupts. La boucle principale réduite (interruptible) analysera ce bit de contrôle et coupera alors les moteurs.

Dans cette boucle d'attente de fin de rotation, le clignotement des fins de courses correspondants sera inséré.
Cette partie du fonctionnement bien qu'interruptible, ne traitera rien d'autre durant ce fonctionnement des moteurs, en attente du bit de contrôle dans l'état "Terminé".

Les moteurs seront toujours commandés séparément et ce n'est pas un problème. L'écart éventuel entre la résolution de base et la valeur réelle de l'instant sera toujours pris en compte. (Le temps de fonctionnement moteur est toujours pris en compte à la commande suivante par le biais de la continuation du temps system durant le fonctionnement moteurs).

14 Les calculs "astronomiques" et quelques astuces

Dans les calculs "astronomiques", l'essentiel est de ne pas perdre trop de décimales. Sans passer par les nombres réels trop difficiles en assembleur, il n'y a pas d'autre solution que de multiplier pour avoir des nombres entiers. Cela entraîne des nombres de plus en plus grands.

Cependant, lorsque ces nombres sont déterminés comme étant encadrés dans des limites précises, et je pense aux rapports trigonométriques, il est possible de ruser pour éviter de perdre beaucoup de chiffres significatifs en précision.
(Ne pas confondre chiffres significatifs et troncature qui sont très différents dans l'esprit.)

Ainsi, si l'on considère que la précision d'un sinus doit comporter 4 décimales, cela revient à multiplier par 10000 la valeur.
Dans les équations solaires il y a des produits de sinus et cosinus et cela entraîne donc au maximum 10E8
soit plus de 4 milliards face à 100 millions.

Par opposition, si l'on divise ces 10000 par 2 pour chaque élément de rapport trigo, on atteint seulement 25 millions au maximum soit un nombre de 32 bits (ayant encore une possibilité de signe en bit 31) (0x17d7840).

Pour obtenir le résultat sur 4 chiffres il suffira alors de diviser par 10000 puis de multiplier par 4 (2x2)
En résumé on va seulement diviser par 2500 (=10000/4), ainsi on aura perdu un minimum de chiffres significatifs.

Bien entendu la division par 2, de nombres (de 16 bits) est ultra rapide (Un RRF sur chaque octet). Quant à la division par 2500, elle ne change pas foncièrement de temps entre 10000 et 2500.

Voilà donc pour cette petite explication des opérations qui peuvent paraître bizarres, mais qui sont en réalité des astuces pour éviter de monter en nombre élevé de bits dans les opérations. Je ne peux accepter de passer à 48 voire 64 bits avec des entiers, car trop "lourd" à gérer !

Enfin autre point très important, comme précisé au paragraphe précédent, il n'y aura pas d'évolution des positions angulaires avant 12 secondes révolues, correspondant à 5/100 de degrés en azimut, (Bien que les calculs soient réalisés plusieurs centaines de fois par seconde.
Cela évite de dépasser des possibilités de calculs en 32 bits, et permet par une simple multiplication par 5, d'obtenir des degrés et 1/100 de degrés à 5/100 près.

D'une façon générale on ne calculera pas les levers et couchers de soleil, car c'est un peu long et ne sert à rien réellement, (si ce n'est à l'affichage pour lequel il n'y a pas de place d'ailleurs).
Il suffira seulement de vérifier que la hauteur passe à 0 puis devient négative ou l'inverse. A ces moments le soleil est disparu sous l'horizon ou va apparaître. (Heure légale des levers et couchers sont des valeurs différentes prenant en compte d'autres paramètres "officiels")

Aussi ce simple passage à zéro de l'angle de hauteur sera synonyme de déploiement du panneau ou au contraire de son repli. Les mouvements sont de plus autorisés par les limites physiques du panneau, ainsi que par les heures d'autorisation (Obstacles éventuels au lever et coucher, mais rien n'est prévu pour des obstacles de masquage en cours de journée.)

Les formules d'expression des angles horaires dans les formules astronomiques réclament des angles horaires basés à Zéro au midi solaire.
Le matin, les angles d'Azimut seront donc négatifs, passeront à zéro au midi solaire puis deviendront ensuite positifs.
Les angles seront toujours au final exprimés en degrés et centièmes pour pouvoir être traités par la table de sinus.

14.1 Le système solaire et les équations

Quelques définitions
Dans les dénominations relatives au soleil, on peut citer le plan de l'écliptique qui représente le plan dans lequel la terre effectue son mouvement annuel autour du soleil.
L'autre notion est l'obliquité qui est représentée par l'angle que fait un axe passant par les pôles avec le plan de l'écliptique. Cet angle est fixe et ferait 23°44 (Je ne l'ai pas mesuré !)

La déclinaison est représentée par l'angle de la direction du soleil avec le plan de l'équateur terrestre. Cet angle varie au fil des jours, mais varie aussi (très peu) au fil des heures d'une journée. (Cet angle est à priori indépendant de tout contexte d'hémisphère terrestre, ce qui est vérifié par la formule 1 : voir ci-après)
(À voir si j'ai exprimé correctement ces éléments d'astronomie que je maîtrise très moyennement ? Ces notions sont très importantes pour comprendre les calculs et surtout les raisons des simplifications)

Pour rester simple, on fera l'impasse sur la variation de la déclinaison au cours d'une journée qui est très faible. La déclinaison varie au cours des jours de l'année "grosso modo" entre -23° et +23° soit un écart de 46° donc 0.12° par 24 heures et durant la période solaire active environ 6/100 de degré, ce qui correspond à la précision angulaire à 12 secondes (de temps) de l'angle horaire. (Ouf !)

De même on fera l'impasse sur une incidence des années bissextiles, (Seulement au niveau de la déclinaison sur la valeur 0.986 car l'erreur est très petite. (Voir formule ci-dessous)
Il ne serait pourtant pas difficile de l'introduire, dans le calcul, mais pourquoi faire compliqué alors que nous avons déjà une bonne précision !
Nota : Cette valeur représente le rapport des 360° d'angle de rotation annuelle divisé par le nombre de jours d'une année (365 ou 366 selon les années)

La déclinaison est donc calculée une seule fois par 24 heures juste après la mise à l'heure par le DCF77 soit tous les jours à 4 heures du matin ou à la mise sous tension.

On comprendra à tout cela que les jours d'équinoxes ne tombent pas toujours le même jour calendaire, à cause de tous ces éléments qui sont ajustés pour que le calendrier civil "tienne à peu près la route" relativement au "calendrier astronomique".

Vous ajouterez à cela toutes les irrégularités du système solaire et vous aurez ensuite comme moi, un bon mal de tête, alors restons simples, car la mécanique céleste n'est ni divisible par 10, ni par 360° et pas plus par 365 ou 366 !

14.2 Dénominations des variables solaires et équations

Voici la dénomination des variables utilisées dans les équations solaires :

Teta   Latitude du lieu dans l'hémisphère NORD (toujours positive)
Delta  déclinaison journalière. Angle calculé seulement une fois par jour durant la nuit
Omega  Angle horaire centré au midi solaire avec angle négatifs le matin
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))

Nota : Voir ci dessus pour ce coefficient 0.986
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            alors a= -180-a
           sinon  a= 180-a
     sinon a n'a pas besoin de correction

Le calcul de l'angle d'azimut a est déterminé en grande partie par l'angle horaire Omega exprimé en degrés et centré sur le midi solaire.
Cette opération de changement d'offset de l'heure consiste à convertir l'heure en secondes et à retirer 43200 secondes (86400 secondes par jour /2).
Il faut en outre comprendre que des indéterminations nécessitant un redressement angulaire, sont dues au fait que pour un même sinus ou cosinus, il y a deux angles qui peuvent répondre, au signe près et 4 angles si on ne considère que les valeurs absolues.

Nota :
La formule 4 permet de rectifier ces indéterminations angulaires pour retrouver les angles réels.
D'autres rapports que le cosinus, notamment le sinus de l'angle horaire, permettent de lever ces indéterminations.

15 Trucs sur MPLAB

Une erreur à laquelle je n'avais pas spécialement prêté attention est l'absence totale de contrôle sur des doubles définitions de bits.
Cela a été une cause d'incompréhension et de grande difficulté de recherche d'un problème, car celui-ci était relativement aléatoire.
J'avais espéré sur le déplacement de zones datas pour espérer de véritables plantages récurrents, mais ça n'a pas été le cas ! Par chance le bit en double définition était rattaché à l'horloge et donc un peu synchronisé par le start de départ.

La double définition qui suit ne cause aucune erreur d'assemblage :

#define  Sign_op CTRL2,Bit5 ; signe des différentes opérations en double avec param
#define TOP12  CTRL2,Bit5 ; top 12 secondes.

Ceci est un piège qu'il faut éviter car les #define ne font que substituer sans aucun contrôle et une inattention dans une rubrique de 8 bits est vite faite…
Alors voici une erreur qui coûte très cher en temps de mise au point, qui est normale vu les principes, mais il est bon de la rappeler pour mémoire.

16 Conclusions

Une mouture "Beta" déjà bien aboutie fonctionne déjà au réel, depuis le 15/01/2012, c'est la version 03-4P.

Ce que je peux déjà en dire, est que les calculs ne posent aucun problème de précision ni d'erreurs. Ouf !
A l'origine, je pensais être un peu juste au niveau des temps de calcul, mais il n'en est rien, ainsi qu'il a été vu dans les temps de boucle.

Alors il aurait été certainement possible de descendre en vitesse à 8 MHz au lieu de 20.
Il aurait aussi peut être été possible de résoudre le temps angulaire à la seconde près au lieu de 12 secondes, mais à quoi bon, alors que les temps moteurs restent toujours très aléatoires, et surtout que la surface apparente d'exposition ne change qu'avec le cosinus de l'angle formé par la normale au panneau et le soleil.

Enfin cela vaut il réellement la peine d'être si précis alors que les jeux des engrenages sont loin d'être négligeables ?

En conclusion on peut aussi citer la difficulté de mettre au point des phénomènes très lents, et combien un programme qui fonctionne parfaitement au simulateur peut révéler en situation réelle toutes sortes d'embûches allant jusqu'aux petites erreurs de hardware (Ceci c'était la dernière erreur qui m'a tenu presque 3 semaines). Il y a aussi le fait que de se prendre les pieds dans le tapis est aussi une réalité toute simple !
Pour la mise au point, j'ai tourné à double vitesse d'horloge, vitesse normale pour les essais réels avec le DCF et prescaler réduit pour tourner 8 à 16 fois plus vite... Mais cela affectait aussi la fonction touches appui long...
En bref ce n'est pas très commode !

Il est fort probable que je ne diffuserai pas le source de ce programme un peu particulier qui représente un travail très conséquent.
Les séquences SINUS, COSINUS et ARCSINUS représentent déjà un travail important et d'une très bonne précision. Ces séquences ont été publiées et constituent un outil dont je n'ai pas trouve de traces sur le Web.
Le principe pourrait peut-être intéresser les astronomes en herbe car moyennant une finesse plus grande, et de meilleurs moteurs, je pense qu'il serait possible au moins de pointer grossièrement des étoiles. (Suivre me parait impossible par le principe même.)

Inutile de dire que le circuit imprimé reste simple en regard du programme lui-même, et que le rapport des temps d'études est au moins de 15 à 20 !

Alors c'est bien le logiciel qui est essentiel dans cette réalisation et comme dans beaucoup d'autres à ce jour, avec les microcontrôleurs.

Surtout pensez à l'eau chaude et aux méga Wh d'énergie électrique gaspillée qui représentent un gouffre énergétique.
Face à cela, la position "veille" de quelques appareils reste bien peu de chose. Cela ne veut pas dire qu'il faut continuer à laisser les appareils en veille, cela veut simplement dire qu'il faut parfois choisir entre deux maux, mais dans ces conditions, la question ne se pose pas, car ce n'est pas la peste ou le choléra, qu'il faut choisir, mais seulement la peste ou un rhume !
On ne remplit pas une bouteille avec une petite cuillère, mais c'est toujours un petit volume utile !

Allez tournez manège !!!

17 ANNEXES

Cela me dérange de publier des plans assez "moches", mais je vais vous livrer tout de même une réflexion, faite il y a déjà fort longtemps concernant ce fait.
Les plans manuscrits ne sont pas beaux, mais véhiculent avec eux des informations visuelles caractéristiques qui par leurs graphisme très mauvais donnent des repères pour la mémorisation.

Ce n'est donc  pas catastrophique, et un mauvais plan vaut mieux que rien du tout !
Merci de votre compréhension et de méditer sur cela, car c'est une réalité qui va à l'encontre du "tout automatique et parfait".

Schéma simplifié du CI puissance

PILOT9

 Plan du CI Alimentation et puissance

PILOT10

Photos des versions précédentes et particularités

Version initiale avec coffret embarqué, version avec calculateur et coffret intérieur, et quelques Fin de courses logiques et de puissance ainsi que les capteurs à magnétorésistances.

oldpan1BFig_P7Fig_P8Fig_P2Fig_P4

Fig_P1Fig_P5Fig_P3

 

_____ ( retour en début d'article ) ____

 _____ ( retour accueil lokistagnepas ) ____
_____ ( retour accueil bricolsec ) ____