Virtual write speed over bluetooth. Yes loop is clean

[EPV77]

I’m attempting to use Blynk as a multi-gauge display for my vehicle, showing engine data. As you might understand the speed of presenting data is essential. Blynk officially states that you should limit your message count to 10 per 1000ms. I’ve done my research and tried various tricks to speed up thing but need more, any advise is welcome. Code is very simple, the virtual write Blynk default sketch can be used as an example. Running on bluetooth and a ESP32 so no network limitations.

I need to execute >100 virtual pin writes every second, 10 different values every 100ms. I’ve tinkered with the BLYNK_MSG_LIMIT to speed things up and switched off debugging just to reduce load but still Blynk will struggle. All the running values will freeze at once sporadically in the Blynk app. Is there anything else that I can change in the BlynkConfig file for the sake of speed?

[PeteKnight]

I think that BlynkTimer limits the number of writes per second.
Try using SimpleTimer instead.

Pete.

[IBK]

… Blynktimer and SimpleTimer are the same - if I read this correctly:

blynkkk/blynk-library/blob/master/src/utility/BlynkTimer.cpp

[PeteKnight]

As I understood it, BlynkTimer is a modified version of SimpleTimer that does 3 things differently…

1. fixes the disappearing Timer ID zero bug
2. increases the number of allowable timer instances to 16 for each timer object
3. in some way limits sequential writes to prevent server flooding.

I’ve never tested anything other than the Timer Zero bug, and can confirm that BlynkTimer and SimpleTimer are different in this respect.

I think there was an announcement about these in a library release about 2 years ago, but as I’m writing this on a phone it’s tricky to search for the info. Besides, I still have an hour or so of sunbathing to do before watching the sunset

Pete.

[PeteKnight]

Seems like I can multi-task with sunbathing and searching, despite Mrs K telling me that I don’t have the correct genes for that stuff…

New Blynk Library Release v0.5.3

NOTE: This version contains security/stability bugfixes. It’s HIGHLY recommended to upgrade asap. Be sure to use the latest Arduino Core for your hardware (2.4.1+ for ESP8266 is required) In this release New boards support Arduino MKR GSM 1400 U-blox 2G/3G modems Quectel BG96 modem New features TinyGSM updated to 0.3.5 All Arduino MKR devices now support 128 Vpins terminal.clear() support Add setDeviceName for ESP32 BLE Cloud OTA support for ESP32 Board in…

• • Important : When BlynkTimer struggles to run multiple times (due to a blocked loop), it just skips all the missed intervals, and calls your function only once. This now differs from SimpleTimer , which could call your function multiple times in this scenario.

Pete.

[EPV77]

Thanks for the advise, I’ll test the SimpleTimer instead and see how it runs.
I’ll report back!

Don’t believe in what your wife tells you, I rarely do .

[EPV77]

No difference at all, issues must be elsewhere .

[Gunner]

You only mention the Bluetooth in the title… somehow I don’t think Blynk’s BT link is anywhere as fast as WiFi… particularly as it is using the BT link between device and phone, then the phone’s WiFi/cell signal between it and the server, so that is a point of delay right there.

@EPV77

I need to execute >100 virtual pin writes every second, 10 different values every 100ms

Blynk has implemented some “anti-flooding” methods, so unlikely you can reach that, even with WiFi… but I would recommend comparing what you do have between the ESP32 WiFi vs ESP BT

@EPV77

I’ve tinkered with the BLYNK_MSG_LIMIT to speed things up

but I believe the proper value to “disable” the anti-flooding is

#define BLYNK_MSG_LIMIT 0

@PeteKnight

Seems like I can multi-task with sunbathing and searching

Hmmm… must have been be difficult for you I spent today freezing fingers & toes in the cold and literally watching/waiting for water to boil, in order to fix frozen RV plumbing issues… definitely no multi tasking abilities for web surfing at the same time for me.

[EPV77]

Attached is a sample of the code that will generate the sporadic freezing symptom, it runs smoothly for about 8-10 seconds and then freeze 1 second, behavior repeats itself continuously . Debug print shows no errors.

#define BLYNK_PRINT Serial

#define BLYNK_USE_DIRECT_CONNECT

#include <BlynkSimpleEsp32_BT.h>


char auth[] = "XXXXX";

BlynkTimer timer;



void myTimerEvent(){

  Blynk.virtualWrite(V2, millis() / 100);

}



void setup(){
  
  Serial.begin(115200);

  Blynk.setDeviceName("Blynk");

  Blynk.begin(auth);

  timer.setInterval(100L, myTimerEvent);
  
}



void loop(){

  Blynk.run();
  timer.run(); 
  
}

[EPV77]

@Gunner

You only mention the Bluetooth in the title… somehow I don’t think Blynk’s BT link is anywhere as fast as WiFi… particularly as it is using the BT link between device and phone, then the phone’s WiFi/cell signal between it and the server, so that is a point of delay right there.

WiFi wasn’t really part of my original idea with this project, might give it go to see if any difference .
The server isn’t used as per my understand when you connect directly over bluetooth to the phone as I do , correct?

@Gunner

Blynk has implemented some “anti-flooding” methods, so unlikely you can reach that, even with WiFi… but I would recommend comparing what you do have between the ESP32 WiFi vs ESP BT

I commented out the code just to see if that would change things instead of raising the limit as I’ve done too but no difference.

/*
// Limit the amount of outgoing commands per second.
#ifndef BLYNK_MSG_LIMIT
#define BLYNK_MSG_LIMIT      1000 //15 is default
#endif
*/

[PeteKnight]

@EPV77

8-10 seconds

Sounds like the sort of frequency that the Blynk ping/ heartbeat would occur.
@Gunner, is there an option to change this frequency, or disable it altogether?

BTW, this is the view. from my office today, not a frozen pipe in sight

Pete.

[EPV77]

I like the idea of disabling

@PeteKnight Nice view, waves and curves…

[Gunner]

@EPV77

The server isn’t used as per my understand when you connect directly over bluetooth to the phone as I do , correct?

Not correct… the server (cloud or local) is likened to the brain of Blynk, it is always needed and always used. With BT, the App must act as a go-between, in comparison to a WiFi device accessing the server directly.

BT is just an older, and now not as common, method of linking older devices (pre ESP… AKA Arduinos with BT, etc).

Yes is is still used and seemingly updated at times, but WiFi based devices are always the better option.

[EPV77]

Video of the issue I described.

[Gunner]

I stopped watching when my ears where blasted

But what I saw was what is expected… too much too fast. Blynk is an IoT app and IoT means internet link, and that means some degree of lag. Adding in BT just adds to the link lag.

For an in car display, you might want to install a local server on an RPi, set up as an access point, and have a dedicated phone/tablet connecting to that server via WiFi (basically NOT connected to or reliant on internet) then use the RPi’s GPIO for sensors and a Blynk client program (NodeJS or Python… Python may be best) running alongside the server. A good RPi, v4 or better, can easily handle both server and client.

[EPV77]

Sorry for the background audio, kids watching cartoons.

I understand the fact of this being a IoT solution. Adding additional hardware in the car to host a server is not an option for me at this stage.