Chat here is you are connecting ESP-xx type modules to existing AVR based Arduino

Moderator: igrr

User avatar
By giovi61
#77916 UPDATE:
I solved the problem of communication between Packet Sender and ESP (I did not realize that Windows10 had blocked some features of the program for security reasons).
Now I could establish the connection between an ESP set as AP and 2 ESP set as clients. Co-operation works and now I have nothing left but to try and develop the system. In the coming days if I succeed in my intent I will share the scheme and the sketches used for those who were interested and who wanted to help improve this project.
If anyone has any advice on this, it is well accepted!
Thank you
User avatar
#93765 Hi giovi61

What's the status of your project?

Reason I'm asking: I'm trying to hook up two repeater lights to a fencing scoring machine.
One ESP8266 (Wemos D1) as controller reads the digital signals (green, red, 2 x invalid ) from the FIE certified scoring machine and sends them two ESP8266 (also Wemos D1), the clients. They will then drive two Neopixel discs (6 ring, 93 LED each) accordingly.
The controller WiFi is configured as AP and the two clients as STA. That way the system is self sufficient without the need for some external AP.
I only need a payload of 1 byte per message. Main issue is low latency, should be below 10mS, the faster the better.
So far I tried TCP sockets, UDP and webSockets.

TCP: was to slow, I had a latency 100mS or more
UDP: was very slow, particularly the multicast I used had a latency well above 100mS
webSockets: works rather nice, average latency 2-3 mS but every 20-30 seconds I get a few packets that are in the range of 30-60 mS

If you got it working reliable and with low latency with UDP I would be very much interested in the communication parts of your sketch.

Any other hint to a good implementation of UDP communication is appreciated

As soon as I get the latency fixed I will share the project as a whole.
User avatar
By Inq720
#93799 Sounds like a very interesting project.

I would agree about WebSockets as being both a more friendly way of doing a full system and for speed and reliability. I'm getting full HTTP requests back in the mid-teens milliseconds (counting the shipping of HTML/CS/JS file). Once fully established, WebSockets are sending ~30 byte messages at a rate 1 message / ms / client with 4 clients running. => Total server throughput about 130 KB/sec.

For the O.P. I would consider using the WebSockets if I was doing Browser clients, but WebSocket is just another layer on top of TCP and since you want to build ESP clients, there is no advantage. TCP should be just as fast as WebSockets once established.

Use some kind of custom handshaking at the beginning to establish a base-line delta Time relative to their own millis() or maybe even using micros(). For instance,
  1. once the client knows it has connected to the server
  2. client takes a t0 = micros() reading
  3. immediately ask the server's time.
  4. server returns its current hack = micros() value.
  5. on return client takes another t1 = micros() value.
  6. client calculates that half the "flight-time" was when the server took the reading.
  7. s32 deltaTime = t1 - (hack + (t1 - t0) / 2);
  8. When registering a hit, simply send t = micros() + deltaTime.

Anyway... once you establish a constant on each client, they could always send events with the adjusted time. That way, during game play latency won't matter even if the message shows up tens of milliseconds later, its the adjusted timestamp that counts, not the receive time. The server receives them and just compares the values of each combatant... lowest number wins! It doesn't even have to compare it to its own time. They already been normalized.

Caveat - TCP has some unknowns, like potential NAK's and flight time to and from are not always exactly the same. However those are unknowable at our level of coding. There is no better assumptions. You might do a test of several hundred times and see what kind of variability you get with a delta-Time calculation. See how many outliers you get.