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.
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.
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.
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.
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.
