GPS over wifi connection

What are the best/good ways currently to implement GPS over wifi?

I have succeeded in tests at least with the following method (with just trial lisences of the software):

  1. Sharing a mobile hotspot from my phone, where both AOG pc and wifi GPS antenna are connecting.

  2. Have Virtual Serial Port Driver program to create two joined virtual serial ports

  3. Have a TCP COM BRIDGE program to connect to wifi gps in TCP Client mode and forward this connection to another of the joiner virtual serial ports.

  4. Have AgIO connect to the other one of the joined virtual serial porta to read data just like any COM port data.

Problem being the cost of these apps… Some 140 USD for Virtual Serial Port Driver and 50-65 € for TCP COM BRIDGE

If there are better options that would be great. The best would of course be to have AOG connect to ESP32 of the GPS unit as a TCP Client.

1 Like

Use UDP directly instead of converting serial to TCP and back. The biggest problem with wifi is that packets are grouped into large blocks and this causes delays and out of order packets. I think it only works with the ESP8266/32 because it allows you to send the data without grouping but if you go through a router instead of direct to the ESP it could group them again.


By “use UDP directly” I mean use a Nano with Ethernet shield, see the Arduino sketches included with AoG and the connection diagrams.

I agree with m_elias, I did it this way, I have no problem. I used USR-TCP232-T2 and mini simplertk2_blite.

1 Like

Yes, for the GPS, this works well to get UDP to the tablet.

Ethernet indeed works fine, but that’s another cable and having got used to just 12V power + wifi makes me disgust adding unnecessary wires.

Plus I have 2 Fieldbee L2 rovers that don’t have bluetooth or ethernet, but instead ESP32 + wifi. I get RTK corrected NMEA via wifi.

I have thought of soldering a bluetooth module inside the rooftop unit. Another option is to solder wires in the external power+serial+xxx connector to the right wires and use serial to ethernet converter at the other end of the cable. But wifi would be just so simple in this case. I understand with simpleRTK2b it’s a different story.

Also from Septentrio is available (to make) the Mosaic X5 chip with integrated ESP32 as follows: GitHub - septentrio-gnss/mowi: Mowi is an Open Source hardware project that combines a compact Septentrio's GNSS receiver mosaic with a wireless ESP32 Wrover module

Wifi would again be the choise nr 1.

1 Like

1 year ago an AGOPENGPS user sent us a feature request about integrating NMEA sending over UDP to tablets and RTCM transmission to AGOPENGPS over NTRIP via ESPrtk module.
The email is very long, below are 2 snapshots of his request.

Just like what m_elias describes, NMEA/PSTI messages will be parsed before sending over UDP to make sure it’s not corrupted.
The speed can be up to 50hz.
The discussion ended when we released version 3.9.85 for his request.

We later released an updated version of this feature with 6 types of data bridges:

    1. TCP Server AP.
    1. TCP Server STA.
    1. TCP Server Client.
    1. UDP Server AP.
    1. UDP Server STA.
    1. UDP Server Client.

You can see more here :

So in addition to the solutions you guys mentioned above.
Hope you can try with ESP32 running ESPrtk.

I tried the C099-F9P Application board via Wifi:

1 Like

The one thing you have to be very careful with wifi is that it isn’t real time. Since there is only 1 air space wifi multiplexes data between the different connections so it will send out bursts of data and then the next channel as well.

Wifi works great, solid connection, can send easily 50 hz gps… BUTTTTTTTTT and is a big but, it sends several fixes at once which aog parses as just one fix ( the latest one). So if you send 10 hz it really works out to be 3 groups of fixes and becomes 3 fixes instead of 10. I couldn’t get a router to stop doing that so be sure you are getting somehow a QOS approaching real time.

I know Matthias got it working with using the esp32 as a hotspot and some other voodoo for a particular setup, but generally it doesn’t. That is where the recommendation of wired udp comes from.


I was able to integrate wireless UDP communication into open grade using an ESP32. Seems to be stable and can’t find much for latency in the pAckets. It configures the ESP32 as a AP, that you then connects to from your tablet. The only information sent over that network is the (in my case) OpenGrade data, so shouldn’t run into other traffic. Just reads the serial data from the RTK2B and then broadcasts over the UDP network.

Now this sketch obviously wont compile as I I just ripped bits and pieces out of my main file but maybe enough to help someone to implement it in AOG.

Another neat option that this opens up is wireless module that all Communicate on the same network, and the only wires that would need to ran to them are to power those modules. I may end up pulling my hair out with wireless issues but for now it seems to be a viable option.

Wireless_UDP.ino (4.6 KB)

1 Like

hi, how did you end up connecting the l2 rover? Isn`t there a way to connect it via a hotspot on the tablet? kind of the same way you use it normaly with the field bee app. i am kind of new to al this. and want to use the most of wat i already have a L2 base and rover. thanks

Unfortunately AOG does not support such a type of position data transfer that would work over the tablet’s wifi hotspot.

I think one would need to modify Fieldbee L2 receiver settings in UCenter so that it is sending just VTG & GGA messages over another serial port (e.g. bluetooth module or RS232) for AOG. You would also need to buy the RS232 including Fieldbee cable or modify the original cable a little by soldering wires to the plug so that you get whichever communication you need. There are at least 2 serial ports coming to the receiver’s socket, so no need to solder anything inside the unit.

Just a thought, if you use udp , then connect fieldbee to WiFi router. I think the package issue will not be the same, because fieldbee send continuing data.