This problem is not unique to the uAvionix Echo.
When the FAA started updating their SSR (secondary surveillance radars), this problem with mode S transponders became apparent. One of the transponder manufacturers first noticed it. It had something to do with the way mode S transponders were interrogated before versus after the SSR updates. I don't know the details. And for awhile, it would still work in areas that had not had their SSR updated.
In my case, I had two issues: I had not installed the Echo with proper strain relief at the Echo connection to the UAT antenna, and the weight and maybe vibration, physically broke the Echo. Second, was the issue we've been hearing about in this thread.
I had purchased the uAvionix Echo/Safefly 2020 GPS from my EFIS manufacturer (GRT) in 2017, and installed it with the "Setup Source" being the EFIS, and the "Control Source" set to "Transponder Monitor". This 'sniffed' the transponder squawk and it worked fine until sometime in 2022.
I hadn't done another PAPR check of my ADSB until early October, 2023. I was receiving some ADSB ground stations, and did see some traffic, so thought all was well. I learned about the problems after several PAPR test flights, most of which came back "No Report Available". This result was mostly due to the broken Echo. I did receive one or two actual reports that showed bad squawk code. I think this is called a bad Mode 3A.
Solution: uAvionix recommended their MUX cable. I did not buy their MUX cable since GRT already had been using the TMAP interface for sending most info to the Echo, so all I had to do was to hook up one additional wire from the GTX330 (non-ES) to the GRT HX EFIS to send the squawk code to the EFIS, and then it sent that along the TMAP interface to the Echo. And of course, I changed the "Control Source" from "Transponder Monitor" to "EFIS/Panel".
No more 'sniffing' the squawk, but now all is working well. The lesson I've learned from this...perform a PAPR flight check at least yearly, at every condition inspection.
