Suivi RSS
Votre IP : 3.143.4.181
Dernier ajout : 20 avril
Visiteurs connectés : 21
Conception
Développé sous SPIP
Informations légales
OpenCPN
Grand Voyage
Articles
Trucs et astuces
Forum technique
Livres
msg
Accueil du site > Forum technique > OpenCPN -forum- > Utilisation sous Windows -forum- > Opencpn dernière version déconnection
__________________________________________________________________________________________________________________
Version imprimable
Publié Avril 2013, (màj Avril 2013) par :
Epsilon77
|
| 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,
Je pensais le problème résolu mais non, c’est a dire que Opencpn se déconnecte très et trop souvent du Gps, (W7 et Furuno GP-32), les bonnes bonnes cases sont cochées.
Avec l’ancienne version 3.0.2 que j’ai réinstallé pas de problème.
Que faire SVP.
D’avance merci.
Pierre Sur Anak.
Répondre à cet article
(pour répondre à un message en particulier, voir plus bas dans le fil)
__________________________________________________________________________________________________________________
__________________________________________________________________________________________________________________
10 avril 2013 17:07,
par yoruk 
|
Animateur
|
Bonsoir Pierre...
C’est vraiment galère ces GPS, le problème doit être récurent, puisque les développeurs d’OpenCPN ont prévu un add-on à cocher
Je suis allé voir sur leur site, ils ne sont pas généreux en info. Le mieux de ce point de vue, et là je mange gravement mon chapeau, est d"aller voir sur le sir de F Fustier qui propose un schéma de connexion NMEA 0183 pour mac (bien sûr) et pour PC, ce qui est sympa, et voir si tes connexion sont bien faites
Sinon, la meilleure solution pour finalement pas trop cher est peut être de prévoir un petit GPS USB dédié à OpenCPN... C’est qq sous de plus dans l’eau hein 
Voir si tu tentes cette solution si Anak tolère une antenne GPS intégrée dans le carré . Je ne me souviens plus si Anak est en Acier ???
Désolé de ne pouvoir faire plus tout de suite... je vais quand faire des recherches
Michel
|
10 avril 2013 21:54,
par Epsilon77
Ce message répond à ...
|
|
Bonsoir Michel,
Merci de ta réponse, et de la solution GPS, Anak est en GPS, il tolère tout y compris les fautes de sont skipper.
Pour le moment j’utilise l’ancienne version qui me convient bien.
Merci de ton aide.
Amicalement.
Pierre
|
11 avril 2013 22:22,
par svacthelo
|
|
J’ai le même problème avec un GPS furuno GP30.
Il se déconnectait moins souvent avec la version 2.3.1.
Je vais faire comme toi, mettre la V3.0.2.
Dommage, la V3.2.0 permettait d’envoyer les waypoints et les routes vers le GPS qui les recevait très bien quand il ne se déconnectait pas en cours de route.
J’ai bon espoir pour les versions suivantes d’opencpn. Il n’y a pas de raison puisque ça a marché mieux avant ...
Pour info, je pense avoir coché les bonnes cases et j’ai le câblage indiqué sur le site cité dans le message précédent.
Si vous avez d’autres idées, je suis preneuse ...
|
11 avril 2013 22:29,
par yoruk
Ce message répond à ...
|
Animateur
|
Non, rien de concret pour le moment... Je regarderai demain sur le site Cruisers Forum... mais, mon anglais est maigre...
Michel
|
12 avril 2013 10:27,
par yoruk
|
Animateur
|
Toujours rien au sujet du furuno GP30. ,mais une idée 
, si, si, en dépannage voire plus
Interrogé en MP sur des problèmes d’effacement des données personnelles sous 3.0.2, j’ai répondu par un petit PDF (ci joint), montrant comment utiliser en parallèle, les versions 3.0.2 et 3.2 .
Cà peut dépanner en attendant de trouver des solutions. Par ailleurs on y montre aussi comment faire une sauvegarde des programmes et des données utilisateurs.
J’essaierai de faire un dossier là dessus, mais en attendant j’ai du pain sur la planche entre mon carénage et la refondation du monde...
Michel
|
12 avril 2013 14:06,
par Nicodefreja
|
|
J’ai passé la journée hier à bosser là dessus (pffff), une chose est sure, le module nmea a été amélioré sur la dernière version Open CPN ..... pour devenir beaucoup plus instable ! Par exemple, il n’aime pas du tout les phrases gll. J’ai aussi un problème de « freeze » des ports usb, mais là je soupçonne plus la gestion du bus usb.
Cependant, hors ces problèmes de « freeze », je suis parvenu à plus de stabilité.
Ma configuration :
port com 1 : gps GP32, centrale Simrad mixée nmea 0183 et nmea 2000 (pour compliquer les choses !), autopilot Raymarine, le tout arrivant sur un MUX Brookhouse et relié au PC par convertisseur série USB
port com 2 : transpondeur AIS Advensea arrivant direct au pc via un autre convertisseur.
Arrivée au PC sur un seul port USB via hub.
Configuration logicielle : Open CPN, Maxsea et PolarCom tournent en simultané via un port splitter (VSPE)
Volià pour la config, je n’ai pas réussi à compliquer plus 
Ce que j’ai constaté :
en cas d’utilisation de transpondeur AIS, il faut impérativement refuser les phrases AIVDO (sa propre position) sous peine de voir le bateau faire le yoyo entre les deux positions GPS (celle du transpondeur et celle du GPS, qui ont quelques mètres d’écart.
la logique de tri des phrases nmea dansOpen CPN est assez étrange, notamment dans la notion « accepter » et « refuser ». Cependant, je suis arrivé à une stabilité de la position en IGNORANT (si on fait l’inverse, en acceptant celles qui ne sont pas refusées, ça marche pas, va comprendre Charles !) les phrases suivantes sur le port 1 :
RMB, WPL, RTE, GLL, VTG, GSV, GGA, APB, AIVDM (acceptée seulement sur port 2), AIVDO, FRPOS (?), CD, DBT, VHW, MTW, DPT, MWV, APGLL (retour pilote), GPAPA, GPZDA, ZDA.
Certaines de ces phrases ne sont pas proposées dans le choix du module nmea, je les ai ajouté après visionnage dans la fenêtre des phrases nmea.
IL EST IMPERATIF de déconnecter la sortie pilote. En effet, quoiqu’on fasse, celle ci met Open CPN en instabilité. La sortie pilote est pour l’instant et du coup gérée par Maxsea.
Enfin, à noter quelques bizarreries :
impossible d’avoir le vent autrement qu’en m/s (ce qui est agaçant, mais là je soupçonne le nmea 2000 d’être dans le coup)
vous aurez noté dans la liste des phrases refusées qu’on trouve DBT, DPT, MWV, ... qui sont les phrases de la centrale. En refusant la totalité des phrases qui s’affiche dans la visionneuse nmea (tout ce qui est censé circuler donc), OpenCPN reçoit malgré tout les infos vent et profondeur de la centrale. Sortez les gousses d’ail !!! Seule la déconnexion du port coupe les infos. Je soupçonne également un problème nmea 2000.
en essayant toutes les possibilités, impossible d’avoir la valeur du compas du pilote dans le board. Pourtant, OpenCPN semble l’accepter, mais ne pas en tenir compte.
la sortie pilote Maxsea perturbe Open CPN si on n’y fait pas également un tri rigoureux des phrases (et en premier lieu GLL !) : seule les phrases APA et RMB sont cochées. Ce qui confirme que Open CPN a vraiment un gros problème sur la sortie pilote.
Toutes ces bizarreries et problèmes n’existaient pas dans la version 3.0,
Il y a certainement moyen d’améliorer les conclusions que j’ai obtenu hier, notamment en travaillant sur la sortie pilote (mais ça m’a gonflé, donc on fera ça plus tard)
|
12 avril 2013 14:42,
par yoruk
Ce message répond à ...
|
Animateur
|
Houuuaaa... merci Nicolas... enfin du monde, et un pro en plus...
Je pourrai tester ma config basique (OpenCPN + GPS + VHF/AIS) fin du mois, d’ici là je serai bloqué par mon carénage, la préparation du bateau et mes gesticulations « zapatoïstes » dans des bistrots mal famés...
Je pourrai très rapidement voir comment on passe de la 3.0.2 à 3.2 en route et en direct...
Autre chose, « perso non dico » il me semble aussi que le module connexion des versions récentes ne s’améliore pas. C’était nettement plus fiable avec la version 2.5...
Bon on verra
A+ Michel
|
12 avril 2013 17:29,
par yoruk
Ce message répond à ...
|
Animateur
|
Passer alternativement d’OpenCPN v3.2 à 3.0.2
Alors, çà fonctionne à l’arrêt, au port, sous cette configuration
W7 64 bits
|
12 avril 2013 17:31,
par yoruk
Ce message répond à ...
|
Animateur
|
Passer alternativement d’OpenCPN v3.0.2 à 3.2
Alors, çà fonctionne à l’arrêt, au port, sous cette configuration
W7 64 bits
|
12 avril 2013 17:33,
par yoruk
Ce message répond à ...
|
Animateur
|
Il faut ré-paramétrer les connexions quand on change de version
Les fichiers personnels (cartes, layers, etc...) restent inchangés
|
12 avril 2013 21:11,
par Nicodefreja
Ce message répond à ...
|
|
Heuh, merci Michel, mais non, certainement pas pro, juste amateur et très modeste en plus, j’aime juste bidouiller ces petits trucs (même si je sais un peu bidouiller les bus usb, ça reste toujours un mystère .....). Au passage, heureux qu’on puisse encore s’amuser avec le nmea 0183, mais inquiet par la fermeture du nmea 2000 qui ne permet aucun « bidouillage » pour l’instant ! Bref !
Juste un mot en relisant les messages à propos du GPS Furuno. Je ne me souviens plus du GP30, il a quitté le bord (pour une raison dont je ne me souviens plus il y a 8 ans, mais il marchait très bien vu que je l’ai revendu), mais dans le GP32, il faut configurer le type de sortie nmea (paramètre E/S) : nmea rem1, nmea rem 2, nmea AP sur data1 et data 2. Personnellement, j’ai réglé la data 1 (la principale, qui va au MUX) sur nmea rem2. La data 2 est connectée sur la VHF Navicom RT 650 qui elle, est TRES TRES capricieuse sur son interface nmea (regret pour cet achat, mais bon on ne peut pas gagner à tous les coups).
Je pense, sans en être sur, que cela correspond aux versions du nmea 0183, et que Open Cpn travaille sur la dernière version nmea 0183. A vérifier pour ceux qui utilise un Furuno (qui est un très bon GPS, mais comme tout ce que fait Furuno, un poil compliqué)
Cette intervention juste pour donner une éventuelle piste à ceux qui utilisent des Furuno 
|
13 avril 2013 07:01,
par Nevermind
Ce message répond à ...
|
|
|
13 avril 2013 07:11,
par yoruk
Ce message répond à ...
|
Animateur
|
Heuh, merci Michel, mais non, certainement pas pro, juste amateur et très modeste en plus
Heuh… Disons que la modestie des amateurs ‘’éclairés ‘’ me convient bien !!! Je te croyais informaticien, bon y a pire, j’ai une universitaire dans mon couple
Merci pour ceux qui possèdent un GPS 32, du rappel du GP30 çà les aidera peut-être. Mais, puisqu’on en est au débroussaillage primaire du touffu OpenCPN, enfin qui commence à s’embroussailler sérieusement, et que justement c’est la vocation de ce tutoriel : débroussailler, voire débroussailler jusqu’à l’excès,
La question suivante sera : l’architecture d’OpenCPN est-elle de taille à supporter ces complexités ??? 
Michel
|
13 avril 2013 10:15,
par Epsilon77
Ce message répond à ...
|
|
Bonjour
Que ce soit en version 3.0.2 ou en version 3.2.0-1, je suis en W7 64 bits, le réglage est le même port com 7 4800 bauds je n’ai pas le choix, opencpn ne me donne pas d’autre choix.
je n’ai rien d’autre comme matériel de branché, pas d’AIS, le pilote automatique est independant d’opencpn.
En version 3.0.2 tout fonctionne à merveille quant à a version 3.2.0-1 impossible de m’en servir déconnexion intempestive du GPS Furuno GP-32.
Pour le moment je n’utilise que 3.0.2 en attendant une mise à jour.
|
13 avril 2013 13:24,
par Nicodefreja
Ce message répond à ...
|
|
As tu bien vérifié que le port com 7 dans le gestionnaire de périphérique était bien réglé sur 4800 bauds ? Je viens de vérifier, sans sortie pilote et avec un GP32 (dont la sortie data est réglé sur nmea rem2), Open CPN 3.2 est stable, donc il y a quelque chose dans ta configuration
|
13 avril 2013 15:58,
par Epsilon77
Ce message répond à ...
|
|
Merci de ton Email, je serai surpris qu’il y ai quelque souci avec ma configuration l’ordi est un Asus avec W7 et 64 bits dédié exclusivement a la navigation il n’y a rien qu’opencpn et les cartes aucune autre application sauf celles de base.
De plus pourquoi 3.0.2 fonctionne a la perfection et que 3.2.1 ne fonctionne pas par déconnexions intempestives, rien n’est changé dans la config de l’ordi.
La case GPS est bien cochée, quant a Nmea je n’en sert pas.
Le pilote automatique est indépendant du GPS.
Suis perplexe devant ce problème quant aux autres avis de filtrer où accepter où pas filtrer telles où telles données ou instructions comme nmea 0183 c’est de l’hébreux pour moi.
Très content d’Opencpn autrement, c’est un excellent produit qui s’affinera au fur et à mesure des mises à jour.
|
13 avril 2013 16:02,
par Nicodefreja
Ce message répond à ...
|
|
Mais as tu bien vérifié la vitesse du port dans le gestionnaire de périphérique ?
|
13 avril 2013 15:59,
par Nicodefreja
|
|
Bon bah voilà après avoir tout essayé sur la sortie pilote, je n’ai pas réussi à trouver une configuration qui ne déstabilise pas la position du bateau ni n’entraine de décrochage. Donc je suis revenu à la version 3.0.2 qui me semble beaucoup mieux marcher :
+ le bateau est aligné sur son cap compas et ne suit pas le cap gps (qui, à l’arret change tout le temps). Cela me semble une fonctionnalité importante car en navigation on détecte immédiatement la dérive. Par contre, je n’arrive toujours pas à afficher ce cap compas dans le tableau, mais ce n’est pas important.
+ Open CPN dans cette version ne tient compte que de la position gps, et non celle de l’AIS. Ca m’arrange, celle du gps est plus précise (même si on ne parle que de 2m au maximum ......)
+ Etrangement, le vent est à nouveau en nœuds et non en m/s. Ca c’est important. Par contre, il n’affiche plus l’angle de barre (pas grave)
C’est dommage, mais tant pis, j’ai vraiment l’impression que la version 3.2 a des problèmes dans son module nmea. Et je crois que cela vient du filtrage des infos qui ne marche (entre autres). J’ai tenté une expérience : sur le port de sortie, à l’aide de l’afficheur nmea, mais en vérifiant également sur hyperterminal, j’ai relevé la totalité des phrases en sortie et je les ai filtré toutes (en les nommant à la fois en 3 lettres mais également en 5 lettres, donc avec leur origine, pour être sur). Nada, ça ne marche pas, il y a toujours des phrases qui sortent alors qu’elles ne devraient pas sortir.
Par contre, le vent qui est en m/s sur 3.2 et en nds sur 3.0.2, ça reste toujours un mystère .......
|
13 avril 2013 17:30,
par svacthelo
|
|
j’ai un peu creusé le sujet hier sur le Furuno GP30 en simplifiant au maximum la configuration : un PC, un GPS, que les plugins grib (pas celui de base, l’autre) et dashboard.
A mon bord, la liaison vers le PC se fait via la sortie OUT2 configurée en NMEA-REM en version NMEA 2.0 (je ne connais pas la différence avec la V1.5) en RS232 (Tx, rx, Gnd). J’ai un convertisseur RS232 / USB bien câblé comme indiqué sur un autre site (rebouclage des RTS/CTS et DTR/DSR).
Le GPS, le port COM virtuel sur le PC et opencpn sont tous configurés de la même manière selon les indications fournies par le GPS quand on lui demande d’échanger des données avec le PC, c’est à dire : 4800 bauds, 1 bit de stop, pas de contrôle de parité, contrôle de flux Xon/Xoff.
Pour info, la sortie OUT1 du GPS va vers la VHF ASN en différentiel (+Tx, -Tx).
Je n’ai aucun autre instrument connecté au PC. J’ai donc fait quelques essais supplémentaires en V3.2.0 en utilisant la fenêtre d’espionnage NMEA et je n’ai rien trouvé de concluant. J’ai l’impression que la déconnexion est totalement aléatoire.
Le GPS envoie dans l’ordre des trames GLL, GGA, VTG, ZZDA, RMC,RMB, BWC.
Si j’active la connexion avec le GPS en sortie, opencpn renvoie au GPS exactement les mêmes trames (je n’ai mis aucun filtrage nulle part).
Trouvant ça dommage de renvoyer au GPS les trames qu’il m’envoie, j’ai filtré ces trames et je vois bien que ces trames sont filtrées en sortie dans lafenêtre NMEA : elles apparaissent en marron au lieu du bleu.
==> Première réflexion : pourquoi opencpn génère ces trames alors qu’il ne les transmet pas au GPS ?
Puis, j’ai envoyé une route au GPS à partir de opencpn. Ca a fonctionné correctement. J’ai vu passer les trames PFEC GPwpl, GPRTE et PFEC, GPxfr. Petite précision : quand le GPS est en attente de réception de données du PC, il semble arrêter l’émission de sa position et ce jusqu’à ce que l’on acquitte la fin de la réception des données sur le GPS. Ainsi, si on est assez rapide pour envoyer les données vers le GPS, ça fonctionne. Mais si on attend trop avant d’acquitter la fin du transfert sur le GPS, opencpn perd la connexion avec le GPS (le bateau devient gris). Mais dès que l’on a acquitté la fin du transfert sur le GPS, opencpn récupère la liaison sans problème avec le GPS (le bateau redevient rouge).
Une fois, opencpn a perdu la connexion avec le GPS et je n’ai pas réussi à la reprendre. Dans ce cas, le fichier opencpn.log indique qu’il n’arrive pas à fermer la connexion avec le GPS. Le message exact est "18:08:57 : Closing NMEA Datastream Serial:COM3
18:08:57 : Stopping Secondary Thread
18:09:07 : Not Stopped after 10 sec."
Ce problème de fermeture de la connexion n’apparaît que lorsque la liaison avec le GPS ne fonctionne plus. Dans ce cas, je ferme opencpn et j’essaie de supprimer le fichier opencpn.log mais sans succès. Pour récupérer la connexion avec le GPS, je suis obligée d’éteindre le PC et de le rallumer.
J’ai aussi observé dans le fichier opencpn.log qu’il a l’air de détecter un driver Garmin alors que j’utilise un furuno et que j’ai bien coché furuno partout dans la fenêtre de gestion des connexions. Voici ce qui est écrit dans le fichier opencpn.log : « 18:06:52 : EnumerateSerialPorts() Found Garmin USB Driver. ».
Est-ce qu’il faut installer un driver furuno ? Et si oui, où le trouver ?
J’ai aussi noté qu’opencpn utilise un watchdog de 6 secondes sur le GPS, ce n’est peut-être pas suffisant ?
Bon, j’ai un second PC qui a l’air de se déconnecter beaucoup plus souvent du GPS alors je vais refaire quelques essais d’ici-là. Par contre, sur cet autre PC, souvent windows (opencpn n’est pas encore lancé) prend le GPS pour une souris pointball et du coup une souris fantôme (les données du GPS) se met à cliquer n’importe où dans l’écran. Est-ce que quelqu’un saurait me dire comment je peux résoudre ce problème ? Pour info, si la souris fantôme m’en laisse le temps entre deux clics sauvages, j’arrive à supprimer ce problème en désinstallant le driver de la souris pointball. Le soucis est que Windows réinstalle ce driver à chaque nouveau démarrage du PC avec le GPS ...
Je vous tiens au courant de mes tests sur le second PC.
Un autre truc qui m’inquiète : aucun bug n’a l’air signalé sur le site opencpn.org.
|
13 avril 2013 17:44,
par yoruk
Ce message répond à ...
|
Animateur
|
Hé Hop... pour la folle souris :
Pas peu fier, je l’ai retrouvé par l’outil recherche que nous a pondu Robert (tout en haut à gauche de la page d’accueil)
Michel
|
13 avril 2013 20:38,
par Nicodefreja
Ce message répond à ...
|
|
Merci pour ce retour complet C’est en décrivant ce que chacun bidouille dans son coin qu’on arrive à trouver des solutions (ou mieux identifier un problème)
Pour la souris, c’est un problème connu et les réponses sont dans le fil qu’à indiqué Michel.
Pour le reste, quelques réponses et suggestions :
+ il n’y a pas de « driver » Furuno.
+ pour moi, la config que tu as installé est bonne, c’est un problème de paramétrage
+ est ce que, quand tu n’utilises que le port en entrée, la position est stable ?
Si non : tu peux filtrer les phrases en entrée jusqu’à arriver à la stabilité, en commençant par ne laisser rentrer que GGA. Normalement, tu devrais arriver à la stabilité (en tout cas chez moi ça marchait)
Si oui, on passe au point suivant
+ port de sortie : en fait dans ton utilisation et à moins que j’ai oublié quelque chose, tu n’as besoin du port de sortie que quand tu transfères des points au gps, ce qui ne se fait pas tout le temps. Donc tu peux activer le port de sortie que quand tu transfères des points. Une fois les points arrivés dans le gps tu déconnectes le port de sortie pour retrouver la stabilité. Ce n’est pas grave d’envoyer d’autres phrases au gps, de toute façon il ne prend que ce qu’il veut
Personnellement, je compte garder la version 3.0.2 sur l’ordi de nav, et garder la version 3.2 sur mon ordi personnel pour éventuellement transférer des points au gps
Bonne chance
|
14 avril 2013 19:20,
par svacthelo
|
|
J’en suis arrivée au même point que toi : je garde le PC de nav en V3.0.2 et le PC divertissement en V3.2.0 pour avoir le plugin grib un peu plus évolué et envoyer les routes sur le GPS afin d’éviter mes erreurs de saisie quand je le fais directement sur le GPS.
Mais ce n’est pas très satisfaisant intellectuellement ... Bon, l’important, c’est que tout fonctionne pour assurer la nav que de toute façon je double en faisant des points réguliers sur les cartes papiers.
Pour le problème avec la souris, merci beaucoup, je vais m’y atteler dès que le problème reviendra, ce qui n’est plus le cas pour le moment ???
Les tests avec le PC de nav qui se déconnectait plus souvent que l’autre n’ont rien donné de plus. J’ai le même messages d’erreur de fermeture du second thread du port COM dans le fichier opencpn.log et le problème de déconnexion est tout aussi aléatoire.
Je vais donc continuer à suivre cette discussion au cas où une solution miracle apparaîtrait ...
|
14 avril 2013 19:54,
par Nevermind
Ce message répond à ...
|
|
J’ai déjà eu un problème similaire que j’ai détourné comme ça :
|
22 mai 2013 19:19,
par Tiersp
|
|
J’ai enfin réussi à faire fonctionner OpenCPN 3.2 correctement et sans décrochage.
Même le pilote auto fonctionne correctement (SPX10 Raymarine).
Mon problème vennait de certaines phases NMEA que les instruments ou le multiplexeur envoyaient.
Pour que cela fonctionne, j’ai du sélectionner dans la configuration des ports de OpenCPN, Que ce qui m’interresse comme phases pour l’entrée et la sortie..
A savoir :
Je prends tout pour le GPS donc pas de filtrage à l’entrée.
Par contre pour les instruments à l’entrée je ne prends que les phases :
HDG ( compas ),MWV (vent ),VHW ( speedo ), VWR ( vent app ), DBT ( sondeur ), MTW (temp eau ).
En sortie je ne mets plus RMC, mais GPRMC, sinon OpenCPN sort GPRMC et ECRMC
(ECRMC est une phase créée par open )
Pour le pilote il faut aussi mettre RMB et Open envoie ECRMB.
Ma config :
COM 15 GPS bluetooth pas de filtre en entrée pas de sortie
COM 11 Les instruments filtre en entrée que les phases HDG ....sortie RMB,RMC pour le pilote auto
COM3 GPS pour livre de bord entrée pas de filtre sortie RMB,GPRMC,GSA,GSV
COM5 instruments pour livre de bord entréepas de filtre sortie HDG,.....
|
23 mai 2013 17:19,
par Nevermind
Ce message répond à ...
|
|
Je suis surpris car cela fonctionnait chez moi.
JP
|
10 juin 2013 15:56,
par Nicodefreja
|
|
Ah c’est intéressant, passage à la version 3.2.2 aujourd’hui, qui semble confirmer qu’il y avait un bogue dans le module nmea de la version 3.2 :
pour l’instant ça semble stable (depuis une heure)
la sortie pilote peut être utilisée
le bateau est orienté selon le cap compas
par contre, j’ai toujours le vent en m/s
Mais c’est déjà pas mal du tout
|
10 juin 2013 21:27,
par Nevermind
Ce message répond à ...
|
|
