Elektor Lab Notes 22 : Surveillance d'accumulateurs, capteurs de voitures, et d'autres encore
sur
Saad Imtiaz (Ingénieur sénior, Elektor)
Notes de laboratoire : Système de surveillance d’accumulateurs et tableau de bord pour les capteurs d'une voiture
Système de surveillance des batteries de secours au plomb-acide (UPS : Uninterruptible Power Supply, = équipement permettant de garantir une continuité de l’alimentation électrique)
Le projet d’une surveillance des accumulateurs plomb-acide connectés à mon alimentation de secours est presque terminé, et les derniers détails seront présentés dans une prochaine édition du magazine Elektor. En résumé, le système surveille les paramètres critiques tels que le courant et la tension, fournissant des informations en temps réel sur les performances de l’accumulateur. Cependant, le calcul de l'état de santé (en anglais SOH) des accumulateurs est une fonction primordiale, encore en cours de développement. Cette fonction est cruciale pour tout équipement d'alimentation de secours, car elle permet de prédire la durée de vie utile restante des accumulateurs, et de garantir des performances optimales.
L'ajout de la fonction SOH impliquera l'analyse des cycles de charge/décharge et de l'évolution des températures au fil du temps, afin de fournir une vue globale de l'état des accumulateurs. Ces informations sont précieuses pour la maintenance préventive, permettant une meilleure gestion du cycle de vie des accumulateurs et ainsi d'éviter une coupure soudaine de l'alimentation. En intégrant ces critères, ce système garantira la fiabilité et l'efficacité de vos accumulateurs tout au long de leur durée de vie.
Projet d'un tableau de bord pour les capteurs d'une voiture
Dans un autre domaine, j'ai travaillé sur un tableau de bord personnalisé pour les capteurs d'une voiture. L'idée initiale était d'équiper mon Land Cruiser 2001 d'un écran moderne permettant un diagnostic en temps réel du véhicule. Je me suis toutefois heurté à un grand obstacle technique. Malgré des tests et des recherches approfondis, je n'ai pas réussi d'extraire les données des capteurs de ma voiture en raison de l’incompatibilité des protocoles. La plupart des véhicules du début des années 2000 utilisent des protocoles spécifiques aux fabricants et n'adhèrent pas strictement aux normes OBD2. Je n'ai donc pas été en mesure d'identifier ni de décoder le protocole pour en extraire les données significatives du Land Cruiser.
Cependant, le projet est toujours d'actualité, mais avec une nouvelle plateforme d'essai : il s'agit de ma Honda Civic 2007. Ce véhicule prend en charge la communication OBD2 via des protocoles tels que CAN-BUS, ce qui me permet d'obtenir une multitude de données en provenance des capteurs. Des paramètres tels que le débit de carburant, le kilométrage instantané, la température du liquide de refroidissement et le débit d'air ne sont pas seulement intéressants, ils sont aussi très utiles pour une analyse. Par exemple, en examinant la consommation de carburant tout au long d'un trajet, je peux calculer l'efficacité énergétique moyenne, en évaluant l'impact de mes habitudes de conduite sur les distances parcourues. «Alerte spoiler» : les données suggèrent que je devrais relâcher la pédale d'accélérateur, sauf si j'essaie d'établir un nouveau temps record pour me rendre à l'épicerie !
Le tableau de bord est doté d'un écran LCD moderne qui présente ces données de manière conviviale et élégante; ce qui en fait un complément amusant et utile pour les passionnés de voitures et les conducteurs soucieux de l'environnement.
Jean-François Simon (Engineer, Elektor)
Les amateurs d'analyseurs de spectre devront encore attendre. Mes tentatives de réparation du R3132 sont encore en cours. En attendant, dans le cadre d'un autre projet, je modifie un appareil en insérant un module avec microcontrôleur entre un bouton-poussoir et l'actuateur qu'il contrôle. Ceci me permettra de distinguer entre des pressions courtes ou longues. Pour simplifier le câblage et minimiser les modifications sur la réalisation originale, le module Arduino sera alimenté directement par le fil provenant du bouton-poussoir. Pour réagir aux pressions courtes, l'Arduino doit pouvoir démarrer rapidement. Voici ma configuration pour mesurer le temps de démarrage d'un clone du Pro Mini monté sur une plaque d'expérimentation. Une instruction du code envoie une impulsion de 100ms sur la broche 9, et j'utilise un oscilloscope pour mesurer le temps de démarrage. En jaune, vous pouvez voir l'alimentation 5V, et en bleu, l'impulsion sur la broche de sortie :
Voyez les résultats : il y a un retard de 1.45 seconde entre la mise sous tension et l’apparition de l'impulsion de sortie. J’étais convaincu que ce délai pouvait être amélioré. L'étape suivante consista donc à programmer le microcontrôleur sans démarrer le chargeur d'amorçage (bootloader). Cela implique de sélectionner "Sketch > Export Compiled Binary" dans l'IDE Arduino et d'utiliser un programmateur externe. J'utilise un AVRISPmkII (programmateur pour microcontrôleur). La version de l'IDE avec laquelle je travaille est supposée le prendre en charge, mais dans la pratique, j'ai rencontré une erreur (vraisemblablement un problème de pilote). Dans le passé, j'ai investi des heures à batailler avec AVRDUDE (programme pour télécharger et lire la mémoire intégrée des microcontrôleur Atmel's AVR)... Une meilleure solution aurait été Microchip Studio, mais je n'ai pas pu résister à l'envie de tester AVRDUDESS (interface graphique de AVRDUDE), qui a récemment profiter d’une mise à jour (septembre 2024, version 2.18) :
Étonnamment, tout a fonctionné du premier coup, et mon AVRISPmkII a été reconnu sans problème. J'ai sélectionné le fichier HEX sans le bootloader, et voilà ! Ci-dessous la nouvelle mesure du temps de démarrage :
L'Arduino démarre maintenant en 70 ms environ. Ce n'est pas si mal ! C'est beaucoup plus réactif. Mais attendez, à 16 MHz, cela représente tout de même plus d'un milliard d'instructions ! Que se passe-t-il ? Il est temps d'approfondir la fiche technique. Le tableau 8.4 de la page 27 fournit la réponse : il y a un délai de 65 ms pour assurer une alimentation stable et donner à l'oscillateur à quartz le temps de démarrer et de se stabiliser. Les fusibles par défaut du Pro Mini (0xFF, 0xDA, 0xFD) le confirment. En utilisant le Fuse Calculator, nous pouvons voir que nous sommes dans une situation correspondant à la dernière ligne du tableau, avec les bits CKSEL0, SUT0, et SUT1 à 1. Microchip inclut cette option avec raison. Si vous choisissez de supprimer le délai, suivez attentivement la documentation et effectuez des tests complets pour vous assurer que votre microcontrôleur se comporte normalement. Pour un démarrage plus rapide, CKSEL0 peut être mis à 1, SUT0 à 1, et SUT1 à 0, ce qui peut se faire avec AVRDUDESS en mettant la valeur des fusibles à 0xDF, 0xDB, 0xFD. Voici le résultat avec la nouvelle configuration :
Nous avons maintenant un démarrage rapide de l'Arduino (presque) comme l'éclair : 2.9 ms ! D'après la 6ème ligne du Tableau 8.4, le délai de démarrage comprend encore 16'000 cycles de l'oscillateur, soit 1 ms. Cela suggère que l'oscillateur à quartz intégré a mis environ 1.9 ms pour démarrer, ce qui correspond à l'indication de Murata "environ 2 ms". Amusez-vous bien avec vos Arduinos turbocompressés !
Brian Tristam Williams (rédacteur, Elektor)
J'ai commencé la nouvelle année avec quelques nouveaux jouets à essayer. Je suis en train de les classer et de faire une liste de ceux pour lesquels je vais d'abord faire des commentaires et/ou des vidéos.Vous avez l'embarras du choix, dans les commentaires, faites-moi savoir ce que vous désireriez voir en premier !
En 2025, l'un de mes objectifs est d'accroître le nombre de vidéos que je produis, mais cela implique de rationaliser le flux de travail et de me perfectionner avec les applications de montage vidéo. Le grand choix maintenant consiste à décider si je me perfectionne avec Adobe Premiere Pro, ou si je passe sur DaVinci Resolve (comme recommandé par Jens), puisque ces derniers temps, Adobe a obtenu des commentaires peu favorables à propos de la protection des données.
Discussion (0 commentaire(s))