[akschu]

I'm still in the panel planning stage and collecting all of the information I can. One thing I have read is that some EFIS systems take longer to boot than others, and some even require a shutdown. This indicates that these EFIS units are built on an operating system since you don't commonly find embedded devices requiring much startup time and no shutdown time assuming there aren't any file systems.

In order to make the most informed decision possible I want to put together a short list of boot/shutdown times along with the OS and processor used. There are a lot of holes in my data, can some of you help me fill it in?

EFIS, startup, shudown, OS, processor
AFS advanced deck, ??, ??, ??, ??
GRT HX, 50 secs, none, linux, ?? (probably AMD or ARM)
MGL odyssey, few seconds, none, flightops (in house written OS), ARM
Dynon, few seconds, none, embedded code, ??
Blue Mountain, 15 secs, none, Linux, AMD Geode

Some of you may think that this information is irrelevant which is fine, but I want to know if an EFIS is going to take 2 minutes to boot before I buy it, and I also want to know what is under the covers since I've been doing system engineering work for many years and have a pretty good feel about how robust something is given some information about the design decisions made.

Thanks,
schu

 

[flion]

I haven't put a timer on it, but my Gen4 EFIS One takes about 15 seconds or less to boot, I think. Acquiring the GPS data and painting the map and synthetic vision onto the VSI takes longer, especially as I usually bring up the engine monitor page immediately. Like a microcontroller, though, shutdown is instantaneous; no data is lost or corrupted. In fact, I still haven't gotten around to wiring my EFIS to the backup battery so it reboots when I start the engine. Someone here had mentioned that this would be bad for the EFIS but the folk at BMA assured me that my system would be fine and they are so far proven correct. I was more concerned about not being able to monitor the engine during start but the reboot goes quickly enough that it hasn't been a problem - still, my summer project will be to rewire so that the EFIS runs off the backup battery normally and off the master only if the backup fails, which should eliminate the reboot.

 

[Radomir]

You're right.. it's completely irrelevant info. In this particular case, it's really the code that each company is putting out that's A LOT more important than the underlying OS/architecture.

Having said that.. GRT HX is built on top of Linux (Debian distro)..

 

[MrNomad]

VISTA anyone? I don't think so.

"You're right.. it's completely irrelevant info."

I vehemently disagree. Windows barely runs w/o crashing in my home pc. The last thing I want driving my EFIS and EMS is more of Gates' garbage.

My understanding is that at least one EFIS vendor has written the necessary underlying code and avoided Windows entirely. Boot up is measured in seconds, not minutes.

Crashes just don't happen.

Barry

 

[akschu]

I'm VERY familiar with linux having built my own embedded distro.

Anyway, that means that the HX probably runs an AMD Geode or ARM. Do you know which one?

Another question, does the HX need to be properly shutdown (mounted filesystems)?

schu

 

[Ironflight]

Another question, does the HX need to be properly shutdown (mounted filesystems)?

schu

Nope - just power it down from whatever it is doing. It will boot right back up to initial conditions every time. I have never actually timed the boot-up, as it is up by the time I finish fastening my harness and putting on my headset.

Paul

 

[akschu]

MrNomad,

I agree, I wouldn't buy anything that runs windows, I don't trust it to check my email, let alone tell me which side is up.

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?

schu

 

[dhall_polo]

more boot times

Garmin GNS430 - 22-25 seconds to the first "OK". More time to acquire signal.

AFS AF3500 - about 30 seconds to "I agree" with newer firmware.

BTW, Garmin's older MFDs run embedded Windows NT.

 

[Rainier Lamers]

Good topic - but it SHOULD be irrelevant

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.

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).

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.

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).

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

 

[carguy614]

Dynon boot

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

 

[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

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]

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]

I think...

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]

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.

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.

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.

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.

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]

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]

Whatr happens when you shut your EFIS down in flight?

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

 

[Rainier Lamers]

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

If you're doing any updating, please update the little thing that says "embedded code" behind our MGL "FlightOps" entry. It is not really. The operating system boots from a built in Flash disk and is loaded into RAM just like any other operating system. The only embedded code in our system is a small resident boot loader.

Rainier

 

[Rainier Lamers]

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.

I did not think you where planning to run IE and outlook on your EFIS and connect it to the net. I was talking about the core, essential drivers and libraries as a foundation to a single application - the EFIS.
Spammers have nothing to do with holes in IE. You are simply receiving an e-mail addressed to you (most likely routed via Linux servers and routers).

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.

Only partially true. Microsoft gives you the source for some of their Embedded systems (after signing the required agreements) and it is very possible to do DO178 at a high level.

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.

I think I had a good reason. I wanted a compact and stable EFIS (and I had done somewhere around 300 embedded systems before so I had some idea of how things work (Anyway, I think our EFIS's are living proof of this).

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.

Yes, a very valid observation. However, while I would like to view myself as indespensable, unfortunately the reality is that I am not. MGL has grown in the last 8 years and I'm afraid I will be replaced in less time that I will believe right now.

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.

Yes, I agree with this. Linux is a general purpose operating system (as is Windows). For this reason it has to do things in a certain way. This translates into wastage - and lots of that (much more than even hardcore Linux programmers are willing to admit). The solution is and has been to throw more expensive and power hungry hardware at it. The result is a workable but not ideal system. Nevertheless, if you want to use an existing operating system as a base - Linux is your answer. The reason is, if you are willing to get your hands dirty, you can remove or alter some of the kernel to better suit what you want to do (For an EFIS you might not need virtual memory, pre-emptive multitasking or an MMU - remove all that and things start looking better, much better).

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

I think you are perhaps being a little unfair to Microsoft (I know they are everybodies pet hate and I'm not exactly a fan myself - but from my side I value their contribution from a technical point of view - but I do not and will never agree to the way they have been doing business).
You are also correct - it does not matter what the EFIS has been written in. As long as it works and as long as it works well. That is the only criteria that matters.

Rainier
CEO MGL Avionics

 

[Rainier Lamers]

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

I am the author of "Embedded Pascal", a range of compilers for various processors that I sold as low cost shareware on the net starting in about 1998. There is a long history that led to these compilers. I have stopped selling them some time ago as I can no longer support them due to the pressures of MGL. The final port of this compiler (ARM processors) is what is used for our EFIS's - and due to the fact that I don't have to stick to conventions any longer it has deviated from the original Pascal somewhat in order to be able to produce code structures that suit this processor better (sometimes the high level needs to change in order to optimise the low level).

Embedded Pascal is written in native Delphi and it's claim to fame is the very good, highly optimised assembler output (It generates assembler text as native output). The actual code generator is perhaps 90% of the compiler, the rest is almost trivial.

Sorry for posting off-topic, just answering a question that might be of interest to others.

Rainier
CEO MGL Avionics

 

[akschu]

If you're doing any updating, please update the little thing that says "embedded code" behind our MGL "FlightOps" entry. It is not really. The operating system boots from a built in Flash disk and is loaded into RAM just like any other operating system. The only embedded code in our system is a small resident boot loader.

Rainier

Updated.....

 

[akschu]

I did not think you where planning to run IE and outlook on your EFIS and connect it to the net. I was talking about the core, essential drivers and libraries as a foundation to a single application - the EFIS.
Spammers have nothing to do with holes in IE. You are simply receiving an e-mail addressed to you (most likely routed via Linux servers and routers).

I don't want this stuff on my EFIS, my point was simply that the microsoft way of doing things (integrate everything together) is not generally a good idea on hardware that has a specific purpose since the best way to not have bugs is to not have code.

Spammers have everything to do with holes in IE. The vast majority of spam comes from home user PC's with tojans that have gotten there with security issues in IE or outlook. As a mail admin that has been battling spam for many, many years, I assure you that security issues with windows PC's are the single biggest contributor to spam.

http://www.consumeraffairs.com/news04/2007/01/zombie_computers.html

Only partially true. Microsoft gives you the source for some of their Embedded systems (after signing the required agreements) and it is very possible to do DO178 at a high level.

I didn't know this, that contradicts their usual business practices.

I think I had a good reason. I wanted a compact and stable EFIS (and I had done somewhere around 300 embedded systems before so I had some idea of how things work (Anyway, I think our EFIS's are living proof of this).

Having the experience to do this is a huge thing, what other embedded systems did you work on?

Yes, a very valid observation. However, while I would like to view myself as indespensable, unfortunately the reality is that I am not. MGL has grown in the last 8 years and I'm afraid I will be replaced in less time that I will believe right now.

Hopefully that will give you more time to attend Osh, while letting others gain experience.

I think you are perhaps being a little unfair to Microsoft (I know they are everybodies pet hate and I'm not exactly a fan myself - but from my side I value their contribution from a technical point of view - but I do not and will never agree to the way they have been doing business).

Perhaps I am unfair, but I spend a tremendous amount of time in my job dealing with spam and integration work (integrate systems based on a standard protocol or API) that frankly wouldn't be nearly as time consuming or frustrating if they could write a decent desktop os. Even backing it up is a huge pain in the neck due to locking issues. Perhaps I'm bitter, but I've seen plenty enough blatant security holes, poorly written code, and blue screens to ever have that in my airplane.

You are also correct - it does not matter what the EFIS has been written in. As long as it works and as long as it works well. That is the only criteria that matters.

Rainier
CEO MGL Avionics

Agreed, but simple is almost always better.

 

[Rainier Lamers]

I didn't know this, that contradicts their usual business practices.

They started this in a big way with Windows CE years ago. Windows Embedded (effectively what used to be Windows XP) is following or so I am told.

Having the experience to do this is a huge thing, what other embedded systems did you work on?

This is a very long list and touches a large range of applications. I suppose my first systems where audio HIFI systems with relatively minor amounts of digital stuff (but I learned my analog there), some RF stuff, some scientific equipment, radar systems (high resolution mono-pulse systems) - both RF and signal processing (early, very expensive DSP stuff) - that was also my first brush with airborne systems. After I moved from Germany to South Africa I was involved with a large air traffic control system development, then branched out to what you could loosly call "revenue collection systems", big involvement with broadcast electronics (radio and TV) - every terrestial TV signal in South Africa goes through my systems. Quite a bit of automation and systems monitoring stuff of various descriptions. Good sprinkling of small and very big projects.
Makes my head spin trying to think of all the embedded systems I did over allmost 30 years -starting with early Intel and Zilog processors, 805x, 65xx, 68xx, 68xxx, AVR, ARM, 386's, PICS, STC, etc etc etc...
Giving away my age there (48 if you have to know).
Spent my army time as part of German Nato forces (teaching electronic field repair and maintenance on radar systems).
But not all nerd. Did a few hard core expeditions as well, South pole (1984), Amazon, Sahara. But I was a little fitter then I suppose.
When I bought my first aircraft (a trike) in 1998, it was only a matter of time until I would end up making things for sport aircraft. I just had to.

Rainier
CEO MGL Avionics

(yes, now well off topic - my appologies)

 

[Garage Guy]

Open source EFIS software?

Rainier,

Any chance of making your source code and toolchain available to those of us who might want to tune, tweak, modify and maintain the software in our MGL EFIS's? I guess you might see the risk of intellectual property leakage being too great, but it would arguably be in the spirit of experimental aviation to do something like that.

--Paul

 

[vic syracuse]

The Cheltons take about 2-3 minutes to power up aligned, and you have to sit still while they are aligning, or you get a big red X on the screen and have to reboot. In flight, though, they can be reset if you maintain straight and level for about 30 seconds.

Vic

 

[Rainier Lamers]

Rainier,

Any chance of making your source code and toolchain available to those of us who might want to tune, tweak, modify and maintain the software in our MGL EFIS's? I guess you might see the risk of intellectual property leakage being too great, but it would arguably be in the spirit of experimental aviation to do something like that.

--Paul

Yes, this is likely going to happen sometime in the future.
The first criteria that needs to be met for this to become possible is that the systems need to reach a stage where it is unlikely that large changes will be done. While we are still working on large additions in all sorts of directions opening would be a disaster.
The second and most important criteria is that once the system is open it must be supportable. Currently there are around 1 million lines of source code stashed in hundreds of source files. The systems are vast and complex so it is important that this is documented in a way that makes it possible for a skilled programmer to get to grips with it in a reasonable amount of time (for this reason also, the system must not change by much anymore as the docs would otherwise be outdated quickly). A support structure needs to be in place to answer questions and to validate code contributions (to ensure that these do not inadvertantly cause trouble somewhere else).

As you can see, it is not a matter of simple putting the sources and compilers on the web for free access - that is bound to end in huge problems. After all this is a system that gets installed in aircraft. Regardless of who takes ultimate responsibility for the system and its code, it must work, must work correctly and must work reliably.

We also have some input from the lawyers -as you can imagine, not good input on this subject. One example that we have been given is - if somebody modifies code based on incorrect or inclomplete documentation (or even just badly worded documentation - or the guy simply did not understand), and there is an incident arising out of that - it does not matter if we even knew about the changes, we could be in trouble (even if the guy that does the changes signes a waiver - it may be worthless).
It's a bit of a mine field - but nevertheless, I am very keen on the open source idea and this allready applies for much of the data formats we use (you can get the docs on our website).

Rainier
CEO MGL Avionics

 

[akschu]

We also have some input from the lawyers -as you can imagine, not good input on this subject. One example that we have been given is - if somebody modifies code based on incorrect or inclomplete documentation (or even just badly worded documentation - or the guy simply did not understand), and there is an incident arising out of that - it does not matter if we even knew about the changes, we could be in trouble (even if the guy that does the changes signes a waiver - it may be worthless).

I just finished a rant about how lawyers limit your freedom as a developer and businessman and that it was more lawyers that make the waiver useless, but then I realized that it is terribly off topic. So in a desperate attempt to keep it on topic I'll just say that even though the FAA has allowed us some freedom in the experimental market, it is a real shame that absolute freedom in the experimental market is compromised by greedy lawyers.

schu

 

[RichB]

Yes, this is likely going to happen sometime in the future.
The first criteria that needs to be met for this to become possible is that the systems need to reach a stage where it is unlikely that large changes will be done. While we are still working on large additions in all sorts of directions opening would be a disaster.
The second and most important criteria is that once the system is open it must be supportable. Currently there are around 1 million lines of source code stashed in hundreds of source files. The systems are vast and complex so it is important that this is documented in a way that makes it possible for a skilled programmer to get to grips with it in a reasonable amount of time (for this reason also, the system must not change by much anymore as the docs would otherwise be outdated quickly). A support structure needs to be in place to answer questions and to validate code contributions (to ensure that these do not inadvertantly cause trouble somewhere else).

As you can see, it is not a matter of simple putting the sources and compilers on the web for free access - that is bound to end in huge problems. After all this is a system that gets installed in aircraft. Regardless of who takes ultimate responsibility for the system and its code, it must work, must work correctly and must work reliably.

We also have some input from the lawyers -as you can imagine, not good input on this subject. One example that we have been given is - if somebody modifies code based on incorrect or inclomplete documentation (or even just badly worded documentation - or the guy simply did not understand), and there is an incident arising out of that - it does not matter if we even knew about the changes, we could be in trouble (even if the guy that does the changes signes a waiver - it may be worthless).
It's a bit of a mine field - but nevertheless, I am very keen on the open source idea and this allready applies for much of the data formats we use (you can get the docs on our website).

Rainier
CEO MGL Avionics

Perhaps a plugin system would be more workable (or more lawyer friendly) than full sourcecode release? Provide access to data, and let the user create objects to display to screen... but don't let them mess with other components or write to protected data. Something like that should let folks extend the system, add their own widgets, but not break the existing and validated stuff.

 

[Rainier Lamers]

Perhaps a plugin system would be more workable (or more lawyer friendly) than full sourcecode release? Provide access to data, and let the user create objects to display to screen... but don't let them mess with other components or write to protected data. Something like that should let folks extend the system, add their own widgets, but not break the existing and validated stuff.

Funny you should mention that.
There is in fact a stub in the system to do exactly that. The idea was to load modules at startup from disk (much like a windows DLL) and give hooks to various pieces of data and the API. It was originally intended to allow running of seperate programs (picture the operating system plus the EFIS application becoming the operating system). This has never been developed to maturity but I will need to start looking at this soon as I'm going to need it for a new function in development. Who knows, perhaps this could work...

Rainier
CEO MGL Avionics

 

[Dynon]

If you want to update the list, the current Dynon EFIS and EMS products run display code on an ARM processor. They run the ADAHRS algorithm on a separate set of embedded microprocessors in order to give some segmentation to the code and systems.

As mentioned, they have no operating system and we have written every line of code. The ADAHRS is all done in assembly.

All of this gives us very short boot times, on the order of a few seconds. We have no filesystem, so shutdown is instant.

Additionally, your power supplies are designed to be on during crank even in 28V airplanes, so you can turn the EFIS and EMS on before engine start, and we can reboot in the air and have AHRS alignment within a few seconds as well.

 

[loopfuzz]

plugins

Funny you should mention that.
There is in fact a stub in the system to do exactly that. The idea was to load modules at startup from disk (much like a windows DLL) and give hooks to various pieces of data and the API. It was originally intended to allow running of seperate programs (picture the operating system plus the EFIS application becoming the operating system). This has never been developed to maturity but I will need to start looking at this soon as I'm going to need it for a new function in development. Who knows, perhaps this could work...

Rainier
CEO MGL Avionics

Rainier, that is awesome! I for one like to see devices like this for the experimental aircraft builder. We are building our airplanes, we shouldn't we be able to build our virtual panels (sort of).

Chris.

 

[Rainier Lamers]

Rainier, that is awesome! I for one like to see devices like this for the experimental aircraft builder. We are building our airplanes, we shouldn't we be able to build our virtual panels (sort of).

Chris.

Yes quite right !
This is the exact reason we made the panels so incredibly configurable (and in some peoples minds "terribly configurable" - it can cut both ways).
So, considering all our data formats are open and documented for anybody to use, the fact that we pack just about anything into these boxes (and you choose what and how to use), further to the fact that you can create your own screens from a library of hundreds of configurable components just the way you like - and lastly, you have direct access to the people that write the code (usually using the Stratomaster Yahoo list) where functions and the "wish list" is under constant discussion - well bottom line, the whole thing is very close to an open source system anyway - not exactly there but close (and using experience as a guide, this system works well for everybody).

Rainier
CEO MGL Avionics