If the additional range of an external antenna is not needed I use M5Stamp Pico. Link here. Very useful for other (no ArduPilot related) hobby projects too.
I applied several performance and feature enhancemants to the code:
Highly optimized serial handling using buffering etc.
Option to change TX power
Option to change radio data rate from 1 Mbps to 2 Mbps
Option to use integrated USB serial and separate payload and monitoring data
I am using it with the tiny XIAO ESP32C3 boards which weigh only about 3g including foil antenna and also support Bluetooth 5.0:
Although these C3 modules run at “only” 160 Mhz, bitrates of 921600 were no problem after the performance optimizations. I could even use it for video transmission at 400 kpbs:
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.
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.
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.
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.
PROTOCOL_TCP and PROTOCOL_UDP can 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.ino in a separate sketch folder to make an ESP32 TCP or UDP client that connects to the ESP-Serial-Bridge. Edit client_config.h and 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.
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!
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.
. Can’t wait to give the update a shot!
. 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!