What's new
Van's Air Force

Don't miss anything! Register now for full access to the definitive RV support community.

EFIS to HUD Project Update

Brantel

Well Known Member
So a few of us geeks have been quietly working on a project that takes input from an EFIS (currently serial streams) and processes that data within a Raspberry Pi and generates an image that can be used on a HUD or other display that supports HDMI or CVBS (Composite) video inputs. (Think back seat display for tandem aircraft)

The project is being built with the ability to add different input modules and to make it relatively easy to add customized displays to the available options.

Currently the serial input modules that have been developed include:

MGL
Skyview
Legacy Dynon
G3X

Capabilities for each of these input modules vary due to the fact that the different manufacturer's serial streams also vary greatly in the variables being streamed.

As would be expected, I have been working on the G3X input module and have developed the following custom display based on the data that is provided in the G3X serial stream. Several additional variables have been created by developing algorithms that use provided data to calculate those that are not present in the data stream.

Here is a static image of the custom screen as it exist today:

AOSE1SQl.png


A video using data captured from a real flight here at about 3X realtime:
https://www.youtube.com/watch?v=gzcrCiOq3uY&t=33s
The flight included some steep turns, wing overs, rolls in both directions and general boring holes in the sky.

Yes, this has been a distraction to my RV-10 build effort. I need to quit working on this and get back to work on that project! :p

Mostly this has been a fun learning opportunity for me. I have never used Python or this type of graphical programming before.

Thanks to Cecil "TRON" and his son Chris for getting this project started and all the foundational code work that has been done! Thanks to several others for the help along the way especially jacoby for his help!

I am excited to see where this project might go in the near future.
 
Nice!

BTW, The temperature units need to be corrected/switched:

i-gTrjWm5-S.jpg

Funny how one can stare at something forever and not see the simple stuff.
That display was tweaked today and apparently I fat fingered the units.
Thanks for the catch!
 
Really cool. I have been playing with a Hudly for a while in my RV and looking for something to drive displays that are aircraft oriented. Just thinking out loud on how i can take advantage of this in my RV.

Is there a plan or potential to have the HUD that is not feed from an EFIS? I am thinking of using the guts of an EFIS and all the inputs that go into the EFIS but not having the display of an EFIS. This would allow a HUD installation without a big panel change. Or think of it this way, the EFIS display is redundant when you have the HUD display. If you like redundancy, as I see most panels now have multi EFISs, this could be an independent set of flight instruments driven from second source. Maybe very practical on tandem RVs that have limited panel space.
 
Really cool. I have been playing with a Hudly for a while in my RV and looking for something to drive displays that are aircraft oriented. Just thinking out loud on how i can take advantage of this in my RV.

Is there a plan or potential to have the HUD that is not feed from an EFIS? I am thinking of using the guts of an EFIS and all the inputs that go into the EFIS but not having the display of an EFIS. This would allow a HUD installation without a big panel change. Or think of it this way, the EFIS display is redundant when you have the HUD display. If you like redundancy, as I see most panels now have multi EFISs, this could be an independent set of flight instruments driven from second source. Maybe very practical on tandem RVs that have limited panel space.

This is very doable and there is already one example where another project is driving a HUD from the Stratux project and hardware. While this project I am working on is currently geared toward using an existing EFIS to drive the display, it could be easily adapted to using similar hardware that the Stratux is using to provide much of the information that an EFIS does. There may even be some off the shelf stand alone ADAHRS units out there that could be interfaced to it to provide exactly what you describe.

A few years ago I was able to build an AOA system out of an Arduino and some off the shelf pressure sensors that worked very well for air data. Today there are AHRS boards available that will work with these small computers. Add a GPS board and you are a long way toward what you are asking.

I don't see this as a replacement for EFIS units but more as an enabler for a HUD and or back seat remote display for tandem aircraft. There may be some additional use cases one might dream up. To your point, given the right setup, it could be a backup to the primary EFIS units.
 
Last edited:
Really cool. I have been playing with a Hudly for a while in my RV and looking for something to drive displays that are aircraft oriented. Just thinking out loud on how i can take advantage of this in my RV.

Is there a plan or potential to have the HUD that is not feed from an EFIS? I am thinking of using the guts of an EFIS and all the inputs that go into the EFIS but not having the display of an EFIS. This would allow a HUD installation without a big panel change. Or think of it this way, the EFIS display is redundant when you have the HUD display. If you like redundancy, as I see most panels now have multi EFISs, this could be an independent set of flight instruments driven from second source. Maybe very practical on tandem RVs that have limited panel space.

I just bought the Stratux AHRS unit to integrate with the HUD. With that plus a GPS source, a good portion of the functionality can be had without an EFIS. Without OAT there won't be a TAS, no pitot so no AS, and altimeter would be GPS, which isn't really useful. GS would be GPS as well.

There is also no pressure sensor so that goes away along with AGL. AOA will not be available either.

AI, track, bearing, wind, etc should all be available.

The project has a long way to go before it's really flight ready, especially with fault handling.

Depending on how much CPU is available, it may be possible for it to run both Stratux and HUD on the same Raspberry pi so you'd get the info on the hud and your ipad along with ADS-B alerts on the hud.

And to be clear, Brian has done 99% of the work here. I just answer emails!
 
It seems to me that data acquisition is now a solved problem. And with a Raspberry Pi you can add an OAT sensor easily - there's a hat for that. And there's a hat for pressure sensors so you could obtain pitot air speed.

As far as I can tell the unsolved problem is a HUD display focused at infinity that does not requires a massive disruption of the instrument panel/glare shield, and which is visible at all Sun angles.

Hudly is a step in the right direction but it's only focused a few feet from the prop and I think I read somewhere that it's not always easily seen at certain Sun angles..
 
Look Ma - No Pi?

I got excited when the possibility of using glasses for "HUD" was published - quickly that morphed into the current technology.
What interests me even more is the advancement to not requiring an android (or iPhone) interface between the data source and the HUD. A direct serial connection would be simplest and (my opinion) preferred.

Brian - you mentioned Dynon systems were being worked on. Does that include the Advance Flight Systems EFIS as well, or are they still in the "next iteration" phase?
 
It seems to me that data acquisition is now a solved problem. And with a Raspberry Pi you can add an OAT sensor easily - there's a hat for that. And there's a hat for pressure sensors so you could obtain pitot air speed.

As far as I can tell the unsolved problem is a HUD display focused at infinity that does not requires a massive disruption of the instrument panel/glare shield, and which is visible at all Sun angles.

Hudly is a step in the right direction but it's only focused a few feet from the prop and I think I read somewhere that it's not always easily seen at certain Sun angles..

Yes, sensors can be added if it morphs into a permanent install. Realistically though, I would think that most people who would embrace a HUD would already have an EFIS onboard and would rather hook it to power + a serial stream vs power + pitot static + OAT. I could be wrong.

The focus and visibility issue is real. I don't know all the details but it has been discussed. There doesn't seem to be a practical solution right now. You can choose between the ~$1k hudly or go off into the certified world and spend a magnitude more.
 
I got excited when the possibility of using glasses for "HUD" was published - quickly that morphed into the current technology.
What interests me even more is the advancement to not requiring an android (or iPhone) interface between the data source and the HUD. A direct serial connection would be simplest and (my opinion) preferred.

Brian - you mentioned Dynon systems were being worked on. Does that include the Advance Flight Systems EFIS as well, or are they still in the "next iteration" phase?

Advanced Flight can be added if they have an appropriate data stream output. I did a quick search and could not find any info on their's if it exist.
 
Last edited:
Yes, sensors can be added if it morphs into a permanent install. Realistically though, I would think that most people who would embrace a HUD would already have an EFIS onboard and would rather hook it to power + a serial stream vs power + pitot static + OAT. I could be wrong.

The focus and visibility issue is real. I don't know all the details but it has been discussed. There doesn't seem to be a practical solution right now. You can choose between the ~$1k hudly or go off into the certified world and spend a magnitude more.

I wasn't advocating for the Raspberry Pi path - I was simply pointing out that there are ways to add capability to a Pi-based solution.

I agree that if EFIS outputs can be easily accessed and used, that would be the way to go.
 
I got excited when the possibility of using glasses for "HUD" was published - quickly that morphed into the current technology.
What interests me even more is the advancement to not requiring an android (or iPhone) interface between the data source and the HUD. A direct serial connection would be simplest and (my opinion) preferred.

Brian - you mentioned Dynon systems were being worked on. Does that include the Advance Flight Systems EFIS as well, or are they still in the "next iteration" phase?

I, personally, see this as something that will take multiple forms of input and normalize that into a hud output. It could be the onboard serial or a ahrs + gps daughter board or the stratu[sx], et al. The protocols are all simple to parse and map to the HUD.

We have d100, g3x, mgl, and skyview data streams and parsers. If you, or anyone else, wants to capture an AFS data stream and send it to me or Brian, we can attempt to get it parsed and supported. Documentation on the format would be appreciated as well.
 
As far as I can tell the unsolved problem is a HUD display focused at infinity that does not requires a massive disruption of the instrument panel/glare shield, and which is visible at all Sun angles.

Hudly is a step in the right direction but it's only focused a few feet from the prop and I think I read somewhere that it's not always easily seen at certain Sun angles..

I got excited when the possibility of using glasses for "HUD" was published - quickly that morphed into the current technology.

The focus and visibility issue is real. I don't know all the details but it has been discussed. There doesn't seem to be a practical solution right now. You can choose between the ~$1k hudly or go off into the certified world and spend a magnitude more.

Most that use the auto based HUD displays seem to comment that the focus to infinity problem is true but ends up not being much of an issue. Visibility in some cases can be compromised as well but reports are that this is also mostly a non issue. Heck even the best EFIS screens and definitely Ipad's have visibility issues in some cases so there are trade-offs all around.

I am no optics expert but I do ponder on why it is so hard to make an inexpensive HUD display focus to infinity? Why is that so? One thing I have learned is that VAF usually has a trained expert on just about everything there is. Someone on here knows....

As for glasses, that is still a possibility if we find some with the right capability. Glasses based attitude displays can be disorienting unless we add some sort of head tracking AHRS to the glasses and this gets complicated fast! All the other info could be added though without too much trouble.

I have a Kivic display on the way to test with. I like the Kivic because it seems to have the best all in one footprint and might work better for a tipup canopy. Will report my experiences with it.
 
Last edited:
I am no optics expert but I do ponder on why it is so hard to make an inexpensive HUD display focus to infinity? Why is that so? One thing I have learned is that VAF usually has a trained expert on just about everything there is. Someone on here knows....

I did a bit of research when this was discussed on the email group and it seems most of the issues come from the light source. Apparently it has to be lined up parallel in all directions (like a laser except bigger). So you need one big array of light so there is no disbursement of the rays when they are reflected back from the glass.

I have no clue how the true infinite focus displays manage this or how to get close enough with COTS hardware. Maybe an array of fiber and LEDs?
 
Interesting, I hadn't heard of the Kivic. Still, this doesn't look like it'll fit "cleanly" on the glareshield like a Hudly would:

51-lXnqNmgL._SL1417_.jpg
 
Problem with the Hudly Classic is that it has been discontinued. The Hudly Wireless has issues like tinted glass and it is flat not curved which causes issues.

Tipups also have different challenges vs sliders or the RV10.
 
In general I would think having the image focused at infinity is important for final approaches. You want to flick back and forth between the HUD ("Am I too slow?") and the runway ("are there animals on the runway?" and other important facts like is my spot moving down the windshield, staying in the same spot, or moving up?).

Maybe less of an issue for Cruise.
 
Advance Flight Systems Data Stream

I can?t find info of their data stream in their manuals. Hopefully Rob Hickman or Ken will see this thread and provide some insight.

Since the AFS EFIS supports five serial ports, there are possibilities to have direct connections. With a PFD and MFD you?ll have ten ports to choose from. Most of their Port configurations permit selection of devices, which I assume configures the data stream to properly interface with the device.
 
I got excited when the possibility of using glasses for "HUD" was published - quickly that morphed into the current technology.
What interests me even more is the advancement to not requiring an android (or iPhone) interface between the data source and the HUD. A direct serial connection would be simplest and (my opinion) preferred.

Brian - you mentioned Dynon systems were being worked on. Does that include the Advance Flight Systems EFIS as well, or are they still in the "next iteration" phase?

I can't answer your question, but I wouldn't think it would be that difficult. AFS already provides the required data via WiFi for display for a variety of tablet applications.

My interest is high on this, but unfortunately my available time is pretty committed for awhile.
 
I can?t find info of their data stream in their manuals. Hopefully Rob Hickman or Ken will see this thread and provide some insight.

Since the AFS EFIS supports five serial ports, there are possibilities to have direct connections. With a PFD and MFD you?ll have ten ports to choose from. Most of their Port configurations permit selection of devices, which I assume configures the data stream to properly interface with the device.

I looked through the AFS docs yesterday and it appears that the data format is configurable. I don't know which format is usable for the project. It looks like the aviation data format would be the most likely but I don't think that's something I could tackle anytime soon.

The documentation is in the installation guide under serial port configuration.
 
I looked through the AFS docs yesterday and it appears that the data format is configurable. I don't know which format is usable for the project. It looks like the aviation data format would be the most likely but I don't think that's something I could tackle anytime soon.

The documentation is in the installation guide under serial port configuration.

Stretching my memory but I seem to recall the old AVIATION data format was navigation type data only. I don't remember that having any ADAHRS type data included in it. That protocol definition was around on the web in the past.

I took a quick look at the available options for AFS and I don't see one that obviously meets our needs with this project. Would need more info on what some of the others include.
 
I can't answer your question, but I wouldn't think it would be that difficult. AFS already provides the required data via WiFi for display for a variety of tablet applications.

My interest is high on this, but unfortunately my available time is pretty committed for awhile.

If the AFS supplies WiFi data via the GDL 90 data format, I would think that would work (along with the stratu[sx] and any other compatibles). I don't know what data it will report so some info will likely not be available.
 
Stretching my memory but I seem to recall the old AVIATION data format was navigation type data only. I don't remember that having any ADAHRS type data included in it. That protocol definition was around on the web in the past.

I took a quick look at the available options for AFS and I don't see one that obviously meets our needs with this project. Would need more info on what some of the others include.

I looked it up briefly and it appears to be a link-level protocol and not really a data level one. If I read the docs correctly, it's a fixed length data packet with variable data in it with three different encodings and one encoding has a couple of variants. :confused:
 
If the AFS supplies WiFi data via the GDL 90 data format, I would think that would work (along with the stratu[sx] and any other compatibles). I don't know what data it will report so some info will likely not be available.

They supply air data, traffic, and weather via WiFi. The air data feed allows apps like Foreflight, Wingx, etc to mimic a basic efis screen. I think it may be gdl 90 format, but I'm not certain. It would easy enough to validate with Rob, Ken, or Shawn.

There have been quite a few updates to the serial interfaces with V15. I would have to check the manual to see what options are available on a dedicated port.
 
Kivic HUD confirmed to work with the RPi's composite video output.

This thing is fairly compact and looks like it might work well with the tipup canopy. Won't know for sure until I can actually place it on the glare shield and sit behind it.
 
AFS ADAHRS data out

I talked to a friend today, who has an ear with AFS and he told me they are working to give the ADAHRS data out so it can be used with projects like the HUD.

Not sure when it will be available, but they are working on it. So stand by for news hopefully in the near future. Don't ask what the data string will look like as he didn't know either. He did say he thinks they are working with Dynon and since the AF5000 series uses the Dynon ADAHRS it might be the same data string as the SkyView.

Brian
 
Several years ago, I worked with Garmin and Dynon to align their serial ADAHRS and EIS data streams, with a protocol that I called FIX. They both adopted it and it was released in the original G3X and SkyView systems.

Since then, they have been diverging, but it sure would be nice if someone would encourage them (and others) to cooperate as much as possible.

Turns out, that I ended up retiring from commercial avionics development, so I have no skin in the game anymore, but I developed a bunch of stuff that used these serial streams.

V
 
Several years ago, I worked with Garmin and Dynon to align their serial ADAHRS and EIS data streams, with a protocol that I called FIX. They both adopted it and it was released in the original G3X and SkyView systems.

Since then, they have been diverging, but it sure would be nice if someone would encourage them (and others) to cooperate as much as possible.

Turns out, that I ended up retiring from commercial avionics development, so I have no skin in the game anymore, but I developed a bunch of stuff that used these serial streams.

V

Interesting. I just looked at the streams for both the g3x and the skyview and they have very similar data, albeit in a slightly different format. preamble/sync, type, version, data, checksum, crlf

Skyview extends the data with DA, wind direction, wind speed.

G3x:
Code:
=1115032801+112-00071230050+00984+026-02+1099-001+01274A8

Skyview:
Code:
!1116533112-013+00750451000+02866+018-02+1020-060+261074254+048531481087

D100:
Code:
16014827+042-00331080347+0230-026-03+1020FE32F901BB
 
Latest update to the F18 inspired HUD screen include the roll angle and slip/skid indicator at the bottom as well as a flight path marker.

The code for all the "widgets" is coming together. Creating customized screens is getting easier and easier.

T7hkSb3l.png
 
Don't Change Anything

Latest update to the F18 inspired HUD screen include the roll angle and slip/skid indicator at the bottom as well as a flight path marker.

The code for all the "widgets" is coming together. Creating customized screens is getting easier and easier.

T7hkSb3l.png

Great Work
 
I have about 1800 hours looking through a similar looking HUD. It was really good for some things, but those are probably not applicable to a light aircraft. For instrument flying, having airspeed and altitude scales, and trend arrows, is much better for use as a flying instrument.

Basically the same as on a standard PFD display. Boxes with digits don't show trends, or deviations, unless you stare at them. Trend arrows and motion of the scales allow you to see the same thing with peripheral vision.

Much mo betta.
 
No experience at all (yet) flying behind glass, but what svyolo says rings true to me. About 40 years ago, I bought one of the first full-auto SLR cameras, a Canon A-1. Instead of match needles for setting F-stop and exposure, it had a 'digital' display in the viewfinder. A minor nightmare to actually use; you had to stop and read the settings instead of just having a peripheral awareness that the needles matched, as you can do with a match-needle camera. I do worry about transitioning to 'glass' for that reason.

Charlie
 
I have about 1800 hours looking through a similar looking HUD. It was really good for some things, but those are probably not applicable to a light aircraft. For instrument flying, having airspeed and altitude scales, and trend arrows, is much better for use as a flying instrument.

Basically the same as on a standard PFD display. Boxes with digits don't show trends, or deviations, unless you stare at them. Trend arrows and motion of the scales allow you to see the same thing with peripheral vision.

Much mo betta.

Funny you mention this because the F18 style HUD excludes those items and focuses more on digit displays and not tapes and trend indicators. Exception on the HDG tape and flight path indicator. One member of our team is passionate around keeping with the spirit of that simplicity on this particular screen.

Other widgets I have developed for other screen layouts do show trends like the turn rate indicator, VS trend, etc. The flight path indicator is also a very handy tool. I also have versions of the ASI and ALT display that work as tapes as well.

Bottom line is the flexibility is there to customize the display with tons of options to suit the pilot. These displays can be toggled for different flight modes in flight as well if the pilot wants one style for cruise and another for approaches and another for ???? You get the idea.
 
No experience at all (yet) flying behind glass, but what svyolo says rings true to me. About 40 years ago, I bought one of the first full-auto SLR cameras, a Canon A-1. Instead of match needles for setting F-stop and exposure, it had a 'digital' display in the viewfinder. A minor nightmare to actually use; you had to stop and read the settings instead of just having a peripheral awareness that the needles matched, as you can do with a match-needle camera. I do worry about transitioning to 'glass' for that reason.

Charlie

Hi Charlie,

I wondered about that myself but I found it to be a very simple transition.
But you could always rent a glass plane and go up with a flight instructor to see how well you handle it.
 
Transitioning to glass is a no brainer. Going back to steam, will have you screaming for your mama.
 
Latest update video.

Added a caged mode for the Flight path indicator. It can be toggled on and off and when it is caged, a ghost FPI appears

https://youtu.be/x0rPdBmn_wY

This is with recorded flight data running at 5x normal flight speed being streamed to the RPi.
 
The caged and uncaged FPM or VV mode is something I have missed since the last time I flew with a pointy nose in 1996. The caged mode is the best mode for hand flying. All of us used it. We would uncage for landing, or some other purpose. You will never miss knowing where the airplane is pointed.

For autopilot use, obviously the flight director and normal pitch mode are better.

I am a few weeks from buying a glass cockpit setup. Whoever I buy it from, I will request this feature. I have missed it for a long time. The VV is wonderful when it is in the center, but the worse the crosswind is, the more useless it becomes. Except for landing.

Funny you posted this. I just joined AFS's forum yesterday, and posted the question about caged and uncaged VV/FPM.
 
Last edited:
DIY. HUD FORUM at Oshkosh

The OnSpeed Team will have a DIY Open source HUD forum at Oshkosh this month where we will discuss the status of our team HUD project. The OnSpeed team will also have a HUD demo available in the Inovation Building at Oshkosh (EAA at our booth IC29). EAA provided us a booth to display and discuss our Aural AOA project progress over the last year (we were the winners of the 2018 EAA Founders Inovation Prize). We have integrated the visual AOA presentation in our HUD project with the aural AOA tone in our OnSpeed development project.

Due to the super work of Brian and Chris we've made good progress with our software development over the last several months and will be installing a HUD in a RV-6 (Skyview) and Experimental Super Cub (G3x) this month for flight test.
As mentioned below this SW can also be used to run a second aircraft cockpit display using a basic Video screen with a HDMI input and the same $40 Raspberry PI computer used for the HUD display.
Our software currently supports Dynon D10/D100/Skyview, MGL iEFIS, and Garmin G3x serial data output. After Oshkosh we will make the current SW available for all to use (download), but folks ready to join the project and can program in the Python programming language are welcome to join in to help expand the HUD project SW options and functionality.

TRON


DIY HUD or 2nd screen for aircraft
Thu, Jul 25, 2019 - Thu, Jul 25, 2019
8:30 AM - 9:45 AM
Location: Forum Stage 5
Presenter: OnSpeed Team

Learn about an open source HUD project that lets a pilot build a Heads Up Display (HUD) or a 2nd screen for your existing EFIS.* Currently supports Dynon D10/D100/Skyview, MGL iEFIS, Garmin G3x, and more supported soon.* System is easy to configure and expand.* Create your own custom screens or use one already built by the community.
 
The OnSpeed Team will have a DIY Open source HUD forum at Oshkosh this month where we will discuss the status of our team HUD project. The OnSpeed team will also have a HUD demo available in the Inovation Building at Oshkosh (EAA at our booth IC29). EAA provided us a booth to display and discuss our Aural AOA project progress over the last year (we were the winners of the 2018 EAA Founders Inovation Prize). We have integrated the visual AOA presentation in our HUD project with the aural AOA tone in our OnSpeed development project.

Due to the super work of Brian and Chris we've made good progress with our software development over the last several months and will be installing a HUD in a RV-6 (Skyview) and Experimental Super Cub (G3x) this month for flight test.
As mentioned below this SW can also be used to run a second aircraft cockpit display using a basic Video screen with a HDMI input and the same $40 Raspberry PI computer used for the HUD display.
Our software currently supports Dynon D10/D100/Skyview, MGL iEFIS, and Garmin G3x serial data output. After Oshkosh we will make the current SW available for all to use (download), but folks ready to join the project and can program in the Python programming language are welcome to join in to help expand the HUD project SW options and functionality.

TRON


DIY HUD or 2nd screen for aircraft
Thu, Jul 25, 2019 - Thu, Jul 25, 2019
8:30 AM - 9:45 AM
Location: Forum Stage 5
Presenter: OnSpeed Team

Learn about an open source HUD project that lets a pilot build a Heads Up Display (HUD) or a 2nd screen for your existing EFIS.* Currently supports Dynon D10/D100/Skyview, MGL iEFIS, Garmin G3x, and more supported soon.* System is easy to configure and expand.* Create your own custom screens or use one already built by the community.


I checked out your website. Lots of good info, including technical info. I read a bit of it.

I flew in the Corps and spent a bit of time playing with the guys at Tyndall and Eglin close the where you guys are now. I grew up with AOA and HUD's. I flew commercial for the last 25 years, and missed having AOA and a HUD, although I used a 737 HUD in a sim and didn't like it. The focal point was bad for normal use, only good for CAT III.

Because I missed having AOA, I taught myself over the years to use the VV as an "inertial" AOA. One of your tech articles alluded to an experiment using inertial data only as AOA. After using it a lot, it works great. It doesn't matter whether it is accurate to within a small percentage of a degree. The displays can't show it unless it was a digital readout. +/- a half a degree is more than good enough for actual use.

Being able to cage and uncage the VV to center, like a video posted a few posts above, makes inertial AOA very easy. It is harder with a big crosswind without the caged function.

If you know your onspeed and cruise AOA, pitot static problems become a non-event. I understand most of the GA EFIS's use pitot static info for VV functionality, so maybe it would not be as useful for us.

I will go back and read some more PDF's on the tech site. Lots of good reading.
 
Have there been any updates on the release of the program since last year? It sounds like from the Oshkosh briefing the FlyONSPEED Team was getting pretty close to releasing some software after the show.

Hudway is coming out with a new HUD unit this July called the Hudway Drive which incorporates video input feeds similar to the Hudley and Kivic units.

https://store.hudway.co/drive

I'd be interested in trying the Hudway with the F-18 style HUD software for integration with the Dynon Skyview HDX system once I get the avionics installed.

^And, agreed! The flyonspeed.org site has some great literature for RV operations!
 
Last edited:
Epic Optix Eagle II

I don't have a Van but love the aircraft. I've been flying with an Epic Optix Eagle II HUD in my Mooney M20E. The Eagle II has the capability to show Garmin information on the HUD although I don't have those systems, so I just show my iFlyGPS information on it from my Samsung Galaxy S9. It's a true focused to infinity HUD and while it's not conformal I have to say that in every approach I've flown with it the real world runway lines up perfectly with my iFLYGPS software that is in front of my eyes via the HUD. In bad weather it has been a lifesaver, and when I've broken out of the clouds on approach the runway is precisely where the HUD indicated it would be. As a prior naval aviator flying the EA6B/F18G, I have to say that this Eagle HUD is the best thing I've seen or used since sliced bread. It sure beats what we have in the F18 from a capabilities standpoint. It would be interesting to see the software being developed for the Huddly showcased on the Eagle II.
 
Last edited:
Back
Top