search

b-lack / qgis-gnavs-plugin

GNSS Navigate and Save - QGIS-Plugin
https://plugins.qgis.org/plugins/gnavs/
GNU General Public License v3.0
1 stars 1 forks source link

Can´t connect to my GNSS-Receiver #26

Open wein-franke opened 1 year ago

wein-franke commented 1 year ago

Ich verwende einen Empfänger auf Basis des Ublox ZED F9P. Soweit ich das nachvollziehen kann, stellt dieser die Positionsdaten in Verbindung mit dem Softwarepaket RTKLib unter der TCP/IP Adresse 127.0.0.1:999 zur Verfügung. Von dort können sie auch für die klassischen GPS-Funktionen QGIS benutzt werden.

Das Plugin GNAVS bietet mir aber nur das "internalGPS" an, sowie "localhost:2947" und diverse Com-Ports, die aber alle nicht als GNSS Empfänger erkannt werden. Die Position des "internalGPS" scheint zwar sekündlich gelesen werden zu können. Die Daten sind aber entweder mehrere hundert Meter vom tatsächlichen Standort weg, oder werden mangels Qualität gar nicht ausgewertet.

Wie kann ich für das Plugin die oben genannte TCP/IP Adresse verwenden?

b-lack commented 1 year ago

@wein-franke das "internalGPS" gibt, abhängig von der genutzten Hardware, aber in diesem Fall wohl das A-GPS https://de.wikipedia.org/wiki/Assisted_Global_Positioning_System Signal zurück. Das könnte beispielsweise der nächste Funkmast sein. Daher wahrscheinlich auch die ungenaue Position.

Wie und ob die IP des gpsd geändert und genutzt werden kann, muss ich erst prüfen.

wein-franke commented 1 year ago

Wenn es ähnliche Algorithmen sind wie bei den bisherigen "GPS"-Funktionen, bin ich zuversichtlich. Da geht es.

Aktuell verwende ich GPRMC Datensätze. Die meisten meiner Kollegen GNRMC. Die NMEA Codes für Satellitenanzeige sind in unserem Nutzerkreis meist deaktiviert, da das Lenksystem 10 Hz RTK erfordert und unnötiger Datenaustausch nur hinderlich ist.

"Meine Kollegen", für die die Anwendung interessant sein könnte, und die mit dem F9P arbeiten, sind eine Chatgruppe mit nahezu 1000 Teilnehmern. https://t.me/joinchat/EUStFFNMfP5ZgR2bQYfMMA

twiebke commented 1 year ago

Das verstehe ich nicht. GPRMC ist doch ein Datensatz des NMEA.

wein-franke commented 1 year ago

Das verstehe ich nicht. GPRMC ist doch ein Datensatz des NMEA.

Tut mir leid, wenn ich das missverständlich geschrieben habe. Natürlich ist das ein NMEA Datensatz. Allerdings gibt es da ja unterschiedliche, mit denen man die Position und weitere Informationen ausgeben kann. Und beim F9P kann man es konfigurieren, welche er in welcher Häufigkeit bereitstellen soll Ich wollte nur schreiben, dass wir bei unserer Hauptanwendung (das Lenksystem "Cerea-GPS" ) aus Gründen der Performance auf die Ausgabe der GSV, GGA,... Datensätze verzichten, und meist nur die RMC Datensätze, dann aber mit der Frequenz von 10 Hz ausgeben lassen. Und hierbei macht es bei dieser Lenksoftware auch noch einen Unterschied, ob GP (eigentlich nur das amerikanische GPS) oder GN (Kombination verschiedener Systeme) vorne dran steht. Wie gesagt, die meisten Kollegen verwenden wahrscheinlich die unserem Forum "Cerea-Forum.de" hinterlegte "GN"-Variante dieses NMEA-Datensatzes, während ich den F9P wegen Mitverwendung des Signals für ein Terminal zur Teilbreitensteuerung einer Pflanzenschutzspritze auf "GP" umstellen musste.

wein-franke commented 1 year ago

@wein-franke das "internalGPS" gibt, abhängig von der genutzten Hardware, aber in diesem Fall wohl das A-GPS https://de.wikipedia.org/wiki/Assisted_Global_Positioning_System Signal zurück.

Ich habe noch ein bisschen experimentiert. Wenn ich den "GPS"-Empfang in QGIS aktiviere, bevor ich den Empfang des GNAVS mit internalGPS starte, liest GNAVS anscheinend sogar die Position aus meinem Empfänger. Allerdings sind dann die meisten Funktionen in QGIS blockiert. Beispielweise ist die Eingabe von Zahlen im Maßstabs-Fenster unter der Karte blockiert. Und nach anderen Aktionen innerhalb QGIS hängen sich QGIS und/oder GNAVS zumindest für etliche Sekunden völlig auf. Stoppe ich den Empfang in GNAVS und starte ihn erneut, erschien gestern meist eine Python-Fehlermeldung. Heute wechselt die Position meist an den Ort ein paar hundert Meter weit weg, der mir zuerst mit localGPS angezeigt worden war, wenn ich den Empfang innerhalb QGIS nicht aktiviert hatte. Trenne und verbinde ich QGIS-GPS neu, findet GNAVS auch meist beim nächsten Versuch die aktuelle Position meines Empfängers wieder. Aber leider ist dies alles nicht immer eindeutig reproduzierbar.

(QGIS hatte ich gestern auf die Version 3.32.3 aktualisiert. Seither zeigt mir das farbige Feld für die Verbindungsqualität in QGIS GPS grau für nicht verbunden an, auch wenn ich RTK habe. Zuvor war es dann immer grün, auch bei Float RTK oder DGPS. Das mag vielleicht daran liegen, dass in meinem System einige der NMEA Messages deaktiviert sind.)

b-lack commented 1 year ago

@wein-franke Kannst du etwas zu deinem System: Betriebssystem, Hardware/Rechner sagen, damit ich den Fehler eventuell reproduzieren kann?!

Nutzt du die "Navigation" oder die "Punktaufnahme" wenn die Fehler auftreten?

wein-franke commented 12 months ago

@wein-franke Kannst du etwas zu deinem System: Betriebssystem, Hardware/Rechner sagen, damit ich den Fehler eventuell reproduzieren kann?!

Wichtiger wäre mir ja, dass ich das Tool über eine vorhandene Verbindung verbinden könnte, da die im Gerät verbaute Hardware kein RTK kann, egal ob da ein GPS-Empfänger drin ist, oder nur über Sendemasten und Sendestärke nahegelegener WLAN-Netze eine ungefähre Position geraten wird.

Fertig zu kaufen gibt es das System nicht. Es ist aber so oder ähnlich bei etlichen Landwirten der oben genannten Chatgruppe, die sich überwiegend auf der Suche nach kostengünstigen RTK-Systemen für Lenksysteme zusammengefunden haben, im Einsatz:

Ich Verwende ein DELL Tablet 7140 Venue 11 pro. Betriebssystem Windows 10 Version 2009. QGIS 3.32.3, GNAVS 1.0.8. Als Receiver verwende ich seit 2020 ein Ublox Evaluation Board C099-F9P. Dieses ist per Bluetooth (oder USB-Kabel) mit dem Tablet verbunden. (Alternativ kommen in unserer Gruppe meist funktionsgleiche SimpleRTK2B-Boards von Ardusimple zum Einsatz). Für die Versorgung mit Korrekturdaten und Bereitstellung der NMEA-Positionsdaten verwende ich RTKNAVI und STRSVR aus dem Open-Source-Projekt RTKLIB. Über einen WLAN-Hotspot meines Smartphones erhält RTKNAVI Korrekturdaten. Diese werden per STRSVR auf den mit dem Bluetooth verknüpften Comport gesendet. Die vom Ublox-Receiver zurückgesendeten Positionsdaten werden dann auf einer TCP Server-IP den verbundenen Programmen zur Verfügung gestellt. Diese sind bei mir in erster Linie die Software Cerea eines Lenksystem für Landmaschinen und ein Steuerterminal einer Pflanzenschutzspritze. Außerdem verwende ich QGIS um Bewirtschaftungsgrenzen zu suchen oder zu erfassen. Diese unterschiedlichen Programme können dank der TCP-IP-Variante, anders als bei Bereitstellung über einen seriellen Port, gleichzeitig auf diese Positionsdaten zugreifen.

Ausprobiert habe ich GNAVS bislang mit der "Punktaufnahme".

Wie gesagt, viel wichtiger als das "internalGPS" wäre mir die Möglichkeit, den TCP-IP-Port selbst im Programm festlegen zu können. Bislang wird mir dort nur ein einziger angeboten, auf den ich die Daten mit STRSVR aber nicht schicken kann.

[Sollte ich bei der Beschreibung Fachbegriffe falsch verwendet haben, bitte ich das zu entschuldigen. Im Haupterwerb kümmere ich mich um Landwirtschaft.]

b-lack commented 9 months ago

@wein-franke dein Setup habe ich noch nicht reproduzieren können, aber ich verstehe jetzt deine Anforderung besser.

In der neuen Version habe ich eine Port-Auswahl hinzugefügt, wenn du "localhost" wählst. Das kannst du mal ausprobieren und gerne Feedback geben, ob es funktioniert.

Wie gesagt, konnte ich dein Setup bei mir noch nicht einrichten, daher ist die Funktion ungetestet.

wein-franke commented 9 months ago

@wein-franke dein Setup habe ich noch nicht reproduzieren können, aber ich verstehe jetzt deine Anforderung besser.

In der neuen Version habe ich eine Port-Auswahl hinzugefügt, wenn du "localhost" wählst. Das kannst du mal ausprobieren und gerne Feedback geben, ob es funktioniert.

Hallo, danke für die Bemühungen und die Auswahl der Ports für den Localhost. Leider verhält es sich hier aber wie bei QGIS selbst. Innerhalb der RTKLib-Programme und auch mit dem Lenksystem Cerea kann ich auf die Daten über "localhost" und den in STRSVR festgelegten Port 999 zugreifen. Bei QGIS ging das bis Anfang 2019 ebenso. Dann funktionierte diese Verbindung plötzlich nicht mehr. Allerdings fand ein Kollege heraus, dass es mit der Kombination IP: 127.0.0.1 und dem Port 999 wieder funktioniert. Ich kenne leider die technischen Zusammenhänge nicht. Aber in der Chatgruppe wurde das damals mit dem Windowsupdate 1903 in Verbindung gebracht. Mit der Kombination localhost / Port 999 bringe ich leider auch zum GNAVS Plugin keine Verbindung zustande. Vermutlich müsste man dann auch die IP frei wählen können.

Beste Grüße, Wolfgang alias Wein-Franke