Robustness of library

Hi, I am using an Arduino Uno board together with a very simple app which includes 2 ValueDisplay widgets and two buttons, one configured as a switch and the other as a pushbutton.
I have also attached 2 LEDs to D9 and D7 which are driven by the buttons.

I started from PushDataOnRequest example and addes an additional flow of data to the DispayValue Widgets.
Basically to the original 1 sec uptime values I added a 0.5s uptime value, just to have to continuous streams of values to the app (see below the source code).

Every works fine of course, but I decided to run a simple robustness test: I left the board ON for a while night and wanted to see if everything worked properly.
The result is:

  • the two buttons still work flawlessly and respond quickly
  • the two DisplayValue widgets are very slow to update. The results are still sequential, but the frequency of updates drastically decreased and are completely misaligned (non more one the double frequency of others).

Restarting the app in the iPhone does not change the situation, while restarting the Arduino Board (reset) correctly restore the situation and the values are updated with the intended frequency.

This makes me wondering about the robustness of the library in the Arduino Uno.

Any hint ? This is a very simple test every body can make.


#define BLYNK_PRINT Serial
#include <SPI.h>
#include <Ethernet.h>
#include <BlynkSimpleEthernet.h>

char auth[] = “tbd”;

void setup() {

// This command writes Arduino’s uptime in seconds to Virtual Pin (5)
Blynk.virtualWrite(5, millis()/1000);

// This command writes Arduino’s uptime in seconds to Virtual Pin (5)
Blynk.virtualWrite(6, millis()/500);

void loop() {;

The arduino uno is known for robustness? I have never had great success with this chip and “uptime”

I am running my own tests with clean power and have 12 hours uptime right now (running a clock to determine code uptime)

One thing you may be experiencing is the server and data logging robustness - which the team has mentioned is not final yet but in “public 1.0 version” there is a lag when the app connects to the blink server - because the server is not logging data there is a bit of lag there currently

Also have you checked your read/write code and widget polling / push settings to make sure you followed the comments in the top of the example?

My 12 hour uptime arduino is responding amazingly for a 1.0 anything better is crazy amazing IMO. These devices are not known for enterprise perfection. For the price point your going to be better with a rpi for “uptime stability” IMO

Thanks for the feedback.
As I see it’s not a matter of the HW platform which is very simple and with simplicity usually comes also robustness. The only element of non-robustness I can think of is the clock which could change over time. If it was the platform, the two data stream frequencies would have changed at the same time, but in my case the 1Hz stream was ok, while the 2Hz stream slowed down a lot!
As I see this is the software, not the board. It could be cloud service, but when I restarted the board everything worked properly again.

This morning I restarted the board and as I said everything restarted correctly, but I just noticed that after a couple of hours the the data flow update frequencies were already unaligned.
Now I started a new test with two new frequencies of 1Hz and 0.5Hz (before it was 2Hz and 1 Hz).
This will slow down the data stream and let’s see what changes.


The SimpleTimer library does not guarantee such timing to be synchronous.
Try updating both values using one timer, and see if it works!

Hope this helps!

there are a lot of variables here I don’t think are being accounted for in your equation of simplicity - there is another that this stuff is just Cheap electronics there is no clean clock source - if your chip happens to have a crystal or ceramic resonator as its source these can vary as well as with power fluctuation with the power supply etc… and the lack of a normal RTC to run against NTP to validate any drift is also complex.

On top of all this cheap electronics… your also showing in your code that you have the serial buffers loaded and its documented well that the serial output and serial display on the ATmega chips is a resource hog and is potentially causing a lot of your pain.

these two reasons (lack of RTC/NTP) and serial I/O for display and debug are the two major reasons I would suggest a rpi (which normally costs the same as a arduino/ethernet setup) for your more robust requirements in the cheap prototyping market

1 Like

Spudgunman, thanks a lot for the very helpful feedback!
Your points are very good indeed as well as the suggestion about the RPI.
After running that test for a few hours, I noticed a couple of things:

  1. The numbers displayed are perfectly in synch. Since the frequency of the streams are one double the other, when one number is X the other is alway 2X. This is very good in my view since it means no packets are lost.

  2. Observing the tx/rx LEDs in the Ethernet board, when the Blynk app is closed or minimised, it looks like the library in the Arduino board stops sending the packets to the cloud. When the Blynk app is restored, the counter resumes with the correct sequence. SO, it seems the library does some buffering and to me this could be another reason for the progressive delays.

Anyway, I agree with you that with such cheap board the timing stuff must be low priority and anyway the goal of my test was more about robustness about packets which should not be lost and this seems the case.

Thanks again

Ahh well yes that is a different beast! and remember you can run a local server to increase that robustness. I personally am planning to make quite a security system and home automation product with this project so I am in the works of this now. I cant have any security or packet issues (which is why this project was so attractive to me, it allows what other’s never have - your own server!)