LTE Data rate speedup


#1

Hi all, I’m attempting to use the boron LTE in a low power sensor logging application. We record 16 bit int’s at 100 hz then send that data on the hour. it comes out to about 720 kByte. I’m trying to reduce as much power as possible obviously, I use an external mcu to do the sampling and timing, then I boot the boron to sendoff the data. Problem is that theres a data rate limit of the publish fxn. 620 bytes per second turns into about 20 minutes of on time to send off this data :frowning: this is a lot of on time for the boron, I was hopping to get that into the range of a couple minutes, just aquire and send as one big packet. I understand that this is not the fastest chipset on the market but the datasheet for the modem advertises 60kbit > 7kByte speeds for the narrow band edition, are these attainable in this implementation?

one option would be to publish to the modem then sleep the mcu while the data is sending, this is good but not great as the sleep current is still pretty high… I’m pretty sure a larger bw modem would be more efficient in terms of joules/byte in this application. Is there another version with a different modem?

Even so, I’m not seeing the data rate advertised in the ublox datasheet, does anyone have any ideas on how to attain that?


#2

Do you need your data to be encrypted?
If not, you can send the data via TCPClient without a rate limit other than the maxium throughput of the modem and cell network.


#3

thanks scruff, I’ll try this tonight. I’m not sure if we need to encrypt this…


#4

@ccunningham I’ll add to this thread that since my original post, it seems a number of improvements / bug fixes were made to deviceOS, and I have managed to achieve speeds of around 30-40kbps using the UDP client. If you are not getting these speeds, try different releases of deviceOS as it appears that some updates impact performance substantially.


#5

nathanja, thanks for the reply. Did you ever get decent(above 1kbyte/s) throughput with tcp? I kept having the same problem where it would hang and sort of brick itself after the 1st write. I guess you’re delay method works? It’s funny, in the docs it specifically says that it’s a blocking fxn. Anyways, I’ll try udp, but I’m a bit worried about how that’ll come out on the other end…


#6

Are you splitting your data into chunks of not more than 512 byte each?
If not, try it.
Also check the return value of client.write() call for -16 and when found, resend the same chunk with a short delay…