Datalogger avec PIC16F877 et PIC16F628
DATALOG
GER
1 Caractéristiques générales
2 Éléments généraux
2.1 C'est quoi un datalogger ?
2.2 Stockage de données
2.3 Lieu de collecte des données
2.4 Structure de la chaîne
2.5 Les sondes de mesures
2.6 La Base De Mesures (BDM)
2.7 La Base De Stockage (BDS)
3 Le Schéma BDM
4 Les grands principes des mesures
5 L'étalon de temps
6 Le principe des TRIGS
7 Les liaisons radio
8 Sond
es
8.1 Sondes analogiques (température)
8.2 Sondes Logiques
9 Les calculs analogiques
10 Description Base De Stockage
11 Logiciel
11.1 Le programme principal PIC
11.2 La partie interruptions
11.3 Un faux problème rencontré sur PIC16F877A
11.4 LE CLAVIER
12 La RS232 (et radio)
13 Quelques points spécifiques
13.1 Voyants
13.2 Économies d'énergie
13.3 Résistances de rappel
13.4 Alimentations sondes
14 Conclusions
Si vous arrivez directement sur cette page par un moteur de recherche, vous pouvez avoir accès à la table des matières et à chaque article, en page d'accueil. L'accès se fait par l'un des deux liens en tête de colonne de droite ----->
ATTENTION à compter du 15/09/2019 les commentaires ne seront plus possibles à causes de quelques imbéciles qui font du spam pour le plaisir de nuire ! désolé !
Préambule
Toujours intéressé par les problèmes thermiques et hydrauliques, il me fallait tout de même réaliser quelques moyens d'enregistrement (électronique/informatique) de données pour pouvoir analyser les problèmes pour mieux les comprendre et ainsi mieux les résoudre.
Dans la panoplie des matériels d'enregistrement, il y a les appareils du commerce dont certains sont très petits et intéressants. Je pense au HOBO de PROCENSOR qui est réellement un joli produit technique extrêmement petit (taille d'une petite boîte d'allumettes !). En réalité c'est toute une gamme de produits, dont je ne retiendrai qu'un seul modèle, le HOBO 4 entrées.
Seule ombre au tableau, cet appareil réalise une conversion A/D sur seulement 8 bits. Alors c'est mieux que rien, mais aujourd'hui il me semble que c'est un peu juste, d'autant que le prix reste assez élevé pour le porte monnaie d'un amateur. En complément d'information cet appareil ne sait pas enregistrer seulement ce qui change mais scan méthodiquement, certes avec un temps paramétrable, mais il a des limites mémoire qui restent "certaines" et fonction du nombre d'entrées utilisées.
Alors si l'on veut mieux, on passe tout de suite sur les matériels professionnels mais avec des coûts pratiquement incompatibles avec l'amateurisme, et dont les principes restent le plus souvent comme le HOBO sur le SCAN périodique des entrées. (échantillonnage)
Dans les paragraphes qui suivent, je vais indiquer ma démarche qui m'a guidé vers une définition qui sera décrite ci-après.
Cet article est à la fois une ligne directrice d'idées et un guide de réalisation. La réalisation est indiquée en termes de principes, et les schémas théoriques sont pratiquement à jour. Les textes associés permettent cependant cette mise à jour au cas ou...(Résistances de rappel par ex).
De plus il m'est très difficile, à titre individuel de maintenir deux dossiers en //, car bien entendu je ne ferai pas deux appareils mais je me contenterai de celui réalisé.
Je crois qu'il faut prendre cet article comme une idée de base essentielle et retravailler l'ensemble et surtout la réalisation du circuit imprimé.
De fait l'idée de base a été concrétisée dans un nouvel article sur le blog lokistagnepas.
Ce nouveau développement est tout de même beaucoup plus pratique et répond mieux aux besoins d'enregistrements sans énergie.
Vous pouvez tout de même lire cet article et voir que la philosophie du nouveau modèle est assez différente et répond mieux aux besoins d'enregitrements de données...
1 Caractéristiques générales
- datalogger alimenté par batterie 8.75V de 7 éléments NiMH type R6 de 2500mAh
- régulation de tension et courant avec chargeur de batteries incorporé
5 Entrées Logiques 0 à 5V sur mini fiches bananes, dont L4 toujours interruptible.
5 Entrées ANAlogiques 0 à 5V avec conversion AD 10 bits sur connecteur DIN 5 broches
1 entrée comptage rapide à 65536 sur mini fiche banane
1 entrée mesure de temps, précision de 5 ms avec choix du front de déclenchement limitée à 24 heures (jack 3 contacts avec alim)
1 sortie RS232 DB9 3 fils TX RX(n.u.) et masse +12/-12
Choix de vitesse paramétrable 1200, 2400, 19200, 115200 avec valeur par défaut à 2400 bps
1 émetteur 433.92 MHz vers la Base de stockage
1 récepteur 433.92 MHz(utilisation ultérieure)
1 entrée DCF77
1 display LCD 2 lignes 16 caractères
1 clavier PC type PC-AT (Avec clock et data (Pas USB))
1 Processeur principal type PIC16F877 cadencé à 20 MHZ par Quartz avec plus de
6300 lignes programme pour 4 K de code.
1 Processeur auxiliaire de génération d'horloge PIC 16F628 4 MHZ cadencé par quartz à 3.2768 MHZ pour une centaine de lignes programme
- commandes séparées d'énergie pour chaque sonde avec visualisation et 8 voyants LED dont 5 extinguibles par interrupteur.
Précision des temps à 5ms.
Methodes de mesures
- périodicité de temps 1 seconde à 99 jours et méthode continue jusqu'à 15 ms en transmission directe à 19200 bps ou 115 200
- Ecarts de valeur de 0 à 999 par pas de 1/1024 en ANA
- Surveillance de seuils inférieurs ou supérieurs de 0 à 999 par pas de 1/1024
- Possibilités de 5 déclenchements différents
- surveillance possible de la batterie LOW_BAT (paramétrage automatique)
- mode économie d'énergie automatique (en mode périodicité de temps (scanning))
- alerte sonore par buzzer sur franchissements de seuils sur sonde 5 (mode LOW_BAT)
- extinction des voyants d'alimentation des sondes ANA par switch
- Paramétrage complet par clavier PC AT
2 Éléments généraux
Les différents principes sont donnés ci-après, mais un point // très important dirige aussi cette étude : trouver des composants (localement ?) ou chez les annonceurs connus et faire un circuit compatible avec l'amateurisme (simple face de préférence). Ce problème dans la France "profonde" devient réellement crucial, car tous les petits distributeurs mettent la clef sous le paillasson et il ne reste plus que quelques "gros" qui dédaignent le plus souvent à s'embêter avec les petits bricoleurs ou qui forcent un peu sur les frais de port en guise de dissuasion.
(En ce sens Messieurs les "gros" n'oubliez jamais que ce sont les petits ruisseaux qui font les grandes rivières…)
Si il ne faut utiliser que des composants standard et connus, cela limite les possibilités, mais en même temps, cela reste un gage de retrouver toujours les composants en cas de problème.
Cet article ne concerne que le datalogger lui-même. La première sonde de température réalisée n'a pas donné de bons résultats et sera simplement ébauchée puisque destinée à être remplacée. D'autres sondes de température feront l'objet d'autres articles pour ne pas bloquer trop longtemps cet article du datalogger.
Quant à la deuxième partie qui est la base de stockage (BDS), elle fera aussi partie d'un futur article séparé, car elle pourrait s'appeler également "convertisseur RS232" binaire-ASCII et pourrait éventuellement avoir d'autres utilisations.
2.1 C'est quoi un datalogger ?
C'est un ensemble électronique et informatique, d'éléments permettant d'acquérir des données sur des phénomènes à analyser, que l'on souhaite vérifier ou dont on veut connaître les lois de variation, pour pouvoir les améliorer, les comprendre etc….
C'est ce que l'on appelle de l'acquisition de données.
Le datalogger décrit est en réalité composé de plusieurs éléments dont deux éléments principaux (hors PC) et de sondes de mesures de différentes grandeurs physiques (Tension, température, courant, pression…)
Ce que j'ai voulu en plus et qui est certainement peu répandu, (mais je n'ai fait que très peu de recherches sur ce sujet), c'est la collecte de données SIGNIFICATIVES (explications ci-après).
En plus de ce dernier point important, j'ai aussi voulu avoir des fonctions de mesures précises de temps (0/+5 ms) sur environ 24 heures, et également du simple comptage d'impulsions jusqu'à 65000.
2.2 Stockage de données
Une récente expérience de stockage avec PIC 16F628 et mémoire RAM (mon premier projet PIC) s'étant révélée plus que délicate, (j'ai dû abandonner suite à une erreur de conception) non pas au niveau programmation, mais au niveau hardware, je n'ai pas voulu réitérer cette opération qui de plus était très limitée en place mémoire. J'ai donc décidé de ne plus stocker les données dans le datalogger lui-même, mais directement sur un PC.
De plus ce stockage local était plus compliqué, et moins performant sur des valeurs représentées autrement que sur 8 bits.
Enfin au niveau énergie, la consommation restait non négligeable et nécessairement alimentée par le secteur. On ajoutera que la panne de batteries éventuelle pouvait mettre à zéro toute une campagne de mesures par la perte complète des données.
On remarquera aussi que le coeur de mesure de cet appareil était un PIC, et que ceux-ci pour le "middle range", ne regorgent pas de mémoire vive et qu'il était nécessaire d'en constituer spécialement…
(Pas possible de trouver les "datasheet" de quelques mémoires utilisées dans les clefs USB ni de trouver ces composants, alors j'ai jeté l'éponge !)
Alors plus que jamais ce choix de stocker les données sur le PC semble une bonne solution pour l'amateur, mais peut-être aussi pour les professionnels. "Un PC lourd" n'est pas à côté des points de mesure ? Pas de réel problème, la radio pourra faire la liaison manquante, et ceci est expliqué au paragraphe suivant.
Un Netbook peut également faire l'affaire à l'aide d'un convertisseur RS232/USB. (Câbles adaptateurs avec électronique intégrée jusqu'à 115200 bps)
2.3 Lieu de collecte des données
Il est évident que le PC, même s'il s'agit d'un portable, ne sera pas toujours à côté des données. Aussi ces données pourront être transmises par radio, entre la base de mesure et le PC. Les liaisons filaires longues sont toujours pénibles...
Il aurait été souhaitable que chaque point de mesure puisse être indépendant et transmette par radio à la base ses données, mais ce ne sera pas le cas.
Cela n'a pas été réalisé ainsi, pour plusieurs raisons :
- Les problèmes de collisions d'informations radio asynchrones nécessitent des fonctions émission/réception synchronisées sur chaque élément, pour éviter ces collisions (ou la détection de ces collisions et le "retry", voire par pooling).
- Les équipements de transmissions coûtent un certain prix, et cela dépasse le budget prévu. De plus les problèmes techniques de collisions sont ardus à résoudre.
- Enfin le volume de travail pour réaliser un tel équipement dépasse mes seules possibilités effectives d'aboutir dans un temps raisonnable.
Ainsi j'ai retenu la structure qui suit, qui me parait un compromis acceptable au titre de réalisateur amateur.
Un PC est relié par liaison filaire courte (RS232 DB9) à un petit équipement avec PIC 16F628 équipé seulement d'un récepteur radio. Pour simplifier la description, appelons cet ensemble la base de stockage (BDS), et par extension, cette BDS représentera l'ensemble PC+BDS.
Cette base de stockage (BDS) recevra les données par radio en provenance de la base de mesures (BDM).
Cette base de mesure BDM est l'élément central de cette chaîne le plus important, puisqu'il peut fonctionner sans la BDS, (directement avec un PC).
Elle peut donc travailler en direct avec le PC par liaison RS232 et à grande vitesse (pointillé du schéma).
Les vitesses de transmission radio possibles sont données par la bande passante des émetteurs et récepteurs radio qui ne dépasse pas 4 KHz.
Au niveau RS232, il serait possible d'atteindre 115200 bps, ce qui désengorgerait immédiatement la base stockage (BDS), mais des problèmes de déviation de fréquence centrale se posaient et 19200 bps semblaient une limite dans mon contexte immédiat de connexion directe de la base de mesure.
Ce point est maintenant résolu et 115200 bps fonctionne maintenant sans problème car il était dû à une ambiguité des documentations PIC (voir §10 de mon article sur les trucs MPLAB)
Il est inutile de travailler en double buffer de transmission au niveau BDM, car les temps de transmission représentent au moins 90% du temps total d'un cycle complet Mesures/Transmissions.
Il faudra donc attendre la fin de transmission qui est pratiquement la principale limitation à la vitesse de SCAN des entrées. (environ 0.2 secondes maxi).
On verra pourtant qu'il y a un minimum de temps à la montée en tension des différentes sondes alimentées (ou non) et que cela peut amener à réduire ce ratio. Pour ce faire et si les temps sont importants, il n'y aura pas d'autre solution que d'alimenter en permanence certaines sondes. (Une borne d'alim permanente est prévue sur la connectique ANA)
La transmission radio ne véhiculera en cycle de mesures que des INFORMATIONS BINAIRES pour la seule raison de réduction du temps de transmission. La base de stockage (BDS) aura également pour mission la conversion de ces données binaires en ASCII, ainsi que le contrôle de la cohérence des données radio transmises. Pour simplifier, et réduire les temps de transmission, je n'ai pas ajouté de clé de contrôle de parité, sur ces données de 8 bits.
La configuration des entrées ANA sera automatiquement transmise à la BDS pour établir la structure de conversion (En d'autres termes combien d'octets binaires vont constituer une donnée, cela tout au long d'une trame complète !)
La connexion directe au PC se réalisera en binaire, OU avec une conversion ASCII possible et paramétrable à la configuration, tout comme la vitesse.
Cette phase de transmission directe AVEC conversion ASCII a été nécessitée pour la simplification de la vérification du fonctionnement mais est finalement très intéressante pour ceux qui ne voudront pas aller jusqu'aux transmissions radio.
Je vais d'ailleurs temporiser moi-même le développement de la BDS, car j'ai fait des essais avec NETBOOK et un câble USB/RS232 qui donne satisfaction avec l'excellent logiciel RS232 "Terminal de Bray++", (et maintenant jusqu'à 115200 bps).
La base de mesures (BDM), cœur réel du système, est placée à proximité des valeurs à mesurer, sans toutes fois y coller réellement. En effet, à cette base de mesures sont raccordées physiquement les différentes sondes de mesures par liaisons filaires métalliques.
Ces sondes de mesures devront donner des signaux 0-5V logiques ou analogiques.
La base de mesures BDM devrait pouvoir éventuellement recevoir quelques entrées 4-20mA. ou des entrées Fréquence avec conversions appropriées.
Cette même base BDM assurera l'horodatage des mesures (en BINAIRE également), car c'est le lieu le plus adapté pour que l'horodatage soit le plus proche de la réalité possible, tout en n'étant pas dupliqué inutilement sur chaque sonde.
NOTA : Il aurait été plus qu'intéressant d'horodater sur la BDS car on gagnait ainsi 5 octets en temps de transmission (J,H,M,S,D), mais le temps n'aurait pas eu la précision souhaitée. (De plus il aurait été impératif de développer la BDS)
Suivant les cas, l'horodatage sera appliqué en premier aux valeurs analogiques (et dans l'ordre des N° de sonde), dont le temps sera absolument exact à quelques centaines de µ secondes près. Pour les données logiques, le temps sera en suivant avec environ 70 µs de temps de mesure pour chaque entrée ANA (en fonction de leur utilisation réelle ou non : temps de conversion), auxquels sont à ajouter les temps de sécurité de commutation des alimentations de 10 ms (les derniers essais donnent un temps de montée réel de 1.5 ms qui semble "bien").
Dans le cas où des écarts analogiques (DELTAS) ne sont pas surveillés en permanence, ce seront les sondes logiques qui seront les premières examinées.
Ceci est simple à expliquer, car si il s'agit seulement de Scan, et on ne regarde pas les sondes ANA autrement qu'aux instants prévus. Par opposition, si il y a Delta ou seuil, il faut analyser en permanence les entrées ANA pour vérifier les valeurs.
Cet horodatage en temps absolu, sera effectué sur la base initiale de l'émetteur DCF77 bien connu et ayant déjà fait ses preuves avec la réalisation du simulateur de présence (voir l'article). Les écarts de temps éventuels et relatifs dépendent de la précision du quartz horloge temps réel associé au PIC générateur d'horloge.
La mise à l'heure sur l'horloge atomique du DCF77 permet des campagnes de mesures très éloignées (mais synchronisées) avec plusieurs appareils de ce type. Seule la mise à l'heure initiale est effectuée ainsi. Le temps est ensuite traité par une base de temps spéciale à quartz de 3.2768 MHZ indépendante de la vitesse de traitement. Tous les écarts de temps sont ensuite calculés en relatif, mais les temps transmis sont en absolu.
Pour information le temps relatif system en secondes est compté sur 24 bits ce qui donne une valeur maxi de 99 Jours pour une campagne de mesures. Ce temps correspond au paramétrage mais non à l'horodatage des mesures qui est en temps absolu en jours, heures, minutes, secondes et 1/200s.
Pour compléments d'explications, les calculs sur les temps séparés en J,H,M,S,D ne sont pas réalisables ainsi, aussi le temps relatif est un temps // sur 24 bits qui autorise les calculs.
2.5 Les sondes de mesures
Elles seront principalement alimentées par les accus rechargeables NiMh de la base de mesures BDM, de modèle HR6 ou AA ou dimensionnel LR6.
Ainsi ces sondes seront sans énergie auxiliaire.
Elles devraient pouvoir convertir toutes les grandeurs physiques en valeurs analogiques 0-5V. Il est exact que le transport d'informations en tension est moins sécuritaire que la boucle de courant 4-20mA, mais au niveau énergie, il n'y a pas à se poser de questions !
Des sondes logiques sont également nécessaires pour faire la relation entre l'évolution de grandeurs physiques et l'enclenchement d'un processus (suivi de la température d'une pièce relativement à l'enclenchement d'un convecteur par exemple), elles sont au nombre de 5.
Les sondes ANA de température sont les plus intéressantes et sont celles qui dirigent l'essentiel de cet appareil, mais les mesures de pression sont aussi très importantes mais d'un coût très différent.
Ces sondes pour la partie température sont délicates à définir, car plusieurs principes interfèrent et conduisent à plusieurs possibilités.
Les sondes de tout type recevront leur énergie en 8.75V (maxi 10 mA) de façon commutée depuis la base de mesures. Aussi on préfèrera des appareils 0-5V ou 0-10V (avec pont diviseur) aux traditionnels 4-20 mA qui n'écessitent plus d'énergie (et des tensions plus élevées).
Un des points importants est de n'alimenter les sondes que lorsque l'on désire faire une mesure. Les temps d'établissement des tensions ne doivent pas être prohibitifs. voici un exemple de la mise sous tension de l'ancien modèle de sonde de température.
On notera que sur une longueur de 4.5 mètres, les temps
de mise sous tension restent assez courts. (1.5 ms pour atteindre 5 V).
Il y a plusieurs raisons à cela, dont une essentielle qui est de réduire au strict minimum le condensateur à l'entrée, mais également en sortie de régulation. Cela permet des temps de montée assez raides.
La deuxième raison est énergétique, puisque la décharge des condensateurs représente une énergie perdue en pure perte. (un condensateur se comporte un peu comme une inertie mécanique et il faut de l'énergie pour le charger et sa décharge est comparable à une "roue libre" et c'est une pure perte d'énergie).
L'énergie régulée, et principalement la sortie de tension, peut rester présente bien après la coupure de l'alimentation (coupée ici à 10 ms).
Au delà de ces temps, cette énergie est perdue, et il faut donc limiter les condensateurs tout en ayant un fonctionnement correct sans oscillations et sans anomalies.
2.6 La base de mesur
es (BDM)
Elle comportera un PIC 8 bits type 16F877 cadencé à 20 MHZ qui assurera le scanning de toutes les entrées, les conversions AD et les calculs pour un affichage LCD (Display) simplifié, un récepteur DCF77 permettant un horodatage initial précis, et d'un émetteur de données à destination de la base de stockage (BDS).
Outre ces fonctions d'exécution propre, une importante partie de la programmation consiste en l'acquisition des paramètres de ces mesures. C'est pourquoi un clavier a été rendu nécessaire pour éviter une programmation "acrobatique et réellement longue et ennuyeuse"
(quelques touches avec flèches par ex.).
Les fonctions de conversion et de calculs sur entiers de (32), 24, 16 et 8 bits sont également très présentes et assurent les calculs analogiques d'écarts de temps et de temps atteint ainsi que la présentation des données.
Les limitations de calculs sur entiers de plus de 8 bits et les impératifs de rapidité conduisent à ne réaliser que les calculs indispensables. (Les calculs de mise en forme seront réalisés sur le tableur)
La présentation finale sera réalisée directement sur tableur qui possède de larges "atouts" en ce domaine. Ainsi l'affectation des 1024 éléments logiques de conversion analogique aux unités employées sera nécessairement réalisée sur le tableur pour rendre le datalogger généraliste et capable ainsi de traiter toute grandeur physique.
L'horodatage sera précis à 5 ms près ce qui pour beaucoup de phénomènes reste une bonne précision. La valeur du temps (après initialisation) sera donnée par une horloge à quartz séparée et synchronisée au départ des mesures.
Pour les phénomènes rapides et ultra-rapides, l'appareil ne convient pas, car à ce stade c'est un oscilloscope qui est nécessaire (ou autre appareil spécifique genre analyseur), mais les fonctions de comptage proposées restent tout de même intéressantes en analyse technique, tout autant que la fonction de mesure précise de temps très longs (étendue de 24 heures maxi)
Les conversions AD seront réalisées directement par le PIC, sur 10 bits, soit 1024 éléments ce qui est une bonne approche de précision.
Les principes de mesures décrits au §2 représentent le réel intérêt de cet appareil :
En effet, la base de mesures assurera plusieurs méthodes d'analyse des entrées et ceci représente un avantage indéniable pour ne pas stocker inutilement des données sans intérêt, et pour éviter des recherches inutiles de données perdues au milieu de valeurs sans signification réellement utile.
Le rôle de la BDM est aussi et avant tout, d'envoyer les données vers la base de stockage (BDS), sans toutes fois en perdre par "erreur de transmission". Ce principe limitera réellement la fréquence d'acquisition à cause de la faible vitesse des transmissions radio utilisées.
Pour réduire ce temps de transmission, la base de mesures enverra les données en binaire pur (sans contrôle de clef) à destination de la base stockage.
Dans cet esprit de rapidité, toute sonde ANA non utilisée ne sera pas transmise, et le temps de SCAN possible sera ainsi amélioré. Du nombre de sondes ANA dépendra le nombre de cycles de boucles possibles, tant en calculs du convertisseur AD que de la transmission RS232.
La gestion des jours réels, jour de la semaine et des mois ne sera pas réalisée.
Les jours seront simplement remis à zéro en début de mesures, puis incrémentés à compter de la date initiale pour des questions de place occupée inutilement en transmission. (Le jour réel pourra être traité sur tableur par simple addition sur la date initiale)
Le début du fichier sera renseignera en clair (ASCII) la date complète et l'heure initiale et donnera toutes les informations de révision et de paramétrage.
(La date complète initiale (DCF77 ou manuelle) sera toujours incluse en tête du fichier).
La base de mesures (BDM) aura sa propre alimentation sur batterie LR6 et comportera un chargeur régulé (avec LM317 1A régulé en tension et limitation de courant à 250 mA (C/10)).
Un display de 2 lignes de 16 caractères résume les mesures ANA et LOG et affiche en permanence l'heure. Le display témoigne du bon fonctionnement de l'ensemble, avec des valeurs approchées pour les sondes analogiques (limitation à 2 digits)
2.7 La Base De Stockage (BDS)
Cette base BDS est un nœud de transmission. Elle recevra les données BINAIRES en provenance de la base de mesures. Elle transforme ces données binaires en ASCII et les envoie au PC.
Elle n'est pas encore développée à ce jour, mais a eu une première réponse en termes fonctionnels, puisque la partie conversion sera identique à celle développée sur la BDM pour la sortie ASCII.
Un schéma provisoire à base de 2 PIC avait été envisagé, mais s'est avéré critique, voire impossible, d'un point de vue des timings. (Le transfert de PIC à PIC étant beaucoup trop lent par quartet).
En effet le problème majeur est l'unique Baud Rate Générator (BRG) sur le PIC. De plus il était nécessaire de se trouver le plus près possible des fréquences normalisées des BRG, surtout côté PC où les transmissions devraient se réaliser à vitesses élevée (115200 projeté, et maintenant vérifié, mais j'ai eu peur de devoir redescendre à 19200 qui semblait seul fonctionner à cause d'un léger problème de doc) (Plus d'infos sur "Quelques Trucs MPLAB")
Aussi ce schéma à double PIC risquerait de ne pas fonctionner à cause de l'obligatoire transfert entre les deux PIC qui aurait pris beaucoup de temps.
Je m'oriente maintenant vers un PIC 20 MHZ de Type 16F628 largement suffisant pour gérer émission et réception RS232 half duplex mais pour lequel on sera obligé de changer de baud rate en fonction de la transmission ou de la réception. Ceci implique un fonctionnement à l'alternat et ne sera donc jamais en full duplex, mais posera peut-être quelques problèmes de commutation de vitesse BRG ?
Vous aurez compris que je vais pouvoir utiliser le montage avec 16F877 actuel pour développer une grande partie du logiciel, et mettre au point la partie réception que je n'ai encore jamais essayée.
Le passage sur 16F628 n'étant plus alors qu'une "simple formalité".
La transmission vers le PC devra donc être très rapide, car elle utilisera le temps mort mis à profit pour stabiliser la tension de l'émetteur 433.92 MHz.
Actuellement ce temps incompressible est de 5 ms mais sera mis à profit pour transmettre vers le PC, et il devra peut-être (?) subir une légère augmentation pour permettre d'assurer la sécurité transmission et réception.
Le temps le plus "étroit" est lorsqu'il n'y a que des sondes Logiques en vitesse maxi. Ce temps des calculs mesuré est de 2 ms en mode binaire comme en ASCII.
En Binaire, le temps de transmission est de 50 ms environ pour 120 ms en mode ASCII. Ces mesures ont été réalisées sur la pin 35 du PIC qui assure la commande de l'émetteur radio.
Le temps d'émission comportant un délai de 5 ms de MST Radio nécessaire ajouté à 2 ms de calculs couvrira pratiquement la transmission à 115200 bps de 65 caractères au maximum.
Avec 5 sondes ANA à vitesse maxi, le temps de calcul est de 55 ms environ et de 90 ms de transmission en mode binaire à 2400 bps.
Avec 5 sondes ANA à vitesse maxi, le temps de calcul est de 55ms environ et de 275 ms de transmission en mode ASCII à 2400 bps.
Il faut aussi remarquer que le temps de calcul varie de 2 ms à 55 ms suivant le mini ou le maxi de sondes ANA (sans les sondes spéciales TMR1 et RB0)
Par temps de calcul il faut seulement comprendre le temps d'exploration de la boucle SCAN. (Dans le temps de transmission est inclu le temps de conversion lorsque l'on est en ASCII).
A la lumière de ces valeurs, on voit parfaitement la difficulté à transmettre vers le PC, 65 bytes, même à 115200 bps, car cela ferait au mieux 5.6 ms.
On aura remarqué qu'à partir du moment où une émission Radio est lancée, il est exclu de modifier le BRG pour aller en grande vitesse vers le PC. Il resterait donc au pire 2 ms de temps de calculs, + 5 ms de délai de MST, à la condition d'avoir permuté préalablement les buffers.
On est donc dans des valeurs extrêmement proches et la seule solution pour "passer" sera d'ajuster le délai de MST de l'émetteur de quelques ms supplémentaires (au besoin).
La seule possibilité est donc de changer le BRG dès la fin de l'émission radio de croiser les buffers émission/réception et d'envoyer alors les datas vers le PC. (La détection pourra se faire sur "0D" et longueur atteinte)
J'avais mal évalué cet aspect très serré des temps, je vais encore y réfléchir, mais je pense qu'il ne faut qu'un seul PIC pour tout traiter.
3 Le Schéma BDM
.
.
Il est donné ci-dessus et ne présente pas de difficultés si ce n'est de réalisation et de finalisation des adaptations des entrées. Il est évident que ce schéma ne peut s'accorder qu'avec le logiciel développé.
On peut critiquer quelques points notamment l'oubli (rectifié) des résistances de fixation des potentiels sur les 5 entrées logiques, TMR1 et RB0 et les deux lignes du clavier (qui peut être débranché). Vous devrez les ajouter soit sur le CI soit directement sur la connectique retenue.
Par économie et simplification, il est tout à fait possible de ne pas utiliser le DCF77 puisque la date complète et l'heure peuvent être entrés au clavier.
Le reconnaissance de la présence DCF (signal à 0 initial avant de passer à 1 après 10 à 15 secondes) se fait automatiquement et le clavier est alors requis pour entrer la date et l'heure.
On remarquera un strap en réception RX qui permettra de recevoir (quoi ?) par liaison directe PC (alim RX désactivée) ou par radio (strap ouvert). J'avais tout de même quelques petites idées derrière la tête pour cela, et j'ai pensé à des transmetteurs tout autant qu'au PC pour paramétrer le datalogger...
Et puis cela servira aussi à mettre au point le programme de la BDS !
Une diode anti-inversion permet une charge tant en continu qu'en alternatif.
La partie transistors et LED émission réception est différente pour que les voyants soient éteints en l'absence de traffic. (Un BC557 PNP a résolu le problème pour l'émission)
Un dernier point concerne l'alimentation des sondes, et le signal logique 0-5V généré au collecteur des transistors Q3,4,5,6,8 est remplacé maintenant par du 8.75 V, ce qui permettra d'alimenter les sondes avec seulement 3 fils ou 1 câble blindé 2 conducteurs (Masse au blindage, + et signal ). Cette ultime modif donne satisfaction sur la sonde de température ancien modèle.
La connectique est toujours délicate mais à chacun de mettre ce qu'il a sous la main. Le plus long et difficile est de sertir (ou souder) des petits connecteurs Berg sans outillage particulier.
Un dispositif à économie d'énergie pour LED avait été décrit dans un article précédent, il a été installé mais ne répondait plus au problème spécifique. En effet la vitesse de SCAN des sondes peut aller à moins de 100 µs, et dans ce cas l'éclairement est insuffisant. Il a tout de même permis de mettre un interrupteur très facilement en lieu et place du condensateur.
Un interrupteur a donc été installé sur les voyants d'alimentation des sondes ANA seulement.
Les LED TX et RX ont été laissées en fonctionnement normal, car il faut tout de même un minimum de signalisation.
Pour la mise au point j'ai ajouté en "volant" une LED 2 couleurs à côté du module émetteur qui fonctionne avec l'alimentation de chacun des modules Télécontrolli pour me guider dans la mise au point. A vous de voir si vous voulez vous contenter de RX et TX. (Je démonterai cela à la fin de l'ensemble mis au point)
Le connecteur DCF77 est à 4 broches coudées comportant l'alimentation du module (3 mA) . Le module peut être enlevé dès la synchronisation effectuée.
La LED de l'alim ANA_0 est maintenant de couleur verte pour indiquer les étapes de synchronisation DCF77 (comme sur le simulateur de présence, 0=vert 1=rouge et clignotement alternatif rapide à la minute synchronisée)
4 Les grands principes des mesures
Le plus connu est le principe d'un scan périodique (toutes les secondes, 10 secondes , minutes , heures, jours, etc…) On réalise ainsi un échantillonnage régulier des valeurs (de façon linéaire dans le temps). On perd par contre les informations situées entre chaque scrutation, ce qui me parait tout de même assez dommageable.
Ainsi on relève TOUTES les entrées aux instants prévus. Cependant, beaucoup de mesures sont inutiles tant qu'une variation ne se manifeste pas et des éléments intéressants sont donc perdus.
Ce principe est cependant utile pour avoir une idée de l'évolution d'un signal et ne pas avoir uniquement les points "extrêmes".
Plus la "distance" entre chaque mesure est grande, plus la capacité de temps d'analyse augmente. Mais il y a d'autres méthodes pour parvenir à ce résultat. Voici un résumé de ce que ce datalogger peut réaliser :
- mesures à intervalles réguliers en ANA et LOG (SCAN)
- mesures si la valeur observée en ANA (Delta) s'écarte de plus de x% (résolution en 1/1024 ème) de sa précédente valeur ANA
- mesures sur changement d'état en LOG
- contrôle de non dépassement d'un seuil supérieur (avec bip)
- contrôle de non dépassement d'un seuil inférieur (avec bip ou buzzer permanent)
- Mesure de temps entre phénomènes par interrupt
- comptage d'impulsions avec preset maxi de 65536 et interrupt.
- surveillance possible de la batterie de la BDM (sonde spéciale dans une fiche DIN)
- présence de la configuration initiale (binaire) et du type de déclenchement en tête de fichier
Toutes ces possibilités sont mixables sur une même sonde ou sur plusieurs sondes à concurrence de 5 déclenchements différents maxi. (Sauf comptage et mesure de temps qui ne sont pas mixables mais dont les déclenchements sont inclus dans les 5 possibles)
Pour imager le sujet et pour "faire la pause café", il ne sert à rien de mesurer toutes les secondes le niveau des précipitations durant la canicule !
Cela ne facilite pas le dépouillement des données et de plus prend beaucoup de place dans les fichiers si l'on veut une fréquence d'échantillonnage rapprochée.
En d'autres termes il est parfois plus judicieux de rechercher une variation sur une ou plusieurs entrées et de collecter l'ensemble des données pour envoi.
Ainsi, toujours dans l'exemple précédent, la venue de la pluie ou du vent ou de l'obscurcissement du soleil peut témoigner d'un changement de temps. Dans ces conditions, au moins un de ces 3 paramètres devrait déclencher une mesure globale (ou même les 3 à la fois) qui peut comprendre, outre la température extérieure, bien d'autres paramètres.
On va donc essayer d'appliquer ce principe sur les grandeurs à mesurer. Le plus facile n'est pas obligatoirement représenté par les grandeurs logiques…
Une seule grandeur logique peut interrompre par RB0 et permettre des mesures de temps. Cette entrée est un peu particulière et surtout destinée à être très précise sur une durée plus limitée. C'est une mesure précise de temps !
Pour les 5 autres entrées logiques, on pourra choisir soit le changement d'état, soit un intervalle de temps.
Pour les entrées analogiques, (ANAx) on pourra choisir soit un delta de valeur (en plus ou en moins de la valeur centrale (valeur absolue)), soit un intervalle de temps.
On notera l'entrée L4 toujours en interrupts. (Le changement d'état n'a donc pas besoin de faire l'objet d'un TRIG)
Enfin dernière méthode ajoutée in-extrémis, que j'avais oubliée, est l'enregistrement de données sur dépassement de valeurs limites (seuils).
Valeurs supérieures ou inférieures, avec enregistrement des seuls franchissements (double sens) de consignes, car il ne sert rien d'enregistrer 50 000 fois que l'on est au dessus de la température limite par exemple. Il faut le signaler une fois à chaque franchissement de seuil. (On n'est à ce stade, ni en régulation, ni en résolution de problèmes mais seulement en enregistrement de données !)
On remarquera que sur un SCAN périodique, toutes les entrées validées sont présentes. Cela complète les valeurs de franchissement mais est également utile pour EXCEL (V5) qui demandait en standard toutes les valeurs Y pour un même X (un paramétrage différent est possible, je viens de le constater, mais nécessite de le préciser).
Une dernière entrée logique spéciale consiste en l'entrée de comptage sur le timer 1, où là aussi on pourra choisir un nombre sur 16 bits (qui sera mis en négatif par le programme et décompté) et qui fera une interruption lors de chaque passage à 0 du compteur.
En résumé il y aura 5 possibilités effectives pour DÉCLENCHER une série de mesures (TRIG). Suite à ces possibilités, les 5 entrées logiques STANDARD seront systématiquement enregistrées et seulement les entrées analogiques opérationnelles (ANA_USED) seront mesurées ET enregistrées.
Ces possibilités sans ordre pré-établi seront paramétrées en début de programme. Un numéro de sonde interne permet de rendre jointives ces informations et un numéro de sonde va toujours de 0 à 4 aussi bien en LOG que ANA (exception Timer 1 et RB0 respectivement 5 et 6 en ANA). La distinction se fait au niveau du type.
Un byte spécial (ANA_USED) renseignera alors sur l'état utilisé ou non des 5 sondes Analogiques et des 2 sondes logiques spéciales (5 et 6).
L'entrée logique L4 sera toujours active au niveau interruption mais sa précision "fine" est dépendante du temps de boucle du SCAN puisqu'elle est enregistrée en termes d'interruption, mais ne sera exploitée qu'en fin de SCAN. (Tout changement d'état sera toujours surnuméraire en termes d'enregistrements)
5 L'étalon de temps
Ce point est certainement un des points les plus délicats à traiter pour avoir une bonne précision.
Après avoir retourné le problème de "X" façons, j'en suis arrivé à la conclusion qu'il faut l'étalon de temps sur le PIC de la base mesures (BDM), pour avoir la meilleure précision.
Tant pis pour l'envoi par radio qui prendra systématiquement 5 bytes de temps absolu (à 1200 bps ou 2400 à voir) soit une perte de temps d'un peu plus de 40 ms par trame.
Chaque trame si elle est complète sera composée de 26 bytes (binaire) au maximum comprenant dans l'ordre :
SYN,STX,ADR,J,H,M,S,5MS,SCAN,LOG,A0H,A0L,A1H,A1L,A2H,A2L,A3H,A3L,A4H,A4L,TMR1H,TMR1L, et 3 bytes de mesure de temps, CR,
soit un temps total et maximum de transmission total de l'ordre 100 mS à 2400 bps ou 200ms à 1200bps.
Ce temps ne peut être que le temps minimum de scan qui sera toujours un peu dépassé à cause des autres calculs nécessaires, surveillances diverses, interruptions et affichages.
Cependant le temps transmis vers le PC sera le temps relevé au moment du déclenchement de la première mesure Logique déclenchée par un temps de scan atteint, soit sur un évènement déclencheur par exemple une valeur supérieure à la résolution demandée ou une interruption.
Le deuxième point important dans la réalisation est de limiter le nombre de composants. Alors si il faut diviser en décimal une fréquence de base, quoi de plus simple qu'un PIC ?
Cela ne sera pas facile pour autant si on veut garder chaque élément de temps à sa juste place. En d'autres termes chaque µS devra avoir sa position précise dans le temps. (Ceci évitera le jitter (ou la gigue), bien que cela n'affecte pas réellement le processeur principal 16F877, mais c'est tout de même plus propre et surtout pour les observations au scope).
Télécharger ce fichier assembleur DATA628_3 .ASM (32 KO)
Le problème des interruptions avec un "preload du timer 0 (TMR0)" induit des erreurs de temps surtout si la valeur préchargée est faible. Il faut alors ajuster en valeur "moyenne" comme cela a été fait sur la réalisation du simulateur de présence déjà décrite et qui donne cependant satisfaction.
Se souvenir que le "preload" remet à zéro le prescaler, et c'est donc du temps qui disparaît du comptage. On est alors obligé de "moyenner" avec quelques instructions NOP. Il est exact que pour un simulateur de présence, cela n'a pas beaucoup d'importance.
Ça en a un peu plus pour le datalogger, car en mesures réelles, il faut essayer d'être plus précis (surtout pour des ensembles synchronisés). Il faut aussi utiliser les composants du commerce sans recours à l'exotisme souvent utile mais non disponible facilement. Alors, je n'ai rien trouvé de mieux que d'empiler des instructions sur un PIC 16F628 qui ne servira qu'à générer un signal d'horloge STABLE issu d'un quartz standard de 3.2768MHZ.
Ce programme essentiellement constitué d'instructions NOP ou GOTO ou cycles équivalents comptés devra donner un temps sur un port de sortie de 19.53125 µS.
Ce temps de base sera lui-même introduit dans le PIC 16F877 en TMR0 RA4/TOCKI, et compté jusqu'à 256, cela donnant une résolution à l'interrupt de 5 MS.
Cette résolution servira à horodater toutes les mesures.
On remarquera que ce temps sera bien fixe, précis et indépendant de la charge du PIC et/ou des réponses à des interrupts. (Le temps d'horodatage sera donc un temps effectivement toujours atteint juste ou dépassé)
Ce temps de résolution est également intéressant car il est précis et autorise le comptage sur un octet unique, ce qui ne serait pas le cas en descendant jusqu'à 2.5 mS, car il faudrait cette fois compter sur 2 octets (doublement de la précision avec une complexité un peu plus importante).
On remarquera que ce dernier choix mériterait de descendre au moins à 1.25mS pour utiliser au mieux ce deuxième octet de comptage !
La mise à jour de l'horloge du PIC principal ou de toute autre interruption, ne devrait pas durer plus de 5 mS (sous peine "d'oublier" une unité de 5 mS) ce qui à 20 MHZ de cycle ne pose aucun problème.
Au niveau des temps, il faut aussi ajouter que la mesure des temps à l'aide de l'entrée RB0_INT se veut d'une bonne précision. Aussi, le temps entre fronts sera mesuré non pas à la seconde près mais à 5 ms.
Ceci limitera à cause des calculs en 24 bits la plage de mesures à 23.301688 heures, donc pratiquement 24 heures. Les valeurs transmises seront indiquées en 1/200 de seconde. Le "redressement" en 1/1000 de secondes, "plus pratiques", pourra être effectué sur le tableur, car cette opération nécessiterait de passer en 32 bits de résolution, ce qui devient largement "l'usine à gaz" pour une précision parfaitement identique.
Ceci sera fait suivant la troisième méthode décrite à l'article "Quelques truc sur MPLAB" paragraphe 9 3ème Solution.
6 Le principe des TRIGS
Que sont les TRIGS ?
Ce principe est intéressant et à ma connaissance n'est pas ou peu répandu ?
Cela consiste à déclencher une mesure sur des évènements tels que ceux qui ont été définis au §2.
C'est par cette table des déclenchements que l'on va pouvoir ne prendre en compte que les éléments significatifs des grandeurs mesurées. (Seuils, écarts de x%, valeur de temps…)
Le principe est largement identique à l'entrée "Trigger" d'un oscilloscope et se rapproche des fonctions d'un analyseur logique. On va donc définir un certain nombre de TRIGS possibles (5 (et à ne pas confondre avec le nombre de sondes)).
Ces TRIGS vont permettre le DÉCLENCHEMENT d'une série de mesures sur L'ENSEMBLE des sondes retenues au paramétrage, relativement à l'état ou au temps sur une ou plusieurs sondes dites "pilotes".
5 TRIGS au maximum vont permettre des combinaisons complexes et sans aucun ordre pré-établi. Les TRIGS sont exploités séquentiellement, mais n'affectent aucunement les résultats de mesures dans le temps.
Un TRIG pourra s'appliquer à une entrée ANA ou LOG avec différentes subtilités.
Pour une entrée ANA, un TRIG pourra se réaliser sur un DELTA de valeur (écart) en multiples de 1/1024 jusqu'à 999 maxi. Pour imager, une température de chaudière entre 65 et 80° serait considérée comme normale. Donc une valeur centrale de 72.5 °C avec + ou – 7.5 °C serait correcte.
Alors nous pouvons imager en disant qu'un DELTA de 8° devrait être enregistré (valeur absolue). Tout dépassement reprendra alors comme valeur centrale cette nouvelle valeur. Ainsi si c'était 8°C au dessus, la nouvelle température centrale retenue sera cette fois de 80.5°C avec le même DELTA.
Cette méthode est économe en mesures et ne retient que les points significatifs.
(On notera que l'exemple est mal choisi et que ce cas est beaucoup mieux traité par les seuils).
Pour une entrée LOG, ce principe se simplifie à tout changement d'état (1 à 0 ou 0 à 1).
La deuxième possibilité est de travailler en échantillonnage du temps, avec un écart de temps constant entre chaque mesure.
Cet écart de temps maximum est de 99 jours. Le minimum au temps d'un scan est de 1 seconde, cependant, cet écart indiqué à zéro obligera le datalogger à balayer en permanence à une période de l'ordre de 200 ms, voire moins suivant les entrées utilisées et les vitesses de transmission. C'est alors une surveillance à vitesse maxi.
On notera que l'ensemble des entrées logiques est toujours lu. (Ce ne sera pas le cas des entrées analogiques qui peuvent être actives ou non). (Comme il y a plusieurs PORTS concernés, quelques centaines de nano secondes peuvent séparer ces valeurs).
Les TRIGS et la méthode des DELTAS, sont, je pense, une réelle innovation qui permet de ne pas surcharger de données inutiles car constantes (ou presque) et de créer des courbes en escaliers.
Les TRIGS sont intégralement paramétrables par le clavier, de même que le nombre et la position des entrées ANA utilisées.
L'ordre est indifférent, et il peut y avoir plusieurs TRIGS différents en valeur et nature sur une même entrée ou plusieurs, de même que des sauts de N° de TRIG peuvent exister.
Pour une représentation satisfaisante des phénomènes, je pense utile de réaliser des associations de DELTAS de valeurs avec des mesures à temps fixe moyennement éloignées, ce qui permet de garder une image à la fois moyenne et à la fois très précise des évènements.
Un dernière possibilité consiste à surveiller des SEUILS maxi ou des minis de valeurs.
Dans cette optique tout franchissement d'un seuil entrainera un enregistrement et un BIP.
Pour le seuil inférieur et sur la sonde ANA 4 seulement, un BIP permanent attirera l'attention (batterie faible)
Cette méthode permet de constater des dépassements ponctuels rapides qui peuvent être des parasites le plus souvent.
7 Les liaisons radio
Ces liaisons sont réalisées à partir de petits modules hybrides Telecontrolli à 433.92 MHz. La bande passante est limitée suivant les modules entre 2 et 4 KHz. Aussi les liaisons radio seront plus certainement réalisées à 1200 bps ?. (Voir ci-après).
Malheureusement mon revendeur habituel n'a plus ces modules mais d'autres existent (VELLEMAN) mais je ne les ai pas testé.
La partie émission est réalisée par un module miniature type RT6 avec antenne à connecter. Ce module émetteur sera alimenté en 8.75 V pour les nécessités de portée. (Alimentation de 2 à 14 V) Il est installé sur la base de mesures (BDM).
L'antenne sera constituée d'un petit fil rigide de longueur 17 cm environ. (à ajuster pour une portée maximumm).
On notera une partie réception sur la BDM, qui n'est pas utilisée à ce jour, mais qui pourrait l'être par la suite…(elle peut ne pas être installée sans affecter le programme existant)
La partie réception sera réalisée par un module RR3-433 de même fréquence et installé sur la base de Stockage (BDS). Son alimentation est nécessairement en 5 Volts. Selon la notice, la bande passante est ici de seulement 2 KHZ. Dans la solution de base il sera choisi une vitesse de transmission de 1200 bps compatible émission/réception (à voir par la suite).
Comme la vitesse est réellement exclusive des deux bases, il sera peut être possible d'utiliser une vitesse plus élevée non standard utilisant la totalité de la bande passante ? Cela fera l'objet d'essais ultérieurs.
Pourquoi un récepteur sur la BDM ? Ce récepteur pourrait s'assurer que juste avant l'émission, il n'y a pas d'autre émission (Projet de sonde radio…) ou de brouillage intempestif. Pour cela il aurait été très utile de disposer d'un signal de détection de porteuse, ce qui n'est pas le cas...
Mais ce récepteur est aussi et surtout prévu pour une future réception de sonde radio, éventuellement comme organe de paramétrage pour ceux qui ne voudraient pas d'un clavier...(mais il faudra introduire les fonctions de réception, et de préférence en interrupt, mais il serait alors plus simple et pratique d'introduire tout le paramétrage depuis le PC.
Les essais du récepteur radio avec mise sous tension presque instantanée (quelques millisecondes) ne se sont pas révélés satisfaisants, et j'ai dû monter jusqu'à 325 ms de délai entre la mise sous tension et l'obtention d'une réception à priori correcte (non vérifiée en termes de datas mais seulement de qualité du signal seul).
Ceci pose un double problème d'allonger le temps du scan et d'allonger le temps de mise sous tension.
Cependant sur un scan à 15 ou 60 ms, on ne saurait admettre un temps de mise sous tension de 325 ms !
Il serait donc quasi obligatoire de laisser la réception en permanence sous tension...?.
Une consommation de 3 mA permanente serait la rançon de ce manque de dynamisme du récepteur, aussi, et pour l'instant, j'ai abandonné la réception sur la BDM, ce qui ne me gêne pas vraiment dans l'immédiat.
La partie émission se contente d'un délai de stabilisation de 10 ms, ce qui reste tout à fait acceptable. En effet l'émission d'une porteuse ne sera pas permanente, mais débordera légèrement avant et après l'envoi des données. Les éventuels ajustements ne pourront être réalisés qu'avec l'utilisation de la BDS. Ceci a été vérifié si j'ai bonne mémoire avec le récepteur alimenté en permanence.
8 Sondes
Un datalogger sans sondes analogiques ne serait rien, aussi, j'ai débuté avec une sonde de température "maison", équipée d'un LM324 et d'un LM35.
J'ai d'abord pensé à commander son alimentation par une commande logique séparée de l'alimentation. Après réflexion, il semble qu'il eut été tout aussi intéressant de commander DIRECTEMENT la "puissance" ce qui est possible sans trop casser le schéma de principe de la BDM.
J'ai donc modifié ainsi, mais cela a nécessité un transistor de plus par sonde ANA, sur la BDM, ce qui n'était pas vraiment prévu...!
Cette sonde à base de LM35 et LM324 était limitée en excursion de température, mais restait un élément simple qui variait bien avec la température, jusqu'à ce que je m'apercoive que l'offset n'était pas celui que je pensais et qu'il évoluait aussi avec la température....
Cette sonde que je ne diffuse pas n'était pas bonne.
8.1 Sondes analogiques (tempéra
ture)
Elles sont délicates à définir, car les choix sont très variables suivant l'emploi que l'on veut en faire. Aussi il n'y a pas une, mais plusieurs solutions que chacun adoptera en fonction de ses exigences. Voici quelques éléments pour choisir :
Choisir des thermistances CTN dont chacune doit faire l'objet d'un étalonnage spécifique est toujours gênant.
En effet en cas de casse de sonde, il faut entrer dans une procédure d'étalonnage toujours délicate pour obtenir une bonne précision. Mais une question se pose tout de même, car lorsque l'on fait de la mesure, il y a toujours un étalonnage préalable !? Alors ? C'est une solution très simple et peu coûteuse qui reporte les calculs sur le tableur.
En effet, il a été possible d'établir des relations mathématiques pas trop compliquées en utilisant la fonction de valeur cible d'EXCEL. Ci-contre on peut voir 4 courbes de CTN, les deux premières bleues et magenta sont en direct alors que les jaunes et cyan sont en // avec une résistance de 10K. La formule indiquée s'applique aux CTN seules. La formule pour les courbes avec 10K en // répond aux groupement de résistances (le produit sur la somme).
La courbe Magenta représente le calcul suivant la formule indiquée, et la courbe bleue a été relevée au réel. On peut vérifier la bonne proximité de ces courbes et donc, la facilité pour faire les calculs sur EXCEL lors du rapatriement des données.
Les autres courbes sont avec un résistance de 10 K en //. Le calcul se réalise sur la base de la même formule modifié par le calcul des résistances en //.
Choisir une diode comme capteur est très intéressant pour la linéarité et la simplicité du capteur lui-même, mais il faut à ce stade prendre des valeurs de tensions d'alimentation plus élevées que prévu (référence 7.1 volt sur LM723 par exemple) et il faut aussi ÉTALONNER chaque diode, ce qui est également gênant.
Les références de tension plus faibles disponibles au niveau amateur sont limitées et seuls le LM317 et le LM385-1.2 peuvent répondre (1.2 V). Il faut ajouter aussi le problème des tensions d'alimentation des amplificateurs opérationnels pour ne pas tomber en saturation notamment vers le Zéro.
Peut-être faut-il aller vers des alimentations négatives des amplis OP ? ICL7660 par exemple, NE555 ? A voir.
Je ne dis pas cependant mon dernier mot sur ce sujet, car j'ai l'expérience de ma vieille régulation solaire qui fonctionne toujours après plus de 24 ans...avec diode et amplificateur d'instrumentation. Il suffirait de l'adapter avec de nouveaux amplis OP et avec de nouvelles références de tension...(Je vais y travailler avant de passer à la BDS). De plus ce système avait les diodes déportées à plus de 15 mètres sans problèmes dus à la distance.
D'une façon générale, ces sondes pour une question pratique ne devront pas comporter de batteries ni avoir une consommation excessive et devraient pouvoir être alimentées par la BDM et sa batterie. Une campagne de mesure nécessite une certaine fiabilité et il y a toujours un grain de sable qui met tout par terre.
Alors des batteries sur chaque sonde, n'est pas acceptable en termes de gestion de la charge des éléments, pas plus que de coût qui devient vite important. C'est la raison pour laquelle les sondes seront principalement alimentées par la BDM et rarement localement.
Ces sondes doivent rester simples pour l'instant et ne pas contenir de microcontrôleur PIC. Il est en effet actuellement exclu pour les problèmes de collision radio, de transmettre ces données en numérique à la base de mesures (Pour l'instant).
Ces sondes fourniront un signal de tension 0 – 5 V standard permettant une conversion AD facile et commune à d'autres valeurs sur la base de mesures.
Pour la température, l'absence de stockage possible de tables de conversion dans la sonde impliquerait l'abandon des thermistances, bien que très intéressantes car simples à mettre en œuvre pour un signal 0-5V. Mais, on remarquera toutes fois qu'il est tout à fait possible de faire les mesures de tension et d'assurer par le tableur la mise en forme exacte des mesures suivant une loi qui a déjà été vérifiée (voir ci-dessus formule dans le graphique)
De toutes façons il faut mettre en // une résistance pour linéariser un peu mieux mais on perd ainsi en sensibilité. On a aussi une précision variable en fonction de la zone de température et c'est un peu gênant, mais peut suffire si l'on ne s'attache pas à la valeur absolue, mais seulement aux variations.
On prendra garde dans ce cas à l'échauffement interne des CTN et on utilisera nécessairement la commande de tension des sondes pour limiter le temps de MST et ne pas fausser ainsi les mesures par l'auto échauffement.
Je ne prendrai jamais la résolution d'éxécuter la formule indiquée sur le graphique avec un PIC, car c'est un travail beaucoup trop lourd en assembleur, et de plus je me suis aperçu que j'ai bien oublié tout ces calculs avec exponentielles... (kt/e !)
Au fait comment fonctionnent les petits thermomètres numériques du commerce, avec une seule pile de 1.5 V ? Quel miracle ! Non pas vraiment, car au niveau consommation, ces appareils ne font réellement de mesures que durant une fraction de seconde toutes les 10 ou 15 secondes. Ils ont donc un gain de 100 environ dans la durée des piles. (Cette façon de procéder est la seule qui permet la longévité des piles).
Pour les autres paramètres je n'ai pas été "fouiller" plus loin, mais ce sont très certainement des µ contrôleurs avec tables de conversion ou linéarisation par résistance en parallèle.
(Le fait d'alimenter durant un temps très court évite de plus l'échauffement de la thermistance)
Pour en revenir au choix intial de mesure de températures, il s'agissait donc du LM35 et du choix d'une référence de tension de faible valeur fournie par un régulateur LM317LZ fournissant 100 mA au maximum mais nécessitant un courant minimum de 5 mA. (Ce circuit permet d'alimenter directement la chaîne d'amplification).
Le LM35 assure une parfaite linéarité des valeurs ainsi qu'une précision absolue constante sur toutes les plages de mesures et sans AUCUN ÉTALONNAGE.
D'autres types de sondes analogiques pourront être connectées (pression, débits, etc…)
On remarquera la commande d'alimentation de l'électronique de ces sondes pour économiser l'énergie des batteries, mais aussi réduire l'échauffement intrinsèque des sondes (qui reste faible)
Une étude de plusieurs modèles est en cours, et je pense que la commande logique de mise sous tension est superflue, car cela "consomme un fil de plus" et n'apporte rien.
J'ai donc supprimé la commande et donné directement la tension d'alimentation, ce qui simplifie sans inconvénients à priori. (courbe de MST). J'ai découvert d'autres problèmes sur ces sondes lors de la mise au point réelle avec la BDM, alors je vais travailler sur :
Une deuxième version de sonde de température en étude et réalisation avec LM35
Une troisième sur la base d'un petit amplificateur d'instrumentation avec capteur diode.
Au cours de ces premiers essais peu encourageants, j'ai pu apprécier le problème des tensions de saturation qui affectent tout autant les valeurs basses que les valeurs élevées, et j'ai pu le vérifier par la saturation vers 736/1024 du convertisseur du PIC sur les sondes ANA.
Pour la valeur supérieure, j'avais simplement affecté le 8.75V à l'alimentation du LM324, et cela a résolu parfaitement le problème de limite supérieure. Le gain ne devrait pas être beaucoup affecté par ce changement, et on atteint cette fois les 1023.
Le problème de limite inférieure reste quant-à lui toujours présent ! mais j'ai bon espoir...
Rendez vous ultérieurement pour des articles annexes consacrés à cette mesure de température par différentes méthodes.
Concernant ces sondes de Température, vous pouvez aussi consulter le très bon site de kudelsko. J'ai cependant eu un problème sur le réglage et la stabilité de l'offset et je ne suis pas allé plus loin dans les recherches, j'ai dû donner ma langue au chat !
(Il n'est pas exclu d'être obligé d'affecter des temps de réglage pour chaque type de sonde. Cela fera l'objet de modifications ultérieures éventuelles).
8.2 Sondes Logiques
Naturellement les niveaux des tensions logiques seront 0-5V et compatibles directement avec les entrées logiques CMOS d'un PIC. Le plus souvent il s'agira d'entrées type trigger de Schmitt.
Des condensateurs, tant au départ qu'à l'arrivée permettront de ne pas prendre au vol des parasites. Ces sondes ne sont donc que des liaisons sur des contacts secs ou ne véhiculant aucune tension.
On notera des modifications effectuées en cours de MAP qui ont consisté à fixer les potentiels des entrées "pouvant être en l'air". Je pense en particulier à toutes les entrées LOG mais aussi aux entrées clavier (Une fois paramétré, le datalogger peut être déséquipé du clavier toujours encombrant). Ce dernier point était très gênant car des interrupts parasites se produisaient.
Il faut donc fixer les potentiels par 3.3 Mohms c'est suffisan
t (pour limiter les consommations).
Ces entrées logiques seront également utilisées par des sondes plus complexes comme la mesure de la présence
de TENSION secteur sur un appareil en évaluation (moteur de pompe à chaleur par exemple). Un opto coupleur permet de s'affranchir de tout parasite et de toute tension rebouclée. Cet opto coupleur "maison" est constitué d'une LED IR et d'un photo transistor IR placés en regard dans un petite colonnette nylon.
Ce photo transistor attaque directement une entrée ANA. (voir photo 
de cette sonde et schéma). Une gaine thermo maintient l'ensemble diode et photo transistor en place dans la colonnette. (flèches rouges de la photo)
Des sondes de COURANT Secteur sont également possibles, et permettront soit la simple détection d'un courant, ou sa mesure réelle en 0-5V avec cette fois raccordement sur une entrée analogique. (ou simplement logique)
Un prototype sur base d'un transformateur en simple C est en cours de réalisation. Il est basé sur le principe des pinces ampèremétriques. Il faudra seulement faire un peu de mécanique pour fermer le circuit simplement et bien l'isoler. (voir l'article "pince ampèremétrique")
A chacun d'inventer et de faire attention car le secteur 220V est toujours proche dans ce genre d'applications et l'accident peut aussi être très proche.
9 Les calculs analogiques
Les sondes analogiques fournissent après conversion AD des valeurs sur 10 bits et il faudra les convertir approximativement en des valeurs sur 2 digits seulement pour pouvoir être toutes affichées sur le display de la BDM. (uniquement sur le display !)
Il est impératif de garder la précision pour l'envoi vers le PC, car la BDS recevra toujours les valeurs binaires "non modifiées".
J'ai trouvé des algorithmes de calcul sur 24 et 32 bits sur le très bon site de "Doumai" :
Dans les autres sites il y a toujours l'incontournable BIGONOFF qui avait aussi les calculs en 24 bits que je cherchais.
ATTENTION cependant aux soustractions qui nécessitent de rechercher préalablement l'élément le plus grand…!
(Voir la séquence de comparaison sur l'article quelques truc MPLAB)
Les sondes analogiques de température donneront une étendue de mesures (EM) sur trois chiffres aux offsets près. Il y a donc un rapport de 10 environ. Vu que les valeurs affichées au display seront seulement sur 2 digits, on simplifiera en faisant une vraie division par 10 avec reste perdu. On obtiendra ainsi la température depuis 0 à 102 (/10).
Le signe au display ne sera pas traité puisque le départ est sur une valeur 0 qui sera affectée à une température. Je pense qu'au niveau des températures il n'y aura pas de confusion possible pour ce qui dépassera 99 car un ":" apparaîtra alors au display en guise des centaines affichées (c'est le prix de la simplicité et de la place disponible en affichage pour les valeurs 100, 101 et 102 seulement !).
Notez que cela ne concerne que L'AFFICHAGE SEUL, puisque la BDS et le PC recevront bien entendu, la valeur exacte issue du convertisseur AD.
Pour confirmation de la sonde traitée, j'avais ajouté le numéro de sonde en binaire sur l'octet de poids fort (cadré à gauche), mais cela n'est plus nécessaire, car éliminé par la position exacte des sondes ANA utilisées et leur ordre de SCAN.
10 Description Base De Stockage
C'est un maillon moins important que la BDM car au pire la BDM peut fonctionner seule en connexion directe avec le PC. C'est d'ailleurs le cas, puisque j'arrive seulement à la fin de Mise au point de la BDM.
Cependant, cette base de stockage BDS représente quelques difficultés techniques.
Dans ces difficultés, il faut recevoir en série à petite vitesse les données issues du petit récepteur radio. Le timing bit doit être identique à celui de l'émission (BDM) pour éviter toute erreur de réception.
Parallèlement, la transmission vers le PC se fera à grande vitesse (Liaison filaire RS232) et avec la meilleure précision de fréquence possible.
Les fréquences sont différentes et initialement j'avais envisagé 2 PIC, mais le transfert de PIC à PIC prend trop de temps par quartet.
Alors la BDS devrait être seulement équipée d'un PIC 16F628-20 qui devrait normalement avoir la capacité de traiter cette conversion binaire ASCII et de l'envoyer à 115200 bps vers le PC.
L'envoi vers le PC se fera pendant le délai de MST de l'alimentation de l'emetteur de la BDM. 65 octets (maximum) seront à envoyer au PC.
J'avais envisagé des doubles buffers, mais vu les temps respectifs, et ayant pu transmettre à 115200, de telles complications sont inutiles, mais de plus impossibles puisque l'émission et la réception seront nécessairement en half duplex.
Deux possibilités s'offrent pour contrôler une suite de caractères peu fréquente, ce qui est le cas puisque chaque ligne se termine par 0D (RETURN) et commence par 16 02 02 (SYN et STX et ADR). Ceci n'est cependant pas obligatoirement suffisant et la longueur d'une trame devrait pouvoir être contrôlée pour s'assurer d'un transfert correct. Ce sera également le cas.
Un octet transmis en début de mesures avec code adresse (ADR) 01 (USED_ANA) détermine le nombre et la position des entrées ANA, TMR1 (mesure de nombre d'impulsions) et RB0 (mesure de temps)
Ce seul octet de configuration permet donc de connaître avec les quelques octets de début et de fin de trame, les opérations à effectuer pour décoder en ASCII les valeurs binaires transmises.
Une trame aura toujours la structure suivante:
Les trames peuvent être repérées par les caractères de début et fin de trame et par la longueur calculée.
Pendant le remplissage d'un buffer de la BDS (à petite vitesse), le PIC de la BDS devrait avoir le temps de convertir les données par la surveillance du nombre de caractères mis à jour dans la séquence interrupt.
On comprend dès cet instant que la puissance de calcul devra être élevée, pour traiter à la volée la conversion de groupements d'octets en nombres de 2 à 8 chiffres, au fur et à mesure de la réception. (dans les bases 10, 16 et 2).
La vitesse de réception sera parfaitement en accord avec la partie BDM, puisque chaque quartz sera à 20 MHZ. On choisira le BRGH=0 pour la partie réception et BRGH=1 pour 115200 bps (ce dernier est impératif pour la compatibilité avec un PC).
Tout ce paragraphe de la BDS reste cependant délicat à cause des timings à respecter pour pouvoir "suivre" la BDM sans perdre d'informations.
A 115200 bps, chaque caractère dure 86 µS et cela reste peu.
Ainsi pour une trame ASCII de 65 caractères, la transmission durerait tout de même 5.6 ms.
Rien n'est perdu d'autant que pour toute lecture ANA, un délai de MST de 10 ms est appliqué et qu'il est déjà supérieur au temps de transfert d'un ensemble complet...
Cette BDS fera l'objet d'un article séparé, puisqu'elle n'est pas encore développée.
11 Logiciel
11.1 Le programme principal PIC
Ce programme occupe 4 K de mémoire programme pour plus de 6300 lignes de source. De nombreuses interrupts sont utilisées et concourent à la difficulté de compréhension.
Ce programme est divisé en deux grandes parties qui sont le paramétrage comprenant la mise à l'heure et la saisie de tous les paramètres d'exploitation.
La deuxième partie est constituée de la grande boucle de surveillance des entrées.
Il serait restrictif de présenter ces deux grandes parties sans parler des sous programmes (call) qui sont appelés par chacune des parties. Ceux-ci sont nombreux et variés et répartis dans les deux pages utilisées suivant leur utilité : paramétrage, programme ou séquences communes (page 3 et page 0 respectivement).
De nombreuses séquences sont parfois laissées telles qu'elles pour limiter la profondeur de descente dans le stack, car je n'ai pas réellement compté.
J'ai cependant commis une grave erreur d'inattention (réparée bien entendu), mais qui a été de mettre un sous-programme ayant d'autres appels de sous programmes dans une réponse à une interruption (c'était naturellement beaucoup plus facile !) mais ça ne pardonne pas !
Il serait aussi bien trop long d'expliquer tout en détails, tant les cas sont nombreux et variés. Je crois qu'il faut seulement retenir les grands principes de stockage minimaliste retenus.
Ce programme sera disponible sur demande dans la version du jour et en .HEX seulement, car je me suis aperçu que de grands groupes internationaux scrutent largement ces articles techniques pour en tirer des idées et économiser du personnel. Je ne veux pas cautionner ces façons de faire au détriment de l'emploi en général (Ceci explique cela !)
De façon générale toute la partie paramétrage est traitée en page 3 de la mémoire programme. Tous les sous-programmes qui sont communs sont en page 0 avec la boucle principale de surveillance.
Concernant les Banques des variables, un maximum est en bank0, mais il se trouve en banque 1 le buffer TX et la table des TRIGS ainsi quelques autres variables. Dans la partie commune sont logées des sauvegardes de registres et les données de date et heures.
Certaines adresses de la zone commune des banques non utilisées après l'initialisation sont reconverties en ADRESSES LOCALES, mais ce principe ne me satisfait pas vraiment car l'adresse n'est pas flaguée "not used" quand elle est libérée et j'ai fait quelques erreurs d'utilisation sur ce principe qui n'est finalement qu'une simple équivalence de nom non sécurisée.
Ce programme principal est lourd et difficile de compréhension, vu le nombre d'entrées sorties associés aux différents paramètres. Inutile de dire je pense que cette mise au point a été longue et difficile. Certains blocages ont persisté plusieurs jours, et toute modification un peu importante rendait la reprise souvent difficile et à certains moments des décisions de revenir en arrière se sont réellement posées avec acuité…
Ceci indique que je ne suis encore qu'un débutant en PIC et que je n'ai pas encore atteint toute la rigueur nécessaire pour ne pas me "prendre les pieds dans le tapis"…
11.2 La partie interruptions
Il est évident que la partie interruption doit permettre de tenir à jour l'horloge temps réel et qu'une réponse à toute interrupt doit être obligatoirement assez courte.
Pour la partie clavier qui pose le plus de problèmes tant le sujet n'est pas si simple que cela. Il a été traité avec clock et datas et seulement clock en Interrupt, le signal data étant quant à lui parfaitement inutile d'être traité de cette façon.
J'ai donc traité en interruption la partie clock clavier seulement au niveau récupération de SCAN code CLAVIER (ne pas confondre avec les SCAN codes du programme principal), celui-ci sera exploité au niveau programme, car les calculs restent un peu pénibles à gérer. (Je n'ai pas trouvé, mais je n'ai peut-être pas suffisamment cherché de routines en assembleur pour traiter ce sujet).
Je rappelle que dans le cas du projet, le temps de calcul pour la réponse à une interruption doit impérativement être inférieur à 5 ms qui représente la résolution de l'horloge temps réel.
Les interruptions décodées sont donc
l'horloge Timer 0 T0IF
le timer 1 TMR1IF
La transmission série RS232 TXIF
Le Port B bit 4 à 7 incluant le clavier RBIF
Le Port B bit RB0 RBIF
11.3 Un faux problème rencontré sur PIC16F877A
C'est une partie très importante, et je suis tombé sur un problème pourtant décrit dans la documentation… Je pensais avoir assez bien compris la sauvegarde des registres, mais…
Si vous travaillez avec les 4 BANK, vous ne savez donc pas dans quelle BANK vous êtes lorsqu'il y a Interrupt.
Je pensais à tort qu'avec la page 0 imposée, la BANK serait également la BANK 0. Grave erreur ! J'ai donc cherché pourquoi l'adresse +0x80 était modifiée par la sauvegarde de W.
J'ai relu BIGONOFF sans autre information, puis en cherchant un peu j'ai pensé à des "btfss" associés à des bsf ou bcf, mais à ce moment on ne sait pas encore dans quelle PAGE on se trouve…
Dernière solution libérer l'emplacement +0x80 correspondant. (Cela me paraissait assez peu orthodoxe -ou catholique- pour ne blesser personne) mais c'est pourtant la seule solution viable.
En effet, j'ai relu la documentation officielle (Chapitre 12.11 page 130) et là soulagement !
En effet pour les PIC à deux BANK au moins, il faut une double adresse pour permettre le stockage là où la BANK en cours se trouvera.
Cela concerne seulement la sauvegarde de W à priori.
Le constructeur rappelle à juste titre que les PIC 16F877A à 4 BANK ont une zone commune aux 4 banques…C'est la bonne solution, et c'est écrit par le constructeur. Personnellement, j'ai stocké W et STATUS en sauvegarde dans cette zone, mais je préfère garder le reste de cette zone commune pour mes données les plus fréquentes et éviter ainsi le "bankage" toujours pénible.
Voilà donc un écueil qui servira à ceux qui ne se sont pas encore fait piégés, car je ne dois pas être le premier à tomber dans le panneau ! Et cela fait des programmes qui marchent dans 99% de cas, mais pas 100% ! (Un peu comme ma voiture qui condamne à tort le coffre arrière sans raison apparente)
11.4 LE CLAVIER
Préambule :
J'ai passé beaucoup de temps sur cette connexion, et j'en ai fait un article séparé. En effet ce clavier PC AT n'est qu'une petite partie du datalogger. L'article aurait été trop long à cause de ce sujet nécessairement développé, vu les ennuis rencontrés.
Voir l'article sur le clavier.
12 La RS232 (et radio)
En fait, c'est la RS232 qui attaque directement la partie émission radio et cette dernière a une entrée data et c'est tout (comme dirait quelqu'un !)
Cette partie émission RS232 / Radio a été traitée totalement en interrupt et cela facilite largement l'emploi, sans aucun souci maintenant.
Une dernière séquence de clôture des données d'une trame (Fintram) calcule la longueur de la trame et ajoute un 0x0D (return). L'adresse et la longueur de la trame sont passés en paramètres à la séquence interruptible. Il ne reste plus qu'à tester le TRMT au niveau du programme principal. (Le TRMT est bloqué en permanence durant les transferts, car le registre n'est jamais vide).
La radio reçoit directement ce signal !
L'alimentation de la radio, bien que peu gourmande est commutée, et la tension qui peut aller de 2.7 à 14 volts a été raccordée au 8.75V, pour espérer avoir assez de puissance tout de même, et autant dépenser cela en UHF pour la portée que dans le régulateur de tension....
13 Quelques points spécifiques
13.1 Voyants
Ainsi que cela a été vu, le principe de charge d'un condensateur pour les voyants a été éliminé (voir l'article) car la fréquence était trop rapide pour assurer un allumage suffisant.
Dans ces conditions un interrupteur du plus simple modèle rendra le service de coupure des voyants permettant ainsi des économies d'énergie, tant sur la BDM que sur les sondes.
Ce même principe avait aussi été retenu sur la première sonde de température.
13.2 Économies d'énergie
Dans les économies d'énergie, il faut citer la coupure de l'émetteur durant 2 à 50 ms par cycle, ce qui est peu, mais tout de même !
Il faut rappeler le paragraphe ci-dessus également, et dire un mot sur le récepteur radio qui sera mis hors tension par le programme puisque non utilisé à ce jour.
Dans ce paragraphe il faut aussi citer les sondes ANA non utilisées qui ne seront jamais alimentées et l'on gagnera de plus en temps de traitement.
13.3 Résistances de rappel
Les entrées CMOS sont sensibles à tout champ électrique même très faible comme une simple main par exemple. Aussi si les entrées ont été quelque peu protégées des impulsions, sur le circuit imprimé, elles n'avaient pas été fixées en potentiel. Aussi il a fallu mettre des résistances de rappel au +5V pour pallier ce problème.
Ceci affecte particulièrement les entrées LOG, TMR1 et RB0, mais surtout le clavier qui ne pouvait pas être retiré sous tension sans planter à cause des interrupts.
Ces résistances ont été placées à l'arrière du pupitre en dehors du CI sur les mini bananes. Des 3.3M Ohms rendent le service sans réelle consommation.
A la lumière de ces éléments sensibles, j'ai protégé les coffrets par du papier d'aluminium collé, bien que je n'ai pas eu d'autres problèmes de parasites ou de sensibilité.
Je remarque aussi la grande insensibilité au bruit d'un micro contrôleur en regard des anciens montages non intégrés où tout parasite pouvait faire planter...
13.4 Alimentations sondes
Les sondes étaient initialement alimentées en 8.75 V et une commande logique 5V validait l'alim locale des sondes pour fournir ou non la "puissance" régulée à 5V.
Ceci était assez gênant car le principe obligeait à un fil de plus sans réelle utilité puisqu'il suffisait alors d'alimenter directement en 8.75 V.
Ceci avait été fait ainsi pour des questions de rapidité d'établissement des tensions. Mais après réfexion, j'ai préféré la solution de commande directe des alimentations depuis la BDM. Ceci a nécessité d'ajouter un transistor de plus (pas trop facile sur un circuit déjà bien chargé !)
Le problème de la rapidité d'établissement de la tension a
donc été réalisé sur les sondes elles-mêmes. Pour cela, un très petit condensateur d'entrée 33 nF évite un temps de charge trop long, mais aussi avec un condensateur après régulation, lui-aussi très petit de 1µF.
On peut voir sur la tension analogique (tension de sortie de l'ampli OP de l'ancienne sonde de T°) que cela est largement suffisant puisque le temps de stabilisation de l'alim est fixé à 10 ms et que la tension (de sortie) se maintient durant envrion 20 ms (pour température ambiante).
Le temps de montée de la tension d'alimentation jusqu'à sa valeur nominale est réellement de 1.5 ms environ. La sécurité est donc assurée.
14 Conclusions
Ce datalogger fonctionne bien à priori, mais cela a été un travail de plus de 6 mois presque à plein temps. Il va encore évoluer (passage en ASCII des paramètres des sondes et des TRIG, pour plus de facilité de dépouillement).
Je ne doute pas qu'il subsiste encore quelque bug caché, car sur 4K de programme, ce serait bien le diable qu'il ne reste pas un petit truc...
Il est évident aussi que j'ai un peu dévié (temporairement j'espère) du projet initial, puisque la partie transmission radio à distance n'est pas encore réalisée, et qu'elle n'est pas spécialement simple contrairement à ce que j'aurais pu croire, car les problèmes de timings sont pointus, mais je devrais en venir à bout, durant l'hiver prochain.
En ce qui concerne les sondes analogiques de température, je vais commencer par réaliser deux prototypes différents quand j'aurai les composants.
Ensuite j'aimerais bien avoir quelque sonde de pression.
Enfin et pour poursuivre dans cette voie, une sonde ampèremétrique a été réalisée plus vite que je ne pensais, sur la base d'un petit transformateur en C.
Cette sonde ampèremétrique ANAlogique peut aussi servir de sonde LOGique, pour indiquer un courant alternatif 50 Hz lorsqu'il n'est pas possible de prendre facilement la tension.
Bonne acquisition à toutes et tous.
____ ( retour début d'article ) ____
____ ( retour accueil bricolsec) ____
____ ( retour accueil lokistagnepas) ____
/http%3A%2F%2Fstorage.canalblog.com%2F78%2F10%2F338014%2F116239131_o.jpg)
/http%3A%2F%2Fstorage.canalblog.com%2F55%2F24%2F338014%2F105236621_o.jpg)
/http%3A%2F%2Fstorage.canalblog.com%2F29%2F22%2F338014%2F74002382_o.jpg)
/http%3A%2F%2Fstorage.canalblog.com%2F36%2F08%2F338014%2F63028714_o.jpg)
/https%3A%2F%2Fprofilepics.canalblog.com%2Fprofilepics%2F2%2F8%2F289215.jpg)