Current reliability of Mesh.publish messages

Connectivity BLE // NFC
#1

Understand that Mesh.publish is not reliable. As stated by @rickkas7

“At this time, Mesh.publish is not reliable. It uses UDP multicast, and thus Mesh.publishes could be lost.”

What I am observing is that my subscriber sees most every message, however, there are rare times where I only get part of the message.

So, for example, if the sender does

Mesh.publish("name", "abcd");

Sometimes the subscriber gets just “bc” or “bcd”, etc. I haven’t noticed the string getting out of order but that may be possible as well?

Is this the expected behavior given that it is using UDP multicast to send messages?
If so, I would need to implement a response message that the sender would need to receive and compare to ensure the response message exactly matched what was sent.

Xenon with AWS IoT Certificate
#2

That doesn’t sound like a typical failure mode for UDP.

With Particle.publish and Particle.subscribe they share a buffer so you can’t for example, publish from a subscribe handler or the data will be corrupted.

Perhaps something similar is going on with your mesh publish? I’m not sure that’s the case, but I would guess it’s something like that.

While UDP is not reliable, a single packet should still either make it through intact or be thrown out because of a bad checksum.

2 Likes
#3

gotcha. Thanks @rickkas7. I’m currently not publishing inside a subscribe. Basically, the temp sensor just publishes every 10 seconds and the Argon consumer is subscribed and displays on a feather OLED. Note I am hoping through two other Xenon Routers to make it to the Argon due to distance.

I’ll do some more testing on this by sending confirmation messages back and see if I can catch it and duplicate.

#4

FYI, I’ve been doing a Mesh.publish inside a Mesh subscribe handler and haven’t seen any issues. Basically my handler sends an Ack as I was having an issue with missed messages and having a the Sender repeat it’s publish periodically until it receives the Ack got my reliability up to 100%. When I was having issues with missed message the subscribe handler was not doing a publish.

#5

Have you been publishing some other data payload than you received and doing that before you looked at the actual data that came in to the subscribe handler?
The buffer share will only become an issue when you do that, otherwise you won’t notice.

#6

Good point; I fully extract the incoming data before I publish.