Vance Harral

That's not exactly correct, but it gets a little complicated. The G5 absolutely has a built-in GPS, but its purpose is only to provide positional data over time to allow the instrument to correct for gyro drift. It is not designed to provide nav information or data for a moving map. In particular, I'm not aware of any way to configure a G5 to output its GPS data to another device via its CANBUS or RS-232 outputs. The G5 installation manual allows you to provide GPS data to the G5 for drift connection from another device instead of using the built-in GPS receiver, e.g. you can wire an RS-232 output from a GTN 650 to the G5 and leave the internal GPS disabled. A lot of installations are set up this way because it's less expensive to run the RS-232 connection than it is to purchase and install the additional GPS antenna that is otherwise required. It's been a while since I looked at the installation manual, but my recollection is that if you're super paranoid, you can connect both the RS-232 setup and also an external GPS antenna, and set up the G5 to fail over from one to the other source. Again, though, this stuff only has to do with gyro drift correction, nothing to do with navigation. It's also my recollection that loss of GPS data won't cause your G5 to kill you with totally invalid attitude information if GPS signal is lost. It's still good enough to keep the greasy side down, it just doesn't quite meet certification accuracy requirements without GPS correction.

I think the ubiquitousness, relative low expense, and pretty good reliability of EFB tablets has rendered a second, full-featured NAV/COM/GPS to be largely uninteresting relative to what one might otherwise spend money on. Nowhere is this reflected more than in the flight school airplanes I fly, none of which are equipped with a second GPS, and a couple of which don't even have a second ground-based NAV radio, just like you note. My main gripe about this has nothing to do with safety, only with training. Teaching VOR navigation is challenging enough when manipulating the hardware consists only of "tune this frequency, turn that CDI knob". Increasingly, it's "click the cursor button to select the nav tuner, tune the nav frequency, enter a series of clicks/rotations on the HSI to select NAV indication, then more clicks/rotations to select a course". I try to be good natured about it, and preach the value of the redundancy of ground-based nav. But it's increasingly clear to me that the students simply don't want to do it, and just hope GPS is always going to be there, on their iPad if not on their panel-mounted equipment. And I think the reason it's increasingly hard to beat this attitude actually has less to do with the theory of VOR navigation, and more to do with how much of a PITA it is to set up the instrumentation to actually show VOR/LOC course guidance.

Something often overlooked in these discussions is the temperature tolerance of the pilot. One of my friends had an airplane on the ramp in Nebraska over the Christmas holidays, in below zero (Farenheit) temps. The airplane was fine, but the pilot wound up with frostbite on two finger tips due to a hole in his glove that he didn't think was a big deal. Your decision making won't be as good if you're miserable, of course. And if you bundle up enough not to be miserable, you may find you have some minor difficulties strapping in, reaching various controls, etc. Having said that, how cold you're willing to start the engine isn't really a black/white thing for a single flight, but more of a long-term wear and tear issue. If your battery/starter combination is strong enough to turn over the engine and get it started, you're not going to destroy your engine and gyros in a single cold-weather operation, even in fairly brutal conditions. As such, a once-every-few-years special missing during a brutal cold snap isn't really ever a "no go", provided the pilot can take it and the starter can crank the engine. All this good information you're getting about minimum temps, pre-heat, gyros, etc. is based on keeping the machine healthy across frequent cold weather ops.

The GI-106A definitely has flags for both lateral and vertical needles. You can see them in the picture at the top of the Garmin product page for the unit: https://www.garmin.com/en-US/p/6435/ The later GI-106B design doesn't have flags, it instead has the "disappearing needle" behavior you describe, and that I agree is superior: https://www.garmin.com/en-US/p/552213/ There is definitely an opportunity for confusion if you fly multiple GI-106 equipped airplanes and don't realize there is a difference between the "A" and "B" models.

This attitude is winning lately, and I can't really argue with it. But no one seems to know where the next generation of Senior Developers is going to come from, when there's no time/patience/money for Junior Devs. That's a future problem to be solved by someone else, I guess. In the mean time, the employment landscape for legions of young software developers is a wasteland of filing literally thousands of applications (because both the producers and the consumers of the applications are using AI, natch), who are drowning in bitterness. On the other hand, I'm sure that 50 years ago someone claimed there eventually wouldn't be anyone with enough machine language programming skill to write compilers. Hasn't happened yet.

Meh... that's debatable. I'm not a Luddite about autopilots ,and I'm not saying you're outright wrong. I've had good IFR training experiences with students in autopilot-equipped airplanes. If it's there, I incorporate it early and often in the training (including failing it, though honestly I get to teach plenty of autopilot "failures" that are simply pilot error in using it). And I am definitely not saying an autopilot isn't both an operational and a safety advantage in real-world IFR flying. I'm just not convinced it's "immensely helpful" during training as you say, and I don't really think it's critical for the OP to get one in his airplane right now. My experience may be biased by easy access to a pretty good AATD, which I regularly put IFR students in when we're going to do intensive cognitive stuff: first time making them fully responsible for an entire instrument approach sequence with no help, introducing new types of approaches, etc. The "pause" button in the AATD is incredibly helpful during those exercises, and I guess a reliable autopilot is sort of an equivalent if you're limited to doing all your IFR training in a real airplane.

Hmmm... make sure you get a PIREP from some of their customers. It would be quite unusual in the current market to get a multi-component avionics project in the shop door in two weeks and out in just two more. Not impossible, of course. But I'm very skeptical of this estimate, and avionics shops are generally notorious for missing deadlines. Whatever you decide to do about equipment, enjoy the training!

Have you considered doing no upgrades at all until you complete your IFR training? Perhaps unpopular opinion: spending a lot of money on avionics upgrades at the start of IFR training isn't a great idea. For one thing, it might take as long or longer to get a shop to complete the upgrade than it would take to complete your training in your already airworthy, IFR-capable airplane. And as you've already observed, you don't know what you don't know yet. Better to get a bunch of hours under your belt before upgrading, because while there are a few factual truths about equipment and capability, a lot of resto-mod panel design boils down to personal preference. The panel you already have is adequate to train for and pass the instrument rating practical test, at which point you'll be proficient in one airplane. Perhaps the most proficient you'll ever be for the rest of your life. That's a great place to be when thinking about what kind of instrument flying you're really going to do, and what equipment you want to feel safe and comfortable while you do it. Some ugly truths to consider, from an old CFII: A lot of pilots who start instrument training never finish. Some pilots who finish instrument training decide never to fly in IMC, particularly those based in areas of the country where there isn't much piston-single-flyable IMC. Some pilots who fly IMC limit themselves to "gentleman's" IFR conditions, e.g. punching through a thin layer that's a couple thousand feet above the ground. Some pilots with instrument ratings and fancy panels are actually quite bad at basic instrument flying, and are hindered as much as helped by all the gizmos they've got in the panel. I don't say these things to discourage you, just to inject a dose of realism before you break out the wallet. Prove to yourself you have the perseverance to complete the rating. After (or while) you do, lean on friends and/or rentals and/or AATD simulators to gain experience with additional equipment. Then, with rating in hand, decide what kind of IMC flying you're actually going to do. At that point, you'll be in pretty good shape to think about upgrades.

In most cases it's a lot less Orwellian. The industry is just full of engineers who both want to "do something", and are also convinced they're some of the smartest guys in the room. They're often led by managers who are willing to let them try things, because that's how you learn. In some cases you learn not to touch stuff, but to be fair it's also how you learn to maintain stuff when it breaks due to underlying changes in the hardware, O/S, or whatever. I've been both the developer and the manager in my career, and even having seen what I've seen, it's still challenging to leave things alone. It's also very tough to recruit for a team with a mission statement like, "Please maintain this existing, well-loved software, exactly like it is", so efforts to do so often cause the app to fall below critical support mass. Combine that with the nature of most engineers to (1) tinker; and (2) be introverted enough to avoid asking others' opinions about what's best, and you wind up stacking the deck against simply letting good things stay status quo.

Probably more accurate to say it's "largely" about security. Long, boring, nerdy post follows... Speaking as a grifter er, "development specialist" who works in the software industry, much of the public just doesn't (nor should they be expected to) think about compatibility test matrices and the need to keep them finite. It's all well and good to say a particular piece of hardware or software is "backward compatible", but no successful software company actually relies on that. They all employ a Regan-esque "trust but verify" strategy. Every change to the product must be tested on every combination of supported hardware and software. Let's use Foreflight as an example. Latest production Foreflight is 17.11, presumably 17.12 is in the works. Latest production iOS is 26.2. Foreflight has a test suite they use to prove functionality, and they're certainly running it on iOS26.2 and Foreflight 17.12.XXX as I write this. Well, you've got to run the 17.12.XXX testsuite on iOS26.1 too, because not everyone has upgraded to 26.2, and it's not a winning strategy to force everyone to upgrade to the latest iOS on every Foreflight update. So the verification process has two dimensions: Foreflight version and iOS version. Fine. Actually, there's a third dimension because Foreflight's version history is branched rather than linear. 18.XXX versions are co-developed simultaneously with 17.XXX (and 16.XXX and so on), and customers expect all of them to work. Actually, there's a fourth dimension because iOS version history is also branched rather than linear. iOS 26.xxx is co-developed with iOS 18.xxx and other iOS 18.xxx releasess. Actually, there's a fifth dimension because different iPads have slightly different CPUs and other hardware, and sometimes that triggers corner-case problems. Actually, there's a sixth dimension because Foreflight has to run on iPhones as well as IPads. Actually... well, you get the idea. There are surely additional dimensions I don't know about. Software validation engineers at Foreflight have almost certainly automated test matrix management. They don't have to write a whole new testsuite or hire a new person to push a particular button every time a new test element or test dimension is added. But... they do have to buy, set up, install, and maintain the additional test hardware and operating systems. They also have to hire more (or smarter) people to write the meta-software that reviews test results, identifies all the failing cases, filters "real" failures from nuisance failures (e.g. someone tripped over the power cord of one of the test devices), triages the failures, doles them out to individual developers for debug, etc. At the modern pace of new hardware, operating system, and software development, this rapidly gets out of control, because there's only so much test budget and manpower to go around. The obvious solution is to roll supported combinations off the back end more and more frequently. But since the manufacturers know this is a bitter pill for the public to swallow, they'll happily imply the changes are out of their control. And "security" is a good fence post to lean on, because it's not really a lie - there are indeed new threats all the time that exploit gaps in older hardware and software. Having said that, as an decaying engineer with retirement on the horizon, I'm aging out of my enthusiasm for it, and I certainly don't mean to imply anyone should be sympathetic to the test matrix problem I blather about above. The admittedly impressive technology that allows for continuous updates to everything in the universe has a dark side, which is that dumb updates that do as much harm as good are a lot more likely to make their way to the public than in the "old days". It also damages the whole concept of documentation, help, and support, because so much of the information about your product applies to a version of the product you are not running. I've tired of it, and the cynic in me feels like much of modern software development is just a jobs program for wanna-be tech bros who aren't actually very good at their job. And, uh... stay off my lawn too!

Anything's possible, but it's worth talking about accuracy vs. precision of the system that's showing you RPM. I don't know what a "UPB-16" tachometer is. Is that a modern system designed this century, or something akin to the old Electronics International R1 that was designed in the early 1990s? To put some nerd numbers on it, for a 4-cylinder engine with the world's greatest P-lead sensor (the P-lead signal is quite noisy) 10 RPM accuracy requires resolving pulse edge differences on the order of 50 microseconds (2700 RPM on a 4-banger is 5400 P-lead pulses per minute, or one every 11,111 microseconds; at 2710 RPM it's every 11,070 microseconds). A CGR-30 or GI-275 EIS with a modern microcontroller and A/D system is almost certainly sampling at much higher than 25 microsecond intervals (need at least 2x oversampling), but it's less likely to be true for something designed decades ago, just based on my general knowledge of hardware available at reasonable costs for consumer applications over the years. A lifetime spent in the digital design industry has shown me several examples of manufacturers deliberately conflating precision with accuracy, and it's left me skeptical that the 10 RPM (or in some absurd cases 1 RPM) indications on digital tachometers are meaningful, especially not with older hardware. Speaking for myself, I start paying attention when max indicated RPM differs from redline by more than 50 RPM or so. I wouldn't personally spend energy chasing down a 30 RPM difference, and definitely not a 10 RPM difference. But to be clear, I don't know what tachometer you actually have, or what digital guts are in it. It's certainly possible your numbers really are accurate enough to be interesting.

This is hyperbolic. Per the M20C POH performance tables, the difference between 2600 and 2700 RPM at the same manifold pressure is about 2% across a broad range of takeoff altitude and temperature. 2640 RPM is in the middle of that, so call it a 1% degradation in power developed, assuming all gauges are perfectly precise and perfectly accurate. That number is so small as to be completely lost in the noise for actual takeoff performance. Unrelated factors such as density altitude, runway slope, minor cam lobe wear, dirty air filter. etc. are all going to have a much greater effect than 2640 vs. 2700 RPM. Bear in mind also that even if this is "fixable" with a governor adjustment in the field, you must have realistic expectations about what can be achieved. Odds are that tweaking the max RPM adjustment screw in situ is not going to give you exactly 2700 RPM, but rather something like 2680 or 2710 (with a flashing red indication on your G3X), etc. Such is the curse of modern digital instrumentation. Be careful what you try to fix, lest you create a bigger problem than was there in the first place.

I'd advise moderate caution here, as over the history of flight simulation there have been numerous simulators that don't model post-stall characteristics very well. I don't have a rundown on specific, modern simulators, such as the Prepar3D software used in the Redbird devices, maybe they are very good. But I'm old enough to have played with some sims that just sort of "give up" once the simulated aircraft stalls, and seem to assume normal recovery technique is applied at the moment of stall rather than modeling what's actually happening. If the goal is to set muscle memory as guided by an instructor, what the simulator actually does/shows may not actually be all that important. But if the goal is to see what a spin looks like, I think a better bet is just to look at the numerous youtube videos from the cockpit, of real spins in real airplanes.

Correct, but a complete loss of oil pressure (likely leading to the engine seizing) is not the most common engine failure mechanism. If the engine is windmilling and you've got any oil at all in the system, the governor is going to be at least somewhat effective in moving the prop toward low pitch. This is especially true in the most common engine failure mode - running out of gas. Having said that, it's somewhat unlikely the glide ratio improvement from moving the prop to coarse pitch is going to be the difference between a successful and unsuccessful engine-out scenario. Survivability is almost entirely governed by your ability to pick a suitable landing spot within a very conservative gliding distance, and maneuver the airplane to arrive in that spot at minimum energy using a combination of flight path, drag devices, slips, etc. You won't be able to do that unless you practice it at least occasionally. And you won't practice it if you're afraid of damaging the engine doing so, see my rant above.

Sigh. I guess I can sorta sympathize with these kinds of questions when the cost of an engine overhaul is $50K for a simple Lycoming 4-cylinder and double that for a high-end Mooney. But there's a lot of bad risk management information circulating out there. Data point: the case on our IO-360-A1A was last split in 1991. We bought it in 2004, now on 22nd year of operation since purchase, with 2700+ hours and 30+ years since that 1991 case split. In our partnership we have never, and I mean never, spent one minute worrying about the prop driving the engine or shock cooling. Every pilot in the partnership has performed "stressful" commercial maneuvers on the regular: not just power-off 180s, but full-power Chandelles followed immediately by steep spirals at idle. We don't pre-heat unless it's below 20 degrees, and when we do we just use a simple space heater and blanket. We don't tape off the oil cooler in the winter or constantly fiddle with the cowl flaps to achieve "optimum" cylinder head and oil temps. We don't agonize over oil change intervals or what type of oil to use, yadda, yadda, yadda. The worst incidents we've had throughout these decades of operation involve oil leaks in the engine and prop governor, and I think it's essentially guaranteed those are a result of calendar time (seals and hoses drying out) rather than operating technique. In the mean time, as an instructor at the local flight school, I watch a fleet of 4-cylinder Lycomings get abused on the daily: cold engine starts on the ramp by inexperienced students with the engine immediately going to 1500+ RPM. CHTs well in excess of 400 degrees in the summer followed immediately by idle-power engine-out training. Engines on the twin being cycled from full power to idle (or shutdown altogether) over and over and over again during engine failure training and Vmc demos, and so on. None of these airplanes are falling out of the sky, and all of them are making TBO (or in some cases well beyond). My point is not that we're right to operate our engine "abusively" and others are wrong to be more cautious. I'm open to the idea that on a statistical basis, careful operators might get a few more hours out of an engine before it starts making metal or the governor fails or whatever - particularly on airplanes that are not flown frequently. But it just drives me nuts that every time someone talks about training techniques that have real, tangible benefit - including being ready an actual engine failure - the engine worrywarts show up and imply that you'll destroy your engine if you don't treat it like a Faberge Egg. In my flight instruction work, it's not uncommon for me to come in contact with owners who simply don't want apply sufficient power in a stall recovery, won't practice engine out scenarios, etc., for fear of damaging that precious engine. These folks are not doing themselves any favors, and I have to have awkward conversations with them about their misplaced fears. So please, my brothers and sisters of the skies. For the love of all that is holy. Stop worrying so much about "abusing" your engine. A lot of you are overly focused on tiny, almost meaningless risks, at the expense of actually operating and fully understanding your power plants.

@PT20J beat me to it, but I was writing that If you want to feel like you're getting your full money's worth out of the blue knob, try playing with it in an idling glide. Specifically, climb high enough to practice an engine out glide, set normal power, then pull the throttle to idle, establish best glide speed, and observe your glide ratio with the prop windmilling at your normal cruise blue knob setting. Then pull that thing all the way back and take note of the difference in descent rate and glide ratio. As Skip says, it's a big enough difference to notice. Mostly you shouldn't need this trick. But it's one to keep up your sleeve if the fickle fates align to present you with an engine out (but not seized) scenario at high altitude. Or if you need just a few more feet of glide distance to make your Commercial Pilot Power-Off 180 Landing work out to ACS standards.

If you have the quadrant style throttle like in the picture above, and if you also have the fairly tight restricted RPM range (green arc 2350-2700), then yes, almost the entire normal operating range of the propeller is traversed by small movements at the top of the propeller control lever range. We cruise at 2500 RPM, and I'd estimate the lever travel between there and 2700 RPM to be an inch or less. Ours actually used to be even more sensitive with the old Woodward prop governor. After replacing that with a McCauley governor, it's a little easier to control, but still pretty sensitive.

The drain on the pilot's side wing is connected to the pitot system, not the static system, and would not be the culprit in a static system leak. If that wing drain is leaking, it will be reflected in airspeed errors. Static system leaks can come from the static drain on the belly as you mention, but also any of the static system tubing, and any of the instruments the static system tubing connects to. You'll have to look at all these tubing connections and instruments if you're chasing a static system leak. Having said that, even significant leaks in the static system are not going to cause huge errors in the pressure altitude reported by your transponder. At the speeds and altitudes your M20G flies, the air pressure inside the airframe that would "leak" into the static system is not really all that different than true static pressure sampled from the atmosphere. You can see this yourself by flying an airplane that does not have a static system leak, and opening the alternate static valve in flight. At piston airplane speeds and altitudes, the difference in indicated altitude with alternate static is only about 100-200 feet, which is generally not enough for ATC to notice and query you about. So if you're getting queries from ATC that your Mode C altitude is substantially different that what you report as your indicated altitude, it's more likely to be a problem with your transponder or altitude encoder or the wiring between them, than it is to be a static system leak.

A respectful +1 on this from me. Data point: our airplane is hangared in the Denver area where temps occasionally reach 100 in the summer and below zero in the winter. We don't have a Battery Minder or any similar gizmo. We rarely hook up any kind of charger, not even when the airplane sits in the maintenance hangar for a week or two with the gear being cycled for an annual inspection. Throughout all this "abuse", we've been averaging 7 years of life on Concorde RG batteries over the last 20 years. And yes that includes actual capacity tests, not just "it was strong enough to start the engine". Air temperature inside our hangar is probably a bit more temperate than atmospheric OAT, and the airplane rarely sits more than a week or two between flights that charge the batter, so our use case is not particularly extreme. Still, based on our experience, I think a lot of owners running Battery Minders are taking on unnecessary trouble for not much benefit.

Disagree, at least for some of the M20 models. At the first annual after we bought our F model in 2004, the IA found a groove worn in the trim tube where it passes through that grommet, and we had to repair it. He applied heat shrink to the repaired tube where it passes through the grommet. We keep the area greased, but we've replaced the heat shrink at least once in the last 20 years, when it showed signs of wearing through.

Yes, but if you have a GI-275 (or G5 and GAD29), that effectively provides an integrated roll steering converter. That's the question @Mellow_Mooney was asking. Again, I think it's "likely" a GI-275 -> Brittain connection will work, though it's not guaranteed. In a production environment, nerds like me would be responsible for checking impedence matching and other signal integrity subtleties of the connection. As a reminder, those preliminary drawings from Jerry which proposed connecting a GAD29 to Brittain hardware did so via a 1:1 audio transformer rather than direct wiring. My guess is he did this because he wasn't 100% sure the load presented by the Brittain hardware was load and signal-integrity compatible with the output of the GAD29, even though it's likely to be fine.

The GI-275 has an output pair that can produce the AC heading error signals the Accutrack expects, so it's likely you can connect them without a GPSS converter, either directly or via an audio transformer. But there is no drawing from either Garmin or Brittain which documents this, and thus no particular guarantee from professionals that it will work. I suppose someone who has done so might chime in with empirical data from their own installation. As I mentioned upthread, it's important to have an up-front conversation with your avionics installer about what they require in the way of documentation to connect modern avionics to an orphaned autopilot. Not every shop is willing to install and sign off on something without manufacturer drawings, just because it seems like it ought to work. Obviously you have a lot more control over this if you have the training and credentials to act as your own installer.

No need for conspiracy theories, no one "canned" any Brittain autopilot. The principal driver behind Brittain autopilots in this century, Jerry Walters, passed away in 2018 (I believe somewhat unexpectedly). He was actively working on drawings to legally approve connecting Brittain components the the Garmin GAD29 at that time, but these did not reach completion status with the FAA, and that effectively ended further development of the product line. His sister, Cecilia, made a good-faith attempt to sustain and sell the business, and in fact made some posts here as @CSmith. But as I understand it, no buyer with sufficient technical and monetary resources came forth, and Cecilia was unable to keep the business operating in a meaningful way. The Brittain web site is still up, and Cecilia may even still answer the phone. But no parts or service are available, at least that's my understanding as of today. @Kevin Westbrook probably knows the whole story, but not sure if he's interested in detailing it here.

If you're referring to the R-1, it's certainly passable, but it's my least favorite tachometer of all time. I think there are better solutions, including the UMA tachometers which have a vintage analog presentation, but digital guts. To be fair, my negative review is heavily influenced by my experience in the flight training environment, which is different than one might feel about a personal airplane. One of the flight school airplanes I teach in has an R-1, and it's loathed by all the instructors. Readability of the 1980s-vintage LCD from the right seat is marginal at best, and the ring of LEDs is useless (might be OK if the 17 LEDs were associated with 1000-2700 RPM, but I've never seen one where the LEDs came online at anything less than 1300). The unit doesn't display tach time unless it's powered on; and because most renters students forget to record the tach time prior to shutdown, they wind up cycling the master to get it, which puts double the wear on the master and occasionally results in the master being left on. Once powered on, you have to press the tach time button to actually see the tach time, and since the LCD can only display a limited number of digits, you have to cycle the button to "scroll" through a couple of displays which you must mentally concatenate to get the actual value. That causes a lot of confusion. Again, these complaints are less interesting in a personal aircraft, and I will say that the instrument has been reliable. But I just don't like them much from a usability perspective.

Suggest making your enroute stops at larger airports with luxurious FBOs and expensive fuel. I know this is contrary to official Mooney CB doctrine, but bear with me for a minute... Early in my family flying endeavors, I dutifully planned XC trips with small airport/cheap fuel stops enroute as a GA loyalist. Doing so effectively ended my wife's interest in GA flying for about a decade. There were a couple of incidents of sitting around at run-down facilities waiting on weather with no Uber/Lyft/cab service that didn't sit well. The last straw for her was my cheerfully diverting for an unplanned potty break stop, but choosing a tiny little airport that turned out to have not even so much as an accessible porta-potty, requiring her to drop trou in the open air. That was 20 years ago, but it's still the first story she tells every time traveling by GA comes up in our friend group. I want to emphasize that my wife and kids aren't high maintenance types, and in theory they're all about adventurous travel. But everyone has their limits, and statistically, GA flying is at the edge of what's fun for most people who aren't actually flying the airplane. She still flies with me on occasion, but we're not really a GA travel family, and I trace it all back to my choice of stopover points when I was young and enthusiastic about GA flying. These days, if I'm traveling with anyone other than another pilot, I'll happily buy eight dollar avgas and pay ramp fees in exchange for comfortable lounges, free cookies, on-the-field maintenance, nearby nice hotels, readily available Uber service, and so forth. The monetary cost is incredibly cheap relative to the emotional expense of a bad travel experience.