Long story short, the u-blox SARA-R410M-02B modem is limited to 512 bytes per “read” call, for either TCP/TLS or UDP. This is why you see the upper bound of 512.
Thank you for pointing this out. That answers that mystery!
There is another thing i have questions about.
When doing what I described above over UDP I only receive 1 0xCE frame of 512 bytes with the sequence {1…155}.
If i then send another data to that socket
ie. echo “hello” > nc -p 12345 -u xbee3 4445
I receive two 0xCE frames; one of 404 bytes containing the sequence {156…256} and one of 6 bytes containing "hello
".
If I send a larger payload instead,
ie. echo {1…256} | nc -p 12345 -u xbee3 4445
I still receive two 0xCE frames; one for 404 bytes containing the sequence {156…256} and one containing 512 bytes {1…155}. With the remaining data being held until additional data is received.
This behavior does not happen over tcp and only happens when done from Host machine -> xbee3
If i send the same payload from one xbee3 to another or xbee3 -> host, it fragments correctly (512, 404) and two 0xCE frames are emitted.
This same behavior happens if i send “hello” from a different host machine than the one used to send the initial {1…256} which tell me that its not my host machine waiting to flush the second half.
It looks like for memory efficiency reasons, the XBee 3 Cellular LTE-M firmware can only properly handle received UDP datagrams of up to 512 bytes in size - at least, right now. I will submit a ticket to potentially look at improving on that in the future.
In our experience most IoT application designs that use UDP don’t even use messages that are that large. Since you’re just using shell expansion right now, I’m guessing you’re only playing around. Do you have any particular UDP-based protocol in mind?