Ironically, you might think, I waited until the very last minute to get ADS-B Out installed (well, re-installed) in my RV-6A. The RV arrived back in 2017 with a Dynon system which included Dynon’s (which is actually Trig’s) Mode S transponder. Within a few weeks I swapped out the standard GPS for the 2020-complaint version (SV-GPS-2020) and was fully legal. That worked great until this past summer when I went and ripped everything out to install FlightView. Transponder integration was a long way down the FlightView feature list, so I punted and installed an old but reliable Garmin GTX-327.
Late this fall I finally got around to working on the transponder. It turns that it uses a rather complex low-level protocol called TMAP which both configures and remote controls the transponder. Fortunately, I have friends who are much smarter than I am. With a huge amount of help from Eugene (thanks, Eugene!) I managed to put together a working TMAP implementation. It allows FlightView to do all the transponderish stuff you would expect: squawk, ident, switch from standby to altitude mode. Exciting stuff. So that took care of the transponder requirement. Unfortunately, getting the ADS-B Out feature working was not so straightforward.
The Dynon GPS meets the performance requirements of the 2020 mandate. So does the Trig TT22 transponder. And they work together beautifully in an all-Dynon system. Unfortunately, it’s a bit of a challenge to get them to work together without the Dynon EFIS. The GPS operates at 8 volts (weird) and communicates at 115,200 bit per second (sounds fast, but it’s not). The Transponder operates off of standard ship’s power (12v – 28v) and communicates with the position source at a maximum 38,400 bits per second. The transponder is built to communicate directly with a 2020 position source, and does in many installations. Unfortunately, not in Dynon installations. In a Dynon install, the EFIS acts as a bridge between the GPS and the transponder. It digests the data from the GPS and pushes it to the transponder using the aforementioned TMAP protocol.
Ok, so under ordinary circumstances that would be fairly easy to replicate, but unfortunately the GPS includes one special message that tells the receiving gear (transponder or EFIS) the current accuracy and integrity of the position fix. That message is, unfortunately, proprietary. You need the documentation from the GPS chipset manufacturer to know how to decode the accuracy and integrity information in order to pass it along to the transponder. Without the details on that message you can’t know the accuracy / integrity. Ouch.
Ok, so the transponder also supports a direct RS-232 connection to a position source. The FlightBox can bring the data from the GPS in at 115,200 bps and spit it back out at 38,400 bps. All it takes is a pair of RS-232 adapters and two available USB ports – not a problem, right? Well, it turns out that it’s not at all hard to do but there’s still one small snag: the transponder firmware apparently doesn’t speak the GPS dialect used by the Dynon GPS. At least not with the firmware it has now. It almost works. It sends out ADS-B squits* with the correct position data, but without the all important integrity value. Without acceptable integrity data the towers ignore your squits and you’re not compliant.
By the time I figured all of this out it was late December. Time for Plan B, which in this case was to install an EchoUAT transceiver. The Trig would stay, but would be relegated to doing only basic transponderish stuff. The ADS-B function would be handled by a tiny black box from uAvionix. The Echo, fortunately, speaks a wider variety of GPS than the Trig, including the dialect pumped out by the Dynon. It’s also very simple to install – just power it up, configure it using a mobile app, and away it goes. It reads the squawk code and altitude inductively via the power connection, so all it needs is the feed from the GPS. The one down side: it can’t share an antenna with the transponder. Fortunately, I had a second transponder antenna that I was using for ADS-B In.
I finished the installation and the ground tests just after noon on December 30th. A half hour flight around the Santa Clara valley was enough to generate a passing PAPR report. I would estimate I spent at least 100 hours coding and burned at least 20 gallons of av gas trying to get this right. Not the most efficient path to ADS-B compliance.
Eventually I intend to revisit the Trig, as I would like to be able to use the second antenna for ADS-B In functions again. I think (and please speak up if you know) that the trick might be getting the transponder firmware updated, something which requires the assistance of an authorized Trig dealer. A more recent update added support for the Trig TN72 which is rumored to use same chipset as the Dynon SV-GPS-2020. If anyone knows the detail, please post a comment.
Transponder control isn’t one of the sexiest FlightView features, but it is nice. Getting the TMAP driver working is a good first step. At some point I hope to add support for other transponders including the Sandia STX line and possibly the Garmin GTX models if I can figure out their protocol.
* No, squits are not some unfortunate digestive condition. ADS-B is “automatic” – meaning the transmitters don’t require an interrogation but instead send out an update known as a “squit” once per second. The ES in 1090-ES actually stands for “Extended Squitter”.
For the past few weeks I’ve been working on an interactive checklist feature for FlightView, our iPad-based EFIS. This checklist feature lets you create lists containing items which FlightView can display and also play as an audio prompt. (Think: “Flaps to 20 degrees.”) You acknowledge the list item by either tapping a button or by saying an acknowledgement word. (Think: “Check” or “Twenty”.) I wasn’t sure how well this would work out, since in most cases speech recognition requires an Internet connection, which can be hard to come by at 10,000 feet.
Fortunately, Apple managed to surprise and delight by introducing a new feature in iOS 13. Offline speech recognition is now a standard feature available on all iOS devices equipped with an A9 or newer processor. This is a game changer: the same technology will ultimately allow us to build a comprehensive voice assistant into FlightView. (Think: “Artoo, plot a course to KRHV” or “Hal, open the pod bay doors.”) Cool stuff!
In the long term this will make FlightView an even better EFIS, which is great. However, the number of people who can use FlightView is fairly limited (for now) so I decided to build a stand-alone app that anyone can use. The Chekov app runs on all recent iPhones and iPads running iOS 13. iPad Multitasking lets you to use it concurrently with your favorite EFB app.
You can install Chekov now from the App store:
As with all of our products, we appreciate your feedback. If you try Chekov and have suggestions or questions please drop us note or open a trouble ticket.
And finally, a tip of the hat to our namesakes:
“Knowledge is of no value unless you put it into practice.”
– Anton Chekhov (author)
“Excuse me. I am looking for the nuclear wessels?”
– Pavel Chekov (space ensign)
A quick post to cover the process of installing the FlightView app on your iPad. The process is as follows:
Then follow the instructions in TestFlight to install the app. Once it has finished installing, start it up and follow the setup assistant to install base maps, the aviation database, and terrain.
The beta is open to the public and totally anonymous – we don’t get contact information or anything else when you join. The only things that get sent back are your feedback and debug logs.
I’ve been flying with various versions of FlightView for nearly two years now. When I moved from Kansas City to Cupertino in July of 2018 I had an alpha version running on a RAM mount next to the Dynon system that came with my RV-6A. This gave me a safe and reliable way to test, tune, and validate FlightView. If something didn’t work as expected (which happened occasionally with the early versions) I had a set of instruments to fall back on.
That was a great way to start out, but eventually you have to “eat your own dog food” as they say in the tech world. Over the course of the past year the FlightView software and hardware had matured to the point where I was ready to take off the training wheels, so early this summer I took out the original panel – the Dynon, the steam gauges, and everything else – and replaced it with a dual-screen FlightView system tied to a TruTrak Vizion autopilot.
Before: note the steam gauges and the first-generation 7″ Dynon display.
After: 11″ iPad Pro and 12.9″ iPad Pro, TruTrak Vizion AP.
Once the upgrade was complete I started with taxi tests, followed by some short flights – first in the pattern, then out in the “practice area” south of San Jose. I flew the new configuration locally for roughly five hours, testing out the integration with the TruTrak and getting comfortable with using FlightView as the primary (and only) instrumentation and navigation system.
The five hours of local ops was a good way to test out the individual features and functions, but the real test of an EFIS is a long cross country. From San Jose to Oshkosh definitely qualifies: 1800 miles and 11+ hours of flight time by either the northern or southern route. (A truly direct route isn’t an option – too many mountains and restricted areas.) I figured that 22+ hours of cross-country would help shake out any remaining gremlins and would prove – to me, and to everyone else – that an “iPad EFIS” could really do the job.
On July 18 I loaded up the RV and headed out, following the southern route down California’s central valley, then across the desert south of Las Vegas to Santa Fe, New Mexico. The first segment took me from Reid-Hillview (KRHV) to a fuel stop in Apple Valley (KAPV) near Victorville. I pre-programmed the route into the FlightView FMS, starting with a direct leg to the Avenal VOR. From there I followed Victor airways to KAPV.
Back in Missouri I regularly flew “direct” everywhere. The midwest is mostly flat, making for plenty of places to land in an emergency. The west is beautiful but much less forgiving, with mountains, canyons, and forests covering most of the routes. Following established airways kept me in constant radio range of ATC and out of the many MOAs and restricted areas that cover huge sections of the map. Following the ancient VOR pathways also gave me a good opportunity to really test the navigation and autopilot functions of FlightView.
After two hours and fifteen minutes in the air I landed in Apple Valley for some good discount 100LL. A few minutes later I was back in the air, climbing slowly back up to 11,500′ to avoid the building heat and bumps. So far, so good.
The segment from Apple Valley to Santa Fe was beautiful, in an unearthly and inhospitable way. Even following an airway I was in empty part of the world – nothing on the traffic display, nothing on the ground below. The 3 hour and 30 minute flight eventually took me over Prescott and Winslow Arizona, then Gallup New Mexico before arriving at Santa Fe municipal. Over the course of the flight I probably was “flying” a total of about ten minutes – the takeoff and landing. The rest of the time FlightView and the TruTrak guided the airplane along the course unaided.
The next day I was up and off the ground early, trying to beat the heatwave that had engulfed the central and eastern parts of the country. I plotted a course from KSAF to a small airport in southern Kansas that was showing a very attractive price for 100LL. I cruised north-east, again at 11,500′, until I hit my descent point about 30 miles from the destination. By the time I reached 9500′ the OAT had gone from a comfortable 73°F to 85°F. On the ground it was hovering just below 100°. This was uncomfortable, but it was also a good test of the cooling system for the iPads.
As you might know, the iPad’s Kryptonite is heat. Get the battery core temperature above about 95°F and it will shut down to protect the lithium cells from cooking. As airplanes often experience temps in excess of this, we built a custom mounting system (FlightDock) which uses a high-speed fan to keep the tablets running in conditions where they would otherwise shut down. I had spent a good bit of time testing this in lab conditions and the mount had managed to keep the iPads running in ambient temperature that topped out at 108°F.
On the ground in Sublette, Kansas (19S), the cabin temp quickly climbed past 100° while I tried, unsuccessfully, to get avgas from an apparently empty pump. By the time I gave up and climbed back into the cockpit, the seats were hot enough to sting and the panel was too hot to touch. I started the engine and powered on the avionics master, bringing the FlightDock fans online. The thermal sensors in the fan controllers kicked into high gear, blasting the backs of the iPads. Both came online and loaded the FlightView app as normal. A quick check of the hardware status page showed that they were experiencing some thermal stress (which causes iOS to throttle back some functions) but they behaved normally and easily got me to Dodge City (KDDC) where I was able to fuel up.
The leg from Dodge City to Liberty, Missouri was another two hours and twenty minutes at high altitude. The air temp was into the 90s up to about 8500 MSL, so I stuck to 11,500 until I was just outside the Kansas City class bravo ring, then descended at 1500′ / minute through the hot air, muggy air to land at Roosterville (yep, that’s the name – look it up – 0N0) airport. I learned to fly at Roosterville, and was based there until I moved to California. Great little airport with a 20′ wide x 2700′ long runway (with a hump in the middle, and a slight dog-leg).
Saturday morning I checked the weather and found that Oshkosh was expecting severe weather. As it turned out, the forecast was correct: torrential rains and a number of tornados (or micro-bursts, depending on who you ask) hit the greater Fox Valley area, turning Wittman Field into a shallow lake. By early afternoon word went out that even if the weather cleared, there was no way to park aircraft on the grass. Anyone without a hard-surface parking reservation was to be turned away. By that point I had checked out of my hotel, but fortunately a friend had a very nice (air conditioned) camper trailer stored at Roosterville that I was able to borrow. (Thanks again, Todd!)
Unfortunately, the weather that had been plaguing Minneapolis and Oshkosh on Saturday swung south and hit Kansas City early Sunday morning, leaving a layer of scud hanging over most of the midwest. The RV (my 6A, not the camper) was tied down on the ramp without its canopy cover and was a bit damp in the morning. It took me about an hour to get things dried out, by which time a hole had formed in the low-level clouds. I launched and quickly found myself in perfectly still, cool air between the broken ground layer and another much higher layer of clouds.
At the time I launched, KOSH was still not taking any aircraft that would be parking on the grass. As I was flying north, an army of trucks normally used to drain porta-potties was working diligently to drain the swamps in and around Wittman. About forty-five minutes out I called up Flight Service and asked for an update on parking. Still closed. Ok…. Rather than waste gas, I decided to stop in Portage, Wisconsin (C47).
The ramp at Portage was its own mini-Oshkosh, with probably two dozen aircraft tied down and waiting. Shortly after I landed I got another text from the automated status system letting me know that the field was still closed. Fortunately, Fond du Lac (KFLD) – about 25 miles south of Oshkosh – was open and taking aircraft as long as they were willing and able to park on the grass. Sold.
A little after 1:00 PM CDT, I landed at KFDL and was marshaled to a spot on the far side of the field. With the extra stops I had traveled 1850 nautical miles in just shy of 12 flight hours. At least 10 of those hours were actually flown by FlightView and the TruTrak. The system handled turbulence over the mountains in Arizona, the heat across the midwest, and a soggy night on the ground in Kansas City. It wasn’t perfect – I had a couple of thermocouples that became intermittent, and the fuel-flow dropped out for a bit – but it got me there in comfort and style.
My one regret: I flew myself in the RV both to test out the system and also to show it off to everyone. Unfortunately, I ended up leaving the airplane at KFLD. It would have been nice to have it over at KOSH. Fortunately, the three-screen demo panel I brought did a pretty good job of that.
In response to the blast of questions that have been coming in, I’ve created a video playlist on YouTube that covers some of the more interesting features of FlightView. The library also contains a longer-form video that walks you through the process of upgrading a FlightBox with the 2.0 beta, and installing the FlightView app beta on your iPad.
So about the blog… The past few months have been pretty busy, and unfortunately the blog has been a bit neglected. I’m going to try to remedy that starting now. (But you know how life goes.)
You might have noticed the addition of a new product – something called FlightView. If you’re a regular follower of this blog, you might recall a post from some 16 months ago announcing a new EFIS. I think I even used the phrase “coming soon.” Oops. That said, I think you will find it worth the wait.
FlightView is an Electronic Flight Information System (EFIS). That’s a bit of a catch-all term that gets used for a wide range of products. Some are basically attitude indicators with… attitude. Others (like FlightView) could best be described as operating systems for aircraft. They either provide or are connected to every major system on the airframe: flight instruments, engine instruments, navigation, terrain awareness, traffic, weather, communications, and surveillance. They tie all of those systems and technologies and data sources together into a single coherent view.
What’s really cool about EFIS* technology is that, unlike steam gauges or even independent digital instruments, the whole is truly greater than the sum of its parts. The EFIS has the ability to constantly scan all of the inputs and cross-check one against another. Yes, this is something that us pilots are supposed to do, and should continue to do even if we have an EFIS. But let’s be honest here – the machine has some advantages. It doesn’t get distracted by neat cloud formations. It doesn’t get into engrossing conversations with passengers. It doesn’t try to pick out its mom’s house from 5000 feet. It stays on the ball, all the time.
Variations on the EFIS concept have been around for a while now. Modern airliners have had extremely sophisticated digital flight deck systems for the past thirty years. Elements of those began to trickle down to the GA world in the late 1990s with products like Garmin’s G1000. The heavy iron systems generally cost tens of millions. The first generation GA systems cost tens of thousands. Thanks to Moore’s Law, the mobile computing revolution, IoT, and MEMS sensors, FlightView gets to shave another order of magnitude (or more) off the price tag.
FlightView is made up of a number of independent systems, all of which are built to work together. Where the typical EFIS has a very expensive custom display system (screen + computer + knobs), FlightView uses an off-the-shelf iPad. The iPad runs an app which communicates with a network of sensors, receivers, and interfaces. The various sensors, receivers, and interfaces are spread across a set of small boxes that add up to about two pounds.
One of these boxes is a souped-up version of our FlightBox Pro (called the FlightBox Pro EXP) which serves as the hub of the system. Where the typical EFIS sports multiple DB-25, DC-37, or DD-50 connectors, FlightView has two USB ports which connect to USB hubs. We polled the membership of a number of EAA chapters and found that the least favorite part of an avionics install was building the wiring harness. Using USB simplifies the installation process significantly.
The other boxes are an air data computer and an engine monitor. The air data computer (ADC) connects to the pitot and static lines and to an OAT probe. It sends airspeeds, altitude, vertical speed, and outside air temp back to the FlightBox Pro EXP. The engine monitoring system (EMS) box has ports for all the standard engine probes and senders: RPM, manifold pressure, fuel level, fuel flow, EGT, CHT, etc. Both the ADC and the EMS have modular jacks (think land-line phones) that connect to the USB cables from the FlightBox. They both also contains Wifi radios that can connect to the FlightBox network if the serial link is interrupted.
The iPad and the three boxes make up the main components of the system. We also offer USB-to-RS232 cables that can interface with COM radios, transponders, autopilots, and ELTs. To round out the package we’re also launching an iPad mount with active cooling and a gizmo we’re calling FlightBar. FlightBar adds a set of two knob and six buttons to the FlightView display (iPad), making the system much easier to use in turbulence. (If you’ve ever tried to use a touch screen in the bumps, you understand what I’m talking about.)
The most visible part of FlightView is the app. If you’ve used an EFB app, you have some idea of what to expect. The FlightView app includes a primary flight display (PFD) view, a multifunction display (MFD) view, an engine monitor system (EMS) bar, and pop-up views for radios, transponders, and other systems. The FlightView system supports up to three displays – three iPads simultaneously displaying aircraft data. (Oh, and there’s no charge for the extra displays other than cost of the iPads.) Displays can be full screen (i.e. all PFD or all MFD) or split 50/50. The EMS bar is optional.
The list of features is pretty long and, because the front end of the EFIS is an app, only going to get longer. (You can check out the current list here.) The backlog of features we plan to add is pretty long. (Yes, synthetic vision is on it.) Before we start in on those projects we want to get feedback from a broad group of users. And that brings me to this…
If you have an iPad and a FlightBox, you can try out FlightView today. We have a beta upgrade for FlightBox that allows it to communicate with the FlightView app. We also have a beta version of the FlightView app that you can install now. Here’s the process.
To help out, here’s a video that walks you through the process. (Wherever it mentions and email, just refer to the links above.)
We will be formally launching FlightView at Oshkosh 2019. If you’re going, please stop by and see us. We will be in Hangar A (Aircraft Spruce) in Booth 1043. That’s on the left-most row of the hangar towards the back. We will have a demo system running in the booth. We will also have our RV-6A testbed out in Homebuilt Parking for those who want to take a look at FlightView in its natural environment.
We will be giving a forum presentation on Thursday (7/25), at 4 PM on Forum Stage 11. The forum will cover ways to save and simplify on avionics for your homebuilt or LSA.
Did I mention that FlightView is the lowest cost EFIS on the market? The normal price for the core hardware bundle (FlightBox Pro EXP, air data computer, and engine monitor) will be $2000. Between now and July 31 we are offering an early-bird AirVenture special: $1500.
You will also need an iPad and the probes for the engine monitor, but that still gets you a complete EFIS for less than half the cost of a system from the usual suspects.
* What really sucks about EFIS…es is trying to figure out a reasonable plural. EFII? EFISesz? EFUM?
Moving is always painful. For the past month we’ve been operating in limbo while realtors and their clients wandered through the house / shop / office. As you may recall, we abandoned ship for a couple of weeks in May to let them look in peace. Fortunately, that worked and we now have a contract, a moving date, and a new location in Cupertino, California.
That’s the good news. The bad news is that we will be closed for another two weeks while things get packed, loaded, hauled, unloaded, and re-assembled. I have to have everything packed up by next Monday (June 25), so Friday, June 22 is the last day I will be shipping orders until we get thing re-established in the Golden State on or around July 8.
The address for the new location is:
Open Flight Solutions
10649 Nathanson Ave.
Cupertino, CA 95014
Effective immediately, if you have a system that needs updated or repaired, please send it to the new address. Things sent to the old address may take quite a while to forward.
For everyone impacted by the move, I truly appreciate your patience and understanding. If you make it up to to Oshkosh next month, come by the booth and I’ll give you water. Or catch me after the booth closes and I’ll buy you a beer.
P.S. – I also have good news with regard to the EFIS project. I’ll have a post on that up in the next day or so.
Dear Open Flight Customers,
Several months ago my wife took a job with with a large technology company in the greater Silicon Valley area. I stayed behind in Kansas City, getting the house ready to sell and allowing our daughter to complete her senior year of high school. This weekend (May 13) she graduates. The house goes on the market the next day. As soon as it sells, Open Flight Solutions will relocate to a new address in California.
I am excited about the opportunity this brings. The Bay Area has a vibrant general aviation community and is the undisputed technology hub for the entire planet. I expect that this move will accelerate a number of projects including the previously announced EFIS.
That’s the good news. The bad news is that selling a house with a working factory in the basement is a challenge. To help expedite the process (and to keep our realtor sane) we are pausing operations for two weeks, starting Monday, May 14. Orders received after May 14 will be processed / shipped the first week of June. During the sale period and subsequent move we will continue to provide technical support using our online trouble ticket system.
I apologize for any inconvenience this may cause. Moving is always a painful process, but I am looking forward to getting through the move, reuniting my family, discovering a new part of the country, and continuing to develop innovative solutions for the general aviation market.
P.S. – If your travels take you to northern California, please let me know. My airplane will be based at Reid-Hillview (KRHV) in San Jose.
TL;DR – A new FlightBox update is available that adds AHRS support for ForeFlight and GPS NMEA output over RS232.
Welcome to the middle of winter. Things have been rather quiet for the past couple of months, which has allowed us to spend some time heads-down on new features and functions. First among those is AHRS support for ForeFlight*. This has been the number one request since we rolled out the original AHRS support back in March of last year.
The update is available for download from our site or for installation using the FlightBox Utility app. New systems ordered after February 14 will ship with 1.4r4 installed. The code has seen quite a bit of testing from the Stratux community, so it should be smooth sailing under most circumstances.
A few notes on the FF AHRS feature:
Web Interface – To get to the FlightBox web interface, you normally open a web browser and go to 192.168.10.1. Because of changes in the update this might not work in some cases (please see below for geeky details). If you update to the latest version and cannot get to the web interface on 192.168.10.1, try accessing it on 10.26.36.1. If that doesn’t work for you, go into your computer’s (or mobile device’s) network configuration and use the “Renew Lease” function to get a new IP address. (Or just reboot it – that will do the same thing.)
Fully Automatic, Mostly – Once you’ve installed the update you should be able to fire up ForeFlight, select the PFD view, and within a few seconds you’ll see the attitude display lock in. If the display is not level, make sure you have the level-point set from the “GPS / AHRS” page of the FlightBox web interface before you try adjusting the level point in ForeFlight. You may have to restart the ForeFlight to get it to detect the AHRS data.
Requirements – You must have the AHRS hardware installed and configured for this to work. You also must have a ForeFlight subscription that includes synthetic vision to be able to use their synthetic vision feature.
Somewhat Sensitive – The ForeFlight display is somewhat more sensitive than other apps and can bounce a bit. This is in part an artifact of the way we integrate with it. The better the alignment of the FlightBox with the aircraft, and the more secure the mount, the better your results will be.
Apps – This may break the Android and iOS utility apps. To make the AHRS data visible to ForeFlight we had to make some changes to the network addressing structure we use (again, please see the Geeky Details section below if you’re geeky and care about the details). As a result of this, the utility apps will need some updates. If you can’t get the app to connect, please use the web interface.
Other New Stuff
v1.4r4 also adds another new feature: NMEA output. NMEA output lets FlightBox share GPS data with other device over an RS-232 link. The standard GPS mode outputs the current location, ground speed, ground track, and altitude data. (Those would be the $GPRMC and $GPGGA sentences.) All kinds of aviation gadgets can make use of GPS information. Autopilots use it to follow a ground track. ELTs use it to send your position. Fuel computers use it to determine your range.
GPS mode is a great enhancement on its own, but the really interesting feature is NAV mode. In NAV mode, the FlightBox outputs the active waypoint and course deviation information that autopilots use to steer a course. (The $GPRMB and $GPAPB sentences). The steering algorithm in FlightBox can even intercept course lines and anticipate turns – the “roll steering” or “GPSS” feature that is usually only found in high-end navigators.
The kicker with NAV mode is that there’s no standard method for EFB apps to send the flight plan data to FlightBox, so we’ve developed a very simple data exchange format that we’re hoping to get our EFB friends to implement. If you would like for your favorite EFB app vendor to support NAV integration with FlightBox, please send them an email asking them to check out our Integration Guide.
To use the NMEA output, you’ll need an NMEA serial adapter cable. To install it we recommend using a small unpowered USB hub, as this makes connecting it much easier. (The other option is to perform surgery on your FlightBox case to get at the open USB port.) Note that the serial adapter requires the remote GPS – it is not compatible with the internal GPS.
From the lawyers: Please be aware that connections to required, installed systems in a certified aircraft generally require either an STC or a field approval. In some rare cases approval may be available from the manufacturer of the aircraft or certified system. Do not connect FlightBox to a certified system in a certificated aircraft without appropriate approval. Doing so will invalidate the airworthiness of your aircraft.
Getting The Update
The new release is currently available through all of the regular update channels:
This is a larger update and takes a bit longer than most to install. Give your FlightBox at least two minutes to complete the update process.
AHRS Upgrade Kits
If you’ve been holding off on adding the AHRS hardware, you can order the upgrade kit here. It’s only $100 and includes everything you need to add AHRS capabilities to your FlightBox. Please note that your FlightBox must have a GPS for the AHRS features to work. If you don’t have a GPS, you can add either an internal or remote for $35.
WARNING! If you are not a computer / networking geek, please don’t read this. It contains more techno-babble than a StarTrek marathon. You have been warned.
The new release changes the range of IP addresses that the DHCP server on FlightBox uses. We previously served addresses in the 192.16.10.x range. In order for ForeFlight to recognize the data we are sending, we had to change the source to 10.26.36.1 so we’re serving addresses in that range.
To make the transition as seamless as possible, the FlightBox adds an alias address of 192.168.10.1 to the Wifi interface. If you connect to it from a device that only has Wifi enabled, or which makes the Wifi connection the primary connection, you should have no problem getting to the system on the alias address. However, if your device has multiple interfaces, including one which is prioritized above your Wifi interface, you may not be able to get to the FlightBox using the alias. In that case you’ll want to use the 10.26.36.1 address.
* As always, we need to be clear that Open Flight Solutions is not affiliated with nor endorsed by the makers of ForeFlight.
UPDATE: FlightView EFIS Is Now Available
For the past two years Open Flight Solutions has been building and selling the FlightBox line of ADS-B receivers. From the beginning we envisioned FlightBox as the starting point for a much broader set of product intended to reduce costs while increasing safety. While we’re not quite “there” yet, we’re getting close, and I believe this is a good time to share the high-level vision with the aviation community.
In the next several months we will be releasing a set of components that allow homebuilders and LSA manufacturers to assemble a full-featured EFIS with high resolution touch display, precision air data and attitude sensors, comprehensive engine monitoring, WAAS GPS, and dual-band ASD-B for around $2000. Rather than taking the traditional monolithic approach, we’re creating a distributed, optionally redundant network of independent components that provide the full EFIS feature set at a lower price and with greater reliability.
We plan to seek NORSEE approval for these components, allowing them to be installed in certificated aircraft to facilitate better situational awareness and to serve as a backup to legacy instruments.
Please take a few minutes to look over the preview below and let us know what you think. If you’re interested, please sign up for our FlightBox EFIS mailing list. Feel free to send your thoughts and questions directly to email@example.com.
The displays (1) are Apple iPads running an EFIS application that we’ve developed. The displays interface with other components (and with each other) via the wireless network created by the FlightBox (3). Expanding from a single display to a dual display is simply a matter of adding a second iPad.
The FlightBox (3) acts as a hub, relaying data between the displays and the other components in the network. It also serves as a bridge to third-party systems including autopilots, COM radios, and transponders. In a fully redundant configuration, the aircraft is outfitted with two FlightBox units, one serving as the primary flight computer, the second as the backup.
The ADAHRS (4) uses a set of solid-state (MEMS) sensors to generate attitude and air data. We support single or dual ADAHRS configurations. The EMS (5) connects with a full set of engine probes and relays engine data to the FlightBox and displays. Both the ADAHRS and EMS feature builder-friendly installation, with simple, rugged connections and no complicated wiring harnesses.
Other EFIS vendors put a good deal of effort into building custom display hardware. We’ve decided to take a different approach and leverage the significant engineering expertise of Apple. The current line of iPads is powerful, light weight, bright and has been road tested over the past decade by literally millions of users. It’s also much less expensive than a custom display, with a starting street price of only $279.
We’ve overcome the iPads’s one major limitation – heat – with a light weight panel mount that includes thermally controlled active cooling. Made from the same FAA-approved plastic as our FlightBox, the mount is strong but still weighs in at less than one pound. A set of six thumb screws hold the face place securely, but allow you to swap iPads in a matter of seconds. It includes secure, recessed spaces for a Lightning power connector (included) and for a low-profile audio connector (optional). It provides access to the sleep (power) button, the home button, and the front-facing camera.
We currently have a mount for the 9.7” iPad. We’re in the process of designing mounts for the 10.5” iPad Pro and the 7.9” iPad Mini. If there’s any demand, we will also build one for the 12.9” iPad Pro.
The FlightBox EFIS application currently provides all of the basics required for VFR flight: a complete set of flight instruments; a moving map with a database of US airspace, airports, and nav-aids; power plant instruments, and VFR navigation. The primary goals for the first release are usability and stability. We’ll add the bells and whistles in upcoming releases.
The app is currently in private beta (internal testing). The first version is scheduled to be released in the March / April timeframe. The app will be free with in-app purchases for maps, charts, and some advanced features.
One of the greatest advantages of the iPad is its multi-touch interface. Unfortunately, turbulence can make a touch-screen difficult to use. To overcome that limitation, we’ve designed a secondary “twist-and-click” user interface we’re calling the Turbulence Tactile Interface or TTI. This optional device adds two rotary encoders (aka “knobs”) which connect to the iPad using Bluetooth. In smooth air, use the touch screen. In the bumps, use the knobs.
We have a working prototype of the TTI and are in the process of revising that into a marketable product. We should have pricing and an estimated availability date by mid-March.
FlightBox continues to act as an ADS-B and GPS receiver, but it picks up some additional duties. We use it to relay data and commands between the ADAHRS, the EMS and the displays. It outputs NMEA data to an autopilot (if installed), control codes to Garmin SL-30/40 and compatible radios, and (soon) TMAP to transponders. The onboard AHRS becomes the backup attitude source if an ADAHRS (see below) is installed and active.
If you already have a FlightBox, you will be able to upgrade it to support the new features and functions. For those who don’t have a FlightBox, you can use the FlightBox Plus, FlightBox Pro or the upcoming FlightBox EXP. The Plus model is a portable, while the Pro and EXP are built for permanent installation and can be connected directly to ship’s power. (Note: permanent installation in certificated aircraft requires the Pro, which has FAA NORSEE approval.)
ADAHRS stands for “air data / attitude and heading reference system.” It includes a set of air pressure sensors that connect to the pitot and static lines, an inertial measurement unit (gyroscope / accelerometer) for determining attitude, and a magnetometer (digital compass) for magnetic heading. If installed, it becomes the primary source of altitude, attitude, and airspeed.
We worked very hard to make the ADAHRS small, accurate, and inexpensive. You can install either one or two ADAHRS units in an aircraft. In a dual ADAHRS configuration, the FlightBox continually cross-checks between the two and alerts the user in the event of a disparity. They’re cheap enough ($450 each) that most users will want to go with two. We will be be taking pre-orders starting in March.
We’ve also built a prototype engine monitoring system (EMS) that supports 4 and 6 cylinder engines, providing RPM, MAP, CHT, EGT, Oil Temp, Oil Pressure, Fuel Level (2), Fuel Pressure, Fuel Flow, Volts, and Amps. Each unit has a total of 16 thermocouple interfaces. Rather than wiring everything through a single DB-XX connector, it uses thermocouple quick-connects and screw terminals which makes it significantly easier to install and maintain.
We’re expecting the second round of prototypes in March. We should have them available for pre-order in April, with delivery slated for May or June. While the final price will depend on the package of senders and probes selected, the data acquisition unit (the interface box) will retail for between $400 and $450.
While we’re quite proud of our app, we’re committed to the idea of an open platform. We will be publishing an integration guide that allows 3rd party developers to add support for our hardware to their apps. This will include the real-time data feeds from the ADAHRS and EMS, autopilot integration, COM and (eventually) NAV radio integration, and transponder control.
If you have a preferred EFB app, we suggest that you contact the developer and ask them to sign up for the FlightBox EFIS mailing list. We expect to have the initial draft of the integration guide available in March.