Capteurs SCLUMBERGER/ACTARIS/ITRON (Cyble) à courants de Foucault

Capteurs SCLUMBERGER/ACTARIS/ITRON (Cyble) à courants de Foucault

1    But et Utilisations
2    Spécifications
3    Le Schéma logique
4    Cyble et Partie courants de Foucault
4.1    Généralités Cyble et principe
4.2    La self et la fréquence
5    La gestion du Temps
6    Alimentation
7    Le micro contrôleur PIC 16F690
8    Les transmissions
8.1    Partie émission radio mode binaire
8.2    Partie réception (paramétrage)
9    Structure programme
9.1    Paramétrage
9.2    Commandes
10    Adaptation radio / PC
10.1    Le schéma actuel RS232
11    BRAY++ b et logiciels
11.1    Commande "B" (Binaire)
11.2    Commande "A" (ASCII)
12    Prochaines versions
12.1    Future version
12.2    Version simplifiée
13    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 ----->
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 projet avait commencé par un premier montage basé suivant le principe des battements de fréquence (Série de Fourrier), et qui n'avait pas donné satisfaction à cause de sa dérive en température. J'ai donc du l'abandonner. (Il était prévu à l'origine pour mesurer le débit du circuit primaire de mon panneau solaire). 
http://bricolsec.canalblog.com/archives/2010/09/15/19069451.html

J'ai repris récemment le sujet et j'ai ensuite essayé un principe opto par réflexion sur ce secteur argenté qui n'a pas donné de bons résultats à cause de la lumière du jour qui peut perturber (Délicat aux vitesses de scan nécessaires de travailler en modulation de lumière, et de toutes façons le procédé reste assez gourmand en énergie, même avec des LED haut rendement). (Montage avec PIC12F675).
(De plus tout aurait pu être anéanti si le constructeur mettait une couche de peinture noire sur la Cyble, ce qui est tout à fait envisageable, d'autant que certaines Cybles sont déjà tachées de façon native)

J'ai eu connaissance, depuis ces premiers essais, du principe utilisé par le fabricant, qui publie sur son site le principe des 3 bobines et qui expose clairement la mesure de la durée d'oscillations amorties…
Je sais faire cela, et je me suis donc lancé le défi d'arriver à quelque chose d'opérationnel. Il m'aura fallu près d'une année pour arriver à ce résultat qui est sur la bonne voie, mais j'ai dû faire l'impasse des 3 bobines et de ne traiter que les index (et non le sens).

Bien entendu ça n'a pas été tout seul sans autres précisions techniques (sans modèle à découvrir) et les écueils ont été nombreux et il y en a encore. Je les citerai, car c'est aussi important de les connaître que de retenir la bonne solution. (Un écueil est parfaitement visible dans cette photo, je l'expliquerai un peu plus loin...)

J'ai donc voulu refaire depuis zéro, ce qu'a fait ce  constructeur, avec cependant mes petits moyens techniques et un nombre d'heures de travail restreint, en regard de la puissance technique des bureaux d'études des grands groupes.
Je ne bénéficie bien entendu d'aucune aide, autre que de la seule description succincte du principe de la détection Cyble avec ses 3 bobines.

J'ai dû cependant déclarer forfait immédiatement sur le fait d'utiliser 3 bobines pour des questions de réalisation de selfs aussi petites dans un espace si petit. C'est la première concession de fait, car techniquement trop difficile à réaliser et à mettre en oeuvre.
Cette renonciation implique que la tête développée ne saura pas reconnaître le sens de rotation et qu'il sera impératif de placer un CLAPET pour éviter les problèmes de retour d'eau.
C'est une renonciation mais je la minimise, tout en sachant qu'au niveau AEP, l'installation d'un clapet NF anti-retour est obligatoire et que sauf dysfonctionnement de ce clapet, il n'y aura pas de conséquences sur le comptage lui-même.
Pour le reste, je crois que commencer par la description de ce que je voulais faire est essentiel pour bien comprendre les solutions techniques. Ce sera l'objet du premier paragraphe.

NOTA 1: "Cyble" est un nom générique déposé et appartenant à la Société SCHLUMBERGER/ ACTARIS/ITRON qui caractérise le principe du dispositif de capture des impulsions de comptage par courants de Foucault sur un petit secteur métallique de 120°(Cyble), sur les compteurs des marques citées ainsi que pour les marques associées.

NOTA 2: J'emploierai indifféremment le terme self ou bobine pour l'inductance qui sera le capteur situé au dessus de la Cyble

NOTA 3: "Cyble" désignera dans cet article le petit secteur métallique de 120° des compteurs de la marque et parfois même par abus de langage l'ensemble avec la self elle-même.

PS : La photo de tête d'article est un montage, car toutes les données de numérotation ont été "perturbées" ou effacées pour discrétion.

1 But et Utilisations

Définir l'index et les Tops Index est important...
L'index représente la valeur d'un compteur en termes de M3 et de litres. Les Tops Index sont des impulsions qui indiquent le passage d'un volume élémentaire de référence.
Le lien entre les deux est trivial, puisque l'index est simplement constitué de la somme de tous les tops Index !
Utiliser l'index ou les tops index ? Les Tops index permettent facilement de mesurer des débits avec le temps entre tops.
L'index est une valeur qui sert principalement à la facturation. Un débit à partir des index nécessite de faire la différence des index correspondant au temps.

Initialement ce montage était toujours fait pour mesurer le débit du circuit primaire de mon panneau solaire, mais je rejoins le métier AEP également et les relevés pour ce même type de compteur...
Trouver un système simple et peu onéreux pour relever automatiquement cette marque et type de compteur largement installé dans le parc AEP Français est utile pour les particuliers qui souhaiteraient utiliser leur PC pour lire l'index de leur propre compteur d'eau à distance, mais j'avais pensé initialement aux petites structures AEP qui veulent prendre le progrès en marche avec peu de moyens et qui ne veulent pas être prisonnières d'une marque.

J'ai pensé aussi que ce développement devait participer à bannir des "contrats captifs" avec une main mise de fait sur un système de relevé automatique par radio de seulement quelques grands groupes.
En effet choisir une marque de relevé radio implique de fait le choix d'un compteur, d'une tête radio pour ce compteur particulier ainsi que du dispositif de relevé informatisé (Terminal portable).
Bien qu'il existe des têtes radio "déportées", qui permettent de mettre la radio sur un compteur d'une autre marque, le coût engendré est si élevé qu'il est financièrement impossible de choisir cette solution. (En effet Il faut toujours le capteur spécifique de tops du compteur)

Mon but est donc double : Aider les particuliers pour qu'ils puissent réaliser sur PC leur suivi individuel de consommation ou toute autre application (Contrôle de débit de panneau solaire par exemple), mais aussi pour les petites unités AEP (Syndicats ou Communes), de briser cette chaîne qui oblige à ne garder qu'un seul constructeur pour son parc de compteurs, et permettre ainsi à ces petites structures AEP d'avoir accès au relevé radio à moindre coût, sans être pieds et poings liés à une marque de compteur.

Pour ce faire, d'autres têtes pour les autres grandes marques de compteurs sont à développer (J'ai donc réalisé celle-ci, pas très facile mais il faut aussi finaliser et industrialiser cette réalisation et continuer sa mise au point, et même la perfectionner pour accepter les retours d'eau et donc gérer le sens, ce qui serait tout de même "plus logique". Le projet est en cours mais il demande encore beaucoup de travail, peut être au niveau du temps de 10ms un peu juste au niveau interrupts.
(C'est la raison pour laquelle je suis passé en version 1-16 logiciel et Rev 10 du schéma avec une réaffectation de 2 I/O pour pouvoir essayer ultérieurement l'ULPWU (Ultra Low Power Wake Up))

D'autres têtes sont plus simples sur la base du magnétisme et seront aussi à développer.
J'ai créé aussi un petit émetteur récepteur radio qui sera connectée à un PC portable, et à partir de simples fichiers TXT, tout un chacun pourra exploiter les données sur son informatique de gestion.
Cet ensemble se veut le plus standard possible, ce qui est un gage de liberté de choix.

Alors, ce n'est pas moi qui vais continuer ces développements complémentaires, mais bien une société directement liée à l'eau potable, et qui veut aussi prendre sa part du marché des relevés radio toutes marques de compteurs confondues, mais aussi des futurs concentrateurs collecteurs de données.
(Société ou distributeur de matériels AEP mais jamais un grand fabricant de compteurs évidemment !)

Vous aider à poursuivre et vous expliquer plus en détails ce que j'ai réalisé est dans mes possibilités.
Si cela vous intéresse, vous pouvez simplement prendre contact avec moi par le blog (Ce blog est modéré) en précisant simplement si vous désirez la discrétion (Je ne publie pas dans ce cas).

(Je ne souhaite jamais être joint par le lien "Contacter l'auteur" qui m'oblige à dévoiler mes coordonnées pour répondre et je tiens plus que tout à garder mon anonymat).

2 Spécifications

Les spécifications découlent d'une partie de ce qui vient d'être dit précédemment, et on retrouvera cette dualité entre particuliers et professionnels.
Ces spécifications sont déjà bien étoffées peut-être trop déjà ? Elles sont implémentées.

- Relève automatique des compteurs SCHLUMBERGER, ACTARIS, ITRON et des marques associées équipés d'une Cyble (Petit secteur "argenté" de 120° angulaires faisant un tour par unité de volume, le litre présentement !)
- Tête équipée d'un micro contrôleur Microchip PIC16F690
- 3 piles R6 de 1.5V pour une tension opérationnelle comprise entre 5.12 V et 2.7V (0.9V/elts)
- Régulation de tension permanente à 2.5V avec mesure et suivi tension des piles dont un bit "Low_Bat"
- Programmation RS232, RX par sonde LED et aimant vers une cellule opto associée à un ILS
- Envoi par radio de toutes les données (Pas d'afficheur) Vitesse de transmission 2400bps
- Connecteur de programmation tronçonnable après programmation ICSP du PIC
- Assure l'envoi de TOPs d'Index sur une sortie dédiée en Open drain
- LED de signalisation à usage divers et possibilité Buzzer ou autre
- De jour Envoi par radio de l'index en cours (6+3 caractères) et de divers indicateurs, toutes les 10 secondes entre 7 heures et 19 heures.
- De nuit Envoi par radio de l'index en cours et de divers indicateurs toutes les minutes entre 19 heures et 7 heures (Économies d'énergie)
- Peut assurer deux relevés à date fixe par année (Date à Zéro évite la comparaison)
- Horodatage des incidents à la minute près, avec reset automatique pour certains
- Historique des incidents en EEPROM (64 entrées possibles)
- Maintenir une autonomie énergétique de 10 à 15 années
- Surveillance d'une fraude magnétique, pour prendre le contrôle
- Contrôle d'une tentative de fraude à la feuille de cuivre (blocage des oscillations)
- Surveillance des fuites en cours
- Surveillance des fuites AYANT EU lieu (Correction par l'abonné)
- Surveillance des compteurs bloqués
- Dump RS232 de l'EEPROM
- Code de sécurité constructeur (inaccessible)
- Code de l'entité exploitante sur un octet
- Permettre le réglage du nombre d'oscillations en production
- Transfert en mode binaire pour un exploitant garantissant une certaine discrétion, la plus grande autonomie et la sécurité des informations avec une parité verticale associée.
- Transfert en ASCII pour les particuliers (Autonomie moindre)
- Reprise du contrôle d'une tête déjà installée (Suite à un changement de compteur par exemple)
- Verrouillage durant une heure de la tête avant une nouvelle écoute en cas de tentative de commande sans donner le code constructeur (3 commandes avec code)
- Gestion des dates, heures et années bissextiles (2100) avec correction mensuelle automatique
- Effacement possible en cours de saisie
- Possibilité de saisie partielle des données
- fréquence maxi de 8 Hz de la Cyble (soit 28.8 M3/h pour l'unité du litre)
- 1 scan de position toutes les 10 millisecondes
- Émission spontanée toutes les 10 secondes d'une trame RS232 de 29 caractères binaires ou 57 ASCII
- Émission d'une trame plus longue (en binaire) toutes les 8 heures comportant en plus la valeur précise de la tension des piles.
- Paramétrage direct depuis un PC avec RS232 ou émulation RS232 depuis USB avec convertisseur USB/RS232
- Numéro de compteur composé de 6 caractères ASCII alpha et de 6 caractères numériques
- Saisie index sur 6 digits pour les M3 et 3 digits pour les litres ou sous unités.
- Saisie des jours de relevé à date fixe en mois et jour avec contrôle des jours pour les années bissextiles (le transfert d'index a lieu à 0 Heure)
- Maintien des index automatiques à date fixe durant une année
- Toutes les saisies sont contrôlées en alpha ou numérique (Sauf les séparateurs)
- Parfaitement stable en température jusqu'à 55°C
- Possibilité de verrouillage du code assembleur.
- Réduction maximale de consommation avant première mise en place (2 µA)
- Consommation moyenne SANS transmission 19.6 µA en mode Binaire
- (Le code source ne sera pas distribué pour l'instant pour les raisons évoquées) mais le .HEX pourra l'être d'ici quelques temps….

3 Le Schéma logique

Il n'a rien de très particulier hormis la zone de la self qui est rappelée à un potentiel intermédiaire, ce qui évite l'emploi d'un comparateur externe au PIC. Tout le reste est très classique. Voir ce qui suit pour les détails.

4 Cyble et Partie courants de Foucault

Voir pour plus de précisions l'article Wikipédia sur le principe des courants de Foucault. Vous aurez noté que dans ce cas c'est bien la variation du champ magnétique qui est à l'origine des pertes et que ce n'est pas le déplacement de la Cyble qui crée ces courants.
Ces courants engendrent théoriquement en retour une réaction sur la self ?
(Bien qu'il y ait aussi ce phénomène conjugué du déplacement possible de la Cyble, mais la vitesse de rotation est si faible que rien ne se produit véritablement, du moins je le pense (?), car aucun freinage substantiel ne devrait être vraiment mesurable ?)
http://fr.wikipedia.org/wiki/Courants_de_Foucault

4.1 Généralités Cyble et principe

La Cyble est donc ce petit secteur argenté de 120°, dont la rotation d'un tour représente un volume de 1 litre passé. (Pour les classiques compteurs d'abonnés de DN15. Voir photo).

La nature du métal Cyble m'est inconnue, mais n'a pas une grande importance sur le principe. C'est un métal  inoxydable (Non ou très faiblement magnétique ?), et en ce sens je supposerais volontiers un acier inoxydable genre 304 comme pourrait en témoigner quelques traces de corrosion superficielle irisées.

C'est de la position de ce petit secteur par rapport à la self (qui sera située juste au dessus), que l'amortissement des oscillations va être plus ou moins important.
On remarquera d'emblée que sans la Cyble, OU la self complètement en l'air, le résultat est identique et donc qu'à l'aplomb de la Cyble, rien ne perturbe  l'amortissement

Un échelon de tension de 250 µs est appliqué toutes les 10ms à l'ensemble oscillant constitué de la self L1 et du condensateur C1 (Par le PORTC Bit7).
Suivant la position du secteur argenté sous la self, le nombre d'impulsions sera plus ou moins important.
C'est donc ce principe physique même qui permet cette réalisation

La création de tops se réalise par un pseudo trigger de Schmitt (Réalisé par programme) avec un seuil haut à 20 impulsions et un seuil bas à 16 impulsions.

Chaque franchissement de ces seuils, construit pallier par palier, le signal Top d'index et réalise +1 sur la valeur numérique de l'index à chaque front positif.
Cette marge des hystérésis peut paraître un peu étroite, mais elle semble suffisante.
Cependant un essai sur la durée m'indique une déviation et il faudra en trouver les raisons. (J'ai quelques interrogations sur la synchronisation nécessaire de 2 cycles CPU pour les Timers...)

On notera également un seuil de fraude à la feuille de cuivre de 8 impulsions. Les nombres d'impulsions maxi devront être réglés à 25 avec un potentiomètre par le programme de réglage inclus dans le programme de base de la tête (Car l'oscilloscope modifie ce nombre à cause de sa sonde de mesure : 2 impulsions environ).

Le potentiomètre est alors mesuré et remplacé par 2 résistances fixes série totalisant la même valeur. Ceci permet d'éviter un potentiomètre qui pourrait être noyé dans de la résine suivant les cas et procure une meilleure stabilité dans le temps mais aussi en température.
Tout cet ensemble de valeurs reste parfaitement stable jusqu'à 55°C. (Cette fois c'est bon !)

La sonde de l'oscilloscope modifiant sensiblement ce circuit, c'est seulement une commande de service du programme de la tête qui peut renseigner de façon exacte sur le nombre d'impulsions reçues et donc permettre des réglages corrects.

Les impulsions sont donc des portions positives de sinusoïdes qui dépassent la valeur de seuil fixée par le point bas de la self. Attention que le nombre d'impulsions durant un temps donné ne correspond pas nécessairement à la fréquence du circuit oscillant car ce sont seulement des trains d'impulsions qui peuvent se terminer avant les 250 µs "d'écoute".

Ces impulsions peuvent être très fines et très brèves et un comparateur externe avait été utilisé initialement. J'avais du mettre alors un comparateur rapide (MAX985) avec des consommations complémentaires etc…(J'étais vers 300 KHz à cette époque)
Finalement je suis revenu avec une fréquence plus basse, à la plus grande simplicité et c'est l'entrée logique de T0CKI qui reste maître de la situation avec son seuil logique standard.

Le signal dans son ensemble est très particulier puisqu'il est rappelé à un potentiel intermédiaire, permettant de s'adapter au seuil de l'entrée logique du PIC et de contrôler le nombre d'impulsions. (Merci au copain Riri pour cette idée qui simplifie grandement le schéma)

Le compromis important à surveiller à ce principe est de ne pas chercher à mesurer TOUTES les impulsions jusqu'à un très faible niveau. Pourquoi ?

En premier lieu, il peut y en avoir beaucoup et même dépasser le comptage à 255 maxi, mais plus simplement parce que dans cet état, le micro contrôleur doit nécessairement être actif pour compter et qu'il consomme de l'énergie (TMR0 et y compris dans une moindre mesure les résistances R7 +P1--> 2.5V/5.7M=438 nA). Il y a donc lieu de réduire au plus juste le temps de mesure des impulsions à 250 µS.

Passé ce temps, l'échelon de tension du circuit LC est coupé et la tension diminue alors progressivement du point médian vers le zéro, durant 10 ms précisément et jusqu'au prochain cycle de 250 µs.
Cette particularité explique la forme très bizarre du signal dont seule la petite partie positive du début des alternances est utile si elle dépasse le seuil logique de l'entrée T0CKI du PIC.
(Durant le comptage, le palier est parfaitement horizontal)

(L'oscillogramme ci-contre n'est que le grossissement de la partie de début des oscillations de la courbe générale ci-dessus. Cyble en dehors du champ de la Self)
On constate une légère modification du signal à l'instant de la coupure de l'échelon qui peut s'expliquer par le fait que le potentiel de sommet, fixé préalablement par T1, est devenu à la coupure, esclave des oscillations et de l'instant de cette coupure, l'amortissement global a pu changer aussi, bref...c'est du détail !

Le 3 ème oscillogramme (le montage photo juxtapose avec plus ou moins de précision) la différence des courbes d'amortissement avec (cyan) et sans Cyble (noir). (En Cyan, la self est à l'aplomb de la Cyble ---> amortissement).

Générer un échelon de tension plus court que 250 µs aurait conduit à une forme support décroissante exponentielle des impulsions dont la détection de seuil aurait été de ce fait très incertaine.
C'est pourquoi il faut maintenir cet échelon de tension durant tout le temps d'une mesure.
(La consommation (qq centaines de nA) reste seulement liée à R7 et P1 hormis la charge initiale des condensateurs C8 et C2 qui ne sont pas totalement déchargés à la fin des 10 ms.)

Le nombre d'impulsions est donc traité de façon autonome par le registre TMR0 utilisé en compteur (PIC actif), aussi pendant ce temps établi par le Timer 2 (250µs) cette fois, (En interrupt) le programme travaille au calcul/contrôle des valeurs précédentes de mesures, ce qui permet de ne pas perdre son temps à attendre bêtement durant 250 µs et toujours dans l'optique d'une réduction de la consommation.

Vous noterez aussi qu'il n'y a pas de surtensions réellement possibles, car ce n'est pas la coupure d'un circuit selfique. (Seule une coupure immédiate lors d'une des premières alternances pourrait générer une tension supérieure à l'alimentation, mais ce cas est contrôlé par la durée de 250 µs et reste donc impossible, et les protections intrinsèques du PIC sont largement suffisantes

Enfin pour terminer cette explication du principe, le fait de mettre un potentiel continu non nul en pied de la self implique de prévoir le libre passage pour le courant alternatif (à 100 KHz).
C'est donc la raison des condensateurs C2 et C8 qu'il faut voir suivant le même principe qu'un atténuateur compensé, -comme dans une sonde d'oscillo- (Appelons le "Pont diviseur compensé").

NOTA : Lors de la création d'un modèle simplifié, je me suis aperçu que ce pont diviseur compensé est en réalité beaucoup plus complexe que je ne le pensais.  Ceci étant il faut dans ce cas distinguer les périodes en jeu et réfléchir en termes impulsions et récurrence des impulsions. (Je pense que je ferai une explication plus complète de cette partie lors d'un prochain article dédié ou sur le futur montage simplifié).

En effet toute modification des valeurs entraînerait la déformation de la courbe "porteuse" des oscillations amorties et principalement du palier horizontal de mesure, ce qui  perturberait les seuils de détection, soit en augmentant les impulsions soit en les diminuant.

Ces deux condensateurs sont donc indirectement importants et participent à la bonne constance de la valeur du pseudo zéro des oscillations.
Je précise tout de même que le courant qui circule (alternativement) dans la self est bouclé par R7 et C2 et bien entendu C1 qui est le principal "actionnaire" de la fréquence.

Ce principe de détection est donc composé d'un MOSFET T1 qui délivre l'échelon de tension à front raide qui va charger C1 au travers de la self de mesure et de C8.
Le circuit oscille ensuite librement avec C1, L1 et C2.
Le potentiel de pied de la self est donc constant aussi bien en continu par les résistances R7 et P1 qu'en alternatif avec C2 et C8, cet ensemble constituant le "pont diviseur compensé". La décharge de C2 et C8 (Après la coupure de tension par T1) dans leurs résistances correspondantes débute la décroissance exponentielle à la fin des 250µs.
Cette décroissance ne sera d'ailleurs pas totalement terminée après 10ms puisqu'il restera encore environ 150 à 200 mV (Zéro volts que l'on n'atteindra donc jamais). On repartira donc de cette valeur pour le prochain cycle de 10 ms.

Au vu des dimensions du secteur de la Cyble, et de celles de la self, il est certain que le diamètre de la self aura une incidence sur la répartition du nombre d'impulsions en fonction des degrés angulaires parcourus par la Cyble.

(La courbe du bas résulte très certainement d'un déplacement axial de la Cyble en cours de mesures, car je ne pensais pas la Cyble si mobile axialement -avec un jeu qui est loin d'être négligeable-)

Le facteur de forme des impulsions en fonction de l'angle, dépend à la fois du diamètre de la self, de l'hystérésis programme, mais aussi de l'angle précis de la Cyble. La Cyble n'a que le ~1/3 des 360°. (120° non vérifiés)
Les courbes me semblent donc "normales"

(Mesure faite, la Cyble ferait ~108/110° et non 120° ? )

Je dois ajouter que ce dispositif est réputé énergivore, car il nécessite de scanner à une vitesse élevée.
Ce nombre de scans important pourrait être largement diminué dans le cas de 3 ou 4 selfs qui travailleraient en séquences.
Dans ce cas le passage de la Cyble devant une self déterminerait automatiquement à la fois le sens et la position de la Cyble (Fixe,  Av ou AR).
(Pour rappel ce choix d'une seule self découle de la difficulté de trouver des selfs de très petites dimensions, et de plus, les interactions entre selfs seraient à craindre et cette étude pourtant très intéressante dépasse mes moyens immédiats. (Peut-être un jour ?))

Dans les particularités remarquées du système, je me suis aperçu que la Cyble peut bouger un peu verticalement (axialement)  (Moins de 1mm mais c'est déjà beaucoup) et que la distance étant importante dans la détection, il faudra faire très attention aux compteurs placés dans des positions autres qu'horizontales (Possible pour les compteurs volumétriques), car les valeurs de base pourraient être différentes. (Je n'ai pas prévu d'auto-apprentissage pour ce cas)

Dans ce même esprit de plusieurs selfs, j'avais essayé au tout début, la self en dehors de son contexte de compteur, avec succès ! (Et après de multiples échecs préalables voir § ci après).
Pour le premier circuit imprimé j'ai fait comme à l'habitude un plan de masse partout où c'est possible car cela m'évite quelques problèmes de parasites ou de diaphonie et me permet d'économiser un peu de perchlorure de fer.
Au montage, j'ai réussi à placer la self précisément sur le trajet du secteur de 120°, mais les résultats étaient totalement différents et j'avais un amortissement conséquent incompréhensible !

J'ai déjà pratiquement donné en quelques lignes ci-dessus, la raison… vous avez trouvé ?
Oui j'avais commis une erreur fondamentale car le plan de masse qui entourait la self et bien cela c'était l'équivalent d'une spire en court-circuit d'un transformateur et donc de pertes de Foucault dans une pseudo Cyble !!!!
Un transformateur n'apprécie pas du tout cette liberté d'usage d'un plan de masse...

Alors abstenez vous de remplir cet espace de dispositifs conducteurs (Même de simples "runs"). Les connexions se feront par le dessus et assez loin de préférence de même que tout autre composant sera à écarter de la zone d'influence de la self.

C'est également pour cette raison que je crains des interférences entre selfs dans le cas de 3 selfs comme dans le montage du constructeur. Ceci confirme que dans ce cas, celles-ci devront être très petites et cela est peut-être incompatible avec la fréquence que j'ai retenue.
J'entrevois également la nécessité de blinder chacune des selfs dans cette éventualité… Alors forcément ça complique tout !
Même si les circuits des autres selfs restent "ouverts", les pertes par proximité, dans le cuivre des bobinages seront bien réelles sans blindages appropriés...
Ne faudrait-il pas penser à des selfs de type "pot ferrite" avec un flasque manquant et noyau et bobine affleurants, car cela réduirait sensiblement les interactions, au moins en partie verticale, mais pas au niveau de la "vitre" de la Cyble.
Une structure un peu identique à un "moteur" de haut-parleur dans lequel le champ de fuite serait concentré au niveau de la vitre de la Cyble. Finalement un entrefer réduit, ce qui n'est pas le cas à ce jour.
(Je ne sais pas réaliser ce type de pot ferrite pour essayer, car c'est trop fin et je n'ai ni  la ferrite correspondante ni l e mandrin ad'hoc.)

4.2 La self et la fréquence

Je vois déjà votre mine déconfite car ces composants restent la misère des électroniciens, car c'est toujours la panique pour bobiner, mesurer et avoir un Q de bonne valeur. (Pas de fil émaillé ou de Litz, pas de noyau ou mandrin….!)
Bien évidemment, les dimensions de la self doivent être réduites pour être en regard de la Cyble, et toute liberté n'est pas donnée, c'est pourquoi il faut de la ferrite !

Sur la photo ci-contre quelques uns des nombreux tâtonnements toujours trop hauts en fréquence, justifiant la ferrite et de "fouiner" tous azimuts..

Non rassurez vous, cette (une) self  existe toute faite et elle est présente dans des éléments que vous utilisez tous les jours, je veux parler des lampes à basse consommation (LBC)

La self la plus appropriée pour travailler à 100 KHz est de 4.7 ou 5 mH et c'est déjà une valeur assez importante qui nécessite un noyau ferrite pour garder des dimensions acceptables.
Mais sans avoir véritablement essayé avec assiduité, je pense que les modèles subminiatures de 2.75mH devraient aussi convenir avec une capa C1 de l'ordre de 1nF ( à confirmer ! 3 modèles en haut à droite sur la photo ci-contre).
De ce que j'ai pu lire sur un tel sujet, il y a lieu de privilégier une valeur de self assez élevée avec un condensateur plus faible (Sans pourtant entrer dans des valeurs extrêmes)
Vous trouverez assez facilement dans ces lampes et plus difficilement ailleurs car elle fait partie des composants utilisés en très grande quantité et n'est donc pas d'usage courant ailleurs. Il y a des milliers de marques de LBC et il faut chercher un peu…

La forme est importante (sorties radiales impératives et noyau ferrite en "I" majuscule)

Attention en ouvrant les LBC avec un canif de ne pas se le planter dans la main, ni que la lame ne se replie, ni, ni, ni,  !!!, ni de casser le tube fluo ! (C'est la même chose qu'avec les huîtres et un tendon est si vite sectionné!!!)

Ces selfs sont parfois marquées en clair, mais le plus souvent sans aucune inscription et il faut donc les mesurer ! Pour ma part j'ai un Q mètre et c'est donc assez facile, mais il existe des ponts "RLC mètres"…
Seules les selfs à sorties radiales (comme la photo ci-dessus) conviennent.

On peut trouver 472K ou 472 (c'est identique) comme pour les condensateurs et exprimés en µH soit ici 4700µH
On peut aussi avoir 4.7mH cette fois avec l'unité milli Henry ou 5 mH
On peut aussi....ne rien avoir ou un N° de produit !!! (Une indication qui vaut ce qu'elle vaut et hors de toute publicité, Philips utilise souvent ce type de self de 4.7mH et plus particulièrement dans les petits culots à vis. Sur la centaine de lampes dépouillées je n'ai trouvé qu'une seule self coupée (Fil cassé à raz du picot)) C'est un composant intrinsèquement robuste sauf au niveau des connexions avec les picots et vous devrez faire attention  lors du dessoudage du composant pour ne pas casser à raz, le fil parfois très fin (6/100)!

Comment sont elles faites ? Elles sont bobinées directement sur le noyau ferrite incluant 2 flasques dont l'un porteur des picots de raccordement (Un peu fragile car la colle céramique ne fait pas tout !).
Mais ceci étant tout fait, voilà une sacrée épine du pied d'enlevée. Un petit merci à Androclès s'impose !

Ce n'est pas fini pour autant, car vous devrez également égaliser la face en regard de la Cyble avec un cutter pour enlever le trop de gaine thermo ou de plastique qui tient lieu "d'emballage de protection" au bobinage, de façon à ce que la face ferrite soit bien plane et puisse être en regard sur la "vitre" de la Cyble, et au plus près.
Une distance minimum est extrêmement importante, car cela conditionnera l'amortissement.
Plus la distance sera élevée, moins l'action de la Cyble sera importante, or il faut pouvoir discriminer avec et sans la Cyble. C'est là toute la délicatesse du procédé !

Vous avez aussi compris que la forme des lignes de force va se modifier au fur et à mesure de l'intersection d'un cylindre (Self) et d'une ligne droite (Rayon de la Cyble).
Cette "facétie" engendrera un rapport cyclique qui sera compliqué à déterminer avec précision. (Cela n'est pas très important mais permettrait de mieux comprendre avec les lignes de force : Avis aux férus de magnétisme HF)
J'ai essayé de modifier la face de la self en regard de la Cyble en laissant seulement le noyau et en meulant au diamant un flasque pour réduire cette surface au minimum, mais ce fut un échec car on casse la ferrite plus qu'autre chose et les impulsions sans aucun amortissement, ont été réduites significativement à cause d'un plus mauvais coefficient de qualité (Q).

J'ai cherché en vain sur Internet les lignes de force de tels composants ferrite avec 2 flasques…! Je n'ai rien trouvé chez aucun constructeur, mais je suis très intéressé pour voir, car je n'ai pas pu mettre vraiment en évidence ce point pourtant important (Et encore plus avec plusieurs selfs !)
Bien que cela fonctionne bien, je vous invite à faire attention à certaines selfs qui sont pratiquement des pots ferrite fermés, et donc avec très peu de fuites magnétiques. Or ce sont ces fuites qui sont la clef de ces courants, alors toutes les réalisations de selfs ne sont pas bonnes pour cet usage.

Pourquoi ce choix de la fréquence de 100KHz ? Regardez le datasheet du PIC, la fréquence maxi de l'entrée T0CKI ne doit pas dépasser 1 MHz environ (Pour 4MHZ).  Autrement Il pourrait y avoir des erreurs dans le comptage.
Mais monter très haut engendre des problèmes collatéraux que j'ai pu rencontrer à 300 et 500 KHz. Ainsi la largeur des impulsions est déterminante, et certaines impulsions trop étroites peuvent être oubliées.
Cela a aussi été une limite lors d'essais précédents avec un comparateur "standard" (Il avait déjà fallu utiliser un comparateur rapide)
Cette fréquence est donc un compromis global qui satisfait aussi bien l'entrée PIC T0CKI, que la self elle-même, et qui permet aussi un amortissement significatif en présence de la Cyble.

En effet un circuit à cette fréquence peut avoir un coefficient de qualité Q (Q=Lw/R) assez élevé en l'absence de courants de Foucault. Des fréquences plus élevées donnent souvent des Q plus faibles et limitent donc la variation lors de la présence de la Cyble.

Attention également à cette distance entre la self et la Cyble (partie "argentée"), car vous ne pouvez pas la maîtriser puisque le compteur est ainsi fait et que vous n'avez  pas le droit de le modifier sous peine de graves ennuis (Du moins pour les compteurs AEP). Le flasque de la self (Opposé aux connexions  bien entendu) doit donc être placé directement contre la "vitre"  de la Cyble et surtout pas au dessus du circuit imprimé, car cela diminuerait considérablement l'amortissement lors de la présence de la Cyble sous la self.

Cette fréquence n'est pas spécialement critique, mais il faut s'y ranger pour toutes ces raisons.

Des selfs plus petites existent dans certains modèles de LBC mais elles font 2 ou 2.75 mH et il faudra ajuster le condensateur C1 en conséquence pour avoir cette fréquence. Le Q est souvent plus faible.
(J'envisagerais plus ces modèles pour des têtes radio à 3 selfs…)

5 La gestion du Temps

Le relevé à date fixe implique qu'une horloge précise soit présente au niveau de la tête radio. Ce point est extrêmement lourd de conséquences.
En effet il faut donc gérer le temps en termes d'années, mois, jours, heures et minutes. (Les secondes bien que présentes ne participent pas à l'horodatage pour des questions de consommation d'énergie, car chaque caractère transmis a un coût énergétique.)

Le temps implique donc le fonctionnement permanent d'un oscillateur précis.
Initialement et pour l'anecdote, je me suis fait d'ailleurs piéger par un ancien montage alimenté par le secteur et j'avais mis un CD4060, pour compter le temps avec la précision de la demi seconde.
Je n'ai pas vérifié les consommations du circuit et je ne pensais pas qu'il utilisait autant d'énergie en tant que CMOS (Quelques centaines de µA à priori !).
(J'ai "droit" pour 15 années de fonctionnement de la tête radio à un courant équivalent de 25 µA permanent, or ce 4060 dépassait très largement cette valeur et j'ai du impérativement abandonner cette solution !)

Pour la partie des mesures, le temps est organisé ainsi :

Les impulsions issues des oscillations sont donc comptées par le Timer0 utilisé en compteur à 256 maxi. Le temps consacré à ce comptage est déterminé par le Timer 2 par 250 µs fixes.
Le temps entre mesures est calibré par le Timer1 pour 10 ms précises. C'est la fin du Timer1 (Interrupt) qui réinitialise celui-ci pour une période identique, mais relance également le Timer2 et alimente le circuit oscillant par T1. (identique mais ajusté à la seconde)
Le timer 1 piloté par un oscillateur externe à 32.768 KHz est donc le "gardien" du temps et assure le réveil du PIC si il ne l'est pas déjà. Mais le problème est qu'il faut répondre à cette interrupt en moins de 30 µs faute de quoi on risque de perdre une unité de comptage du temps de 30.518 µs.

Autre problème important, il faut aussi accorder le système binaire du temps avec le système décimal de comptage du temps. Il faut donc obtenir 10ms précises pour une horloge temps précise. Or ces divisions ne tombent pas juste et pour régler cette correspondance des bases de calculs, le Timer1 sera tantôt ajusté à -327 puis -328 pour obtenir une précision globale la plus proche au niveau de la seconde.
En effet, 327*30.518=    9 97938ms et 328*30.518=10.009904 ms

La "charnière" la plus proche est calculée par OpenOffice et détermine 66 fois 327 puis 34 fois 328, ceci pour une seconde de temps ! Le rattrapage à la seconde bien qu'un peu moins souple que sur une durée plus grande devrait suffire. Il évite de devoir "traîner des corrections" en permanence.

Ces éléments s'approchent seulement d'une valeur exacte de la seconde, aussi il est nécessaire de réaliser une correction théorique de temps de 26 secondes tous les mois.

Il est également prévu de pouvoir faire une correction statistique (Complémentaire mensuelle ou à l'année) à cause que dans des cas très limites "d'encombrement des interruptions", les 30µs de temps maxi de réponse à une interrupt TMR1 pourraient être éventuellement dépassés.

Ceci représente toute la difficulté d'un manque de possibilités pour arriver à concilier tous les impératifs de temps.

Vous aurez également saisi qu'il n'est pas possible d'avoir un deuxième oscillateur dédié (OSC1 et OSC2 seulement), et que l'on ne peut pas non plus travailler au delà de 4MHz à cette tension de 2.5V

Suite aux essais longs qui ont donné une forte divergence du temps, je suis persuadé que ce système est trop délicat à gérer et il me semble nécessaire de reprendre cette fois le problème à l'envers en
trouvant une fréquence divisible par 2 et 10 et éviter ainsi toute cette salade bien délicate à "surveiller".

Cette toujours délicate gestion du temps est imposée par le relevé à date fixe (Voir l'article dédié à ce sujet)
On voit donc que cette très simple comparaison de dates prend une allure démoniaque à cause de la consommation d'énergie pour maintenir la date et de la précision requise pour rester acceptable durant 10 à 15 années.

Je n'ai pas dit non plus que l'abandon du CD4060 pour l'oscillateur interne au PIC s'est soldé par une consommation "raisonnable" cette fois mais tout de même bien réelle puisqu'il faut 6 µA permanents pour cette fonction d'oscillation temps. (Valeur à confronter au 25µA moyens maximum autorisés pour 15 années)

Je m'aperçois également à la relecture de ce paragraphe qu'il aurait peut-être été judicieux d'utiliser RA0 en ULPWU (Ultra Low Power Wake Up) pour assurer le délai de 10ms qui n'a pas besoin d'une précision absolue contrairement au temps… Mais c'est fait !
Et c'est la preuve qu'il est très difficile de faire bien du premier coup. J'ai donc préparé cette modif à la fois sur le schéma et sur le plan d'implantation.
Cette possibilité ULPWU est réalisable très simplement, car il reste des I/O disponibles…On verra la suite des évènements…! J'ai tout de même préparé cette possibilité en faisant cette ultime modif du CI.
Je ne la mettrai pas en oeuvre maintenant, mais elle est prête et j'ai essayé (La courbe de RA0 passe à Zéro et est presque une décroissance linéaire mais beaucoup plus courte que la courbe exponentielle décroissante.

Notez que 10 ms de temps de scan n'ont pas besoin d'une extrême précision, ce qui n'est pas le cas du calendrier et qu'aujourd'hui ce sont les 10 ms qui assurent à la fois la récurrence des scans et l'horloge temps…
J'ai tout de même essayé l'ULPWU (sans interrupt) et avec 1 nF on arrive à peu près à 10ms.

6 Alimentation

Pour économiser, économiser, économiser la consommation, j'avais démarré le projet sans régulateur avec seulement 2 piles  et à force de compenser tel élément à cause de la variation de tension au fil de l'usure des piles, j'étais arrivé à une compensation permanente de telle ou telle valeur et cela devenait une usine à gaz (ou une bouteille à encre) et souvent impossible à mixer avec d'autres restrictions.

J'étais toujours "serré" par les tensions trop faibles ou incompatibles et j'ai dû me rendre à l'évidence de la nécessité absolue d'une régulation de tension, principalement au niveau des seuils, soit avec le PIC soit au tout début avec le comparateur dédié à la sélection des impulsions des oscillations amorties..

J'ai donc du me résoudre à trouver un régulateur, et manque de chance, bien qu'il soit particulièrement sobre Qs=2µA, il n'existe pas de modèle à 2 Volts exactement. Pas de chance, mais c'est un produit particulièrement bien. Cela a une conséquence sur le nombre de piles…
Le montage est donc maintenant alimenté par 3 piles R6 de 1.5V. Ces piles devraient assurer une autonomie de 10 à 15 années sans que je puisse préciser vraiment à cet instant.

Le régulateur MCP1702-25 de 2.5 V fixes est actif en permanence et consomme 2µA typique pour 5 mA maxi de débit.
Il faut aussi que ce régulateur qui a un dropout inférieur à 50mV pour un courant de quelques mA puisse être alimenté à 2.05V…! Ce n'est pas le cas puisqu'il lui faudra au moins 2.7V.
Ceci explique que le montage fonctionnera avec certitude jusqu'à cette valeur théorique entraînant une tension par élément de 0.9V, ce qui représente une excellente optimisation de l'énergie des piles en fin de décharge !

Un contrôle de la tension des piles est nécessaire pour la certitude des valeurs transmises, aussi une entrée analogique RC0 est utilisée à cette fin. Les valeurs d'impédance d'entrée données par Microchip sont de 10 Kohms, aussi le pont avec 2 x 4.7M + 220K représente une valeur complètement anormale au vu des temps d'acquisition. Les premières valeurs mesurées lors de la mise sous tension (MST) seront donc fausses, ce qui est parfaitement normal. C'est la charge de C11 qui mémorise la valeur atteinte (et certainement pas les ponts de résistances !)
Une faible portion de son énergie est "partagée" instantanément dans le tout petit condensateur CHOLD de 10 pf du convertisseur lors du lancement toutes les 8 heures d'une mesure de la tension piles. Autant dire que le rapport 1000 ne sera pas perturbé par cet "emprunt" ! (Vu la sélection permanente, il est fort probable que ce fait soit d'ailleurs unique à la MST, puis constant puisque le condensateur CHOLD restera chargé sur cette unique sélection d'entrée.

Cette tension est donc "mémorisée" en permanence par le condensateur C11, car non seulement la valeur doit être présente sans attendre le temps d'acquisition, mais il y a toujours un bruit de fond plus ou moins important dans ces sources d'énergie et d'autant plus que le pont de résistances est de forte valeur.

Il faut environ une dizaine de secondes pour atteindre une valeur exacte. La diode D2 permet une limitation dans le cas de piles un peu trop neuves ou "nerveuses" qui pourraient dépasser 5.12V+0.65V de tension directe de la diode.
Cette mesure de tension n'est faite que toutes les 8 heures quelque soit le mode. Elle est donnée de même toutes les 8 heures en mode binaire, mais toutes les 10 secondes en mode ASCII.
Le contrôle de tension est mémorisé dans un bit de l'octet d'incidents (Low_Bat) Cette valeur limite est de 2.7V (Justement la valeur mini nécessaire au régulateur !).
La référence ANA utilisée est la tension régulée à 2.5V. Le bit Low_Bat fait partie des indicateurs et est bien entendu transmis avec toutes les trames.
Il est tout à fait possible de n'utiliser que 2 piles au lieu de 3, mais dans ce cas l'arrêt se fera à 1.35V par élément, ce qui ne permet pas de profiter pleinement de l'énergie encore disponible dans les piles, car il reste encore de nombreux jours d'utilisation théoriquement disponibles entre 1.35V et 0.9V.

L'allure générale du courant d'alimentation est totalement impulsionnel puisque le micro contrôleur est en sommeil une grande partie du temps, avec une consommation stable de l'ordre de 18µA et qui passe à 1.5 mA lors d'une transmission radio soit une dynamique de courant de l'ordre de 100, dans un temps très court et de plus parfaitement "haché" au gré des bits à 1 ou 0 transmis par l'émetteur.

Il s'agit ici du courant (Sur 1K) lors de transmissions ASCII.

Il est donc nécessaire d'avoir 10µF de condensateur en sortie de régulation  et un peu plus avant régulation, pour que les piles aient le temps de "se réveiller" sur de tels écarts (Écarts importants dans les faibles consommations cependant).

L'intégration du courant sur une résistance de mesure de 1K et un condensateur d'intégration de 1000µF semblerait donner une consommation moyenne de 31 µA (Valeur calculée par le scope) ce qui fait que l'autonomie ne serait pas de 15 années mais comprise entre 10 et 15.

Des mesures complémentaires pourraient être réalisées pour plus de précisions.

7 Le micro contrôleur PIC 16F690

C'est le coeur du montage et il ne peut fonctionner que sur son oscillateur interne RC à 4 MHz, à cause de son alimentation à seulement 2.5V et de l'utilisation nécessaire des I/O OSC1 et OSC2.
J'aurais souhaité réduire cette tension à 2V qui est la limite, cela m'aurait permis de n'utiliser que 2 piles au lieu de 3, mais je n'ai pas trouvé de régulateur 2V ayant une aussi faible consommation que le MCP1702-25 qui n'existe justement pas à cette valeur de 2V  ! Pas de chance.
Toutes consommations auraient pu être ainsi largement plus faibles.

A titre d'information voici ce que consomme ce PIC suivant les fréquences de son oscillateur interne… (Ce tableau a été relevé et ne provient pas du constructeur (qui ne le donne pas !))

On notera que ce processeur est amené à être en sommeil (SLEEP) une grande partie du temps et que lors de ses réveils, il doit être opérationnel rapidement pour le problème du maintien du temps.
Pour un réveil rapide pas besoin d'un "verre d'eau dans la figure", mais simplement de l'oscillateur interne de type RC qui en quelques alternances est opérationnel. Cela exclu de fait tout oscillateur à quartz qui demande "un certain temps" avant d'être opérationnel (1024 cycles de base)

Consommation en µA sur VDD pour PIC 16F690 en INTOSC (SANS autres oscillateurs )

Les courbes ont aussi un intérêt pour évaluer les "pour et contre" d'une fréquence plus élevée sur un plan  énergétique, aussi je les ajoute ci-dessous. (Ainsi on visualise parfaitement qu'entre 125KHz et 500 KHz l'augmentation de consommation reste faible quelle que soit la tension)

Ainsi que vu au paragraphe précédent, le fait de travailler à 2V aurait permis d'économiser 70µA lors du fonctionnement du PIC.

En réalité, le processeur utilise moins de 1 ms pour la majorité de ses calculs (sauf durant la préparation des données et la transmission). Voir-ci après pour la transmission…

Vous noterez que le PIC est encore capable de fonctionner à 1.5V et même à 8 MHz, mais cela n'est plus garanti par le constructeur, aussi je m'en tiens à ce qui est du datasheet !

8 Les transmissions

D'une façon générale, la transmission radio est un poste de consommation "très élevée" (1.5 mA !!! Oui relativement aux qq. µA !!!). C'est le poste qui va largement conditionner l'autonomie du dispositif.
La vitesse de transmission est prévue à 2400 bps principalement pour une facilité de modules radio bon marché, aussi bien en émission que réception (LED de paramétrage).

A force de "penser économies d'énergie", je me suis fait aussi piéger, car comme je traite les transferts TX en Interrupt, j'ai considéré que si le PIC est en sommeil, c'est l'interrupt TX qui va le réveiller et ainsi de suite…

Le raisonnement est partiellement exact car j'ai oublié un point essentiel interne au PIC, qui est que la sérialisation des données pour TX est faite par le CPU (TSR register) que celui-ci DOIT être ACTIF pour pouvoir compter les BRG et faire un shift de plus…!?!
Cette erreur "si grossière" est difficile à rechercher car comme le mode SLEEP n'est pas simulé, le simulateur donne un résultat parfait et la réalité est incompréhensible…
Alors évitez donc ce piège !

Pour accélérer les transmissions, il serait peut-être possible de passer à 4800 bps car l'émetteur est donné à 4 KHz, mais 4 KHz ce n'est pas 4.8 KHz !!! Ce point est à véritablement regarder de très près, car il peut être source d'importante économie énergétique.

Comme on a pu le voir, la fonction transmission nécessite que le PIC soit actif et doubler la vitesse est particulièrement intéressant sur ce poste, premier consommateur d'énergie.

8.1 Partie émission radio mode binaire

C'est la fonction la plus importante car c'est celle dont le courant et la répétitivité est la plus élevée.
Aussi, comme dans les téléphones portables, tout est bon pour faire feu de tout bois..;
Ainsi la nuit les émissions radio sont réduites à une émission toutes les minutes au lieu de toutes les 10 secondes.
Je considère qu'à priori on ne relève pas les compteurs d'abonné la nuit.... (?)
Pourtant dans quelques cas de lever de doutes cela a pu arriver et il faut aussi se rappeler que ces têtes radio peuvent accompagner aussi des compteurs de production ou de branches de réseau et que dans la recherche de nuit d'une casse de canalisation de grosse section, il est important de pouvoir disposer au moins de l'information d'une branche non raccordée à une télégestion pour des questions financières (Si il y en a une ?!)
Dans ce cas, le relevé de nuit est utile, certes un peu plus lent, mais entre une minute au maximum à attendre et le fait de descendre du véhicule, lever un tampon etc… c'est 10 minutes de perdues !

Une particularité de l'émetteur est de ne rien consommer si l'entrée data est à zéro. Bien qu'il soit commandé par un FETMOS-P, un courant de base du transistor émetteur subsisterait et impacterait le bilan énergétique, aussi il est nécessaire qu'au repos la tension de repos TX soit à zéro et non à 1, aussi il existe un bit (SCKP du registre BAUDCTL) qui permet d'inverser la polarité de transmission TX du PIC (Attention ce bit n'existe qu'en émission (et pas en réception))
On peut même imaginer que le FETMOS d'alimentation de l'émetteur de la tête radio pourrait même être supprimé ? A vérifier !

Voici la description d'une trame binaire "standard"

IDENT    1 octet    définit le concessionnaire ou distributeur AEP ou l'exploitant. Cela permettra sur un terminal portable éventuel ou à un logiciel spécifique de ne prendre que les compteurs ayant ce code. Il peut donc y avoir des mélanges entre opérateurs, car certains relèvent aussi pour l'assainissement. Ce code permet une sélection plus rapide que le numéro de compteur.

No_COMPT_A     : Partie ALPHA du numéro de compteur : 6 octets alpha numériques ex: xC07AB
No_COMPT_B     : Partie NUMérique sur 3 octets 24 bits permettant une numérotation jusqu'à 999 999.
INDEX_M            : Index partie des M3 sur 3 octets permettant le comptage jusqu'à 999 999
INDEX_L             : Index partie des LITRES sur 2 octets permettant un comptage jusqu'à 999
INDEX_AUTO1   : Premier index mémorisé sur la date Jour/mois indiquée en paramètre AUTO1, (la valeur est uniquement en M3 sans les litres) valeur en rétention durant une année
INDEX_AUTO2    : Deuxième index mémorisé sur la date Jour/mois indiquée en paramètre AUTO2, (la valeur        est  uniquement en M3) valeur en rétention durant une année
JOURS        définit sur un octet le jour de l'installation initiale, puis après le jour actuel.
MOIS          définit sur un octet le mois de l'installation initiale, puis le mois actuel
ANNEES      définit l'année de l'installation initiale puis l'année actuelle
HEURES      définit l'heure de l'installation puis l'heure en cours
MINUTES     définit la minute de l'installation puis la minute en cours.
DIVERS        octet de service des incidents composé de 8 bits indicateurs
 Bit7    Low_Bat        Piles faibles
 Bit6    Erreur
 Bit5    Tentative de fraude à l'aimant
 Bit4    Fraude cuivre
 Bit3    Fuite
 Bit2    Il y a eu Fuite
 Bit1    Cpt bloqué ?
 Bit0     free
 
PARITE            parité verticale calculée sur un octet depuis IDENT Inclus
Return            caractère return

Soit un total de 29 octets pour un temps de transmission de 120.8 ms

Une trame spéciale de 2 caractères de plus est envoyée toutes les 8 heures. Elle est insérée juste après la parité, 2 octets contenant la valeur précise de la tension des piles. (Trame terminée aussi par return)

Il existe un code Fabricant qui n'apparaîtra plus maintenant dans aucune sortie, qui est interne au programme et qui sera demandé pour certaines commandes.

8.2 Partie réception (paramétrage)

Un point important également consiste au paramétrage par la LED et la fonction de réception RX du PIC. En effet durant l'attente des données de paramétrage, la consommation pourrait être maximale, car le PIC doit surveiller la réception.
Un artifice prévu par Microchip vient me sauver de cette attente de frappe au clavier du PC… En effet si le paramétrage mange déjà une grande partie de l'autonomie, rien ne va plus !
Le bit WUE du registre BAUDCTL vient à mon secours, car il permet au micro contrôleur de se réveiller au premier bit start qui annoncera la venue d'un caractère qui sera à sérialiser et qui nécessitera donc au moins 4.1 ms (1/2400) de temps de fonctionnement CPU !

A ce niveau vous avez vu sur le schéma que la réception est de type "opto" sur une cellule. Pourquoi cela ? Simplement parce que cela évite un récepteur radio toujours cher qui n'est utilisé qu'une seule fois lors du paramétrage. (2 à l'extrême rigueur !)

Cette solution est donc seulement une question de prix de revient et finalement une bonne solution qui allie également une plus faible consommation qu'un récepteur radio (0.36mA maxi contre 3 mA environ, soit un rapport 10 tout de même !). C'est aussi un coût très faible par rapport à un récepteur.

Dans cet aspect de programmation, une sécurité est ajoutée avec l'ILS qui devra "voir" un aimant pour que la cellule soit alimentée, et donc qu'une programmation puisse avoir lieu. C'est une sécurité mais également un gage d'économie d'énergie, car si la cellule était éclairée, son courant n'est pas du tout négligeable et mettrait vite la durée des piles à mal.

9 Structure programme

Le programme qui fait un peu plus que 2 KO est en assembleur.
Les interruptions gèrent quasiment complètement le scan périodique de la Cyble, et la principale difficulté réside dans la gestion des interrupts et la mise en sommeil du PIC pour que tout se déroule normalement.

Il y a 5 interruptions dont l'ordre de priorité est défini par l'analyse des Enable de priorités sauf pour le Timer 1 qui est le premier et qui ne doit absolument pas perdre "une seconde" si j'ose dire ! Cette séquence de réponse doit être traitée en moins de 30 µs et après des essais un peu plus longs, des loupés se produisent  dans la gestion du temps.
(Ceci confirme la nécessité de séparer le "temps horaire" du temps entre scans, et la version avec ULPWU devrait palier ce problème).

La correction de temps pour une division au plus juste est traitée dans cette réponse aux interruptions du Timer1 à l'échelle de la seconde.
Cette réponse du Timer 1 assure aussi le lancement du Timer2 et l'envoi de l'échelon de tension sur le circuit LC.
Enfin il assure l'incrémentation du compteur des secondes et donc la justesse des secondes, et c'est pour cela que cette réponse doit être particulièrement rigoureuse dans le temps de traitement, mais à la lumière des résultats, c'est trop juste !

Vient ensuite le Timer2 qui coupe l'échelon de tension au circuit LC car le comptage des alternances est maintenant terminé. Il assure également à ce stade le transfert du nombre d'impulsions "actuel" dans "précédent" et celui qui est encore en Timer0 dans "actuel".
Cette bascule actuel/précédent permet au programme de travailler sur les impulsions précédentes sans attendre "l'actuel" et de ne pas consommer d'énergie pour rien durant ces 250µs.

La troisième interrupt concerne les transmissions TX et donc la partie radio, c'est standard et sans particularités, mis à part que l'on doit maintenir le PIC "réveillé" pour qu'il assure les décalages à la sérialisation.

La quatrième INT concerne cette fois la réception de la LED pour le paramétrage, mais aussi pour la reprise de contrôle en cours de fonctionnement, dans le cas que je ne souhaite pas, c'est-à-dire, le cas du "tout à la poubelle" (électronique et  piles, à recycler (séparément)).

Une particularité est traitée ici avec l'analyse du return éventuel en premier caractère pour laisser la zone en l'état (Évite de tout retaper un champ)
Lors d'un return hors de la première position, un ou plusieurs caractères (Espace ou zéro) suivant le type de zone, seront ajoutés en tête du champ.

Enfin la Cinquième INT concerne le retrait ou la mise en place de la sonde de programmation aimant de programmation (solidaire de la LED d'émission de données)

Le programme tourne en boucle après avoir fait ses différentes initialisations. Les principales étapes de cette boucle (Interruptible) sont les suivantes :

Début de boucle
- Surveillance et détermination tops et index par l'analyse des nombres d'impulsions reçues (Précédent)
- Traitement interruptible de l'heure (Mise à jour effective des secondes, minutes, heures, jours, mois, années.
- La mise à jour du temps permet de comparer si 8 heures sont écoulées et de lancer une lecture de la tension des piles
- De même c'est ici que sera verrouillé durant une heure une tentative de fraude magnétique.
- La détection de fuite est également attachée au temps en minutes cette fois (255 minutes)
- La détection de compteur bloqué est également attachée au temps.
- Les dates anniversaires de relevés à date fixe sont également comparées à cet instant sans préséance d'ordre en vérifiant seulement qu'elles ne sont pas à 0. (Zéro= pas de contrôle)
- C'est également ici que les 10 secondes d'intervalle d'émission radio sont établis (ou la minute la nuit)
- Dans le cas d'émission venue à échéance de temps, le buffer est constitué directement de la zone des variables dans le cas d'une émission binaire. Dans le cas contraire, un buffer auxiliaire est préparé en BANK1 pour assurer les conversions binaires/ASCII.
- Avant de tester si on est en émission radio on vérifie si l'aimant a été de nouveau activé (le retrait n'occasionne rien car c'est normal de le retirer en fin de programmation). Dans le cas d'une nouvelle présence, il faut donner une commande spécifique associée au code du fabricant en moins de 3 secondes pour reprogrammer le compteur, faute de quoi la tête continue et aucune programmation ne peut plus être faite durant une heure.
- En l'absence d'émission radio en cours, on attend la fin effective des 250µs car le PIC doit être actif pour compter les impulsions et on se met en SLEEP jusqu'à l'interrupt du TIMER1.
- En cours d'émission radio on reste éveillé en attendant l'INT du timer 1 et on repart ensuite en début de boucle.

9.1 Paramétrage

Le paramétrage consiste à renseigner ce qui va permettre d'associer des valeurs d'index à un compteur (Un numéro) et donc à un abonné, (qui sera facturé sur cette base).
Pour ce faire, dans les zones où plusieurs entités sont présentes, (ce qui peut arriver), le distributeur possède un code spécifique qui est le premier élément d'une émission radio. Il est appelé code d'identité
Toute différence sur ce code sera d'emblée rejetée.

Le premier paramètre à renseigner est donc ce code d'identité de 0 à 255.

Dans la suite des opérations, l'affectation d'index sera toujours faite sur l'égalité des numéros de compteurs.
Rappelons que ces numéros sont uniques et qu'ils répondent à une norme ou directive conseillée (J'ai oublié depuis …), mais dans ce numéro constitué à l'époque de 5 caractères Alpha (et de 5 caractères numériques) on trouve notamment l'année de fabrication et une identification du fabricant.
La partie numérique étant bien entendu unique pour la partie Alpha correspondante.

Pour être plus simple, il n'y a pas de compteurs portant des numéros identiques !

C'est donc le numéro de compteur qui est l'élément suivant du paramétrage
(Après recherches : Il s'agirait d'une directive européenne MID qui définit des éléments techniques propres aux appareils de mesures et elle serait définitivement applicable en 2016)

A paramétrer ensuite, il y a l'index actuel, car une tête radio n'est pas toujours installée sur un compteur neuf, c'est même peu souvent le cas, encore que les fabricants tendent à offrir ce service de programmation en plus avec l'achat groupé de compteur + tête.
(A préciser aussi qu'un compteur neuf n'indique pas toujours un index à 0, car il y a un certain nombre d'essais en usine)

C'est maintenant les dates et heures du jour d'installation, exprimés dans le format suivant :
JJ/MM/AA HH:mm  (Aucun séparateur contrôlé) Les secondes seront assumées à 0, c'est à dire qu'il faut préparer pour une (ou plus) minute plus tard et valider lors de la commande suivante.
De cette mise à l'heure dépendra la véracité des relevés à date fixe et c'est donc important si cette particularité est utilisée

Viennent ensuite les mois et jours du premier relevé à date fixe sous la forme JJ/MM (avec le séparateur non contrôlé). Suivi du deuxième paramètre de relevé à date fixe bien entendu et suivant les mêmes règles.

Puis c'est ensuite le caractère d'affectation du mode de fonctionnement de la tête radio qui est une véritable commande d'un seul caractère et qui débute l'heure précédemment enregistrée.

9.2 Commandes

Une commande est nécessaire, car la tête radio a la possibilité normale d'envoyer par radio son (ses) index mais a aussi d'autres possibilités liées à l'exploitation cette fois.
On trouve donc la définition de ces commandes, toutes constituées d'un seul caractère (majuscule ou minuscules) dont la signification est la suivante :

B.    Envoi de trames radio en Binaire pur
A.    Envoi de trames radio en clair (ASCII)
R.    Réglage du nombre d'impulsions (à effectuer en usine seulement)
D.    Dump de l'EEPROM pour l'historique des incidents (Exploitant)
K.    Kill Annulation complète de la Saisie en cours (Exploitant)

La dernière commande validera la seconde 0 pour la minute paramétrée précédemment.

Voir les deux principales commandes au paragraphe 11 BRAY++ et Logiciels

10 Adaptation radio / PC

Les têtes radio utilisées émettent à la fréquence de 433.92 MHz, mais encore faut-il "écouter"…
Les outils d'écoute se veulent standard puisqu'il s'agit en premier lieu d'un PC et d'une petite adaptation d'émission/réception radio 433.92.
En réalité l'émission radio sur cette adaptation n'est pas impérative, mais elle permet l'écho lors de la frappe des données.
"L'écho" évite à la tête radio de devoir retourner la frappe par radio en émission depuis la tête. De plus ainsi équipée l'adaptation devient un outil standard d'émission/réception pour toute application avec micro contrôleur.

J'avais déjà développé un outil similaire (voir l'article), je viens de le mettre au goût du jour en permettant cette fois l'inversion ou non des signaux, tant en émission que réception, et en ajoutant la sortie pour LED en vue d'assurer la programmation de la tête.
J'ai également supprimé le verrouillage RTS/CTS qui finalement ne sert pas à grand' chose, sauf à se faire piéger une fois de plus en oubliant (vu l'écho toujours actif).

J'avais prévu dans cette deuxième version l'alimentation possible par USB (Pour pouvoir être autonome en énergie avec un PC portable), mais j'ai eu un revers (voir l'article sur le 5 Volts USB) et je dois de nouveau le modifier pour m'adapter à cette nouvelle alimentation qui n'a pas de façon native toutes les qualités que l'on pourrait supposer.
J'en profiterai de plus pour changer le connecteur USB –B par un connecteur plus petit Mini USB-B plus adapté.
Je donne tout de même ce nouveau schéma qui ne sera pas modifié sur les possibilités d'inversion des signaux, et qui comporte maintenant une nouvelle tension 5V issue de la tension de +9V issue du MAX232. Cette nouvelle tension est maintenant tout à fait "propre".

Ce ne sera pas encore la version définitive, car la consommation me semble un peu élevée à 22mA et je changerais encore volontiers le 74LS86 par un modèle HC.
Je profiterai de cette ultime version pour mettre un connecteur Mini USB-B, ce qui n'est pas encore fait.

Enfin transmission et réception s'effectuaient à 2400 bps, mais au vu des performances de l'émetteur et du récepteur, rien n'interdit d'essayer à 4800 bps.
(Et en cas d'échec, puisque l'on maîtrise le BRG, rien n'empêcherait de fonctionner exactement à 4000 bps. Le logiciel BRAY++ et tout à fait capable de travailler à cette vitesse non standard (Custom)).

Je crois d'ailleurs avoir déjà fait des essais sans problème à 4800 et le cartouche du schéma ci dessous semble le confirmer


10.1 Le schéma actuel RS232

Ce schéma est surtout prévu pour une alim USB. Le LP2950 est alimenté dans ce cas à l'envers, ce qui n'est pas très bon, et la diode Schottky D4 devrait rétablir une tension en entrée dans ce cas et éviter au LP2950 de se trouver "mal".
Les essais réalisés sans diode indiquent qu'une tension à peine plus faible  se retrouve en entrée également, et que c'est peut-être une précaution inutile ?

J'ai aussi essayé avec 10K et une diode, la sortie +9V du MAX232 en entrée U1. Là aussi ça fonctionne correctement.
Dans les 3 cas possibles, je n'ai pas trouvé de surconsommation.

Pour ceux qui ne veulent que l'USB, je vous invite à supprimer U1, B1,C8 ainsi le combat cessera faute de combattants !!!

La reprise du +9V en entrée du récepteur après régulation est nécessitée pour obtenir un 5V propre (U3) exempt de parasites pour le récepteur à super-réaction.  Cette solution très simple donne satisfaction.
Concernant ce petit dispositif, il ne restera plus qu'à remplacer le 74LS86 par un 74HC86 qui devrait consommer un peu moins, ce qui est toujours intéressant.

11 BRAY++ b et logiciels

C'est le logiciel BRAY++ qui reçoit et émet les trames RS232 en liaison avec l'adaptation Radio/PC, sur une entrée série d'un PC. C'est un logiciel "free", et il est véritablement très pratique et bien réalisé.
Il permet le paramétrage des têtes à partir d'un PC et récupère les données à l'écran ou dans un fichier avec des modes hexa ou ASCII

11.1 Commande "B" (Binaire)

Chaque trame en mode binaire reçue d'un compteur est d'abord réceptionnée en hexadécimal ASCII par le logiciel BRAY++.
Elle devra ensuite être convertie en ASCII alpha ou ASCII Numérique (Extérieurement à la tête compteur pour des questions d'autonomie des piles.

Pour ce faire, la réception se réalisera impérativement en mode HEXA et le fichier devra être soit traité manuellement dans WORD, ou tout traitement de texte, ou par un logiciel dédié qui assurera la mise en forme complète avec les conversions hexa vers l'ASCII *.txt exploitable par tout logiciel d'application ou même simplement dans EXCEL ou OpenOffice.

Un travail assez "pénible" est à faire pour la mise en forme définitive, car il faut créer les zones comme en émission et les affecter à des valeurs ASCII ou numériques suivant les cas.
De plus les données numériques ont les poids inversés ce qui complique encore un peu ce sujet.

Les fonctions d'OpenOffice telles que hexbin() et car() ainsi que d'autres permettent d'en venir à bout.
Des macros permettraient également d'automatiser toute cette "salade informatique".
Sur le fond, autant cela se réalise assez simplement dans la tête compteur pour la sortie ASCII des résultats, autant cela prend une certaine complication lors de la sortie binaire.
Aussi je préconise tout de même un petit logiciel de traitement des données pour tout remettre en ordre, car ce serait tout de même plus simple.
Une réflexion sur d'autres méthodes de transfert de l'ensemble des données est ouverte, et des possibilités en deux temps, ou abandon des éléments peu utiles est à évaluer

11.2 Commande "A" (ASCII)

Cette commande typique des particuliers, permet de recevoir en clair les différents éléments émis par la tête… Alors pourquoi ne pas faire de même pour les relevés d'un exploitant ?

Simplement parce que dans ce cas, on double pratiquement les temps d'émission, et qu'il faudrait alors diviser par 2 la fréquence d'émission, soit toutes les 20 secondes…
Cette fréquence parait trop faible pour tirer tout l'avantage d'une telle opération, mais peut-être que 15 secondes seraient un compromis acceptable ? (Pourquoi pas lors de l'utilisation de concentrateurs ?)

Tout cela résulte d'études complémentaires que je ne saurais faire, faute de moyens, et cela confirme ma volonté de trouver une entité intéressée par ce challenge d'un concurrent hors ligne, ne fabriquant pas de compteurs (C'est essentiel !).

Dans cette application et pour donner toutes facilités, ce mode est surtout utile aux particuliers qui n'en sont pas à regarder pour l'échange d'une seule pile même tous les 5 ou 10 ans. De plus, dans ce contexte, la fréquence d'émission peut très facilement être ramenée de 10 secondes à 1 minutes, ce qui compenserait largement la perte

12 Prochaines versions

12.1 Future version

Cette future version s'appuiera sur cette expérience et devra parfaitement séparer le temps horaire du temps de scan. En effet je devrais peut être modifier le calcul des 10 ms en utilisant le système d'Ultra Low Power Wake Up (ULPWU).

La consommation pourrait être améliorée en utilisant 3 bobines, mais c'est une grosse étude !!! . En "grappillant" les derniers µA que j'aurais pu oublier. On gagnerait du coup le sens et les retours d'eau. La sélection des bobines sera possible par RC1 et RC2 sans toucher au fond du schéma. L'alimentation du CI sélecteur de bobine pourrait se faire en même temps que l'échelon de tension.

Pour utiliser l'ULPWU, j'ai du reprendre l'entrée RA0 qui est seule en mesure d'utiliser cette possibilité. De ce fait le condensateur de l'ULPWU qui devra être placé sur cette entrée en série avec une résistance, devra être connecté APRÈS programmation ICSP. (C'est incontournable mais gênant en mise au point...strap à prévoir en MAP)

Enfin RA1 qui mesure la  tension des piles est récupérée à la place de RA0 pour contrôler la fermeture de L'ILS. (L'I/O RA1 est nécessaire pour pouvoir générer une interrupt (IOCA))
La tension des piles sera quant à elle mesurée sur RC0 qui sera donc maintenant utilisée !.

C'est donc sur la base de l'ULPWU que serait généré le délai de 10 ms qui sera à ajuster pour cette valeur minimum.

L'oscillateur LP à 32.768 KHz n'aura plus besoin d'interrompre toutes les 10 ms, mais seulement toutes les 2 secondes, en faisant le set initial de TMR1H et L à 0x0000 avec le prescaler toujours à 1.
(On retrouve cette valeur de 2 secondes de "sommeil" chez le fabricant, mais est-ce bien du "vrai sommeil" ou seulement la périodicité de mise à l'heure ? ? ?)

Ainsi il y aura une interrupt pour la gestion du temps, toutes les 2 secondes, ce qui est largement suffisant.
De ce fait la réponse à cette interrupt n'est plus limitée dans le temps (On a 2 secondes pour répondre) et la précision du temps sera rigoureusement celle du quartz utilisé sans aucune correction cette fois.

La réponse à l'interrupt ULPWU fera exactement ce que fait actuellement le Timer 1 avec des lignes en moins d'ajustement à -327 et -328 et donc une consommation un peu moindre mais à vérifier...... c'est plus prudent !
Mais ça c'est la partie énergie…

Aurais-je également le courage de m'engager dans un système à 3 selfs et de gérer les retours d'eau ? C'est une importante question aussi dans l'immédiat, je vais plus m'orienter vers la version simplifiée qui intéressera plus  les particuliers que les entités AEP ou les fabricants.


12.2 Version simplifiée

En même temps que la version actuelle j'ai aussi préparé une version simplifiée pour les bricoleurs un peu moins pointus et qui coûtera aussi moins cher puisqu'il n'y aura pas de gestion de l'heure et seulement une seule possibilité rudimentaire d'envoi de l'index par radio, ou seulement de Tops par Open Drain.

Je tiens à apporter une précision technique concernant l'oscillateur interne Low freq et le comparateur.
L'oscillateur 31KHz consommerait 4.6µA à 3V et un comparateur (capable de travailler en SLEEP) 6.1µA à 3 V.
Pourtant à 2V les avantages sont inversés. Disons pour simplifier que les deux systèmes sont à peu près équivalents en consommation.
Le comparateur pourrait être utilisé comme un pseudo ULPWU "local"
Mais ULP (en ANA) permet de libérer une OUT, ce qui pourra peut être être utile, vu qu'il y en a déjà assez peu...?

Aussi la version simplifiée pourra être déclinée en 2 versions simplifiées distinctes, mais dans l'immédiat je traiterai avec oscillateur, car l'autre version nécessite de reprendre complètement les I/O pour s'adapter à l'unique comparateur.

(Dans la deuxième version, j'essayerai donc de charger un condensateur par une sortie, puis après ce temps de charge, de repasser en input et en ANA, puis de basculer sur un comparateur interne qui peut fonctionner en SLEEP cela fera une INT et on arrêtera pour une nouvelle recharge.
Le point d'interrogation reste ouvert et à vérifier!)

La tenue en température sur ce principe sera à surveiller de près.
Bien que le PIC utilisé n'ait pas la fonction TX, je pense pouvoir l'émuler comme pour le compteur horaire radio déjà décrit, et envoyer une trame très courte constituée d'un petit indicatif de sélection et de la seule valeur de l'index.
Il me sera ainsi facile d'assurer directement l'inversion des poids nécessaire pour ne pas alimenter en permanence l'émetteur.

Je compté également réduire les vitesses de scan à des valeurs plus plausibles pour les particuliers soit de l'ordre de 2 Hz ce qui pour des petits compteurs donne 7.2 M3/h ce qui est largement suffisant.

Il n'y aura pas de paramétrage direct possible et j'envisage seulement, dans le cas d'une radio seulement, que l'index de départ soit programmé en EEPROM. Ce n'est pas très pratique je suis bien d'accord mais peut-être mieux par la suite en fonction des possibilités....
Ce point est délicat car aucune commande ne peut donc être passée et un artifice devra être trouvé...!

Un simple strap sur GP3 permettra de déterminer si la radio sera présente ou non. Ce sera donc des TOPs sur la sortie ou l'émission de l'index suivant la position de J1.

Les petits cercles concernent le connecteur ICSP pour la programmation
Tout cela est encore à réfléchir…

Voici le schéma actuel mais il n'est pas figé.

13 Conclusions

Cet article traite principalement du montage standard avec PIC16F690 qui ne fonctionne pas encore complètement, qui est stable en température, mais qui a besoin d'un peu plus d'études et de corrections pour être commercialisable et pleinement opérationnel.

Il peut être la voie ignorée par les différents grands fabricants qui disent tous que leur protocole est disponible à qui le souhaite, mais que personne n'a pu véritablement trouver en intégralité.

Il me semble important que, quelque soit la marque d'un compteur, on puisse trouver une tête radio correspondante utilisant un protocole unique, et que la chaîne de relevé devienne commune à tous.

D'autre part, ainsi que je l'ai déjà dit, je pense qu'il faut aussi limiter un peu ce qui ne sert à rien, et je pense principalement au contrôle des débits qui apportent pourtant une indication "intéressante" sur les débits instantanés, maxi, mini etc… Mais au final il n'est en général pas possible de changer un compteur faute de place ! Alors à quoi bon renseigner cette variable. (Je parle des seuls compteurs d'abonnés !!!)

Ne jamais oublier que toute valeur issue d'un système représente un coût pour sa création, son exploitation et sa maintenance. (Cela me conforte dans mon principe de vouloir faire simple).

Je pense que la version décrite donne l'essentiel des fonctionnalités vraiment utiles, sans aller trop loin dans la complexité.
Je pense qu'il est parfois nécessaire de revenir à des choses plus simples, et en ce sens, j'espère ne pas avoir déjà dépassé un peu cela.

Alors bonne continuation à toutes et tous pour arriver à comprendre cet article très technique à la fois en électronique, en programmation mais aussi dans le domaine des compteurs AEP, et d'en tirer de nombreux éléments d'information.

Je veux encore ajouter un oubli, et en ce sens rédiger un article est résolument formateur, car on repense à un certains nombres de points dont un qui me vient à l'esprit parce que j'ai dit que la transmission est ce qui coûte le plus en énergie… Alors pourquoi transmettre les index anniversaires si ils ne sont pas utilisés ou seulement 1 seul. C'est une modif que je laisserai de côté pour l'instant mais qui est à traiter le moment venu, car à ce jour ces index même non utilisés sont transmis ...
La relecture et la rédaction sont riches d'enseignements et d'obligation à la rigueur de ce que l'on écrit…

Si cet article vous a donné des idées, alors à vous de créer suivant ce principe des courants de Foucault, un encodeur en quadrature avec un secteur de 180° et deux bobines seulement, et de créer votre ligne de compteurs, sans oublier de créer les autres têtes....


FAQ

Au fait,… encore un bémol ! Et si par hasard votre compteur était déjà équipé d'une tête radio de la marque ? Alors là j'avoue ne pas trop savoir… Si par opposition vous aviez déjà installé votre équipement (sans rien casser bien entendu, sauf le petit cache obturateur de la vis de 4), et que le gestionnaire installe ces têtes, alors le problème est un peu différent et j'arguerais que j'étais le premier à l'utiliser  et qu'il devrait au moins me donner les moyens de reporter "mes" informations (même par fils).
Au niveau programme c'est très simple, car toute la boucle 250µs "saute" et vous pourriez rentrer directement la valeur des tops. (Si vous aviez ce cas, alors faites moi signe, je regarderai ce que l'on peut faire pour entrer les tops directement en fonction des tensions présentes).
Le distributeur devrait pouvoir vous installer une sortie de la tête compteur (Capteur de tops seuls En commun  avec lui, mais attention aux niveaux de tensions qu'il utilise…) Mais j'ai plus l'impression qu'il vous expédiera vers sa solution (moyennant finances).

NOTA 1 : La tête compteur peut revêtir deux fonctions très distinctes, ce sont d'ailleurs des produits très différents :
- Le capteur de TOPs : Il récupère chaque impulsion de l'unité de volume et la transmet par fil vers un dispositif de calcul  (tête radio déportée ou électronique particulière) C'est à ce niveau que le partage de l'information d'un compteur peut seulement être fait entre un particulier et le distributeur.

- La tête radio (complète) comprend un capteur de tops intégré et l'électronique de gestion des index et l'émission radio. Ce dispositif est exclusif et il est impossible de s'y insérer, même en exploitant seulement l'émission radio, car c'est un protocole complexe qui gère cette fonction. Une tête radio complète interdit tout partage des informations

- La tête déportée n'est pas en réalité pas une tête proprement dite mais un boîtier électronique située non loin du compteur et recevant par fils les données du capteur de tops. Le résultat radio est alors parfaitement identique à une tête radio standard

NOTA 2 : Il ne peut y avoir qu'une seule tête par compteur et il est impossible de les empiler...

Au fait et si on dévisse ou déclipse  simplement la tête du compteur…c'est gagné en fraude de différé de facturation ! Mais il faut verrouiller seulement la vis de fixation par un petit trou et un "plomb" avec le circuit imprimé....ou un petit ILS avec un autre petit aimant serait le bienvenu pour contrôler simplement et éviter des scellés…C'était pourtant simple !

Le mode ASCII est véritablement très pratique, et à l'origine je l'avais créé pour vérifier rapidement ce qui se passait, car c'est tout de même plus simple à lire que l'hexadécimal 24 bits…Mais comme tout ce qui est utile, j'ai regret à m'en séparer, alors je l'ai laissé pour le bonheur des particuliers principalement.
Mais au lieu d'ajouter un paramètre de plus, vous pouvez gagner en autonomie en supprimant la relève à date fixe qui ne vous sert à rien dans ce cas… Vous gagnerez donc !

Encore.... J'ai prévu 6 caractères alpha pour le N° de compteur  et 6 caractères numériques, en réalité, tous les compteurs de ce jour ont seulement 5 et 5, ce qui fait déjà 1 car alpha gagné +7 bits, car 99999 donne   0x1869F.
Enfin tous les index sont sur 24 bits soit des valeurs encore trop grandes au vu des 5 galettes des totalisateurs. L'index du jour peut donc tenir de la même manière sur 17 bits, tout comme les index anniversaires. soit encore 21 bits de grappillés.
Ces différents bits restants peuvent faire partie de l'information "litres", car il y a alors 6 bits de disponibles pour compter jusqu'à 999. Bref c'est du futur !

Si vous êtes un peu perdus avec une avalanche de mots inconnus, ou de jargon indigeste lisez tous les articles mentionnés, vous aurez une meilleure approche de chaque partie. Lors du modèle simplifié j'essayerai d'être un peu moins "technique" et plus pratique, mais il est vrai que l'on n'efface pas une année de recherche sur ce sujet, sans en faire profiter largement ceux qui peuvent utiliser ces informations.

Comme on disait il y a déjà de nombreuses années : "Allez la relève"…


lokistagnepas/bricolsec

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

Comments

[lokistagnepas]

Bonjour,

Sans faire de philosophie, quand je parle de "temps en temps" cela signifie principalement notre période de vie, à savoir le jour de 24 heures ou proche.

Après, cela devient plus un enregistreur dont le rôle est l'analyse, (avec les graphes éventuels) alors que pour moi et dans l'immédiat c'est principalement pour du suivi de consommation.

Le capteur lui même pouvant bien entendu servir à l'un comme à l'autre !

Les nouveaux langages ne me sont pas connus, aussi je préfère garder "mon marteau et mes clous"...

Au fait accumuler les Tops est pratiquement envoyer un index ?

Pour les transmissions, je ne sais pas à 2.4 GHz, mais à partir de 800 MHz, il semble qu'un simple trou de 1 cm dans un tampon métallique facilite la propagation.

Allez à un peu + tard quand la version simplifiée sera opérationnelle.

Meilleures salutations

lokistagnepas/bricolsec

[sven337]

En environnement Windows XP, forcément, la vie est plus difficile :)

Le meilleur choix pour ce genre de logiciel serait probablement un langage de script tel que Python, qui permet les modifications faciles. Mais je suis développeur C par passion et profession, donc si c'était à moi de le faire je l'écrirais en C.



Je ne suis pas forcément d'accord que le scan doit se faire "seulement une fois de temps en temps" pour un particulier. C'est quand même intéressant d'avoir des courbes précises de consommation, à l'échelle de la minute ou de l'heure.Une plaisanterie que je fais régulièrement à mes invités est de leur suggérer que je peux leur facturer précisément le gaz qu'ils consomment lorsqu'ils prennent une douche trop chaude chez moi :)

Pour cela bien sûr il faut enregistrer les données dans une base et faire des graphes (par exemple avec une page Javascript), et dans ce cas d'usage vous avez *de toute façon* tellement de post-traitement que vous n'avez pas besoin de la remontée d'info en ASCII.

On ne va pas se mentir, les courbes précises relèvent du gadget, mais de manière générale le suivi de consommation d'eau/électricité/gaz pour un particulier relève du gadget (au sens où on s'en passe très bien). Dans ce contexte où on fait quelque chose de beau et d'amusant plutôt que de vraiment utile, avoir des courbes précises est un objectif défendable.

La détection de fuite ou de robinet laissé ouvert est évidemment un point intéressant pour l'eau. La réaliser sur un R-Pi me semble être une bonne idée car le R-Pi est aisé à connecter à Internet, et dès lors vous pouvez l'utiliser pour envoyer un e-mail ou carrément un SMS au propriétaire.



(Pour ne pas perdre les tops index, la solution est de les accumuler au niveau de la tête radio, et d'envoyer non pas simplement un top mais un total de tops écoulés depuis le démarrage. Le récepteur se contente de faire une soustraction et verra s'il en a manqué un. En pratique, cela arrive de temps à autre. Sur votre version simplifiée, cela vous éviterait le problème de stocker l'index de départ dans le PIC : mettez-le à 0 et stockez-le côté récepteur. Plus simple, en admettant bien sûr qu'il y a du post-traitement côté récepteur.)



J'y pense, concernant la transmission radio : est-ce que le tampon en métal qui ferme le regard ne gêne pas la transmission ? J'ai fait ce genre de manips en 2.4GHz et rien ne passait.

[lokistagnepas]

Bonjour,

Merci du commentaire très complet et très intéressant.

Je suis assez d'accord avec votre approche, et c'est pour cela que le modèle "particulier" sera plus simple.

Pour l'informatique, je préfère et de loin, les assembleurs, car après Algol60, fortran_IV, cobol,C, je préfère le Pascal, mais les compilateurs pour ce dernier ne courent pas les rues dans l'environnement Windows XP.

Pour le particulier le peu d'informations à remonter est tout de même beaucoup plus pratique en ASCII, d'autant qu'il n'est pas question de scanner à outrance, mais seulement une fois de temps en temps, alors au niveau énergie ce sera dérisoire.

A remarquer toutes fois dans votre solution que les tops index peuvent se perdre et que cela peut occasionner des divergences d'index

Mais chacun voit "midi à sa pendule", ce qui est bien normal.

Vous avez la partie "pseudo analogique" vous pourrez donc l'adapter facilement à votre serveur.

Intéressant pour le RaspBerry et la RS232

Meilleures salutations

lokistagnepas/bricoslec

[sven337]

Bonjour,



merci pour ce très bon article, on voit que vous avez travaillé dur.

Je voudrais faire quelques remarques, d'abord sur le cas d'usage "particulier", et ensuite sur la partie informatique de votre réalisation.



Pour un particulier, je pense que le besoin est suffisamment différent de celui d'un exploitant pour justifier une réalisation qui diffère quelque peu. Ce que j'ai réalisé chez moi pour le gaz, c'est que chaque top d'index (= 10L de gaz) est accumulé dans la tête radio et immédiatement transmis à un mini serveur dans la maison. L'horodatage et le suivi de l'index sont réalisés par ce serveur.

La raison est la suivante : si le particulier dispose d'un mini terminal de relève radio, autant qu'il le laisse fonctionner en permanence (sinon quel intérêt d'avoir fait ce montage, autant se déplacer et aller lire le compteur directement). Sous l'hypothèse d'un dispositif fonctionnant en permanence en réception, à l'intérieur de l'habitation et donc branché sur secteur, on peut simplifier considérablement la tête radio, ce qui :

- réduira la consommation d'énergie

- sera plus simple pour le particulier lorsque les piles sont HS (pas besoin de re-programmer la tête radio avec un index de départ, puisque l'index sera géré dans l'informatique de réception)

- permettra de voir directement le débit consommé (puisque chaque impulsion sera transmise), au lieu d'avoir à dériver l'index calculé



Voir plus bas pour le dispositif qui me semble le meilleur choix.



Concernant la partie informatique, on voit que vous êtes plus à l'aise avec l'électronique analogique qu'avec l'informatique :)

Sérieusement, le post traitement avec OpenOffice n'est pas la solution. Il faut prévoir un logiciel dédié qui sera simple à écrire et plus rapide.

Oubliez le mode ASCII qui ne sert à rien d'autre que consommer des piles. Envoyez tout en mode binaire, le plus compact possible, comme vous l'avez prévu pour l'usage "production". Côté récepteur, un logiciel peut déconner les infos du paquet et les présenter de manière lisible par un être humain (ainsi que les enregistrer pour l'exploitant).

Une suggestion de conception que je peux vous faire pour le côté récepteur est d'utiliser un Raspberry Pi, petit ordinateur peu coûteux qui dispose d'une UART qui sera (moyennant quelques modifications) compatible avec votre récepteur 433MHz (en imaginant que vous teniez particulièrement à utiliser votre solution maison plutôt qu'un chip tout intégré type RFM12B). Un Linux sur le Raspberry Pi pourrait faire tourner un programme très simple pour recevoir les paquets et les décoder. D'ailleurs, si cela vous intéresse je veux bien l'écrire.



Avec un Raspberry Pi chez un particulier vous pourrez faire le suivi de consommation d'eau en temps réel, et puisqu'on en parle, le suivi d'électricité et de gaz également.

Pour le terminal de relève de l'exploitant, j'aurais plutôt tendance à choisir un ordinateur portable pas forcément récent, fonctionnant sous Linux et avec un PL2302 ou similaire pour interfacer l'USB avec le récepteur radio. Avec le logiciel adéquat on pourra ainsi faire le traitement très facilement. Une alternative sur smartphone est certainement possible.