For the past several months FlightBox has been shipping with a copy of Stratux v0.8r2. After several months of testing we’re happy to announce that an update to Stratux v1.0r1 is now available. 1.0 fixes a number of minor issues. Updates to the software include:
All together these make for a more stable and powerful system. The Stratux community has been using v1.0 since mid-July with no major issues reported. I’ve put about 20 flight hours and over 500 bench hours on the FlightBox 1.0 build with no complaints.
Please see the Update Tutorial page for a link to the update file and for installation instructions. (Or just use our new iOS app to install the update.)
As always, a big thank you to Chris Young and the Stratux community for all the work that went into 1.0!
When we launched the last update a few months ago we had a number of users complain that after installing the update their system stopped working – the dreaded “bricking”. To get everything back up and running they had to re-image the SD card (or send it in for us to re-image). It took a bit of digging but I finally figured out what was happening.
When you download the firmware file you wind up with something that looks like this:
If you happen to download it again, you wind up with this:
It’s exactly the same file, but the download manager adds ” (1)” to the file name. The space you see between the end of the build ID and the open parenthesis is the culprit: it causes the installation to fail – and it also causes the delete command that should remove the .sh file from completing. So every time the system boots up it finds the update file, tries to apply it, fails, and reboots. Instant “bricked” system.
If you update manually (i.e. not using the new iOS app) be absolutely certain that the filename does not have a space in it. If it does, you will wind up bricking your system and will need to re-image, send your card in for update ($3), or order a new card from the web store ($13).
A fix that eliminates this potential pitfall will be included in (embrace the irony…) an upcoming update.
When we launched on Kickstarter back in February we declared the beginning of a Kit Avionics Revolution. Since then we’ve sold over 1200 FlightBox kits to pilots all over the world. In so doing we’ve learned a lot about ADS-B and about the aviation market. The Kit Avionics Revolution has been a huge success for us, but one of the more important things we’ve discovered is the range of technical aptitudes and interests in the flying community. While many pilots relish the opportunity to get hands-on with their systems, others prefer something a bit more finished.
In order to serve those who just want to buy and fly, we’re pleased to announce the availability of the FlightBox FB1X – a fully assembled and tested dual-band ADS-B receiver with all the features of the original FlightBox kit. The assembled version includes high-gain antennas, a 12v/24v USB power adapter, and a one year warranty. It is compatible with all of our add-on products: the remote GPS, remote antenna kit, friction mount, battery, etc.
We’ve know that we were missing out on a segment of the market for some time. I’m very proud to say that we took our time and did this right. The FB1X is fully FCC certified. It has been tested over the course of more than 30 flight hours and under a wide range of conditions. It ships with version 1.0r1 of the Stratux software (updates for existing FlightBox systems will be release shortly).
The list price for the assembled FlightBox dual band receiver is $325. To celebrate the launch of our first turnkey product we are offering a $25 discount through the end of October. Our goal is to be the value leader in ADS-B, and at $300, I think we’re hitting the mark.
If you have any pilot friends who have shied away from FlightBox due to the “DIY” nature of the kit, please let them know that we’re now ready for them. They can order the FlightBox FB1X from our web store today.
When we launched FlightBox we consciously decided to go with a simplified design that did not include an internal battery. Batteries add weight, complexity, and liability to any product. By offering FlightBox with a standard 5v USB power input, we gave our users the option of using a cigarette lighter adapter, a battery, a solar charger or any other power source that could provide 2 amps at 5v.
After six months I still think this was the right choice: there are many FlightBox users who have found the flexibility to be extremely useful. Some users withe experimental aircraft have installed USB transformers. Most users who own certificated aircraft use a cigarette lighter adapter. CFIs who move from aircraft to aircraft throughout the day love the option of simply swapping batteries when needed.
But… the most common issue we run into is power. Many of the tech support calls and emails we field each week come down to inadequate power. After talking with a group of users at our booth in Oshkosh, it became abundantly clear that providing a number of trusted, reliable option for power was important. As a result we immediately added a USB cigarette lighter adapter to our catalog. The search for a battery took a bit longer.
Fortunately, it turns out that the need for a good source of portable USB power is not unique to FlightBox. As it turns out, the popular Pokemon Go game has made backup power for mobile phones practically a requirement. An old friend here in the KC area decided to capitalize on the demand for high quality batteries and ordered a large batch built to spec by a reputable manufacturer overseas. (At this point only Tesla is building lithium battery systems here in the States.) He gave me a sample to test and after a few weeks of abuse I am happy to announce that we now offer a battery.
The USB packs that we are selling are rated at 10,000 mAh which typically provide more than five hours of flight time on a full charge. (I’ve had the test unit last for 7.5 hours, but that was under cool, comfortable lab conditions.) They’re slim and weigh in at only 0.45 pounds. Most importantly, they consistently deliver up to 2.1 amps – more than enough power for a FlightBox. We’re offering them for $35 on the web store. They will come with a 6-inch USB cable and a set of velcro dots to (optionally) attach the battery to the FlightBox.
Note the supplies are limited: the Pokemon craze took up a big chunk of the supply, so we only have 50 in stock at the moment. More are on the way and should be here in September.
The last time I posted anything we had just finished loading up the giant rental van for our long journey north to Oshkosh and AirVenture 2016. A huge thank-you to everyone who stopped by the booth. We had a very successful week in Wisconsin. We talked with hundreds of pilots from all over the world. Across the course of the week we sold more than 100 FlightBox systems on-site, and nearly as many over the web.
Oshkosh was also a great chance to catch up with our EFB partners. It is amazing how many innovative developers are working to make aviation safer using consumer electronics platforms. Between the iPad aviation revolution and the recent release of “approved but not certified” products from Dynon and Garmin’s Team X, the future is looking brighter than ever. I managed to talk with a number of other vendors from the experimental avionics market and several of them have already launched projects to seek FAA approval for their products. I expect that AirVenture 2017 will host the launch of a number of newly approved, affordable systems including navigators and autopilots.
As anyone who has ever been to an Oshkosh (or, as the locals call it, to an “EAA”) knows, it’s absolutely huge. It takes up the entirety of Wittman Regional Airport and spills out into both the town of Oshkosh and the neighboring lake Winnebago. According to EAA officials, more than 10,000 aircraft and over half a million visitors attended this year’s event. We spent most of the time in our booth, but did make it out to see a few events, including an awesome night air show. If you’ve never been you owe it to yourself to go – it truly is a spectacle no pilot should miss.
I have to thank my wife Amy, my daughter Katie, and my friend Larry for hours of tireless work, and for making the long drive into the north woods. I also owe a huge thank-you to Bryan Heitman of Aerovie for hosting us. It was an amazing opportunity and we’re already looking forward to next year’s show.
A bit over three months ago we exhibited at Sun-N-Fun with DroidEFB, one of our application partners. The show was a huge success and resulted in over 250 orders over the next month. However, one of the most common refrains we heard was, “If you had them for sale here, I would buy one!”. Well, we heard you.
We’re showing up to Oshkosh with nearly 400 dual-band FlightBox kits plus remote antenna kits, friction mounts, and remote GPS units. We’re exhibiting with Aerovie, another application partner. You can find us in Hangar C, Booth 3078.
Sun-N-Fun was a solo gig for me, which was something of a challenge. This time the whole team will be at the show, plus we have a number of volunteers who will be joining us. We’re offering a new service as part of the Oshkosh experience. The new offer – called “20 Minutes To Taxi” – is a factory assisted build: you can borrow our tools and work with one of our expert builders to get your FlightBox system assembled, tested, and ready – usually in less than 20 minutes.
We will be exhibiting all week, so if you’re able to make it up to the big show please stop in and introduce yourself.
At least once a week somebody sends me an email about an ADS-B traffic target that suddenly appeared on their EFB app, often just a hundred feet above or below, and less than half a mile behind. The reporter is never able to spot the target, which appears to doggedly follow them for a few minutes before disappearing. No, this is not a UFO or a new stealth drone. It’s just an annoying (and occasionally panic-inducing) artifact of the way ADS-B works.
If you’re being chased by ghosts, don’t worry – you’re not alone. It’s not an issue that’s specific to FlightBox or to whatever EFB app you’re using. Every ADS-B In system occasionally displays a ghost, even for those of us equipped with ADS-B Out. Here’s what appears to be happening:
You’re receiving ADS-B traffic data from the FAA ground towers. Those towers are receiving data from secondary surveillance radar. The radar data is collected at various center and terminal radar sites and sent to the towers for processing and broadcast. The software in the towers use the “hockey puck” algorithm to determine what traffic targets get broadcast.
Apparently, the delay between the time the radar site picks up a target and the time it arrives in your cockpit can vary quite a bit. Most of the time your EFB is able to determine which of the various targets it’s receiving is your aircraft (often referred to as “ownship”) which it filters out. But if the latency (time lag in delivery) is too great, the software can’t be absolutely sure if a given target is really “you” so, so it displays it – frequently with a traffic conflict warning.
Theoretically, this shouldn’t happen with aircraft that are equipped with ADS-B Out. Each Out-equipped aircraft broadcasts a unique identifier (ICAO code) which should allow both the towers and your local software to filter it out, preventing ghosts. But even the towers sometimes can’t correlate between your radar target and your position as received directly from your ADS-B Out transmissions. They fall victim to the same latency-induced issues that plague your EFB. Rather than take a chance on miss-reporting a conflict, they rebroadcast the radar data as an anonymous target which suddenly appears on your screen as a ghost.
The ghost effect appears to be worse when you’re in an area covered by multiple radars and multiple ADS-B towers. In talking with ADS-B experts, it does not sound like there’s any obvious fix for this. Lower latency links between the radar sites and the ADS-B towers can help, but even that’s not a guaranteed fix. As we get closer to 2020 and more aircraft are equipped with ADS-B Out, it should get better. Until then, don’t panic every time a mysterious traffic target appears on your screen. But don’t ignore it, either – that way lies midair ugliness.
Just a quick “thank you” to everyone who has waited patiently for the past two weeks. The vacation in France was amazing and an excellent opportunity to recharge the batteries. I’ve already begun digging out and will be shipping all of the backorders on Monday. I’ll also be going through nearly 500 email messages. It may take a day or so, but I will respond to all of them.
One other item of business: I’m extending the deadline for the AHRS Challenge. If you’re interested, you now have until July 15. Please keep in mind that the entries will be tested in the order they were received. The first entry to meet the qualifications will receive the bounty, so get your entry in as soon as you have it tested and feel confident that it will work.
Many users have contacted me over the past few days with reports of a new issue. In flight (or when near an ADS-B tower) the data flow from FlightBox periodically stops. It typically happens after 5 – 10 minutes of operations, does not cause the wifi connection to drop, and is remedied (temporarily) by a disconnect / reconnect. It only impacts systems running UAT – users with 1090-ES systems in Europe and Australia are not impacted.
After a bit of research, it turns out that our friends at the FAA recently changed weather providers and that some of the new weather data is a bit dirtier (less scrubbed for format errors) than before. Specifically, the format of certain AIRMET messages causes a fault in the Stratux software that kills the process. The issue required a very minor tweak to the code to remedy.
My family and I are going to be out from June 6 – June 17 on a long-awaited vacation. We will be in France, exploring museums and enjoying awesome food. During this time, technical support will be limited email. Phone support will not be available. Orders placed between June 5 and June 17 may be delayed.
If you need any sort of support, please contact me ASAP. If you’re hoping for a FlightBox as a Father’s Day gift, please get your order in sooner rather than later.
Thanks in advance for your patience. We’ve had five solid months of FlightBox, and we’re already gearing up for Oshkosh. This break is going to really help recharge the batteries.
I’ve had a number of users ask for an easy way to keep their FlightBox from sliding around on the glare shield. I ran a number of prototypes on the 3D printer and eventually settled on a design that is both simple and effective. It includes a broad base with a layer of sticky open cell neoprene rubber that prevents the system from moving. It’s made from the same Botaron aviation-grade plastic as the FlightBox and can be left on the glare shield for those who take their FlightBox home at the end of each flight.
I’ve ordered 100 of these from the fabricator and should have them by the time we get back from vacation. They will sell for $26.50 plus shipping. We will start offering them as an add-on to the kits as soon as they arrive.
FlightBox user Mike Albertson sent in a great suggestion for anyone who has their remote GPS receiver installed in a hard to reach location. Rather than removing the GPS every time you want to take the FlightBox out of the airplane, use an inexpensive USB pigtail cable:
Unlike the other players in the ADS-B market, we don’t have a great deal of budget for marketing. That’s a large part of what makes FlightBox so much less expensive. If you happen to have a few minutes, please do us a favor. Download and print our flyer and hang it up on the bulletin board at your airport or in your EAA chapter hangar.
For the past several weeks I’ve been receiving reports from FlightBox customers of “missing traffic” – traffic observed visually or on some other system (TIS, TCAS) but not seen on their EFB application from ADS-B. In some cases the answer was a simple misunderstanding of the way ADS-B traffic currently works, but a subset of the reports sounded suspiciously like we had a problem – somewhere. Either a bug in the Stratux software that powers FlightBox, or something going on with the ADS-B network.
Yesterday morning I decided to figure out what’s going on – or at least give it my best shot. From my own experience and from customer reports, we have no problem seeing aircraft that are equipped with ADS-B Out. What is missing is the rebroadcast secondary surveillance radar data – the copy of “everything in your hockey puck” that you’re supposed to get if you have ADS-B Out. I figured that one of the following was happening:
A) Stratux was not getting the data because of poor reception
B) Stratux was receiving but ignoring ATC traffic data due to a bug
C) Stratux was not getting the data because the FAA towers are not sending it
D) Secondary surveillance radar was not picking up the traffic
To figure out which of the above is causing the problem I put together a simple, practical test.
I own an Appareo Stratus 2 which I use as the ‘control’ in my experiments. If the Stratus has data flow from a tower but FlightBox does not, it could be failure mode A – poor reception. If both devices connect to and receive the same data from the towers, that essentially rules out condition A. If the Stratus receives and displays traffic that is not visible to the FlightBox, the root cause might be failure mode B – a bug in the Stratux code. But if both devices display the same traffic, that rules out condition B. Failure modes C and D take a bit more effort to test.
My 1976 Grumman Tiger is equipped with FreeFlight Systems RANGR Lite UAT transmitter, and I regularly request status reports from the FAA. As of the last test (a few months ago) I was 100% ADS-B Out compliant. In other words, I should absolutely trigger the towers and receive a “puck” of ATC radar data for aircraft in my vicinity. To test if the ATC radar is making its way to the ADS-B network, I enlisted the help of my friend Larry. Larry flies an Arion Esqual – a precursor to the popular Lightning homebuilt – which has a standard Mode C transponder but no ADS-B Out. His job was to fly in relatively close formation with me to present a controlled traffic target.
Yesterday morning Larry and I took off from Roosterville (our home airport). I had two iPads running ForeFlight – one connected to the FlightBox and the other connected to the Stratus 2. I took off first and climbed to 1000’ AGL where both systems showed solid connection to two ADS-B towers. When Larry took off, I kept an eye on the iPads looking for him to appear on ForeFlight.
We flew south from Roosterville towards Liberty Landing. I let Larry stay roughly a half mile ahead and 200 feet above me. He did not appear on either iPad at 2,000′ MSL (~1100′ AGL). After roughly five minutes at 2,000′, I asked him to climb up to 3,000′. At roughly 2,500′ MSL, he appeared as an ADS-B traffic target 100’ above me an less than a mile head. Ok, it appeared to be working as expected.
To figure out the “bottom” – the lowest altitude at which it worked – I asked him to descend. He dropped off the screen at roughly 2,200′ MSL. We made a turn out towards the east and decided to see where he re-appeared. He began a steady climb that eventually topped out at 3,500′ MSL, without reappearing on either device. A quick check of the Weather tab showed that FlightBox was continuing to receive ADS-B data from the towers. Both the Stratus and the FlightBox continued to show both 1090-ES and UAT targets, but all appeared to be direct.
We flew for another 30 minutes at various altitudes. Larry only appeared again briefly, at 3,900′ MSL. On the off chance that we were too close – that ATC saw one target instead of two – we diverged to at least a mile separation. No joy. We contacted Kansas City approach to make sure that we being seen by radar. They had us 5-by-5 in exactly the right spot. Larry was at 3,900′ and I was below him at 3,200′. That would seem to eliminate the admittedly far-fetched failure mode D.
To review the facts:
Later in the day I went back up alone and spent some time in the airspace below the Kansas City class B directly along the approach path for runway 18 at MCI. I was within 10 miles of the ADS-B tower at Dearborn, Missouri and maintained a solid connection to it. I spent twenty minutes or so visually observing airliners arriving and departing above me. None of them appeared on either ADS-B system.
All of this seems to indicate that the cause of the missing traffic is failure mode C – the ADS-B network simply is not sending the data. The next question is, of course, why? My ADS-B Out transmitter was running. I should have had a puck that included Larry and the MCI traffic. Why wasn’t I able to see either?
Hard to say. It might be that the only radar that feeds into the ADS-B system is ARTCC (“Center”) and the altitude range we tested (2,000′ – 4,000’ MSL) was below the visibility “cone” for their radar. But they did have Larry as low as 2,500′ MSL for a while. It seems more likely that whatever gateway feeds ATC secondary surveillance radar data into the ADS-B network is flaky. Or that the software in the towers that calculate the “pucks” has a problem.
Whatever the cause, never assume that ADS-B provides a complete picture of traffic – even if you’re equipped with ADS-B Out. We’re still very much in a “see and avoid” world, and probably will be until at least 2020.
If you have two ADS-B In systems and a friend who’s willing to play along, please try to replicate my experiment. I would love to have enough evidence to take this to the FAA and get some kind of response.
As most of you know, we’re working on a hardware add-on for FlightBox that will include AHRS – the sensors and software necessary to drive a virtual attitude indicator or provide attitude data to a synthetic vision system. We’ve made good progress on this. Our hardware engineer has selected components and is currently working on the board design. What may not seem obvious is that the hardware is the easy part. Software is where the real challenge begins.
If you’ve ever played with a motion-sensitive game on a smartphone that may seem counterintuitive. A $100 Android phone can easily determine attitude, right? Well, yes – in some situations. It’s easy to accurately determine attitude when standing still or moving at a steady pace. It’s far more complicated when you take into account fixed-wing flight dynamics.
There are several products on the market today that claim to provide backup attitude, and they appear to do – as long as you’re flying straight and level. Drop into a 30° bank and the screen will show it – for a few seconds. But hold the turn for a few seconds and you’ll notice something disturbing: the display starts to level out. After another few seconds the display shows straight and level again – while you’re still turning. Huh?
It turns out that without some very clever software, the hardware sensors fall victim to the same effect that makes your inner ear such a bad attitude indicator – centrifugal force. In straight and level flight, your ear and the inertial sensors in the phone both detect one acceleration, that of gravity. When you’re turning, you are subject to two accelerations: gravity and the “false gravity” of centrifugal force. In VFR your brain compensates for this using your view of the horizon to override what your inner ear thinks is happening. To accurately display attitude the AHRS system needs something similar – a means of determining what sensory inputs it should ignore.
Many, perhaps most, off the shelf IMUs (inertial measurement units) – the core sensors of an AHRS – are built for use in cell phones or quadcopter drones. Neither of these are subjected to fixed wing flight dynamics. To build a real AHRS, the data from the IMU must be filtered to eliminate noise and must have the inertial (centrifugal) vector factored out of the readings. This is the real challenge of AHRS. Without this, you don’t have an AHRS – you have a toy.
Fortunately, there are people out there who are very good at the kinds of mathematics required and who could create a set of algorithms that combines data from an IMU and a GPS to provide a realistic attitude solution. Unfortunately, I am not one of those people. Thus the Open Source AHRS challenge:
Open Flight Solutions in partnership with Aerovie, Hilton Software, and DroidEFB is offering a bounty of $4,000 to the first developer or team of developers who can provide an open source AHRS implementation that can successfully return an accurate and timely orientation based on raw IMU (3 axis accelerometer, magnetometer, and gyroscope) and GPS data. Please see “The Rules” for details on the requirements and terms.
If you are a developer and you think you might be able to solve this, please jump in. If you know any developers who might be interested, please pass this along. We’re know that this problem can be solved in a way that makes GA safer and more affordable.
UPDATE: We’ve decided to extend the challenge through July 15, 2016.