En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies pour vous proposer des contenus et services adaptés. Mentions légales.

Arduino : Jauge FUEL

N.B. toutes les photos sont agrandissables...

fuel arduino2.jpg
 

Contextualisation...

Schnaps est un fifty de 12 tonnes, pour lequel le moteur est un élément important. A fortiori, connaître sa consommation et, surtout, le reste de Fuel est donc essentiel.

La jauge de Schnaps était en panne lors de l'achat.
Il s'agissait d'une simple jauge à levier avec un flotteur et un affichage sur cadran peu précis. Après avoir démonté, nettoyé et testé tout le mécanisme, j'ai malgré tout constaté que l'affichage sur le cadran restait irrégulier. Soit le levier était à nouveau bloqué (usure ?), soit ce levier touchait une des parois du réservoir, difficile d'avoir une certitude.

ancien cadran.jpg
L'ancien cadran, peu précis surtout avec une jauge aléatoire...

Comme déjà expliqué précédemment, j'avais pensé réaliser un montage ARDUINO assez compliqué, basé sur le compte-tours, pour estimer au mieux la consommation de fuel (à partir du GitHub de PauloSurArbutus).
Une estimation de consommation + une jauge imprécise devaient normalement me permettre de voir venir, d'autant que précédemment - avec son ancien propriétaire - ce Fisher 34 naviguait parfaitement avec sa jauge bloquée... (mais perso, cela ne me convient pas).

Ceci étant, je n'ai pas réussi à parfaitement estimer la consommation de carburant telle que je le pensais, à partir du compte-tours...
Et une estimation reste une estimation, j'ai donc décidé de procéder autrement.

Le principe retenu

  • Lecture du niveau de fuel par la jauge capacitive, affichage graphique du reste-fuel en volume et pourcentage sur 2 écrans TFT et LCD et sur le livre de bord d'OpenCPN.
  • Calcul de la durée moteur avec branchement sur borne W.
  • Affichage Pression, Température et RPM
  • Sauvegarde des données sur carte SD et en NMEA0183 sur le livre de bord d'OpenCPN

J'ai donc décidé d'acheter une jauge capacitive (sur le ouaibe, on trouve des tutos pour en construire, mais perso j'ai préféré assurer et avoir une jauge fiabilisée) qui soit étalonnée de 0V à 5V et alimentée en 12V.
Quand la jauge indique 0V, le réservoir est vide et quand elle indique 5V, il est plein. Cela permet d'étalonner de 0 à 100% la capacité du réservoir.

Avec un programme (sketch) écrit pour l'ARDUINO MEGA, il suffit ensuite de convertir ces impulsions en pourcentage pour finalement afficher sur un petit écran, le volume exact en pourcentage et en litres du réservoir de carburant...

jauge.jpg
La fameuse (et couteuse !) jauge ...

IMPORTANT :

J'ai remplacé cette jauge par une simple jauge résistive en fin février 2020 car cette jauge initiale (la capacitive) ne donnait plus d'indications fiables (ai-je inversé l'alimentation en démontant/remontant ou n'était-elle pas adaptée au fuel, que sais-je !?!).

Après démontage et tentative de "réparation", voilà ce qui reste de la jauge capacitive...

jauge_capacitiv.jpg

J'ai donc remplacé cette jauge capacitivé très précise par une jauge résistive, moins précise mais qui durera plus longtemps... Hope so !!
(Voir plus bas)


Le programme arduino ne change pas, seuls les branchements ont été modifiés ; voir en fin de page.

Simple à expliquer, plus difficile à mettre en oeuvre...
D'autant que pour afficher la consommation de fuel, j'avais initialement acheté un petit écran LCD monochrome qui était fixé sur une plaque acrylique où se trouvait également la consommation en eau douce. Cela ne me satisfaisait pas.

fuel 2ecransdebutgood.jpg
L'ancien LCD est conservé, avec l'affichage du reste de FUEL en segments


Dans ce cas précis, comme je remplaçais la jauge, j'ai donc décidé d'acheter un écran tactile de 2.8' TFT couleur avec lecteur de carte SD intégré, pour moins de 12 roros en Chine.

Cet écran est un shield, c'est à dire qu'il s'emboite parfaitement sur l'arduino UNO ou MEGA.

ecran.jpg

Cet écran est équipé du chip ILI9341 et de nombreux tutos sont disponibles, mais uniquement pour l'arduino UNO.
Mon programme étant plutôt complexe, il a fallu que je travaille avec une carte MEGA et donc adapter certaines bibliothèques et faire pas mal de recherches pour que le tout  fonctionne : affichage +sauvegarde sur carte SD + touchscreen...

L'avantage de cet écran est qu'il n'y a pas de complications liées aux branchements. Dans le même temps, sur une carte UNO, il n'y a que deux slots de libres, il y en a plus sur la MEGA. J'ai lu par la suite que cet écran existe aussi pour la MEGA (peut-être plus cher ?) mais peu importe.
L'inconvénient, en plus des connections limitées, réside dans l'encombrement. La carte MEGA dépasse de l'écran et pour ensuite encastrer le tout dans un support, cela n'est pas si évident.

Matériel

- écran TFT 2.8' acheté chez Bangood, pour +/- 11 roros ;

- carte arduino MEGA, +/- 12 roros ;

- capteur BME280 (pression, humidité, température) que j'avais déjà, environ 2-3 roros ;

- adaptateur 5V / 3.3V (pour le BMP280) 0,50cts FdP compris ! ;

- adaptateur 12V / 9V (alimente l'arduino et l'écran, 5V n'est pas suffisant) ;

- jauge capacitive 0/5V, en inox, à +/-60 roros + 50 roros de FdP et taxes
(là, c'est vrai ça pique un peu. En fait, il m'a été difficile de trouver un fournisseur chinois pour une seule unité - minimum 10 unités vendues - ce qui explique les frais connexes...)

- boitier imprimé en 3D, par mes soins ;

- du fil, des waego et surtout beaucoup de temps de recherche !

frown

Je vous passe les détails et le temps passé à écrire le sketch, cela fonctionne et c'est là, l'essentiel.

A la mise sous tension par la clé de contact, la jauge est activée ainsi que l'écran qui donne le niveau exact de fuel (et accessoirement la pression barométrique et la température). Clé tournée, moteur mis en marche, le RPM s'affiche et l'horamètre décompte le temps.

L'horamètre ne s'égrène (minute par minute) que quand le moteur tourne.
 

Données affichées

- Le reste de FUEL en pourcentage et en litres et sous forme d'un demi-camembert en segments décroissants ;

- L'horamètre moteur (heures et minutes), qui est sauvegardé sur la carte SD ;

- la pression barométrique et la température intérieure ;

- le régime moteur (RPM)

Toutes ces données sont envoyées sous forme de phrases NMEA par une "sortie" serial (il y en 3 sur la MEGA - TX1 à 3/ RX1 à 3) et notamment récupérées par OpenCPN.

Dans le livre de bord d'OpenCPN, s'affiche automatiquement le reste de fuel après une sortie et sur une autre colonne la consommation de cette sortie.

En tenant compte des autres paramètres récupérés automatiquement par le livre de bord, je pourrais ainsi - au fur et à mesure des sorties - estimer la consommation de carburant selon l'état de la mer, le vent et les courants !
En termes de prévision et de gestion de la ressource carburant, cela peut s'avérer très utile...

Phrases NMEA et indications données dans le sketch et lues par OpenCPN

Pour la pression, la température et l'humidité


 $WIMDA,<1>,<2>,<3>,<4>,<5>,<6>,<7>,<8>,<9>,<10>,<11>,<12>,<13>,<14>,<15>,<16>,
              <17>,<18>,<19>,<20>*hh<CR><LF>

Fields
<1>    Barometric pressure, inches of mercury, to the nearest 0.01 inch
<2>    I = inches of mercury
<3>    Barometric pressure, bars, to the nearest .001 bar
<4>    B = bars
<5>    Air temperature, degrees C, to the nearest 0.1 degree C
<6>    C = degrees C
<7>    Water temperature, degrees C (this field left blank by WeatherStation)
<8>    C = degrees C (this field left blank by WeatherStation)
<9>    Relative humidity, percent, to the nearest 0.1 percent
<10>   Absolute humidity, percent (this field left blank by WeatherStation)
<11>   Dew point, degrees C, to the nearest 0.1 degree C
<12>   C = degrees C
<13>   Wind direction, degrees True, to the nearest 0.1 degree
<14>   T = true
<15>   Wind direction, degrees Magnetic, to the nearest 0.1 degree
<16>   M = magnetic
<17>   Wind speed, knots, to the nearest 0.1 knot
<18>   N = knots
<19>   Wind speed, meters per second, to the nearest 0.1 m/s
<20>   M = meters per second

Ou bien (fonctionne aussi pour la pression - faut préciser Barometer dans ce cas -, mais la multiplication des **XDR à toutes les sauces n'est pas satisfaisante amha ; mébon, NMEA 0183 est une ancienne norme...)
 
1.--$**XDR


        1 2   3 4            n
        | |   | |            |
 $--XDR,a,x.x,a,c--c, ..... *hh<CR><LF>

Field Number:
1. Transducer Type
2. Measurement Data
3. Units of measurement
4. Name of transducer
There may be any number of quadruplets like this, each describing a sensor. The last field will be a checksum as usual.

ex : $IIXDR,P,1.02481,B,Barometer*0D
________________________________________________________________
 
 AVEC BME280
CAPTEUR ---> ARDUINO
SDI -------> SDA  A4
SCK -------> SCL  A5
SD0 -------> GND
  ==============> ATTENTION sur 3,3V

UNO              MEGA              
SDA = A4         SDA = 20           
SCL = A5         SCL = 21             

Phrase NMEA pour le fuel ( "spéciale OpenCPN )

$ IIXDR,V,00.0,L (or G),FUEL, * checksum

 IMPORTANT : le ground de la jauge doit être aussi relié au ground de l'arduino

biggrin

fuel arduino1.jpgDurant un test, on voit le RPM, baro et T°en plus...
 
TFT encastre.jpg
Test d'encastrement du boitier dans le pupitre de BàR.
il reste le "pourtour -couvercle" à rajouter pour finaliser l'encastrement et cacher les découpes dans le bois...

frown

Sur la courte vidéo ci-dessous, on aperçoit sur le côté le capteur BME280 et le convertisseur 5V/3.3V.
Il s'agit d'une vidéo réalisée durant les tests, certaines améliorations ont été encore apportées, notamment l'horamètre affiché en heures & minutes...

Initialement, je comptais afficher la pression, l'humidité, la température et le RPM sur une deuxième page, car il s'agit plus de contrôler de temps à autre le bon fonctionnement des capteurs que d'avoir l'oeil rivé dessus, d'autant plus que ces données sont envoyées en phrases NMEA au Journal de bord d'OpenCPN.
Cependant, au fur et à mesure de l'avancée de mes travaux, la fonction Touchscreen est devenue inopérante (soit un problème de librairie, de programmation, de SPI ou autres...) mais comme cette info. ne m'est pas essentielle, je l'affiche en petit sur l'écran 1, histoire de vérifier le bon fonctionnement des capteurs...

Tous les éléments ont ensuite été installés dans le boitier imprimé en 3D. Le résultat est très propre.

smile

ADDENDUM :

J'ai retravaillé l'affichage des caractères (lettres et chiffres) qui - d'origine - sont plutôt d'aspect Amstrad....frown

En effet, avec la librairie ADAFRUIT (qui est riche en exemples et fonctionnalités), les caractères (fonts) d'origine ne sont pas très sexy mais permettent d'afficher un chiffre et/ou une lettre avec sa couleur et la couleur du background, ce qui permet des changements d'état "invisibles" à l'écran.
La sonde peut bouger dans tous les sens, l'affichage ne sera affecté que sur le caractère qui change et cela se fait en toute transparence et le changement est imperceptible, seul le chiffre change.

Par contre, pour ajouter des caractères plus sexy à l'oeil, la musique est toute autre...
Il est en effet nécessaire de calculer la surface où s'affichera le nombre pour - à chaque fois - remplir le rectangle/background de la couleur du fond. En effet, si on n'efface pas à chaque fois le chiffre, le suivant s'imprime au-dessus et au bout que quelques instants, le tout devient illisible.
Cela est d'autant plus ardu quand il faut calculer différentes surfaces, pour permettre un affichage harmonieux s'agissant d'un nombre à un, deux ou trois chiffres (le volume restant et le pourcentage)...
Mais ce rajout indispensable d'un background à chaque passage de la boucle loop créé un clignotement systématique plutôt désagréable...

J'ai donc résolu ce souci en n'affichant les data de la jauge que toutes les 5 minutes, ce qui est largement suffisant et évite le clignotement.

Sur l'écran ci-dessous, on peut constater que même avec une simple police ARIAL, le rendu est quand même plus agréable à l'oeil...
La prochaine amélioration cosmétique concernera le segment coloré croissant/décroissant, mais cela n'est pas une priorité cool.

IMG_20181114_100236.jpg
L'image est agrandissable.
Seuls les petits chiffres "témoins" (baromètre, température, RPM)
restent dans la configuration d'origine et ne sont donc pas en ARIAL
(N.B.: La jauge n'étant pas branchée (sur cette photo), il y n'y a donc pas correspondance entre le %age et les segments colorés)

biggrin

FEVRIER 2020

Comme indiqué plus haut, j'ai dû remplacer la jauge capacitive par une simple jauge résistive; moins chère mais moins précise.

Une jauge capacitive donne le niveau de volume au pourcentage près du début 0V à l'extrémité haute 5V du tube, alors que sur une jauge capactive il y a 5 ou 6 signaux qui au passage d'un "aimant" modifient le signal envoyé. Cela est pour l'instant largement suffisant.

jauge_resistiv.jpg

Le branchement de cette jauge est relativement simple, quoique...

Un fil de la jauge résistive est branché sur le 0V. L'autre est branché sur du 5V (dans mon cas, à cause de l'arduino) avec une résistance que j'ai estimée au doigt mouillé à 560 ohms (après moult lectures sur internet). Ce même fil qui part de la jauge vers l'alimentation est également relié (via un waego) à un autre qui lui va vers l'arduino, comme signal.

Pour résumer, le noir vers le 0V.
L'autre fil va sur une entrée d'un waego 3 entrées qui est connecté sur l'alimentation avec résistance pour une entrée et sur le signal pour l'autre entrée.

Je ne garantis pas la fiabilité ni la pérennité d'un tel branchement que je n'ai pas encore testé dans la durée, nous sommes tous actuellement confinés !!!!
Je l'ai testé chez moi et cela fonctionne, rien de plus.biggrin

Rochers7163.gif


Date de création : 19/04/2020 11:03
Catégorie : -
Page lue 684 fois