image
image
image

Votre IP : 54.226.226.30
Dernier ajout : 28 mars
Visiteurs connectés : 15

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- > Linux, Mac OS, etc ... -forum- > pas de position sur la carte affichée si connexion série ou gpsd

Rubrique : Linux, Mac OS, etc ... -forum-

__________________________________________________________________________________________________________________

pas de position sur la carte affichée si connexion série ou gpsdVersion imprimable de cet article Version imprimable

Publié Novembre 2021, (màj Novembre 2021) par : Fata Morgana  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 à tous,
J’ai un rpi3b+ avec openplotter (2.7 ?), opencpn(5.2.4) sur le quel je suis parvenu à faire fonctionner un gps bluetooth par une liaison série et la fonction rfcomm. c’est principalement ce que j’utilise à la maison.
Sur le bateau je voudrais utiliser mon gps mlr relié en usb au rpi avec un convertisseur RS422/USB.
Avec l’aide de posts et video trouvés sur le forum (PTP, auteur fulup merci à lui) et la doc opencpn.shoreline.fr, je n’ai toujours pas réussi à reporter ma position gps sur la carte de opencpn.
J’ai essayé en créant des connexions série, en passant en gpsd. en utilisant signalK. Rien sur la carte alors que par exemple quand je suis en connexion série je vois bien les trames du gps quand je demande leur affichage.
J’ai remarqué que gpsd était actif au boot et ,d’après la doc, exclut les connexions série. je l’ai donc désactivé mais rien n’y fait.
J’en suis à me demander si la configuration du gps bluetooth ne bloque pas le passage des trames reçues vers opencpn quelqu’en soit l’origine si pas bluetooth.
Si quelqu’un a une piste pour m’aider à m’ en sortir je suis preneur.
Merci de m’avoir lu

UP


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

9 Messages de forum

__________________________________________________________________________________________________________________

__________________________________________________________________________________________________________________

  • 19 novembre 2021 14:52, par yvesD écrire     UP Animateur

    Je comprend que vous n’arrivez pas à faire ingérer par OpenCPN les trames NMEA émises en RS422 par le MLR et converties en USB par le convertisseur ad-ho, correct ?

    J’ai eu un problème peut-être comparable lorsque j’ai tenté de raccorder ma nouvelle VHF Navicom à mon (ancien) GPS Furuno GP32 (qui fonctionnait avec la VHF Nexus précédente). Du coup les deux sont partis au SAV en Bretagne, qui m’a suggéré d’utiliser l’option « boucle de courrant » du GP32, plutot que l’option « niveau TTL » opérationnel avec la précédente VHF Nexus.

    Dans votre cas précis je m’assurerais que :

    • Le MLR émet bien quelque chose (s’il était en panne, ça serait ballot)
    • Le convertisseur RS422/USB produit bien de l’USB (utiliser un outil d’affichage de trafic USB, demander à gogol)
    • OpenCPN reçoit bien ce trafic USB : en déterminant le port série associée à ce port USB (débrancher, rebrancher : celui qui monté c’est le bon port série), puis en affichant le trafic USB reçu par OCPN (Dans OCP, onglet ’Options’, puis onglet Connexions, cocher ’ouvrir la fenêtre d’affichage’, éventuellement en créant un nouveau port de connexion ’ajouter une connexion’ avec le bon port série en cochant ’Série’ et renseignant ’Port Com’ (la vitesse n’a pas de sens, laisser 4800) en acceptant les bonnes phrases (coche ’accepter seulement ...’ et laisser vide) et en titillant ’Contrôle du checksum’

    Qu’en est-il de tout ces tests ?

    Répondre à ce message

  • Bonsoir à tous et meilleurs voeux.
    Voilà depuis quelques jours je suis parvenu à faire fonctionner tout ça. Je précise que j’utilise OpenCPN par l’entremise de OpenPlotter et donc SignalK. et Serial. C’est une reinstal complète qui a été mon point de départ.

    Dans OpenCPN je n’ai qu’une connexion déclarée : Network/input/tcp/10.10.10.1/10110 pour recevoir les messages arrivant de SignalK
    Pour le bluetooth, je ne parvenais pas à ajouter à SignalK ma connexion bluetooth créee via Serial. En fait, il fallait la créer directement dans SignalK.
    Pour le MLR tout semblait fonctionner sauf que les messages nmea183 reçus par SignalK n’étaient pas prolongés sur la connexion interne 10.10.10.1:10110 car la case à cocher checksum verification était sur on. Le MLR utilise peut-être une version ancienne de la norme ?
    Maintenant quand j’irai au bateau je pourrai tester l’envoi de la position GPS vers la VHF et la réception de l’AIS.

    Répondre à ce message

Répondre à cet article

UP

Copyright et informations légales