Pratiques et Techniques de la Plaisance

Rubrique : OpenCPN -forum-

__________________________________________________________________________________________________________________

__________________________________________________________________________________________________________________

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

46 Messages de forum

__________________________________________________________________________________________________________________

• OPEN ET PILOTE RAYMARINE 18 octobre 2011 20:29, par Robert

  Voilà le bug est corrigé, on peut répondre au fil de nouveau ouvert.

  Répondre à ce message

• OPEN ET PILOTE RAYMARINE 18 octobre 2011 20:39, par yoruk

  Bonjour
  Normalement vous avez une sortie avec un N° de port vers le pilote dans l’onglet GPS de la boite à outil.
  Je ne suis pas spécialiste à ce niveau, mais il me semble que sans multiplexeur, les phrases NMEA de OpenCPN ne seront pas interprétées par l’interface seatalk de Raymarine
  Cordialement
  Michel

  Répondre à ce message

• OPEN ET PILOTE RAYMARINE 18 octobre 2011 22:00, par JPL

  Le SPX 30 reçoit les infos car j’ai les données wpt, la distance et le cap.
  Alors ????

  Répondre à ce message

  • OPEN ET PILOTE RAYMARINE 19 octobre 2011 05:45, par yoruk

    Le SPX 30 reçoit les infos car j’ai les données wpt, la distance et le cap. Alors ????

    Ou lisez vous l’affichage de ces donnés ???

    Répondre à ce message

    • OPEN ET PILOTE RAYMARINE 19 octobre 2011 07:59, par JPL

      Je lis les infos sur l’écran du St. 6000 :
      nom du wpt, distance pour l’atteindre, cap pour l’atteindre.
      Cela correspond aux info du dashbord.

      Répondre à ce message

      • OPEN ET PILOTE RAYMARINE 19 octobre 2011 10:21, par Robert

        Je n’y connais rien en Raymarine, cependant je peux faire un commentaire global.

        Sauf erreur le bus Seatalk est un bus parallèle (l’information est distribuée à tous les instruments sur le même fil) . Or vous lisez des informations (WP, distance, etc ...) sur l’un des éléments (St6000) qui a un écran de visualisation, ce qui ne prouve pas qu’elles arrivent sur l’autre élément qui n’a pas de visualisation (SXP30). Autrement dit, la visualisation ne prouve pas que toutes les information nécessaire au SXP30 sont présentes.

        On peut comprendre cela de plusieurs façon :

        • Le St6000 est plus tolérant que le SXP30 envers un défaut dans la qualité ou le contenu de l’information qui ne serait pas tout à fait conforme.

        • L’information de déclenchement (mise en marche) du pilote n’est pas incluse dans ce qui sort du PC et son absence ne se voit pas sur le ST6000.

        Répondre à ce message

• OPEN ET PILOTE RAYMARINE 19 octobre 2011 11:28, par JPL

  Sur le ST6000 la fonction track est peut être visualisée.
  Lorsque je l’active, j’ai le message no data.
  Le ST6000 est relié au spx30 qui reçoit les infos.

  Répondre à ce message

  • OPEN ET PILOTE RAYMARINE 19 octobre 2011 22:59, par Robert

    Il serait intéressant de savoir exactement dans quelles circonstances le message « no data » est affiché par Raymarine. En tout cas, à l’activation de « track » quelque chose est envoyé (vu le message d’erreur) mais visiblement pas la commande adéquate ou des phrases manquantes.

    Une sonde de lecture des phrases NMEA à la sortie du PC serait bienvenue ... Par exemple, brancher l’entrée RS232 d’un second PC sur la sortie du PC de commande et avec le logiciel « terminal » (par exemple) lire les phrases NMEA qui sortent au moment de l’envoi de la commande « track ».

    Répondre à ce message

    • OPEN ET PILOTE RAYMARINE 19 octobre 2011 23:25, par JPL

      Je ferais le test lorsque je serais à bord, actuellement à Paris et le bateau en Corse.
      Quel est ce logiciel : terminal et ou peut on le télécharger ?
      Ce qui m’intéresse surtout, c’est d’aller au fond des possibilités, l’exploitation de cette fonction sera à utiliser avec beaucoup de surveillance. Merci. JP

      Répondre à ce message

      • OPEN ET PILOTE RAYMARINE 20 octobre 2011 06:19, par Robert

        Oups, ce n’est pas « terminal » mais « Hyper terminal » qui est un utilitaire intégré dans Windows (du moins dans XP, dans W7 je ne sais pas).

        Répondre à ce message

      • OPEN ET PILOTE RAYMARINE 23 octobre 2011 02:29, par Robert

        A toutes fins utiles, voilà « hyperterminal » avec sa DLL qui marche sous XP et W7. Mettre les deux fichiers exe et dll dans un répertoire.

        Comme c’est prévu pour Telnet, à la mise en route il pose des questions liées au réseau téléphonique qu’on ignorera.

        Ensuite on indique le port COM qu’on veut tracer et on voit défiler tout ce qui sort de ce port COM.

        

        Répondre à ce message

  • OPEN ET PILOTE RAYMARINE 20 novembre 2011 00:35, par yvesD

    Le 19/10 JPL se lamentait d’arriver jamais à causer à son pilote raymarine

    J’ai eu un autohelm ST6000 (le vieux nom de raymarine), j’ai une petite idée là dessus (la bonne ?)

    J’avais un ST6000 avec les modules wind, depth et un course computer et je ne sais trop encore
    J’arrivai sans problème à récupérer, en NMEA, les données issues d’un module en me branchant à la prise ad-hoc de ce module là (2). J’ai même l’impression que je pouvais, en NMEA, causer à ce module.
    Mais ça n’est pour autant que j’avais accès au bus seatalk par lequel tous les modules causent entre eux.

    A mon avis il faut que le PC cause directement sur le seatalk, du coup tous les modules branchés sur le ST entendront ce que dit le PC et le module pilote recevra les ordres qu’il faut.

    Comment passer d’une prise RS232 à du Seatalk :

    • raymarine vendait ( 200€) un convertisseur ST <-> NMEA, c’est la solution que j’avais retenu en 2001
    • shupmodul vend un mux NMEA (j’avais ça en 2001) qui dans sa version 2010 que j’ai racheté cet été a un port capable d’ingérer et de causer en NMEA. C’est aussi un mux à 4 ports et un port USB auquel je raccorde le PC (avec une pseudo-tty sur le PC, un port COM virtuel) Je l’ai payé 230€ TTC directement en .NL via internet, je n’avais pas assez de sous poiur l’acheter en France (300 € HT).

    Pour obscurcir encore le tableau j’ajouterai que sur mon nouveau (qui a une très grosse masse métallique en guise de moteur) il y a un compas fluxgate loin du moteur raccordé à un module/afficheur compass ST50 et que le connecteur ST de ce module peut être utilisé aussi bien pour faire du SaTalk (normal) que du NMEA (étrange, juste une affaire de broche). Je l’ai raccordé au shipmodul en NMEA. Je peux fournir la doc (pas encore sur mon site du cata d’alors). La vieille doc du ST et ST <-> NMEA (le Z290) est dans http://www.devill.net/docs.html à la rubrique autohelm

    Enfin, pour ceux que ça intéresse, SeaTalk est un truc diaboliquement astucieux : c’est un vrai bus (comme ethernet) sur lequel plusieurs peuvent causer à la fois mais pour éviter les coûts élevés des chipset ethernet des fin 90 le concepteur s’est basé sur les chipset serial port (on dit USART) et la détection de collision (1) se fait en véirifant qu’un caractère asynchrone démarré par le premier parleuqui émet un bit de start se termine bien 10 à 11 temps plus tard par un stop qui retombe à zéro (stop = 1) au bon moment (11 temps car 1 temps pour le start qui est par ex un 0, 8 temps pour les 8 bits d’info et deux temps pour les deux bits de stop qui sont des 1). Si un autre brouille l’écoute pendant ces 9 premiers bit alors les bits de stop seront endommagés (soit ils ne seront pas 1 pendant les deux temps attendus, soit il ne termineront par une retombée à 0 après ces deux temps) et l’USART détectera un framing error qui vaudra détection de collision et il faudra recauser. La connexion électrique d’un causeur à ce bus se fait en RS432 ou 422 (me souviens plus bien), c’est à dire en différentiel, en courant et non en tension, on peut même au moins conceptuellement voir un transfo entre le parleur et le bus. Si ça intéresse je peux retrouver sur mes disques mes papiers d’alors, écris par un allemand.
    1 : en ethernet cable jaune (les jeunes peuvent pas connaitre, maintenant tout est en 10BAS10 ou pire, le jaune c’est le 50 ohm de Metcalfe au tout début 80) la détection de collision se faisait par mesure d’un niveau électrique car 2 causeurs simultanés « pullaient up » le bus à travers 2 résistances de charge et non une, ergo le niveau différent.
    2 : mes plans http://www.devill.net/InfosCatana/m... page 6 montrent que je piquast le NMEA sur le ST600 plus autopilot control unit. Possible également sur les E et S NMEA du course computer

    Répondre à ce message

    • OPEN ET PILOTE RAYMARINE 22 novembre 2011 11:26, par JPL

      Bonjour,
      Merci pour ta réponse.
      Voici le shéma du SPX 30 , le pc est connecté sur l’entrée/sortie NMEA par le biais d’un convertisseur série/usb
      les données venant du SPX ne sont pas reçues sur open cpn, je pense qu’il faut un multiplexeur type Brookhouse ?

      les données venant d’open cpn sont reçues par le spx 30 : cap, wpt, correction de cap, distance, et sont affichées sur l’écran du ST6000
      C’est en activant la fonction Track sur le ST6000 que j’ai : NO DATA
      Donc des phrases manquantes ou non lisibles par le ST6000.

      la continuité du câble est ok

      JP

      

      Répondre à ce message

• OPEN ET PILOTE RAYMARINE 22 février 01:16, par Coriolis

  Bonjour,

  Pour apporter de l’eau au moulin de ce « fil », je connais le problème de l’affichage sporadique « No data » sur le contrôleur de mon pilote ST6002 (calculateur SX5).
  Un autre problème vient d’apparaitre avec le passage de SeaClear à OpenCPN (V2.50) :
  Les phrases RMB et RMC transmises par SeaClear sur l’entrée NMEA du calculateur se trouvent correctement affichées sur l’écran du contrôleur (UTC, XTE, DTW etc).
  Les phrases similaires issues du même PC produites par OpenCPN ne semblent pas correctement interprétées par le calculateur, car l’affichage des données sur le contrôleur est vide...
  Le document joint contient les traces des sorties du PC pour les deux logiciels. Seules des différences mineures de format ou nombre de décimales apparaissent dans chacune des phrases. Cela peut-il rendre ces phrases inintelligibles ? Si oui, les développeurs d’OpenCPN peuvent-ils les rendre compatibles ?
  C’est une grande frustration de ne pouvoir utiliser les routes d’OpenCPN avec mon pilote.

  

  Répondre à ce message

  • OPEN ET PILOTE RAYMARINE 22 février 06:31, par yoruk

    Bonjour,
    Faute d’expertise technique sur les phases NMEA, ou les procédures d’échange Seatalk avec le pilote, juste une petite observation : nous sommes toujours refusé dans notre approche du tutoriel OpenCPN, en français, à traiter de l’automatisation de traitement des données du pilote…
    Nous estimons, qu’il faut sortir le nez dehors, pour assurer la route du bateau. A ce titre, tout assujettissement à un automatisme susceptible d’abaisser le degré de lucidité du skipper, nous semble préjudiciable. Nous raisonnons de la même façon avec l’AIS, il ne faut pas que l’information supplémentaire, apportée, tue la sécurité, en scotchant le nez du navigateur sur un écran.
    Asservir le pilote à une girouette, suivre le vent et non pas régler les voiles en permanence offre des avantages. Nous les avons testés (avec un Raymarine et seatalk, justement), mais… est-ce un gros problème que de relever un écart de trace, par rapport à une route de sécurité pré établie, et de corriger manuellement le pilote, ‘’dans le cockpit’’ les quelques degrés d’écart constatés sur OpenCPN, à la table à carte ??? Non, bien sûr, c’est facile et çà entretient l’esprit critique… en sortant le nez dehors, justement !!!
    Voilà, pourquoi, nous avons si peu d’expertise à ce niveau… ceci n’empêche nullement d’argumenter sur les avantages respectifs du Seatalk et du NMEA… personnellement, pour avoir tâté des deux, ma religion est faite : le démoniaque Seatalk l’emporte largement, très facile à connecter… mais çà a un prix… et çà sort du mode associatif en vogue chez les fondus Open Source de OpenCPN…
    Maintenant, si l’un d’entre vous peut nous traiter dans l’esprit du tutoriel (faire simple, et pédagogique), ce problème d’automatisme, merci d’avance, il est le bienvenu !!!!
    Michel

    Répondre à ce message

    • OPEN ET PILOTE RAYMARINE 22 février 10:09, par Robert

      Hummmm .... l’évidence que l’observation visuelle humaine doit être le premier critère qui guide le navigateur n’excuse pas un éventuel bogue dans OpenCPN dans la lecture des informations du pilote automatique

      En observant les phrases transmises par Coriolis je suis perplexe en regardant les 2 caractères préfixe envoyés par SeaClear et OpenCPN

      • Sortie SeaClear :
        $SCRMB,A,0.007,R,01-,02-,4339.358,N,00710.835,E,5.32,171.4,-0.0,V*0A ...
        $GPRMC,175939,A,4344.619,N,00709.738,E,000.0,360.0,210212,001.0,W*69...

      • Sortie OpenCPN :
        $ECRMB,A,0.011,L,001,002,4339.490,N,00710.953,E,5.197,170.275,0.000,V*11...
        $ECRMC,173339,A,4344.613,N,00709.739,E,0.000,360.000,210212,1.000,W*7F...

      Serait-ce une question de préfixes ? Je viens de vérifier que le « checksum » est correct.

      En tout cas, ça devrait interpeler OpenCPN. Le plus efficace serait de déposer une question au bon endroit : http://opencpn.org/ocpn/flyspray/

      Un résumé NMEA : http://vancouver-webpages.com/peter...

      Répondre à ce message

      • OPEN ET PILOTE RAYMARINE 22 février 10:26, par yoruk

        Hummmmm.... tu le fais Robert ???

        Répondre à ce message

    • OPEN ET PILOTE RAYMARINE 22 février 13:07, par Coriolis

      Bonjour,

      Je dois d’abord vous faire part de mon énooorme étonnement de voir la réactivité de la communauté PTP.. Bravo !
      Je ne ferai que répondre à la légitime remarque selon laquelle « tout assujettissement à un automatisme susceptible d’abaisser le degré de lucidité du skipper, nous semble préjudiciable ». Je ne peux qu’abonder dans le sens de la responsabilisation de l’homme sur la machine. Toutefois les outils puissants auxquels ce fil se rapporte peuvent être utilisés... encore faut-il qu’ils apportent l’information là ou elle peut être le mieux « critiquée », c’est à dire dans le cockpit, à la barre. En effet, même s’il peut être tentant de confier la tenue de la route au pilote (le mode track à l’origine de ce fil), c’est une autre approche que de vouloir disposer, près de la barre, des informations de relèvement du prochain WP , de l’écart de route actuel etc. ce qui était le cas avec la sortie SeaClear et ne l’est plus avec OpenCPN.

      Répondre à ce message

      • OPEN ET PILOTE RAYMARINE 22 février 13:15, par yoruk

        Bonjour... Bah... ce sont des habitudes de navigation... peut être liées au fait que navigant la plus part du temps en solo, la séparation des tâches me convient : en fait, j’ai deux équipiers : ST 6002 et OpenCPN... chacun à sa place !!! Bon... c’est mon style
        Maintenant que OpenCPN n’arrive pas à réaliser que Sea Clear fait... Cà agace...Faudra peut être voir pourquoi... ce qui renvoie à l’observation de Robert !!!

        Répondre à ce message

  • OPEN ET PILOTE RAYMARINE 22 février 11:16, par Robert

    A propos de signalement de bogue OpenCPN dans leur « flyspray » : http://opencpn.org/ocpn/flyspray/

    Je l’ai déjà fait et peux le refaire bien entendu. Cependant, dans le dialogue qui va s’instaurer il y aura des questions auxquelles je ne pourrai pas répondre car je ne connais pas les détails des essais. L’idéal serait que Coriolis fasse le dépôt directement si le problème de langue n’est pas un frein trop important.

    Répondre à ce message

    • OPEN ET PILOTE RAYMARINE 22 février 11:54, par yoruk

      S’il le peut ce serait parfait.. Encore mieux, s’il peut le faire en laissant la référence de PTP... ce serait un plus pour notre communauté.
      Par ailleurs, si quelqu’un ayant les connaissances techniques suffisantes pour traiter un dossier tutoriel sur le transfert des données NMEA entre le pilote et OpenCPN, je veux bien m’investir là dessus (çà fera un petit peu d’expertise en plus...)
      Michel

      Répondre à ce message

      • OPEN ET PILOTE RAYMARINE 22 février 12:07, par JPL

        Bonjour,
        J’ai acheté un boitier Raymarine E85001 qui convertit le seatalk en NMEA.

        http://www.raymarine.com/ProductDet...

        Cela devrait me permettre d’interfacer la centrale SPX 30, le pilote et opencpn.
        Je ne l’ai pas encore installé, donc à suivre.
        JP

        Répondre à ce message

        • OPEN ET PILOTE RAYMARINE 22 février 13:40, par Coriolis

          Bonjour,

          J’ai développé autour d’un microprocesseur PIC un programme qui reprend les informations de girouette, anémomètre, sondeur et compas fluxgate du bus SeaTalk de Raymarine à 4800bps, les convertit dans leur équivalent NMEA (MWV, DBT et HDM) et les multiplexe avec la sortie NMEA du GPS (Garmin GPS 152) à 38400bps vers le PC sur lequel tourne OpenCPN (ou SeaClear). Ca marche plutôt bien dans les deux environnements.
          Le problème existe seulement pour le « retour » des logiciels vers la centrale du pilote. Ce retour se fait par l’intermédiaire des deux phrases NMEA : RMB et RMC.
          Pour ce qui est des en-têtes :
          SeaClear génère le RMB avec un en-tête paramétrable dans la configuration du programme ($SCRMB) et simple passage (passthru) de la phrase RMC en provenance du GPS ($GPRMC)
          OpenCPN génère les deux phrases avec l’en-tête $ECxxx : Electronic Chart Display Information System (ECDIS).

          Répondre à ce message

          • OPEN ET PILOTE RAYMARINE 22 février 16:18, par Robert

            Deux idées :

            • puisque l’entête est paramétrable avec Seaclear, cela vaut le coup de voir si avec SeaClear ça fonctionne en mettant la même entête « EC » que celle utilisée par OpenCPN ? Des fois que la tête de l’entête ne plait pas au récepteur ?

            • Autre essai : envoyer sur le port « com » un fichier de texte contenant des phrases NMEA qu’on peut alors varier à l’infini « à la main » pour trouver le point de blocage que le récepteur ne comprend pas ?

            On a eu un problème tordu du même genre avec OpenCPN et les fichiers GPX contenant des URL amputées (utilisées intensivement par tout le Web) qui remplacent illégalement le "&" par un simple « & » ...

            Répondre à ce message

            • OPEN ET PILOTE RAYMARINE outil pour causer NMEA 22 février 17:09, par yvesD

              J’avais trouvé, à l’poque du début de ce fil, un outil qui même dans sa version « démo » permettait de causer NMEA. L’utilisateur fabriquait la phrase à tester et l’outil calculait le checksum (le plus pénible)
              J’avais trouvé ça en cherchant sur gogol sans doute en charchant « nmea talker »
              Pour convertir de Seatrlak en NMEA j’utilise la version 2011 du shipmodul USB, moins chez que le module de raymarine que j’avais acheté vers 2002 pour le cata.

              Répondre à ce message

              • OPEN ET PILOTE RAYMARINE outil pour causer NMEA 22 février 17:21, par yoruk

                Peut-être et avant que je n’y mette un peu une nécessaire simplification :

                • http://www.eauxturquoises.fr/a_tuto...
                • http://www.eauxturquoises.fr/a_tuto...

                Michel

                Répondre à ce message

              • OPEN ET PILOTE RAYMARINE outil pour causer NMEA 22 février 18:07, par yvesD

                J’ai retrouvé, c’était l’outil de sailsoft.nl, dans sa version démo
                page de manuel du générateur de phrase ici
                possibilité de conserver les phrases dans un fichier et/ou de les envoyer en rafale.
                Vu le prix il est pas mal.

                Répondre à ce message

            • OPEN ET PILOTE RAYMARINE : checksum 22 février 17:35, par Robert

              Pour faire des phrases d’essai, le petit programme « checksum » que je viens de bricoler cet après midi pour vérifier !

              

              Répondre à ce message

              • OPEN ET PILOTE RAYMARINE : checksum 22 février 17:35, par Robert

                Et la démo ...

                

                Répondre à ce message

              • OPEN ET PILOTE RAYMARINE : checksum 22 février 17:45, par Robert

                Pour ceux qui n’ont pas les bonnes librairies, la version installable.

                

                Répondre à ce message

            • OPEN ET PILOTE RAYMARINE 22 février 20:27, par Coriolis

              OK, la modification de l’en-tête par SC est une bonne idée, mais ne pourra s’appliquer que sur la trame « générée », c’est à dire RMB. J’essaierai cela dès que j’irai au bateau, mon banc de test local n’inclut pas le SX5...
              Je vais également préparer un jeu de phrases RMC + RMB que j’enverrai directement du port vers le pilote, histoire de voir si on peut trouver où ça coince.
              Merci pour les idées d’investigation.

              Répondre à ce message

    • OPEN ET PILOTE RAYMARINE 22 février 13:13, par Coriolis

      Bonjour,

      Je vais essayer de poser le problème comme demandé.
      Pour la référence PTP, je ne sais trop comment l’intégrer, sauf à simplement citer le site communautaire...

      Répondre à ce message

      • OPEN ET PILOTE RAYMARINE 22 février 13:17, par yoruk

        Merci, sauf si Robert est d’avis contraire, mais une citation, pour mémoire... ne nuirait pas...
        Michel

        Répondre à ce message

      • OPEN ET PILOTE RAYMARINE 22 février 13:35, par Robert

        Les contributions sur Flyspray sont de préférence très courtes, très précises et factuelles : quand je fais ceci, il se passe cela qui me semble anormal. Donc la citation des deux flux SeaClear et OpenCPN, agrémenté de la vérification du checksum avec le résultat négatif pour OpenCPN semble contenir l’information. En donnant tous les détails de l’installation logicielle, version OpenCPN, Windows, bus de réception, etc ... Les anglo-saxons sont le plus souvent concis et sans fioritures

        Répondre à ce message

        • OPEN ET PILOTE RAYMARINE 22 février 15:58, par Coriolis

          Bonjour,

          C’est fait... FS#735 dans le projet OpenCPN stable 2.50
          Merci

          Répondre à ce message

          • OPEN ET PILOTE RAYMARINE 24 février 23:41, par Coriolis

            Bonjour,

            Je rentre du bateau où j’ai pu identifier la différence de comportement pour les informations de pilote (phrases RMB et RMC) avec SeaClear et OpenCPN, le premier fonctionnel, le second non.

            Contrairement à ma première suspicion, le problème n’a rien à voir avec le contenu des trames : envoyées directement sur l’entrée NMEA du SX5 elles sont bien interprétées dans les deux cas... C’est un problème de communication.

            Sur le PC de la maison, avec lequel j’ai relevé les phrases NMEA issues des deux logiciels, j’ai un VRAI port série RS232.
            Le portable utilisé au bateau n’a pas de port série et, comme beaucoup, j’ai recours à un convertisseur USB <->Série à deux ports (un pour le GPS et le pilote, l’autre pour l’AIS). C’est là le problème... Dans le sens de la réception, tout est bien initialisé au démarrage et le PC reçoit bien les données GPS et AIS.

            En revanche, le flux sortant ne peut être démarrée qu’APRES l’activation d’une route.
            La différence entre SC et OCPN est qu’après avoir activé la route, RIEN ne sort du convertisseur USB-série avec OCPN.
            Avec SeaClear, après avoir activé la route, il est nécessaire d’activer la sortie NMEA (Sortie NMEA OFF par défaut) , ce qui a probablement pour effet d’initialiser (ou ré-initialiser) le convertisseur.

            Fort de cette « découverte », j’ai tenté de ré-initialiser « à la main » la transmission du convertisseur dans OCPN :
             activation de la route : rien ne sort.
             ouverture de la boîte à outils, désactivation du port du pilote (None), et validation par OK : évidemment jusqu’ici, aucun changement.
             ouverture de la boite à outils, changement du port du pilote (Com1) et validation : les données de route sortent du convertisseur et sont immédiatement affichées sur la console du pilote.

            Pour confirmer la reproductibilité du problème et de la solution palliative décrite ci-dessus, j’ai fait cette manip à plusieurs reprises avec chaque fois les mêmes résultats...

            Serait-il envisageable que cette « séquence » (ou un équivalent fonctionnel) soit implémentée lors de l’activation d’une route dans le programme lui-même ?

            Répondre à ce message

            • OPEN ET PILOTE RAYMARINE 25 février 08:18, par yoruk

              Bonjour et merci
              Quel type de convertisseur USB/RS232 utilisez vous ???
              On a un problème qui ressemble à ce que vous décrivez avec les remontées de WP depuis OpenCPN vers le GPS..
              Michel

              Répondre à ce message

              • OPEN ET PILOTE RAYMARINE 12 mars 20:19, par Coriolis

                Bonjour,

                Désolé pour le délai...
                Le problème soulevé existe que j’utilise un convertisseur USB-RS232 à base de chip FTDI FT232 ou un convertisseur USB-2xRS232 à base de chip Moschip MCS7720.
                J’ai profité du monitoring du port série (TX) pour tester la remontée de WP (dans le vide) et n’ai trouvé aucun problème. Ceci est probablement du au fait que la transmission est initiée « sur commande », un peu comme le contournement que j’ai trouvé pour le pilote.

                Répondre à ce message

            • OPEN ET PILOTE RAYMARINE 25 février 12:14, par Robert

              « Serait-il envisageable que cette « séquence » (ou un équivalent fonctionnel) soit implémentée lors de l’activation d’une route dans le programme lui-même ? »

              Cela vaut la peine de compléter l’information à la suite de votre intervention sur « Flyspray » dans OpenCPN, afin de donner au concepteur le maximum d’informations pour qu’il puisse décider de la suite à donner.

              On sait que les liaisons USB-NMEA et le multiplexage NMEA conduisent parfois à des comportements bizarres. Si vous le souhaitez, ce serait utile de décrire cette expérience en la détaillant dans un article ici sur le site que l’on mettra en position dans les bonnes rubriques ?

              (voir p.ex. http://www.plaisance-pratique.com/l...)

              Répondre à ce message

            • OPEN ET PILOTE RAYMARINE : windows et les COM virtuels 25 février 13:13, par yvesD

              ouverture de la boîte à outils, désactivation du port du pilote (None), et validation par OK : évidemment jusqu’ici, aucun changement.
              ouverture de la boite à outils, changement du port du pilote (Com1) et validation : les données de route sortent du convertisseur et sont immédiatement affichées sur la console du pilote.

              Dans le cas présent, en secouant très fort le « matériel » COM vous redémarrez quelquechose.

              C’est la grosse difficulté que j’ai constaté depuis plus de 10 ans avec les convertisseurs USB-série et windows XP : il arrive que ça tombe en marche, parfois même tellement souvent qu’on en arrive à penser que le problème a été résolu par le dernier patch, et puis un jour, dans tel scénario, pfuit, plus rien ...

              Il faut noter que c’est très rarement un vrai problème de matériel dans la mesure ou il n’y a que deux ou trois puces (== fondeur de silicium) distinctes, et donc deux ou trois driver réellement distincts, dans le monde faisant cette conversion, tout le reste n’est que variation d’emballage (les forum du monde linux en disent plus sur ce sujet des drivers et des fondeurs).

              Mais quand on rentre dans l’interface gestionnaire de périphérique on constate, par exemple, une telle multiplication des ports COM (driver re-installé dynamiquement à chaque fois qu’on reboote, ou pire, qu’on rebranche le cordon USB) qu’on ne sais plus trop bien quel nouveau n° de port COM renseigner à nouveau dans l’application, et comment virer les trop nombreuses instances de port COM qui sont désséchées.

              Conclusion : Si par mégarde vous trouvez une méthode qui marche, retenez bien les stances et faites un bakcupdu système pour pouvoir redémarrez sur des bases stables (sic !) lorsque tout dégénérera, et mémorisez/conservez bien les outils de monitor qui vous ont permis de retrouver la lumière.

              Répondre à ce message

              • OPEN ET PILOTE RAYMARINE : windows et les COM virtuels 26 février 13:01, par Coriolis

                100% d’accord avec vous sur la piètre « maintenance » des ports Com opérée par Windows.
                Il n’en reste pas moins que les convertisseurs sont le seul moyen de continuer à utiliser facilement la liaison série, pour le NMEA 183, en ce qui nous concerne ici. Il faut donc en passer par là...
                Force cependant est de constater que le logiciel SeaClear arrive TOUJOURS à activer la transmission au travers du convertisseur alors que le « protocole » d’activation du port de sortie utilisé par OpenCPN ne fonctionne que s’il s’agit d’un VRAI port série, mais pas dans le cas d’un convertisseur, sauf à secouer très fort le matériel, comme vous le dites, pour le « faire tomber en marche ».
                Il me semble que mon expérience devrait donner une piste aux développeurs, à moins que ma naïveté candide ne me pousse à imaginer qu’il suffit de reproduire, dans le programme, les actions expérimentées « de l’extérieur » (désactivation-réactivation) pour obtenir le même résultat.

                Répondre à ce message

                • OPEN ET PILOTE RAYMARINE : windows et les COM virtuels 26 février 13:19, par Robert

                  J’imagine qu’une manip à faire serait de tester le même problème sur un PC fonctionnant sous Linux pour être sûr que c’est bien un problème spécifique à Windows.

                  Pour le cas de Windows, il faudrait (sur le PC ayant un vrai port com) enregistrer dans un fichier la totalité de la séquence produite par SC et la totalité de celle produite par OCPN. En pratique cela se fait en branchant le port com d’un second PC sur le port Com du PC de navigation, et avec le logiciel « Hyperterminal » fourni avec Windows sur le second PC.

                  Avec un peu de chance, on pourrait alors localiser ce qui manque dans la séquence OCPN pour initialiser le port com dans toutes les situations.

                  Sans cette indication précise, je crains que le(s) développeur(s) d’OCPN ne puisse pas régler le problème car ils auront peut-être d’autres priorités nécessitant moins d’investigation propres à Windows..

                  Répondre à ce message

                  • OPEN ET PILOTE RAYMARINE : windows et les COM virtuels 12 mars 20:11, par Coriolis

                    Après bien du tracas, j’ai enfin fini par installer Ubuntu 11.10...
                    Le jeu en valait la chandelle : sous Linux, ça fonctionne sans problème...
                    Le « monitoring » du port série n’apporte rien de plus par rapport à mon premier message, si ce n’est une séquence d’initialisation au démarrage de Linux et aucune au démarrage de Windows (dualboot), mais ceci n’a rien à voir avec OpenCPN...
                    Une erreur de manip m’a apporté une info supplémentaire : en oubliant de mettre le GPS sous tenson, la sortie Pilote (TX) s’est mise à fonctionner... Avec le GPS sous tension le problème est confirmé.
                    Bien que le mode de fonctionnement « sans GPS » ne présente qu’un intérêt très limité, il précise les conditions de dysfonctionnement : (Windows) ET (utilisation d’un convertisseur série-USB) ET (le GPS et le Pilote sur le même port).

                    PS :Pour la question concernant une possible identité avec la remontée des WP vers un GPS, j’ai profité du « monitoring » du TX du port pour faire un test et, dans mon environnement, pas de problème. Mon interprétation est qu’on ne démarre le port TX que SUR COMMANDE, un peu le même comportement que le contournement que j’ai trouvé,

                    Répondre à ce message

                    • OPEN ET PILOTE RAYMARINE : windows et les COM virtuels 12 mars 20:19, par yoruk

                      Ho que çà m’intéresse (pour les remontées WP -> GPS)
                      Vous dites qu’en lançant OpenCPN sans que le GPS soit initialisé, permettrait le fonctionnement du TX à l’ouverture du GPS... J’ai bien compris ???
                      Michel

                      Répondre à ce message

                      • OPEN ET PILOTE RAYMARINE : windows et les COM virtuels 25 avril 17:21, par Coriolis

                        Désolé pour le manque de réactivité du à une absence prolongée...
                        J’ai peur que l’explication de ma fausse manip n’ait été mal interprétée (donc mal décrite), je précise donc :
                        1- lorsque j’ai omis de mettre le GPS sous tension le convertisseur a bien sorti sur le TX la phrase RMB dès que j’ai activé une route. Il est évident que ce mode “sans GPS” présente un intérêt réel très limité...
                        2- ce que j’ai voulu dire ensuite est la confirmation que si le GPS est actif à l’ouverture d’OpenCPN (données sur l’entrée RX) ET le même port utilisé pour le pilote (sortie TX), le problème d’absence de sortie demeure.
                        3- je n’ai pas vérifié la “persistance” de sortie en allumant le GPS APRES avoir activé la route.
                        4- je confirme que la condition “GPS activé” (et fournissant la position) n’a pas empêché la sortie de données destinées au GPS sur le même port (commande “Envoyer au GPS”). Je n’ai cependant pas vérifié la validité de ces données (non utilisées dans mon cas).
                        J’espère que cette fois ci c’est plus clair...
                        PS : sur le tracker d’OpenCPN, Marco (au départ très dubitatif) a pu reproduire le dysfonctionnement original.

                        Répondre à ce message

• OPEN ET PILOTE RAYMARINE 10 mars 08:11, par JPL

  L’installation du boitier Raymarine E85001 ne m’a rien donné de plus.
  JP

  Répondre à ce message

Répondre à cet article