XBee3 LTE-M does not always transfer all data.

Question

I have a XBee3 LTE-M module, mounted on a custom board that is communicating with a Cypress PSoC 5, running FreeRTOS 10.1

I'm trying to download a ~150 KB file (a firmware for OTA updates) using HTTP GET, and sometimes it works, but a lot of times the transfer just stops mid way through. I've been running the module at 9600 baud, but I tested at 115200 baud and had similar difficulty. I'm working the module in transparent mode.

Surprisingly, I also have the same difficulty using an XBee Wifi module communicating with a local server.

Are there any procedures or settings I'm missing that can help make the connections more reliable?

Thanks,

Chris

Answer 1

The 11410 firmware for XBee3 Cellular LTE-M/NB-IoT which will be released in the next month or so contains a fix that should resolve this problem.

Answer 2

Can you wireshark the server side? It isn't unheard of for internet providers (especially cell carriers) to fiddle with tcp or http to 'optimize' it and break things.

Answer 3

I'm grabbing files from a Linux laptop that's plugged directly into the router/AP that the digi is associated with, so there's no ISP or firewall involved.

I did wireshark the transfer directly from the server, both from the PSoC board/firmware, and from the digi development board and XCTU. Both showed massive amounts of TCP Window Full and TCP Retransmission packets, but that is to be expected since the conversation is funneling into a 9600 bps serial port. The difference is that the PSoC FreeRTOS code just stops at some point, but the XCTU powers through to completion.

Comments

Are you using hardware flow control over the serial connection between the PSoC and XBee Cellular?  If not, it's possible the PSoC is dropping characters in the transfer, maybe while it writes data to flash.

Can you compare what you've received to what you're sending to see if your dropping bytes or just stopping before completion?

Answer 4

I have determined the problem: according to the documentation of the XBee WiFi module, "...the device could send up to four characters out of the UART port after RTS is de-asserted." The LTE-M doesn't say that in its manual, but the fix for the WiFi module worked with the LTE-M one.

Though to be fair, I hadn't tested the LTE-M in a while.

The fix is to manually de-assert RTS when there is still room in the MPU buffers, rather than rely on the MPU UART device de-asserting RTS when its FIFO fills up.