ESP8266 Developer Zone

[Solved] Re: how to query UDP transmit status

2015-11-20T21:55:34+08:00

You will see a callback indication - but it doesn't mean the package is on journey.
Unfortunately the callback occures BEFORE esp_sendto returns.

My testcase contains 8 datagrams, collected during boot up, which should be send as soon as we have a Wifi connection.
case 1: send next datagram directly after esp_sendto
callback shows up DURING the esp_sendto. Only the last 3 (three) datagrams show up on receiver side.
The call to esp_sendto doesn't produce an error code - it always shows success.
Also, the callback doesn't show any usefull information (error, internal overflow, internal OoM).
case 2: send next datagram in callback function (like the TCP handler does)
the esp_sendto gets nested, after approx. 4-5 packages the esp_sendto returns error -14.
Unfortunately, the sender can't check this status, because callback is DURING ets_sendto.
Only the first 4-5 packages arrive at the destination, rest gets lost due to OoM error.
case 3: the WORKING case
The callback fires a system_os_post which in turn sends the datagram. All packages arrive at the destination.

Code:

No.  Time           Source      Length Info
1430 35.988406 192.168.254.82   105    USER.NOTICE:  - ems-link02 esp-link 0.129427 1 Reset cause: 4=restart
1431 35.989382 192.168.254.82   142    USER.NOTICE:  - ems-link02 esp-link 0.131356 2 exccause=0 epc1=0x0 epc2=0x0 epc3=0x0 excvaddr=0x0 depc=0x0
1436 36.003432 192.168.254.82   128    USER.NOTICE:  - ems-link02 esp-link 0.148481 3 Flash map 4MB:512/512, manuf 0xC8 chip 0x4016
1437 36.016850 192.168.254.82   100    USER.NOTICE:  - ems-link02 esp-link 0.163107 4 ** esp-link ready
1448 36.032175 192.168.254.82   119    USER.NOTICE:  - ems-link02 esp-link 0.172913 5 SNTP timesource set to 192.168.254.1
1449 36.045156 192.168.254.82   100    USER.NOTICE:  - ems-link02 esp-link 0.186165 6 initializing MQTT
1450 36.059739 192.168.254.82   112    USER.NOTICE:  - ems-link02 esp-link 0.197549 7 initializing user application
1451 36.074040 192.168.254.82   108    USER.NOTICE:  - ems-link02 esp-link 0.209346 8 waiting for work to do...
2097 61.809809 192.168.254.82   127    USER.NOTICE:  - ems-link02 esp-link 28.976948 9 Accept port 23, conn=3fff5af8, pool slot 0

Statistics: Posted by Strolch — Fri Nov 20, 2015 9:55 pm

Re: how to query UDP transmit status

2015-11-19T00:03:03+08:00

Howdy,
I am not an expert on UDP processing ... but may I ask some questions?

Are you saying that you ARE getting a callback indication that indicates the UDP datagram was sent? If so ... would than not be the indication as to when it is safe to send the next packet?

Statistics: Posted by kolban — Thu Nov 19, 2015 12:03 am

[Solved] how to query UDP transmit status

2015-11-18T22:41:16+08:00

when sending more than 3 UDP packages in a row only the last three are going over the wire.

Code:

   while (syslogQueue != NULL) {
      DBG_SYSLOG("syslog_udp_send: %s\n", syslogQueue->msg);
      espconn.proto.udp->remote_port = syslogHost.port;               // ESP8266 udp remote port
      os_memcpy(&syslog_espconn.proto.udp->remote_ip, &syslogHost.addr.addr, 4);   // ESP8266 udp remote IP
      DBG_SYSLOG("*** before %s\n", "espconn_send");
      res = espconn_sendto(&syslog_espconn, (uint8_t *)syslogQueue->msg, len);
      DBG_SYSLOG("*** after %s\n", "espconn_send");
   }

udp_sent_cb gets triggered BEFORE espconn_sendto returns to the caller, so I can't use it as indicator:

Code:

100592> syslog_udp_send: host=192.168.254.216:514
100596> syslog_udp_send: <13> - ems-link02 esp-link 0.186084 6 initializing MQTT
100603> *** before espconn_send
100606> syslog_udp_sent_cb: 0x3fff2d30
100609> *** after espconn_send
100612> syslog_udp_send: <13> - ems-link02 esp-link 0.197466 7 initializing user application
100620> *** before espconn_send
100623> syslog_udp_sent_cb: 0x3fff2d30
100627> *** after espconn_send
100629> syslog_udp_send: <13> - ems-link02 esp-link 0.209266 8 waiting for work to do...
100637> *** before espconn_send
100640> syslog_udp_sent_cb: 0x3fff2d30
100644> *** after espconn_send
100646> syslog_udp_send: <13> - ems-link02 esp-link 40.475910 9 Accept port 23, conn=3fff7600, pool slot 0
100657> *** before espconn_send
100663> *** after espconn_send
100666> syslog_udp_send: <13> - ems-link02 esp-link 100.585642 10 Accept port 23, conn=3fff6298, pool slot 0

(numbers at the beginning of line are ms since boot)
Any other suggestions than gating the messages with os_timer_*?

Statistics: Posted by Strolch — Wed Nov 18, 2015 10:41 pm