Brantel

Brantel

Well Known Member
http://www.dynonavionics.com/docs/support_bulletin_010710.html

"Date: January 7, 2010

Installations Affected: Only airplanes that have TWO D10/D100 series EFISs (EFIS-D10A, EFIS-D100, FlightDEK-D180), an AP74, and autopilot servos, connected together via DSAB and configured to communicate are affected. SkyView is not affected by this bulletin.

Firmware Versions Affected: All versions up to and including 5.2.

Time of Compliance: Before further flight.

Problem Description: When two or more EFISs (FlightDEK-D180, EFIS-D100, and EFIS-D10A models), an AP74, and servos are connected together and configured to share information with each other via DSAB, there exists the possibility for one or both screens to reboot during flight.
Because this multiple EFIS and AP combination is typically used in IFR-capable aircraft, Dynon is recommending that immediate action is taken to eliminate the possibility of this occurring.

There is no known problem with a single EFIS connected to an AP74 and servos, or for two EFISs and servos connected without an AP74.

Methods of Compliance.
Any of the following methods of compliance will eliminate this issue:
1) Isolate one of the EFISs from the DSAB network.
a. Physically remove the DSAB connection between the two screens, ensuring that they can not communicate with each other.
b. Alternatively, you may leave the physical DSAB wires connected, but you can reconfigure the system so that the two screens do not communicate with each other via DSAB. To do this:
i. Apply power to all devices (EFISs, Autopilot components, etc.). Choose the screen that you want to control the autopilot from and power the other screen off. Configure DSAB by going to SETUP>DSAB>CONFIGURATION. Confirm that all of the powered on devices are configured by going to SETUP>DSAB>STATUS and scrolling through the devices that were found during configuration. Make sure that the screen that is powered down is no longer listed here.
ii. Power down everything that was on in the previous step (i) and power on the remaining screen by itself. Configure DSAB by going to SETUP>DSAB>CONFIGURATION. Confirm that only the single screen is configured by going to SETUP>DSAB>STATUS and ensuring that the AP74, servos, and other screen are not listed.
iii. Though the units are still physically connected, they are no longer talking via DSAB and are no longer susceptible to this problem. Note that autopilot capability from one screen is maintained.

2) Update to firmware 5.3 when released. This is Dynon?s next planned D10/D100 Series firmware release, and is not yet available."
 
Future fix?

Brian,

Will 5.3 fix this problem, I have a D180/D10A planned for my panel. One of the things I want is the ability to move information from display to display, this is not possible without the DSAB. I will just buy the D6 if DSAB is not going to be usable between EFISs.

Thanks for posting this, I am not flying but would be glad to see this information if I was going on a trip where I might need to punch through the overcast deck.

Cheers
 
The bulletin states that it will be fixed in 5.3 but does not mention when 5.3 will be released.
 
Here's an easy test you can conduct

gator said:
Does this also apply if you have a D100 and a D120 along with the AP74?
Click to expand...

No, as far as I know, the problem only applies to the AP74, D100, D180 combo which we have. It took me 8 months to convince them it was not our wiring but here's an easy way to make sure it doesn't affect your installation. You can do this on the ground and you will need to supply power to the Dynons, AP74, and servos.

Place your Dynons in a non-default screen. It does not matter which screen you select as long as it's not the screen that comes on when you power up the units. Hook a trickle charger to the airplane battery so that you don't deplete the batteries inside the Dynons or ship's power.

Come back in 6-8 hours and if the non default screen is still on both Dynons, your units did not reboot. The only unit that rebooted in my installation was the D180.

Per Dynon, I have temporarily pulled pins 4 & 5 in my D100 until 5.3 is available, and the reboots have stopped.

finishedpanelsmall.jpg
 
Barry

Any clue as to what the problem is?

We have a D100/D180/AP74/HS34 + SV52's and so far we have not seen a reboot, but I doubt we have flown more than 4 hours in a sector.

I will disable the D180 from the network, however that takes out the audio alarms from the D180, which while not critical, its not nice to do!

Any more thoughts?

Regards
David
 
hs34`

I thought the alarms worked via voice through the hs34 if you have one of
those, is the ap74 really more important that the networking of the two efis's units ? and won't the autpilot work ok till the problem is resolved.. I would think taking out the ap74 would be the best idea of this problem ? why is that not the best solution ? alarms will still be working too..

Danny..
 
David, answers to your questions.....

RV10inOz said:
Barry

Any clue as to what the problem is? We have a D100/D180/AP74/HS34 + SV52's and so far we have not seen a reboot, but I doubt we have flown more than 4 hours in a sector. I will disable the D180 from the network, however that takes out the audio alarms from the D180, which while not critical, its not nice to do!

Any more thoughts?
Regards
David
Click to expand...

Although I spent 30 years developing software before I retired, I can only speculate what's causing the reboot condition so I'd just as soon not. But once we realized we could get it to reboot in the hangar (engine not running), experimenting became easier and results were forthcoming much faster.

Time and time again, we set up the same conditions to learn the pattern. The logs provided no clues but after many overnite experiments we learned something more. If we DSABed with the AP74/servo breaker pulled, and then DSABed again with the AP74/servo breaker in, the number of reboot incidents decreased. That result made absolutely no sense to me, it was counter intuitive, but I repeated the test over the next three nites and achieved the same results. The net result was that using the two-step DSAB under 5.1 reboot incidents decreased, I could enjoy my airplane, and use the A/P.

Suffice to say the overnite test I suggested in my earlier post should raise your confidence, plus you have a different equipment combo than I do. As far as I know, it only affects AP74/D100/D180 combo. I gave up IFR flying until they resolve this issue.

5.3 is in beta and release is expected shortly. You can be absolutely certain that I will test 5.3 in the hangar overnite when I get it.

To their credit, once they duplicated the reboot in their office Dynon was very helpful, apologetic, and determined to make it right. The functionality their products offer is amazing so there is no way I'd ever go back to steam despite all of the grief & needless rewiring we endured.

Best of luck & please keep in touch.
 
Thanks Barry, yes my system is slightly different in that I have the HS34 on the network. So I guess the question is will this be different enough to not cause an issue.

Godspeed, I believe taking the D180 off the network is the most usable solution, still keeps all the IFR goodies working, and you still get the red flash on the D180, but the audio alarm is fed from network to the Audio panel, so you will lose that function only. This is of course depending on your system, some may have it set up differently.

I have experienced a loss of an A/P servo from the network a month or so ago and Dynon could not explain it. Even rebooted the D100 master in flight, and could not get it back. Not failed since. I will recheck with them and see if they think this is related. A networking bug perhaps.

Cheers!

DB:cool:
 
Spoke to the guys at Dynon and even in my system I potentially can have the problem. Regardless of the HS34.

I will do a test like Barry suggests, seems they can get it to happen on their tests after 3 hours, so I will see what happens. Not many people have reported it so far, but it could happen.

They are working on it, so as usual there will be a fix!

DB:)
 
It's a simple test.

RV10inOz said:
Spoke to the guys at Dynon and even in my system I potentially can have the problem. Regardless of the HS34.

I will do a test like Barry suggests, seems they can get it to happen on their tests after 3 hours, so I will see what happens. Not many people have reported it so far, but it could happen.

They are working on it, so as usual there will be a fix!

DB:)
Click to expand...

DB:

Debugging is typically the most difficult aspect of development so any additional information you can offer will probably be appreciated. I tried to use the internal log for clues but all it told me was that the reboots occurred randomly. Sometimes it would not reboot for 4-5 hours, other times sooner. I could not detect a pattern but other anomalies appeared after I installed 5.2 so I disconnected my D100 from the network and await their software fix.

Fortunately, you can do a lot of experimenting on the ground which conserves fuel but more importantly, does not stress an already busy pilot flying into busy places such as SOCAL.

If I were a younger man......
 
7 hours and counting, still no drop out, see how it looks in 24hrs.............

Talking to Dynon they did not think having an HS34 on the bus would matter, now I am not sure if they have introduced more items on the bus and see if they still get the reboot, they think its a comms timing issue so maybe another item stops the bug......time will tell.

I will post again tomorrow and advise Dynon Monday.

DB:cool:
 
Went 30 hours straight without a reboot at all.

Will advise Dynon also. They seem to be on top of it and its only a rare thing (two in the field), so a fix is due out very soon, after they and the field folk have tested it just in case the bug is hiding I guess.

Gotta say good work to all involved!

Cheers

DB:cool:
 
Last edited:
30 hours is encouraging!!

RV10inOz said:
Went 30 hours straight without a reboot at all.

Will advise Dynon also. They seem to be on top of it and its only a rare thing (two in the field), so a fix is due out very soon, after they and the field folk have tested it just in case the bug is hiding I guess. Gotta say good work to all involved! Cheers

DB:cool:
Click to expand...

That's great. They told me that it only happened to the AP74/D100/D180 combo. Perhaps having one more device renders a different condition. The patch may be out to more testers this week but in the interim, my D100 remains off the network. Flew today for an hour w/no issues.
 
We do know the root cause of this and have a fix in the works as has been mentioned.

Ironically, the broken bit was in our internal health monitoring, which was failing a check and rebooting the unit on purpose.
 
Why would you want to reboot the system on a failure? That doesn't make a lick of sense, unless it runs windows......

schu
 
Thanks Dynon

Thanks for posting this. I am planning an IFR panel with Dynon (D100s).

Dear Dynon it is excellent to see your continued support of the D100,D180 products. Your announcement of Skyview and the message that no further functionality would be added to D100/D180 gave me the message that support for D100/D180 would stop and that new purchases should go Skyview and that Skyview, (not the D100) is the go forward product for the future. So is it fair to conclude the D100/D180 are great products, with continued support, for the future?
 
Steve,
Features and support are totally different things!

We are making no promises that we will add features to the D10/D100, but by features we mean "moving map" or "coffee maker". Bugs are not features, and they will be fixed.

We will continue to sell, support, repair, fix bugs, etc in the D100 and all other products for a long time. The SkyView is a different system, it is not a replacement system.

As for why you would reboot a system that has certain failures, it's a pretty common method in embedded systems. It's so common that pretty much every processor ever made supports this protection method in hardware. No software is perfect, and detecting a locked up situation and restarting it all is a lot better than just hanging forever. That being said, this is the first time we know of that it has ever happened, and it was a bug in the detection not in the operational code.
 
Yes, I know what a watchdog is, once the software quits responding, the hardware reboots itself. However, I disagree that restarting is better than hanging forever. It masked the problem for a long time, whereas if it hung then the problem would have been found faster, and the pilot would certainly know there is a problem when things quit updating.

If I was flying and my EFIS locked up, I wouldn't trust it anymore anyway, and would power it off and fly VFR or use backups. If I didn't have backups, then I would restart it manually, but the point is that the pilot should decide.

If I where writing this, this is what I would do:

I would power the machine off and leave it off, and if I couldn't do that then I would find a way to detect if the machine was restarted by the watchdog then display a warning on next boot that said that there was a software failure and ask the pilot of they wanted to power off the device or continue to use it anyway.

While rebooting may be common in other embedded systems, this isn't the way avionics (should) work. You should get a warning telling you something is wrong or it should just power off completely.

schu
 
Test results as follows.....

Earlier this week, I received a beta copy of 5.3. I installed it and have now completed two multi-hour tests on the ground.

I'm pleased to report that my D180, D100, AP74 combo did not reboot during my tests!!

Using the same on-the-ground procedure I advocated in my earlier post, I placed the two Dynons in non-default screens and let them run with a trickle charger to keep ship's power alive. If they rebooted, they would have the default screen on them when I returned to the hangar.

The first test lasted 7 hours. The second test lasted 6 hours. No reboots. Tomorrow, weather permitting, I will fly the plane to look for any other anomalies but so far, so good.

I have no firm date when the final version will be distributed but this looks good so far.

Halleluyah!
 
While rebooting may be common in other embedded systems, this isn't the way avionics (should) work.
Click to expand...

I had a Garmin 250 reboot on me while bearing down on delta airspace, already having established contact. I was glad the sucker came back up, as it was the rental's only com. Well, and nav. but I was VFR. Don't know what caused it, maybe static, maybe gamma rays.

Apparently Garmin thinks avionics should reboot as well. ;)
 
You must log in or register to reply here.