Make a PR and I’ll review for inclusion.
Feel free to implement UDP as well 
I love those XIAO boards.
You have done some awesome work getting this to be usable! Some confusion I have however is you mentioned how Dronebridge didn’t have a way to operate in station mode. From what I’ve seen on all these different forks( ESP-Now, ESP-Now-Burst), there is still no station mode capability. Have you moved away from a LAN connection environment with the lawnmower to esp32<->esp32? Maybe I’m missing a piece of information.
Personally I have a strong Wi-Fi environment where I need to pass this serial data for the lawn mower. If I had the capability to send and receive data to and from multiple esp32 (direct and without GCS involvement) over LAN, then it would be a win for me.
@JMBCreations, this is what you want. It’s literally the first in the series of these projects and operates in station mode on the user’s wifi network.
On the other hand, the ESP-Now variants allow direct comms between ESP32s, which results in increased range due to the low bandwidth and minimal overhead, as well as allowing the flexibility to operate outside of an existing wifi network.
I haven’t moved toward or away from anything. I use each where appropriate/necessary.
So I am currently using that ESP-serial-bridge and it work great to feed telemetry and RTCM data to Mission Planner! What I’m talking about is taking mission planner out of the loop and receiving the data on another esp32 while operating on an existing network. I don’t currently see a way to point the receiving ESP32 to listen to a specific IP and Port using your existing code. My end goal is having ESP32 <-> Router <-> ESP32.
I greatly appreciate all the work you and other have put into this. I’m no expert when it comes to scripting and coding, so again I could be missing something.
To what end? What is the receiving ESP32 providing?
The ESP32 on the rover could receive RTCM3 packets from the RTK Base over an existing Wifi network. Additionally, the same ESP32 on the rover could send out telemetry data to the same network in the case you wanted to check the status of the river over mission planner.
Fair enough - I hadn’t considered that use case. I suppose also, just for sake of completeness, it’d be good to provide a client companion to the serial bridge.
I did some testing today on such a thing, and I think I’ll have an update soon.
Of note, the WiFi bridge has no significant packet size limitation, so RTCM3 should work just fine. It’s only the ESP-Now variant that forces a bit of “magic” to handle large messages.
1 Like
I guess I could have done a better job explaining myself had I used “Client” and “Host” 
. Can’t wait to give the update a shot!
looks like great work! I will try the AP mode and the ESPnow variant soon.
Anyone already tried this?
- Comparison to dronebridge, especially range? (i currently work with dronebridge and am very happy but with the directivity of wifi and a little bit with range)
- I am thinking to get a dual antenna esp32 (ESP32-WROOM-DA) at least for the receiving part on the ground. Did anybody triy this?
– Is the code easily adoptable?
– Is there any version with just 2 antenna connectors? I could not find any yet, but modification should be always possible.
1 Like
I gave up on Dronebridge before I ever saw it work, so I have no real point of comparison.
However, if you’re using a WiFi network, the range limitation will almost certainly be a combination of network coverage and the tiny antennas typically used on ESP32s. The exact packet architecture probably won’t change that by any significant margin.
If you use ESP-Now, range is significantly increased over most off-the-shelf WiFi access points (unless you have a broad mesh network).
I’m unaware of dual external antenna ESP32s, but the firmware should work fine on the DA variant. It still has an Xtensa processor and shares pin compatibility with other variants.
I forgot the dual antenna esp32 chips existed. I remember seeing them but for some reason it didnt register that it actually had 2 separate antennas.
1 Like
Major update (UDP + client sketch)
- Fixed compatibility with Arduino framework 2.0
- Added compatibility with PlatformIO.
- Implemented
PROTOCOL_UDP(UDP broadcast) -
PROTOCOL_TCPandPROTOCOL_UDPcan be used simultaneously, though doing so may result in serial traffic conflicts if your client connections are not managed carefully. - Added
ESP32-Serial-WiFi-Client.inoin a separate sketch folder to make an ESP32 TCP or UDP client that connects to the ESP-Serial-Bridge. Editclient_config.hand upload to a second board. - Multiple bugs (possible buffer overruns) are fixed in the latest commit(s).
If you’ve been successfully building using the Arduino IDE, you may need to update your ESP32 framework to use the updated version.
5 Likes
Excited to use this but already running into some issues. I have everything uploaded to the ESP32, I can see it connected to the network (on Unifi AP and ping it) but am unable to receive anything on mission planner (MP) or QGroundControl (QGC) over TCP or UDP. Using Wireshark I can see there is packet being sent over UDP and TCP. MissionPlanner just says “no Heartbeat packets received”.
I tried to revert to the original release with just TCP, but because I updated my library I’m now getting all sorts of errors when I verify. Looks like my only path is forward.
I tested very successfully over both TCP and UDP. Make sure you have the baud rates set properly. You should be using the file named ESP-Serial-Bridge.ino and config.h to configure.
Also make sure the ports are not firewalled.
You can monitor ESP32 debug output over USB as well.
Never hurts to double check that you’ve got the RX/TX wiring correct (including your board’s pin out - don’t just blindly connect to the pins labeled RX/TX on the ESP32), and that the autopilot parameters are set to output MAVLink over the UART of choice at a matching baud rate.
I totally forgot to change the baud rate on the serial port on the autopilot 
. On the bright side it now works like a charm! Going to give the client a try when I get some time. One step closer to getting my lawnmower untethered from the computer!
1 Like
Excellent. Now that it’s working, recommend building with debug output disabled. I cautiously recommend UDP as the method of choice, but I have not tested long term for stability.
Hi Yuri,
Struggling to build/configure your ESP Serial Bridge code. I am very new to code but have been around RC rovers for a number of years.
I am mechanically minded and can build most things, but coding is where I fall down and Google hasnt been too much help in this instance.
I am using ESP32 Wroom 32 for my project, I dont suppose you have an example Serial_Bridge code thats filled in so that I can set my own parameter requirements please.
Thanks
I don’t know what you’re asking for. The examples are what exist on GitHub.
What I’m looking for is to able to see a completed example with all parameters filled in. This way I am able to understand and learn what is needed to make the code work.
There aren’t any blanks. It should build as-is. The only things to potentially change are in config.h.