ESP8266 Community Forum

- Tue Apr 07, 2015 4:42 am #13730

I suppose it works when you start a separate UDP-server and UDP-browser on your Windows, right?

I seem to be able to get it to work with a python programme with bi-directional communication although I might be misunderstanding you. This code below sends "on" every two seconds and I can see the reply("light on") from the ESP being printed by the programme every two seconds as well.

Your Python script works on my Mac too, and works as you described. The "light on" reply is received by the Python script.

I principle the hardcoded IP and Port number in the sketch could be replaced by the remoteIP() and remotePort() of the UDP class. Going to try that later, will report back.

Thanks!

Last edited by gerardwr on Tue Apr 07, 2015 5:03 am, edited 1 time in total.

- Tue Apr 07, 2015 5:02 am #13731

I principle the hardcoded IP and Port number in the sketch could be replaced by the remoteIP() and remotePort() of de UDP class. Going to try that later, will report back.

I changed your sketch accordingly and it still works. This means that the hardcoded IP number of the "Python script side" can be eliminated.

Code: Select allvoid sendMessage(char data[]) {
  port2.beginPacket(port.remoteIP(),port.remotePort());
  port2.write(data);
  port2.endPacket();
}

- Fri Apr 10, 2015 6:25 am #14095 I want to share my findings since I've tried unsuccessfully to implement an NTP client.
I can have consecutive incoming and outgoing UDP traffic if I use two instances of WiFiUdp. The listener works with a fixed port that I can assign a number to. The transmitter works with an arbitrary port number (starts with 4097) that I cannot modify. If my loop contains the UDP.beginpacket() call, every time it gets called, the port number used by the transmitter gets incremented by 1. If I put the UDP.beginpacket() in the SETUP part of the sketch, the port number remains the same for each consecutive packet.
When I let the port number increment, at some point the code hangs to a watchdog since it exhausts the heap. I verified it by monitoring which port number the code gets to, then compiling the code with less free RAM by allocating a chunk of RAM for some large array and noting that the port number the code now gets to is lower meaning there was less free RAM for the different UDP instances.
UDP.stop() does not seem to do anything.
If I first open the outgoing port (at arbitrary 4097) and then try to add a UDP listener at that same port, I get port open failure.
This behavior breaks the possibility of having an NTP client.
Nir

- Sat Apr 11, 2015 7:50 am #14171 To make sure I opened a formal "issue" in IGRR's github here:
https://github.com/esp8266/Arduino/issues/64