186mA digital servo frying up Photon regulator

Troubleshooting
1

Question for the digital servo folks:

Got myself a Turnigy TGY-S712G digital servo. Tested this on an Arduino Uno using onboard 5V to provide power to it. My DMM shows that it consumes around 186mA when the servo arms are in full swing.

That seemed to indicate that switching over to the Photon would be fine, using 5V@VIN to power the servo (via USB). This was also supported from past experience with regular analog servos, which never exhibited any problems (again where VIN=5V, either externally powered with grounds tied or via USB) either.

I’ve tried this on two Photons. Code was written such that the servo arm does a basic test sweep 0-180º. Both released the proverbial magic smoke on the Photon’s tiny voltage regulator (RT8008-33GB).

Anyone with clues as to what might be causing this?

2

Post a picture of how you have it wired up so we can better help.

3

Maximum current draw for a motor is stalled, not in full swing. There is also a higher current transient when the motor starts than while it's running full swing. Your DMM works by sampling and will probably miss the startup spike. A motor also can kick back a high voltage spike when it stops, though the controller in a servo probably clamps that.

2 Likes
4

@RWB it was a simple servo 'test' connection – servo + to VIN, servo GND to GND, servo signal to D0. no-load test, i.e. servo was not connected to any mechanical load.

Yes, good point on transient readings @DevRandom. I was tracking max amperage on a fluke 87V (250us), but I'll check this on the scope again.

The most pertinent detail as I mentioned in my original post is this: 'garden-variety' analog servos do not exhibit this behaviour (frying the Photon's VR). Furthermore, the Photon datasheet says VIN can provide up to 1A. Some analog 'standard-size' servos pull more power than this TGY-S712G wing servo and the transient current never posed an issue for the Photon's VR.

Poking deeper into this particular servo reveals that it uses a rotary pot with some sort of 'clutch' mechanism, i.e. there's no physical endstops on each end of the travel on the output shaft. I know this might sound unrelated to my question at first, but this somehow led me towards thinking about PWM timings and the myriad standards (or lack thereof) that servo manufacturers set to control their servo arms.

This short note on the Particle Docs - Servo provided a partial answer:

Note however that attempting to drive a servo past its endpoints (often indicated by a growling sound) is a high-current state, and should be avoided.

In the case of this servo, because there are no physical endstops, the growling never happened, and perhaps some sort of feedback loop occurred (I'm not an engineer, so pardon the wording) on the servo IC which kept demanding more power to the servo motor to reach an impossible position. That said though, the servo wasn't moving when the VR fried, the arm just travelled to the end and stopped, and... pop.

This makes sense to me because the VR on the Photons did not fry instantaneously, but only when the arm was sent to the extreme ends of its travel (0º, 180º). I'm not sure if any servo IC have the ability to clamp and limit invalid PWM timings. Perhaps I sent PWM timings that put the servo into a 'high-current state' >1A from VIN – it would be great if someone can explain this 'high-current state'.

I subsequently found that this servo works within a narrower angle, via a different mcu and then carefully using another Photon with a potentiometer to find mid/min/max positions.

All this indicates that we have to be extremely cautious with the Servo.write() and Servo.writeMicroSeconds() when testing a new servo out: powering it via the Photon's VIN might just kill your Photon, so use a separate power source while confirming the maximum/minimum range of your servo's PWM timing.

I thought this could be a useful lesson to share with the community.

(now I'm just waiting on new VRs to get those 2 Photons running again...)

1 Like
5

Your assertion that the endposition did actuall put the “stall-load” on the servo and hence cause the current to go through the roof frying the VR seems to be the solution to the “puzzle”.

One other thing the Photon’s regulator doesn’t like at all is noise on the Vin pin. We have seen multiple instances where noisy power supplies caused the regulator to oscillate itself to death.
It’s possible that the servo causes some similar noise on the Vin pin to make the regulator commit suicide - but this usually only happens after prolonged exposure to the noise.
Some filtering caps may help remove that problem.

2 Likes
6

Thanks @ScruffR!

Your notes on the Photon’s regulator are much appreciated and have clarified suspicions that this might be related to the way the servo draws power – given the higher polling rates at which digital servos update their positions, all that switching noise on VIN might also have contributed to oscillating the regulator to death as you so vividly described. :slight_smile:

Filtering caps – definitely adding them in next time. I feel tempted to intentionally try this experiment again with filtering caps, while over-driving the endpositions…

7

@chuank, just to be clear, what is possibly being stressed is the USB power source and the USB cable which due to various factors can create an oscillating condition where the VR will kill itself. The USB supply and cable quality play a huge role here.

I suggest you try powering both the Photon and any servos via a single good quality 5VDC supply to Vin with a 470uF cap near Vin to protect the Photon against large transients. Make sure the supply has plenty of current headroom (2-4amps).

2 Likes
8

One other note, when powering via USB, the “weak point” is not the VR but the protective diode which protects the USB port from being back-powered when you supply power to Vin.
When pulling 5V from USB to Vin the regulator isn’t even in the path of current.

2 Likes
9

However, anything that causes ringing on the Vusb side will reflect back to the VR and may create a self-destructive condition.

3 Likes