image
image
image

Votre IP : 35.175.212.5
Dernier ajout : 28 mars
Visiteurs connectés : 24

image Conception
Développé sous SPIP
Informations légales

image
image
Recherche image

Pratiques et Techniques de la Plaisance

image

Accueil du site > Forum technique > L’électricité à bord -forum- > Divers > Système de supervision de bord : proposition de « beta-test »

Rubrique : Divers

__________________________________________________________________________________________________________________

Système de supervision de bord : proposition de « beta-test »Version imprimable de cet article Version imprimable

Publié Juin 2015, (màj Juin 2015) par : JLouis  image   

Copyright : Les articles sont la propriété de leurs auteurs et ne peuvent pas être reproduits en partie ou totalité sans leur accord
S'identifier pour s'abonner par mail Inscrit aux forum vous pourriez transmettre cette page à un ami plaisancier

Bonjour,
La PME dans laquelle je bosse développe actuellement une centrale de supervision technique basée sur un affichage couleur tactile et des terminaux en réseau (bus LIN) qui prélèvent, traitent et transmettent les données utiles sur l’affichage centralisé.

Une version ’nautique’ sera présentée en commercialisation en fin d’année normalement (salon la Rochelle) qui comprendra au moins la supervision des parcs de batteries, la gestions des réservoirs et cuves, la supervision des pompes de cales et la commande et supervision des feux de nav.

D’autres éléments sont prévus comme la commande à distance de relais, la collecte de contacts, la télécommande radio, l’interfaçage NMEA, etc.

Nous pouvons proposer des conditions intéressantes à quelques ’beta-testeurs’ prêts à consacrer un peu de temps à ce projet moyennant la mise en œuvre des produits sur leur bateau, le retour d’expériences et critiques constructives, la remontée de défauts et le test des correctifs. La réflexion sur des terminaux complémentaires est également ouverte.

J’espère que ce post ne va pas à l’encontre des règles du forum et m’en excuse si c’est le cas mais je précise qu’il ne s’agit pas d’une opération commerciale de ma part.

Merci

UP


Répondre à cet article
(pour répondre à un message en particulier, voir plus bas dans le fil)

94 Messages de forum

__________________________________________________________________________________________________________________

__________________________________________________________________________________________________________________

  • J’espère que ce post ne va pas à l’encontre des règles du forum

    Bonjour
    Non, je pense pas que vous soyez hors charte, c’est de la recherche, et tant que vous ne faites pas de prosélytisme commercial, c’est tout à fait clair...
    Pourriez vous développer plus précisément quels moyens il faudra mettre en oeuvre pour les testeurs ???

    Cordialement
    Michel

    Répondre à ce message

    • Le but est de tester les fonctionnalités implémentées, d’en améliorer la présentation ou l’efficacité, de détecter et de corriger des bugs, d’imaginer des fonctionnalités supplémentaires utiles et/ou pratiques afin de sortir en fin d’année un produit fonctionnel qui corresponde aux attentes des futurs utilisateurs.

      Le système est modulaire et tous les testeurs ne sont pas obligés de mettre en œuvre tous les modules.

      Par contre, le but étant de tester les systèmes en conditions réelles et de vérifier qu’ils supportent différentes configurations et usages, il faut que les cartes soient installées physiquement sur les équipements à superviser, pas simplement mises sous tension avec quelques bouts de fils sur une table, ce que nous faisons déjà au labo.
      A quelques exceptions près, je pense que les modules devraient supporter la mise en parallèle avec un module équivalent existant pour les tests au moins.

      Par ailleurs, les testeurs devront avoir des connaissances techniques afin d’être en mesure de procéder localement à une analyse d’un défaut afin de ne pas transmettre uniquement une info du type ’ça ne marche pas...’. Les cartes sont construites autour de microcontroleurs Microchip qui sont reprogrammables in situ mais ceci devra se faire physiquement avec un outil fourni ce qui suppose d’accéder à la carte et d’y connecter l’outil pour y flasher un soft transmis par mail ou téléchargé sur notre serveur ftp.
      Le matériel sera bien sûr mis à disposition gratuitement et le restera en fin de test s’il vous semble pertinent pour votre usage personnel. Il sera défini avec chacun en fonction de vos propres possibilités ou envies d’installation, d’intérêt.

      N’hésitez pas à poser des questions.
      Merci

      Répondre à ce message

  • La décision de développer ce système est née du constat qu’il est difficile de trouver des éléments sur le marché permettant d’obtenir des informations pertinentes sur divers dispositifs techniques du bateau comme le propose Victron avec la série BMV-600S pour le parc batterie.

    Par exemple, les pompes de cale : hormis un petit tableau avec un report sonore et un interrupteur pour la marche forcée... Pourtant, sauf à être présent 24H/24H sur le bateau, comme à monitorer tension/courant d’un parc batterie, on peut trouver de l’intérêt à analyser le comportement des pompes qui se déclenchent en notre absence : à quelle fréquence se déclenchent-elles ? l’intervalle et la durée de pompage sont-ils stables ? Le fusible est-il OK ? l’évacuation et l’aspiration sont-elles libres ? etc.

    Toutes ces informations seront fournies par l’analyse du courant consommé par la pompe sur une petite carte électronique installée à proximité de celle-ci. Elle intègre en plus une commande de marche forcée, une sortie relais d’alarme et une entrée pour une sonde externe supplémentaire. Si la sonde indique un niveau haut et que la pompe ne pompe pas > alarme !

    Comme pour les batteries, les infos sont mémorisées et accessibles à postériori.
    Sur l’affichage central (TFT 4,3"), elles sont lisibles en liste de textes (logs) mais également graphiquement.

    Dans un second temps, un module permettra de transmettre toutes ces données vers un serveur (Cloud) et elles seront accessibles sur un PC via le web. La liaison directe PC distant / bateau est également envisagée pour de la commande de test en temps quasi réel.

    La place étant limitée sur un bateau, l’afficheur permet de remplacer de nombreux cadrans à galva ou petits indicateurs numériques à usage unique. Plusieurs afficheurs peuvent être montés sur le bus s’il existe la nécessité de plusieurs points d’accès à ces infos.

    Répondre à ce message

    • Par exemple, les pompes de cale : hormis un petit tableau avec un report sonore et un interrupteur pour la marche forcée... Pourtant, sauf à être présent 24H/24H sur le bateau, comme à monitorer tension/courant d’un parc batterie, on peut trouver de l’intérêt à analyser le comportement des pompes qui se déclenchent en notre absence : à quelle fréquence se déclenchent-elles ? l’intervalle et la durée de pompage sont-ils stables ? Le fusible est-il OK ? l’évacuation et l’aspiration sont-elles libres ? etc.

      Disclaimer  : je ne suis pas de la partie même si rêve à l’occasion de pouvoir disposer (post mortem) de ces informations.

      L’exemple ci-dessus me parait très bien choisi et sans doute (espoir ...) répétable pour d’autres fonctions (ex : le frigo du bord ;-) )
      Dans le cas précis de cette pompe de cale il semble clair qu’on puisse tirer un diagnostique utile de l’observation des capteurs et actionneurs de cette dernière (fusible ok, courant « normal » lors des tests forcés, démarrages intempestifs).

      Je soupçonne de nombreux autres cas de « modules » (capteurs et d’actionneurs) pour lesquels les règles conduisant à un diag utile/utilisable et précis sont moins évidentes et sont à personnaliser fortement en fonction de ce qu’on surveille et de son histoire, je pense là précisément au moteur de propulsion équipant l’esquif d’origine (j’ai un fifty, d’où le soucis exacerbé).
      La variété immense de ces moteurs font qu’un logiciel de diag utilisable est « délicat » à développer par autre que le constructeur (ce que font les constructeurs actuels), qui est souvent disparu depuis longtemps ;-)

      Dans ce cas précis l’utilisateur devra (sera forcé de) se contenter de la collecte des infos des capteurs (surtout températures mais peut aussi être pression, en se piquant en dérivation sur les capteurs du constructeur), à charge pour lui d’implémenter des détections de seuil et peut-être un jour des trucs plus smart mais à son niveau. La simple collecte - et surtout leur visualisation ultérieure (ultérieure ou en temps réel sous forme de graphe défilant, à la manière d’un barographe) sous forme de graphe - de ces infos aide déjà beaucoup l’utilisateur de ces vieilleries et peut palier à la quasi impossibilité pour ce dernier de définir (rapidement) des règles d’alarmes fondées et utiles.
      Donc, dans mon cas précis (n’étant pas la partie je ne peut parler que pour moi) la fonction « datalogger » de nombreux capteurs, avec affichage défilant et fichiers de log, le tout augmenté de détection de seuils simples et peut-être à terme d’un mini langage d’expression de collections de conditions ... devrait me suffire ;-)
      Pour info, je pratique déjà beaucoup le datalogging à bord : le BMV600 lorsque je suis à bord (car il faut un PC up and running pour collecter) et l’état de batteries de service (maintenue par un mini-PS) par un Lascar USB et encore la température et l’humidité (pour le point de rosée) de la cale moteur l’hiver.
      L’aspect consommation du système en collecte seule est à prendre en compte, bien sur, d’où l’intérêt des très incomplets Lascar et BMV.

      Répondre à ce message

      • Nous ne pensons pas nous focaliser sur les données moteur pour les raisons que vous évoquez et la difficulté d’adapter un produit ’universel’ à toutes les configurations possibles que l’on peut trouver sur un parc de plus de 50 ans d’évolutions.

        L’objectif initial est de proposer une solution de remplacement de tous les petits galvanomètres qui donnent des informations succinctes et limitées, et encore quand les ils existent et qu’on est devant pour les observer.

        Pour info, nos cartes de supervision sont équipées d’une mémoire flash locale permettant de conserver les logs même si la connexion avec l’afficheur central est interrompue et celui-ci comporte un emplacement pour une carte µSD sur laquelle les logs sont archivés pour l’ensemble du système. Celle-ci peut ensuite être insérée dans un PC pour analyse ultérieure (format .csv). Donc pas besoin de PC pour logger.

        Par ailleurs, unité centrale d’affichage commune mise à part, pour le prix d’un BMV-602S, on va superviser 3 ou 4 shunts judicieusement choisis et montés. Ceci permet par exemple d’obtenir des réponses au lieu de ne faire que détecter un problème.

        Je retiens l’idée des températures de cales moteur...

        Répondre à ce message

  • Bonjour. Je suis intéressé à participer et je suis localisé au Canada ce qui peut peut-être apporter une perspective nord américaine à ce beta test.

    Je possède un voilier de 12m en cours de rénovation alors tous les systèmes ne sont pas fonctionnels voir même existant. Ce que je serais capable de tester dans un premier temps :

    * supervision de la pompe de cale (une seule pour l’instant)
    * supervision et commande des feux de navigation (incandescents pour l’instant, à DEL un jour !)
    * supervision des parcs de batteries de démarrage et de servitude (420 Ah)
    * niveau des réservoirs de fuel (hum... peut-être... à discuter)

    Un jour, si votre produit le permet, j’aimerais superviser :

    * température dans le compartiment moteur, avec alarmes
    * température dans le compartiment à électronique (électronique de navigation et ordinateur de bord), avec alarmes, et voir même contrôle thermostatique de la vitesse d’un ventilateur d’extraction
    * niveau du réservoir d’eaux noires
    * niveau des réservoirs d’eau potable
    * supervision du réfrigérateur
    * supervision du congélateur
    * consommation électrique segmentée en trois catégories : sécurité, navigation et domestique (mon circuit électrique en cours de reconfiguration a été planifié de façon à pouvoir mesurer ces trois catégories séparément)
    * envoie des données dans le cloud via le WiFi de la marina
    * interconnection NMEA 2000

    Pour terminer, je suis architecte de systèmes informatiques et j’ai été programmeur pendant des années. Je sais comment diagnostiquer et comment bien documenter des problèmes techniques. Je crois que ce sont des compétences transférables à ce projet.

    Au plaisir.

    Répondre à ce message

    • Merci pour ce retour positif.
      Effectivement vous correspondez aux profils que nous recherchons dans la mesure où ce dont vous disposerez dans un premier temps sera à solliciter, analyser, corriger et améliorer. Une mise à jour des cartes électroniques est prévue d’ici la fin de l’année qui permettra des évolutions plus importantes que les seuls aménagements des softs.

      Concernant les parcs batteries, nous sommes en cours de redesign de la carte de supervision. Il est possible d’y intégrer facilement la gestion de 3 shunts au lieu d’un. La carte n’est pas conçue pour être fixée directement sur le côté du shunt mais au plus proche de celui-ci avec un petit câble blindé type microphone. Si les 3 shunts de mesure par types de consommateurs ne sont pas trop éloignés, il est possible de traiter les 3 sur la même carte. Idem si 3 parcs (démarrage, servitudes, gros consommateurs) sont proches.

      Concernant la supervision de moteurs anciens (sans données NMEA 2000 en natif), il est possible pour nous de collecter les données des capteurs traditionnels sur un terminal de supervision dédié. Ceci n’empêchera pas de les récupérer ultérieurement sur le NMEA. Il faudrait définir les infos utiles et pertinentes pour voir si nous pouvons les traiter sur une carte existante ou si nous devons en développer une pour cela.

      Concernant la pompe de cale, quel courant max. est indiqué par le constructeur (ou modèle, je trouverai les infos) ? Est-elle montée avec une sonde externe ou interne ?

      Pour les feux, notre carte dispose de 6 sorties avec fusibles avec une entrée générale. Elle est prévue pour des ampoules 25W ou 10W et leds 1W.

      Concernant le réfrigérateur et le congélateur, vous pensez à un suivi continu de leur température interne et éventuellement à la température de surface du compresseur ou du moteur ou simplement à la transmission d’un contact d’alarme existant sur les appareils ?

      Répondre à ce message

      • La pompe de cale est une Rule 2000 monté avec sonde externe. Max 12A.

        Concernant le réfrigérateur et le congélateur, je pensais effectivement à un suivi continu de leur température interne avec alarme pour avertir avant de perdre la nourriture si la température monte trop. Je n’avais pas pensé au suivi de la température de surface du compresseur ou du moteur mais ça pourrait aussi être intéressant.

        Je viens de repasser mes notes concernant un futur système de supervision. Voici en vrac quelques autres idées qui pourraient vous intéresser :

        * Possibilité de centraliser d’autres alarmes pouvant être levées par différents équipements. L’idée étant d’avoir un seul endroit où toutes les alarmes sont envoyées plutôt que d’avoir tout plein de « buzzers » et d’avoir de la difficulté à identifier lequel sonne et pourquoi. Par exemple :
        * Détecteur d’eau dans les filtres diesel Racor.
        * Alarme de haute température du système d’échappement.

        * Possibilité d’installer un deuxième « buzzer » à distance, dans le cockpit par exemple.

        * Fonctionnalité de suspension des alarmes (mute). Une fois que je sais qu’il y a un problème, je ne veux pas continuer à me faire casser les oreilles pendant que j’essaie de le régler... à moins qu’un changement ou qu’une nouvelle alarme survienne.

        Répondre à ce message

  • Bonjour,
    Malgré cette période de silence et mes récents déplacements professionnels, le projet avance mais n’est pas suffisamment abouti pour que nous démarrions ces tests en août, d’autant que l’entreprise sera fermée pendant 3 semaines. C’est donc remis à septembre au mieux.
    Des pistes sont à l’étude pour réduire drastiquement la consommation globale pendant les périodes d’absence ou de recherche d’une consommation limitée au minimum mais les compromis sont souvent un peu délicats... Qu’est ce qui vous semblerait acceptable pour un système de surveillance en veille ?
    Certaines cartes électroniques devront certainement évoluer pour pouvoir exploiter différents moyens non initialement prévus comme la détection du 12V après contact (affichage).
    Bonnes vacances à ceux pour lesquels elles ne sont pas terminées et bonnes navigations à tous.

    Répondre à ce message

  • Bonjour,
    Me voilà de retour sur le forum avec quelques nouvelles mitigées sur l’avancement du projet.
    Quelques défauts de hardware ont été mis en évidence qui vont nous obliger à faire une nouvelle version de certains circuits imprimés donc prendre du temps supplémentaire dont nous nous serions volontiers dispensés...
    Toutefois, si vous souhaitez commencer des tests prochainement et que les défauts à corriger ne sont pas trop gênants pour vous, c’est jouable.
    Le contrôleur de pompe de cale est prêt : le circuit sera refait car il nous manque une mesure correcte de la tension d’alimentation de pompe. Actuellement nous mesurons la sortie 3,3V d’un régulateur mais çà permet néanmoins de signaler que la pompe n’a plus d’alimentation.
    Le contrôleur de feux de navigation est presque prêt. Il reste quelques jours de soft et de tests à réaliser. Son défaut hardware est dans la taille des connecteurs pour y raccorder les fils d’alimentation des feux. Si vos fils sont de 1.5mm² max. c’est jouable mais limite. Si la section est inférieure, pas de problème. Les prochains borniers seront plus gros.
    Le contrôleur maitre avec afficheur TFT n’est pas tout à fait prêt en terme de soft mais c’est une question de jours vis à vis des deux contrôleurs précédemment cités. Il comporte plusieurs défauts hardware et une nouvelle version de circuit s’impose : pas d’entrée pour la détection du +12V après contact pour pilotage affichage et limitation conso (115mA @ 12,6V hors contrôleurs périphériques), erreurs de positionnement de perçages mécaniques, deux corrections de schéma montées en ’volant’. Les cartes sont exploitables et fiables néanmoins.
    Deux versions ’mécaniques’ de l’afficheur sont possibles : montage encastré (façade PVC blanc actuellement ou alu noir ultérieurement) de 175 x 135 mm ou boîtier injecté ABS (blanc cassé ou noir) de 175 x 130 x 26mm.

    Je suis à votre écoute pour préparer le matériel dont vous avez besoin pour démarrer dès que possible avec les circuits actuels ou ultérieurement si vous préférez attendre les versions définitives des circuits.
    Je prépare de la doc préliminaire et des images...

    Répondre à ce message

  • Bonjour,

    Je suis éventuellement intéressé par votre proposition.

    Je vis et navigue depuis 4 ans sur mon bateau de 12 m (neuf et moderne BV 40) , principalement en méditerranée(Italie-Grèce). Ce bateau est équipé d’une platine centrale de commande électronique où tout est centralisé :
    - mise en marche et arrêt des instruments de nav.
    - feux de nav avec test des lampes
    - niveaux d’eau claires et noires avec alarmes
    - tensions des batteries avec alarmes
    Tout ceci sur un seul circuit imprimé avec un afficheur 2 lignes de 16 caractères.

    Bien sur, je ne vous dis pas le prix (+ de 1K€) pour le changer. Quant à réparer une fonction séparée...

    Bref, il serait intéressant de disposer d’un système modulaire pour remplacer au fur et à mesure de leur défaillance les fonctions défectueuses( par ex : les niveaux des.cuves à eaux noires ne fonctionnent plus....).(je vous laisse pour les commentaires :>) !

    Par ailleurs, je suis assez d’accord avec les commentaires et propositions de YvesD et TA, parmi lesquelles :

    -centralisation des contacts d’alarmes : beaucoup d’équipements modernes disposent de ces contacts et sont souvent inutilisés.
    - graphiques d’historique des valeurs de fonctionnement (Charge-décharge, températures..)
    - Si le gestionnaire de batterie donne une idée sur l’autonomie, un ou deux shunts supplémentaires pour les gros consommateurs (pilote et frigo),ainsi que sur les panneaux solaires serait un plus.
    - un module de contrôle et suivi du frigo avec deux sondes( voire 3)...
    - ventilation cale moteur et/ou cabine avec point de rosée
    - interfaçage Nmea 2000(CAN) et série.

    Pour mes compétences, je suis ingénieur bio-médical et j’ai passé trente ans dans l’industrie à « numériser » des équipements et des processus médicaux.
    Je participe peu sur les forums et je « consulte » PTP depuis sa création, une source d’informations de qualité pour moi.

    Enfin, je passe l’hiver sur mon bateau à flot à Marina di Ragusa(Sicile) et dispose de pas mal de temps libre.

    Salutations à tous.

    Gilles.

    Ps pour Michel(yoruk) : Si je comprends bien, nous nous sommes croisés de peu, car je suis rentré hier soir. Mais Licata n’est pas loin...

    Répondre à ce message

    • Bonjour et merci pour cette proposition de participation.

      Les conditions de tests que vous décrivez me paraissent intéressantes compte tenu de l’avancement du projet. Nous pourrions débuter rapidement sur certains aspects et avancer progressivement si vous le souhaitez.

      Dans l’état actuel des choses, je peux vous proposer une unité centrale avec écran 4.3" à encastrer avec façade PVC blanc ou boîtier ABS indépendant écru ou noir qui peut être fixé en applique ou monté sur support articulé.

      En terme de périphériques de contrôle, le CPC (pompe de cale) et le CFN (feux de navigation) sont exploitables avec quelques restrictions déjà évoquées précédemment avec la version actuelle du cuivre. Le CPB (parc batteries) est en cours de développement soft et sera exploitable pour le test d’ici 2 à 3 semaines max. Nous pourrions d’ailleurs rendre ce développement ’interactif" sur ce fil ou un fil annexe si vous le souhaitez afin que les fonctionnalités mises en œuvre soit les plus pertinentes par rapport aux attentes de nos premiers testeurs...

      Quelques infos nécessaires : tension du bateau ? 12V ou 24V ? Combien de pompes de cales ? Quel(s) modèle(s) ? Quel(s) capteur(s) de niveau ? Report(s) sonore(s) à proximité de la pompe ? Pour les feux, quelles puissances d’ampoules ? départs câbles centralisés ?

      A suivre...

      Répondre à ce message

      • Bonjour,

        Merci pour les photos, ça à l’air sympa !

        Pour avoir une idée de mon tableau : voila sa doc
        http://www.yachtcharterlemmer.de/fi...
        tous les départs sont accessibles et centralisés sur des connecteurs.
        La majorités des câbles sont en 2.5 mm2 et certains en 4.
        La tension est 12V.
        Ce tableau est prévu pour des ampoules à filament (10W et 20W).J’ai changé les ampoules de proue(R/V) et de poupe pour des leds 2W et la détection de défaut fonctionne (bien !).Je changerai les autres plus tard( peu utilisées).
        Par contre, j’utilise un feu de mouillage supplémentaire à led.
        Deux parcs de servitude : en effet, aussi sur les monocoques. Pour moi, l’idée est de conserver séparé un parc pour les instruments de nav et d’éviter une décharge complète par les gros consommateurs( Pilote, frigo, inverter).

        Vous parlez de trois modules en cours.Pouvez-vous détailler leurs fonctionnalités plus en détail ?
        Avez- vous d’autres modules prévus ?

        Répondre à ce message

        • Merci pour la doc. Je vais la parcourir.
          Pour les feux de nav, si chaque ampoule est alimentée en 2,5mm² ce qui me semble généreux même pour du 25W en 12V, la carte actuelle va poser un problème car les borniers installés sont prévus pour du 1,5mm² max. Nous allons les remplacer sur la prochaine version. Une bidouille provisoire reste possible...

          La page photographiée ne montre que le paramétrage d’un parc mais le nombre de parcs est actuellement limité à 3 (uniquement à cause de la page de synthèse - idem pompes). Un parc, une carte de contrôle qui supervise de 1 à 3 shunts paramétrables.

          Nous comptons développer toutes les cartes qui présenteront un intérêt technique et une originalité vis à vis de ce qu’on peut trouver par ailleurs sur le marché. Le développement d’une carte n’est pas très coûteux car le code est modulaire et le hardware interne et éprouvé dans le domaine STI médical. Nous disposons de radio bidirectionnelle supervisée, du CAN, l’unité centrale est actuellement USB device mais peut devenir HOST. Une carte SD est intégrée qui contient les logs.

          Après les cartes contrôleurs essentielles, nous intègreront certainement une interface GPRS pour transmettre les données dans le Cloud et y accéder depuis diverses applications ou piloter à distance certaines fonctions.

          Répondre à ce message

  • Voici quelques images ’vite faites’ de l’unité centrale (TFT 4.3" avec dalle tactile).

    PNG

    Répondre à ce message

  • Apparemment, une image par post...
    Pompe de cales (3 pompes possibles / page de synthèse)

    PNG

    Répondre à ce message

    • Bien alléchant tout ça, bravo.
      quelques remarques au vu des images d’écran :

      • feu de nav : de nombreux bateaux sont équipés d’un tricolore tête de mat et de conventionnels au niveau du pont (Bd, Td, poupe). J’ai un vague souvenir que la réglementation britanique ne tolère pas toujours ou tout le temps le tri en tête de mat. Prévoir de suveiller une ampoule de plus (la tête de mat) en plus des 3 conventionnelles.
      • feux d’éclairage de pont (pas critique, quoique) : sur les ketch il y en a 2
      • batteries de servitude : plus d’une fois j’ai vu plus d’un parc et pas que sur les cata ;-)
      • détecteur de gaz : pas de pb avec le CO2 et le CO mais le butane/propane est un vrai problème avec une conso tout à fait non négligeable (500 mW je crois, et 24*365). Cette détection semble obligatoire pour les plaisanciers anglais, couplé avec une électro-vanne au niveau de la bouteille. Sont-ce des fonctions à traiter entièrement séparément, à ne pas intégrer ?
      • détecteurs : pour info mon moteur est équipé de détecteur tout ou rien (alarme) pour la température d’eau, la pression d’huile moteur et la pression d’huile inverseur, ainsi que de capteur analogiques pour les mêmes variables, et dont les valeurs sont affichées sur des cadrans. Je verrrai un plus à ce que ces valeurs soit mémorisées au fil de l’eau (datalogger)
      • température de certaine zones du moteurs, en plus des précédentes : collecteur d’échappement, coude ou tuyau d’échappement (rupture d’impeller), joint presse-étoupe ou PSI (surchauffe pré-fatale)

      Ces deux derniers points sont sans doute les plus « vaseux » et sont pourtant diablement utiles : on ne sait pas trop quoi surveiller ni comment et il parrait difficile de systémtaiser le processus (trop de variabilité/diversité) : au minimum du datalogger et du dépassement de seuil réglable par l’utilisateur.

      Répondre à ce message

      • Mon moteur est aussi configuré comme celui de yvesD avec détecteurs alarmes pour la température d’eau et la pression d’huile, ainsi que de capteur analogiques pour les mêmes variables.

        Merci pour les photos, ça rend le tout plus concret.

        Avez-vous prévu de traduire l’interface en anglais ? Si oui, je pourrai réviser la traduction sans problème étant baigné dans le milieu nautique anglophone nord américain.

        Répondre à ce message

      • Merci pour ce retour constructif.
        Pour le feu tricolore, il est prévu et paramétrable. Il a 6 canaux 3A que l’on peut activer ou non. Si le tricolore est utilisé, je suppose qu’on invalide Bd, Td et poupe (ce n’est pas le cas sur la photo) et inversement. Mouillage et tête de mat ne sont pas désactivables.
        Nous n’avons pas intégré sur cette carte l’éclairage de pont.
        Il pourrait être facilement intégré sur une carte entrées/sorties annexe sur laquelle chaque sortie aura sa légende propre...
        La différence sera le contrôle du courant. Sur la carte feux de nav, chaque canal est contrôlé en courant et si une ampoule paramétré pour 10W n’en consomme que 8,5W vous aurez une alarme visuelle.

        Un second parc de batteries de servitude n’est pas un problème. On ajoute une carte CPB pour lui et on double toutes les fonctionnalités. Sur une carte CPB, on peut câbler de 1 à 3 shunts. Le premier est général et obligatoire. Les 2 autres sont optionnels et permettent d’analyser des circuits partiels du MEME parc. Comme pour les pompes de cale, la page de synthèse batteries permet d’avoir à l’œil 3 parcs simultanément.

        Les détections de gaz et les infos moteurs feront l’objet de contrôleurs dont les cartes ne sont pas encore développées donc je prends note de toutes vos suggestions pour ne pas en oublier. Nous pensons également intégrer la gestion de capteurs à effet hall pour vérifier des parties tournantes en y ’collant’ simplement un aimant (pompe eau de mer, alternateur). Comment voyez-vous la prise de température aux endroits non initialement prévus sur le moteur ou l’échappement ? Type de capteur ? montage ?

        Concernant les températures (hors moteur), en particulier du fait du frigo, nous pensons utiliser des capteurs radio sur pile afin de simplifier l’installation. Qu’en pensez-vous ?

        Répondre à ce message

        • Le post précédent est mal placé... Désolé ! Je me suis râté et je ne sais le supprimer.
          Il fait suite au post de YvesD bien sûr.

          Répondre à ce message

        • Comment voyez-vous la prise de température aux endroits non initialement prévus sur le moteur ou l’échappement ? Type de capteur ? montage ?

          • J’ai souvenir d’avoir lu quelque-part (sur Plaisance-Pratique ?) l’existence d’un collier type serflex intégrant une sonde de température, collier qui doit enserrer le tuyau « souple » en sortie du coude d’échappement (température des gaz d’échappement)
          • un des capteurs analogique de température sur mon moteur est une pastille (10mm de diamètre, 5mm d’épais, 2 cosses) qui est collée (cyanolite) à l’emplacement à superviser (voir photo jointe)
          JPEG

          Répondre à ce message

        • en particulier du fait du frigo, nous pensons utiliser des capteurs radio sur pile

          la consommation d’un truc censé fonctionner 24x265 m’inquiète toujours. De ma pratique avec un bête baromètre enregistreur Latitude (entre autre) je préfère une alimentation sur 12V batteries plutot que sur pile, sauf bien sur si la pile LR4 dure un an ;-). Pour couper la poire en deux, laissez un repiquage interne permettant d’y raccorder le 12V (interrompu au désarmement) du frigo. L’aspect radio me semble parfait pour ne pas tirer un câble de plus

          Si le tricolore est utilisé, je suppose qu’on invalide Bd, Td et poupe

          Ca devrait être le cas. En pratique le tricolore est un add-on à postériori, chacun avec son interr propre, c’est à l’humain le soin de réaliser ce où exclusif. Mais c’est un vieux bateau, bientôt 38 ans.

          capteurs à effet hall pour vérifier des parties tournantes en y ’collant’ simplement un aimant (pompe eau de mer, alternateur)

          Séduisant. J’imagine que vous êtes familier de ce montage, moi j’y craindrai un balourd mais je ne suis pas trop technique.

          Une remarque : l’adjonction de consommateurs (vos modules) consommant même en période de désarmement réclame sans doute un délesteur (11,5 V) en sortie de batterie, ou sur le boitier lui-même ?

          Répondre à ce message

          • La radio pour les capteurs de température permet en utilisation sur pile, d’obtenir une info très simplement dans la mesure où il n’y a pas de fils à passer là où il n’y a pas déjà un passage, comme certainement à l’intérieur du frigo ou à certains endroits de l’environnement moteur... Par contre effectivement le problème de l’autonomie se pose fatalement si on veut une lecture temps réel ou fréquente de la température.
            Si par contre on se suffit d’une transmission cyclique de logs et d’une transmission temps réel de température de consigne dans les choux, une alcaline LR3 peut tenir 12 mois, voire davantage.

            Concernant les capteurs à effet hall / aimants permanents, effectivement l’ajout d’un aimant sur une pièce tournante provoque un balourd mais celui peut être compensé par un second diamétralement opposé ou considéré comme négligeable si sa masse est très faible (< 10g) par rapport à la masse tournante.

            L’alimentation des modules est fournie par l’unité centrale et véhiculée par le bus (2 paires). Ce n’est pas le cas actuellement mais nous allons prévoir une coupure possible de l’alimentation du bus sur la prochaine version de la carte, idem pour la détection du + après contact. Pour ceux qui souhaitent conserver les modules actifs, nous prévoyons un mode ’basse consommation" dans lequel chaque module enregistre dans son coin et transmet épisodiquement.

            Répondre à ce message

  • Parc batteries (paramétrage) en cours...

    PNG

    Répondre à ce message

    • Sauf erreur de ma part, les logs extraits du BMV-600 sont à intervalle d’une à 12 minutes selon paramétrage. Est-ce suffisant pour les besoins d’analyses que vous avez eu à effectuer ?
      Le temps réel à fréquence élevée n’est pas réalisable sur notre système. Nous aurons un rafraichissement tension - courant - ampères-heures à la seconde à peu près.
      Si nous loguons çà, les fichiers vont grossir rapidement...
      Nous pensons donc effectuer une moyenne pour V et I et un cumul pour les AH sur 60s mais on peut descendre si ça a du sens.
      Qu’en pensez-vous ?

      Répondre à ce message

      • Est-ce suffisant pour les besoins d’analyses que vous avez eu à effectuer ?

        Je m’en sert d’une part pour évaluer la bonne santé et la charge des batteries avec un A2B comme chargeur (ça pousse fort) et d’autre part pour évaluer l’impact du frigo et les déclenchements intempestifs de la pompe de cale
        Je viens de vérifier les logs (format csv) produit par le logiciel, c’est cable en dur à un échantillon par minute pour le logiciel PC qui surveille le cordon data du BMV, ce qui est un peu juste pour constater la chute de tension lorsque la pompe ou le compresseur fonctionnent bien que je puisse repèrer ces derniers aussi (et surtout) par le courant restant qui chute tout de même (sur la pompe j’ai un compteur de démarrage que je dois installer ... depuis 2 ans :-< ). Bien sur je les repèrent beaucoup mieux avec le datalogger tension (Lascar Easylog USB 3) dont la fréquence d’échantillonage est réglable à des valeurs de fréquence plus élevées, on peut échantilloner au mieux à 1 Hz (capacité du log = 32000 échantillons).
        A la réflexion donc ces fréquences lentes ou rapides me sont également utiles : les lentes pour durer 2 mois (temps max d’un désarmement) et les rapides pour surveiller du fonctionnement à la journée.

        Si nous loguons çà, les fichiers vont grossir rapidement...

        1 échantillon par seconde pendant 1 an font environ 30 M échantillons (plutôt sur 2 que sur 4 octets pour chaque valeur loggée). Saturer une carte SD de 16Go, faudra le faire ..., la limite ne viendra pas de ce coté mais plutôt de l’analyse des données et surtout de retrouver l’instant significatif à étudier au milieu de ce fatras.
        Si au contraire on logge tout ça au fil de l’eau sur une prise USB la limite viendra du disque du PC, là encore pas trop de soucis

        Répondre à ce message

        • Assez d’accord avec ces réponses qui « sentent » le vécu...!

          Je me permets d’ajouter quelques remarques :

          * en effet, si le stockage des données n’est pas vraiment un problème, l’analyse a posteriori sur un pc peut être grandement facilitée avec des outils comme les bases de données. il serait donc intéressant d’avoir un outil d’analyse des logs produit par le système ( au moins recherche d’une période et affichage de plusieurs valeurs au choix)

          * une moyenne sur 60 secondes avec un échantillonnage à une seconde apporte peu d’information, à part d’être un « gommage » ou filtre passe-bas. par contre,si elle est accompagnée du min/max et/ou de l’écart-type, on peut détecter plus facilement et à coup sur une anomalie.

          * il est aussi possible de comprimer les données, si la puissance et l’occupation du processeur qui réalise le log le permet.

          Répondre à ce message

        • Je suis d’accord, le problème viendra essentiellement du traitement des données archivées.

          Nous avons par ailleurs un problème de débit du bus qui est initialement prévu pour de l’évènementiel et pas pour de l’échantillonnage mais on réfléchit à des solutions de transmissions en paquets afin d’archiver les détails.

          La destination du produit n’étant pas de remplacer un oscilloscope numérique, les signaux transitoires seront de toutes façons lissés par le composant d’acquisition mais nous disposons actuellement sur CPB (batteries) de 88 échantillons/minute (680ms) en tension et courant.

          Est-ce que la puissance vous semble utile à afficher ou tension, courant et ampères heures suffisent ?

          Répondre à ce message

          • nous disposons actuellement sur CPB (batteries) de 88 échantillons/minute (680ms) en tension et courant.
            Est-ce que la puissance vous semble utile à afficher ou tension, courant et ampères heures suffisent ?

            Je vis actuellement très bien avec 1 éch / mn pour la tension de la batterie de servitude et n’en demande en général pas plus. C’est ce que j’obtiens avec le moniteur BMV600 (PC allumé) ou avec le datalogger (PC éteint, bateau désarmé).
            Lorsque j’étudie un problème précis et identifié, la cadence de 1 éch / seconde avec le datalogger me suffit.
            Donc 88 / minute c’est parfait pour les situations que j’ai pratiqué, à bord de ma vielle de 33 pieds et de 1977 (c’est pas un super-yacht)

            Toujours pour ce pas super-yacht tension et courant me sont entièrement suffisant, j’arrive encore à faire la multiplication de tête ou a raisonner en Ah plutôt qu’en Wh. Mais je ne peux me mettre à la place de clients potentiels ;-)

            Répondre à ce message

  • Avez-vous prévu le branchement et contrôle d’un feu stroboscopique de tête de mât. Plusieurs bateaux ont ce feu à utiliser en situation d’urgence. Il serait bien de pouvoir l’allumer de la même interface que les autres feux de navigation. Le mien utilise une ampoule au xenon de 8W.

    Répondre à ce message

    • Nous avons actuellement 6 canaux contrôlés en courant.
      Si on en utilise un pour le mouillage et 4 en nav au moteur, un reste dispo pour y mettre ce que l’on veut tant que sa consommation est inférieure à 3A.
      Si on va au bout de ce raisonnement, en cas d’utilisation d’un feu tricolore, on n’utilise que 3 canaux ou 4 avec un feu bicolore.
      On peut modifier le paramétrage de la config pour isoler les canaux non utilisés par l’automatisme de commutation des feux de nav et affecter ceux-ci à des boutons graphiques ON/OFF à étiquettes variables.
      C’est jouable.

      Répondre à ce message

      • S’il y a un feu tricolore, est-ce que le 6e canal ne sera pas utilisé par celui-ci ?

        Personnellement, je ne pense pas que ce ne soit la fin du monde si le feu stroboscopique n’est pas contrôlé en courant. Il est supposé n’être utilisé qu’en situation d’urgence pour aider les secours à trouver le bateau. Étant en situation d’urgence, je ne monterai certainement pas au mât pour changer l’ampoule si elle est brûlée ! Donc pour ma part, un interrupteur ON/OFF est suffisant pour le feu stroboscopique...

        Répondre à ce message

        • Logiquement s’il y a un feu tricolore, les feux tribord, babord et poupe ne sont pas utilisés donc le tricolore peut utiliser l’un de ces canaux. Il s’allumera et sera testé à chaque passage en voile ou moteur.

          Mettre un feu d’urgence sur un canal testé permet de savoir qu’un problème existe avant de devoir s’en servir. C’est clair que si l’ampoule claque lors de l’allumage, son remplacement n’est alors pas prioritaire mais c’est peut être utile de savoir qu’il ne fonctionne pas et d’utiliser d’autres moyens pour signaler visuellement la position du bateau.

          Répondre à ce message

          • Pour ma compréhension. Quand on dit qu’il y a 6 canaux, est-ce que ça veut dire qu’un maximum de 6 feux peuvent être contrôlés (allumés ou pas), ou plutôt qu’un maximum dynamique de 6 feux peuvent être allumés à la fois, mais que plus pourraient être branchés ?

            Répondre à ce message

            • Côté hardware, il y a 6 canaux indépendants limités à 3A sur chacun avec une mesure de courant individuelle.
              Une commande ’logique’ (soft) permet de choisir 4 modes : OFF/MOUILLAGE/VOILE/MOTEUR. Chaque mode commute les canaux qui y sont affectés.
              Si les feux de route au moteur sont indépendants, 5 canaux seront commutés et contrôlés selon le mode choisi.
              Le 6° pourrait être affecté à un bouton ON/OFF supplémentaire dédié par exemple au feu à éclats.
              Si le bateau est équipé d’un tricolore, 3 canaux seront dispos (hors automatisme de commutations) et alloués à des commutations indépendantes de feux ( < 3A)

              Répondre à ce message

              • alloués à des commutations indépendantes de feux

                On peut aussi régler de façon élégante la réglementation sur les feux en tête de mat, en conservant le circuit et les feux de balcon d’origine. Passant d’un circuit à l’autre en les commutants, il n’y aura besoin que d’un seul point de contrôle
                Et, on conserve aussi le contrôle du feu de mouillage

                http://www.plaisance-pratique.com/f...

                Répondre à ce message

              • Ok, je comprend. C’est ce que je pensais. L’endroit où je pense vous faites erreur, c’est en disant que s’il y a présence d’un feu tricolore de tête de mât, il y ait trois canaux de disponibles.

                Selon mon expérience, et selon ma compréhension du règlement sur la prévention des abordages en mer de l’OMI, le feu tricolore ne peu être utilisé que sous voile, et que donc il y a nécessairement présence d’un feu de poupe et de feux latéraux tribord et bâbord (ou combinés en un seul feu) pour utilisation au moteur. Il y aurait donc au mieux 1 canal de libre, voir aucun.

                Est-ce que je fais erreur ?

                Répondre à ce message

                • En lisant le SHOM 2A, je ne trouve pas de réponse claire à cette question.
                  Il y est précisé qu’en route à la voile, un bateau de moins de 20m peut utiliser un feu tricolore.
                  Effectivement dans le paragraphe décrivant les exigences relatives aux bateaux faisant route au moteur, on ne trouve pas référence au feu tricolore...
                  On doit en déduire que le voilier de moins de 20m s’il utilise un feu tricolore sous voiles doit commuter sur 3 feux indépendants lorsqu’il est au moteur ?
                  Je ne comprends pas du coup l’intérêt du feu tricolore puisque les feux indépendants sont utilisables aussi bien à la voile qu’au moteur...

                  Effectivement, si le feu tricolore ne se substitue pas aux feux latéraux et de poupe, tous les canaux actuels sont utilisés.

                  Répondre à ce message

                  • Je crois avoir compris.
                    Le tricolore ne peut être monté qu’en tête de mat pour être visible sur 360°. Il présente en plus l’avantage pour un voilier faisant route à la voile d’économiser de l’énergie et d’être visible dans les creux car placé haut.
                    En route au moteur, il n’est pas utilisable car le feu dit ’tête de mat’ doit être au moins 1m au dessus des feux latéraux. Il doit donc être éteint et remplacé par les latéraux et le feu de poupe.

                    En conclusion, pour un voilier équipé d’un feu tricolore, les 6 canaux de la carte CFN actuelle sont occupés sauf s’il n’y a pas de tricolore.

                    La révision de la carte qui sera lancée d’ici quelques semaines pourra améliorer çà si nécessaire...

                    Répondre à ce message

  • Avez-vous prévu un mode d’affichage de nuit ? Lors d’une alarme pendant une navigation de nuit, je ne voudrais pas devoir regarder un écran super brillant pour déterminer la source de l’alarme, et du coup perdre ma vision de nuit. Personnellement, j’aimerais voir une interface foncée, style texte blanc sur tons de gris, avec luminosité de l’écran au minimum. J’aimerais aussi que le passage au mode nuit ce fasse automatiquement en fonction de la position géographique et de l’heure de couché/levé du soleil. La position devrait pouvoir être entrée manuellement, mais aussi pouvoir utiliser les coordonnées GPS du bus NMEA2000.

    Répondre à ce message

  • Nous travaillons sur la détection de fin de charge (synchro) permettant d’afficher un SOC théorique de 100%. Classiquement, une tension > 13.2V et un courant < 2 à 4% de C pendant quelques minutes permettent de déterminer ce moment.

    Avec un alternateur régulé (sans AtoB) ou un vieux chargeur de quai (charge à V constant) et sans consommateurs, ça doit se passer plutôt bien.

    Mais avec des chargeurs modernes dont la tension de charge monte jusqu’à 15V et des consommateurs qui perturbent la mesure du courant de charge sur un shunt unique et global, je ne vois pas comment cette détection pourrait être fiable...

    La solution consistant à régler le seuil légèrement au-dessous de la tension d’absorption ne solutionne pas le problème car la consommation simultanée pourra conduire à détecter un faible courant global qui engendrera une synchro 4H trop tôt.

    Vous qui utilisez des moniteurs de batteries performants sur shunt unique, qu’en est-il en navigation par exemple ?

    Répondre à ce message

    • Je ne suis pas absolument certain que ce problème se pose à moi : l’alternateur est capable de fournir 70A (ce qu’il ne fait jamais) et si, dans la phase boost (courant constant, tension décroissant progressivement) un appel significatif de courant se produisait, je ne suis pas sur que la tension décroitrait brutalement au point d’enfumer le A2B et lui faire croire que l’heure de la phase suivante (tension constante et courant décroissant, phase qui débute lorsque la tension tombe sous 13,8-13,6V) est arrivé. J’imagine qu’il faudrait pour cela que les courants consommés (dont cet appel de courant) dépasse les capacités de production de l’alternateur.

      En effet, dans ma situation courante, en route au moteur, l’alternateur produit 20 à 40A (j’ai un ampèremetre historique qui affiche cette production là, je n’invente rien) et le courant au shunt du A2B (juste avant la batterie SERV, ce qui reste pour recharger la batterie après la part des consommateurs) tourne autour de 30 à 10A pendant que les consommateurs (moteur du pilote, PC, frigo, électronique) goinfrent 10 à 15A max (frigo en route).
      En mode boost (les 4 premières heures) le courant restant pour la batterie tourne plutôt autour de 20A (souvent plus) quelque soit les consommateurs, ce qui me fait penser que l’alternateur étale le coup (== les appels de courant), que la tension n’arrive pas à tomber sous 14,5V, que le A2B ne croit pas que c’est l’heure de l’étape suivante.

      Il reste que les indications du moniteur victron (par le cordon data, le cadran du BMV est un peu lège pour faire ça) sont parfois délirantes, mais le plus souvent c’est que le A2B est resté en boost alors qu’il aurai du (selon le victron) passer en float. Alors je jette un coup d’oeil sur les voyants du BMV et sur le cellulo sur lequel à été photocopié la page du manuel Sterling (tout deux dans un compartiments un peu à l’écart), et je ne constate pas, la plupart du temps, d’anomalie flagrantes. Quoique parfois trouver 3A et 14,5V... alors au pire, j’éteins tout (moteur), je laisse reposer et je recommence en surveillant très attentivement.

      En résumé, la plupart du temps c’est l’alternateur qui étale et empêche le A2B de se planter. Et il arrive que je sorte de l’épure, deux ou trois fois par an. Et alors, je ferme les yeux car je ne sais pas faire quoi d’autre (téléphoner à Sterling ?)

      Par ailleurs, les algorithmes et heuristiques utilisés pour passer de courant constat à tension constante comportent, selon les manuels lu entre les lignes, des notions telles que : durée fixée à 4 heure avant d’envisager la phase suivante, durée modulée par la tension au début de la phase et la pente de cette tension ... et bien d’autre choses encore.
      Ainsi avec un autre booster ou avec le chargeur de quai (victron centaur, analogique, sans µproc) il m’arrivait de mettre tous les goinfres en route au démarrage de la charge, histoire d’enfumer le chargeur et le pousser à pousser plus fort et plus longtemps.

      Mais avec des chargeurs modernes dont la tension de charge monte jusqu’à 15V

      Euh, ça dépend du réglage du chargeur, réglage qui doit refléter la techno de batterie utilisée. Il me semble que si vous voulez prendre la décision d’annoncer une fin de charge ou qqchose d’d’approchant vous devez être informé des tensions critiques et propres à ces batteries là, du genre 14,4V et 13,6 pour des OLA ... pour prendre une décision éduquée.

      Remarquez aussi, pour le moniteur victron (et l’autre aussi semble-t-il) des seuils à régler pour que ce dernier déclare un SOC de 100% quoiqu’il ait vu dans les minutes précédentes. Il y a eu une longue discussion sur ce problème dans un des fils sur PTP, discussion qui a abouti a un consensus dans cette communauté sur les valeurs à utiiser/configurer.
      C’est le paramètre It, dont la doc (page 15) dit

      It : Courant de pleine charge. Lorsque le courant de charge est
      inférieur à ce pourcentage de la capacité de la batterie (Cb), la
      batterie est considérée comme pleine. Veillez à toujours fixer ce
      paramètre au-dessus du courant minimal d’entretien de la batterie,
      ou de celui où le chargeur arrête la charge.

      C’est différent de SYNC.

      Personnellement je laisse le moniteur se faire son idée d’une charge complète (et il est bien réglé pour ça) mais je passe derrière lui et refais (de temps en temps) à la mano les intégrations de courant, histoire d’avoir l’esprit tranquille. De plus mes batteries sont OLA, du coup un coup de pèse-acide quelques fois par an est un juge de paix efficace.

      Répondre à ce message

    • Bonsoir,

      Le shunt « unique » est ,amha, peu ou pas influencé en fin de charge par les gros consommateurs car il est sur le moins au plus prés de la batterie et donc ,en charge,il ne « voit » pas les consommateurs si le courant « disponible » est supérieur .
      Au quai avec mon chargeur de 45 A, le XpertPro affiche le « Full » à 2% de C, sans faillir même si le frigo est allumé.

      En navigation ou au mouillage, la situation est bien différente (voilier), car je n’ai pas une « puissance de charge » suffisante pour couvrir la consommation,sauf dans les longues périodes (>4h) de navigation au moteur (rares).En général,si deux heures avant la nuit je suis vers 80%( des fois en dessous,mais alarme à 50%), une à deux heures de A2B me ramène au moins à 95% et ,bien sur, je n’ai pas de « full ».(alternateur de 95 A,ce qui donne un max de 60A avec le A2B et mesuré sur le xpert).

      Par contre, comme l’explique YvesD, il arrive que le moniteur indique « Full », alors que la tension est toujours à 14,4v( dans mon cas), ce qui indique que la phase « float » n’a pas commencé.Cela rentre dans l’ordre au bout d’un certain temps( 1/2 heure) avant de m’inquieter et de couper la charge( très rare).

      Donc,pour moi,le moniteur est essentiel pour suivre la consommation et décider les actions pour éviter la décharge « profonde »( mise en charge ou coupure des consommateurs). La fin de charge est peu utile, mais à suivre pour un éventuel problème de charge ou de batterie. Le seuil de 2% de C me convient,malgré le fait que la capacité diminue avec « l’age » de la batterie,mais ceci est une autre discussion....
      Sur le xpert, pour le soc, en plus du courant, la tension de float ainsi que la période de temps sont paramérables

      En fin, pour moi aussi, batteries ouvertes : un peu d’eau. et densité de temps en temps....

      Répondre à ce message

      • En fin, pour moi aussi, batteries ouvertes : un peu d’eau. et densité de temps en temps....

        Est-ce que tu “égalise” tes batteries à l’occasion, ta réponse m’intéresse puisque tu fais un usage plus soutenu de celles-ci en ne descendant pas rarement à 50%
        “égaliser” dans mon esprit consiste à brasser l’électrolyte des batteries pour lesquelles la densité devient stratifiée (plus dense au fond) avec le temps, ce qui est parait-il inéluctable et soignable. Rappel : L’égalisation consistant à soumettre les batteries à une (trop) forte tension pendant un temps donné (Sterling dit 16V pendant 4 heures, quelle intensité, je ne sais). Bien sur uniquement pour la techno “électrolyte liquide”

        Personnellement je ne le fais jamais et la prise de densité périodique ne montre jamais une strate supérieure moins dense que d’habitude, de plus mon vaisseau est très rouleur, ce qui doit pas mal brasser l’électrolyte. Je ne le fais jamais car il faudrait aussi, pendant ces 4 heures au moteur, soumettre l’ensemble de l’électronique et autres à un 16V potentiellement dévastateur

        Répondre à ce message

        • Merci pour vos retour d’expériences.
          J’ai lu avec intérêt le fil plus ancien cité par YvesD dans lequel vous avez d’ailleurs publié des graphes Excel dans lesquels on aperçoit le phénomène que je décrivais soit une charge à 100% (synchro) détectée en phase de bulk causée par un consommateur qui réduit ’artificiellement’ le courant absorbable par la batterie alors que la charge réelle est certainement inférieure à 85% (bulk).
          Si la charge se poursuit jusqu’à son terme, le SOC restera à 100% pendant celle-ci et l’erreur sera à peu près compensée. Mais si la charge est interrompue par arrêt du moteur par exemple puisque le moniteur affiche 100%, alors l’erreur devient importante car vous avez 15% d’autonomie ’réelle’ de moins que ce qui est affiché et vous pouvez descendre plus bas que prévu sans le vouloir, voire le savoir...

          Nous pensons intégrer dans les conditions de synchro, les données du Coulombmètre qui n’ont pas de raison d’être plus fantaisistes que le courant ou la tension. En reprenant les courbes de décharge / charge publiée par YvesD, on s’aperçoit qu’en intégrant la condition que les Ah entrés dans la batterie pendant la charge soient au moins égaux aux Ah sortis depuis la dernière charge complète, la synchro basée sur tension + courant + durée aurait eu lieu au bon moment (floating).

          Si le CEF est la capacité réelle (restituable) divisée par la la capacité nominale et reflète plus ou moins le vieillissement des batteries, il est nécessaire pour en faire un calcul de connaître la capacité restituable, donc d’avoir une charge à 100% fiable ou réelle et une décharge profonde jusqu’à un seuil de tension (réglable ?) pendant une durée (réglable ?). Ces conditions sont-elles souvent rencontrées dans la pratique ? Un CEF variable et éventuellement erroné ne va-t-il pas être plus perturbant qu’utile ?

          Répondre à ce message

          • Oui, sur le xpert, le total Ah chargés est supérieur au total consommés. Il est configuré en cef auto et ne me demande pas(ou trés peu) de sync manuelle.
            L’autonomie calculée est assez fiable, malgré les charges « incomplètes ».
            Depuis deux ans, j’ai 10% d’écart sur les AH avec 100 « sync » et 0 décharges à 50%( lu sur le moniteur).

            Dans mon programme de nav, le manque d’eau( pas de dessal) me fait rentrer au port au bout d’une semaine env.
            D’où la nécessité d’un moyen de charge en nav à la voile pour une période supérieure( hydro ou moteur...).

            en pratique, je reste « conscient » des charges incomplètes et je réduit les consommateurs( frigo et ensuite pilote).Depuis que j’ai séparé les batteries de servitudes, je n’ai plus de problèmes la nuit (10h d’autonomie avec le radar de temps en temps) et les panneaux sont ok pour le jour.

            Répondre à ce message

        • Non, je ne pratique pas l’égalisation...

          Je n’ai pas d’équipement permettant de le faire..Sur voilier qui navigue, cela bouge aussi pas mal.

          Ce que je fais :

          je vérifie les niveaux,car effectivement le A2B et le chargeur « chauffe » (>13,8V ) et ,surtout l’été dans le sud de la med, une fois par mois, je complète et je fais une charge complète au chargeur de quai.En général,la quantité d’eau ajoutée est faible.Je n’ai pas observé de forte variation de densité, sauf une fois,sur un élément qui à finit par se « court-circuiter »...

          Je pense que sur un bateau l’égalisation est peu utile, par contre sur une batterie de démarrage d’un groupe de sécurité oui !

          Une fois par an avant l’hiver, je fais une charge complète avec un chargeur à impulsions batteries isolées.

          Répondre à ce message

  • Nous sommes en phase de tests avec le contrôleur CPB (batteries). Je posterai prochainement quelques images...

    Je prépare le design d’une carte de monitoring moteur ’ancien’ et avant de démarrer j’aimerais votre opinion sur ses capacités de traitements :
    - 5 entrées analogiques (2 pressions huile, temp. huile, temp. eau, temp. échappement)
    - 5 entrées contacts (alarmes niveaux) interface à définir
    - 1 entrée shunt pour monitoring alternateur
    - 1 entrée fréquence (rotation pompe)
    - 1 entrée hygromètre/température - interface à définir
    - 1 sortie relais 10A pour commande ventilateur de cale
    - 1 sortie relais 1A pour alarme sonore locale

    L’affectation de chaque entrée pourra être redéfinie par l’utilisateur.
    Des seuils d’alarmes (haut/bas) pourront être définis pour chaque entrée variable.
    Le calcul du point de rosée sera fait par soft.
    Des conditions pourront être définies pour les relais ventilo et alarme

    Qu’en pensez-vous ?

    Répondre à ce message

    • Dans le lot d’entrée il y a sans doute celle qui me tient un peu à coeur : la température dans la cale moteur.
      Je vise une capture de la température réelle (plutôt qu’un Tout ou rien pour piloter une alarme), pour permettre au patron de la confronter avec les conditions ambiantes même si ça peut aussi déclencher une alarme pour réveiller le patron somnolant.

      Répondre à ce message

      • Je pensais intégrer le capteur de température de la cale sur la carte électronique pour limiter le coût et la place occupée par les borniers pour les connexions externes.
        Cela impose un montage de la carte dans la cale moteur et engendrera un peu de délai de réaction du capteur mais c’est peut-être un avantage plus qu’un inconvénient. Est-ce que c’est acceptable ?
        Comportant plusieurs liaisons analogiques à convertir, il est préférable que les câbles restent ’courts’ et les cheminements choisis et limités. Par contre, il ne faudrait pas que la carte électronique soit exposée à des température de plus de 50°C.
        Je vais voir si nous pouvons proposer des capteurs absolus avec un montage en cosse à œil comme le propose Sterling avec le AtoB.

        Répondre à ce message

        • Cela impose un montage de la carte dans la cale moteur et engendrera un peu de délai de réaction du capteur mais c’est peut-être un avantage plus qu’un inconvénient. Est-ce que c’est acceptable ?

          Le délai que vous évoquez sera, j’imagine, au pire de l’ordre de la dizaine de secondes, ce qui me parait très acceptable.
          Par contre, la restriction à 50 °C max sur cette carte me gène pas mal. Je la comprend (spec des composants) mais affirmer que ma cale moteur ne dépassera jamais 50 °C sauf à ruiner aussi les capteurs ou leur électronique ... C’est pour éviter de ruiner le moteur (ou réagir rapidement pour contrarier ce désastre) ou autres que je souhaite cette information, alors si dans la foulée on m’annonce que la carte d’électronique est ruinée ... Euh ...

          capteurs absolus avec un montage en cosse à œil comme le propose Sterling avec le AtoB

          De ce que j’ai vu et installé, c’est en fait une thermistance qui est fixée sur le NEG de la batterie et aussi sur le NEG de l’alternateur. Est-ce que ça vous pose une problème de convertir cette résistance en valeur numérique à quelques mètres de là ?

          Répondre à ce message

          • Concernant la température, il n’y a pas de risque de destruction de la carte électronique jusqu’à 70°C voire 85°C sans utiliser des composants spécifiques donc onéreux. Dans notre cas, la température va avoir une influence néfaste et incontrôlable sur la consommation, la précision des conversions analogiques / numériques et la fréquence des oscillateurs...
            Dans la mesure où la précision de la mesure n’est pas essentielle restant inférieure à 1 ou 2°C, la température de la carte peut monter jusqu’à 70°C impunément et les câbles peuvent s’allonger un peu.

            Le problème avec un capteur analogique est l’étalonnage ou sa calibration. Quant il s’agit de limiter le courant brutalement à la moitié de sa valeur si la température dépasse 55°C à 5° près, l’étalonnage est inutile mais pour obtenir une valeur juste, il faut calibrer le capteur soit en fabrication ce qui ajoute un coût soit à l’utilisation, ce qui impose à l’utilisateur de réaliser cette tâche pour chaque sonde mise en œuvre et d’avoir écrit le soft nécessaire et de disposer d’un référence correcte.

            De plus, un capteur analogique au bout d’un câble ’long’ est toujours une histoire de compromis. Si les signaux ou les variations sont faibles (10mV/°C), ils seront perturbés par le bruit récupéré par le câble (50mV à 100mV facilement). Pour s’en affranchir plus ou moins bien, on augmente les tensions donc les courants...

            Tout ceci conduit depuis longtemps à traiter ces faibles signaux le plus localement possible et à les transmettre sous une forme numérique qui résistera beaucoup mieux aux agressions liées à leur transport.

            Nous analysons une solution qui pourrait être intéressante sur le protocole 1-Wire développée à l’origine par Dallas rachetée maintenant par Maxim qui supporte plusieurs mètres de câble (Infos ici)

            Répondre à ce message

    • Lors de ma réponse à votre appel à commentaire j’ai oublié de mentionner un intérêt pour du comptage “brut” d’impulsion.

      • Ça peut servir à compter le nombre fois ou une pompe de cale s’est mise en route (très utile en période de désarmement)
      • Ça peut aussi servir à mesurer/totaliser les impulsions d’un capteur de débit, par ex pour mesurer plus précisément des consommations de carburant (gazole) et s’étonner tant qu’il est encore temps d’une augmentation significative de celle ci, ou aussi à déterminer un régime optimum (miles per gallon) bien utile sur des petits fifty (pour les gros il y a des fabricants spécifiques, trop onéreux et très élaboré, ma demande porte uniquement sur de la totalisation, les divisions et les moyennes, je sais faire à la main). Voir PJ

      Bien sur, le risque est élevé de tomber dans le baroque rococo et de rajouter encore un petit angelot en stuc par ci par là ... mais si ces préoccupations peuvent s’inscrire facilement dans votre projet.

      Répondre à ce message

      • L’entrée fréquencemètre/comptage est prévue pour ça. Nous verrons si une seconde peut être prévue pour le débitmètre carburant. Je retiens l’idée et vous remercie pour le lien sur ce produit qui me semble plus sérieux que beaucoup...

        J’avais prévu d’intégrer ce type d’entrée sur la carte de monitoring réservoir mais sur la carte ’moteur’, elle aurait tout à fait sa place.

        Pour le comptage des démarrages de pompes de cale, c’est fait par notre CPC !;-)

        Répondre à ce message

    • Orphelin de longue date du baromètre enregisteur, sur papier de caisse enregistreuse, Latitude, un module logiciel qui afficherai un historique d’une valeur sous forme de barre-graphe m’attire. Bien sur j’ai une préférence pour la pression mais la fonctionnalité est identique.

      Là encore le baroque rococo est en embuscade ;-)

      vous écrivez

      Le calcul du point de rosée sera fait par soft.

      Il y a quelques années j’ai acquis un datalogger Pression/Température/HumiditéRelative non livré avec le logiciel de calcul du point de rosé (à la différence du datalogger Lascar). J’ai donc passé pas mal de temps à me battre avec les unités dans les formules ad-hoc, un changement d’unité dans une fonction exponentielle ayant un impact allucinant. J’avais publié le bout de code excel sur ce site, ici

      Remarque : la pression intervient dans ce calcul mais il est courant, sinon exact, de prétendre que la pression est en permanence de 1013 HPa. Le code excel tient compte de la pression “exacte” (attention à la précision du capteur de pression , CEM c’est pas Vaisala)

      Répondre à ce message

  • 29 octobre 2015 09:27, par JLouis écrire     UP  image

    Malgré la taille réduite de l’écran, l’exploitation locale des données acquises reste possible.
    Pour les tests, nous martyrisons une batterie gel de 7Ah que nous avons totalement déchargée à C/3 environ puis rechargée bêtement (alim de labo)...

    PNG

    Répondre à ce message

  • 29 octobre 2015 09:30, par JLouis écrire     UP  image

    Avec en déplaçant le curseur et en zoomant...

    PNG

    Répondre à ce message

    • 29 octobre 2015 10:20, par yoruk écrire     UP     Ce message répond à ... Animateur

      Bonjour
      Je ne me souviens pas si le sujet a été abordé, mais, pour la couleur de visualisation des données du diagramme, évitez les couleurs à risque (essentiellement les verts et les rouges) pour les daltoniens... Merci d’avance pour eux

      Michel

      Répondre à ce message

      • 29 octobre 2015 10:26, par yoruk écrire     UP     Ce message répond à ... Animateur

        Les couleurs qui sont généralement lues par les daltoniens

        • noir
        • blanc
        • 2 nuances de gris (clair et foncé)
        • 2 nuances de jaune (idem)
        • 2 nuances de bleu (idem)

        Personnellement je vois bien les rouges s’il sont très vifs... Mais je ne suis pas certain que ce soit la cas de tous les daltoniens. Les roses (sauf le rose indien), les violets, tous les verts... C’est l’horreur

        Michel

        Répondre à ce message

        • 29 octobre 2015 12:29, par JLouis écrire     UP     Ce message répond à ...  image

          C’est par contre plus délicat avec les couleurs des icones...
          Sur l’exemple ci-dessous, comment percevez-vous la batterie et l’ampoule ?

          PNG

          Répondre à ce message

          • 29 octobre 2015 13:00, par yoruk écrire     UP     Ce message répond à ... Animateur

            Merci de prendre en compte nos handicaps !!!

            • Pour la batterie, aucun problème, je ne connais pas sa couleur, mais... je la vois, parce qu’elle est contrastée et vraisembablement mono couleur (c’est ce que je vois). Le problème vient généralement avec les camailleux ex : un feu qui se confond sur les enseignes lumineuses d’une ville en arrière plan
            • Pour l’ampoule, c’est simple, et c’est un réflex mémorisé :
              • Ampoule = feu
              • Feu = rouge à babord et vert à tribord
            • Elles sont suffisemment contrastées, pour être explicites (du moins pour moi)... Mais, c’est pas simple

            Il ne faut pas que ce handicap, vous pose trop de problème, mais souvent les développeurs l’ignorent, et çà peut devenir dangereux : deux courbes qui se croisent et... qui est qui ???

            L’exemple le plus célèbre de maltraitance des daltoniens, a été le passage du noir des balises lattérales au vert, dans les années 80... Ca fait hurler ma femme, que je suis obligée de réveiller pour confirmation : est-elle verte ou rouge ???

            Merci d’avance
            Michel

            JPEG

            Répondre à ce message

            • 29 octobre 2015 14:49, par JLouis écrire     UP     Ce message répond à ...  image

              C’est pour moi l’intérêt de travailler dans une petite entreprise et de partager cette phase du développement avec les utilisateurs avertis que vous êtes.
              D’une part, nous n’avons en interne ni la science infuse ni l’expérience que certains d’entre vous ont et d’autre part, nous avons une grande latitude pour faire évoluer les produits afin qu’ils s’approchent au mieux de l’objectif de qualité que nous nous fixons.
              Contrairement aux entreprises plus importantes dont les cahiers des charges sont figés bien avant que le développement ne commence, nous comptons sur l’originalité, la technicité et l’adéquation aux besoins des utilisateurs pour intéresser ceux-ci et améliorer notre cahier des charges en permanence.
              Merci à vous (tous) pour votre intérêt et vos critiques constructives.

              Répondre à ce message

      • 29 octobre 2015 11:53, par JLouis écrire     UP     Ce message répond à ...  image

        Merci pour cette remarque dont nous allons tenir compte.
        Concernant les graphes, nous pouvons prévoir une table de couleurs personnalisables. Comme ça chacun pourra l’adapter à ses besoins ou à ses goûts.
        Néanmoins sur cet exemple de graphe, le fait de cocher/décocher dans la liste de gauche fait apparaître/disparaître la courbe correspondante. Ca peut aider même si ça ne règle pas tout.

        Répondre à ce message

  • 23 août 2016 17:08, par JLouis écrire     UP  image

    Bonjour à vous,
    Tout d’abord, je présente mes excuses à ceux qui suivaient ce fil dont j’ai lâché le bout pendant trop longtemps. Les aléas du quotidien d’une PME nous ont obligé à mettre ce dossier en second plan un moment mais nous avons tout de même avancé un peu.

    Le système dans sa version actuelle sera présenté au salon à la Rochelle fin septembre dans une version pré-série opérationnelle qui peu servir aux beta-tests proposés.

    Toutes les cartes ont été revues une première fois mais il n’est pas exclu qu’elle le soit à nouveau pour améliorer la facilité de montage.

    Les modules CFN (contrôle des feux), CPB (contrôle batterie) et CPC (pompe de cale) sont opérationnels même si des améliorations soft restent à faire.

    Le module CCM (contrôle moteur) est fait mais le soft d’affichage reste à finir (sera fait pour la fin du mois de septembre) et le module CJR (jauge de réservoir) va être revu pour homogénéiser les composants utilisés et y intégrer 2 jauges et accessoires.

    Le terminal d’affichage est opérationnel et la carte de connexion va évoluer très prochainement en terme de connectique essentiellement mais celle qui est faite est opérationnelle.

    Dans les jours et semaines à venir, nous allons sortir les documentations techniques et commerciales qui seront distribuées au salon. Si vous souhaitez des invitations pour le grand Pavois, faites-moi signe..

    Répondre à ce message

    • 23 août 2016 18:03, par Jona écrire     UP     Ce message répond à ...  image

      Bonjour,

      Content d’avoir des nouvelles et que le projet continue......
      Une question qui me vient à l’esprit après la relecture du fil :
      Avez-vous prévu une interface numérique vers l’extérieur de votre système ?
      Sans parler tout de suite de N2K, connaissez-vous Signal K ( http://signalk.org/ ) ?
      Sur un module Wifi, ce serait une solution pour enregistrer les données.

      A bientot sur PTP ( pas de La Rochelle pour moi,cette année..)

      Gilles

      Répondre à ce message

      • A ce jour, le système est purement ’local’ mais les données sont enregistrées sur une carte µSD si celle-ci est présente évidemment.
        Dans un avenir proche, nous allons interfacer un modem GSM 3G pour transmettre des alarmes en SMS, mails et logger sur serveur distant.
        On pourra sur le même principe (module externe additionnel) ajouter une communication WiFi ou SigFox ou autre... tout bouge en ce moment.

        Répondre à ce message

Répondre à cet article

UP

Copyright et informations légales