Particle Boron LTE Speed / Bandwidth Limit

boron
Tags: #<Tag:0x00007fe2224dc838>

#1

Hi,

I’m evaluating a Boron LTE here in the States for a project that for a short period of time streams data at a few kBps up and down. In the process of prototyping with the internal SIM, I’ve noticed that if I send more than about ~1kBps (~8kbps) in both directions over UDP (in packets up to ~500 bytes) to my own host on the public internet I appear to be throttled, with my traffic being black-holed until I reboot the Boron. The Boron usually thinks it is successfully sending UDP packets as no errors are returned while things are black-holing.

It looks like according to the data sheet for the SARA-R410M the max data sheet is 375kbs up/300kbs down so I’m guessing this is either firmware throttled or carrier throttled. So:

  • Does the Carrier/MVNO with the internal SIM throttle below the theoretical speed limit fo LTE-M? This would indicate I can switch to 3rd party carrier and perhaps get around this.
  • Does DeviceOS throttle transmission somewhere? This would indicate I can compile my own firmware with modified throttling logic.

Thanks,
Ben


#2

Alright, I’ve got some interesting findings:

  1. A 3rd party sim (h2o, an ATT MVNO) works slightly faster but still exhibits issues with black-holing, so it doesn’t appear to be the carrier.

  2. The black holing starts more or less when the device rapidly starts blinking cyan, which the status page seems to indicate is “Connecting to the Cloud.”

Given these hints, I’m theorizing that the Particle Cloud connection is struggling in the presence of other transmissions and turning everything else off in the process in an attempt to salvage things.

To test this theory, I modified my simple app (that just spams UDP packets to an echo server) to wait for Particle.connected() to report true, immediately call Particle.disconnect() and then commence spamming. The device breathes green (which means “Cloud not connected”) and I get much faster data rates (I’ve tested up to 5kBps which is enough for my needs).

So it appears that Device OS is indeed the culprit. I don’t care a whole lot about the cloud functionality at the moment so I’m happy to live with this trade-off but it’d be nice to figure out why this failure mode appears to be unrecoverable. If I get a chance, I’ll start poking through the code for DeviceOS today.

Cheers,
Ben


#3

It’s my understanding that you could use SEMI_AUTOMATIC mode and perform Cellular.connect() instead of Particle.connect(). This allows the use of raw TCP and UDP without the Particle cloud.
Might be worth a try?


#4

Particle Cloud connection also uses UDP on the cellular devices. If you are in a state where UDP packets get lost, the UDP packets handling the cloud connection may also be lost.

If the device does not receive answers back from the cloud (because request or answer packets are lost), the connection is considered as lost and will be reestablished, visualized by the led blinking cyan.


#5

I’ll have to experiment a bit more with SEMI_AUTOMATIC / MANUAL modes, good suggestion.

I actually did my math wrong and need a bit more bandwidth than I initially wanted so I’m back to the earlier problem.

I was looking at the datasheets for the u-blox modem and it appears that the UART is limited to a baud rate of 115200, which is quite low (14.4kB/s) not including parity bits, however they factor in). The modem can theoretically talk over USB but I don’t believe the nRF chip can drive it as a host.


#6

Actually, it looks like the datasheet has a typo: running the AT command AT+IPR=? reports that the UART can go up to 4000000 baud.


#7

But the twist here is that the Boron firmware changes the default modem baud rate to 921600 except when the running on the Sara R410 (probably because the datasheet doesn’t report that it’s supported but the device itself reports that it is).

Now to compile DeviceOS from scratch with that guard removed (so things run at 921600 to see if some of my problems are alleviated)…

Update: commenting out the guard causes modem initialization to fail :frowning:

Last update for tonight:

  • You can’t set UART speed in a normal application because it’s not allowed once muxing has started across the serial port.
  • It appears you can’t set UART speed at all on the SARA 410M – any change to anything other than 115200 errors out and fails modem initialization.
  • Sending UDP packets via AT commands seems to be far more reliable than the normal UDP calls. Unfortunately the throughput is also far slower (around 3kB/s).
  • Something in the muxer seems to be super wonky (suggested by someone else in private), but I need to learn more about PPP and the like to come up with next steps (I’m picking this all up as I go along).