Chronique d'abandon d'un projet de Débitmètre

Avant propos d'un échec

1    Principes de base
2   Programme
3   Précision des mesures
3.1   Étalonnage
4   Schéma et CI
5   L'interface avec le système hôte
6   Réalisations sur ACTARIS
6.1   Conséquences du diamètre codeur
6.2   Circuit imprimé du PIC
6.3   Circuit porteur de la LED/cellule IR
7   Conclusions

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

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

Avant propos d'un échec

Ce fiasco vient de trouver son épilogue dans les minutes présentes ce 27/03/2016 après un dernier essai qui vient de me confirmer l'impossibilité d'obtenir quelque chose de fiable au niveau des mesures de débit suivant le principe adopté.

Pour rappel, le principe était d'utiliser un compteur d'eau volumétrique avec un disque codeur optique inclus dans le totalisateur.
De multiples problèmes ont été résolus sauf un seul qui est rédhibitoire. La liaison magnétique entre la chambre de mesure et le dispositif ne peut pas s'adapter à ce type de mesures.
C'est une impossibilité physique car globalement les temps des impulsions sont élastiques tout comme la liaison magnétique, et c'est là le fond du problème.

Je publie tout de même l'article, car il sera utile pour que l'un d'entre vous comprenne et ne réitère pas cette erreur d'utiliser un compteur d'eau comme débitmètre avec disque codeur optique (ou autre d'ailleurs).
En théorie pure ça fonctionnait parfaitement, mais en pratique c'est impossible d'avoir des résultats sérieux à cause de la liaison magnétique entre la chambre de mesure et le totalisateur.

Je vais faire une mise en forme très simplifiée de l'article, car j'ai déjà passé beaucoup de temps en pure perte.

La confirmation de ce que j'avance est avérée, car j'ai enfin pu voir de mes propres yeux, l'avance saccadée du disque codeur. Ces saccades sont de fait incompatibles avec les mesures de temps des impulsions (pour la partie à zéro).
Les chiffres de la liaison RS232 confirment numériquement le problème, mais de voir en plus ces saccades, c'est la cerise sur le gâteau !!! (Dont une part est due aux nombreux démontages/remontages et à un alignement moins bon de l'axe).

Il est impératif que la liaison entre la chambre de mesure et le dispositif soit rigide.

En effet, pour imager ce qui se passe, je pense que ce système est fonctionnellement identique à la tectonique des plaques de notre bonne vieille terre. L'ensemble des frottements du piston se débloque à certains instants lorsque la pression interne oblige l'ensemble à bouger, aussi le mouvement est aussi brutal qu'un tremblement de terre (Toutes proportions gardées bien entendu).
Ce mouvement rapide est transmis à un "élastique" constitué par l'aimant multipolaire qui se comporte comme un élastique ou le pendule d'une horloge.

Le mouvement débute lentement, s'accélère, puis dépasse alors le point où il devrait s'arrêter.
Ce mouvement est donc une suite d'allers et retours permanents, dus à cette liaison magnétique.

On ne réussi pas à chaque fois, ce serait trop beau !

La partie électronique fonctionne correctement, et le programme a même été agrémenté d'une sortie ASCII pour la mise au point qui a donné les premiers signes d'inquiétude sur le principe.

Cette partie électronique et programmation décrite ci-après est parfaitement opérationnelle. Elle a permis de débusquer les problèmes mais ne peut malheureusement pas servir puisque le principe de mesure est inadapté.

Dernière raison de l'abandon, j'ai tout de même voulu voir, si en se passant du totalisateur et en réutilisant le circuit à effet Hall AH1892, il était possible d'avoir quelques données. (AH1892 collé sur la plaque bombée en inox)

C'est effectivement possible, et les valeurs ne sont plus du tout aléatoires mais à quelques sauts polaires d'aimant. Il est en effet très difficile de trouver une position qui donne des valeurs stables sans saut polaire.
L'effet "élastique a bien entendu disparu, mais un autre souci s'est présenté...

De désespoir, pour comprendre cela, j'ai démonté en la cassant la couronne noire qui appuie sur la plaque inox et assure l'étanchéité, et on a alors accès à la boîte de mesure dont le principe reste identique à SAPPEL, mais dont la réalisation est un peu différente.
Comme sur SAPPEL, l'axe de la glissière porteuse de l'aimant multipôles, a un jeu fonctionnel assez important et lorsque l'on sait que le positionnement d'un aimant correcteur est au 1/10 de mm, alors c'est perdu d'avance, et c'est pour cette raison que l'on arrive à sauter des pôles (Au niveau mesure seulement).

En tout état de cause, il y a bien au moins deux problèmes majeurs, dont le "problème de l'élastique" et ce dernier problème de jeu est aussi présent dans la situation normale avec totalisateur comme accélérateur de l'effet "tremblements de terre".
Il n'y a plus à ce jour de totalisateurs dits "noyés" et même les petits compteurs divisionnaires sont avec entraînement magnétique et donc incompatibles pour réaliser des débitmètres instantanés.
(A la nuance près que ces compteurs "vitesse" ont beaucoup moins de frottements que les compteurs volumétriques et que "l'effet tremblement de terre" est très fortement diminué)

Désolé les compteurs d'eau sont mal adaptés pour mesurer des débits instantanés !

Il reste les capteurs et montages à monter sur les têtes des deux marques de compteurs, avec lesquels on peut bien entendu calculer un débit, mais qui ne sera pas instantané car il faut au minimum attendre le passage d'un litre d'eau, ce qui peut parfois être très long !

Si cela vous intéresse de comprendre ce qui s'est passé, ou si la partie électronique vous intéresse, vous pouvez lire la suite.
Si les raisons de l'échec ne vous intéressent pas, alors fermez cet article sans plus attendre.

Avant propos de l'article tel qu'il était prévu mais obsolète maintenant.

Ce débitmètre utilise le capteur de débit déjà décrit, (voir cet article) mais avec un disque codeur encore plus petit. Ce capteur ne donne que des impulsions à mettre en forme, et à compter. Il n'a pas d'autres fonctionnalités.

Ce débitmètre véritable a pour rôle de transmettre une information de débit en Litres par Heure très rapidement. En ce sens utiliser un convertisseur fréquence Tension (CFT) ne convient pas à cause de la lenteur inhérente au procédé, et c'est bien dommage, car c'était réellement très simple de le réaliser avec un 555 ou assimilé ou même un LM331.
Tous ces circuits sont basés sur un réseau RC d'intégration et sont donc très lents, aussi il est nécessaire d'utiliser à bon escient le temps entre impulsions et de le transmettre rapidement vers le processeur chargé de l'utiliser.
On se basera donc sur une demi période du signal dont on déterminera la largeur par un comptage rapide.

De cette demi période on calculera facilement le débit que l'on enverra en série rapidement pour limiter les I/O du PIC et pour gagner du temps.
Ce débitmètre utilise un très petit PIC 12F675 dont le montage sera placé à l'intérieur d'un totalisateur de compteur ACTARIS Aquadis DN15.
Le capteur spécifique a été décrit dans l'article précédent (voir l'article)

1 Principes de base

Pour arriver à cette fin, il sera (malheureusement) nécessaire d'utiliser un PIC et de préférence un petit modèle.
Le modèle 12F675 conviendrait-il ? Ce serait à priori possible, mais il faudra générer par programme la liaison série RS232 vers le système hôte car durant ce temps, on ne pourra rien faire d'autre pour respecter le timing de l'horloge de transmission.

A 38400 bps l'envoi d'un mot de 16 bits (20 bits réels) durera 520µs ce qui est peu, mais il faut remarquer que durant ce temps toutes les interruptions (horloge particulièrement) devront être arrêtées pour respecter le timing RS232.
(Cependant durant ce même temps de transmission, il serait possible de lancer une mesure, car celle-ci ne serait pas affectée par la sérialisation du fait que le comptage en TMR1 est purement hardware, sauf si le temps d'une demi période du signal est proche de 1ms, soit vers 3000L/h.)
Pour éviter toute complication de timing, on ne procédera pas ainsi, car cela pourrait impacter les mesures aux débits élevés.

Pour utiliser un seul circuit intégré (PIC), il est pourtant nécessaire de mettre en forme le signal.
Pourquoi, alors que dans l'article sur la liaison magnétique et capteur de débit, le signal était suffisamment "joli" pour attaquer directement une entrée PIC ?

Le fait d'avoir réduit de plus en plus le diamètre du disque codeur pour une question de masse, mais aussi d'encombrement, a rendu le signal plus "mou", mais il a pourtant la même fréquence…
Je ne pense pas beaucoup me tromper en disant que l'éclairement est beaucoup moins précis, car la distance séparant les zones transparentes et opaques est plus floue, ce qui fait ce manque de dynamique.
Ceci est un problème pour lequel je ne veux pas revenir en arrière, car ce sont les oscillations qui sont en causes du fait de la masse de l'ensemble disque et axe.
Alors une seule solution : mettre en forme le signal avec un ampli OP intégré dans le PIC (Comparateur).

Cette mise en forme de signal coûte 3 entrées sur 6 ! Le signal ainsi mis en forme est ensuite introduit dans l'entrée T1G* du TIMER1.
Cette entrée de validation de comptage permettra de mesurer des temps sur la base de la µs de précision. Elle permettra tout aussi bien de compter les phénomènes beaucoup plus lents.
Seule ombre au tableau, on ne pourra pas travailler sur une période complète du signal, mais seulement sur la demi période. Il faudra pour cela que le signal reste assez symétrique pour que l'on puisse faire la multiplication par 2, sans faire de grosses erreurs.
Ce fait de la demi période implique de régler le courant LED ou la résistance du photo transistor pour une bonne symétrie du signal.

Bon an mal an la plage de fonctionnement du débitmètre ira de 4 L/h à 2500 L/h, pour un temps maximum théorique de 1.5s d'acquisition de la mesure.
On verra que ce temps est le temps de mesure seul, sans compter le temps correspondant à la période de synchronisation.

2 Programme

Le programme doit donc assurer durant une durée la plus brève possible, des mesures de temps entre les 2 fronts d'un palier à zéro, et pouvant même rencontrer un arrêt complet lors d'absence de fronts. Ce cas fréquent doit être traité aussi bien que possible, car le débitmètre peut s'arrêter sur un éclairement de la cellule ou l'inverse, mais cela ne doit pas bloquer le programme pour autant.
Dans de tels cas, il faut définir un temps maximum, au delà duquel on devra déclarer "arrêt de débit".

C'est bien dans les faibles débits que ce temps sera maximum, et on déclarera ARRÊT si le nombre d'impulsions de 1 µs est supérieur à 750 000 µs.

La précision du comptage sera donnée par l'horloge interne du PIC (INTOSC) mais sans quartz cependant, aussi le réglage du byte OSCCAL est impératif et si l'on respecte la donnée constructeur, la précision semble tout à fait correcte pour l'application, qui ne sera pas, il faut le dire, un instrument de mesures homologué, mais qui rendra d'excellents services ???
On préfèrera compter les reports du registre TMR1 à 65536, sans utiliser le pré diviseur. Un mot complémentaire comptera les reports du TIMER1 (maxi 256, soit environ 16 secondes), et cela ne prendra aucun temps supplémentaire tant que le signal sera à zéro, puisque c'est essentiellement une opération hardware par la Gate de T1 (T1G*).

Il est évident également qu'il est impossible de réduire la consommation (avec SLEEP) du fait que c'est l'oscillateur principal qui donne les impulsions de comptage dans TMR1. Cependant si c'est l'ordinateur hôte qui demande la mesure, il pourrait être possible de mettre en sommeil, mais si on mesure un débit, c'est le plus souvent pour l'utiliser immédiatement. (A développer, mais ne sera pas traité dans cet article)

Les reports avec TMR1IF seront gérés en interrupts et c'est cette séquence qui assurera le +1 automatique sur les reports (Temps masqué).
Parallèlement à cela, il est nécessaire que l'horloge principale soit active pour que le programme ne se bloque pas ou n'attende pas "des heures" sur un éventuel arrêt du débit.

Un timeout doit donc être généré dans cette éventualité à chaque test d'un état de l'entrée Gate T1G* mais aussi durant un comptage qui peut également s'arrêter sans prévenir.
Cette condition implique que durant une mesure, il ne sera pas possible de transmettre en RS232.

Le petit PIC utilisé PIC12F675 ne possède pas de port série RS232 aussi la transmission ne pourra donc pas se réaliser en temps masqué. On utilisera une vitesse élevée (Sans trop) mais suffisante pour ne pas bloquer trop longtemps les mesures. On se rangera donc à 38400 bps, vitesse suffisante pour aller vite et garantir une certaine précision dans le séquencement.
Cette vitesse élevée est possible du fait qu'il n'y a pas de transmission radio, mais une liaison filaire avec un processeur (Host)
Cette vitesse avec un temps de 26.042µs entre bits a l'avantage de garder l'oscillateur CPU exactement à la vitesse de 4MHz sans retoucher par OSCAL pour s'adapter à la transmission.
On transmettra en direct vers l'ordinateur hôte seulement 2 octets (binaires) sans autre accompagnement, ce qui donnera un temps théorique de 520µs pour cet envoi.

L'horloge temps (TMR0) fonctionnera en permanence pour éviter les blocages sur arrêt de débit sauf durant le temps de transmission qui ne souffrira aucune interrupt.
La fin d'une mesure fera l'envoi d'une trame RS232 de 2 octets durant environ 520µs si on est en mode binaire.

Toutes les mesures amènent à effectuer des opérations en 24 bits seulement. La précision permettrait si nécessaire de compter jusqu'à 0.18L/h sur la base de mesure d'une demi période, mais malheureusement sur la base d'au moins 33 secondes de temps de mesure du palier à zéro.
0.18L/H correspondent à un goutte à goutte d'une goutte toutes les secondes, valeur théoriquement possible pour un compteur volumétrique.
Pour fixer les idées, on pourrait détecter un robinet qui fuit ainsi en 90 secondes environ, mais dans l'application, on limite pour des questions de durée d'acquisition de mesure à 1.5 secondes le temps de mesure stricte du palier à zéro (sans compter la synchronisation nécessaire).

De très nombreux cas particuliers peuvent se produire lors du lancement d'une mesure de débit, suivant qu'il y a ou non débit, que l'on entre dans un certain état et que l'on s'arrête en cours ou réciproquement etc…

La valeur du débit est calculée ainsi =0.833333 L / Nbr impuls (µs)
Le nombre d'impulsions est en réalité un temps en µs puisque la fréquence de l'horloge INTOSC de 4MHz donne des impulsions à fosc/4 soit toutes les 1 µs.

Pour avoir des Litres par heure cela donne 2 999 998 / N impuls que l'on n'arrondira pas puisque ce nombre tient en 24 bits.
Le nombre d'impulsions tiendra compte des reports qui donneront autant de fois 65536 en plus.

3 Précision des mesures

Cette précision est en premier lieu influencée par le rapport cyclique du signal. Celui-ci devra être ajusté au mieux en jouant sur le courant LED ou la résistance du photo transistor.

Le rapport cyclique a pour corollaire la qualité du disque codeur dont la régularité induit la constance des écarts sur les 360° d'une rotation du disque. Fabriquer un disque codeur est une opération de précision que j'ai réalisée avec le logiciel Turbocad avec une définition bien meilleure que celle des circuits imprimés, d'autant qu'il y a une interpolation difficile pour chacun des secteurs dont l'angle progresse.

(On ne peut pas cependant atteindre la qualité d'un film photographique avec une imprimante jet d'encre)

Cette précision est ensuite affectée par le nombre d'impulsions de comptage du temps qui est à +- 1µs.
C'est-à-dire que pour 2500 L/H de débit mesuré, on a 1199 µs à +- 1µs ce qui est "bien"…!

Quand on est à 4litres / heure, on a 750 000 impulsions +-1 soit une précision (théorique) "fantastique".

Ne rêvons pas cependant car ces derniers chiffres bien que très réels pour leurs valeurs intrinsèques sont largement augmentés au niveau global, relativement aux autres possibilités et notamment concernant la largeur du palier de mesure (rapport cyclique)

Les résultats sont donnés par des divisions entières sur des entiers. Ceci implique que les faibles valeurs de débits seraient exprimées sur un nombre réduit de digits, ce qui est réellement dommage, car c'est précisément dans ce contexte que la précision est la plus parfaite. (Rapport 750 000 à 1)

Aussi je réutilise systématiquement le reste des divisions pour toujours avoir 4 digits d'expression des résultats, quelques soient les valeurs de débits.
Cette possibilité n'est plus paramétrable, on verra pourquoi.

La plage de mesures de 4 litres / heure à 2500 litres/heure permet d'avoir sur 16 bits la totalité des valeurs sur 4 digits tout en laissant libre 2 bits non utilisés (Pour la position du point décimal, voir ci-après).

En effet, dans le cas où on accepte 4 chiffres significatifs systématiquement, cela autoriserait encore de compter jusqu'à 16383 (10) (ou en hexa 3FFF), mais déjà là, l'expression en décimal serait à 5 digits. Alors 9999 reste la valeur clef qui autorise la libération de 2 bits et permet de représenter 4 digits décimaux de 0 à 9.

Les 2 bits de poids les plus forts seront utilisés pour préciser la position de la virgule depuis la gauche du nombre de 4 digits avec les exemples ci-dessous :

9999             00 10 0111 0000 1111
999,9           01 10 0111 0000 1111
99,99           10 10 0111 0000 1111
9,999           11 10 0111 0000 1111
0,000           11 00 0000 0000 0000       (Pas d'autre possibilité pour une valeur nulle (time out))

Pourquoi le nombre de digits n'est pas paramétrable ? Simplement parce que c'est une complication stupide du fait de l'immense étendue des temps possibles de mesure. Je ne parle ici que de la durée du palier à 0 qui détermine ce temps de mesure. En effet 1ms devant 1.5 secondes reste si petit que le jeu n'en vaut pas la chandelle !

De plus les temps spécifiques d'une mesure ne sont pas la réalité, car pour ne pas faire d'erreurs de mesure, il est nécessaire de préparer durant le TOUT DÉBUT du palier haut tout ce qui sera nécessaire à la mesure proprement dite. (Diverses initialisations, lancement de la gate T1, interrupts T1…etc).

Alors on doit pour commencer attendre systématiquement un palier bas et tout préparer au début du palier haut (TMR1ON) pour que dès l'arrivée d'un nouveau palier bas, le comptage soit prêt à débuter (Front négatif).
Le reste des opérations reste très mathématique, certes un peu long mais sans commune mesure avec ce temps de préparation et de mesures.

Enfin, j'ai parlé du TOUT DÉBUT du palier haut, cela signifie qu'il faut PRÉALABLEMENT attendre un palier bas qui ne sera PAS celui de la mesure, mais celui juste avant.
En conclusion, le temps total de mesure peut varier de 4.5 secondes à 7.2 ms, ceci pour 4 litres/heure à 2500 litres/heure respectivement.

Une autre précision inhérente au principe retenu :

Il est même possible de mesurer des temps de 200µs et d'afficher une valeur exacte en débit de 14999 L/H.
Bien entendu on ne peut pas traiter chaque palier à zéro et à cette vitesse, on est obligé d'en sauter quelques uns comme le montre la recopie d'écran, qui indique de fait une récurrence aux alentours de # 2ms. (capture d'écran ci-contre)

Le temps limite en descendant encore un peu plus plafonne vers 1.4ms qui est le scan le plus rapide, mais qui perd cependant un peu de sens du fait que des mesures sont sautées à cause du manque de temps.

Il est même possible de mesurer précisément jusqu'à 10µs, uniquement pour le nombre d'impulsions de 1µs mais cette fois les valeurs converties seront fausses, car les calculs de débit sont restreints à la plage de valeurs définie soit 4 à 2500 L/h.

3.1 Étalonnage

Tout est parfait dans le meilleur des mondes, mais est-ce bien le cas ? Je ne le pense pas, car j'ai bien dit palier à zéro, or ce palier dépend aussi de la précision du disque codeur, mais un peu aussi de la mise en forme avec le comparateur.
De plus la dispersion des largeurs de fentes du disque codeur pourra induire des valeurs légèrement différentes, sans que l'on y puisse vraiment quelque chose.

Alors pour l'étalonnage, il faudra suivant le modèle retenu utiliser 2 compteurs ou simplement le modèle ayant pu conserver ses galettes de totalisateur.
L'étalonnage se fera en agissant sur le coefficient 2 999 998. Ce coefficient sera donc placé en EEPROM pour ne pas avoir à recompiler le programme.

De la même manière pour éviter de faire appel au host, un paramètre EEPROM permettra de transmettre en permanence les mesures, ce qui sera également très utile lors de la mise au point.
Ces mesures pourront être visualisées sur un PC avec l'excellent logiciel RS232 "Terminal.exe" (free).

Une sortie convertie en clair (ASCII) de 4 ou 5 caractères a également été ajoutée car il restait de la place en mémoire programme, et cela sera très utile à la mise au point et l'étalonnage.

Il sera ainsi possible de régler finement la précision.

MAIS préalablement, il est important de faire un premier réglage du courant dans la LED qui assurera un réglage "gros", en rendant les paliers positifs et à zéro à peu près égaux.

Je ne pense pas qu'il faille rendre les paliers dissymétriques par ce réglage, car cela pourrait éventuellement réduire les limites et augmenter le temps de mesure. Une réduction du palier engendrerait une baisse de la précision. Alors je n'explorerai pas plus cette voie de la dissymétrie.

Pour le photo transistor la résistance de collecteur ne sera pas plus forte que 10K ohms à cause du comparateur du PIC.

4 Schéma et CI

Celui-ci reste très simple avec LED et cellule, soit en capteur fourche, soit en discret et intégré dans l'enceinte existante du totalisateur complètement équipé de ses galettes.
Le cœur du montage est un petit PIC12F675 avec 6 résistances et 2 condensateurs. 2 connecteurs utiles dont l'un pour le capteur avec 4 broches utiles, et l'autre à la fois pour la programmation et la récupération des tensions issues du host ainsi que le transfert du résultat par GPIO5, mais aussi avec GPIO3 qui assure un pseudo handshake DTR/DSR. (Le tout avec une masse commune bien évidemment !)

Peut-on programmer directement le PIC ? Oui en débranchant le connecteur capteur. (Après quelques oublis, il s'avère que même avec le capteur connecté, la programmation ne poserait pas de difficultés ?)

Dans le cas du montage avec le totalisateur complet vous regretterez le connecteur capteur, inutilisable ! Désolé il faudra souder les fils, mais vous pourrez reprendre le CI si vous le désirez.

Juste un mot sur la résistance R7 qui est simplement une petite aide au basculement du comparateur lorsque le disque codeur est arrêté juste à une frontière de basculement.

5 L'interface avec le système hôte

En effet ce débitmètre n'est pas un appareil isolé, mais est destiné à être connecté à un système hôte (ou "host" pour être plus concis).
Il s'agit donc de voir cet aspect sous plusieurs angles, et en s'inspirant des contraintes liées à un système de régulation solaire.
Ce host effectue de nombreux calculs (voir l'article) et si son temps n'est pas critique face à la lenteur des phénomènes, il n'est pas question de le distraire trop souvent.
Aussi il apparaît nécessaire d'établir un dialogue entre les deux systèmes pour "préserver la paix des ménages"…
Sur la base de l'existant et des faibles possibilités, j'ai donc décidé d'établir un dialogue très simple entre eux. Le principe est le suivant :
Le débitmètre calcule ses débits en permanence et surveille par interrupt son entrée GPIO3 qui sera pour lui le signal issu du host qui demande une mesure.
Face à cette demande, le débitmètre ne peut pas répondre immédiatement suivant son processus de mesure du temps qui peut occuper l'essentiel de son temps CPU.
Aussi à l'origine il maintient sa sortie GPIO5 à 1 jusqu'à ce qu'il repère cette demande émanant du host. Il y répond immédiatement par un simple "accusé de réception" en plaçant sa sortie GPIO5 à 0.
Ne pouvant se détourner de ses mesures et calculs en cours, il les termine et peu de temps avant la fin, replace sa sortie GPIO5 à 1 durant environ 10 µs.
Passé ce délai, il envoie ses 2 octets binaires en direction du host.
Suite à ce délai, le host a lui-même le temps de se préparer à recevoir l'information série des deux octets qui seront alors transmis et qui représentent la dernière mesure connue.
Si la configuration est en ASCII, le principe reste identique.

Pourquoi ce procédé un peu particulier ? Cela est dû à la structure même du débitmètre, puisqu'il ne peut pas gérer la RS232 en interrupt du fait que la fonction n'existe pas sur ce PIC et que c'est en mode programmé qu'il transmet ses données.
Cela est aussi fait ainsi pour ne pas envoyer en permanence des informations inutiles au Host qui ne les traiterait pas mais perturberait son fonctionnement par les interrupts associées.
Si besoin, (Manque d'une I/O au niveau du host pour recevoir GPIO3), il est possible de ne pas utiliser GPIO3 et de tout concentrer sur GPIO5 qui pourrait passer d'entrée à sortie en associant une résistance de rappel assez élevée sur GPIO5. Le host commencerait par forcer à zéro cette entrée, puis passerait ensuite en lecture. Le débitmètre ferait exactement l'inverse, mais le temps serait moins bien maîtrisé entre les différents basculements. (C'est la raison pour laquelle je garde GPIO3 comme entrée).
(En général GPIO3 est une I/O dont on ne sait que faire tant elle est particulière en n'étant qu'entrée, MCLR* et VPP !)

Le programme du débitmètre testera simplement si il y a eu demande du host AVANT de relancer un nouveau cycle de mesure. Cet envoi représente un temps très court d'environ 520µs en binaire, ce qui sera le plus souvent négligeable devant le temps de mesure moyen de quelques dizaines de ms.

Il y aura donc deux signaux de sens opposé qui définiront ce dialogue très simple.
Les modalités prévues sont celles directement données par les PIC ayant la RS232, soit le signal "mark" (1 logique) donnant le repos sur la ligne et l'envoi des 8 bits de données poids faibles en tête suivi d'un "STOP".
Ainsi un host pourra directement reprendre ces données séries par son USART ou au contraire préparer quelques instructions pour récupérer ces données.

N'aurait-il pas été possible de traiter en bufférisant les données précédentes ?
Peut-être, car durant le processus de comptage du temps, on accepte parfaitement toutes les interrupts. Tout dépendrait seulement de l'instant auquel la demande parviendrait dans le processus de lancement de la mesure.
Durant la seule mesure proprement dite c'est possible, car c'est une opération hardware pure. Mais juste avant on ne maîtrise pas l'instant d'arrivée de la demande relativement au processus.
Pendant la phase des calculs ça serait possible.
Une telle opération devrait alors invalider la précédente mesure pour raison de sécurité des valeurs et relancer alors le remplissage du buffer.
Les gains de temps en jeux sont faibles et les risques de fausses mesures assez importants
Alors restons simples.

6 Réalisations sur ACTARIS

Je ne reviens pas sur le choix de ce compteur qui présente un taux de démultiplication de 30, bien supérieur au modèle SAPPEL qui n'a que 18. (Cette valeur est principalement attachée au volume de la chambre de mesure).
Il est évidemment préférable d'avoir un maximum d'impulsions et c'est pourquoi les réalisations sont sur cette base de compteur ACTARIS.
Si le cœur du sujet est toujours la mesure de débit, j'ai procédé par tâtonnements car c'est au fil des différents essais que je suis arrivé à la solution finale d'un capteur qui conserve la fonction de comptage.
C'est donc un appareil peu conventionnel qui mesure à la fois des débits et des volumes

Vous avez pu voir là où j'en étais resté avec les disques codeurs sur une marque de compteur ACTARIS/SCHLUMBERGER.
Vous avez compris que j'ai fait la chasse aux éléments trop lourds pour limiter les couples résistifs, et ainsi ne pas avoir d'oscillations du fait que tout le mécanisme de comptage était enlevé pour loger le disque codeur et le capteur fourche.

Vous avez aussi compris que les ennuis d'oscillations rencontrés, avaient pour origine justement le retrait du mécanisme vis sans fin et galettes d'affichage.

Après réduction au plus juste du diamètre du disque codeur, j'ai sauté le pas et essayé de loger non plus un capteur fourche, mais une LED IR et un cellule IR correspondante, (Deux éléments démontés d'ailleurs d'un capteur fourche).

Cela n'a pas été trop simple, car la place manque sérieusement et il a fallu ruser. Le résultat est pourtant là et le disque codeur fait maintenant 11.75mm (photo en début d'article).
En effet au début du projet le disque codeur faisait 40mm puis il est passé à 22mm suite aux oscillations, et maintenant encore plus petit !.

J'ai même essayé d'utiliser un disque codeur de molette de souris… Ces codeurs ont 36 secteurs pour le modèle essayé, et pour un diamètre identique de 11.75mm.
Cependant avec une telle petitesse, la moindre vibration entraîne des variations incontrôlées dans un sens ou dans l'autre, aussi il est impératif à une telle définition de faire une détection en quadrature, ce qui est effectif sur les souris, d'autant que cette détection est impérative et native puisque la molette doit traiter le sens de rotation.
Cette solution est donc beaucoup trop fine pour être envisagée à mon échelle amateur, et dans un contexte très délicat de place disponible.

6.1 Conséquences du diamètre codeur

La diminution permanente du diamètre du disque codeur a entraîné une modification du signal, non pas en fréquence puisque le disque codeur utilise toujours 20 secteurs angulaires avec un nombre total de 600 impulsions par litre.
Ce signal s'est "avachi" et est devenu une piètre sinusoïde par une diminution de la dynamique du fait d'un éclairement global plus élevé à cause de la finesse des secteurs.

Il a donc été nécessaire de remettre en forme le signal dont on ne mesure que le palier négatif.
En effet l'entrée dans la logique du PIC est nécessairement sous forme logique.
Cependant le PIC utilisé, comme presque tous les PIC possède un comparateur que l'on va mettre à profit pour redresser les flans du signal.

Le disque codeur de 11.75mm a été réalisé comme indiqué dans l'article consacré aux circuits souples (voir cet article).
La colle utilisée n'est pas de la cyanoacrylate, mais de l'Araldite qui reste plus souple et surtout moins cassante.
Elle est plus difficile à mettre en œuvre pour l'étaler et éviter les bulles d'air mais aussi pour respecter une épaisseur à peu près constante, et la plus fine possible.

6.2 Circuit imprimé du PIC

Dans un cas comme dans l'autre, le tout petit circuit imprimé prend place en partie avant du totalisateur, que le montage soit avec ou sans les galettes du totalisateur.

Le connecteur LED/cellule est résolument mal placé car initialement, je ne pensais jamais pouvoir conserver la mécanique des galettes, aussi j'avais trouvé le passage central intéressant pour éviter de déborder et pouvoir connecter facilement la fourche sur le circuit imprimé proprement dit.

Mais puisque je conserve maintenant cette mécanique, je serai obligé de souder les fils et réduire la taille du nez de carte pour ne pas passer trop près des galettes.
C'est donc en deux phases distinctes que la réalisation se fait avec un connecteur d'essais, puis lorsque le montage sera assez stable techniquement, on soudera alors les fils et on pourra replier l'ensemble.

Il faut dire que je n'ai pas envie de refaire le CI pour une série de 2 appareils !!!
Vous noterez également que les modèles considérés ACTARIS (ou SCHLUMBERGER) ont des différences de forme de la partie blanche suivant l'évolution des états techniques, mais heureusement celles-ci n'impactent pas le principe ni le montage.
Il est fort probable que les nouveaux compteurs ITRON soient un peu différents, mais au vu de l'aspect extérieur, l'esprit semble conservé.

6.3 Circuit imprimé porteur de la LED/cellule

Ce circuit porteur LED/cellule n'existe que sur le modèle ayant le totalisateur présent. Dans le cas du modèle avec le capteur fourche, c'est seulement un petit étrier métallique qui maintient la fourche en place.
Ce circuit est uniquement un petit morceau d'époxy cuivre non insolé. Il est utilisé simplement comme support de la LED IR, ainsi que pour souder le petit support en laiton de la Cellule IR.

Dans un cas comme dans l'autre, il est nécessaire de fixer CI ou étrier pour immobiliser sans collage mais aussi pour assurer le démontage dans le cas où le mécanisme des galettes est conservé.
Des trous taraudés dans le fond de totalisateur avec des vis inox de 3 permettent la fixation d'un dispositif comme de l'autre.
Deux petites surépaisseurs triangulaires en fond de boîtier empêchent de placer le circuit à plat, mais également l'étrier. IL est nécessaire de les supprimer à l'aide d'un cutter.
Il ne sera pas utile de "massacrer" une partie du fond du totalisateur comme j'ai pu le faire Cela avait été réalisé pour voir un peu plus clair lors de l'appréhension du sujet.

Le circuit du PIC sera fixé au boîtier blanc par 2 vis inox et 2 colonnettes dans les deux cas, le plastique blanc sera percé de 2 trous taraudés à 3 mm pour cette fixation.

Bien entendu, le circuit imprimé du PIC est réalisé en CMS, mais vous pourrez aussi le faire en traditionnel, sans pouvoir cependant l'intégrer facilement dans le totalisateur par manque de place.

7 Les essais décevants

Après avoir déjà vérifié que les essais précédents ne correspondaient pas aux coups de pales de la pompe, (insignifiants) les irrégularités de valeurs transmises en ASCII à différents rythmes révèlent que les deux versions sont parfaitement instables.
Même avec un disque codeur de taille moyenne, et sans le mécanisme, l'instabilité est certes plus faible mais loin d'être nulle.

Bien entendu, il fallait le programme et des sorties ASCII pour avoir véritablement les preuves.
Les écarts mini / maxi enregistrés sont de l'ordre de la mesure. Évidemment ce n'est donc plus une mesure, c'est un fiasco !

Après avoir longuement réfléchi à ce problème, j'en arrive à la conclusion que le principe même est en cause. Pourquoi,
Avec un totalisateur, celui-ci fait office d'intégrateur pour le mouvement du piston.
L'idéal serait d'observer les phénomènes à la caméra ultra rapide, mais je n'en ai pas !!!

Avec un totalisateur, ce mouvement est très vite limité par la non réversibilité de la vis sans fin.
(Ceci est vérifié très facilement, car lorsque le totalisateur n'est pas en place, en tournant à la main la cyble, cela entraîne automatiquement le disque codeur.
Réciproquement, lorsque l'ensemble est sur le compteur avec l'aimant de la chambre de mesure, il est impossible de faire bouger la cyble.)
Le totalisateur joue alors le rôle d'intégrateur et la valeur moyenne au litre est alors stable.
La liaison magnétique est également un système trop "mou" pour garantir des temps stables, car il fonctionne par à-coups.

Voilà donc ma vision de ce projet.
Ce qui est dommage est d'arriver presque au terme pour s'en apercevoir, certes le petit disque codeur était trop délicat par sa finesse, et sa précision était évaluée comme problème potentiel, mais si il y participe, il n'est pas le centre du sujet.

On évitera également des problèmes en assurant une rotation parfaite (non voilée) du disque, car la modification de la distance entre LED et la cellule ajoute encore un peu d'huile sur le feu !
En effet, plus le disque est de grandes dimensions, plus il est difficile de réaliser une rotation sans faux rond mais surtout sans voile.
Il faut ajouter que la surface de référence est extrêmement petite puisque c'est la seule surface du petit pignon.

La vision du signal du photo transistor permet également de vérifier que l'on n'a pas d'effet de bord. Je viens justement de voir que cela peut être aussi une cause de problèmes.

8 Nouvelles dispositions

A la lumière de ces essais, je me voyais mal abandonner ce projet qui dure depuis pas mal de temps, aussi voici les dispositions que je prends pour réduire ces problèmes.

- On gardera le compteur ACTARIS pour ses 30 impulsions par litre.
- Abandon du disque de petite dimension, ce qui implique de fait l'abandon du compteur (totalisateur) associé.
- Reprise d'un disque de dimensions maximum avec un premier essai avec un disque de 40mm de diamètre. (On ne pourra pas dépasser 44mm à cause du diamètre intérieur de la partie blanche, on garde environ 1 mm de jeu)
- Création d'un canon avec épaulement pour supporter le nouveau disque codeur
- Modification éventuelle du programme pour obtenir (suivant les temps) la moyenne de plusieurs mesures. (À voir en fonction des résultats)
- Réflexion sur le moyen d'amortir le disque codeur, sans trop augmenter la masse (Frein à courants de Foucault ?) Une masse trop élevée pourrait endommager à la longue le pivot porteur de l'aimant. C'est aussi la raison qui fait qu'il est préférable d'avoir un COUPLE résistif qu'une masse (Diamètre important du disque).
- Réduire le voile et le faux rond du disque codeur au minimum
- Observer les signaux aux bornes du phototransistor.

9 Conclusions

L'espérance d'un débitmètre associant un compteur de volume s'envole à la lumière des derniers essais.

Des deux versions différentes de débitmètre, et je crois qu'il faut comprendre ces deux versions par la chronologie des essais et par la volonté d'avoir au besoin un compteur associé, ce qui faciliterait largement l'étalonnage et permettrait des mesures de débit, mais aussi du comptage, ce qui en ferait un outil complet d'analyse et de mesures. Hélas cette idée s'envole !

Un tel outil permet surtout d'étudier une consommation et les habitudes mais aussi d'assurer une régulation de débit pour mon panneau solaire.

J'ai surtout réalisé ces appareils pour réguler le débit primaire de mon panneau solaire, car c'est pour cette raison que je m'étais engagé dans cette voie de mesure de débit.
Il sera nécessaire d'attendre de nombreux mois avant la reprise de cette régulation solaire, car j'ai encore bien des essais complémentaires à faire sur ce débitmètre qui pose bien des problèmes difficiles à solutionner.

J'espère que cette réalisation vous aura intéressé par son aspect peu habituel et de réutilisation d'éléments qui finissent toujours à la casse. Une deuxième vie est toujours un plus que j'apprécie.
C'est aussi une réalisation avec des soubresauts techniques, et l'on revient finalement aux réalisations initiales.

Mais alors les oscillations ? A ce stade il faut attendre les essais finaux, mais je ne pense pas à la lumière de tout le chemin parcouru que ce soit le problème le plus important.

Les essais précédents sans le programme n'ont pas formellement mis en évidence l'instabilité, car la visu était seulement à l'oscilloscope et c'est seulement sur le dernier essai avec le programme et une sortie ASCII des valeurs que l'on peut véritablement se rendre compte des énormes problèmes.

C'est un fiasco ! Vite mon mouchoir ...

Chronique d'abandon d'un projet de débitmètre

Partager cet article