What's new
Van's Air Force

Don't miss anything! Register now for full access to the definitive RV support community.

Weird Transponder Problem Found

GalinHdz

Well Known Member
The guys that are partners in a Grumman Cheetah in the hangar behind mine told me they had been fighting an issue with their transponder (King KT76A) for over 3 months. Their transponder worked fine when squawking a code (like 1200) but when they went to squawk altitude (Mode 3C) the code would instantly change to 7770 with no altitude being displayed. Worst was that their Tail Beacon ADS-B would act the exact same way. The squawk was correct until the transponder altitude was turned on. Then even the ADS-B would display 7770 with no altitude being reported.

This happened at different airport towers, different approach control and even different center control so they knew it wasn't an FAA ground system error. A local avionics repair station swapped their transponder with a known good one and it did the exact same thing. They checked all the gray-code wiring and it checked out perfect. No matter what code was dialed up, as soon as the altitude reporting was turned on the, squawk went to 7770 with no altitude displayed. It was baffling.

I told them I had never seen or heard anything like this but would try to help out. With a person from a very well known large aviation company here at our airport I spent several days discussing transponder operation theory trying to make sense of this. We eventually theorized that somehow the altitude encoder wasn't sending the encoded altitude pulses at the correct point within the data stream to the transponder. If the encoded pulses were at a specific wrong point in the stream, 7770 would be the code transmitted with no altitude reported no matter what was actually dialed in. The Tail Beacon ADS-B would then report the erroneous data exactly as it was received, GIGO. With this recommendation they changed the encoder and the problem went away.

So if your transponder squawks 7770 when Mode C is activated no matter what you have dialed in, replace your altitude encoder. Hopefully you will never encounter this but I wanted to share it so you don't wind up with days of headaches and ATC getting angry at you as they did.

:cool:
 
Last edited:
Thanks for this reminder but that AD covered:

"...transponders transmitting misleading encoding altimeter information to ground-based ATC radar sites and nearby Traffic Alert and Collision Avoidance System (TCAS)-equipped aircraft." The actual squawk (Mode 3A) was unaffected and remained correct.

In this case the squawk code would be correct until they turned altitude reporting ON. Then the squawk would change to 7770, no matter what was actually dialed in, and no altitude information was transmitted. THAT is what baffled everybody. :cool:
 
Last edited:
KT76 vs KT76A

I hope this problem is not related to the "OLD" KT76 with a million "one shots" in the design. The KT76A is "micro" driven. All "76"'s should have been junked by now, right? John
 
Sorry, it was a KT76A not a KT76 my mistake. I corrected my original post.

To clarify; the transponder would not report any altitude at all. As soon as altitude reporting (Mode 3C) was turned ON, the ATC assigned Mode 3A code would change from whatever was assigned to 7770 no matter how much they changed what was dialed in. They could have 1200, 0346, 4752 or any other squawk dialed in but as soon as they turned on the altitude reporting the code would immediately go to 7770 and stay there. This made it appear to be a transponder problem, which it wasn't. THAT is what had everybody so baffled, the encoder was changing what the transponder was actually replying. The transponders were working as designed. The altitude encoder was the problem.


:cool:
 
Last edited:
similar not identical

KT-76A, passes bench test. GRT Sport SX200 EFIS is the encoder, via its dedicated Gray Code outputs. It has passed IFR pitot static and its menus show it is encoding accurately. It outputs to the KT-76A accurately. TSO`d uAvionix Skybeacon UAT.

Same style issue- CLEAN PAPRS and NO mode 3A flags, BUT- the encoded altitude Mode C will replace the squawk set in mode 3A of the transponder about 12 times per 25 minutes.

Trevor at uAvionics confirmed what is happening and flight logging with an app directly from the ADSB-Out UAT stream shows it is AT the altitude that should be going out as MODE C but it is 3A instead of the 1200 I have in the transponder!

So, if truly always 7770 is going out, that is odd as Mode C Gillham Gray code is in 100 foot increments. 70' going out tells me similar but different to my issue.

For me, it is most commonly 2500 and 2600 feet pressure altitude goiing out as 0120 and 0160 replacing my 1200 3A code. This will not flag on a PAPR, but ATC will ask why I am changing mode 3 from 1200! When it happens at 1600 feet PA my Mode 3A becomes 0760 instead of 1200. Mine are all equal to decoding gray codes, the 100 foot increment the encoder is actually pushing out.

I have a 4 foot RG58 for the transponder, will replace with a RG400 next. No pigtails, just BNC on each end. The encoder bundle from the EFIS to the transponder and powers and grounds might need to be re-routed but all have good pins/wires/continuity and seats. Stick and ball antenna right front footwell corner.

I have the current 1.5.1 uAvionix OS update and the only final curveball is I have a local ground for the nav lights, not a home run to the forest of tabs, which uAvionix said is fine. I have all LED nav bulbs, replacements that make intercom noise if I remove the added toroid magnet clamps. I guess I can also put the incandescents back in the right wing and tail bulb and see if that fixes the problem.

I have tried every Sensitivity from 30-40. All work for 3A code.

Thoughts?
 
Last edited:
Galin, thanks for the post. Do you know the make/model of the errant encoder that was replaced? Presumably a pretty old unit. Also, do you know the make/model of the new encoder.
 
Sorry, it was a KT76A not a KT76 my mistake. I corrected my original post.

To clarify; the transponder would not report any altitude at all. As soon as altitude reporting (Mode 3C) was turned ON, the ATC assigned Mode 3A code would change from whatever was assigned to 7770 no matter how much they changed what was dialed in. They could have 1200, 0346, 4752 or any other squawk dialed in but as soon as they turned on the altitude reporting the code would immediately go to 7770 and stay there. This made it appear to be a transponder problem, which it wasn't. THAT is what had everybody so baffled, the encoder was changing what the transponder was actually replying. The transponders were working as designed. The altitude encoder was the problem.


:cool:

See post #2
 
Shows you what I (don’t) know. I always thought gray code was an analog system.

You are correct it is actually an analog signal but representing binary data when decoded. To make it easier for us humans to use it there is an octal to binary conversion that goes on the the background. Easier for us to squawk 1200 instead of 0001 0010 0000 0000. One of the very first uses of binary data in electronics that dates back to WW2. :cool:
 
Last edited:
KT-76A, passes bench test. GRT Sport SX200 EFIS is the encoder, via its dedicated Gray Code outputs. It has passed IFR pitot static and its menus show it is encoding accurately. It outputs to the KT-76A accurately. TSO`d uAvionix Skybeacon UAT.

Same style issue- CLEAN PAPRS and NO mode 3A flags, BUT- the encoded altitude Mode C will replace the squawk set in mode 3A of the transponder about 12 times per 25 minutes.

Trevor at uAvionics confirmed what is happening and flight logging with an app directly from the ADSB-Out UAT stream shows it is AT the altitude that should be going out as MODE C but it is 3A instead of the 1200 I have in the transponder!

So, if truly always 7770 is going out, that is odd as Mode C Gillham Gray code is in 100 foot increments. 70' going out tells me similar but different to my issue.

For me, it is most commonly 2500 and 2600 feet pressure altitude goiing out as 0120 and 0160 replacing my 1200 3A code. This will not flag on a PAPR, but ATC will ask why I am changing mode 3 from 1200! When it happens at 1600 feet PA my Mode 3A becomes 0760 instead of 1200. Mine are all equal to decoding gray codes, the 100 foot increment the encoder is actually pushing out.

I have a 4 foot RG58 for the transponder, will replace with a RG400 next. No pigtails, just BNC on each end. The encoder bundle from the EFIS to the transponder and powers and grounds might need to be re-routed but all have good pins/wires/continuity and seats. Stick and ball antenna right front footwell corner.

I have the current 1.5.1 uAvionix OS update and the only final curveball is I have a local ground for the nav lights, not a home run to the forest of tabs, which uAvionix said is fine. I have all LED nav bulbs, replacements that make intercom noise if I remove the added toroid magnet clamps. I guess I can also put the incandescents back in the right wing and tail bulb and see if that fixes the problem.

I have tried every Sensitivity from 30-40. All work for 3A code.

Thoughts?

In my case the code was always 7700 no matter what. Yours gives different codes not just one specific code as in our case. Can you change from grey-code to RS232? Maybe that will correct your problem.
 
You are correct it is actually an analog signal but representing binary data when decoded. To make is easier for us humans to use it there is an octal to binary conversion that goes on the the background. Easier for us to use a 7 instead of a 1111 for each squawk digit. One of the very first uses of binary data in electronics that dates back to WW2. :cool:
So if it is an analog signal, how can it be sending pulses ‘at the wrong time’?
 
So if it is an analog signal, how can it be sending pulses ‘at the wrong time’?
Hence the baffling nature of the problem. It didn't make sense.

The analog signal represent "digits" based on how many microseconds they are from the 1st "start" pulse, and with transponders, an additional "bracket" pulse. An analog pulse a wrong number of microseconds from the "start" pulse will put the reply in the wrong place and therefore decoded wrong. To complicate things a 0000 in transponders represent the number 7 while a 1111 represents the number 0. This would explain the always 7770 code being displayed by ATC.

This is the best theory we could come up with to explain the problem. Without a real expensive spectrum analyzer that can read up to 2Ghz we can't be 100% sure.
 
Last edited:
Galin, I think it's just going to be time for a GTX 375 as I "need" a GPS IFR navigator and the ES transponder will replace the KT-76A at the same time in roughly the same spot.

I could get a Garmin 327 with serial input and ditch the Gray code lines from the EFIS, I'd need the port expander, but I need one eventually for an ARINC 429 box to make the GRT fully tied to the Trutrack 385 autopilot, plus the update to the Sport 200SX for the vertical navigation

Will be a bit of a stack shuffle for whatever extra height is in the 375 tray.

Was trying to do ADSB-out as simply as possible, which this WAS, until this issue appeared.

How my timing shifts only occasionally has me hunting interference. The encoder and transponder work, it's the Skybeacon reading Mode 3C as 3A that is the timing issue- can the KT-76A generate the timing slip?

The KT-76 needs Gray code, so I could add a serial to Gray code happy box, but does that fix the issue?
 
Last edited:
Galin, I think it's just going to be time for a GTX 375 as I "need" a GPS IFR navigator and the ES transponder will replace the KT-76A at the same time in roughly the same spot.
This might be your best "long term" option but only you can make that decision.

How my timing shifts only occasionally has me hunting interference. The encoder and transponder work, it's the Skybeacon reading Mode 3C as 3A that is the timing issue- can the KT-76A generate the timing slip?
That was the inital diagnostic but when they swapped the KT76A with a different one from another airplane that was working fine the problem stayed with the airplane. The "old" KT76A worked just fine in the other airplane. And that was baffling.

The KT-76 needs Gray code, so I could add a serial to Gray code happy box, but does that fix the issue?
It might but if the issue is generated within the encoder converting to RS232 won't cure the problem, GIGO. But I guess at this point it doesn't hurt to try.

:cool:
 
I'm close enough on ifr pitot static dates sliding in a loaner is easiest- if fixed, I'll keep it. If not- smells like upgrade time.

The encoder works- but is its timing contoller inside the transponder? That's how I read, if not mistaken, so that sure seems the easiest "fix".

Thanks for the timely thread and advice- I would have started a new one If I had not seen yours!

I asked for a loaner Skybeacon. The bench check tech says a KT76A cannot slip Mode 3C output to Mode 3A's squawk timing.
 
Last edited:
Simple!

Current OS is simply in error.

Reinstalled last OS, back to perfect, which is technically, quite unacceptable.
 
Last edited:
I'm not really clear on this issue but certainly have been IFR/VER certs for years. If I can offer any help, don't hesitate to email or PM me. Maybe be best if we talked on the phone.

Dan
Limited Repair Station Lic VDJR395X
 
Last edited:
Back
Top