- Sat Jul 11, 2020 1:58 pm
#87853
The thing is, the issue appears beyond the point of waiting for that high to low transition, I've got the change on the pin, so assemble a packet and send it to the server, then sit in a time limited loop awaiting the server's reply. if (digitalRead(PULSE_PIN) == PULSE_ON) {... wait for pulse to end, move to transmit code..... the pin read is left in the rear view mirror...
No messing with timers, no interrupts, nothing to interfere with the line by line execution of the code. Keeping that in mind, then referring to the Wireshark screen grab, the connection to the server is established, the wifiClnt.print follows, then wait for the reply. Works well repeatedly, until.... that wifiClnt.print is delayed, once in maybe 500 transmissions. I don't think I'm going to get to the bottom of this one, so.....
I've re-coded the software to use UDP and written a UDP server to listen for the incoming data and make the replies. Testing so far reveals 1 packet lost in over 8,800 sent. I know the "limitations" of UDP, but with that loss rate as opposed to the potential loss rate at a faster pulse period when something delays transmissions by up to 3 seconds, well it looks fabulous to me.
I wouldn't have noticed this "issue" at all should I not be needing something which is relatively time critical, so if this hasn't been seen previously, could be a heads up if it should affect someone else.
I did put a timing counter in the loop which waits for the reply to packet "print", and when the issue arises, the counter is huge, indicating the code is indeed in that loop waiting for something to happen.
I've surrendered.....