Flying Sunday afternoon I got the warning "Datalink Data Not Rcvd", the pilot's manual says:

This was the first time I have seen the message, I acknowledged the message and didn't see it for the remainder of the (short) flight.  My ADS-B in unit is the NGT-9000 and I was in a location and an altitude that I'm sure I had ADS-B coverage, I was at 6500 ft right over LGA.

Jeff

It’s pretty pathetic that my $300 consumer portable unit is more reliable when it comes to WX and traffic than the unit I dumped thousands upon thousands of dollars on. 

Hi Steve,

Attached is a photo of the alert. I get this alert on every flight. You can see from the NGT9000+ above the IFD that there is an airmet being received.

Hi Steve,

Thanks for looking into this. Attached are images of each page from today. I just noticed that this time it is an error about sigments instead of airmets this time. I don't think there were any sigmets in the area today.

On the return flight, I got the alert again (as mentioned, I get it every flight), but didn't pay attention to the full message. I was watching the ADS-B Stations page though. I noticed that coverage would switch between 0%, 50% and 100%. I was busy at the time the alert came on, so didn't catch if anything was above 0%, but I did notice that even with 100% reception, the alert stays on. I didn't take any pictures of the return flight.

Sorry, I can't seem to get the rotation corrected this time. Let me know if you need anything else.

AviSteve wrote: Yes, it was.  The stations page shows that SIGMETs are expected from stations 8, 13, and 14 but haven't all been received (because the text is white instead of green).   Our datalink guy is in the loop and he's looking into it.

Thanks Steve.  As a follow up on this interesting diagnostic screen:

It looks like AIRMETS were also expected on 9 and 10, and not received there either? 

In other words, does the indication of white text mean that there is data to be downloaded?  There are some that are filled in with dashed lines, meaning there is nothing of that data to send perhaps?

Based on the release process and dev cycles, is it safe to assume this is still a problem with 10.2.4.1? I seem to get them every flight. I.e. March 21 (10.2.3.1):

Again, April 12 with 10.2.4.1 you can see the AIRMET on the NGT-9000 in the upper left corner:

I didn't get a photo of the stations...

AviSteve wrote: 10.2.4.1 didn't address anything with that regard, so I'm sure the problem is still there.  We're looking into the way that the list of expected reports is processed.  I expect something to be found and fixed for 10.3.

To be certain, this is a software problem not a wiring problem, correct?

Since it is displaying the stations, traffic, METARs, I am inferring that the NGT-9000 is sending the data stream correctly. Agree?

Thank you,

Theo

Any chance that is already known and will be addressed in 10.3?  

That scenario doesn't make sense to me.  Sounds to me like either it's not wired the way you think it is or the configuration is off.  This may be a job for tech support, but if you post back your RS232 port configurations we might be able to figure it out.  

Thanks for the help!!!

In case another data point will help, photo taken 4/19/2020 13:51 PDT:

It does not send the traffic to the IFD100 - but that is a feature request for another day. :-) 

Avidyne Support is the best ever!!!

Thanks

He has an MFD that is controlling the XMD076.  So he had to change his IFD configuration to use "XMD076 AUX" rather than "XMD076".

Jeff

two flights now, no datalink error and the GPS track on the Garmin G5 stayed stable where before it would periodically blank out.

Sounds like there were a bunch of fixes related to the serial ports if you read between the lines on the release notes these three items are all serial port related.  I'm not sure if the 429 stuff falls under serial as well as it is a different physical interface and protocol plus I am not using the 429 interface so I can't comment there.

resolves datalink configuration problems

fix to dropping of ADS-B data

fixes incorrect ATC code transmission to the NGT9000R transponders

This tells me there was something wrong with the serial ports, dropping characters, funky speeds, something else?  which is why I think my G5 problem is now gone too.

-PA

dmtidler wrote: Just out of curiosity, what software version are your G5’s using?

The latest version on Garmin's website - 6.76

Thanks! I believe G5 update 6.76 is the latest for G5's on experimental/LSA aircraft. I was curious if anyone on the forum has upgraded to Garmin G5 software version 6.82 for certificated aircraft (available on the Garmin website since December 10th). 

Thanks!

This thread has had a lot of twists and turns, so I'm not sure which problem you're talking about.

Maybe this will help.  Each kind of datalink report has a "late" time and a "stale" time.  If the IFD powers up and doesn't receive a given report within the "late" time, the message "Datalink Data Not Rcvd" is issued.  If the IFD *has* received a given report but then does not receive another one within the "stale" time, then the message "Datalink Stale" is issued.

The logic and the messages remain the same in 10.2.6.1.

For not-yet-released 10.3, we've done some work on the messaging in an attempt to make it more understandable, but the underlying logic remains the same.  If the IFD is expecting a datalink message and it has not been received, we want you to know about it.  The new "late" message will say "Datalink Data Overdue" and the datalink status page will show you which products are overdue.  The "stale" message will remain the same.

Steve, I'm sure that some of the error reporting in the yet to be released version will be helpful.  But the problems I was having now appear to have been resolved and was actually two problems which I now believe were related in the IFD software.

1) Randomly receiving the "datalink error" at least once every flight (what this thread was started for)

2) (unrelated to this thread) constantly losing  and regaining the GPS ground track being sent from the IFD to my Garmin G5 AI

Although I've only had 2 short flights with a total time of about 2 hours, it is possible but doubtful that I simply didn't receive the datalink error as it is somewhat random but I believe it triggered every flight within the first 5 minutes, the output problem to the the G5 (mapMX format) which I hadn't reported yet was continuous, the ground track would appear for a few minutes than disappear for a few seconds and simply repeat throughout the whole flight, this problem was not observed at all with the new software as the ground track display stayed on through the whole flight.

As of right both problems appear to be resolved in 10.2.6.1, I am sure there were some changes in the serial I/O stuff that was causing both of the issues which are now fixed, and although lacking any real detail Avidyne's release notes do point to some changes in the external I/O stuff and I base this on the list of items that were listed as fixed in the release notes that rely on the serial I/O and the Arinc 429.  Arinc 420 is also a serial protocol, although synchronous rather than asynchronous so I suspect it is relying the same underlying code in the IFD for its processing.

Previously working for a (non aviation) software/hardware vendor I know that there are always bugs that get resolved in both minor and major software updates that are not always listed in the public release notes.  We would typically list 15+ bug fixes in a minor release but there might be 50 or 60 more that are not on the release notes that were flagged internally as fixed.

Of particular interest to me is the communication with the NGT-9000, of which I posted several photos up thread. Specifically, reporting that AIRMETs (and sometimes SIGMETs) have not been received when the NGT-9000 displays several.

10.2.6.1 did address some NGT9000 issues, but not specifically for the ADS-B data.  However, there was another fix that addressed ADS-B being dropped from a FreeFlight box.  Since that processing is in common, though, it would have a positive affect on the data being received from the NGT.  The problem shown in the pictures above could definitely be explained by data from the NGT being dropped by the IFD, making the IFD believe that it hadn't received the expected report.

That's a long winded way to say that "Yes, this problem has been addressed in 10.2.6.1".

However the GPS ground track displayed on my G5 is now rock solid, so one problem solved.

Pretty much the same result for me. NGT-9000, Aspen EFD 2000 Max, IFD540. NGT shows Airmets, IFD does not.

Avidyne was sure it was the MLB100, but reverting to 10.2.3.1 resolved the problem.

Still, I upgraded to MLB100+ because I was worried the earlier (MLB100) was not going to work with newer versions. 

Now, my Avidyne dealer says he can't get the MLB100+ to work on my IFD550.

Can someone list the RS232 settings? I know the ports, but I need to confirm the settings.

Hi, I understand that it is being work at but is there a way to disactivate this warning that keep coming on for the time being. 

Decibel wrote: Hi, I understand that it is being work at but is there a way to disactivate this warning that keep coming on for the time being.

No.  10.3 will adjust the alert to say "Overdue" instead of "Not Rcvd", which more accurately reflects the situation.  But the only way for the alert to stop appearing is for the IFD to successfully receive the datalink messages that it's expecting.

The alert is intended to indicate that the expected message hasn't been received from the ground station.  What's really happening in most of these instances, though, is that some part of the message is being dropped along the line and the IFD has to throw it all away.  If the messages were retransmitted frequently, you probably wouldn't notice it.  But, for instance, AIRMET messages are infrequently transmitted, so the IFD reaches the timeout period before it has a chance to be retransmitted.  Since the timeout period expires, you get an alert.

There's really nothing you can do on your end to help the situation.  Earlier in the thread I thought maybe the work we did for FreeFlight boxes had fixed the overall ADS-B dropping messages problem (because it affected common code).  Clearly, I was incorrect about that.  We're continuing to work on the issue within IFD software.