This past Sunday marked my first AutoX event with a couple of buddies at Atlanta Motor Speedway. While the day was hot, sweaty, and hungover (thanks to Jay's He-Man Juice the night before), it was an absolute blast.
The experience was very different than HPDE events I've done in the past, arguably AutoX is a different animal all-together. Honestly the most challenging aspect is actually finding the course on the first couple of runs. Unlike HPDE events which are on road courses (which have little to no variability in the route), Auto Cross (or AutoX for the initiated) uses large parking lots and "gates" defined by marker cones, where the driver has to learn the course while trying to set their best time on that course. Each vehicle is "spaced" safely from the vehicle running the course ahead and behind them, so there's no pressure of other drivers or risk of collision. Additionally, unlike HPDE, the drivers are also required to "work the course" when their run group is not running, by noting cone hits or DNFs, and ensuring the cones are in their correct position. BMW CCAs AutoX allowed 8 runs, with a time penalty of 1 second for any cone hit and a DNF for any "missed" gates. Comparing HPDE to AutoX, I'd highlight the pros and cons of AutoX as follows:
- Less risk of colliding or damaging your or others' vehicles
- More ability to "push the limits" of traction and control
- No pressure from other vehicles on the course, having to provide "point-bys" or anticipate other driver's behavior or course
- Less risk of a "money shift" since you can pretty much stay in the same one to two gears throughout the course
- Greater "appreciation" for the event since you are both a participant and a course worker
- Exercise (e.g. running to pickup cones, monitoring your assigned sector, and "on your feet")
- Less expensive
- Challenge of finding the route/course crowds out/distracts from the ability to identify braking zones, apexes, etc
- Lower speed and less distance does not lend itself to better understanding your vehicle's handling characteristics in dynamic environment
- No "persistence," so once you learn a course, it's only good for that day - the next time you return, it will be a different course
- Less seat time
- Less technical in driving requirements (e.g. no shifting or heal-toe required, limited benefit or opportunity for trail braking, little to no elevation change)
Since purchasing our house (or rather 20% of it) in September, I've dived head first into home automation. It's turned into a hobby, as it combines a lot of my interests - computing and virtualization, lighting and electrics, and working with my hands. A lot of friends and colleagues have expressed an interest in home automation, so I decided to put together a short guide around what I've done and what's worked for me. Before I lay claim that I have derived this information all on my own, I must admit it's an amalgamation of information from forums, Amazon.com, friends, and neighbors (hat tip to Brian, if you're reading).
Choosing a systemThis is very much a developing industry and technology, and in many ways is still immature. There are many offerings from many manufacturers leveraging different protocols and technologies. It definitely follows the adage, "Fast, cheap, or good. Pick two." Definitely do your research as depending on which platform you choose, you can get locked in, as not all "Smart" devices play nice with each other. The key things to consider are:
CostSome platforms are more expensive than others. Not only are you looking at upfront costs, you also have to consider subscription fees for things like cloud storage, application or plugins, etc. Ikea has a new offering that is supposed to be cheap and easy, but it's not extensible. Apple has HomeKit which is on the more expensive end, but requires less "fiddling," at the expense of extensibility and customizability. Google Home or Amazon Alexa support some native "Smart" capabilities, but they're not true smart platforms (see protocols and efficiency below)
SupportSome platforms have more community support than others, which include both troubleshooting, device support, custom logic and device handlers.
ExtensibilityIt kind of goes hand-in-hand with support, but open platforms allow developers to contribute to and expand the functionality of different devices, which tends to happen faster than the vendors themselves integrate their solutions. A good example is thermostats- EcoBee (which is what I use) has Samsung Smartthings (which is what I use) support, but there its functionality pales in comparison to a custom device handler that a community member wrote. Smartthings also includes the ability to install community-develops SmartApps, allowing for advanced orchestration and automation
Protocols and efficiencyMany devices mark themselves as "Smart," but it's more a marketing term than anything else. Just because something has Wifi connectivity doesn't inherently make it "Smart," and WIFI is definitely not an ideal protocol for smart device networks due to its power requirements and design. Below is a quick rundown of the different "Smart" protocols:
- WIFI - many appliances, thermostats, doorbells, and cameras leverage WIFI for connectivity into a the "smart" platform. While WIFI is appropriate for some of those devices (e.g. a doorbell), it is pretty inefficient for most devices. You have to take into account what WIFI was designed to do - handle a large volume of network traffic, with emphasis on throughput and speed at the expense of power and simplicity. While a WIFI plug, bulb, switch, or camera may work for your needs, they also add significant overhead in terms of number of devices, chatter, and traffic to your home wireless network. WIFI cameras in particular can bog down a home wireless network due to the low latency, high bandwidth requirements of modern 1080p or 4k cameras. Additionally, range can be limited with WIFI and you have to take into consideration distance of devices from your wireless router/access point. Generally speaking, "Alexa-enabled" or "Google-Home" enabled devices are simply just WIFI devices, which means no smarthub is required
- Bluetooth - Apple Homekit uses bluetooth for some devices, where you can use an iPad or AppleTV as a "smarthub" which acts a bridge between a TCP/IP network and bluetooth devices. Many "smartlocks" use bluetooth to interface directly with a phone or Homekit. While requiring less power than WIFI, bluetooth has even more range limitation, often requiring line-of-sight distance from a phone or an AppleTV to work. Additionally, Bluetooth is a relatively insecure platform. The newest implementation of it supports encryption, but few vendors are currently implementing it effectively. Needless to say, I wouldn't want my home's physical security subject to the vulnerabilities to Bluetooth (ie a door lock)
- Zigbee - a purpose-built home automation technology, it is a low-cost, low-power protocol. It is gaining popularity but is inferior to Z-Wave (see next point) due to lack of interoperability, fewer device and manufacturer support, and lack of forward- and backwards-compatibility. You'd need a smarthub (e.g. Samsung Smartthings, Wink, Wemo, Homekit, etc) to bridge between your wireless network and zigbee devices.
- Z-Wave - a purpose-built home automation technology, it is low-cost, low-power, and has the widest manufacturer and device support. It operates at 900MHz so it doesn't interfere with WIFI networks (2.4GHz or 5GHz), although it could interfere with a cordless phone (although who uses those anymore?). Being lower powered, z-wave is good for wireless devices (e.g. motion sensors, door sensors, etc) All Z-wave devices can talk to all other z-wave devices within a network. Additionally, Z-wave devices act as a mesh network, so the more devices you have in your house, the stronger your network. Z-wave will allow a maximum of 3-hops among devices to transmit to the hub, which is nice. So you could hit a smartswitch at one end of the house, and the signal will "hop" to another switch, to a smart outlet, to your home hub. You'd need a smarthub (e.g. Samsung Smartthings, Wink, Wemo, Homekit, etc) to bridge between your wireless network and zigbee devices. I've standardized my home on z-wave devices.
- Thread - a relatively new wireless, low-power home automation protocol founded by manufacturers such as Google (and Google-owned Nest), Samsung, etc. I don't know much about it, but a quick search shows it's based on Zigbee technology and should mirror Z-wave in terms of functionality
LightingThere are lots of "smartbulbs" such as Philips Hue or LifX which change color, dim, and turn on and off with a smartapp. I initially started looking at Philips Hue as an option for lighting, but quickly found that it did not meet my needs. It's expensive, requires its own hub device, I didn't need the color changing features, and I had read it can be unreliable. I did a bit more research and stumbled on Z-Wave smart dimmers and switches (I use GE Z-Wave smartswitches, but there are other options such as lutron). I like using smart switches rather than smart bulbs since I can continue to use traditional light fixtures and bulbs and can control the lights via apps or via the switch itself. Also, it fully supports three-way and four-way switches (e.g. when you have two or more switches in your house that control the same light(s)). The downside is you have to be comfortable with home wiring and replacing traditional switches
CamerasI did a ton of research into cameras and ended up choosing Ubiquiti Unifi as it suited all of my requirements. Most notably:
- Wired - I didn't want to use wireless cameras for both security reasons and because I didn't want to saturate my wireless network with camera traffic
- ower-over-ethernet (PoE) - Power-over-ethernet is as exactly as it sounds - you can both power and receive camera data via one ethernet cable (e.g. Cat5E or Cat6). This eliminates the need for finding a power source or plug nearby, or worse, having to use and recharge batteries
- No cloud storage required - I really did not want to pay a subscription service for cloud storage of my video footage since I have a perfectly good (albeit old and slow) NAS at home. Cameras such as Nest or Ring require a monthly or yearly cloud subscription. With Ubiquiti I can specify how many or for how long to store video footage Linux support for the NVR - probably not a big consideration for you, but I really wanted full control of my NVR and the ability to install it on Linux since thats primarily what I use for my home lab and setup. Ubiquiti Video NVR also supports Windows and Mac, so you'd be okay there.
- Advanced Motion zones and detection - I can define motion zones to monitor (and not monitor) to trigger recording as well as specify the duration to record Camera NVR - if you don't want to go with Ubiquiti cameras (they are relatively expensive) take a look at Foscam PoE cameras and BlueIris NVR software
My SetupTo give you an overview of my setup, I'm using the following:
- Samsung Smartthings Hub
- Using WebCore for advanced logic and orchestration
- Ubiquiti Unifi Video Cameras (for external cameras and security)
- GE Z-wave smart switches
- GE Z-wave smart outlet
- Ecobee v3 thermostats (I deliberately chose v3 since I didn't want or need the built-in Alexa functionality in v4)
- Ring Pro Doorbell
- Foscam wireless camera (for internal monitoring and recording)
- Ecolink motion sensors (for internal and external motion detection for security and light automation)
- Ecolink rare earth magnet door sensors (for door monitoring for security and light automation)
- Google Home
- Google Chromecast
The best word to describe the first few sessions: frustrating. Having tracked the BRZ nearly a dozen times at AMP I had gotten comfortable with the lines, brake zones, and corner speeds in that car, which I quickly found did not translate directly to the Miata. Not that the BRZ is a power monster, but compared to the Miata, I could miss an apex or deviate from the perfect line and still run 1:43s consistently. Not so with the Miata. One bad corner, a little too much application of the brake, or deviating from the race line at all, and I was hanging in the 1:51s (not great).
But by the second half of the day, once I had gotten a better feel for the car, learned the near limits of the tires and suspension, it became much more fun. Once I accepted the fact that I'd be giving point-bys most of the session, when I found myself some open track, the car was amazing fun. I could carry a lot more speed through certain corners, I could brake later in others, and I could hold tighter lines than in the BRZ (and certainly than in the understeering STI). Perhaps it was having the top down, not having any electronic nannies, or the direct feedback from the steering, but I certainly see the appeal of the NA Miata on a track like AMP.
At the risk of coming off as condescending, there is a certain pride of hanging with more powerful cars. The occasional time I earned a point by from a late-model mustang or E36 BMW was all the more rewarding. The thing about the Miata is if you don't get your braking just right, or hit your apexes perfectly, you're in for a frustrating lap. But get it right, and every second off your previous time is all the more rewarding.
One item of note is by the end of the day, I was pretty beat up (physically). Having the stock leather seats and original 95' suspension led to a lot of leg and knee banging against the door and transmission tunnel. Some Sparcos, a race harness, and some new coilovers with a bit of life left in them would serve this car well.
Would I take the Miata on a faster track like Road Atlanta or Roebling? Absolutely not, unless I had a penchants for masochism. AMP or Barber? If the weather is alright, and of course, with permission from Lydia.
I've since dug up the paper and gave it a re-read and reminiscing in my days of Econ and IT wonk, so in the spirit of Open Source, I've uploaded the paper to matt5lot10.
Here's the abstract from the Thesis
The market for software is in many ways distinct from that of any other good due to software's strong network effects, imperfect public-good nature, and complexity. As a result, the free market has two primary means of delivering software to consumers: the proprietary method, and the free/open source method. These two contrasting methods of software production may appear to be mutually exclusive, and many believe their coexistence to be unsustainable. This study investigates the theoretical and empirical literature regarding the rationale and motivation for, and welfare impacts and overall efficiency of, each software development model and how they interrelate. We can conclude from this study that these two models are in fact not mutually exclusive and in some cases complementary, provided certain market conditions are met. We can also conclude that the open source software development model is in fact consistent with economic theory and is thus a sustainable method of software production.
So after owning the BRZ for 2.5 years with no power upgrades, I finally bit the bullet and installed some goodies to give it a bit more power and help reduce the all-too-familiar torque dip on the FT86. The upgrades performed this past weekend include:
- Moto-East Flex Fuel Kit
- JDL UEL Header
- ISR Overpipe
- EcuTek Tune
All told, the modifications should add about 30whp, bumping it up from 175 to 205.
For your viewing pleasure, here's a timelapse video of the installation. Lots of standing and talking, but that's part of the process
In a serendipitous procession of events, the TooheyMobile is no longer in the stable, as it had to be surrendered to make room for the new toy above.Nothing was inherently wrong with the Subaru Legacy - in fact I parted with it rather regrettably, but I just couldn't turn down the deal on the STI. I happened to run a search on AutoTrader one Friday for "wanted cars" (as I'm apt to do), when a new listing popped up from the same dealer from which I purchased Zed. Having no photos and a limited description, the ad was austere, but two very important data points were present; mileage and price. Recognizing the potential deal, we hopped in the Legacy and headed over to the dealership to scope out the car in person (mostly just to confirm that the listing was in fact not a mistake). Before I knew it, I was signing paperwork and organizing finances, all before actually having the opportunity to actually sit in the vehicle, let alone test drive it. So for all of those curious, here are the stats (and essentially why I took the plunge):
- 2004 Subaru Impreza WRX STI
- 36,000 miles
- One owner
- Relatively unmolested
- 20% below KBB value