Feature request #9373

Support for UDP connections in GPS Widget

Added by jtornero - over 3 years ago. Updated about 2 months ago.

Pull Request or Patch supplied:Yes Resolution:
Easy fix?:No


Sometimes NMEA data (not only GPS but sounders, etc) data is feeded through UDP datagrams. This is common, for instance, in research vessels.

It would be nice for QGIS' GPS panel to have an option for UDP connections.

Best regards


#1 Updated by Jürgen Fischer over 3 years ago

Could you include pointers to any specs please?

#2 Updated by jtornero - over 3 years ago


What kind of specs should be needed (ports, hosts...?

AFAIK It depends a lot on the R/V, but basically the most widespread schema is to send UDP datagrams with the same format as a NMEA sentence; In fact, what they do is a just a multiplexation of different instruments through the net. You can catch them simply listening to UDP datagrams at a given port. Those datagrams can be catched by any computer on the net, so I guess an UDP broadcast/multicast is sent.

Jürgen Fischer wrote:

Could you include pointers to any specs please?

#3 Updated by jtornero - over 3 years ago


Well, this is what I've made so far, maybe someone can take a look at it (sorry about coding, I'm not a C++ guy):



1. Created a new class+files(cpp+h) called QgsGpsUdpConnection, which basically mimicks QgsGpsdConnection.

2. Made some changes to the GUI (radioButton for UDP plus configuration (port and host so far) lineEdits, plus one checkButton (to possibily add broadcast/multicast if needed, currently figuring out how UDP GPS works)

3. Added logic for managing UDP radioButton in qgsgpsinformationwidget.cpp, which also mimicks the behaviour for GPSD radioButton

3. Added logic for management of UDP connection in qgsgpsdetector.cpp, in the same way than the GPSD connection is managed but creating a QgsQGpsUdpConnection instead of a QgsGpsdConnection. (some parameters are passed to the udp connection but not used yet.

Success degree so far: Well, coding some debug strings mostly in qgsnmeaconnection.cpp:

src/core/gps/qgsgpsdetector.cpp: 169: (advance) Conexion UDP
src/core/gps/qgsgpsudpconnection.cpp: 33: (QgsGpsUdpConnection) ᎊ
src/core/gps/qgsgpsudpconnection.cpp: 34: (QgsGpsUdpConnection) localhost
src/core/gps/qgsnmeaconnection.cpp: 62: (parseData) numBytes:67
src/core/gps/qgsnmeaconnection.cpp: 75: (parseData) endSentenceIndex is -1
src/core/gps/qgsnmeaconnection.cpp: 76: (parseData) dollarIndex is -1
src/core/gps/qgsnmeaconnection.cpp: 77: (parseData) mStringBuffer length is 0
src/core/gps/qgsnmeaconnection.cpp: 78: (parseData) Firstchar is
src/core/gps/qgsnmeaconnection.cpp: 92: (processStringBuffer) endSentenceIndex is -1
src/core/gps/qgsnmeaconnection.cpp: 93: (processStringBuffer) dollarIndex is -1
src/core/gps/qgsnmeaconnection.cpp: 94: (processStringBuffer) mStringBuffer length is 0
src/core/gps/qgsgpsudpconnection.cpp: 41: (~QgsGpsUdpConnection) entered.

Seeing this homemade debug dump I think I can say:

1. The overall proccess works because I get bytes (67) when the GUI is properly configured, in my case, with port 5002. When I configure another port, no bytes are received/read

2. But I'm not able to put that data into mStringBuffer. So after that, the call to processStringBuffer(); doesn't work and it happens that QGIS thinks that the connection can¡t be stablished.

3. I suspect that it has to do with the way UDP is read, but can't be sure. I'm stuck here, but still trying to solve. Any help would be appreciated

Best regards

Jorge Tornero

#4 Updated by jtornero - over 3 years ago

Dear all:

I've made a PR #1112 regarding to this issue. I hope that everything is OK, but I have some doubts with the code and how it works (mainly regarding to QgsGpsDetector class).

Anyway, the patch makes it work as expected: QGIS is now able to listen to an UDP port and get broadcasted NMEA sentences.

Despite this is my initial patch and maybe (well... for sure) it need some refinement, I want to thank to all the people who has been so patient with me in these days with this stuff and related (git et Al.)

Best regards

Jorge Tornero

#5 Updated by Giovanni Manghi over 3 years ago

  • Category set to C++ Plugins
  • Pull Request or Patch supplied changed from No to Yes
  • Target version set to Future Release - Nice to have

#6 Updated by Alexander Bruy over 3 years ago

  • Category deleted (C++ Plugins)

#7 Updated by Giovanni Manghi about 2 months ago

  • Easy fix? set to No

Also available in: Atom PDF