XPDR Caution

[jakej]

Hi Steve,

It still appears to be power related IMO, I've seen this problem before (one other aircraft) & leaving avionics off until after start fixed the issue. In his case the Hex code sometimes changed (WTF)
So I would strongly recommend you somehow leave the Transponder power off until after start too.
Just my .02 worth

 

[swatson999]

I agree that it's power related...but I contend that the XPDR should be designed to be immune to power sags and/or spikes (if that's what's causing it...in this case, a power sag).

BTW, it's not entirely clear whether it's the sag that's causing it, or the inrush after the power comes back up.

 

[jakej]

Personally I don't care in the end as to cause as long as the issue is fixed permanently - I can understand the 'need to know' but I don't have the time to go there

 

[swatson999]

It's the engineer in me . Unless I know the root cause, I'll always wonder if the "fix" has really fixed the problem or not.

I've been bitten by "fixes" that didn't fix the actual problem too many times to count...

 

[lolachampcar]

I've seen this issue a few times in the last two months having not had it in the four years / 500 hours previous. The battery is now four years old so voltage sag while starting could be the reason.

 

[jakej]

Leaving the avionics off (includes Transponder) is an industry wide practice that goes back decades, why would you do any different now especially considering the issues appear to be voltage 'sag' related ?

 

[Raymo]

Leaving the avionics off (includes Transponder) is an industry wide practice that goes back decades, why would you do any different now especially considering the issues appear to be voltage 'sag' related ?

Leaving them off does go back decades and still applies to decade old hardware but modern avionics are built to handle power surges and sags without damage.

 

[swatson999]

Precisely...because there's no need to add a switch (a single point failure node) to the circuitry to correct for what shouldn't happen in the first place.

I'm not a EE, but I wouldn't accept a piece of flight hardware for any of my projects which can't take power surges, spikes and sags and suffer no ill effects.

Note that during normal starts, 99% of the time, the power drops low enough to take everything that isn't battery backed off-line (so my SV stays up, as desired, to enable monitoring of the engine parameters).  Everything else shuts off at whatever voltage it's designed to shut off at, and then restarts when power comes back to a high enough level that it turns on (which is what a switch does, anyway...).

But for some reason, when power goes *very* low during a start, it seems the XPDR has a problem on occasion...either it's not completely shutting down, or it's starting up in an odd manner when power rises.  Either way is not clean, and hints at a design issue...

 

[dynonsupport]

Dynon's equipment, including the transponder, is designed to be on during engine start. It doesn't appear that Steve's transponder has been damaged at all, so that's not the issue. It also doesn't appear that the transponder wasn't working while the message was displayed. It appears that the only issue is a warning that is displayed.

Likely the issue is just that we persist messages from the transponder. If the RX PSU FAIL (receiver power supply fail) message is received we show it, even if it's no longer valid. In fact, the way the transponder protocol is designed, there's no particular way to know if the error is still present, only that it occurred at least once. We can however tell if it has rebooted, and clear the messages on that.

So likely the issue here is that while you crank, the voltage goes way down, and this causes the transponder to temporarily fail, but not totally reboot. It now tells us about this failure, and we display that message. This doesn't mean it's still failed, since it likely recovered just fine. But the error still exists in the queue.

If the voltage didn't go quite as low, no message. If it goes lower, it reboots and the message is cleared. So this appears to be a corner case of our messaging system we didn't quite consider. While we design for and support aircraft with no avionics master, it is pretty rare, so this might be the first time we've heard of this issue.

I'm not quite sure how to handle this issue- we want to persist messages so you can actually go and see them even if they were only momentary, like a loose wire could cause. But we also don't want to keep showing ones like this that are caused by expected behaviors. We'll have to think about it.

I do just have to say- the idea that all flight hardware can support any dip or surge in power without ill effects is not something that is generally required by the specs. Generally the way certified equipment gets around having to test for every single possible case is to throw in a switch so the user can cycle it. We don't like that either, but even a 787 is allowed to have power up and down procedures to manage issues like this. It's a pretty high bar to say no matter what your input does you must always recover perfectly.

 

[swatson999]

Dynon's equipment, including the transponder, is designed to be on during engine start. It doesn't appear that Steve's transponder has been damaged at all, so that's not the issue. It also doesn't appear that the transponder wasn't working while the message was displayed. It appears that the only issue is a warning that is displayed.

Likely the issue is just that we persist messages from the transponder. If the RX PSU FAIL (receiver power supply fail) message is received we show it, even if it's no longer valid. In fact, the way the transponder protocol is designed, there's no particular way to know if the error is still present, only that it occurred at least once. We can however tell if it has rebooted, and clear the messages on that.

So likely the issue here is that while you crank, the voltage goes way down, and this causes the transponder to temporarily fail, but not totally reboot. It now tells us about this failure, and we display that message. This doesn't mean it's still failed, since it likely recovered just fine. But the error still exists in the queue.

If the voltage didn't go quite as low, no message. If it goes lower, it reboots and the message is cleared. So this appears to be a corner case of our messaging system we didn't quite consider. While we design for and support aircraft with no avionics master, it is pretty rare, so this might be the first time we've heard of this issue.

I'm not quite sure how to handle this issue- we want to persist messages so you can actually go and see them even if they were only momentary, like a loose wire could cause. But we also don't want to keep showing ones like this that are caused by expected behaviors. We'll have to think about it.

I do just have to say- the idea that all flight hardware can support any dip or surge in power without ill effects is not something that is generally required by the specs. Generally the way certified equipment gets around having to test for every single possible case is to throw in a switch so the user can cycle it. We don't like that either, but even a 787 is allowed to have power up and down procedures to manage issues like this. It's a pretty high bar to say no matter what your input does you must always recover perfectly.

Thanks for the long answer...I think you're probably right about the corner case. I could live with it on the rare occasions it happens if I know that's what it is, and there's no damage (doesn't appear to be), and I can clear the message (which currently, I can't). Anyway, still probably a nice exercise for any junior engineers you have around...

As for power surges/sags/spikes, yes, *any* sort of deviance is a bit broad of a statement, and there are specs as you know on what they're supposed to handle (usually, of course, the more worrisome is a surge or spike of sufficient amplitude with a long enough time to cause some deleterious effect), but power outages, "brown-outs", and so forth shouldn't cause any damage, either, nor affect the proper operation of the equipment when the fault is removed.

We're probably saying the same thing, though...but in any case, if you think this is something you may wish to look at sometime in detail, I have the data log and alert log if you wish to see it (I think I have a diagnostic log, as well).

 

[lolachampcar]

My battery is getting a bit long in the tooth and I am now seeing Xponder warning messages on most starts. I simply cycle the breaker and the warning goes away which sounds like a perfect match for your description.

Thank you!

 

[RVDan]

I am having this same problem. This just started recently after the backup battery fully discharged itself after shutdown. Recycling the XPDR power removes the warning. Never saw this in previous 2 yrs of flying.

 

[Dynon]

lolachampcar - Do you mean aircraft battery or SkyView backup battery?

 

[lolachampcar]

Actually, both although I attributed the issue to the main ship's battery (LiFo) which is showing a couple of tenths down on resting voltage before starting. That said, the droop under starting is much less with my battery then standard lead acid.

I am just wrapping up a conditional and the Dynon back up battery is still passing even at four or so years old.

 

[coyote]

As another data point, I have had the same problem. Occasional "rx psu failure" transponder message after startup. No recognizable change in transponder function. Would be great to be able to clear the message if the function is normal.

 

[Dynon]

It's a real report of a fault. If occasional is more than once or twice ever, we should probably take a look at it.

 

[swatson999]

OK, I still get this occasionally...XPDR message after engine start (and all avionics are already powered on). Cycling the master after the engine is running clears it, but I wonder if Dynon can make this one of the messages that can be cleared by acknowledging it?

Once it's been sent to the screen and the user sees it, is there any reason not to clear it from the display?

This is the Tx PSU LO message that I originally posted about, and the presumed corner case of voltage dropping to some midway-low point (see discussion above).

 

[Dynon]

Unfortunately, because of the protocol limitations described above, this is a hard message to clear and know that what we're showing is "the right thing". We haven't found a way to account for the (unknown) chance that such a condition persists vs was just a transient outside of having the unit power cycled and come up error-free.

 

[swatson999]

Unfortunately, because of the protocol limitations described above, this is a hard message to clear and know that what we're showing is "the right thing". We haven't found a way to account for the (unknown) chance that such a condition persists vs was just a transient outside of having the unit power cycled and come up error-free.

So that's kind of my point...you don't know which it is (and apparently it's transient), allow the user to acknowledge it and then remove it.

It's not really a safety of flight issue unless you're IMC, in which case you'll know if it's a real persistent fault anyway when ATC loses your beacon. VFR? Not a problem (I've had XPDRs fail and just coordinate w/ ATC if in Class B, C or D via the radio). Ground? Seriously not a safety problem, or easily sorted out if it IS persistent.

I can see your point, though...I just think that having no way to clear the warning when the human in the loop *knows* it's transient isn't quite right, either.

 

[breister]

Thanks for the long answer...I think you're probably right about the corner case.  I could live with it on the rare occasions it happens if I know that's what it is, and there's no damage (doesn't appear to be), and I can clear the message (which currently, I can't).  Anyway, still probably a nice exercise for any junior engineers you have around...

As for power surges/sags/spikes, yes, *any* sort of deviance is a bit broad of a statement, and there are specs as you know on what they're supposed to handle (usually, of course, the more worrisome is a surge or spike of sufficient amplitude with a long enough time to cause some deleterious effect), but power outages, "brown-outs", and so forth shouldn't cause any damage, either, nor affect the proper operation of the equipment when the fault is removed.

We're probably saying the same thing, though...but in any case, if you think this is something you may wish to look at sometime in detail, I have the data log and alert log if you wish to see it (I think I have a diagnostic log, as well).

There is a way to prove or disprove this theory.

Install a bigger, or second in parallel, battery temporarily.

I switched to an EarthX and starts went from barely two chances, "lucky, lucky, lucky," to "VROOM!"

Also check all master power leads and grounds and cable connectors.  On my previous plane a weak crimp on the battery connector caused all sorts of intermittent gremlins.