BLYNK
HOME       📲 GETTING STARTED       📗 DOCS       ❓HELP CENTER       👉 SKETCH BUILDER

Communication latency

Thank you dear Pavel for your kind welcome message and many thanks for your brilliant project idea of BLYNK.

I have been looking for some answers on the web, but maybe it is better if could get answers from you directly, if possible!

i am willing to build a remotely controlled ground vehicle, remotely controlled over the internet. As a start, trying to use Blynk App and Blynk cloud server with NodeMCU ESP8266.

The point I want to ask, how fast could I expect data exchange between my hardware and Blynk app via your cloud server. I know that communication latency depends on many factors, but did you measured before what is the shortest latency could be achieved?! or what is the average latency expected for pulling data from hardware via cloud server?

I hope you can answer me with some experimental measurements.
Thank you

Firstly… I moved your post/my answer from that older topic into your new duplicate topic :wink:

I think you just answered your own question… and that answer is “depends” :innocent:

A more revealing starting point would be to set up your own Local Server, test ping (as shown in the debug Serial on the MCU device, see image below) and overall latency (however you decide to make such tests… sooo many ways…) within your own LAN environment, then at least you will have a “best case” base to compare with.

Old image from my files, so ignore the version etc.
Capture

Then you can repeat again using your own Local Server, but with port forwarding to allow WAN access of the App to your server.

And finally, using Blynk’s Cloud Server via whatever various means you expect to use to access internet from both phone and device (cellular, cable, ADSL, fiber, carrier pigeon… There are three “Cloud Server” locations, and each will differ in connectivity due to “geographical variables” between them and the connecting user.

Basically, what I am saying (from my own experience with rover projects and Blynk) is that there is NO definitive answer. There are way too many variables that determine min, max, average ping and latency speeds… and some of those variables are (ehem) “variable” in their own timing as well.

How long is a piece of string?.. how fast is fast?.. why am I posting in this forum again? :stuck_out_tongue_winking_eye:

Dear GTT
Thanx for your reply. Actually, you opened my eye on the ping result the comes out when NodeMCU get connected to Blynk-cloud server.
lets share some results on the forume, later I have a question:
#Results for pinging from CMD prompet window:
ping ip(188.166.206.43) result in latency around 275ms
ping ip(45.55.96.146) result in latency around 150ms
ping ip(139.59.206.133) result in latency around 85ms

But, when I test connecting to a specific IP server using NodeMCU
such as Blynk.begin(auth, ssid, pass, IPAddress(139,59,206,133), 80);
I always get redirected to 45.55.96.146 such as following:

[2643] Connecting to 139.59.206.133


[3064] >45.55.96.146[00]80
[3064] Redirecting to 45.55.96.146:80
[3066] Connecting to 45.55.96.146:80


[3347] Ready (ping: 146ms).

I read some issues regarding GeoDNS!! is this the issue in my situation?!
my question is:
Can i get dedicated connection to specific Blynk cloud server IP?(in may case 139.59.206.133 is the best latency response)

one more thing:
can any one help with writing the “ping command function”!! just i don’t know how to get it out of the Blynk Library :woozy_face:

Thanx

Your account, project, and corresponding auth code(s), sits on just one server. In your case this is the New York server at 45.55.96.146
Your nearest server geographically is the one in Frankfurt on 139.59.206.133

When you create a Blynk account from your phone, it will normally be created on the Blynk server that’s geographically nearest at the time. If you did this while you on a business trip and were bored whilst sitting in your New York hotel room, then it would almost certainly end-up on the New York server.
But, there are other reasons why your account could be on the New York server. If your mobile ISP’s DNS servers resolved the New Your IP address rather than the Frankfurt one then it may be that they choose to do some slightly odd things with their DNS settings. I’d say that mobile communications companies based in the Middle East, China or parts of Asia are likely to be the main culprits for doing things a little differently.

When your mobile app tries to connect yo your project, no matter where you are in the world, it will do some clever stuff in the background to ensure that it connects to the server where your project lives. When your NodeMCU connects to the Blynk server it will also do some clever stuff to redirect the connection top the correct server, and produce the messages that you’ve seen in the serial monitor.

The only time that this clever redirection doesn’t work is when using the API calls, and in that case it’d important to specify the IP address of the server where your project lives. This is what is generally referred to as the “Geo DNS issue”.

Getting your account moved to a different server probably isn’t going to happen. You could create a new account on the Frankfurt server if you wish, and I guess you could force this by putting the Frankfurt IP address n the Custom Server fields of the app before you sign-up.

If you want to ping from the NodeMCU then this library is probably the best one to use:


You can install it directly from the “Manage Libraries” option of the Arduino IDE.
There is a bug in the library that always returns ‘true’ even if the ping fails (see #11), but the ping times seem okay (although the percentage loss numbers are also a bit questionable in case of a ping failure).

Ultimately, anything that involves the internet is going to give variable latency. Consider the round-trip of the phone talking to the server (across the internet) then the NodeMCU polling the server asking for updates (across the internet) then the response being sent from the server to the NodeMCU (across the internet). There’s an awful lot of scope for delays in that process, before the NodeMCU has any chance to act on the change of status of a widget in the app.

A local server, and your phone connected directly to the same network, is the only way to cut-out the variables introduced by the internet and the ISP’s providing the connectivity.

Pete.

Thanx Pete for your detailed reply,
First, I’d like to clarify that my target is to exchange data remotely over internet.
I will try your advice of enforcing creating account at Frankfort server.
This server serves me with 100ms latency, which is quite good for responsive robot control.

Second, Iam digging inside Blynk library right now, and found the part responsible for ping.

if (state == CONNECTING && (1 == hdr.msg_id)) {
switch (hdr.length) {
case BLYNK_SUCCESS:
case BLYNK_ALREADY_REGISTERED:
BLYNK_LOG3(BLYNK_F("Ready (ping: "), lastActivityIn-lastHeartbeat, BLYNK_F(“ms).”));
lastHeartbeat = lastActivityIn;
state = CONNECTED;

As I understood, the library pings the server every while to keep connection alive or reconnect:

if ((t - lastActivityIn > 1000UL * BLYNK_HEARTBEAT ||
t - lastActivityOut > 1000UL * BLYNK_HEARTBEAT) &&
t - lastHeartbeat > BLYNK_TIMEOUT_MS)
{
// Send ping if we didn’t either send or receive something
// for BLYNK_HEARTBEAT seconds
sendCmd(BLYNK_CMD_PING);
lastHeartbeat = t;
}

I hope if you could help, just how to print this pings out as debugging prints the heartbeats.
I dont like to use another library or specific sketch for getting pings result, i would like to monitor pings while running Blynk sketch and while using my project on the App.

thank you again for your kind respond

Hi every one
I hope somebody check this with me please,

I copied the following in the blynkProtocol.h library

BLYNK_LOG3(BLYNK_F("Ready (ping: "), lastActivityIn-lastHeartbeat, BLYNK_F(“ms).”));
lastHeartbeat = lastActivityIn;

and pasted a copy inside the same library at following place

    {
        // Send ping if we didn't either send or receive something
        // for BLYNK_HEARTBEAT seconds
        sendCmd(BLYNK_CMD_PING);

BLYNK_LOG3(BLYNK_F("Ready (ping: "), lastActivityIn-lastHeartbeat, BLYNK_F(“ms).”));
lastHeartbeat = lastActivityIn;

        lastHeartbeat = t;
    }

this resulted in the following debug at serial monitor

[2643] Connecting to 139.59.206.133
[2744] <[1D|00|01|00]…
[2807] >)[00|01|00|0F]
[2808] >45.55.96.146[00]80
[2808] Redirecting to 45.55.96.146:80
[2835] Connecting to 45.55.96.146:80
[3007] <[1D|00|01|00] …
[3143] >[00|00|01|00|C8]
[3143] Ready (ping: 135ms).
[3143] Free RAM: 49712
[3210] <[11|00|02|00]Hver[00]0.6.1[00]h-beat[00]10[00]buff-in[00]1024[00]dev[00]NodeMCU[00]build[00]Jul 24 2020 14:13:22[00]
[3362] >[00|00|02|00|C8]
[13224] <[06|00|03|00|00]
[13225] Ready (ping: 219ms).
[13371] >[00|00|03|00|C8]
[23226] <[06|00|04|00|00]
[23227] Ready (ping: 147ms).
[23475] >[00|00|04|00|C8]
[33228] <[06|00|05|00|00]
[33229] Ready (ping: 249ms).
[33426] >[00|00|05|00|C8]
[43230] <[06|00|06|00|00]
[43231] Ready (ping: 198ms).
[43445] >[00|00|06|00|C8]
[53232] <[06|00|07|00|00]
[53233] Ready (ping: 215ms).
[53485] >[00|00|07|00|C8]
[63234] <[06|00|08|00|00]
[63235] Ready (ping: 253ms).
[63413] >[00|00|08|00|C8]
[73236] <[06|00|09|00|00]
[73237] Ready (ping: 179ms).
[73619] >[00|00|09|00|C8]
[83238] <[06|00|0A|00|00]
[83239] Ready (ping: 383ms).
[83485] >[00|00|0A|00|C8]
[93240] <[06|00|0B|00|00]
[93241] Ready (ping: 247ms).
[93419] >[00|00|0B|00|C8]
[103242] <[06|00|0C|00|00]
[103243] Ready (ping: 179ms).
[103448] >[00|00|0C|00|C8]
[113244] <[06|00|0D|00|00]
[113245] Ready (ping: 207ms).
[113486] >[00|00|0D|00|C8]
[123246] <[06|00|0E|00|00]
[123247] Ready (ping: 242ms).
[123518] >[00|00|0E|00|C8]

which prints something looks like pinging latency every heartbeat!!!

the ping latency varies widely, lets say from 135ms to 380ms

i am NOT quite sure about this solution for gathering the ping latency result, but it is a self trail.

if any professional programmer could help, i would be very grateful and thankful .

Hi again… I tried Mr.@Pete advice for creating a new account at Frankfort server 139.59.206.133, it works well. thank you @Pete.

following is the ping result at connecting stage
Connecting to blynk-cloud.com:80
[2858] <[1D|00|01|00] ********************
[3072] >)[00|01|00|11]
[3072] >139.59.206.133[00]80
[3072] Redirecting to 139.59.206.133:80
[3074] Connecting to 139.59.206.133:80
[3165] <[1D|00|01|00] *******************
[3270] >[00|00|01|00|C8]
[3270] Ready (ping: 104ms).
[3270] Free RAM: 49696

as you can see, i tried to connect to blynk-cloud.com, but because my account wes created at Frankfort server, so i’ve been redirected to 139.59.206.133.

the result was better latency at ping response
Ready (ping: 104ms).

comparing with
Connecting to 45.55.96.146:80
[3007] <[1D|00|01|00] …
[3143] >[00|00|01|00|C8]
[3143] Ready (ping: 135ms).

this solution saved almost 30ms communication latency.

still looking for help with monitoring ping results periodically as heartbeats for implementing statistical data for my connection latency.
approving and keeping my communication delay below 200ms will give me a good chance to remotely control my robot over the internet with responsive behavior.

keep an eye with me :nerd_face:

Ping time and latency are not the same thing!
As I explained earlier, the process (as I understand it) is this…

  1. You change a widget in the app, app sends this to the Blynk cloud server (latency part 1)
  2. The NodeMCU is running code, which periodically encounters a Blynk.run command (latency part 2)
  3. The NodeMCU sends a request to the server (latency part 3)
  4. The server responds with a result (latency part 4)
  5. The NodeMCU possesses the response (which I believe needs another Blynk/run command to instigate the callback in the code

Ping measures the round trip request/response from a device to the server and back again (elements 3 & 4 of the list above).

Pete.

2 Likes

@adham, how do you connect to your Internet Service Provider? DSL/Cable/Fiber/3 4 5G…The latency is also affected by your type of connection.

Dear @Emilio
i connect via 4G mobile internet (cellular provider).
finally i got a very god responsive maneuvering.

best regards :wink: