Today I believe I have discovered the root cause, or at least the source of our error. It appears to be the Garmin 510. I will describe what I did, and what I found below. The suggested resolution is at the bottom of this post.

I received the following email, forwarded to me from our installer today. This was from the Foreflight tech support.

“Could we try and get some detailed information from you?

While connected to your Garmin devices, open ForeFlight select **More** (**Menu** if using an iPhone)> **Device** > please take a screenshot of this page >Next, tap on the Flight Stream Connext tile and take a screenshot of this page.

Please then attach the screen shots to a reply to this email or send them to team@foreflight.comattn:213199″

Today I decided to go back down to the airport and gather the requested information. Nothing was mentioned of whether I should be in flight or not to show this data but I assumed we needed to be receiving ADS-B towers to get usable information so I went up for another test flight. The weather was once again severe clear with no precipitation anywhere in the area.

For this flight, I again went up with the same two iPads described in the previous post. I also took the same Stratus 2. One iPad was initially configured to bluetooth to the Garmin panel, one with wifi to the Stratus. The first screen captures were from the iPad connected to the Garmin panel, both GTX 345 and Flight Stream 510.

The above was the configuration right out of the box, after takeoff and once towers were in view and data was flowing.

The below was what the map screen looked like. All of these were taken within a few minutes of one another, as fast as I was able to take them, fly the plane solo, etc.

Since our previous test, I’d installed Garmin Pilot onto my iPad mini that normally is used with 54SS. I still don’t have any experience with Garmin Pilot, but I tried to grab any screen shots that may prove useful. Again, these are taken on the iPad connected to the Flighstream 510 and the Garmin 345 via bluetooth. 

Here I have an iPad connected to the panel via bluetooth, and the Stratus via wifi. It was an accident that I had both at once, but I thought it may show you something as the radar was being received and there was no error message. 

Once I had captured the requested screen captures, I started doing some experimenting. Here is what I found.

Actionable Results

iPads connected to the Stratus showed no errors, as before.

iPads connected to the Garmin panel, both to the GTX345 and Flightstream 510 showed the “radar not available” message. This error is consistent.

iPads connected to ONLY the 345 or the 510 showed the same issue as before, “radar not available” the same as in the test on 12/1/17. However by allowing about 15 minutes for the data to stabilize/update/whatever, I found the iPads connected to the GTX345 ONLY would eventually remove the “radar not available” message and the grey crossed lines. However, iPads connected to the 510 ONLY would continue to display the “radar not available” message for as long as I let the test run.

In our prior test, we did not allow a full 15 minutes for the changes to take effect, mainly because when we connected to the Stratus the error message disappeared with 60 seconds so we expected a similar result from the GTX345. That is the difference in this test on 12/4 vs. the last test on 12/1. I was able to replicate the issue across two iPads. Whichever one was connected to the 510 only, showed the problem. The problem could be eliminated by connecting to the 345 only, or of course the Stratus.

Update/Refresh rate issue

I did note that even when the iPads were working as we would expect, with no “radar not available” messages when connected to the GTX345 only, that the data refresh was different still than what is shown on the GTN650. The data would consistently be only 2-3 minutes old on the GTN, but maybe 10 minutes old on the iPad, even though it appeared to be working properly. It appeared as if the 15 minute update issue is still present, but it’s not 15 minutes now. It’s 10 minutes, or 5 minutes.

As you look through these screen captures, understand that I am flying single pilot in this test, with the sun going down blinding traffic search in about 40% of the sky, trying to avoid traffic that was in the area. I couldn’t just stare at the update results, but it appeared that every update on the iPad was at 4:30, or 4:35, or 4:40. I didn’t see any updates at 4:32 or 4:36, it was always on an even number (I know 5 is odd, I hope you get my meaning.) Here are all the screen captures I took at all stages. Note the update time stamp showing the time sequence I reference, while the actual time stamp at the top changes. When I would pull up the GTN650 time stamp, it would consistently be updated to what I’d call a random time, 4:37, 4:29, etc. The GTN time stamps are also consistent with what I see when flying other airplanes, the data block on Foreflight doesn’t update on even times when flying those planes.  

I apologize the above picture is blurry. Single pilot and all that. As you can see in the above picture, the picture was taken at 4:54. The last update is 4:40, which has just turned orange indicating it has gotten old. This was during testing, so it took a few minutes for the iPad to update to the latest information after it connected. However in this instance it took several minutes, till 4:55 if I remember correctly, which you can see the result of in the previous screen capture just above. However what is concerning is that even with a proper connection, and old data, the iPad doesn’t update from the GTX345 for almost 15 minutes even though the GTN650 has data that is only 2-3 minutes old.

It’s possible that this is just a reporting issue where Foreflight reports updates differently that the GTN650, however since this is an issue that I don’t see replicated in the CAP aircraft I fly with the same iPad, I think it’s another issue with our installation.

Interestingly, when I connected to the Stratus, the radar not available message goes away almost immediately. When I connect to the GTX345 it takes as much as 15 minutes for the message to go away. However I seem to recall that the Stratus buffers/saves data so that it can be delivered in a burst when connected to an EFB. Something about it being used with devices that are operating on batteries. I assume that the GTX345 has no such feature since it’s designed to run on ships power and operate continuously.

Recommended next steps

Since the 510 is such a small and easily removable device, my recommendation is to ship a replacement 510 directly to myself to be installed locally. I can then test fly with the replacement 510 to see if the problem persists. This is opposed to shipping the 510 to Pee Dee in SC, necessitating a another flight to maintenance. If the replacement does not fix the problem, we know we have a software issue. If the replacement solves the problem, we know we had a bad device. Regardless, we can return the extra or bad 510 once we have tested. All it will cost is overnight shipping both ways which is less than the cost of a flight to SC. However tech support may have a better idea once they have this additional data.