This could 100% be something unrelated to my Argon, but here goes.
I am trying to control LIFX lights with the LAN API, which is UDP. I can send a blistering amount of UDP packets without issue to 1, or 2, or 10 bulbs. Say, 20/sec per bulb.
Once I add an 11th bulb in loop, it appears as if only a handful of the UDP packets are being delivered. Doesn’t matter if I add delays, I can even duplicate commands 2, 3 or however many times as long as I have 10 bulbs. The difference is dramatic. My test is simply changing the brightness. 10 or less, I can cause a seizure it flickers so fast. 11+ bulbs only a couple change state, slowly, total randomness.
I am scratching my head. The loop itself completes in 5-7ms, which is about the same as 10 bulbs. I am wondering if there is something in the UDP stack, like a very tiny address table that is doing something strange. This is all happening over WIFI. I have an Eero wifi setup if that might play into it.
Seeing your code might help.
Are you keeping the available sockets permanently occupied? These are a limited resource.
You should free your sockets as soon you are not using them anymore (UDP.stop())
Can your LIFX lights be setup for UDP multi- or broadcast?
I am using this project to talk to the LIFX Bulbs with tiny modifications for it to work on the Argon:
That is the meat of how it builds the packet and uses UDP.
I tried, after each packet, stopping the UDP client and beginning another session, and still have the same issue. Previously I just had the .begin() LIFX/UDP code in Setup(), below is a modified version where I just handle that on each light change. I did add a .stop method to the Arduino example above that related that to the _udp. But again, no change.
Does it use a socket for each target bulb? (sorry new to this). My intention is to constantly be changing each bulb several times a second, I thought it was best to keep it open. There is no response needed, or ack needed from the bulbs.
As I need to individually control them, I wanted to just directly send a packet to each light. Broadcasting when testing was actually worse.
However, I should state that if I just send out a single batch of commands, like turn all lights “red” and then delay for 5 seconds. The lights eventually do all turn red. Instead of being instant, it takes a couple seconds. (the loop’s speed was masking this) But I can see from the output that the Particle finished sending the packets in about 6ms. So, I feel like this may be more network related. But it is confusing me why 10 bulbs - perfect, 11 bulbs crazy town.
I’m not 100% familiar with the Arduino Ethernet lib, but I would suggest to check the return value of this->_udp->write() and this->_udp->endPacket(). It could be possible that the queue to send data is full and at some point, you are not able to post a new message until a previous one is out.