Shift cable/brake interference on prototype Soma Smoothie HP Frame (Photo from Soma)
Originally this post was going to be about my new road bike, but instead I’m writing a warning about the new Soma Smoothie HP and a safety issue, recommending against buying it without fully understanding the possible downsides. While the specs of this frame promise to be an excellent modern steel road bike, it has a design problem that can lead to rear brake failure.
Specifically, the location of the brake housing mounts results in the front derailleur cable resting on the brake cable at a mount. Over time movement of this cable can cut into the brake hose/housing, cable clip/tie, etc. If not caught in time this can lead to brake failure.
I purchased one of these frames and have been excitedly building it up, finding this problem late into the build when preparing to run the shift cables and brake lines.
When I brought this up with Soma seeking for a solution, they dismissed the issue, saying they identified this interference during frame development, but that it’s not concerning to them. Stan, with Soma, instead suggested that I rely on the cable tie (as seen above) to mitigate the rub, that rubbing through a brake hose or housing will take a long time, and to add additional material (rubber cable donuts or tape) to the cable if I am worried about it.
I disagree, as any component that’s designed to move should not have unintentional rub, particularly not against a safety-critical system like a brake. A frame should be designed to avoid this; it should not be necessary to bodge in rub protection to stave off cables cutting into other housing.
The photo at the top of this post is of Soma’s prototype build and shows the interference and their reliance on the head of a cable tie for keeping the shift cable in place and away from the brake line. Beyond the safety issue of the front shift cable rubbing on the brake line, the cable does not have a clean path between the upper stop and lower guide, which can lead to shifting issues.
While it would be possible to build this frame up as a 1x (no front derailleur) system to avoid this interference, I want this to be a double-chainring road bike (Shimano 105 R7000) and thus is not an option for me. Or one could go with wireless shifting, but due to cost this isn’t an option for me either.
I really wish Soma had fixed this interference when they first identified it, or at least mentioned it in their documentation so I would have passed on buying the frame. All it would have taken is moving the brake routing to either the centerline (like on this Lynskey) or much further up the downtube (like on my Salsa Vaya) and it’d have been solved.
After I found this a good friend reached out to me, and I’ve since passed the frame on to him. He was looking to build an wireless shifting road bike with fenders, and this will work out perfectly for him. With the electronic shifting he won’t run into this cabling issue.
For those considering this frame, unless you are going with wireless shifting, a 1x setup, or are willing to deal with the compromises of a shift cable rubbing on a brake housing/hose, I suggest that you look elsewhere.
EDIT on 2024-Feb-20: This evening I received email from Stanley at Soma Fabrications about updates to the Smoothie HP frame. It sounds like this will alleviate the concern I mention, so I’m sharing it here:
I just want to update you that early 2023 we replaced the plastic BB mounted cable guide on all our HP frames with one of those guides with two mounting holes (similar to Shimano SP18) which moves the derailleur wire just enough to avoid any contact with the zip tie or brake housing.
Though we maintain the opinion the possibility of the front derailleur wire cutting thru both the zip tie and housing in real world use is extremely remote with the old set-up, we chose to improve the routing.
The new production that arrived this month moves the brake guides to the 6 o’clock area which will probably avoid contact no matter what plastic guide is used on the BB.
Stanley Pun, Soma Fabrications, via email on February 20, 2024
Below are photos showing the interference on my frame. These were taken when the build was nearly complete, while I was planning cable routing. These photos are when I first realized the problem and reached out to Soma.
Detail of cable from non-drive-side stop to front derailleur guide. Cable sets inside of brake mount.
Cable from non-drive-side stop to front derailleur guide sits in lower brake mount.Cable from non-drive-side stop to rear derailleur guide sits in middle brake mount.
Comments closed
Kristen and I have been spending a good deal of time in the Ishpeming and Negaunee area this year, and I’ve made it a personal goal to become more familiar the local trails — both RAMBA-supported and otherwise — and get them documented OpenStreetMap (OSM). Having these trails in OSM provides two big benefits: they appear in other mapping tools (such as OsmAnd, GaiaGPS, Strava, MapMyRide/MapMyRun) and the trail data can be freely used to build other tools.
Official RAMBA Map v6 from 2018
Over the years of making trail maps with OpenStreetMap I’ve mostly produced PDFs for printing, leaving mobile and online mapping to other apps. These work well, but have the big downside of rendering routes with their style. That is, online maps via these tools’ show the routes, but look quite different from print maps, even if all the data for them to display more data (such as colour=* tags on relations) is in OSM.
While these apps work pretty well, and I use them myself routinely for navigation, I got the itch to see if I could make a web-based map that looked more like locally produced print maps than app-based renderings. It seemed like a good project, a good way to learn some basics of modern web development, and maybe make something useful.
What I ended up with was a slippy map of showing the RAMBA trails that uses layers of pre-rendered tiles to show the different official trail routes, placed over a background map. The map viewer is client-side JavaScript that loads static tiles from a basic web server, making this a very simple app to host (just a bunch of static files on a site).
In this post I intend to document the major steps of how I made this map, why I used the tools I did, and share the code to reproduce (and update) this build. Hopefully this’ll allow others to get their head around these map presentation basics, perhaps even reusing this work to make and host another map.
Update OSM Data
Strava Global Heatmap in JOSM
Mostly outside the scope of this article but worth a mention, a significant amount of time was spent ensuring that the RAMBA area trails are accurately listed in OSM. Without good data it would not be possible to go further, as the OSM data is the base data used to create other maps.
By combining information from a bunch of sources, and doing some personal surveying of trails while riding and hiking, I was able to get all of the official RAMBA trails documented, along with numerous other paths and tracks in the area. This building a complete picture of the usable trails in the area.
Information used to get the RAMBA trails in OSM included:
Hand-annotated map from Danny Hill listing local trail names.
These sources were combined in JOSM, cross-referenced, ways drawn and tagged, relations built out, and before long a complete picture of the RAMBA-area trails — official and otherwise — were in OpenStreetMap.
Most importantly, beyond documenting the trail locations, trails were grouped into route relations to show each official route, and then all the official routes were grouped into a superroute for all the RAMBA trails. As of time of writing, relation RAMBA Trails (12425503) is the superroute that aggregates the individual trail routes such as Epic Loop (8467869) and Malton Loop (8468010).
The result of this is accurate trail data that’s easy to query for and style using other tools.
Rendering Tiles with Maperitive
There are myriad ways to render tiles from OSM data, with most of these involving setting up a database server and a toolchain which’ll generate, cache, and serve tiles on demand. For most large data sets this makes a lot of sense, but for a small trail system I really wanted to use static tiles I could serve from a simple webserver.
Eventually I came across Maperitive, a desktop application for Windows that takes GIS data (including OSM), stylizes it with a relatively simple ruleset, and can generate tiles in the standard XYZ format for use elsewhere. It can also be scripted, which meant I could use it as part of an automated workflow to generate new tiles as the OSM data changes. This seemed like a good solution, so I set about writing some rulesets that would reasonably show the RAMBA trail routes and some automation around it all.
After a lot of experimenting I settled on a having separate tile set for each of the official loops, an overview of all trails, and a base map. The base map would always be shown, and a user can toggle between layers which highlight all the trails or individual loops.
After a few iterations of custom rules, I settled on a simplified set based on the Default.mrules file which comes with Maperitive for rendering the base map. The only modification was changing the font to Michael Adams’ Roadgeek 2005 Transport Medium font, as it looks nicer than the default, Verdana. For the overview and route layers I created simple rules based on the the default rendering of highway=path, using the Heavy version of the font. The rule for each trail route (relation) selects the trails in a given relation then colors them accordingly.
Creating these rules took a bit of fiddling, as Maperitive is both a bit of a dead project, not completely documented, and (in the latest Beta) sort-of buggy where sometimes the map display would stop updating. Still, even though I’m not great at making attractive things, I was able to come up with something that worked well enough.
Conveniently, Maperitive also comes with a command line version (Maperitive.Console.exe). After settling on rendering rules and a tile generation script, I used this as part of an automated workflow which downloaded OSM data directly then rendered each of the tile sets.
After tile generation I used a Windows binary of OptiPNG to losslessly compress the tiles, resulting in a ~62% space savings (original: 746MB, optimized: 286MB) which’ll reduce storage and bandwidth overhead.
The Front End
Editing in VS Code
With tiles generated I needed a way to display them. It turns out that OpenLayers was easy to use and it all ran as simple client side application in a browser. By using npm and parcel, with Visual Studio Code for editing, it was quite easy to get the site developed, tested, and bundled up for deployment. The only component I had to add was ol-layerswitcher control, which provides an easy way to toggle between layers.
Prior to this I had very little experience with modern web development, with my exposure to JavaScript pretty much limited to reading others’ code to figure out what it’s doing. After a bit of confusion (and having to accept the hidden complexity of using an application bundler), I was able to focus solely on writing a single main.js file with a basic index.html that together do what I wanted:
Run full screen by default.
Show all trails by default, with toggles for the defined routes (layers of the map).
Show an attractive background map below the routes to show the rest of the area.
Offer controls to use geolocation to showing one’s location on the map and reset the view to the original map extents.
Look sane on desktop and mobile devices.
This ended up being much easier than I thought, and between the OpenLayers Examples and just some basic programming I was able to get something I’m happy with. Far more time was spent designing the tiles and thinking about what I wanted it to do than writing the code to display it all.
Tile Hosting
The actual map tiles are a number of small PNG files, and a typical session of viewing and panning around the map can result in hundreds of image loads. This was seeming a bit slow when being served from nuxx.net via HTTP/1.1, so I looked into using HTTP/2 to improve performance.
Unfortunately, it was not simple to turn on HTTP/2 here at nuxx.net as I’m using PHP for WordPress, which in turn requires MPM prefork, which precludes mod_http2. I could have set up another web server and such, but for now I’m hosting the tiles in AWS, with the tiles uploaded to an S3 bucket and served via CloudFront.
This should allow for better tile download performance than what I can do from my server. Despite potentially incurring a bit of a financial cost it is a good experiment in hosting tiles in the cloud. I may change this in the future, particularly if it becomes cost prohibitive, but for now it’s working well.
Follow Along At Home
If you would like to generate this same map, start by downloading this ZIP file: ramba_trails_map_code_1.0.zip. It contains the scripts and rules needed to generate the map tiles (ramba.mscript and the .mrules files), the index.html, main.js, and package.json for the OpenLayers-based front end, the .osm file used to generate the first release of the map, and a few batch files that tie it all together.
These batch files are included to will help you out, but may need some editing to fit on your environment:
fetch_osm.bat: Uses curl to download all OSM data within a bounding box that encompasses the Ishpeming/Negaunee area.
generate_tiles.bat: Runs ramba.mscript via Maperitive.Console.exe to generate the tiles.
optimize_tiles.bat: Copies the unoptimized tiles from the .../tile_output/raw output directory to the .../tile_output/optimized directory, then runs OptiPNG against the tiles to optimize them in place.
To build the web app you’ll need to install npm, parcel, create a new OpenLayers app as per the directions here. Then install ol-layerswitcher (npm install ol-layerswitcher), replace the default index.html, main.js, and package.json with the ones I provided, and you should be ready to go.
Updating the Map
As you can see, the map is two major pieces: the front end and the tiles. Whenever the map data changes in OSM the tiles can be regenerated to update those layers. The code for the front end web app only needs to change if the storage location changes, features are going to be added, etc.
Conclusion
This map has worked out rather well and I’m happy calling it v1.0. It’s been a great learning experience, and I’ve even managed to produce something useful that didn’t exist before: an interactive map of some of the most rugged single track trails in Michigan; one of my favorite places to ride mountain bikes.
It’s far from perfect, and there are some things I could do differently, but for now, I’m considering it a success. When in Negaunee for vacation last week I successfully used development versions of this map to find my way around, so I know it’s better than nothing.
If you find any quirks in the map data — such as trails with wrong names or in the wrong location — please take a screenshot and show me what’s wrong and email that to steve@nuxx.net. I’ve done my best to ensure the RAMBA trails are accurately mapped, but I’ve certainly missed some things.
Problems
No key or other ancillary information (such as logos) as are normally found on print maps.
No terrain. While 1m DEM elevation data is available from the USGS, I couldn’t figure out how to use it in Maperitive for generating hillshading.
No easy way to add clickable items to show additional info, link to external map apps (eg: for navigation).
Maperitive’s text rendering isn’t the best, resulting in goofy looking text at some zoom levels.
Long trails only have one label placed on the middle. Trails with one name broken into multiple ways will be labeled numerous times.
Due to being run in a browser it’s a sufficient, but not great, mobile experience. Specifically, selecting the geolocation, recenter, and layer controls can be fiddly because they are so small.
Does not work offline, but thankfully most of the RAMBA area now has good mobile data coverage.
Things To Investigate
Keep an eye on AWS cost and performance.
Look at Leaflet for the front end, as it seems a bit more modern.
Consider rendering map tiles with TileMill. This will add a lot of complexity both in setup and styling tiles, but once done should allow a lot more flexibility in styling and overcome most of Maperitive’s problems. mapbox/mbutil should work for getting XYZ PNGs out of MBTiles files.
Consider using a tile server if I don’t want to deal with discrete files.
Look more into using vector tiles with client-side styling. (I passed on this for now, as a GeoJSON file showing each of the route is a large download and had no benefit over raster tiles.)
Maperitive should run under Mono, and OptiPNG is available for many platforms, meaning it should be possible to reproduce this build under macOS or Linux. Note that the GUI for Maperitive will not currently run on macOS due to Windows.Forms currently being based on Carbon, which is not available for 64-bit macOS. So while the CLI should work, the GUI version isn’t currently compatible with macOS 11.5 (Big Sur) and higher.
Both the Electric Queen and Timberjack were fitted with the same Industry Nine Trail S Hydra 28H wheelset; a really nice value wheelset which mates the amazing Hydra hubs with aluminum rims. Despite slightly denting (and fixing) the rear rim, these have held up great and been wonderful to ride, but I still occasionally found myself missing the stiffness (and durability) of carbon rims.
As the bike sat over winter I figured it’d be a good time to upgrade to the carbon rims, so just before Thanksgiving when Light Bicycle was offering a bit of a sale I ordered a set of rims and got the process started. Between these value rims and (literally) slow-boat-from-China [1] shipping, eBay special spokes, and spare nipples from previous builds I was able to put together a nice, solid, carbon wheelset for about $550 less than if I’d bought a complete similar set from I9. And I’ll have some rims to sell (or reuse).
The Trail S Hydra rims come with straightpull hubs that I9 doesn’t sell separately, but they were nice enough to send me the specifications for them. With some forward/backward checking against the original rims and spokes (597mm ERD, 303mm spokes) I found the DT Swiss Spoke Calculator to work great for these hubs as well.
For rims I chose the Light Bicycle Recon Pro AM930 rim, which is their high end 30mm internal 29er rim with a nude unidirectional carbon finish. As options I chose 28h drilling, black logos, and black valve stems to match the hubs and any bike. (Silver logos would also have been fine to match the hub logos, but I really prefer plain looking rims.)
When shopping around for spokes a deal popped up on eBay offering a whole box of 298mm DT Swiss Competition straightpull spokes, which perfectly match Squorx nipples left over from previous wheel builds. I love working with nipples like these, because they are tightened with a T-handle tool from the back side, which makes building way more comfortable and faster than with a traditional spoke wrench. And it means no chance to mar the anodizing on the nipples.
The wheels were built up using Ultra Tef-Gel as thread prep, to a maximum tension of ~131kgf. Before starting the build I hadn’t realized that the inner and outer spokes on each side of the rim would be a different tension. As their flange offset is a bit different for each set of spokes on each side, necessary so the straight spokes don’t interfere with each other, the bracing angle is slightly different resulting in a different tension.
I did have a slight issue where, when bringing the front wheel to tension and trying to hit the Light Bicycle recommended tension of ~145kgf, the inner Squorx heads broke off three nipples. After this I detensioned the wheel and brought it back up to a lower, but still appropriate, spec. (In the process of figuring this out I ended up cutting two spokes as the nipples couldn’t easily be turned. After the third I detensioned the wheel and decided to build to a lower tension.)
Final tension for the wheels are as follows, with the small number the indicator on a Park Tool TM-1:
Front Wheel (NDS / L / Brake Side is Steeper Bracing Angle):
Per usual with carbon rims building is a matter of centering the rim, eliminating runout, and detensioning the spokes. There’s really no truing (in the traditional sense) because single-spoke tension doesn’t really affect a stiff carbon rim.
Out of pocket cost was $651.13 on top of of the original wheelset, for a total of $1519.27 (excluding tires and sealant and whatever I can sell the old rims for):
A complete Industry Nine Hydra Trail S Carbon would cost about $2015 (with Shipping + Tax), about $500 more than the end cost of building these. While this set doesn’t have the US-made Reynolds Blacklabel rims, I’ve been happy with Light Bicycle rims on previous bikes and anticipate these’ll be just as good.
The final build, without tape/valves/tires/rotors/cassette, comes in at 794g for the front wheel and 917g for the rear wheel (1711g total). This is a 51g savings over the Trail S Hydra build when going to wider and stiffer rims. This isn’t enough weight savings to notice, but at least it didn’t add anything.
When putting the wheels back together I fitted the old tires as they still have a good bit of life left. I also used the original valve stems from Industry Nine as they are a bit shorter and I prefer the brass body versus the aluminum valves that came with the rims. It also turns out that Light Bicycle provided more than 2x as much tape as needed for the rims, which is great for future spare use. (The rims came with two rolls, one roll did both with plenty to spare.)
[1] The shipping notification states: “It is scheduled to board a Matson Liner’ ship for a sea journey of about 3-4 weeks before its arrival at Los Angeles port in the US. Then UPS will pick the package up to manage the local delivery for you. It is only when the pickup is made, the information at UPS website will be updated further as well as you could reach out to UPS by calling 800-742-5877 for quicker help then.”
Unfortunately, the only good solution was to get a different frame. The Salsa Timberjack was my original choice for this hard tail trail bike build, but I got excited by the idea of a steel bike, loved the paint on the Electric Queen, and glossed over the seat tube angle. By the time I realized I needed a new frame the stand-alone black frames were no longer available. Fortunately, over at the excellent Sports Rack Marquette, Evan had some new frames from complete bikes available, and I was able to get a beautiful gloss teal frame from a 2019 Timberjack Deore 27.5+ from them.
Besides matching my wants geometry-wise, the frame is a great choice because all parts except for the headset swapped over, and the frame came with a headset. While the stock Cane Creek 10 is a lower end part, which lacks sealing on the top bearing cover and has a plastic compression rings and crown races and black oxide bearings, it works and will be fine for a while. The fork was already fitted with a higher end matching crown race, and I have a Cane Creek Hellbender 70 headset ready swap in once the bearings and compression ring start to go.
One downside to the Timberjack vs. Electric Queen is that I’ll no longer have a rigid fork for the bike, but if I really want one the Firestarter 110 Deluxe is a perfect match. The top tube on this bike is also a little bit tall, as it’s also designed for bikepacking and fitting a top tube bag, but it’s plenty comfortable to ride and I love all the bottle cage options.
To round out the build and get the colors nice I ordered some new fork decals from Slik Graphics. Unfortunately, I screwed up and ordered the decals for the Factory-series forks, so while it looks good, I technically have the wrong upper logo on the fork lowers. I’ve since ordered another set with the proper Performance decals for the upper, and am waiting for them to arrive. Since this order was placed Slik became involved in a dispute with Fox, so I’m hoping to receive the updated decals. Even if they don’t arrive, at least the colors are right on the fork. I could even remove the upper decals and have it still look good.
When finishing up the build I ran into a significant problem with the brakes: squealing and vibration. Due to part availability I’d purchased the calipers and levers as a non-retail / meant-for-complete-bikes / likely grey market set from a well-known eBay seller, ronde-cycling. I was never able to get them bedded in properly, and after a few rides they began squealing horridly and shuddering under hard braking. This seller offers different pads options with the brakes, and I began to suspect they handle the pads with each brake set sale, did so poorly, and contaminated the pads before they got to me.
I tried the normal recommendations of cleaning everything, sanding the pads and rotors, and even baking the pads in the oven, but on each bed-in procedure they’d begin squealing again. Resolution a set of new J04C pads and a bed-in and now the brakes are working great. At ~$50 for a new set of pads this really added to the cost of the brakes, but at least they are now working.
Final build, with water bottle cages, pedals, and computer came out to right around 27 pounds. And, it fits! Since building it I’ve put over 180 miles and nearly 16 hours on the bike, haven’t touched the geometry, and I’m really happy with the result. It’s exactly what I wanted; a high quality hard tail trail bike.
Get osm2ai.pl working on your computer. I run this on macOS, and it works fine on Linux as well. Since it’s a Perl script there are probably some dependencies; likely resolved by installing a few modules.
Process each OSM file with: osm2ai.pl --input infilename.osm --projection mercator --output outfilename.ai
Open each file in Illustrator, combine them into a larger document, make it look the way you want, etc.
Nearly four years after getting a full suspension XC / trail bike (2016 Specialized Camber) and beginning to really enjoy riding with a bit more travel and a dropper post I started getting the itch to build a similarly spec’d hard tail. Picking up a few particularly good deals (frame/fork), shopping smartly, using some parts I’d collected over the years, and getting some parts from friends, I ended up putting together an All-City Electric Queen.
This steel frame from a QBP brand best known for urban bikes, fitted with a smart choice drivetrain (SRAM GX), higher end wheels (I9 Hydra hubs) and suspension (Fox 34), and reliable brakes (Shimano SLX) is the solid spec build that I was wanting. The frame came complete with a matching rigid fork, and I anticipate switching over to the rigid fork in springtime or when the Fox 34 is out for service.
After the first shakedown ride at Stony Creek I’m pretty happy with the bike. The geometry of the frame itself is a little curious, but it seems to fit me well. Specifically, it has a fairly slack seat tube, tall head tube, tall seat tube, and rather high top tube. This means I have minimal stand-over (akin to the Titus Racer X 29er) and the saddle has to sit quite-forward on the rails, but it seems to work and feels good when pedaling. It also results in the controls (dropper lever and shifter) hitting the top tube when turning the bars, so I’ve had to pad the top tube with some 3M mastic tape.
I suspect this frame would work well for the sort of long-leg/short-torso rider who often finds themselves on a custom frame, but it also works well for me. It also means that a slim top tube bag like the Relevate Designs Tangle would fit along with bottles. Or, it could have been placed almost 1.5″ lower (with a shorter head tube and seat tube) and still been good… But I’m not a frame designer, so I suspect there’s some good but unknown-to-me reason why this was done.
Coming in at 28 pounds it’s not a light bike, but being a cheaper steel frame, 120mm fork with 34mm stanchions, 2.4″ wide quite-knobby tires, dropper post, and aluminum rims I’m okay with it. Going to some carbon bits (eg: bar) I could drop some weight, but I don’t think it’ll matter much, as this is roughly the same weight as the Camber, which I love riding.
Part details are below, and photos of the build showing everything from parts to checking clearances, can be found here: All-City Electric Queen.
Over the years I’ve gone through a few different iterations of bar end plugs for the elastic found inside of pogies such as Moose Mitts and Relevate Designs’ Williwaws. While many of these pogies can be used with the elastic wrapped around the grip, I find this a bit uncomfortable and these iterations happened as I tried to get to something better. Previously attempts were a couple variations on road-type screw-tight bar end plugs with a stack of washers, but after one of these became stuck in my carbon bars during a crash on ice I went looking for something simpler and more robust. I also wanted to avoid the thin washers, as a glancing blow from one during a fall could easily result in a cut.
Shown above is my latest attempt, made from two off-the-shelf parts:
.531 x .870 x 3/16 Nylon Flat Washers (Lowes: $1.28, P/N 423512, Photo)
This setup meets the following requirements and should be an improvement on previous designs:
Easily removable, such as with a screw to tighten / remove.
Resistant to being driven into the bar or bending during a crash or bike falling over in the wind.
Must not have a sharp or narrow edge that could cut the rider.
Compatible with a variety of bar wall thickness; including thick-walled carbon bars such as the Salsa Salt Flat.
To put it all together I disassembled the ODI plug (photo), slipped the nylon washer over the body of the plug (photo), reassembled the plug, then inserted the plug into the bar and and tightened it down like normal. The washer is perfectly sized to set in the recess in the bar end plug while spacing it out from the end of the grip/bar. This ensures there’s a slight gap left for the elastic (photo), keeps the plug from hammering in during a crash, and the rounded bar edges of the plug should minimize injury. It’s also just large enough that it cannot slip past the expander wedge of the bar end plug, which should make removal extremely simple.
Prior to this I’d tried the ODI plugs without a nylon spacer, leaving them set a little ways out from the bar (photo), but whenever the bar end hit the ground during a fall they’d push in and trap the elastic. An alternative would be the Relevate Designs Pogie Bar End Plugs, but at $10 (plus shipping) per pair they aren’t much cheaper and won’t as easily be removable. Being all plastic and press-fit they seem more likely to pull out or be damaged during a crash.
For pretty much as long as I can remember I’ve been interested in experimenting with sound. While I love great music, sounds themselves are most interesting to me. I remember using the shaft of spinning electric motor pressed against the mic of a cheap cassette recorder to simulate chainsaw sounds, putting my ear against different parts of my sister’s Casio SK-1 (where I also learned about ADSR) as the case vibrated and tone changed, and intently listening to The Downward Spiral picking out samples (puffing a drinking straw, fingers brushing over metal grating).
Over the years I’ve ended up owning, and in many case building, a number of piece of music equipment. This ranged from the Electrix suite of effects, some drum and synth modules (Yamaha TX81Z, Alesis D4), self-built x0xb0xes, some MIDIbox SID-NUXXs (where I learned the basics of PCB layout), but they all seemed too oriented around song composition and didn’t work well when I simply wanted to play with sound.
With some self-built gear sitting around on the shelf and a newfound empty space in my closet, I decided to put much of it back together, but this time acquiring something that’s much more hospitable to experimentation: a eurorack-format modular synthesizer. As of now I’ve mostly settled on a suite of modules, with just enough stuff that I’ve still got loads of learning to do and lots to explore. This setup also allowed me to connect some of my older DIY gear; stuff that I’d been longing to hear for a while. Conveniently I had an old analog oscilloscope and quality multimeter, things which are surprisingly useful when troubleshooting why a patch isn’t doing what was hoped.
All set up, it’s as seen above.
When expanding I started out with the basic (but fantastic) Moog Mother-32 and the cost effective Arturia BeatStep Pro, but soon after realized that for the kind of experimenting I wanted to do a few discrete modules would be really nice. While fairly low end (especially the speakers) it’s a good setup for experimenting and deciding how much further I want to take things. I believe I’m pretty well set up and have a lot to learn before I make any additional significant purchases. This setup gives me option for everything from triggering drums and playing with sequencing music from synths to setting up drones and seeing how sound can be tweaked:
A couple years ago I had an older Bomb Pop Blue colored El Mariachi that I used in a bunch of different setups, including rigid SS and rigid 1×9, but mostly it saw use as a hard tail SS with wide wheels. A fun all-around XC bike; I loved it. After building up the Jones Plus (as a single speed) I sold the El Mariachi, but missed it, especially after selling off the Jones. (While nice, I couldn’t justify such a high end single speed like the Jones, and my buddy Bob was really keen on it…)
For everything from might-get-wet rides to trips to Ray’s (where a derailleur can be a liability) I liked having a cheaper, familiar, single speed bike and kept an eye out for something that’d meet the want…
Suddenly, one dreary spring day in 2016, I found what I was looking for: a second hand (but practically new condition) 2015 Salsa El Mariachi Single Speed, in it’s wonderfully weird grey-green color which occasionally looks to my deuteranomalous eyes as brown. Even better, with a 44mm straight head tube and kinked seatpost it features Salsa’s newer El Mariachi geometry; the same as is found on my beloved El Mariachi Ti, a perfect single speed for me. Unfortunately, while I love the frame and its color, I was was never really happy with the anodized orange accents.
After riding it for a year, tweaking some things, reusing spare parts, and finding some mid-winter deals it’s had quite an upgrade. While the stock wheels were nice I wanted higher engagement hubs and wider rims with higher volume tires. A suspension fork, bought used from a buddy in late spring 2016, took the edge off of rough trails. New wheels, a black handlebar (from the Blackborow), and a new seatpost collar did away with the remaining orange. Swapping on 180mm/160mm rotors (also from the Blackborow) brings stopping in line with my other XC bikes. The end result is monochrome parts on a colorful frame, my preferred style of bike.
Topping it all off are Schwalbe’s giant, aggressively knobbed 29″ x 2.6″ Nobby Nic tires which — even on the wide-for-XC WTB KOM i29 rims — fit nicely in the El Mariachi’s frame, getting it close to 29+ territory. While I’m not normally fond of such an aggressive tread for XC use it’s the only tire of its size available that appealed to me. The stock bike build featured 2.25″ Nobby Nic tires and while they felt squirmy on hard pack, they were quite enjoyable when conditions are soft or loose; precisely one of the times when I opt to ride single speed. So, I opted to give them a go. I may eventually switch to something lower knob, but for now they are staying.
More photos, including wheel build numbers, can be seen here, and the complete bike is built as follows:
Post upgrade, tubeless, with suspension fork, without Garmin Edge 520 or rear light, it weighs 26.12 pounds. This is pretty nice for what’s effectively a steel 29+ single speed, with super-grippy tires, in a geometry that I’m very comfortable riding. I have less than $1500 into the bike, which I’m pretty happy with considering how well equipped it is.
I’ve had my Salsa Blackborow for a year and loved riding it in all seasons, but thanks to Tree Fort Bikes I got a line on the brand-new 2017 Salsa Mukluk Carbon frame and decided it was time to upgrade. I love how the Blackborow rides, but a carbon frame with a 100mm threaded bottom bracket is what I’ve really wanted and until now it wasn’t practically available. In designing the 2017 Mukluk Salsa made some slight tweaks to the outstanding Blackborow geometry, named it the Mukluk, added some nice options (dropper post routing, new style Alternators), and built it out of carbon. All parts (except crank and headset) will swap over from my Blackborow, so there was no way I could say no.
Complete, with pedals, bottle cages, Garmin Edge 520, rear blinky light mount, bell, all sensors, and 4.8″ Schwalbe Jumbo Jim tires set up tubeless the complete bike weighs in at 26.48 pounds.
Almost all the parts are the same as the Blackborow build, save for the wheels (upgraded at the end of my time with the Blackborow), stem, crankset, bar, and headset. The crankset on the Mukluk ended up being a unicorn SRAM XO1 fat bike crank which I fortuitously found as a brand new take-off from a Bucksaw Carbon XO1. Fitted with the non-standard 0mm offset chainring (intended for Boost 148 spec bikes), two non-drive side spacers (none on the drive side), the chainline moves to 71.5mm, which is just about right for a 190/197mm rear end fat bike. It was necessary to put both spacers on the non-drive side to get even spacing between the crank arms and chainstays.
On the first couple rides there was occasional heel rub, so I fitted a set of extended spindles for Eggbeater pedals. This is minor and only seems to happen with larger shoes on technical corners, so the extra 5mm Q-factor should help.
Due to a slightly different geometry on the bike and a wider bar (carbon, to hopefully keep my hands warmer in winter) I went with a 90mm stem, which results in the same saddle-grip reach and feels good.
