** IT WILL NOT INSTALL ON OTHER FlightBox HARDWARE **
I’ve put together a “hot-fix” update that includes a number of fixes and a few small features. As a hot-fix, this update will need to be installed manually (rather than from the FlightView app). As none of the fixes are critical, feel free to skip this unless you need one of the two new features. These include:
You can download the hot-fix here. You will need to install it manually. The process is fairly simple:
After a brief period the system should respond with a pop-up letting you know that the update was successfully uploaded. It will take between three and five minutes for the update to complete. During that time the FlightBox Pro EXP will reboot twice. After the second reboot the system will come up with the new firmware installed.
*DO NOT UNPLUG OR POWER OFF THE FLIGHTBOX WHILE THE UPDATE IS INSTALLING*
Your computer’s Wifi interface may connect to a different access point when the FlightBox reboots, so you may need to re-connect to the FlightBox Wifi after the update is done. To verify that the update finsihed successfully, repeat steps 1 – 3 again and check the Status page. It should show the new version (2.1r1, build 4c112c5a43-PRO) as the installed version.
* Yes, computer. Last time I checked, you can’t upload files from Safari on the iPad. That might have changed with the move to ‘iPad OS’ but I’ve not tested it. This process works fine from any desktop browser: Chrome, FireFox, Edge, or Mac Safari.
I’ve been compiling frequently asked questions about FlightView and now have a pretty good start on a “living” document. I will be adding to this on a regular basis. If you have a question that’s not on the list, please email it to email@example.com and I’ll do my best answer it.
I’ve published a copy of the installation guide and diagram on the FlightDock product page. If you run into any questions or issues with the installation, please let me know. Here are direct links: FlightDock Mounting Diagram and FlightDock / FlightBar Installation Guide
Just a quick note to let everyone know that the move is complete and we are now located at Breakaway Airpark in Cedar Park, a suburb of Austin Texas. Our new address is:
Open Flight Solutions
2901 Kenai Drive
Cedar Park, TX 78613
Production has resumed on the FlightBox and FlightView lines. We’re currently running about 10 days on a FlightView Core Kit or FlightBox Pro. FlightBox portables are expected to be back in stock the week of June 15. Apologies for the delay. It seems that there has been a bit of a run on Raspberry Pi computers as a result of the pandemic.
So if you’ve been following this blog for the past several years you might recall that we moved from Liberty, Missouri (a suburb of Kansas City) to Cupertino, California in 2018. That move was the result of a fantastic career opportunity for my wife Amy. Well, two years later she has been offered a promotion with a relocation to Austin. There are few things worse than moving, but in this case I’m looking forward to it. The Bay Area is beautiful, and the weather is fantastic, and it’s so absurdly expensive that growing a small “bootstrap” (i.e. self-funded) business is a significant challenge. The move to Texas will reduce costs (like my $630 / month T-hangar) and make it much easier to grow.
The down-side to the move is that it will disrupt things for a couple of weeks while everything is in transit. Orders for FlightView systems, FlightBox Pro systems and most accessories that come in after May 15 will be shipped as soon as things get unpacked – probably somewhere close to June 1. Orders for FlightBox Plus systems (the portables) should ship next-business-day in most cases. I will be providing tech support by email / trouble ticket throughout the move, but there may be slightly longer delays in response time.
The new address for the company will be:
Open Flight Solutions
2901 Kenai Dr.
Cedar Park, Texas 78613
Thanks in advance to everyone for their patience. I look forward to working with you from the new digs in Austin.
We’re getting close to a 1.0 release of the FlightView app. I just pushed the latest beta version to Apple’s TestFlight. It should be approved and available to all beta testers in the next 24 – 48 hours. I’ve had several users ask for a way to see FlightView in action without actually having to install all the hardware. Understandable. Fortunately, using off-the-shelf gear makes that pretty easy.
The demo flies a continuous circuit around California through heavy air traffic (300 random simulated targets), through a rain storm, and over some challenging terrain. The emulator sends a constant stream of data for all the key subsystems including the engine monitor, radios, and transponder. To get the full effect you’ll want to install the base map for California and the “US North-West” and “US South-West” terrain images in FlightView. (NOTE: Because of a change in the way we’re handling file access, you will need to install Beta version 0.3 before you can install the terrain files. Apologies for any inconvenience that may cause.)
Here’s the instructions in somewhat greater detail:
If you don’t have a copy of FlightView yet, you can install it from TestFlight. To do so:
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.