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.
This isn’t my first entrepreneurial rodeo, but it’s been a while. I’ve spent the past several weeks re-learning several lessons. The first of these is that platform changes are never as easy as you expect. We recently switched from using the Raspberry Pi 2 to the new Raspberry Pi 3. In theory the change should have been quite simple and a small net positive for both users and Open Flight. I ordered two of them the day they were released and put more than 25 flight hours on them before we made the switch. But – as anyone in the IT field knows – just because something works perfectly on one system (or two) is no guarantee that it will do the same on all systems – even theoretically identical semi-embedded devices like the Raspberry Pi. I re-learned the hard way that a larger sample is mandatory.
At the end of April we sent out the first 75 kits based on the Pi 3. We had approximately 25 of them mysteriously fail – no wifi. After a weekend of research it turned out to be an incredibly subtle change in the shell script command interpreter on the new Linux operating system. A script that had been working fine for months on the Pi 2 failed to work correctly on some of the new Pi 3s. A somewhat longer power cable that we shipped with the Pi 3 kits exacerbated the problem significantly. I spent the next several days writing and testing a new script. We tested it on 10 different Pi 3s from two lots. We re-imaged 250 SD cards, built up over 50 “recovery packs”, and shipped them out to anyone who had problems Pi 3. A week later we had almost everyone up and running. (If you’re not, please contact me ASAP.)
The lesson is to never, ever take for granted that something works. If we make another platform change in the future, I will round up as many beta testers as I did for the original FlightBox launch early in the year. We had close to a dozen people test-flying the first build, and we had very little in the way of trouble with it. Lesson learned. Sincere apologies to anyone who was bit by this bug.
For everyone who’s been waiting for a remote GPS option, the wait is over. We have 100 remote GPS units in stock and more on order. You can order them here. The list price is $35, but I am offering a one-time $10 discount to all existing FlightBox owners (anyone who has completed an order prior to to today). Please email me for your personal discount code. Before you order, please note that we’re working on a complete “remote kit” that includes the GPS as well as cables and a suction cup window mount for the ADS-B antennas. If you want the full remote solution, wait another few weeks you can save yourself a bit on shipping. The $10 discount will apply to that as well.
The remote GPS will require a bit of minor surgery on your FlightBox case. You may have noticed the U-shaped partial cut at the end of the box near the USB risers. To use the remote GPS you will need to cut out the “U” to make room for the USB plug from the GPS. I hope to publish a video showing how this is done in the next few days. The plastic is thin and it is quite simple to make the cut with an Xacto knife.
We’ve made the decision to phase out the VK-172 GPS module that we’ve been shipping since we launched. When they work, the VK-172s are great little GPSs, but we’ve had enough marginal performers that it makes more sense to remove it and instead offer an optional product that has top-notch quality, stateside technical support, and an RMA program. (Sending products back to China is… problematic.) We’re dropping the price of the dual band kit from $250 to $240. The remote GPS will be available as a $35 add-on, which makes it a bit more expensive than it is today – but only if you want or need the GPS feature.
(Note that any outstanding orders placed prior to today will go out with the internal VK-172. Anyone with an outstanding order qualifies for the $10 discount on the remote GPS.)
At the same time we are adding an option for high gain antennas. These are 978 MHz and 1090 MHz tuned antennas that are 1/2 wave, rather than the 1/4 wave of the stock antennas. They significantly increase the receiving power (gain) of the system, which can be useful in areas with limited ADS-B coverage. They’re rather large (about twice the size of the stock antennas) but well worth it if you’re a long way from towers and need to boost the signal. They will add $10 to the cost of a kit.
The arrangement I’ve worked out with the manufacturer only allows us to sell them as part of a kit, but they are available on Amazon. (As of this moment they are out of stock. The seller assures me that more are on the way.)
I probably get five emails a week asking about the state of the AHRS project, so here’s an update. We’re making good progress. We have the initial hardware design complete and hope to get our first round of prototypes later this month. We are still working towards Oshkosh as a launch target. I will have a blog post dedicated exclusively to AHRS next week, so please check back.