I’ve done some more tests, but not yet done. I took Blynk out of the equation to see if it’s hardware related. I run the WifiEsp library and use a modified WebServer. I coded an app for iOS using Cocos2dx (for UI), and I run the app with the Simulator.
I basically establish a TCP connection to my ESP, and send data. I can see from the output that it is much faster. I still have more testing to do, but it does seems that there’s some kind of buffering that is happening that can slow down reception of data.
That would explain by a Blynk joystick could introduce latency because it sends many packets.
On the Blynk side, I turned on tracing on my local server. I did notice that from my Android app to the local server, there could be large hiccups (greater than 2 seconds) when receiving a hardware pin message. I’d imagine there’s a certain amount of latency from Android app -> Local Server, and then Local Server-> ESP hardware.
I’ll do more tests tonight to come up with a conclusion, but it’s starting to look that in my case, using Blynk does not allow me to have enough responsiveness to drive my little robot vehicle.
The only thing I find maddening is that psoro’s vehicle works so well!! I wish mine would’ve worked so nicely without much latency.
Hi cyberbum,
I’m afraid I can’t help you as I wanted, it seems your knowledge regarding ESP is bigger than mine…
What I can tell you is the rest of my set up but it’s so simple that I think it wouldn’t help you…
This is where Blynk enters… It does the “magic” and everything works…
Just one silly thing I remember regarding my Rpi as local server, at first, I used a WiFi Dongle and I changed to the RJ45 network socket… Time ago the WiFi signal from my old router was really bad, I’ve got a new router but I’m still using the RJ45.
Yes I was connected to a local server (running on my macbook) using IP. I was also on my local Wifi with my Android phone. My wifi doesn’t have much interference, and I have already run a peer to peer app on my Android to my macbook with very low latency.
Ok, so I finally got my robot car to respond with under 100 ms or so latency (basically I don’t notice it anymore, it’s near instant while moving the joystick). Unfortunately, I couldn’t do it with Blynk, I wrote my own iOS app using Cocos2dx for the UI, and connect via tcp to my ESP8266-01 to send data.
Here’s what I found:
-The Blynk single axis joystick (though I’ve noticed they have been removed) will send values as fast (or so it seems) as you move the slider. All this data is first sent to the local server (already incuring latency + processing time). It is then forwarded to my ESP (adding more latency from server to my ESP). Maybe it’s my ESP hardware, but it’s not super fast to process tons of data. I didn’t analyze how much data it receives from the local server, but it was large enough to that my ESP had trouble keeping up.
-The “hiccups” I would see on the local server that I mentioned above. Sometimes, it seemed when the local server processed a heartbeat message, it would seem to not process my hardware message quickly there-after. Not 100% sure, just sometimes I noticed while tailing logs. The bad thing was sometimes this hiccup would be when sending the “center” value, to stop my motors from spinning. If I was testing it out on the ground, my robot would’ve basically crashed in a wall.
-So my final solution was using my own slider/joystick, and throttle updates to about one update per 200 milliseconds, except when my slider falls back to the center position, which basically shuts off the motors. I send basically 3 bytes : one byte for vertical/horizontal axis, one byte for value (0-255), and a terminating byte. This lets my ESP “breathe” more easily and allows to process more data rapidly.
All of this leads to me being able to control my robot RC with fairly low latency.
Some questions for the Blynk guys:
-Are you going to open-source the app code as well? It would’ve been nice to see how the widgets send their data (how often, how large the data is)
-Will it be possible to directly connect to hardware, rather than passing by a server? It adds unnecessary latency for projects that require low-latency communication
-Why did you kill the single-axis widget?
Hello. Most probably weak point in your setup is ESP or wiring. @vshymanskyy was able to build copter via Blynk with low latency.
No.
It would’ve been nice to see how the widgets send their data (how often, how large the data is)
This info is open. Briefly - 5 bytes header + body. Body is usually 8-12 bytes. You may think that this is a lot. But considering TCP/IP packet header itself (40 bytes) this not much. So your packet is 43 bytes. Blynk packet is ~55 bytes. So in terms of latency this is almost the same. Also for joystick and slider we cut 2/3 of events, cause our tests show that most of hardware cannot handle such load. And ESP if one of the weakest chip here.
Yes, we even have internal prototype for that. See our roadmap here. You may vote for direct connect to make it happen faster .
The copter example wasn’t good for me, he is using an ESP8266 ESP-07 ESP-12, already better than the ESP-01 because it has more GPIO pins than the ESP-01.
I think the weak point is the ESP. If wiring was the problem, my non-Blynk code setup would’ve had the same problems.
The point here - esp works fine without Blynk server. That is logical, but still Blynk should be fast enough. Maybe @vshymanskyy has ideas of what is going wrong here?
Yeah I have a feeling the Esp boards are bad (I actually tested with 2 board, but they were bought from the same place at the same time).
I had to return a motor driver from the same vendor because it was dead. When I order new ones, I’ll be sure to try again with Blynk. The widgets are pretty sweet to use and look very professional too:)
I don’t want to waste anymore of your time since it seems hardware or wiring related, thank you all for all your help!
Hi Dmitriy!
From my point of view, the slider is not as good as the single-axis Joystick… With the single-axis we had the “Autoreturn” function, it was like a real one, more friendly/intuitive for children … Obviously we can use the two-axis, but it’s not the same sensation…
I agree:) With the single-axis joysticks, you can simulate the “feel” of the classic RC toys radio controller. Also the auto-return was super useful as well.
Ok I can confirm, it is an ESP problem, but I’m still tackling it.
I started pinging my ESP, and I was getting almost 800 ms responses. So no kidding everything seemed slow. I switched to another ESP card, with an older firmware. For some time, I was suddenly getting 30 ms ping times!! I tried my motor control sketch, and I was getting instantaneous reaction, even when spamming the connections!
I unhooked my FTDI and started it untethered, and all of a sudden…ping times dropped back to 600 and even 1000 ms! I tried resetting the ESP, a whole bunch of other stuff, and I couldn’t get the same performance.
It’s super annoying, I thought finally I solved it and I was gonna hook Blynk back in, but now I’m back to crappy ping times. Argh!
SUCCESS!!! Ok, so, the whole problem was caused by…a damn wifi network from my neighbor that was completely interfering with the ESP’s wifi.
To solve this, I changed that my car now hosts a local AP (access point). I used the Netspot app on Macosx to see which channels were being used around me, and picked something unused (channel 12 in my case).
On my app I connect to my car’s AP (wireless network). Once connected, I have perfect control, no latency!!!
So happy, this took me so long to figure out:) Now I will replugging in all my Blynk stuff:P
I had read a post about some guy using two ESPs beside each other, and he mentioned that if one was using its GPIO, it would interfere with the other ESP, lowering its ping and even timing out.
So I started taking snapshots of wifi networks around me. I noticed I was sharing the same channel as many other networks, but didn’t want to switch my own wifi network’s channel. So I found out that if you create your own AP with the ESP, you can pick any channel you want!
It’s still working great! I’ve certainly learned a lot while troubleshooting all this:)
.
