Category Archives: General Tech Stuff

Flying Friday: the avionics brain transplant begins

I fly a 41-year-old airplane. Not that there’s anything wrong with that. As I’ve said before, there’s something to be said for mature technologies, and the economics of general aviation are such that there’s no chance I’ll be buying a new airplane any time soon when even an entry-level Cessna 172 costs north of $400K. Because new aircraft are so expensive, there’s a lively market in refitting and upgrading existing airframes. The engines, paint, interior, and avionics on an airplane can all be replaced or upgraded at pretty much any time, and the longevity of the basic airframe means that I can comfortably expect to get another 20-40 years out of my existing plane if I take good care of it.

With that said, newer airplanes have some major advantages, many of which (built-in cupholders, leather seats, ballistic recovery parachutes) aren’t available for my plane. After flying 706 for about a year, getting my instrument rating, and taking more and longer cross-country trips there were a few things that I wanted to add to make instrument flight easier and safer. My co-owner Derek and I spent a lot of time hashing out what we wanted vs what we could afford vs what we could live with. Here’s what we decided.

First off, we knew we’d have to meet Yet Another Unfunded Mandate. Starting in 2020, all airplanes that operate in controlled airspace (meaning the “Class B” and “Class C” airspace surrounding major airports and most cities) have to use a system called ADS-B. The FAA has delusions that ADS-B, which requires every aircraft to continuously transmit its GPS-derived position and velocity, will replace radar. It probably won’t, but that’s a topic for another post. Equipping a plane for ADS-B  requires two pieces:

  • a GPS system that uses the FAA’s Wide Area Augmentation System (WAAS) to provide high accuracy position and location data. The WAAS system combines satellite GPS data with position data from precisely surveyed ground stations to provide sub-meter accuracy.
  • an ADS-B Out transmitter that sends ADS-B data, including the WAAS GPS data

There are lots of ways to get these two parts, ranging in cost and complexity from “absurd” to “merely unpleasant.” The two most popular ways are to install a new transponder that includes a built-in position source or install a separate WAAS GPS and a little box that transmits ADS-B Out without touching your existing transponder. You can also get weather and traffic data using ADS-B In; that requires an ADS-B receiver and something to display the received data on. Right now, I use a Stratus receiver (the original, not the fancy 2S) and ForeFlight on an iPad for ADS-B In… but, as with many other government programs, there’s a huge catch. You get weather data for free, but you only see ADS-B In traffic if there’s an ADS-B Out-equipped airplane near you. This was supposed to be an incentive to get people to add ADS-B Out, but as a practical matter it means that ADS-B In is currently only useful for passive receivers like my Stratus in areas where there are already lots of ADS-B Out airplanes.

Next, we wanted the ability to use WAAS instrument approaches. I love the precision of ILS approaches, and use them whenever I can, but most airports don’t have an ILS, and those that do won’t typically have more than one. However, a growing number of airports have approaches that offer precision vertical and lateral guidance if you have a WAAS GPS. To be more precise (see what I did there?), we wanted to be able to fly LPV approaches so that we’d get precision vertical guidance for approaches where ILS equipment isn’t available. With WAAS equipment, you can also get an advisory glideslope, which gives you non-precision vertical guidance to help keep you from smashing into things.

Finally, we (well, mostly I) wanted to improve the autopilot’s ability to track instrument approaches. The approach phase of single-pilot IFR is a demanding and busy time, and it’s easy to make mistakes. Our existing autopilot can fly a heading, keep the wings level, and hold an altitude, but when you get to a complex approach, being able to let the autopilot turn the airplane based on GPS steering is very helpful because it frees up time and attention for vertical navigation, approach prep, and other critical tasks.

After a lot of back-and-forth, an immense amount of comparison shopping, and lots of head-scratching, Derek and I decided to send 706 to Sarasota Avionics to have the following installed:

  • An Avidyne IFD540 WAAS GPS. I preordered one of these back in 2012, well before I even had my pilot’s license, on the theory that I could always sell it later. The IFD540 is much more capable than the Garmin GNS530 and, to me, is easier to use than the Garmin GTN750. It’s also less expensive to buy, requires less expensive data subscriptions, and provides some much-needed market competition for Big G.
  • An Avidyne AXP340 transponder. The AXP340 transmits ADS-B Out, but it requires a separate WAAS GPS. In our case, that’d be the IFD540. There’s a whole complex mess of rules for which transponders can be legally used with which GPS position sources– basically, only combinations that have been certified by the manufacturer and registered with the FAA can be installed and used, even though other combinations may work just fine. Avidyne’s products are obviously certified to work with each other.
  • An Avidyne MLB100 ADS-B In receiver. Derek talked the Avidyne guys into giving us one of these for free if we bought the preceding two items. With this, the IFD540 can receive and display traffic and weather information. It is extremely useful to see this data overlaid on your primary map, especially because you can “rubber-band” your flight route to deviate around weather and traffic as needed.
  • A DAC GDC31 roll steering converter (which most people just call a GPS steering, or GPSS, adapter). Our autopilot, bless its heart, is the most analog device I think I currently own. It works by sensing voltage output from the directional gyro and course deviation indicator (CDI). To fly a particular course, you twist a knob on the DG to set the heading indicator, or bug, to the desired course; you can also have the autopilot track a VOR or even an ILS localizer, which it does by looking at the voltage used to drive the deflection on the CDI. One thing it can’t do, though, is track an actual GPS course. If the GPS route calls for you to fly a heading of 175 degrees, and the heading bug is set to 95 degrees, guess where you’re going? The GDC31 fixes that by adapting the digital steering commands output by the IFD540 into voltages that the autopilot can understand. I’ve used GPSS in other airplanes before and it’s a great experience– smooth, solid tracking with no “hunting” and accurate turn anticipation.
  • An Avidyne AMX240 audio panel. We’d been talking about replacing our ancient mono audio panel with a nicer unit that would give us better audio quality, and the marginal cost of adding the panel at the same time as the other equipment was considerably lower than doing it later.

The IFD540 + AXP340 combination gives us ADS-B Out, so we’ll be legal. The IFD540 + MLB100 gives us ADS-B In (with the added bonus that the IFD540 has wifi, so it will be able to feed all sorts of useful data to portable devices in the cockpit). Finally, the IFD540 + GDC31 gives us full two-axis autopilot coupling. I think, but haven’t verified, that it will also give us the ability for the autopilot to track altitude changes as expressed by the glideslope. The existing autopilot can track an ILS glideslope, and the IFD540 can provide a glideslope for LPV approaches (and an advisory glideslope for LNAV+V) so I think it should “just work.”

This seems like a huge list of expensive stuff (and it is)– one question that immediately comes to mind is “why bother with all this stuff when you could just use an iPad?” The problem is spelled F-A-A. First, there are no portable ADS-B solutions that are approved to meet the 2020 mandate in Part 23 aircraft. That’s a fancy way of saying that an experimental or homebuilt airplane can use equipment that’s not approved for factory-built airplanes. That also wouldn’t give us WAAS approach capability; even though there are portable WAAS receivers (including this watch!) you can’t use them to fly approaches. While there’s been lots of flailing in the aviation press about the need for cheaper, better-integrated ADS-B solutions, it’s also true that we’re getting a lot of other capability out of the upgrade that we’d miss if we went with a simpler ADS-B-only installation.

Along with the avionics themselves, of course, there are lots of little things– antennae, cables, and so on– that have to be installed and tested. That’s why we expect the upgrade to take an eye-popping four weeks– and that’s assuming everything goes well. Stay tuned!

1 Comment

Filed under Aviation, General Tech Stuff

Garmin Fenix 3 drops data from Stages power meter

I’ve been ignoring this problem for a while, hoping that it would be fixed in a firmware update, but it persists, and I finally got aggravated enough with it to write this post (and to engage Garmin support). The problem is simple: my Garmin Fenix 3 triathlon watch will not reliably record data from the Stages power meter I have on my bike.

A quick digression: there are two major standards for wireless exercise sensor connectivity, Bluetooth Low Energy (aka BLE and Bluetooth 4.0) and ANT+. Some devices support one or the other, and some devices support both. For example, my heart rate monitor (the excellent Scosche Rhythm+) simultaneously transmits both ANT+ and BLE signals, but my Wahoo speed/cadence sensor is ANT-only. When I ride, I usually use two devices: my old iPhone 4 on the handlebars, in a Wahoo case that has a built-in ANT+ adapter, plus my Fenix 3. The iPhone is too old to use BLE, and turning on BLE on the Fenix 3 dramatically drops its battery life, so I’m using ANT for all the sensor data. Having two devices means that sometimes I forget to start or stop one device or the other at various points, so I often have mismatched data between the two.

A picture will illustrate the problem most clearly. When I use the Fenix 3, I end up with ride data that looks like this:

Bad power data is bad

As you can see, the power graph has a few spikes with lots of flats– and an average power of only 23W. (I’ll get to why the average is important in a minute). By contrast, here’s what the ride looked like when captured with the Strava app on my iPhone 4. Note that the power data much more closely tracks the speed, cadence, and HR data.

That's more like it

So why is this important? First of all, as a techie, it annoys me when two things that are supposed to work together won’t. More importantly, I actually use the power data from these rides in two ways. While I’m on the bike, I use it to gauge and adjust my level of effort. For example, yesterday’s ride was pretty windy, so I tried to hold a steady 190-210W while riding into the wind, keeping my level of effort constant and accepting whatever speed that gave me. After a ride, my coach and I use the power data to plan my recovery time and to identify areas where I need more practice (e.g. climbing hills). Having inaccurate or dirty data makes both of these uses impossible.

The Stages power meter support FAQ suggests moving the watch around, but I haven’t tried that yet. My troubleshooting efforts so far have been limited to changing the battery in the Stages and making sure the Stages and Fenix both have the latest firmware. I’ll see what Garmin support has to say. Hopefully they have a magic fix; I have a very early-model Fenix 3 so maybe they’ve made some improvements since launch. Until then, I’ll keep recording each ride twice and keeping the cleanest data.

4 Comments

Filed under FAIL, Fitness, General Tech Stuff

iOS charging woes

I have been meaning to write a long article about why I moved from Windows Phone back to iOS, and the good and bad parts of the transition, but I’ve been too busy to bother. I do have time for a quick rant, though: damn, I am tired of having charging problems.

See, Apple has this logo certification program called “Made for iOS.” Join it, and your devices (which might include chargers, cables, etc) can be certified as compatible with Apple devices, and you get a cool logo. Sure, it costs you a few bucks to sign up and get certified, but it’s cheap insurance. Nice line of chargers and cables you’ve got there. It’d be a real shame if anything happened to it.

On my last two road trips, previously-working cables have suddenly started producing the infamous “this accessory may not be compatible” message. Once that happens, it’s game over. The phone (or iPad) will no longer charge from that cable. If you happen to be on a road trip, well, too bad. Luckily I had a spare, but I am now nearly out of working cables, and there’s no guarantee that the name-brand cables I bought from Amazon (all of which were from vendors who claimed to be MFi certified) will keep working. Of course, because it’s Apple, there’s no way to override this dialog, ignore it, or force the device to talk to a tainted cable– once the cable is blacklisted, it’s no longer usable with that device at all.

The worst part? I’ve seen many reports of this happening to people who bought cables and chargers from the Apple store. Since I am unlikely to ever do that I’m not too worried, but I hate the precedent, and the inconvenience factor has been pretty stunning compared to my easy prior life of using micro USB cables with my Lumias. While I understand Apple’s desire to protect the IP embodied in the Lightning interface, and while I even believe that part of the rationale behind blocking non-certified devices is to prevent bad customer experiences, the whole thing has left an unpleasant taste in my mostly-discharged battery.

5 Comments

Filed under FAIL, General Stuff, General Tech Stuff

Fixed: Surface Book doesn’t recognize docking state

I got a shiny new Surface Book on Monday and started using it immediately… more specific notes on it later when I have more time. I ran into a problem today, though, and wanted to document what I found.

Symptom: the touchpad and keyboard don’t work. The clipboard switches to tablet mode (if you’ve enabled automatic switching). You can’t use the base unit’s USB ports. The taskbar “undock” icon shows that the base is undocked.

Cause: beats me.

Resolution: boot into the system BIOS by turning the machine off, then holding the power and volume-up keys for 15 seconds. When you get into the BIOS, just exit BIOS setup and the machine will reboot normally. There’s a thread here that outlines the exact procedure.

Overall, I love the machine: the form factor, build quality, screen resolution, performance, and trackpad are all superb. I expect this kind of temporary hiccup, so it hasn’t put me off at all.

2 Comments

Filed under General Tech Stuff

Windows Hello and Microsoft Passport intro

I’ve been working on a white paper explaining how Windows Hello and Microsoft Passport work together in Windows 10– it’s a really neat combination. Over at my work blog, I have a short article outlining what Hello and Passport are and a little about how they work (plus a bonus demo video). If you’re curious, head over and check it out.

Leave a comment

Filed under General Tech Stuff, Security

The difference between Suunto cadence and bike pods

I spent way too much time trying to figure this out today, so I’m blogging it in hopes that the intertubez will make it easy for future generations to find the answer to this question: what’s the difference between a cadence pod and a bike pod according to Suunto?

See, the Suunto Ambit series of watches can pair with a wide range of sensors that use the ANT+ standard. You can mix and match ANT+ devices from different manufacturers, so a Garmin sensor will work with a Suunto watch, or a Wahoo heart-rate belt will work with a Specialized bike computer. I wanted to get a speed and cadence sensor for my bike. These sensors measure two parameters: how fast you’re going and how rapidly you’re pedaling. (This is a great explanation of what these sensors really measure and how they work.) Ideally you want a nice, steady cadence of 75-90 rpm. I knew I had a variable cadence, and I wanted to measure it to get a sense for where I was at.

I ordered a Wahoo combined cadence/speed sensor from Amazon and installed it on the bike, which was pretty straightforward. Then I paired it with the watch using the “bike POD” option. (Suunto, for some reason, calls sensors “PODs”). That seemed to work fine, except that I wasn’t getting any cadence or speed data. But I knew the sensor was working because the watch paired with it. I tried changing the sensor battery, moving the sensor and its magnets around, and creating a new tracking activity that didn’t use GPS to see if I got speed data from the sensor. Then I thought “maybe it’s because I didn’t pair a cadence pod”, so I tried that, but no matter what I did, the watch refused to see the Wahoo sensor as a cadence sensor.

Here’s why: to Suunto, a “bike POD” is a combined speed/cadence sensor. A “cadence pod” is for cadence only. Like Bluetooth devices, each ANT+ device emits a profile that tells the host device what it is. That’s why the watch wouldn’t see the sensor, which reported itself as a combined cadence/speed unit, when I tried to pair a cadence pod. After I figured that out, I quit trying to pair the cadence pod… but I still didn’t get speed or cadence data.

The solution turned out to be simple. For some reason, in the cycling sport activity, the “Bike POD” sensor was unchecked, so the watch wasn’t reading its data stream during the activity. I don’t remember unchecking the box, but maybe I did. In any event, once I checked the “Bike POD” box and updated the watch, I immediately started getting cadence and speed data, so I set out for a ride.

NewImage

Hint: if you uncheck any of these boxes the watch will never, ever pay attention to that sensor

I thought it was a pretty good ride from a speed perspective, even though I took a new route that had a number of hills– I had some trouble with that. But look at my cadence… you can see that it definitely needs work. Sigh. One of the nifty things about Suunto’s web site is that it shows vertical speed when you point at cadence data, so I could see where I was struggling to get up hills (meaning I needed to change gears) or loafing when going downhill. Just one more thing to put on my to-fix list…

NewImage

19 Comments

Filed under Fitness, General Tech Stuff, HOWTO

Exchange Server and Azure: “not now” vs “never”

Wow, look what I found in my drafts folder: an old post.

Lots of Exchange admins have been wondering whether Windows Azure can be used to host Exchange. This is to be expected for two reasons. First, Microsoft has been steadily raising the volume of Azure-related announcements, demos, and other collateral material. TechEd 2014 was a great example: there were several Azure-related announcements, including the availability of ExpressRoute for private connections to the Azure cloud and several major new storage improvements. These changes build on their aggressive evangelism, which has been attempting, and succeeding, to convince iOS and Android developers to use Azure as the back-end service for their apps. The other reason, sadly, is why I’m writing: there’s a lot of misinformation about Exchange on Azure (e.g. this article from SearchExchange titled “Points to consider before running Exchange on Azure”, which is wrong, wrong, and wrong), and you need to be prepared to defuse its wrongness with customers who may misunderstand what they’re potentially getting into.

On its face, Azure’s infrastructure-as-a-service (IaaS) offering seems pretty compelling: you can build Windows Server VMs and host them in the Azure cloud. That seems like it would be a natural fit for Exchange, which is increasingly viewed as an infrastructure service by customers who depend on it. However, there are at least three serious problems with this approach.

First: it’s not supported by Microsoft, something that the “points to consider” article doesn’t even mention. The Exchange team doesn’t support Exchange 2010 or Exchange 2013 on Azure or Amazon EC2 or anyone else’s cloud service at present. It is possible that this will change in the future, but for now any customer who runs Exchange on Azure will be in an unsupported state. It’s fun to imagine scenarios where the Azure team takes over first-line support responsibility for customers running Exchange and other Microsoft server applications; this sounds a little crazy but the precedent exists, as EMC and other storage companies did exactly this for users of their replication solutions back in Exchange 5.5/2000 times. Having said that, don’t hold your breath. The Azure team has plenty of other more pressing work to do first, so I think that any change in this support model will require the Exchange team to buy in to it. The Azure team has been able to get that buy-in from SharePoint, Dynamics, and other major product groups within Microsoft, so this is by no means impossible.

Second: it’s more work. In some ways Azure gives you the worst of the hosted Exchange model: you have to do just as much work as you would if Exchange were hosted on-premises, but you’re also subject to service outages, inconsistent network latency, and all the other transient or chronic irritations that come, at no extra cost, with cloud services. Part of the reason that the Exchange team doesn’t support Azure is because there’s no way to guarantee that any IaaS provider is offering enough IOPS, low-enough latency, and so on, so troubleshooting performance or behavior problems with a service such as Azure can quickly turn into a nightmare. If Azure is able to provide guaranteed service levels for disk I/O throughput and latency, that would help quite a bit, but this would probably require significant engineering effort. Although I don’t recommend that you do it at the moment, you might be interested in this writeup on how to deploy Exchange on Azure; it gives a good look at some of the operational challenges you might face in setting up Exchange+Azure for test or demo use.

Third: it’s going to cost more. Remember that IaaS networks typically charge for resource consumption. Exchange 2013 (and Exchange 2010, too) is designed to be “always on”. The workload management features in Exchange 2013 provide throttling, sure, but they don’t eliminate all of the background maintenance that Exchange is more-or-less continuously performing. These tasks, including GAL grammar generation for Exchange UM, the managed folder assistant, calendar repair, and various database-related tasks, have to be run, and so IaaS-based Exchange servers are continually going to be racking up storage, CPU, and network charges. In fairness, I haven’t estimated what these charges might be for a typical test-lab environment; it’s possible that they’d be cheap enough to be tolerable, but I’m not betting on it, and no doubt a real deployment would be significantly more expensive.

Of course, all three of these problems are soluble: the Exchange team could at any time change their support policy for Exchange on Azure, and/or the Azure team could adjust the cost model to make the cost for doing so competitive with Office 365 or other hosted solutions. Interestingly, though, two different groups would have to make those decisions, and their interests don’t necessarily align, so it’s not clear to me if or when we might see this happen. Remember, the Office 365 team at Microsoft uses physical hardware exclusively for their operations.

Does that mean that Azure has no value for Exchange? On the contrary. At TechEd New Orleans in June 2013, Microsoft’s Scott Schnoll said they were studying the possibility of using an Azure VM as the witness server for DAGs in Exchange 2013 CU2 and later. This would be a super feature because it would allow customers with two or more physically separate data centers to build large DAGs that weren’t dependent on site interconnects (at the risk, of course, of requiring always-on connectivity to Azure). The cost and workload penalty for running an FSW on Azure would be low, too. In August 2013, the word came down: Azure in its present implementation isn’t suitable for use as an FSW. However, the Exchange team has requested some Azure functionality changes that would make it possible to run this configuration in the future, so we have that to look forward to.

Then we have the wide world of IaaS capabilities opened up by Windows Azure Active Directory (WAAD), Azure Rights Management Services, Azure Multi-Factor Authentication, and the large-volume disk ingestion program (now known as the Azure Import/Export Service). As time passes, Microsoft keeps delivering more, and better, Azure services that complement on-premises Exchange, which has been really interesting to watch. I expect that trend to continue, and there are other, less expensive ways to use IaaS for Exchange if you only want it for test labs and the like. More on that in a future post….

5 Comments

Filed under General Tech Stuff, UC&C