Udp.receivePacket() returns -1 on Argon - cannot figure it out

h00die · September 28, 2021, 3:08am

I’ve beat my head on this for a while, and I cannot for the life of me figure out what’s happening.

Working on Argon, DeviceOS 3.1.0 - I’m writing a simple UDP listener and looking for broadcast packets on a port, I see bytes with parsePacket, but when I receivePacket them, I get -1. Sometimes it works, but I can’t describe why it works and doesn’t catch all packets even in that case. If I make any changes, recompile, and reflash, it stops working again.

Any pointers welcomed.

SerialLogHandler logHandler;
SYSTEM_THREAD(ENABLED);
SYSTEM_MODE(AUTOMATIC);

const int localPort = 50222;
UDP Udp;

void setup() {
  Log.info("Connecting to XXXXX");
  WiFi.setCredentials("XXXX", "XXXXXXX");
  WiFi.connect();

  while (!WiFi.ready()) {
      Log.info("Waiting for wifi");
      delay(1000);
  }

  Log.info("Wifi connected!");  
  Log.info("localIP=%s", WiFi.localIP().toString().c_str());
  Udp.begin(localPort);
}

void loop() {
  char message[1024] = {};
  int packet_size = Udp.parsePacket();
  if (packet_size > 0) {
    Log.info("Packet Size: %i", packet_size);
    int udp_status = Udp.receivePacket((byte*)message, packet_size);
    Log.info("UDP Status: %i", udp_status);
    Log.info(message);
  }
}

Results in…

0000008323 [app] INFO: Waiting for wifi
0000009287 [net.ifapi] INFO: Netif wl3 link UP
0000009287 [system.nm] INFO: State changed: IFACE_UP -> IFACE_LINK_UP
0000009323 [hal] INFO: DNS server list changed
0000009326 [system.nm] INFO: State changed: IFACE_LINK_UP -> IP_CONFIGURED
0000009339 [app] INFO: Wifi connected!
0000009345 [app] INFO: localIP=192.168.1.196
[...]
0000491691 [app] INFO: Packet Size: 101
0000491691 [app] INFO: UDP Status: -1
0000491691 [app] INFO: 
0000494761 [app] INFO: Packet Size: 101
0000494761 [app] INFO: UDP Status: -1
0000494761 [app] INFO: 
0000495583 [app] INFO: Packet Size: 244
0000495583 [app] INFO: UDP Status: -1
0000495583 [app] INFO:

And what I should be seeing…

20:07:08.956558 IP (tos 0x0, ttl 255, id 41424, offset 0, flags [none], proto UDP (17), length 129)
    weatherflow.lan.50222 > broadcasthost.50222: UDP, length 101
	0x0000:  4500 0081 a1d0 0000 ff11 5711 c0a8 01e2  E.........W.....
	0x0010:  ffff ffff c42e c42e 006d 654d 7b22 7365  .........meM{"se
	0x0020:  7269 616c 5f6e 756d 6265 7222 3a22 5354  rial_number":"ST
	0x0030:  2d30 3030 3039 3730 3222 2c22 7479 7065  -00009702","type
	0x0040:  223a 2272 6170 6964 5f77 696e 6422 2c22  ":"rapid_wind","
	0x0050:  6875 625f 736e 223a 2248 422d 3030 3033  hub_sn":"HB-0003
	0x0060:  3933 3334 222c 226f 6222 3a5b 3136 3332  9334","ob":[1632
	0x0070:  3739 3834 3237 2c33 2e35 302c 3139 335d  798427,3.50,193]
	0x0080:  7d                                       }
20:07:12.028192 IP (tos 0x0, ttl 255, id 41427, offset 0, flags [none], proto UDP (17), length 129)
    weatherflow.lan.50222 > broadcasthost.50222: UDP, length 101
	0x0000:  4500 0081 a1d3 0000 ff11 570e c0a8 01e2  E.........W.....
	0x0010:  ffff ffff c42e c42e 006d 5c56 7b22 7365  .........m\V{"se
	0x0020:  7269 616c 5f6e 756d 6265 7222 3a22 5354  rial_number":"ST
	0x0030:  2d30 3030 3039 3730 3222 2c22 7479 7065  -00009702","type
	0x0040:  223a 2272 6170 6964 5f77 696e 6422 2c22  ":"rapid_wind","
	0x0050:  6875 625f 736e 223a 2248 422d 3030 3033  hub_sn":"HB-0003
	0x0060:  3933 3334 222c 226f 6222 3a5b 3136 3332  9334","ob":[1632
	0x0070:  3739 3834 3330 2c33 2e33 332c 3139 385d  798430,3.33,198]
	0x0080:  7d                                       }
20:07:13.052439 IP (tos 0x0, ttl 255, id 41429, offset 0, flags [none], proto UDP (17), length 272)
    weatherflow.lan.50222 > broadcasthost.50222: UDP, length 244
	0x0000:  4500 0110 a1d5 0000 ff11 567d c0a8 01e2  E.........V}....
	0x0010:  ffff ffff c42e c42e 00fc 9851 7b22 7365  ...........Q{"se
	0x0020:  7269 616c 5f6e 756d 6265 7222 3a22 4842  rial_number":"HB
	0x0030:  2d30 3030 3339 3333 3422 2c22 7479 7065  -00039334","type
	0x0040:  223a 2268 7562 5f73 7461 7475 7322 2c22  ":"hub_status","
	0x0050:  6669 726d 7761 7265 5f72 6576 6973 696f  firmware_revisio
	0x0060:  6e22 3a22 3137 3122 2c22 7570 7469 6d65  n":"171","uptime
	0x0070:  223a 3632 3735 3332 2c22 7273 7369 223a  ":627532,"rssi":
	0x0080:  2d31 342c 2274 696d 6573 7461 6d70 223a  -14,"timestamp":
	0x0090:  3136 3332 3739 3834 3330 2c22 7265 7365  1632798430,"rese
	0x00a0:  745f 666c 6167 7322 3a22 424f 522c 5049  t_flags":"BOR,PI
	0x00b0:  4e2c 504f 5222 2c22 7365 7122 3a36 3236  N,POR","seq":626
	0x00c0:  3336 2c22 6673 223a 5b31 2c30 2c31 3536  36,"fs":[1,0,156
	0x00d0:  3735 3431 312c 3532 3432 3838 5d2c 2272  75411,524288],"r
	0x00e0:  6164 696f 5f73 7461 7473 223a 5b32 352c  adio_stats":[25,
	0x00f0:  312c 302c 332c 3533 3539 5d2c 226d 7174  1,0,3,5359],"mqt
	0x0100:  745f 7374 6174 7322 3a5b 3234 2c33 5d7d  t_stats":[24,3]}

Any ideas?

h00die · September 28, 2021, 4:45pm

Here’s a clue - it did grab one, and note…

The Packet Size (in bytes) returned by parsePacket is 215
But udp_status (should be bytes read on success) returned by receivePacket is 191

When I look at the network dump, two packets came in (about 0.3sec apart), the first sized 215 and the second is 191 - and it looks like parsePacket sees the 215 one to get the size, but by the time I try to read it with receivePacket, it’s looking at the NEXT packet already and gets 191 bytes (short of the 215).

Guessing then that buffers are getting messed up next go around which results in -1.

But why would that be and how to fix?

Also, downgraded to 2.0.2, no change. Also tried turning off threads and putting system in manual, no change.

0000316890 [app] INFO: Packet Size: 215
0000316891 [app] INFO: UDP Status: 191
0000316891 [app] INFO: {"serial_number":"ST-00009702","type":"obs_st","hub_sn":"HB-00039334","obs":[[1632844770,2.33,2.81,3.16,352,3,944.28,10.21,80.71,2839,0.67,24,0.000000,0,0,0,2~
0000319147 [app] INFO: Packet Size: 101
0000319147 [app] INFO: UDP Status: -1
0000319147 [app] INFO:

vs.

08:59:31.934784 IP (tos 0x0, ttl 255, id 41885, offset 0, flags [none], proto UDP (17), length 243)
    weatherflow.lan.50222 > broadcasthost.50222: UDP, length 215
	0x0000:  4500 00f3 a39d 0000 ff11 54d2 c0a8 01e2  E.........T.....
	0x0010:  ffff ffff c42e c42e 00df 8dc2 7b22 7365  ............{"se
	0x0020:  7269 616c 5f6e 756d 6265 7222 3a22 5354  rial_number":"ST
	0x0030:  2d30 3030 3039 3730 3222 2c22 7479 7065  -00009702","type
	0x0040:  223a 2264 6576 6963 655f 7374 6174 7573  ":"device_status
	0x0050:  222c 2268 7562 5f73 6e22 3a22 4842 2d30  ","hub_sn":"HB-0
	0x0060:  3030 3339 3333 3422 2c22 7469 6d65 7374  0039334","timest
	0x0070:  616d 7022 3a31 3633 3238 3434 3737 302c  amp":1632844770,
	0x0080:  2275 7074 696d 6522 3a36 3733 3338 352c  "uptime":673385,
	0x0090:  2276 6f6c 7461 6765 223a 322e 3536 352c  "voltage":2.565,
	0x00a0:  2266 6972 6d77 6172 655f 7265 7669 7369  "firmware_revisi
	0x00b0:  6f6e 223a 3135 362c 2272 7373 6922 3a2d  on":156,"rssi":-
	0x00c0:  3434 2c22 6875 625f 7273 7369 223a 2d34  44,"hub_rssi":-4
	0x00d0:  322c 2273 656e 736f 725f 7374 6174 7573  2,"sensor_status
	0x00e0:  223a 3133 3130 3732 2c22 6465 6275 6722  ":131072,"debug"
	0x00f0:  3a30 7d                                  :0}
08:59:32.139712 IP (tos 0x0, ttl 255, id 41887, offset 0, flags [none], proto UDP (17), length 219)
    weatherflow.lan.50222 > broadcasthost.50222: UDP, length 191
	0x0000:  4500 00db a39f 0000 ff11 54e8 c0a8 01e2  E.........T.....
	0x0010:  ffff ffff c42e c42e 00c7 c561 7b22 7365  ...........a{"se
	0x0020:  7269 616c 5f6e 756d 6265 7222 3a22 5354  rial_number":"ST
	0x0030:  2d30 3030 3039 3730 3222 2c22 7479 7065  -00009702","type
	0x0040:  223a 226f 6273 5f73 7422 2c22 6875 625f  ":"obs_st","hub_
	0x0050:  736e 223a 2248 422d 3030 3033 3933 3334  sn":"HB-00039334
	0x0060:  222c 226f 6273 223a 5b5b 3136 3332 3834  ","obs":[[163284
	0x0070:  3437 3730 2c32 2e33 332c 322e 3831 2c33  4770,2.33,2.81,3
	0x0080:  2e31 362c 3335 322c 332c 3934 342e 3238  .16,352,3,944.28
	0x0090:  2c31 302e 3231 2c38 302e 3731 2c32 3833  ,10.21,80.71,283
	0x00a0:  392c 302e 3637 2c32 342c 302e 3030 3030  9,0.67,24,0.0000
	0x00b0:  3030 2c30 2c30 2c30 2c32 2e35 3635 2c31  00,0,0,0,2.565,1
	0x00c0:  5d5d 2c22 6669 726d 7761 7265 5f72 6576  ]],"firmware_rev
	0x00d0:  6973 696f 6e22 3a31 3536 7d              ision":156}

Colleen · September 28, 2021, 7:54pm

UDP parsePacket and receivePacket are mutually exclusive. The older combination of parsePacket() reads the data into a buffer and then you use read() to read a byte out at a time.

The newer, recommended method, is to use receivePacket() which reads the whole thing into your buffer at once. Since you called parsePacket(), that consumed all of the data in the buffer, so there was no packet to receive anymore, which is why it returned -1.

Hope that helps stop the head beating!

h00die · September 28, 2021, 8:18pm

Ahhhhhh - the magic “new way”. Ok. I revised my sketch to:

// loop() runs over and over again, as quickly as it can execute.
void loop() {
  char message[UDP_RX_SIZE] = {};
  int udp_bytes = Udp.receivePacket((byte*)message, UDP_RX_SIZE);
  if (udp_bytes > 0) {
    Log.info("UDP bytes read: %i", udp_bytes);
    Log.info(message);
  } else if (udp_bytes < 0) {
    Udp.begin(localPort);
  }
}

And that seems to be working nicely!!!

I was nearly there!

Colleen · September 28, 2021, 8:31pm

Haha must really be magic! You were really close. Glad it’s working now!

system · March 30, 2022, 8:32am

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
UDP is not working on Argon Firmware	8	1416	December 7, 2018
UDP::receivePacket() not documented well Community Resources	6	2200	December 11, 2019
WiFi.Ping() returns -120 on Argon Troubleshooting argon	5	936	January 18, 2020
UDP Delays on Argon Troubleshooting argon , photon	15	1441	October 9, 2019
Help with UDP getting all characters in packet and filling variable Firmware	8	2183	January 5, 2019

Udp.receivePacket() returns -1 on Argon - cannot figure it out

Related topics