EFIS boot times, shutdowns, and operating systems.

[Rainier Lamers]

The systems you are refering to do not really fall into the category of systems under discussion.
Your system does not need or have an operating system - it is a pure embedded system and it is quite simple in structure. Once you go beyond this level you need to worry about a file system (and all the bad stuff that brings with it) and you will generally opt for an operating system as a base since, well, it gets kinda complicated...
Few want to mess around with virtual memory systems, MMU's, dynamic allocations, protected memory, low level multitasking stuff. Many will rightfully view any effort spent on stuff like that as a colossal waste of time - simply use something that has been done and is known to work (such as Linux) - then you can concentrate all your efforts on the application (the fun part).
Dynon's new system is a different animal in a different league and it seems they have choosen Linux to to the dirty work. It is a good and very sensible choice. I don't know what hardware they will be running but boot times around 15 seconds should be entirely possible.

Rainier
CEO MGL Avionics

Originally Posted by carguy614

I'm not a computer guy, so my head spins rapidly when I read the above posts. However, My Dynon D100/120 pair boots up in about 10 seconds, requires no shutdown procedure, and peforms flawlessly. Master on, go fly. It does take about 3 min. for warmup of the Efis before it reads stable Baro pressure. This is normal.
Installing updates has been no problem, easy to install, and seems to work OK with the persnickety Avmap EKP-IV glitchy data stream. Great support from Dynon as well.
Hows that for a totally non tech review!!
Hope this helps you decide

Chris

[Jamie]

Originally Posted by akschu

I'm cool with a linux or embedded based system as long as their aren't any mounted filesystems that can become corrupt. Which leads me to my next question, if the dynon is embedded code, why does it require a shutdown?

I really had to scratch my head to try to figure out what you're talking about here. Are you talking about how when you shut off the master switch, the Dynon stays on and starts timing down? That's a feature in case you lose the power buss that the Dynon is powered off of. The timer is to give you an opportunity to tell the EFIS you want to remain on internal battery power.

If you have a Dynon EFIS with no internal battery, it will shut down immediately.

BTW: The EFIS boot time is about 2-3 seconds max. Very fast.

[jsocolof]

I don't know about the other units as I have the Chelton. It boots up in 2:00min or less depending on temperature. Actuall it has a boot up countdown. As I understand it the unit has both a heater and cooling fans that operate to ensure the unit is within it operating temperature range. The AHARS also has an internal heater. This has nothing to do with code or the OS but the hardware and alignment.

[nucleus]

A more relevant question might be:

Can you confuse the EFIS by maneuvering your plane?

The second question would be; how long does it take to recover?

Hans

[akschu]

Originally Posted by Rainier Lamers

Regardless of the bad press that many of Microsoft's systems get, often it is overlooked that the issues do not stem from actualy Microsoft code but rather from a huge amount of third party code related to the various applications, drivers and so forth. It is an architectural issue that Linux is largely avoiding, simply because it has a different foundation.

I disagree, it is totally possible to get their stuff to break even without 3rd party software. Don't forget that the vast majority of spam you get in your inbox is because of spammers taking advantage of holes in IE (which is part of the OS, and you can't remove it) or outlook.

Originally Posted by Rainier Lamers

But for something like an EFIS it should not matter either way as you will be running a core, couple of well defined libraries and drivers and little else. Windows NT, 2000 and XP are pretty good if run this way (and XP is available in a very good "embedded" version as well).

I've not used embedded windows, but if it isn't stripped all the way down to a kernel, and they only give you binaries, then you are still subject to what they force on you. Also, many developers use windows not because it's the best tool for the job, but because that is all they know. I wouldn't be surprised to find embedded windows devices running visual basic code.

Originally Posted by Rainier Lamers

Long boot times can be avoided in many cases but yes, around 15-30 seconds is perhaps the lower limit for a slimmed down system.

As many know, we wrote or own operating system from scratch - after having had a real good look at both Windows CE and Linux. The fact that we did not go for either had nothing to do with whether they where good or bad - we thought we could do better with a "from scratch" development that was aimed squarely at what we wanted to do: "make an EFIS".
This starts with file system issues and goes right down to how tasks are scheduled, how memory is handled as a resource and countless things like that.

This had a big advantage for us: We can use low power, cool running processors and modest amounts of memory as little CPU resouces are wasted - but it also has a big disadvantage - we have to do EVERYTHING ourselves, and that includes device drivers, USB host systems and such.

I agree with this, doing everything yourself is a huge disadvantage as you are re-inventing the wheel. Sometimes that is a requirement for a project, but far and wide it's not a good idea unless you have a very good reason for it.

Originally Posted by Rainier Lamers

Another advantage which is quite helpful is that every single byte of code is known to us - and I am really talking at the byte level as even the compiler needed is written in-house from scratch (we "invented" our own programming language for this, based loosly on Pascal). This makes it possible to very quickly trace bugs or profile the code and that leads to short development times (no need to waste days trying to guess why a particular piece of code done by some unknown entity does not work the way it is supposed to).

This is very impressive, but also dangerous unless VERY well documented. Should something happen to you would someone else be able to take over where you left off? This is the first I've heard of someone writing their own compiler, that must have been a tremendous amount of work.

Originally Posted by Rainier Lamers

Would I do this again ?

Probably not. I'll most likely use Linux should I ever need to start over. Of course, this is now unlikely as FlightOps has matured into a very capable and highly efficient system that does exactly what is needed and no more.

Rainier
CEO MGL Avionics

Linux is nice because you don't have to write all of your own filesystem/usb/memory management/etc code and it's been very well tested on lots of hardware. I prefer it to windows because you have the code and am able to fix problems you find in the kernel or libraries. It has most of the advantages of writing it yourself because you have access to the source, but also the advantages of using established code.

I don't care if an efis is linux or qnx or in house written or whatever else, but I won't give microsoft another dime of my money, and I don't trust them to get it right, and because of the binary nature of their code there isn't anyway for an efis vendor to audit their code.

schu

[Ironflight]

I think it might be useful to interject an observation here - there may be TWO different things people are talking about, wrapped into one. The first is what I would legitimately call "boot time" - the time it takes for the computer to get up and running. The second is "alignment time": - the time it takes for the gyros and accelerometers and Air Data System to be ready for flight. Generally, the more sophisticated systems take much longer to align than boot - on the order of a minute or two. Even the Dynons, which boot VERY fast, require time for the sensors to warm up and give you good information - altitude in particular can take a couple Dov minutes to settle down. That's why I personally like to power up the EFIS on an isolated Aux battery before engine start, so I don't have to sit there burning gas and blowing dust at people with th engine running, waiting for the airplane to be ready to move.

Paul

[erich weaver]

Good point Paul. Certainly most of the time for my GRT EFIS to get going is in the "aligning" phase.

I have no alternate power source for mine, so dont turn it on until after engine start. However, I have to admit that I routinely taxi to the runup area while the EFIS does its alignment. I do a quick check of the heading value before takeoff and of course set the altimeter based on field altitude/ATIS and have never noticed any problem. EFIS, garmin 296, and TruTrak always seem to be within 1 degree. Dumb luck? Do I need to change my habit?

hope Im not hijacking thread too far...

erich

[Garage Guy]

Originally Posted by akschu

This is the first I've heard of someone writing their own compiler, that must have been a tremendous amount of work.

Where I teach, our computer science undergraduates have to take a compilers course where they implement a compiler for a nontrivial object-oriented language in 10 weeks. Theory dating back a few decades makes it a pretty easily solved problem now, and lots of good stable lexer and compiler generators exist (though of course I don't know what Ranier's development process was in any detail).

--Paul

[N941WR]

That is a question you should ask.

Hold the power off button on the Dynon D100 in flight and it simply goes dark.

(Schu - Are you thinking about the 30 second count down message you get when external power is lost? This is there to give the pilot the option of pressing a button to run the Dynon of the internal battery, if installed. If the battery backup is not installed, it simply shuts down.)

When you power it up, everything is shades of gray until the gyros align (I'm guessing the delay is for the gyros to come back up to speed, but I don't really know), and then the color returns as if nothing has happened.

Boot up time to the gray screen is almost instantaneous, seconds to the full color screen. I've never timed it but it isn't long enough to be a concern.

[akschu]

Yes, thanks for updating me about the dynon, I've updated my info at the top of the thread. Now I'm just missing the AFS info.

schu