Over the summer I’d been having issues with getting ADSB weather on my IFD550. As I learned more about it, it became apparent that my GTX345 was getting the weather and traffic, and I could link my iPad directly to it to display weather there.
Working with Avidyne technical support, as well as experimenting on my own, I learned that the innocuous error messages I’d been getting about a UTC Mismatch were part of the problem. I was getting them at every flight.
The error message led me to find that my UTC time was routinely displaying local time, not actual UTC time from the satellites. Having the incorrect time was blocking the upload of this data. Working with my Avionics shop (Lancaster Avionics, KLNS), and with Avidyne, we shipped the unit back for warranty repair.
Since the unit came back, I have not seen the UTC Mismatch error again.
I headed over to the airport to polish the airplane and make sure it was ready for my Florida trip the following week. I decided that I was too hot and sweat soaked to fly after the airplane was cleaned, so I left the airplane in the hangar and updated the JEPP data while I was there.
That is when I noticed that the IFD550 was telling me that the fresh data I just uploaded wasn’t current. The error indicated my data wasn’t in sync, and asked me to confirm that. I knew that my data was correct, so I started looking for the problem.
The error was raised because the Avidyne IFD550 thought it was still July 29th! That is the last time I’d flown, so the date was stale! Time was correct, but date was wrong. I guess this is because I did the update inside the hangar and the satellites were not in view. I’d have thought a simple clock would have kept track, but I guess not.
To be sure the unit was functioning correctly, I pulled the airplane out of the hangar to ensure the satellites were in view. The date didn’t update immediately, so I encouraged it with several reboots. After the third start, the date corrected itself.
Observations: I’m surprised that the unit didn’t have an internal clock that kept up with the data while out of satellite view and in the hangar. Given that it took several reboots to self-correct the date, I’d like to know if the date will ultimately update in flight and on it’s own without rebooting. No one has really been able to answer that for me as yet.
I’m doing a trip this weekend and will pull the airplane out of the hangar first, like normal, and check to see if the date is still showing Aug 10th. If it is, I’ll make sure the time is at least accurate, and leave the date as it is. that will tell me if it will catch up on it’s own. It could be my process on the previous startup in the hangar confused it a bit.
I’m obviously going to track the ADSB weather uploading, and ensure that works as well.
NAV/COMM Drama
Shout out to Lancaster Avionics at KLNS. I flew up to drop off my IFD550 for the warranty work, and was very confident in relying on my KX-155 for the few weeks it would take. With the IFD550 out of the panel, I was pulling up to the hold short line when my trusty and powerful little KX-155 outright failed. No COMMS. No Navs. Period.
I used my phone to call the tower, and taxied back to the avionics shop. Turns out my unit tests fine on the bench, but fails when in the airplane. They thought it was capacitors inside the unit, and repair could be costly and tenuous. I ordered a new GNC225 to replace the KX-155, but that they had to schedule my work for February.
In the meantime, Lancaster Avionics loaned me their KX-155 so I could keep flying IFR.