Restoring a Scratched Instrument Cluster

My 2006 Mitsubishi Lancer Evolution was in great shape when I bought it, with one exception: The instrument cluster plastic looked like someone had taken steel wool to it. The speedometer and other gauges were still visible, but looking through the hazy plastic felt like driving a fifteen year old neglected economy car.

The usual cleaners did nothing. The plastic was rough to the touch from a mix of scratches and heavy oxidation. The back of the plastic was fine, which suggests that someone might have used a very plastic-unfriendly cleaner on the piece at some point. Alternatively, it’s possible that Mitsubishi applied an anti-glare coating to the piece from the factory which doesn’t age gracefully. Either way, it was going to take some mechanical abrasion to remove the damaged top layer and polish the good plastic underneath.

Close-up of scratches on plastic

The plastic piece must be removed from the car to do this properly, but fortunately that’s an easy task in the Evo. First, use a short Phillips screwdriver to remove the two screws at the top of the instrument cluster hood. Don’t let the screws fall down into the steering column like I did, because it’s a pain to get them back out.

The plastic piece is held in by three tabs at the top and two at the bottom. Use a flathead screwdriver to very gently loosen the two clips at the bottom.
Screwdriver underneath the tabs on the bottom

The three clips at the top are much easier to access. Use your finger to release the tabs from behind.
Removing the top tabs

It took me several tries to get all of the tabs loose at the same time as they all have a tendency to re-latch themselves while you’re working on the opposite tabs. The key is to be gentle and go slowly. I’m willing to bet it’s not cheap to replace this part if it breaks.

Be careful to not touch the back of the plastic much so as to minimize the number of fingerprints you’ll have to clean from the back of the plastic later on. Also make sure to roll up the car windows while working on the instrument cover plastic to minimize the amount of dust that settles on the exposed gauges.

Instrument cluster plastic removed from vehicle

I started with Meguiar’s PlastX Clear Plastic Cleaner and Polish to remove the haze and deep scratches and used Mothers Plastic Polish to finish the polishing process. The Meguiar’s plastic cleaner is more abrasive than the Mothers product, but it doesn’t provide the same level of clarity as the Mothers polish. Likewise, the Mothers product produces a better finish but requires substantially more effort to remove deep scratches. Starting with the Meguiar’s product and finishing with the Mothers product gives the best of both worlds. As an added bonus, the Mothers product claims to include a compound that protects the plastic finish over time.

Meguiar's and Mother's Plastic Polish

Both polishes are straightforward to use. Apply the polish liberally to the face of the plastic, then use a clean automotive microfiber towel to work it into the plastic. Alternatively, Meguiar’s makes a fancy applicator pad that they recommend for this purpose. The key here is to use a perfectly clean automotive-specific towel or applicator, because any old dirt or grit in the towel will just introduce new scratches while you work. Using medium pressure, work the compound into the plastic in all directions for a long time. Apply more compound as needed to avoid letting the surface go dry at any point in the process, as this can also introduce new scratches back into the surface.

Polished Plastic

When most of the scratches are gone, switch to a clean microfiber cloth and very gently buff the remaining compound off of the surface. Be sure to thoroughly clean any fingerprints, lint, and streaks off of the back of the plastic piece before you install it. I wasn’t careful enough the first time around and had to remove the plastic piece a second time to eliminate all of the lint from my towel.

Finished Instrument Cluster

The restored instrument cluster plastic looks brand new. The deepest scratches are still there, but they’ve been reduced enough that you can’t notice them under normal viewing conditions.

How to use the Mentor Graphics Sourcery ARM toolchain on 64-bit Debian Wheezy

The Mentor Graphics CodeBench Lite ARM toolchain (formerly known as the CodeSourcery ARM toolchain) is the toolchain of choice for many open-source ARM projects. Unfortunately, Mentor Graphics provides only 32-bit binaries for the toolchain and the provided source code package is quite difficult to compile. If you try to run these 32-bit binaries on a 64-bit Debian or Ubuntu installation without the proper 32-bit libraries installed, your shell will greet you with the following less than helpful error message:

$ arm-none-eabi-gcc
-bash: /opt/arm-2013.05/bin/arm-none-eabi-gcc: No such file or directory

The ‘No such file or directory’ error occurs not because bash can’t find the file, but because your 64-bit system lacks the proper libraries to run the 32-bit executable.

On Debian Squeeze (6.0) and most other Debian-based distributions, the solution is to install the ia32-libs package:

$ sudo apt-get install ia32-libs

However, starting with Debian Wheezy (7.0) the i386 packages are not available by default on a 64-bit installation due to Debian’s new Multiarch system. Attempting to install ia32-libs on a fresh Debian Wheezy install gives the following error:

$ sudo apt-get install ia32-libs
Reading package lists... Done
Building dependency tree 
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
 ia32-libs : Depends: ia32-libs-i386 but it is not installable
E: Unable to correct problems, you have held broken packages.

The solution is to add the i386 architecture to your multiarch setup before attempting to install any 32-bit libraries such as ia32-libs:

$ sudo dpkg --add-architecture i386
$ sudo apt-get update
$ sudo apt-get install ia32-libs

After adding the i386 architecture and installing ia32-libs, you should be able to run the 32-bit Sourcery ARM toolchain binaries:

$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (Sourcery CodeBench Lite 2013.05-23) 4.7.3
Copyright (C) 2012 Free Software Foundation, Inc.

Note that the ia32-libs package installs a lot of i386 libraries that aren’t necessary for the Sourcery ARM toolchain. If you’re trying to minimize disk space usage and you’re feeling adventurous, you can get away with only installing libc6-i386, which is substantially smaller:

$ sudo apt-get install libc6-i386

This worked for my purposes with the Sourcery ARM toolchain. However, you may run into issues with some of the other 32-bit binaries in the toolchain, as I didn’t use them all in my build process.

Analysis of the iPhone Location Log

Yesterday, security researchers announced that iPhones and 3G iPads maintain a log of the phone’s position over time. Today, another researcher released a python program to dump the equivalent log from Android devices. While it has been common knowledge that cellular phone carriers store customer location data for a while now, it comes as a surprise to learn that client devices are carrying their own logs as well. These logs are included in backups on the user’s computer and rogue applications could easily steal the data if left unencrypted. Even more troublesome are reports that Michigan State Police are using a device from a company named Cellebrite to extract data from people’s cellular phones during routine traffic stops.

So what data, exactly, is contained in the consolidated.db file? And just how accurate is the positioning data contained within? After unencrypting my iPhone backups in iTunes, I used the information in Pete Warden’s documentation on GitHub to pull the information into a spreadsheet. I had 12,380 records in total starting on 9/3/2010. That’s the day I purchased my iPhone 4. On average, that’s 61 location entries per day! After spending some time with the data, here are some preliminary observations:

1. The log appears to be limited to cell phone tower data, not GPS data. The values in the Horizontal Accuracy column never fall below 500 (meters) which suggests this is approximate location data from cell towers. Moreover, the VerticalAccuracy and Speed columns are always -1, which is what the Significant Location Change service reports when GPS is not in use.

2. The MCC and MNC columns represent some combination of carrier and/or country code. These columns have values of 310 and 410, respectively, whenever I was in the United States. This includes trips to both coasts, so I’m fairly certain these values apply to AT&T anywhere in the country. In Europe, these columns take on different values for each country. It appears that the MCC column might be a country code and the MNC column is a carrier code.

3. Timestamps are only updated after a significant location change. Surprsingly, the same timestamp value is shared across many location entries. This behavior seems rather strange, as it is trivial to grab the current system time when writing locations to the database. Apparently the column was intended to represent the phone’s arrival in a certain area. Generally, travelling a distance of 5 kilometers is enough to trigger a new timestamp but this is not guaranteed. I have many timestamp updates at less than 1km traveled and quite a few updates of over 5km without a timestamp change. It appears that driving somewhere quickly (i.e. using the freeway) is more likely to trigger a timestamp change than by slowly moving to a new location (i.e. on foot). This is not a reliable metric by any means, as I had some blocks of entries with the same timestamp span upwards of 20 miles within a city.

4. A stationary phone can generate many log entries. Building on the idea that timestamps only change when the phone is moved a significant distance, I started mapping blocks of entries with the same timestamp value. It turns out the phone logs quite a few location entries while the phone is technically stationary, even in buildings with great reception. This is not surprising, as received signal strength from nearby towers will vary significantly as I walk through a building. The following image shows location entries while I was in my apartment, which has excellent reception: (Note: I translated all of the values by the same offset for some anonymity)

These consolidated.db entries were logged over the course of 11 hours in one building with great reception.

5. Averaging entries with the same timestamp comes remarkably close to the phone’s actual location, but only if reception is good and cellular towers are dense. Averaging a random sample of consolidate.db entries with late-night timestamps yielded coordinates only 690 meters from the actual location of my apartment. The average of a block of entires on a Saturday gave me coordinates only 630 m from my girlfriend’s house. Both of these locations have great reception and are moderately-dense suburban neighbors. On the other hand, averaging entries during the week put me a full 8.1 km from the actual location of my office. We have terrible reception in my office, so this is not too surprising.

The average of these points with the same timestamp is within 650 meters of my actual location

6. 50% of location changes occur after 1 km of [perceived] movement. 33% occur after 500 m of movement. A full 90% occur within 5km. These distances are calculated from the estimated locations in consolidated.db. It would be interesting to log actual GPS location in parallel and compare the two values.

Relative frequency of the distance between updates

7. Locations with good reception have far more entries than locations with poor reception. I expected the opposite to be true, as buildings with poor reception tend to have higher received signal strength fluctuations and therefore trigger more perceived location changes. Instead, the phone infrequently logs locations whenever reception is poor. This could be a side effect of some built-in mechanism to only log locations when the phone is relatively stationary and receiving a stable signal. As a result, it’s very difficult to pin down the phone’s location if reception is poor.

8. Older entries are less frequent. This one is just a rough observation. It’s entirely possible that I’ve been more mobile lately than when I first bought my iPhone. However, my log has far more entries with timestamps in the past several months than it does from the beginning of the consolidated.db log. This could be due to changes in the iOS software to log more often. It could also indicate that the iOS software prunes older entries over time to keep consolidated.db from growing too large, but I’m not so sure this is the case.

So what does this mean for iPhone users? Not a whole lot, as long as you remember to encrypt your iPhone backup in iTunes to make it a bit more difficult for rogue applications to access. Still, I’m not sure why iOS and Android OS find it necessary to keep location logs. The only logical explanation I’ve heard so far is that it might help speed up future geolocation queries. It will be interesting to see how Apple and Google respond to this, if at all.

iPhone Background Location Service

Location Updates After 2 Days in San Diego

Apple’s iOS operating system famously doesn’t allow applications to run in the background. It does, however, allow them to perform seven narrowly-defined background services such as audio streaming and receiving ‘significant location change’ updates. The significant change updates don’t use the iPhone’s highly accurate but power-hungry GPS in the interest of preserving battery life. Instead, the phone uses the relative signal strengths from nearby cellular towers to triangulate a rough approximation of the iPhone’s location. The phone’s baseband must continuously communicate with the carrier’s cellular towers when your phone is turned on anyway, so gathering location data from these communications should have a negligible effect on battery life.

So just how accurate are these triangulated data points, and what exactly constitutes a ‘significant’ location change to the iPhone’s iOS? The only information I could find comes from a developer who tested phones in Tokyo, Chicago, and Melbourne. He concluded that 2500m (approximately 1.5 miles) as measured by the phone’s own background location service, was enough to trigger location updates 95% of the time. Moving 750m triggered an update 50% of the time. Good information, but it doesn’t tell us anything about the accuracy of the background updates.

The problem seemed interesting enough, so I spent a Saturday morning putting together a small test suite. I created a simple iPhone app that registered with the iOS significant location change service and logged all updates in an SQLite database and CSV file. I also built a Ruby on Rails app to receive real-time location updates from the phone and pushed it to Heroku for some quick (and free) hosting. Finally, I made a point to record every time I got into or out of my car in my notes for a week so I could compare the background location results to my actual whereabouts.

Some observations:

1) False location change events occur randomly when the signal is weak – At my apartment where the cellular signal is strong, the background location service is generally within 1km of my actual location. When I’m at my office building, where signal strength is so bad we struggle to complete phone calls indoors, the phone will randomly register location events up to 10km away. Usually these events are triggered as I walk from one side of the building to another, but occasionally they will occur while I’m seated at my desk.

2) It doesn’t use nearby WiFi networks for location – The above problem could be mitigated somewhat if the OS would use nearby WiFi networks to aid in location. After all, the iPhone already queries a massive database of WiFi router locations to assist with GPS lookups, and I’ve used my GPS at home and my office enough for the phone to associate my WiFi router’s BSSID with a physical location. On the other hand, scanning for WiFi networks would provide some additional battery drain. Dealing with mobile hotspots like the MiFi would be problematic for a WiFi-assisted location scheme as well.

3) Location updates occur at regular intervals while moving, but not always – For my first test of my location tracking app, I drove 13 miles across town to a coffee shop. Upon arrival, there were exactly two pins on my map: my apartment and the coffee shop across town. I assumed the background location tracking waited until I stopped moving and my location stabilized to register a location change event. Clever. Then, on the drive home, my app diligently registered location events every few kilometers along the freeway until I was home. So much for that theory. Since then, I’ve received updates while moving more often than not, but very rarely I won’t see any location update events until I arrive at my location.

In the screenshot to the left, I ended up driving all of the visible freeway segments (yellow lines) over the course of two days. For the upper (I-80) and rightmost (I-215) segments, the application received location change updates at roughly the same location each time. The segment on the left (I-15) did not register any location events in this snapshot, but on other days driving the same I-15 segment would register location change events every 2-4 km.

The good news is that I always seemed to register a location change event when I arrived at my destination and parked the car. In some cases, these location change events were 15km apart. This only seems to happen when traffic isn’t present, allowing me to maintain a constant 65mph on the freeway.

iPhone Navigation Active Indicator4) If the application is terminated, background location services will restart it automatically – Once the app calls [[CLLocationManager sharedLocationManager] startMonitoringSignificantLocationChanges] the familiar location ‘compass’ arrow shows up in the taskbar, even though the GPS isn’t running. Terminating the application does not remove this arrow as I expected. Rather, the OS will launch the application again when the next significant location change event occurs. The only way to remove the compass arrow and stop location change events is to call [[CLLocationManager sharedLocationManager] stopMonitoringSignificantLocationChanges] from within your application. Unfortunately, there is no way to list which applications are monitoring your location. I can imagine frustrated users killing all of their applications one by one in an attempt to turn off location updates.

5) Activating the GPS will register a location change event, even if the phone hasn’t moved – Opening the Maps application, checking in on FourSquare, or any other activity which uses the actual GPS will trigger a significant location change event. These are easy to distinguish from background location events because they have real values for CLLocation.VerticalAccuracy, CLLocation.Altitude, and CLLocation.Speed, whereas background location updates have values of -1, 0, and -1 respectively.

Choosing the Right Tire for your Mountain Bike

Riding Beacon Hill in Spokane, WA

This is a guide for choosing the best tire for your mountain bike. Too many riders obsess over lightweight frames and top-dollar components while ignoring the all-important tire. Tires connect your bike to the trail. They set the limit for how hard you can corner, accelerate, and brake. Changing a tire can completely change the way a bike handles. It pays to invest some time and money into finding the best tire for your setup.

The best starting point for choosing a tire is to ask the other riders at your favorite trails which tires they prefer. Local bike shop employees are usually helpful as well. Online opinions and reviews in forums are useful, but unless you’re browsing forums for your particular region you may end up with tire recommendations that are sub-optimal for your local trail conditions.

I typically go through 8 tires or more per season, and I keep a stack of different tires in my garage to swap out depending on the trail, the weather, or if I just want to try something new. Through trial and error I’ve learned what to look for in a tire, and what to avoid. Here are the most important things to look for:

1. Tire Width

Wider tires tend to grip better during cornering and over rough terrain, at the expensive of increased rolling resistance and weight. Wider tires will also float better in sandy conditions and are much more resistant to pinch flats when riding over sharp rocks or off of drops. For moderately rocky cross-country use, the sweet spot is between 2.0″ and 2.3″. If you primarily ride smooth hardpack or travel at a leisurely pace, choose a 2.0″ or even a 1.8″ tire. Likewise, if you tend to corner hard on the downhill and ride rough terrain, lean toward a 2.3″ tire. For downhill mountain biking where pedaling efficiency is less of an issue, look for a tire between 2.3″ and 2.6″. Tires up to 3.0″ wide are available, but rolling resistance becomes very significant past 2.6″.

The front tire is typically subjected to more cornering forces than the rear tire. Likewise, the rear tire is usually loaded with more weight while pedaling. Consider using a wider tire in the front with a slightly narrower tire in the back to get the cornering benefits of a wider tire with the rolling resistance advantages of a narrower tire in the rear. I’ve had good luck with a 2.5″ tire up front with a 2.3″ tire in the rear on my downhill bike.

Also note that widths are approximate. I’ve got a 2.3″ tire which measures 2.5″ wide with my calipers, and a 2.4″ tire which is actually only 2.25″ wide. Make sure that your frame and fork have enough clearance to support the width of the tire. Maximum tire sizes are listed in the owner’s manual. If you ride through mud often, allow for even more tire clearance to keep mud from building up between the tire and frame.

2. Compound (a.k.a. Durometer)

Three 42a compound tires in different stages of wear

42/40a compound tire. Left: Brand new. Middle: Used as a rear tire for four days of downhill. Right: Used as a front tire for four days of downhill.

The hardness of the tire’s rubber compound dictates how soft and sticky a tire is. Softer compounds grip better at the expense of shorter tire life. Likewise, a harder tire will last longer but have less traction. Softer compounds also have a higher rolling resistance because the softer rubber absorbs more energy as it conforms to the ground.

Hardness is measured by the tire’s durometer with higher numbers indicating a harder compound. A standard cross-country tire will have a durometer around 60a (the ‘a’ is omitted by some manufacturers) and will last for one to three seasons of moderate weekend riding. A 50a compound will provide noticeably more grip under cornering and braking, but might last only one season. 40a and 42a tires are the softest available compounds and will provide the most traction, but plan on replacing these tires at least twice a season. Some tires are available with a 70a compound for the ultimate longevity, but these are only really useful if you’re riding on pavement or the smoothest off-road trails.

The rear tire will wear faster than the front tire due to higher loading, braking, pedaling, and sliding forces it sees. Consider using one step harder of a compound in the rear to minimize this effect with little impact on overall performance. Riders who slide the rear end a lot will definitely want to avoid soft 40a and 42a compound tires in the rear. If you do use the same tires front and rear, rotate your tires halfway through the season to get the most life out of the set.

New vs Used Tired

Foreground: Soft 42a tire (ab)used as a rear tire. Background: Same tire, brand new

Multi-compound tires can be the best compromise of the above factors. Maxxis’ 3C tires use a hard base rubber for lower rolling resistance with softer compounds on the surface and for the side knobs for better grip. For example, a 70/42/40 compound tire would have a 70a hardness base rubber under the surface, with 42a center knobs and 40a side knobs for the best cornering. From my experience, they tend to last about as long as a 42a tire with the slightly better cornering of a 40a tire.

3. Bead (Wire vs. Foldable, Steel vs. Kevlar)

The bead is the inner edge of the tire that holds the tire to the wheel. This edge is either wire reinforced (steel) or foldable (Kevlar or Aramidd). Foldable beads are about 50 grams lighter and allow the tire to be folded up. Tires with steel beads cannot be folded up, but hold up slightly better under heavy downhill riding.

I always run foldable tires on my cross country and all mountain setups, but after a few bad experiences on my downhill bike I stick to steel bead tires for downhill. Most downhill tires are only available with a wire bead anyway.

4. Number of Plies (1-Ply vs. 2-Ply)

The casing (internal structure) of a tire is a nylon cloth wrapped from one bead to the other. A single ply tire has one layer of nylon fabric, while a dual ply tire has two layers for additional durability at the expense of additional weight. Single ply tires are generally fine for cross country, but for all mountain or downhill riding you will definitely need a dual ply tire. Some 2-ply tires have an additional butyl rubber insert sandwiched between the plies in the sidewalls for even more pinch-flat resistance.

5. Threads per Inch (TPI)

A tire’s thread per inch count refers to how many nylon threads cross through one inch of a single ply of the casing. Lower TPI tires have larger individual nylon threads while higher TPI tires have smaller, more tightly woven threads. High TPI tires have less rolling resistance and weigh less due to the smaller threads, but the thinner weave is more easily damaged than a lower TPI tire. A TPI of 60 is best for downhill and all mountain, and a TPI of 120 is fine for lighter cross country.

6. Weight

Tire weight is proportional to width and durability. A super strong wide downhill tire can weigh up to 1.4kg (3.1lbs) while some narrow, paper-thin, race-only cross country tires can weigh as little as 285g (0.6lbs). I wouldn’t recommend super-light tires for any use (even racing), but if your riding is limited to cross-country on smooth trails a 450g tire can be strong enough . For all-mountain, anything less than 600g is probably not as durable as I would like. Downhill tires start at around 1kg, but the extra weight is a small price to pay for the added durability.

As long as you’re picking an appropriate class of tire for your bike and riding style, it’s not worth obsessing over a difference of a few 100g between tires. It is interesting to note, however, that the weight of a tire has almost twice as much influence on your bike’s inertia than any non-wheel parts of your bike. When you accelerate or brake, you are not only fighting the linear inertia of your tires, but also the rotational inertia of the tire as well. Usually this effect is too small to notice, but it’s an interesting fact nonetheless.

7. Knob Pattern

The tread pattern and knob locations can provide insight into how the tire will handle, but these are very difficult to read. Trying a tire out for a few days is the only way to truly know how a tire will handle, but there are a few guidelines you can use to judge a tire:

  • Tread patterns with lengthwise-overlapping knobs will have a lower rolling resistance because they maintain a smoother contact between the road and the tire as it rolls
  • Knobs with ramped leading edges in the center of the tire have a lower rolling resistance
  • Widely spaced knobs will shed dirt and mud better at the expense of higher rolling resistance
  • Knobs with channels cut through the center have more edges and therefore grip more, but wear faster than solid knobs
  • Patterns with a large gap between the center knobs and side knobs can require more leaning in corners to get a solid bite but grip better under hard cornering

8. Tubes vs. Tubeless

Tubeless mountain bike tire setups have become more popular recently due to their lighter weight and self-healing properties when used with an appropriate sealant. A tubeless setup requires either special UST wheels which are airtight, or standard wheels modified with an additional strip of rubber to be airtight. I’m not a big fan of the modified wheel approach but many people have no issues with it. A UST wheel can in theory be used with a UST tire without additional liquid sealant, but the added protection of a sealant is definitely worth it. Any other tire or wheel combination will absolutely require a liquid latex sealant inside of the tire, as standard tires are not actually 100% airtight and their bead is not designed to form an airtight seal with the wheel.

Perhaps the biggest advantage of a tubeless setup is the ability to run very low pressures without worrying about pinch flatting a tube. A tubeless setup with sealant will also seal any tiny punctures from thorns automatically. The downsides are the additional cost of UST wheels and tires and the added difficulties of mounting a tubeless tire. (Hint: Use a lot of soapy water on the rim first!) Also, sealants are messy and dry out over time, requiring refills every 1-2 months for maximum effectiveness. Always carry a spare tube and tire levers anyway in case your tire is punctured with a hole too large for the sealant to properly seal.

Reblog this post [with Zemanta]

Little Cottonwood Canyon Ruins

Little Cottonwood Canyon Ruins

Last Wednesday I hiked up Little Cottonwood Canyon to revisit the strange ruins at the top of the trail. The trail that runs parallel to the road from the base of the canyon is my favorite after-work mountain biking trail. Across the river from the top of the trail you can see some ruins hidden among the trees. Unfortunately, the river is fueled by all of the melting snow from higher up the canyon, so the water level remains too high to cross for most of the year. This fall the water level finally fell low enough to cross.

The ruins as seen from across the river

The building itself, or what remains of it, was definitely worth the hike and the river crossing. All of the walls were precisely constructed from stacked granite rocks gathered from the surrounding area and held together with mortar. The only exceptions were the wood planks surrounding the door and window frames and some relatively ornate concrete arches over each of the window openings. I can’t even imagine how much effort it would have taken to collect and stack all of those rocks into a building of that size. Given the fact that the building was mostly reduced to rubble, it wasn’t the most robust construction method, but it definitely has a visual impact that is hard to match with any of the modern construction methods.

This hole in the floor drained into a tunnel that flowed out to the river

I had a difficult time finding any evidence of what the building might have been originally used for. After many years of snowy Utah winters, curious hikers, and what looked like a few seasons of abnormally high river waters carrying mud into the building, there was little evidence of the original purpose of the building. I managed to find a pair of small metal hooks near the door, perhaps just large enough to hold two sets of keys. A hole in the floor gave way to a small drainage tunnel that must have carried drain water out to the river. What remained of the roof trusses appeared to be constructed with the same attention to detail applied to the rest of the building. Whatever material the roof was originally constructed from had long since decayed or washed away.

Mother Nature is slowly winning this battle

I searched the internet for some clues about the old building, but never came up with anything useful. Little Cottonwood Canyon was used by the Mormon pioneers as a source of quartz monzonite to build the temple in downtown Salt Lake City, but it sounds like most of the stone came from the mouth of the canyon 3 miles below this building. Still, given the rather ornate construction of the building and my lack of a better explanation, I’m inclined to guess that the structure was constructed for use as a church. Definitely worth a visit if you’ve got a few hours to spare in the Fall.