Connexion série sous Linux
Fenêtre de connexion
Exemple de connexion des données sous Window
Filtere NMEA pour les données relatives au cap et à la vitesse
Montrer la fenêtre des phrases NMEA
Connexions de données - Ajouter et Supprimer
Ajouter une connexions série
Ajouter une connexion réseau
Connexion au réseau par GPSD
Filtre de connexions
Filtrage en entrée
Filtrage en sortie
Notes relatives aux connexions
Envoyer une route active au pilote automatique
Envoyer des routes et des waypoints au GPS
Communication générales (avec tous) et communications multiples
Attention sous Ubuntu :
Assurez-vous que vous appartenez au groupe "dialout". Pour savoir, exécutez la commande "groups". La liste des groupes auxquels vous appartenez s'affichra. Le mot "dialout" doit en faire partie.
Si vous n'êtes pas dans "dialout" :
- Ajoutez-vous avec la commande "sudo usermod -a -G dialout $ USER".
- Déconnectez votre session en cours pour que les modifications de groupe prennent effet.
Vérifiez tout de suite, cela vous sauvera de la frustration plus tard. S'il
y a un problème de connexion du GPS à un port physique, tel que /dev/ttyS0, il est probable que vous n'êtes pas "dialout".
OpenCPN affichera un avertissement, une fois par session, si vous essayez de configurer une connexion série ou démarre le programme avec une connexion série active et n'appartient pas au bon groupe.
Attention sous Red-Hat :
Les versions Linux basées sur Red Hat utilisent le groupe "uucp".
Vérifiez ce qui s'applique à votre version de Linux, en utilisant le retour de la commande stat -c %G `ls /dev/*|grep -m1 tty[A-Z,a-z][0]
Si le retour est" root ", passez à une version Linux contemporaine.
Tout cela est différent de la logique dans les versions antérieures d'OpenCPN. À partir de la version 3.2 :
- Il n'y a pas de port "autopilote" défini.
- Le
pilote automatique est simplement connecté à tout flux de données
activé en sortie disponible et obtient tout sur le bus, sous réserve du
filtrage de sortie spécifié par l'utilisateur.
- Il n'existe pas de port AIS et GPS «partagé» spécifique, car tous les ports sont partagés.
Pour avoir un aperçu de ce qui peut être fait, nous commençons par un cas d'école. Dans l'écran précédent, quatre ports de données sont activés.
Notez que les connexions sont triées automatiquement dans l'ordre du réglage de priorité. L'image provient d'un ordinateur Linux, mais la boîte de réception est un Win XP. Les deux boîtes sont configurées pour utiliser la même adresse de diffusion '192.168.0.255' sur le réseau local, en utilisant le port 10110 par défaut. Notez que UDP, et non TCP, est utilisé. OpenCPN sur la boîte XP reçoit et affiche toutes les informations à partir des trois premiers ports et même des données du plugin VDR, s'il est en cours d'exécution. Toutes les sources d'entrée sont fusionnées et disponibles pour transmettre à un ordinateur externe. Chaque ordinateur à bord peut être utilisé comme répéteur sur la boîte principale!
Notez que dans ce scénario, la connexion UDP est uniquement sortie. Dans les versions précédentes de OpenCPN, toutes les connexions de données UDP liraient les données ainsi que l'écriture. Il s'agit d'une configuration possible dans la version actuelle mais pas nécessaire ni généralement souhaitable. Si une connexion de diffusion est lue / écriture, toutes les données écrites seront lues en retour, ce qui entraînera des boucles de données.
Il n'y a aucun avantage à utiliser une adresse de diffusion sur le réseau local avec seulement quelques ordinateurs. Il est aussi simple de préciser les adresses des ordinateurs récepteurs en tant que connexions sortantes sur l'ordinateur émetteur. Les "récepteurs" spécifient l'émetteur comme adresse pour une connexion.
Dans la vie réelle, une configuration habituelle comprend les entrées provenant du GPS et de l'AIS et une sortie vers un pilote automatique. Si votre GPS produit GPRMC, cela sera automatiquement envoyé au pilote automatique.
Fournir une moyenne mobile de COG / SOG, avec une période d'échantillonnage configurable. Cette fonctionnalité est utile, par exemple, si vous trouvez que le cours et la vitesse par rapport au gps varie de manière erratique en raison de l'état de la mer. Le plugin Dashboard n'est pas affecté par ce paramètre - COG et SOG sont mis à jour environ une fois par seconde.
Si vous cochez cette case, vous obtiendrez une fenêtre qui montre les phrases de données NMEA entrant ou sortant de OpenCPN.
Un exemple, avec l'image ci-dessus, dans laquelle on voit une partie du code couleur au travail. Des messages en rouge peuvent également apparaître et indiquent les erreurs de transmission.
Les messages de changement de priorité des connexions seront également imprimés dans la fenêtre de débogage NMEA.
Dans cet exemple, la raison pour laquelle les messages AIVDM sont tous deux abandonnés et apparaissent comme "Message de sortie", c'est qu'il y a plus d'une source pour ce message et que le filtre s'applique à une seule source.
Consultez la page des phrases NMEA pour voir quels messages sont compris. OpenCPN ne se soucie généralement pas de l'ID de l'emetteur, les deux premières lettres du type de message. Dans la phrase $GPGGA de l'image ci-dessus, l'identificateur de l'émetteur est GP , c'est à dire le gps, en envoyant un message GGA = position, par exemple. À la fin de chaque phrase, il existe un "*" suivi du calcul d'une somme de contrôle.
Pour voir tous les messages, il est important de fermer complètement la boîte de dialogue Options tout en laissant la fenêtre de débogage NMEA ouverte. Les phrases ECAPB, etc., n'apparaissent pas lorsque la boîte de dialogue Connexions est ouverte car la sortie du pilote automatique est désactivée pendant cette période.
Problèmes connus : le bouton de pause ne fonctionne que si la boîte de dialogue Options principale est fermée. Dans Linux, la fenêtre de débogage ne peut être fermée qu'en ouvrant la fenêtre Show NMEA Debug Window, à moins que la boîte de dialogue Options principale ne soit fermée.
S'il existe des phrases NMEA dans la fenêtre de débogage, OpenCPN a ouvert le port défini dans Data Connections. Notez que la source de chaque phrase NMEA est imprimée après l'horodatage sur chaque ligne. Si votre port GPS est configuré, et qu'il n'y a pas de bateau «rouge», les seules raisons sont les suivantes: pas de phrases NMEA envoyée par le GPS ou mauvais contenu des phrases NMEA issues du GPS.
Les messages provenant de la GPSD ou du complément (plugin) VDR (Voyage Data Recorder) apparaîtront également dans la fenêtre de débogage.
Pour un débogage de flux de données NMEA simple, ajoutez ce qui suit à votre fichier opencpn.ini : sous [Paramètres], ajoutez une ligne DebugNMEA = 1500 Cela fournira jusqu'à 1500 débogues relatifs au trafic NMEA vers opencpn.log.
Téléchargement de format pour le filtrage de FurunoGP3X input : si le protocole spécial Furuno gps est nécessaire, cochez cette case. La raison en est que Furuno utilise sa propre version de NMEA pour télécharger des itinéraires. Les utilisateurs de Furuno GPS prennent note. Il est maintenant permis d'utiliser un nom d'itinéraire numérique numérique à deux chiffres (par exemple 10, 21, etc.).
Utilisez le mode GarminGRMN (hôte) pour les téléchargements : Assurez-vous que cette case est cochée, si vous avez un GPS Garmin. La raison en est que les unités Garmin ne peuvent pas accepter les téléchargements d'itinéraires via la norme NMEA0183. Il s'agit d'une "fonctionnalité de conception" de tous les récepteurs Garmin.
Utiliser des caps magnétiques dans la phrase ECAPB :
Certains pilotes automatiques, en particulier les SIMRAD, ont besoin de
connaitre le cap magnétique (cap compas)dans les phrases APB au lieu du
cap vrai (cap fond). OpenCPN peut le faire par défaut
DataPort: choisissez un port en appuyant sur la touche \ / o du côté droit du champ. Si le port que vous recherchez n'apparaît pas dans la sélection, écrivez le port approprié vous-même dans ce champ.
Priorité : un nombre supérieur est égal à une priorité élevée. La priorité est définie pour chaque phrase NMEA individuellement. Tant qu'un flux de priorité plus élevé est disponible, il est utilisé. Si cela échoue, le prochain flux en ligne, avec une priorité inférieure, se déclenche et est utilisé, jusqu'à ce qu'un flux de priorité plus élevé apparaisse. Le filtre actuel ne gère pas le cas où, par exemple, les messages de position sont reçus de différentes phrases. À titre d'exemple, GPGLL et GPRMC transmettent les informations de position. Le dernier message reçu sera utilisé.
Controle du checksum. À la fin de chaque phrase NMEA est une somme de contrôle, qui garantit que les phrases sont correctement reçues. Cette case est cochée par défaut, car OpenCPN calcule la somme de contrôle et la compare à la somme de contrôle reçue. Seules les phrases avec une somme de contrôle valide sont transmises. Décocher cette case peut aider si les sommes de contrôle sont incorrectement calculées ou si les sommes de contrôle sont manquantes.
Utilisez le mode Garmin (GRMN) pour l'entrée : Assurez-vous que cette case est cochée, si vous avez un GPS Garmin réglé sur ce mode. La raison en est que Garmin utilise son propre protocole série.
TCP: est un protocole «orienté connexion» qui fournit un lien fiable entre deux points du réseau. TCP assure que tous les paquets réseau perdus en transit sont transmis à nouveau. Les serveurs Internet AIS acceptent normalement les connexions TCP comme beaucoup de périphériques série-réseau / wifi.
Pour établir une connexion à un serveur TCP distant, entrez son adresse IP ou son nom d'hôte dans la zone "Adresse" et le port TCP sur lequel le serveur écoute dans la zone "DataPort". De nombreux appareils utilisent un port TCP non standard plutôt que le standard 10110 OpenCPN, vérifiez donc la documentation du serveur. Si "0.0.0.0" est entré dans la zone Adresse, OpenCPN agira comme un serveur TCP acceptant une connexion à partir d'un client TCP distant. OpenCPN écoutera toutes les interfaces réseau de son ordinateur hôte pour les connexions TCP au port spécifié dans le champ "DataPort". Normalement, il ne devrait pas y avoir de raison de sélectionner une valeur "DataPort" autre que la norme 10110, à moins que plusieurs serveurs ne soient requis:
UDP: il s'agit d'une méthode de transmission de données comme des «datagrammes» simples sans négocier une connexion entre deux points finaux. Il ne nécessite aucune détection et aucune retransmission de données perdues dans le réseau. Dans un petit réseau de bateaux / bateaux, la perte de données ne devrait pas normalement se produire et, dans tous les cas, les données NMEA sont généralement mises à jour régulièrement par un émetteur. Contrairement à TCP qui implique une connexion entre deux points du réseau, les données UDP peuvent être reçues par de nombreux «auditeurs».
OpenCPN écoutera une connexion de données UDP sur un port spécifié sur toute interface système ou l'adresse de diffusion de tout réseau connecté. Si vous n'avez pas besoin de recevoir des données de multidiffusion ou de transmettre des données, vous pouvez entrer "0.0.0.0" dans la zone "Adresse" si vous ne savez pas quoi faire. Vous pouvez également spécifier l'adresse sur laquelle vous souhaitez recevoir des données. Dans les deux cas, le comportement sera le même. Si vous souhaitez recevoir des données de multidiffusion, vous devez entrer l'adresse de multidiffusion à laquelle ces données sont envoyées ou le système ne les verra pas. Si vous souhaitez transmettre toute donnée ("Sortie sur ce port"), vous devez mettre l'adresse dans laquelle vous souhaitez envoyer des données dans la zone "Adresse". Dans tous les cas (transmettre, recevoir ou les deux), le DataPort doit être spécifié. Pour plus d'informations sur la diffusion et la multidiffusion, voir Broadcast and Multicast ci-dessous.
GPSD: Il s'agit d'un serveur gps Unix / Linux, ce qui signifie que plusieurs applications différentes peuvent partager un récepteur gps. Les utilisateurs Linux ont le choix entre l'utilisation de connexions série ou GPSD pour leur entrée gps.
Port: le port à se connecter à l'adresse réseau. Le port par défaut pour UDP est 10110. Le port 10110 est désigné par IANA pour "NMEA-0183 Navigational Data". Il ne devrait pas y avoir de raison de changer ce port, mais c'est possible. Voir ci-dessous. Le port par défaut pour le GPSD est 2947. Ne modifiez pas cela!
Lors de l'établissement d'une connexion à GPSD, en cours d'exécution sur votre ordinateur local, utilisez les paramètres ci-dessus.
Acceptez uniquement les phrases : Basez votre filtrage en indiquant les phrases à accepter sinon laissez vide.
Ignorer les phrases : identique à ci-dessus. Pour sélectionner des filtres, appuyez sur le bouton. La boîte de dialogue ci-dessous devient disponible.
Beaucoup de phrases NMEA sont répertoriées. Il suffit de cocher la case pour sélectionner une phrase. "Sélectionner tout" ou "Tout effacer" sont également disponibles. Pour les phrases non indiquées, appuyez sur "Ajouter" et entrez une nouvelle phrase NMEA.
Votre saisie doit être conforme à ces règles
Lorsque vous avez terminé, appuyez sur "OK", votre nouvelle entrée apparaîtra au bas de la liste des phrases NMEA pour filtrer. Il sera déjà coché, alors appuyez simplement sur "OK" jusqu'à ce que vous reveniez dans l'onglet Connexions d'origine. Maintenant, appuyez sur "Appliquer". Le filtrage implanté doit maintenant être visible sur la ligne de connexion. Pour en savoir plus, voir ci-dessous
Recevoir une entrée sur ce port : cette case doit être cochée si vous souhaitez recevoir des données de réception sur cette connexion. Si la connexion n'est utilisée que pour la sortie vers d'autres appareils, elle ne doit pas être cochée. Si vous souhaitez diffuser des données UDP à des fins de consommation par d'autres appareils ou programmes, la suppression de cette boîte vous permettra d'éviter de vous inquiéter en définissant la priorité de la connexion pour éviter les boucles de données.
Sortie sur ce port (comme pilote automatique ou NMEA) : cochez cette case si la connexion est utilisée pour la sortie. Un cas commun envoie NMEA à un pilote automatique. * La précision du port APB est grisée sauf si "Sortie sur ce port" est cochée. L'APB est la phrase NMEA "Autopilot Sentence 'B'". La précision peut être réglée entre 0 et 4 décimales, 3 était la valeur par défaut. Certains pilotes automatiques nécessitent une précision différente de celle par défaut, pour fonctionner. Vérifiez la documentation de votre AP et consultez la note ci-dessous.
OpenCPN crée et envoie les phrases NMEA ECRMB et ECRMC au port de sortie A / P lorsqu'une route est activée. Si la variation n'est pas présent, OpenCPN inclut des variations, provenant du plugin WMM, si installé et activé.
Remarque: Le paramètre "APB bearing precision" (ou NMEAAPBPrecision dans Opencpn.ini) est défini dans la page Paramètres des connexions pour les connexions qui ont des messages sortants. La précision est appliquée dans le fichier src / nmea0183 / apb.cpp et est appliquée à:
Quelques exemples pour illustrer comment faire :
Mettre en place ce filtre, conduit à cela dans la colonne du filtre sur la ligne de connexion:
Si "Ignorer les phrases" est coché, alors la ligne produit cet effet :
Mise en oeuvre semblable au filtrage d'entrée ci-dessus.
Ce filtre qui a pour effet de transmettre trois phrases définies à l'avance, cela donne l'équivalent de ceci :
Un autre exemple de flitrage en sortie
Fonctionnalité: on peut maintenant sélectionner l'ID du talkerNMEA des phrases générées par OpenCPN sur un port donné.
Situation : OpenCPN émet (correctement) ses phrases NMEA avec l'ID de conversation "EC" comme c'est normal et avec le comportement attendu (voir ci-dessous).
Problème: certains dispositifs «contraignant», qui devraient accepter des phrases données indépendamment de l'ID du talker, n'acceptent en fait que par exemple GPRMC et non ECRMC.
Exemple : Une VHF Icom est un exemple de ce type. Si le multiplexeur a été configuré pour donner la priorité aux informations de navigation fournies par OpenCPN, et non celles transmisent par le GPS, le résultat est que lorsque OpenCPN pilote le pilote automatique, le VHF ne reçoit plus de position pour sa fonction DSC. Sur le plan de la sécurité, cela n'est pas souhaitable.
Solution : Modifier les phrases ECRMC en GPRMC, ou créer une copie de la phrase ECRMC sur le port de sortie devrait résoudre le problème.
Trois phrases sont ici rejetées. Cela donne l'équivalent de ceci :
Si vous avez déjà une application connectée à votre GPS, sur un port série, OpenCPN ne pourra pas se connecter au même port. Deux applications ne peuvent pas utiliser un port simultanément.
Sur Linux, utilisez Gpsd dans une telle situation. Bien sûr, cela ne fonctionne que si votre "autre application" prend en charge le Gpsd. En
alternative, vous pouvez utiliser Kplex (également pour Mac) ou Muplex
qui peut créer des pseudo-terminaux ("ports série virtuels") pour
partager des données NMEA entre les applications.
Si une phrase NMEA est filtrée sur une connexion d'entrée :
-
Si le paramètre "LegacyInputCOMPortFilterBehaviour" du fichier de
configuration opencpn.conf | ini, reçoit la valeur 1, la phrase entrera
encore dans le multiplexeur interne. Donc, elle sera disponible pour les connexions de sortie, à moins qu'elle ne soit filtrée là aussi.
- Si "LegacyInputCOMPortFilterBehaviour" reçoit la valeur 0, la phrase n'entrera pas dans le multiplexeur interne. Cela ne fonctionnera que pour les connexions en série.
Echo en arrière une connexion réseau, sur le port d'entrée pour la sortie, ne fonctionnera pas ????)
Il n'y a pas de contrôle de flux sur les ports série. Par nature, NMEA ne contrôle pas le flux. Si une phrase est perdue, c'est définitif .... Elle sera mise à jour à un moment donné. Le "tamponnement" d'une phrase retardée qui a perdu son sens, quand il y a plus de données actuelles et exactes disponibles, n'est pas utile. En cas d'interfaçage en respectant la norme NMEA, il n'y a aucun chemin pour le contrôle du flux matériel. Ce n'est pas compatible avec NMEA.
Les paramètres de précision APC et XTE du pilote automatisque sont toujours identiques.
Si une route est activée, OpenCPN envoie les phrases NMEA ECRMB, ECRMC et ECAPB au pilote automatique, s'il est connecté à un port, avec sortie activée.
Right-click on the chart and select “Navigate to here”, then bring up the Options > Connections > Nmea Debug window and look at the Blue output sentences for ECRMB, ECRMC and ECAPB. Below is one example of output connection settings.
Dans l'exemple ci-dessus, NavMonPC a été utilisé pour lire un fichier NMEA précédemment enregistré, puis configurer un Port Com (Com14) virtuel, puis créer une conexion dans OpenCPN vers ce port virtuel pour lire le flux de données NMEA provenant de NavMonPC.
Les données UDP peuvent être livrées à plus d'un système lorsqu'elles sont envoyées à certaines adresses spéciales
Une "adresse de diffusion" (broadcast) est écoutée par tous les périphériques sur un réseau. Il se forme généralement en prenant l'adresse réseau (la première partie de l'adresse IP commune à tous les systèmes de votre réseau local) et en définissant la dernière partie (le nombre qui est différent pour chaque ordinateur) à une valeur représentée par tous les "1" s en binaire. Si toutes les adresses de vos appareils commencent par "192.168.1", l'adresse de diffusion de votre réseau sera probablement 192.168.1.255 (255 est "11111111" en binaire. C'est pourquoi les adresses IPv4 écrites comme celle-ci ne contiennent jamais de nombres supérieurs à 255. Sauf pour dans le film "The Net" et nous n'en parlons pas). Si vous spécifiez une adresse se terminant par "255", OpenCPN suppose que vous entendez une adresse de diffusion. Ce n'est pas toujours vrai mais entraînera le comportement souhaité dans presque tous les cas.
L'adresse de diffusion spéciale "255.255.255.255" est également écoutée par tous les périphériques. Elle ne devrait normalement pas être utilisée pour transmettre des données par OpenCPN. Utilisez plutôt l'adresse de diffusion de votre réseau local.
Une « adresse multicast » est écouté uniquement par les appareils qui souhaitent recevoir des informations sur cette adresse. Les adresses IPv4 dans la gamme 224.0.0.0 - 239.255.255.255 sont des adresses de multidiffusion. Si vous spécifiez une adresse de multidiffusion pour une connexion de données UDP, OpenCPN informera votre ordinateur d'écouter les datagrammes sur cette adresse. * Plus d'un système peut envoyer des données aux adresses de diffusion ou de multidiffusion, donc c'est un moyen de communication "beaucoup à beaucoup". * Vous ne pouvez pas utiliser les adresses de diffusion ou de multidiffusion avec TCP. TCP est une connexion "one to one".
Les périphériques doivent, dans une certaine mesure, traiter tous les paquets de diffusion sur le réseau, qu'ils soient intéressés ou non. Les paquets de multidiffusion ne sont généralement visibles que par des périphériques qui se sont intéressés par une adresse de multidiffusion particulière. En conséquence, la multidiffusion est plus efficace que la diffusion, bien que cela ait généralement une faible conséquence dans un petit réseau. Malgré l'utilisation de protocoles NMEA sur IP tels que la CEI 61162-4 et le prochain NMEA OneNet, la multidiffusion NMEA-0183 sur IP est beaucoup moins largement prise en charge dans les applications maritimes que NMEA-0183 sur diffusion IP.
Il n'existe pas d'adresse de multidiffusion obligatoire pour les données NMEA-0183 dans ce contexte, même si vous devez éviter les adresses utilisées par d'autres protocoles
Lors de l'utilisation de la multidiffusion avec OpenCPN, il est suggéré qu'une adresse soit utilisée dans la plage 239.192.0.0/14 spécifiée par RFC 2365 comme "Organisation Local Scope". En cas de doute, essayez 239.194.4.4. (Traduction ???)
Il n'existe aucun mécanisme dans OpenCPN pour spécifier l'interface réseau par laquelle les paquets multicast sont envoyés ou reçus. Cela sera déterminé par votre système. Dans certains cas, il peut être nécessaire d'ajuster manuellement la table de routage de votre système pour vous assurer que l'interface réseau souhaitée est utilisée. Reportez-vous à la documentation de votre système si cela s'avère nécessaire.
Si vous transmettez une diffusion ou une diffusion multiple par UDP, vous devez définir la priorité de l'entrée NMEA "réelle" à quelque chose de plus élevé que le flux UDP. Sinon, préparez-vous aux problèmes. La raison en est que si vous diffusez, vous recevrez également le message UDP, qui sera de nouveau retransmis ...... De toute évidence, il envoie les données réelles "réelles". Nous obtenons donc un flip-flop de priorité source sur chaque message, puisqu'ils ont la même priorité. Par exemple, définissez la priorité UDP sur "0" et la connexion entrante réelle à "1" ou plus. Le bouclage de multidiffusion n'est pas désactivé pour une compatibilité avec le comportement de diffusion. Cela signifie que les priorités doivent être définies comme décrit ci-dessus lors de la transmission sur multidiffusion, mais la communication multicast entre plusieurs instances de OpenCPN sur le même système reste possible. * Les pare-feu sur certains systèmes (par exemple OpenSuSE linux) peuvent bloquer les données de diffusion et de multidiffusion que vous souhaitez recevoir. Reportez-vous à la documentation de votre système pour déterminer comment autoriser ces données à accéder à OpenCPN.
Consultez également les «Routes actives et Active Route Console» dans Marks and Routes vers le bas. Il est essentiel d'avoir activé une route active afin d'envoyer des waypoints au pilote automatique.
Lire aussi sur «Route vers le pilote automatique» dans les fonctionnalités avancées pour plus de détails.
Se référer à http://willkamp.com/opencpn/flyspray/index.php?do=details&task_id=1706 Vérifiez les câbles et les connecteurs et pour le délai d'attente du port USB. Comment ajouter ou supprimer "USB 3 Link Power Mangement" dans Power Options dans Windows 8 http://www.eightforums.com/tutorials/50276-power-options-add-remove-usb-3-link-power-mangement.html http://helpdeskgeek.com/windows-xp-tips/prevent-windows-from-powering-off-usb-device/