ADSB - Kinematics Position error with Echo UAT the fault of FAA?

Daleandee

Final Approach
Joined
Mar 4, 2020
Messages
7,099
Display Name

Display name:
Dale Andee
Don't know how to title this or exactly what forum it should go into. I read some on VAF (not a member) and found a post (see partial quote below) that was interesting but can't confirm what is being said. Anyone know if this has been proven to be true?
Last year I started getting a consistent "red box" in the Kinematics Position section of the PAPR. I received the free special altitude encoder from UAvionix that was supposed to fix it, but I I still had the error. It eventually was determined by the FAA that it was their equipment, not the ECHO UAT, that was causing the PAPR error. The FAA's resolution was to remove the Kinematics position box from the PAPR because the problem could not be resolved on their end! Now I am back to zero errors on the PAPR.


FWIW my last PAPR report (three months ago) still has the kinematics position box on the PAPR. I have the Echo UAT unit and it has performed flawlessly thus far. If what is stated above is true I wonder if uAvionix will restart production of these units?

Curious ...
 
Wasnt Echo UAT was one of the units that supported anonymous mode?
 
I'm guessing from the lack of replies that nobody else has a clue either. FWIW, I sent an email to Shane @ uAvionix. I'll share an answer if I get one ...
 
Buy crackerjack avionics, win crackerjack prizes?
 
Don't know how to title this or exactly what forum it should go into. I read some on VAF (not a member) and found a post (see partial quote below) that was interesting but can't confirm what is being said. Anyone know if this has been proven to be true?


FWIW my last PAPR report (three months ago) still has the kinematics position box on the PAPR. I have the Echo UAT unit and it has performed flawlessly thus far. If what is stated above is true I wonder if uAvionix will restart production of these units?
I had this problem last August and posted about it here: https://www.pilotsofamerica.com/com...-kinematics-implications.148444/#post-3552179

It was FAA issue which they were working to correct. I retested a couple of weeks later (and several more times after that) and the problem did not show up.
 
My understanding is that the kinematics position error implies that you jumped from position A to position B faster than the FAA thinks you should have been able to. This would suggest to me, that if it is a problem with your installation, either the GPS, the altitude encoder, or the altitude read from the transponder is giving you bogus results. (I have no idea how they merge the transponder and add on encoder altitude data.) Got a way to log your data yourself and look for discontinuities?

The add on encoder was supposed to be a fix for when you are flying through BFE and your transponder is not being triggered often enough - I wouldn't think that would be an issue in "rule" airspace.

usual disclaimers...
 
I sold mine years ago due to this issue. They screwed up not adding another serial port for the encoder. Really liked the weight and Crackerjack box prized size of it though.
 
As I understand it there are two separate issues.

Erroneous kinematic failure errors were a product of the FAA's ADS-B performance monitor. My understanding is that under times of heavy air traffic the servers that aggregated ADS-B data from across the country would bog down and start delaying or dropping packets. The delay would essentially show the aircraft jumping from place to place and trigger an erroneous kinematic failure. For a while the FAA just removed the position delta from the PAPR. I *think* they've fixed the performance monitor and it's back in the PAPR now. This issue wasn't specific to echoUAT. It'd show up across all vendor's ADS-B products. Faster airplanes made the issue worse. It just hit at a bad time when many echoUAT customers were running PAPR to verify their altitude encoder.

The second issue is that the echoUAT didn't have its own altitude encoder. The echoUAT got its baro altitude from mode C transmissions. The problem was that if your aircraft wasn't getting mode-C interrogated (probably in rural areas or flying at low altitudes) the echoUAT wouldn't report baro altitude out. My understanding is that when the product was originally developed they weighed the lesser of two evils - not outputting baro altitude in rural areas vs. the possibility of a separate encoder outputting differently than the mode C. The former was chosen. Later when uAvionix developed the skyBeacon they figured out how to prove the latter wouldn't be an issue. As time progressed the FAA ADS-B system grew and they got more towers in more places than had mode C interrogators. The FAA was no longer comfortable with the echoUAT solution. uAvionix wanted to do right by their customers and offered free altitude encoders to echoUAT customers.
 
Last edited:
Back
Top