Servo fail on power-up, cleared by power cycle

[swatson999]

This hasn't happened in a long time, but it did today. On power-up, I got a Pitch Servo failure/off-line message. Power cycling the SV didn't clear it, but power cycling the Master did.

Any ideas why this might have happened?

 

[rfazio1951]

Steve, mine has done this two times in the past 3 or 4 years. I also tried cycling the SV to no avail. Powering down the servo is what works. If you power down the servo and do a network search it will pop back up. Or just power down everything via the master. I'm not too worried about it. It has not happened ever while flying , only on startup.

 

[vlittle]

+1. I recycle the power to the servos to fix it. It's always the same servo that fails. Only occurs occasionally at power up. Rare enough to not be a concern.

Vern

 

[swatson999]

I agree it's not a concern, but on the other hand, it isn't *right*, and should be addressed.

I don't know if this is a function of the boot cycle and the task prioritizations or something like that, but I shouldn't have to *ever* power cycle a servo (or any other peripheral) to get it come up and communicate with SV at boot time.

This is clearly not a wiring or installation issue...it's something about the power-up/boot cycle for these devices that caused it.

 

[GlennB]

FWIW, I had this problem a while back.  The pitch servo would either display a fault on startup, or work for the entire flight.  Sometimes a reboot or network discovery would bring it back.

Eventually the fault started appearing in flight, as an intermittent (and a maddening, repetitive audio warning!)  Clearly, something had to be done.

A day's work, including monitoring the data lines with a scope, narrowed it to a pin in the D-sub connector at the servo.  The pin wasn't seated fully into the housing, so pressure from the opposing pin in the other half of the connector caused it to withdraw slightly during the year or so after installation.  I was able to replicate the fault by displaying attached devices on the Skyview, and wiggling the wires at the back of the connector.  Another year since snapping the pin fully in, there hasn't been a recurrence.

So, why only on startup?  As I understand it, the duplicated serial lines to the servo are there for redundancy.  My suspicion is that there's an integrity check of all the wires at boot time, though the servo will function with a single failure after that.  The faulty pin in our installation was indeed one of the data lines.

 

[swatson999]

I'll double-check all those pins again at annual in February...thanks for the suggestion! To be honest, I was extremely careful to check every crimp on every wire, including pull tests, visual inspection with an 8X loupe, and ensuring that every pin was secured in the connector, but you never know what might have worked its way loose over 2 years

The thing is, I have a sneaking suspicion the boot-up cycle needs some tweaking...based on my audio "cut-out" when it says "Dy--n Skyview", the quick shot of red X's for all the devices, the Alarm log *always* showing one of the two servos off-line during the boot cycle, etc. It's like it just needs a wait state or two to give everything time to power up and come on-line before attempting communications with the peripherals.

 

[GlennB]

I'll double-check all those pins again at annual in February...thanks for the suggestion!  To be honest, I was extremely careful to check every crimp on every wire, including pull tests, visual inspection with an 8X loupe, and ensuring that every pin was secured in the connector, but you never know what might have worked its way loose over 2 years

I thought I was pretty careful too, but it suckered me by behaving perfectly for more than a year.  It was a little easier to start tracing, given that the aileron servo was always OK, so the fault had to be downstream of where the wires tee off to both.

The thing is, I have a sneaking suspicion the boot-up cycle needs some tweaking...based on my audio "cut-out" when it says "Dy--n Skyview", the quick shot of red X's for all the devices, the Alarm log *always* showing one of the two servos off-line during the boot cycle, etc.  It's like it just needs a wait state or two to give everything time to power up and come on-line before attempting communications with the peripherals.

Can't comment on that, sorry.  Our servos are on the avionics master, so they don't get power until after engine start.  There is, naturally, a "fail" annunciation for both servos until then, but it goes away within seconds.  For the same reason, I don't hear the startup audio.  Might try powering up in a different order, just to test it.

 

[swatson999]

No avionics master, so hard to power up in a different order.

These issues, particularly the audio getting clipped, didn't happen until the release of the version with the "faster" boot-up process.

 

[dynonsupport]

Steve,
I've seen this a few times in our plane too. We have a similar setup with the servos on with the master, and if I had to guess, it's a power drop that occurs with engine start that annoys the servos. Every time it happens, a power cycle of the servos themselves works. As you saw, rebooting the screen doesn't help since it isn't a screen issue.

Agreed here that it isn't right, it just hasn't been high on our list. I've bumped it and we'll see if we can figure it out.

We're still not getting other reports of the clipped audio so that's a hard one to track down.

Understand that SkyView has two processors, one for the main stuff, and one for talking to the various network devices. The processor that talks to the servos is up and running within milliseconds of booting SkyView, so it's on for 20 seconds and stable long before the main application comes up. It can and does run independent of the main application. It also has nothing to do with audio, which is its own subsystem.

So I doubt the faster boot has anything to do with the servos being offline. More likely that your battery is a bit weaker or it's a bit colder out and you see this more due to that.

 

[dynonsupport]

Steve and others,
If you see this AP offline error, a datalog would be helpful. We're trying to find out what event in the aircraft causes the servos to go offline.

If you have it happen, and can pull a datalog within an hour afterwards, contact our support team and we'll tell you how to upload them to us.

Thanks!

 

[swatson999]

Steve,
I've seen this a few times in our plane too. We have a similar setup with the servos on with the master, and if I had to guess, it's a power drop that occurs with engine start that annoys the servos. Every time it happens, a power cycle of the servos themselves works. As you saw, rebooting the screen doesn't help since it isn't a screen issue.

Agreed here that it isn't right, it just hasn't been high on our list. I've bumped it and we'll see if we can figure it out.

We're still not getting other reports of the clipped audio so that's a hard one to track down.

Understand that SkyView has two processors, one for the main stuff, and one for talking to the various network devices. The processor that talks to the servos is up and running within milliseconds of booting SkyView, so it's on for 20 seconds and stable long before the main application comes up. It can and does run independent of the main application. It also has nothing to do with audio, which is its own subsystem.

So I doubt the faster boot has anything to do with the servos being offline. More likely that your battery is a bit weaker or it's a bit colder out and you see this more due to that.

Thanks for the info! If it happens again, I'll grab the diagnostic log file for you.

Note that this did not occur at *engine* start...it occurred at initial Power-on of the aircraft (Master ON) which brings up Skyview and all of its subsystem (and the rest of the avionics).

Agree it might be related to temperature/slightly weak battery, though...anyway, will get a data file if it occurs again!

Thanks!

 

[jakej]

Steve

A thought - it may be useful to connect a DMM to observe the volts while the power up is happening too.

Jake J

 

[swatson999]

Argh...got it again yesterday but forgot to grab a data dump...next time!

Again, a power cycle cleared it, and no issues in 3-4 hours of flight since...*very* intermittent problem (previous incident was probably 20 hours prior).

 

[Schorsch]

My servo issue started in October - initial symptoms: pitch servo shows OFFLINE, but while that servo is powered it put funny jerky resistance on the controls - AND the roll servo does nothing but SLIP (it's detected just fine but zero torque applied to controls). For the next few months, cycling the power to the servos (often a few times) usually fixed the issue for the entire flight.

Starting a few weeks ago, this work-around no longer works; new symptoms:
Usually only one, often no, servos are detected
The detected servo doesn't work (slips continuously)
Roll Servo under power causes jolted, weird resistance on the controls.

I tried the usual steps (reloading entire SkyView package from new download, force network loads, etc)

One day's single exception:
After landing (flight without servos working), I restarted SkyView and both servos were detected normally, I forced another network load, and a servo test was successful moving both pitch and roll servos normally.
Then I restarted Skyview and none of the servos were detected.
3 or 4 subsequent restarts also didn’t detect both servos.

So without touching anything and even without any vibrations from running engine/flight, it worked on one try and not otherwise; in my mind this rules out any wiring or similar issue?

And I have the diagnostic file, if needed! RMA return of both servos should arrive today.

 

[Dynon]

I'm not immediately identifying your RMA to see if we found anything here. Are you saying your servos are on their way back here under RMA, or that we have them coming back to you?

 

[Schorsch]

imprecise me :-[ Dynon recvd both servos yesterday and I just uploaded diagnostics file where the full functioning inbetween non-functioning happened.

Flew 1 year without this issue ever happening, only started shortly after 11.0 / new boot-sequence.

 

[Dynon]

What's the RMA number, or do you have an email trail with a case number in it? I want to make sure we hook up your datalog to your return (that should've happened if we prompted you to send your datalog)