image
image
image

Votre IP : 3.238.180.255
Dernier ajout : 24 mai
Visiteurs connectés : 10

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 > OpenCPN -forum- > Matériel connecté et microordinateur -forum- > OPEN ET PILOTE RAYMARINE

Rubrique : Matériel connecté et microordinateur -forum-

__________________________________________________________________________________________________________________

OPEN ET PILOTE RAYMARINEVersion imprimable de cet article Version imprimable

Publié Octobre 2011, (màj Octobre 2011) par : Nevermind   

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,
Comment activer la fonction track sur le pilote ?

Configuration :

pilote Raymarine st 6000 avec SPX30
les sorties entrées NMEA du SPX 30 sont connectées au pc
dans la configuration d’open, le port est bien identifié et actf
en activant la route, sur l’écran ST 6000, je reçois les WP avec leurs noms, la distance, le cap corrigé pour atteindre le WP

Donc la liaison pc vers pilote fonctionne correctement.
Je ne parle pas de la liaison pilote vers pc, il me faudrait un multiplexeur pour recevoir les données du SPX 30

Mais lorsque j’active la fonction track sur le pilote, après les bips bips, j’ai l’information : no data, donc le pilote ne reçoit pas les données d’open alors qu’il pourrait les recevoir à partir d’un traceur, c’est ce qui est indiqué sur la notice du pilote.

En clair, je voudrais asservir le pilote à la route faite sur open cpn.

Est ce que quelqu’un a déjà utilisé cette configuration ?
Parmi les spécialistes d’open, est ce que l’un de vous à la réponse ?

Merci pour vos réponses. JP

UP


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

49 Messages de forum

__________________________________________________________________________________________________________________

__________________________________________________________________________________________________________________

  • 18 octobre 2011 20:29, par Pil-Poil écrire     UP

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

    Répondre à ce message

  • 18 octobre 2011 20:39, par yoruk écrire     UP Animateur

    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

  • 18 octobre 2011 22:00, par Nevermind écrire     UP

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

    Répondre à ce message

    • 19 octobre 2011 05:45, par yoruk écrire     UP     Ce message répond à ... Animateur

      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

      • 19 octobre 2011 07:59, par Nevermind écrire     UP     Ce message répond à ...

        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

        • 19 octobre 2011 10:21, par Pil-Poil écrire     UP     Ce message répond à ...

          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

  • 19 octobre 2011 11:28, par Nevermind écrire     UP

    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

    • 19 octobre 2011 22:59, par Pil-Poil écrire     UP     Ce message répond à ...

      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

      • 19 octobre 2011 23:25, par Nevermind écrire     UP     Ce message répond à ...

        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

    • 20 novembre 2011 00:35, par yvesD écrire     UP     Ce message répond à ... Animateur

      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

      • 22 novembre 2011 11:26, par Nevermind écrire     UP     Ce message répond à ...

        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

        JPEG

        Répondre à ce message

  • 22 février 2012 01:16, par Coriolis écrire     UP  image

    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

    • 22 février 2012 06:31, par yoruk écrire     UP     Ce message répond à ... Animateur

      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

      • 22 février 2012 10:09, par Pil-Poil écrire     UP     Ce message répond à ...

        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 :-P

        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

      • 22 février 2012 13:07, par Coriolis écrire     UP     Ce message répond à ...  image

        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

        • 22 février 2012 13:15, par yoruk écrire     UP     Ce message répond à ... Animateur

          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

    • 22 février 2012 11:16, par Pil-Poil écrire     UP     Ce message répond à ...

      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

      • 22 février 2012 11:54, par yoruk écrire     UP     Ce message répond à ... Animateur

        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

      • 22 février 2012 13:13, par Coriolis écrire     UP     Ce message répond à ...  image

        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

        • 22 février 2012 13:17, par yoruk écrire     UP     Ce message répond à ... Animateur

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

          Répondre à ce message

        • 22 février 2012 13:35, par Pil-Poil écrire     UP     Ce message répond à ...

          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

          • 22 février 2012 15:58, par Coriolis écrire     UP     Ce message répond à ...  image

            Bonjour,

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

            Répondre à ce message

            • 24 février 2012 23:41, par Coriolis écrire     UP     Ce message répond à ...  image

              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

              • 25 février 2012 08:18, par yoruk écrire     UP     Ce message répond à ... Animateur

                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

                • 12 mars 2012 20:19, par Coriolis écrire     UP     Ce message répond à ...  image

                  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

              • 25 février 2012 12:14, par Pil-Poil écrire     UP     Ce message répond à ...

                « 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

              • 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

                • 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

                  • 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

                    • 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

                      • 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

                        • 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

  • 10 mars 2012 08:11, par Nevermind écrire     UP

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

    Répondre à ce message

  • 15 décembre 2012 18:20, par Nevermind écrire     UP

    Et bien voilà, avec la version OPENCPN 3.2.1206, en rajoutant quelques phrases on peut contrôler le pilote à partir du PC
    JP

    Répondre à ce message

    • 25 décembre 2012 12:29, par BABIG GLAZ écrire     UP     Ce message répond à ...  image

      Salut JP

      Merci pour cette information,( Et bien voilà, avec la version OPENCPN 3.2.1206, en rajoutant quelques phrases on peut contrôler le pilote à partir du PC JP), mais comment fait-on pour« rajouter quelques phrases »......

      Je viens de monter un spx30, et je n’arrive pas a avoir la fonction TRACK par le PC...

      sur le ST6002 s’afiche NO DATA

      Le branchement est bon car sur maxsea ça marche

      Le port de sortie pilote est bien renseigné dans « GPS »....

      Répondre à ce message

      • 25 décembre 2012 13:59, par Nevermind écrire     UP     Ce message répond à ...

        Bonjour,
        Il faut suivre exactement l’article publié matériel et branchements :

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

        Pour rajouter les phrases, regarder les photos jointes et le descriptif.
        Rajouter les phrases qui sont sur les photos et en majuscules.

        Connecter le SPX 30 avec l’interface et le PC suivant les schémas.

        Créer un route sur opnecpn
        Activer la route

        Sur le ST 6002
        activer le pilote
        appuyer sur track
        ensuite appuyer une seconde fois sur track

        Voir les photos de l’article

        le bateau suivra le cap indiqué sur la cartographie opencpn
        Si on change de relèvement, le bateau changera de cap aussi.
        JP

        Répondre à ce message

Répondre à cet article

UP

Copyright et informations légales