Does blynk cause some pulses to wemos d1 mini port D2?

Dear all, I finally managed to get a snap of the issue
in the upper window you will see, the pulses that will present about 500Hz
but suddenly it stops for about 26ms and than provides some fast pulses
which are not from my code.
And I do not think that this is caused by a poor board because it is the original wemos d1 with nothing more attached than my scope

2 Likes

Here is another snap
And again the 500Hz stops and after a delay there are the pulses
But of cause both is wrong
there should only be the frequency of 500Hz
And yes when I delete the blynk.run line the 500Hz are stable without any interruption

is there ANY IDEA what I´m doing wrong ???

it may be possible but how to detect the heartbeat ?
is there a possibility to trigger on that ?

did you tried this:

also, i see the pulses on the screenshot, but the question is, how strong they are?
maybe a really weak pull down could be enough to eliminate them?

You can see the hearbeat and other stuff if you add this as the first line of your sketch:

#define BLYNK_DEBUG

I add a 47k Pull down Resistor

YES that´s it
these pulses come synchrony to the heart beat information
When there are some information’s added at the serial monitor than I observe the pulses at my scope
Are there more information’s what´s going on there ?
How may I eliminate this ?

this is what i say: they probably because of wifi communication, not blynk related?

I’m a genius :slight_smile:

Don’t forget to change from 2nd gear to 5th gear i.e. up the baud from 38400 to 115200 :slight_smile:

Dunno, maybe if you post an extract of the code that is being affected someone can offer a fix.

Blynk.run() is Blynk related and part of it is the hearbeat and other WiFi stuff.

2 Likes

yes, you’re right @Costas, my bad!

1 Like

Because the heartbeat (hmm, I never narrowed it down to that - good call @Costas ), other timing like BlynkTimer and other libraries like stepper and servo all use the same core timers of the MCU, then there is no real way of eliminating the issue… more like mitigating it by perhaps using external stepper controllers that have their own hardware timer?

Here is my code
I shorten it to represent the issue some what better

//#define BLYNK_DEBUG
//#define BLYNK_PRINT Serial    // Comment this out to disable prints and save space
#include <MY_WiFi.h> // MY_personal WiFi including OTA Blynk simple timer
/* the following stuf is includet in MY_WiFi.h so I do not miss to implement it anymore
 #include <ESP8266WiFi.h>
#include <BlynkSimpleEsp8266.h>
#include <ArduinoOTA.h>       // for local OTA updates
#include <SimpleTimer.h>
SimpleTimer timer;
 
 * */
 
 */
// You should get Auth Token in the Blynk App.
char auth[] = "xxxxxxxxx";//my Stepper_2
#define MY_file_name "my Stepper_2"
#define Step_Pin D0
int var = 0;
int tor_status =0;
int countdown = 999;
void setup()
{ pinMode(BUILTIN_LED, OUTPUT);  // initialize onboard LED as output
  pinMode(Step_Pin, OUTPUT);
  delay (500);
  Serial.begin(115200);
  Serial.println();
  Serial.println(F(MY_file_name));
  Blynk.begin(auth, ssid, pass);
  My_OTA_setup();
  timer.setInterval(1L, myTimerEvent);   // Setup a function to be called every msec
  Serial.println(F("setup_END"));
}

void loop()
{
  Blynk.run();
  timer.run(); // Initiates SimpleTimer
  ArduinoOTA.handle();  // see next TAB OTA
}
/*
BLYNK_WRITE(V5) {
  tor_status = (param.asInt() ); // pinData variable will store value that came via Bridge
  Serial.println(F("got V5 value = "));
  Serial.println (tor_status);
}*/

void myTimerEvent()  //this is for example only change it to your ISR needs
{
  digitalWrite( Step_Pin, LOW);
  if (countdown-- < 0)
  {
    digitalWrite( BUILTIN_LED, digitalRead( BUILTIN_LED ) ^ 1 ); // blink x/sec
    countdown = 999;
  }
  var = 0;
  while (var < 2000) {
    // do something for testing only
    var++;
  }

  digitalWrite( Step_Pin,HIGH);
}


you can try to put the critical part of the stepper code in interrupt function. that way the mcu will not do anything else, so will not disturb the steps.

also, most stepper drivers have a standby / disable pin. you can control this pin with the wemos, and just turn on the stepper driver just before you send the commands for it, and turn off right after the steps are done.

in one of my older project i’ve done exactly the same way, on d1 mini pro, and didn’t had any issues.

(in stepper driver datasheet you can find the info how many us or ns you have to wait between turning on the driver and sending the first pulse)

I´m a bit confused because I use the wemos D1 mini several times together with blynk.
Unfortunately my PC burns down and I have to rebuild all my stuff again.
I needed to setup everything to my new notebook

My stepper runs before great and I never observed such an issue
I do not belief that the issue comes from my new notebook.
But I want to give this information because it might be useful to find the root cause

I´m offline for several hours

I always saw a servo jitter cycle that often matched a timer cycle, so unless you needed to use SimpleTimer in your past setup, it might not have been as noticeable… but now that BlynkTimer is built in, it may be noticeable even if you don’t actively use timers. Plus, the developers are always adding stuff, so who knows how that affects timer usage (assuming that is the cause of your noted signals).

Yes you are right
I´m still most frustrated.

What I know up to now is that there is an effect caused by blynk may be a BUG
I assume that the blynk heartbeat will modified the timer.setInterval
By that the timing of my ISR is disturbed and this causes the false pulses.

BUT
I do not find any work around to get a stable timing for my ISR

I hope that one of the developers will take a look on this

Or it is just the result of many core routines sharing the internal timers… there are only so many milliseconds in a day :stuck_out_tongue_winking_eye:

@vshymanskyy is this something you can assist with and/or explain, if you have time?

1 Like

What exactly does your stepper motor do?

it will drive a linear stepper motor.
With a high requirement for precise timing
and a wide range of stepper frequency