stats for roundtrip ping latency and sustained bandwidth?

[ericfont]

Not a bug report, but I have an inquiry. Has anyone measured the roundtrip ping latency and sustainable bitrate between two of these devices in the same city? I realize that the stats would depend on the mobile carrier and city, but if someone at sparkfun headquarters (Boulder?) that would be very informative and appreciated.

I see from the asset tracker description is "offers Secure Cloud LTE-M and NB-IoT data communication" and I'm looking at the chart on wikipedia which shows the see LTE-M bitrates from 1 Mbit/s to 7 Mbit/s depending on version and latency 10–15 ms for LTE Cat M1 (with info for other versions blank). Which doesn't tell me enough

And I guest best to measure with the the Teensy M1 as the controller cause that seems to be the faster M2 board from sparkfun.

(FYI, I would like these stats cause I would like to determine if it is feasible to send realtime MIDI or OSC packets or maybe even low-bitrate low-sampling-rate WAV or OPUS audio before buying a couple of the asset tracker boards and M2 MicroMods)

[ericfont]

I see from https://www.sparkfun.com/products/retired/17583 that the u-blox SARA-R510M8S module which is used in those boards uses "LTE Cat M1/NB2 radio access technologies" and "1200kbit/s data communications", so I guess that 10-15 ms latency might be what it is, but I would still very much appreciate a measurement using the sparkfun asset tracker board w/ Teensy.

[ericfont]

looking at u-blox's datasheet I see a slightly more specific answer:

LTE category M1:
up to 1200 kbit/s UL
up to 375 kbit/s DL

[ericfont]

so I guess that answers the question about maximum up and down bitrate. But I am still curious to get an actual realworld latency measurement using between two teensy MicroMods using this library to do a roundtrip ping at the sparkfun headquarters if you could, before I close this issue.

[PaulZC]

Hi Eric (@ericfont ),
This is a reasonable request and we will try and get to it as soon as we can. It will involve some software development and test though. We will need to write either a peer to peer data transfer example, or a simple ping server (on Arduino or PC). We do plan to use these modules for transferring GNSS RTK data, but we don't yet have the software to do that either.
Best wishes,
Paul

[PaulZC]

Hi Eric (@ericfont ),
OK. A ping test might be easier than I thought. You can configure the SARA-R5 to respond to pings using the +UDCONF=4 command. Provided the network will allow it, my plan would be to have: one SARA-R5 connected to a PC and configured to respond to pings using m-center; a second SARA-R5 / Asset Tracker connected to Arduino and running the Ping example.
I do have two boards, but, right now, I've only got one SIM...
I'll try this test as soon as I have a second SIM.
Best wishes,
Paul

[PaulZC]

Hi @ericfont ,

Apologies for the very slow update...

I finally remembered to buy another SIM. I'm based in the UK and O2 (owned by Telefonica) are the only provider in my area offering LTE services.

I've given PING a try. My two boards can both ping Google - with round trip times of 67-108ms and 77-323ms. But neither can ping the other: the -1 at the end of the +UUPING response indicates a timeout:

AT+UPING="www.google.com"

AT+UPING="www.google.com"

OK

+UUPING: 1,32,"www.google.com","216.239.38.120",113,108

+UUPING: 2,32,"www.google.com","216.239.38.120",113,76

+UUPING: 3,32,"www.google.com","216.239.38.120",113,87

+UUPING: 4,32,"www.google.com","216.239.38.120",113,67

AT+UPING="10.160.147.82"

AT+UPING="10.160.147.82"

OK

+UUPING: 1,32,"10.160.147.82","10.160.147.82",113,-1

+UUPING: 2,32,"10.160.147.82","10.160.147.82",113,-1

+UUPING: 3,32,"10.160.147.82","10.160.147.82",113,-1

+UUPING: 4,32,"10.160.147.82","10.160.147.82",113,-1

AT+UPING="www.google.com",3,256,5000,32

AT+UPING="www.google.com",3,256,5000,32

OK

+UUPING: 1,256,"www.google.com","216.239.38.120",113,323

+UUPING: 2,256,"www.google.com","216.239.38.120",113,122

+UUPING: 3,256,"www.google.com","216.239.38.120",113,77

AT+UPING="10.160.228.88",4,32,10000,32

AT+UPING="10.160.228.88",4,32,10000,32

OK

+UUPING: 1,32,"10.160.228.88","10.160.228.88",113,-1

+UUPING: 2,32,"10.160.228.88","10.160.228.88",113,-1

+UUPING: 3,32,"10.160.228.88","10.160.228.88",113,-1

+UUPING: 4,32,"10.160.228.88","10.160.228.88",113,-1

I suspect the O2 network is blocking the SARA-SARA pings as both say that ping responses are enabled:

AT+UDCONF=4

AT+UDCONF=4

+UDCONF: 4,1

OK

I will try and figure out why the SARA-SARA pings are being blocked.

Best wishes,
Paul

[PaulZC]

Hi Eric ( @ericfont ),

Merry Christmas and a Happy New Year!

Apologies, this took a while...

I've been improving the SARA-R5 library and decided to write an example to test the latency of TCP connections.

I've learned a lot along the way! Primarily that my service provider blocks incoming unsolicited TCP connections to the SARA-R5. I think the same is probably true for PING, which I think explains why my earlier SARA to SARA ping tests failed.

In the end, I had to set up a simple TCP Echo Server (Python running on my home computer with port forwarding enabled on my router) and then had the SARA-R5 send very short TCP messages to it and wait for the reply. "Ping" and "Pong". You will be able to find the code in the Examples folder later today when I up-issue the library.

Sending 4 bytes ("Ping" or "Pong") as 400 individual TCP transfers (200 round-trip echoes) took around 69 seconds:

12:34:31.493 -> Using socket 0
12:34:31.823 -> Socket connected!
12:34:32.200 -> 
12:34:32.200 -> Data received on socket 0 : Ping
12:34:32.342 -> pingCount = 0 : pongCount = 1
12:34:32.530 -> 
12:34:32.530 -> Data received on socket 0 : Pong
12:34:32.670 -> pingCount = 1 : pongCount = 1
12:34:32.811 -> 
12:34:32.811 -> Data received on socket 0 : Ping
12:34:32.951 -> pingCount = 1 : pongCount = 2
12:34:33.184 -> 
12:34:33.184 -> Data received on socket 0 : Pong
12:34:33.325 -> pingCount = 2 : pongCount = 2
12:34:33.467 -> 
12:34:33.467 -> Data received on socket 0 : Ping
12:34:33.605 -> pingCount = 2 : pongCount = 3
12:34:33.840 -> 
12:34:33.840 -> Data received on socket 0 : Pong
12:34:33.982 -> pingCount = 3 : pongCount = 3

...

12:35:40.003 -> Data received on socket 0 : Ping
12:35:40.143 -> pingCount = 98 : pongCount = 99
12:35:40.379 -> 
12:35:40.379 -> Data received on socket 0 : Pong
12:35:40.520 -> pingCount = 99 : pongCount = 99
12:35:40.661 -> 
12:35:40.661 -> Data received on socket 0 : Ping
12:35:40.804 -> pingCount = 99 : pongCount = 100
12:35:40.994 -> 
12:35:40.994 -> Data received on socket 0 : Pong
12:35:41.134 -> pingCount = 100 : pongCount = 100

I.e. approx. 170ms per transfer.

I believe that's the true latency figure you wanted?

That figure won't scale linearly in terms of bytes per second. If I was sending a few hundred bytes each time, I'd expect the time per transfer to be roughly the same. I might try that later...

Closing - after only ~6 months! ;-)
Best wishes,
Paul

[ericfont]

Thank you!