[SOLVED] Need guidance in understanding the flow of a Blynk Function

Why is that?

Exactly my question :)… why should I require that in order for it to work (but with additional buzzing at end), as it does outside of Blynk.

Maybe it adds some delay that makes you fill that “all is alright”. However I don’t see any reason for this line to make it work :slight_smile:.

if you have a servo handy, please try both codes and let me know if it is only an issue in my universe (as seems to happen all too frequently :confused: )

@Gunner why use the map when you can simply put 2350 to 690 in the slider range?

I left it in there due to a technical term call laziness :wink:

I actualy just quickly ported over the code I had written for general arduino use… where the mapping was required.

And honestly, the real technical term is “Doh”. Even though I did have to adjust the slider from 0-255 to 0-1023, I just hadn’t realized I could eliminate the map() until you mentioned it :blush:

Still doesn’t explain the real question… I just hope that answer isn’t another “Doh” :smiley:

Might be worth trying.

I presume you have the slider set as Send On Release as ON.

Can’t see why you need the virtualWrite. I don’t have any servos but I’ll think if there is a way of simulating one in code.

Thanks :slight_smile:

but is it set as ON or OFF?

OFF is not recommended if you want a stable system or you code around the flood you cause.

I have used both options (but usually set to ON)… as it doesn’t affect my overall project either way, even while polling sensors and simultaneously BlinkenDasRGBLights :slight_smile:

Without the virtualWrite() it does “technically” work; IF I keep touching the slider at the desired end point, until the servo position matches (it takes 8-9 touches to go end to end with Send on Release; And 3-4 touches without Send on Release - however when slowly dragging the slider, the servo ‘usually’ keeps up).

Almost like Blynk is somehow interrupting it’s own function before the delayMicroseconds() runs it’s course, and the Blynk.syncVirtual() is required to keep putting it back on track, until truly finished.

Also, I should add that the ‘buzzing’ at the end (with the virtualWrite() “fix”) will usually coincide with disruption in the link between server and app (up-timer display and other data pauses for a few seconds). Again, it is like Blynk is now playing catch-up, after the fact, due to the “fix”.

@Gunner try this with slider set from 2350 to 690:

unsigned long start;
unsigned long finish;

 start = micros();
 SrvoPos = param.asInt();
 finish = micros();
 Serial.println(finish - start);

for me a move to a slider position of 958 gives Serial Monitor output of 972, so pretty accurate.

Some more data shown as slider value and Serial Monitor Micros:

1841 : 1860
828 : 846
2079 : 2098
933 : 952

So around 20 microseconds overhead, which could be covered by a minor coding mod.


I guess I am not clearly explaining what I am seeing?

The issue is not the value of the microsecond pulse… that works perfectly (even with the unnecessary map()… which I since removed and used the slider settings instead.

Rather something acts like it is interrupting the simple flow of the Blynk function process (perhaps microseconds are too fast??):

Pin HIGH - Wait Xms - Pin LOW.

Which does not work ‘properly’ in a Blynk function (as compared to a normal loop).

But with the added and seemingly unnecessary Blynk.syncVirtual(V12); I get something more like:

Pin HIGH - Wait Xms - “Go check the slider and make sure you are not forgetting something ;)” - Pin LOW.

Which does work properly, but then causes other minor delays in the rest of the project.

It is late (early) here… so I will sleep on it… but I think will simply re-code so I can still use the Blynk slider, but redirect the microsecond data to a normal loop instead of a Blynk function.

I truly thank you for your time! but no sense in beating this poor dead :horse: much more :slight_smile:

I have added digitalWrite’s high and low to an LED and using 10 x the slider value the LED responds as expected.

I think the issue is specific to your set up as you shouldn’t need any virtualWrite’s

@Costas @Dmitriy

Finally, after many tests, widgets, dual servos, odd commands that shouldn’t but do effect outcomes, and USB links that shouldn’t and probably don’t, effect the transmission of a single integer and it’s interpretation by hardware. I have proven to myself the following:

It seems since Blynk is constantly in it’s own master loop, something as precise as a microseconds() loop gets lost in the shuffle… needs a servo to really notice, LED’s and data displays don’t tell the whole story.

Adding Blynk.syncVirtual(Vx); resolves the loss by keeping the Blynk Function attentive to the microseconds() loop request. Doesn’t matter if it makes sense or not, it worked :wink:

Unfortunately after job done, the Blynk function in question sometimes gets stuck in an endless loop, until another call comes along (in my case a timer); This was all confirmed with counters on hardware side. And that explains the servo chattering and timeouts I experienced.

Solution… I must stop doing nit-picky, sub-timey, non IoT things while running Blynk… and stick with servo libraries when possible :stuck_out_tongue_winking_eye:

So, I believe I answered my own question about the flow of a Blynk Function :relieved:

Thank you for bearing with me on this journey of WTF?!

I meet this problem too. Any solutions for this?

I think it would be better if you started a new thread and shared all of the relevant information to allow us to understand, and potentially recreate your particular issue.


1 Like

As suggested above… please create your own topic with your specific problem… as mine was a very subjective question (NOT really a Blynk problem), way back in my early days of Blynk.

Meanwhile, the short story is that since Blynk needs constant processing in the background to do it’s thing, and since I was using a rather slow MCU (16MHz Arduino) at the time, I was simply doing too-much-too-fast and something was getting lost in the slider input (the widget was probably set to constantly update as moved, instead of update after release… too long ago, can’t remember).