Is servo.h actually compatible with Arduino Wifi rev2?

Official Hardware Classic UNO WiFi Rev2
1

I have some nicely working code that is based on all the openweathermap.com and arduinoJSON examples. Works well, gets on wifi, gets and prints data, can recover from losing wifi and all of that.

However, as soon as I start to try to use the PWM pins with the servo.h library, the board won't stay on WiFi and WL_CONNECTED goes false every30 seconds or so, prompting my code to do its recovery and get back on.

At first I thought I was having some sort of brownout with servo power needs, but this happens with no servos plugged in at all. Indeed it happens with no commands to make servos move. At that is required to cause problems is adding the following lines:

#define tnowpin 3 // current temperature servo PWM output pin on Arduino
#define tmaxpin 5 // temp max servo output put
#define tminpin 6 // temp min servo
#define mainpin 9 // Main weather conditions dial servo output pin
#define precpin 10 // precip servo PWM output

#define tempservo0 500
#define tempservo100 2500 // temperature servos reading 100 degrees.
#define precipservo0 500 // and so on...
#define precipservo10 2500
#define mainservomin 500
#define mainservomax 2500

Servo TempDial;
Servo MinDial;
Servo MaxDial;
Servo MainDial;
Servo PrecipDial;

And in setup():

TempDial.attach(tnowpin,tempservo0,tempservo100);
MinDial.attach(tminpin,tempservo0,tempservo100);
MaxDial.attach(tmaxpin,tempservo0,tempservo100);
MainDial.attach(mainpin,mainservomin,mainservomax);
PrecipDial.attach(precpin,precipservo0,precipservo10);

It feels like WiFiNINA is using one of the PWM pins or timer configurations for something that servo.h is stepping on. But I am way too much of a noob to know.

I didn't immediately see any reported issues like this in arduino-libraries/Servo.

I am on 1.1.4 of the servo.h lib.

Thanks in advace

Z

2

Separately, when I do set servo commands, it would seem the pulse repetition rate is about 34 Hz. Which if I recall correctly is too slow for some digital servos and slower than the 50-60 Hz rates that one used to get on previous arduino versions?

3

Additional info:

After a bit of elimination, the issue with seeming wifi conflict is with pin 10 (the precpin for my precipitation dial servo above).

Attaching the PrecipDial object will make the arduino unable to stay on Wifi

In looking with an o-scope, writing any number of mircoseconds to that output will produce a garbage waveform instead of a normal servo PWM signal; though the other four PWM pins would appear to be fine.

If anybody has made all five PWM pins produce sensible software controlled servo PWM signals with servo.h while also having the unit be on Wifi and communicate with the world, I'd love to know if you had any similar sounding struggles and what you did about them.

Thanks in advance.

4

It sounds the same as this issue:

Also possibly related:

5

Interesting. Those two examples do at least seem similar.

Though in my case I seem to be using different pins than them (??). 2 and 8 respectively, and if I understand correctly, on arduino Wifi the available PWM pins are 3, 5 6 9 and 10 (??) Do I have a misunderstanding here?

I have my code working with 4 of those 5 possible pins, with 10 still causing wifi drops.

Servos on the others will jitter and jump during any serial communication. Very much like your second link's problem. The PWM signals do stupid things during serial I/O.

Very odd.

Any advice appreciated on how to proceed, or help library makers isolate the issues.

thanks all

Z

6

You're not restricted to the hardware PWM pins when using the Arduino Servo library. You can use any pin.

7

Good call. I'll rewire.

I don't have a good explanation for why pin 10 seems to interact with Wifi. But I'll just pitch around it for now. if anybody knows what's up there, I'd love to know. Happens on all my Wifi 2.0 boards.

As for the serial I/O and the servo configured pins, I can attest that there is indeed interaction between the two as your second link's OP said. My weather gadget works way better with serial debugging text off, and the signals to the servo are sensible at all times.

Thanks for the help

  • Z
8

Hello again. Having rewired a few different ways, I think there is still a problem with servo.h and this board. Because I can't yet find 5 pins that can be controlled with servo.h to drive servo without also causing Wifi drops. Some pins are better than others, it seems. But as this is somewhat irregular problem as to how long it will stay on wifi, it's hard to quantify.

I seem to be able to use pins 3, 5, 6 and 9 with no ill effect.
Adding in 10 or using it on its own will cause wifi drops.
4, 7 and 8 don't seem to work well with the first four that do.

But I am wondering if this is a combination-choice thing with timers and such that is more complex than I immediately see. Or if it also interacts with serial I/O, since I have the debugging text in my code on while running these tests.

So to be clear. I can write code that gets onto wifi, takes operweathermap data, prints stuff out. Recovers from wifi loss (like if I turn off my router and turn it back on) and all that fun stuff. But as soon as servo.h is in play, things get goofy. And, I have one of my wifi 2.0 units sitting here falling off the wifi with pins 3, 5, 6, 7 and 9 configured for servos, but nothing actually attached to the board. So this isn't servo power or noise, or browouts or anything like that.

There are some (perhaps unintentional) rules to how many and which pins will work, but I do not know them.

Again, thanks in advance to any who have more advice to offer.

Z

9

FWIW, I bumbled into a sorta-fix. Wherein I added some delays in loop() to blink some led and whatnot for this project, and servo.h and WiFi played nice again. Or at least WiFi stopped dropping with 5 servos. The other problems above remain. And this obviously isn’t the best solution as there are applications that will want loop() to run at max repetition rate.