Nagasawa

July 11, 2015 ~ flihp ~ Leave a comment

My posts have been very sparse recently. Even less frequent have been posts on non-technical topics. To stay true to the title of my blog I’ve gotta step up my posts on “two-wheeled vehicles”. That or change the name. Changing the name would require digging through WordPress menus and since that’s my least favorite thing to do I ran out and got another bicycle so I could blog about it … and ride it.

Nagasawa makes a pretty serious track frame. More serious than me for sure but when I saw this thing on CraigsList I couldn’t resist. It was meant to be. Nearly everything on it is NJS and it’s in very good shape. A few chips in the paint here and there but nothing beyond standard wear. Even better, it’s the right size. You don’t find very many Japanese track bikes that fit someone over 6 feet tall.

The guy I bought it from had it set up for track riding. Since I’ll be riding it on the street I’m in the process of taming it a bit. First things first: get rid of the NJS track seat (aka the “ass-hatchet”). Then I’ll probably have to drop the gear ratio a bit. The wheels are super nice but they’re not beefy enough for every day street riding. I’ll have to start saving before I can get a new set.

Till my next post, enjoy the obligatory bike porn:

Programming the DS1077L Oscillator

March 7, 2015 ~ flihp ~ Leave a comment

My last post documented my first bit of hardware hacking in probably 10 years. I had hoped to have a full post for a related bit of work ready for posting by now but, to stick with our theme, this stuff is hard so I’ve had to break it down into more than one post. Hopefully this won’t be too much of a spoiler but my current project requires a 33MHz oscillator. Here’s a bit of data about the programmable once I picked up along with a few tools I wrote to program it from Linux.

DS1077L Oscillator

Fixed frequency crystal oscillators are pretty easy to buy, but if you’re prototyping on a breadboard these are a bit of a PITA to hook up. As an alternative, there are surfance mount programmable oscillators available and the DS1077L from Maxim seems to be the most popular in the “maker” community. Sparkfun sells these pre-packaged on breakout boards so if you just just want to buy something and start using it this is the route to go.

I ordered the parts individually so I could practice my soldering but the end result is the same. Take a few DS1077L+66s from Mouser Electronics along with a few 8-pin SparkFun SOIC to DIP Adapters, solder them together and then plug them into your breadboard. The only difference is that the breakout board from Sparkfun comes with a filter capacitor so we’ll have to supply our own. This oscillator is programmable via the I2C bus so to program the oscillator to the frequency we need we need to wire it up to the I2C bus on a Linux system. In the end the circuit looks something like this.

Top quality CAD drawing for you there. If you’re interested in the details of how this chip works the spec sheet is your friend. The values for the pull up resistors on the I2C lines and the bypass capacitor are specifically defined there. My purposes are simple in that I just need a 33MHz clock so the CTRL pins can be ignored, as can the reference output OUT0. OUT1 will output the clock and SCL/SDA are the two I2C clock and data pins. Initially the DS1077L+66 is programmed to output a 66MHz clock so we’ll need to program the chip to cut this in half.

Programming the DS1077L

The first step in this process is wiring the circuit and attaching it to the I2C bus on a Linux system. I soldered an I2C header on to my PCEngines ALIX3d2 and hooked it up like so:

This chip is pretty sophisticated so I won’t cover all possible configurations. The data sheet is readily available here so if you want the details have a read (you should anyways if you’re using this chip). All I’m going to cover here is scaling down the clock frequency and the tool I’ve written to do so.

The primary output (OUT1) has two mechanisms for controlling its output. First is a prescaler circuit that can divide the native frequency (66MHz) by 1, 2, 4 or 8. The second is a divider circuit that can divide the frequency by integers between 2 and 1025. The divider circuit can be bypassed completely if we wish so we can get a 33MHz clock in two ways: 1) set the prescaler to 2 and bypass the divider or 2) set the prescalar to 1 and the divider to 2. The DS1077L defines a low power state where much of it’s internal circuitry is disabled including the divider so I opted for this low power state and the first option above.

To aid in programming this thing I’ve put together a small set of tools I’m calling ds1077l-ctrl. These tools expose a simple command interface for modifying the state of the control registers in the DS1077l. As an example we would program this chip to output the 33MHz clock that I need like so:

$ ./ds1077l-mux --bus-dev=/dev/i2c-0 --set --pdn0=0 --sel0=0 --en0=0 --div=1 --p1=2

That’s it. The –help / –usage messages for the tools combined with data from the spec sheet should be all that you need to set the DS1077L to any possible state. In the command above we’ve set (–set) the DS1077L device on I2C bus 0 (–bus-dev=/dev/i2c-0) such that the divider is disabled (–div=1), the prescalar to 2 (–p1=2). The other options (–pdn0=0 –sel0=0 –en0=0) set the oscillator to a low power state disabling the circuitry we’re not using.

To get a sort of before and after I hooked up this chip to an oscilloscope to capture the default 66MHz waveform and the 33MHz one we get after executing the command above:

Bugs

This software is not without bugs (as always). I couldn’t get the WRITEE2 command to work properly but it’s only necessary if you change the default behavior of the chip and set the WC bit to 1. This causes the oscillator to write register state to EEPROM only when the WRITEE2 command is invoked. By default it will save the register state every time it changes so just leave the WC bit alone and everything should work as expected. Alternatively feel free to fix this bug and send me a pull request.

twobit auto builder part 1

November 29, 2014 ~ flihp ~ Leave a comment

I’ve been a bit out of commission for the past month: starting a new job and moved a long way to be close to it. Before the move I had a bit of a backlog of work to write about and things have finally settled down enough for me to start working that off. This first post is about the work I’ve done to learn a bit about buildbot and how to use it to build some stuff I’ve been working on.

I’ve always been a bit of a “build junkie” and I’m not ashamed to admit that I really like to write Makefiles by hand. Learning buildbot was only partially motivated by masochism though. The other half was motivated by my need to build a few different projects including the meta-measured OE layer, the meta-selinux OE layer and OpenXT.

I’ve put this work up on github and it still needs some work before it’s portable to anything beyond my build setup. I hope to make this reproducible by others but before I do that I want to:

introduce these repos
cover some of the buildbot internals but only the bits required to make the build work

In doing this work I definitely fell down the rabbit hole a bit and started reading a pile of buildbot code but a lot of it was above and beyond what’s necessary to get this stuff building. I’m often guilty of wanting to understand everything about a piece of code before I start using it but that’s not always the right approach. I’ll do you all a solid and leave this stuff out to save you the hassle. This first post will cover the repo containing the buildbot config I’m using. My next post will cover some support code I’m using to trigger builds. I’ll focus on the bits necessary to build OpenXT initially and will include a quick write-up of my other side projects soon after.

twobit-buildbot

There are two repos that make up this work. The first is the actual buildbot config for both the build master and slave(s). It’s up on github here: twobit-buildbot. The second repo is a twisted python daemon that supports the build master and slave. I’m calling this last repo twobit-git-poller. This post will discuss this prior. My next post will cover the git poller.

Build Master

The buildbot config for both the master and the slave(s) I’m using are available on Github here: twobit-buildbot Buildbot configs are a bit hard to call “configs” with any seriousness since they’re proper python code. Still, it’s “config-like” in that there’s really no business logic here. It’s just a pile of classes that you filled with data and passed to the buildbot guts for execution.

If I go line by line through the config then this will quickly digress into a buildbot tutorial. There are plenty of those out there and if you’re interested in getting a deeper understanding then you should start with the buildbot docs. The steps that buildbot goes through to build a project are all wrapped up in a container called a BuildFactory. In my repo the BuildFactory for OpenXT is defined here. This class wraps an array of BuildStep objects that define a series of steps required to build the software.

The BuildStep objects are processed in the order they’re passed to the BuildFactory. I’ll run through these in order just to give you a feeling for the build progression:

The first thing in building OXT is to clone the build scripts. Buildbot knows where on the build slave to check this stuff out so all we do is provide some metadata to tell the buildbot git fetcher how we want the checkout to happen. OpenXT doesn’t yet support incremental builds so for now each new build requires a clean checkout.
Next we execute a shell command on the slave to set up the build config. To do this we use the ShellCommand class which is exactly what you’d expect: it executes shell commands. But with buildbot it’s always a question of where: on the master or on the slave? AFAIK for most build bot stuff you should assume that the action will happen on the slave unless otherwise noted. I’ve rigged the build master configs such that the script name isn’t used explicitly. Instead it’s a shell variable that the slave is expected to set here. I’ll describe this a bit more in the next section describing the build slave.
The next build steps are a series of shell commands that execute the series of build steps that make up the build of the OXT build. These are hard coded as the minimum necessary to create an installer iso. These are all invocations of the do_build.sh script. We could just as well just execute the do_build.sh script and have it get the build steps from the .config file but it’s nice to execute them one by one so that the buildbot UI shows them as unique steps. This also makes it easier to go through the output logs when things go wrong.
Once the main build steps are done we need to get the build output to a place where people can download it. So the next step runs a MasterShellCommand to create a directory on the build master. In the case of my build master this is on an NFS mount that gets served up by my webserver. That should tell you how we serve up the build output once it’s on the build master.
Now that we’ve got a place to stash the installer iso we need to move it from the build slave to the build master. OXT has some script functions in the build script to rsync build artifacts to various places. Buildbot has a build step to handle this for us so I’ve chosen to use that instead. Hopefully we’ll retire the bulk of the custom OXT scripts and use the tools available like the FileUpload class in buildbot.
Unfortunately I ran into a nasty buildbot limitation after getting the build upload to work. The version of buildbot packaged for Debian Wheezy runs the buildbot daemon with very paranoid umask (022). This was resolved 3 years ago but Wheezy doesn’t have the fix. I opted to hack around this with an extra build step instead of requiring people to install buildbot from source or apply a patch to the Debian packages. This hack is ugly but it just runs a scrip on the build master and fixes up the permissions on the newly uploaded file and directory housing it.

The BuildFactory describes how to build something but we still need something to do the building. This is the job of the build slave. The BuildlerConfig is an object that associates a build slave with a BuildFactory. When the build master determines that a build needs to be run the buildbot code will go through the available BuilderConfig objects, find the right config, and then walk the build slave through the right series of BuildSteps.

Build Slave

Naturally we assume that the build slave executing these steps is capable of building the project which in this case is OpenXT. That is to say you’ve followed the steps on the OpenXT wiki to set up a build machine and that you’ve tested that it works. Further, I’ve only tested this with the buildbot package from Debian Wheezy. The build master can be a simple Wheezy system, no need to jump through the hoops to make it an OXT build system since it won’t be building any code.

The config for a build slave is vastly more simple than the master. It only needs to be able to connect to the master to receive commands. The only really interesting bit of the build slave config is in a few of the environment variables I set.

Each of the OE images build my slave is building requires a sort of generic “setup” step where the slave sets some values in a config file. This is simple stuff like the location of a shared OE download directory or something specific to OpenXT like the location of the release signing keys. In each case there’s a script in a bin directory. For OpenXT that’s here.

The path to these scripts doesn’t need to be known by the build master. Instead the build master expects the slave to have a specific environment variable pointing to this script. The build master then tells the slave to execute whatever this variable points to. The build slave only has to set this variable properly in its config like this.

Wrap Up

That’s just a quick rundown of the buildbot bits I’ve strung together to build my pet projects and OpenXT. There’s one glaring gap in this: how buildbot knows when it needs to run builds. This is usually a pretty simple topic but with OpenXT there were a few things I had to work around. I’ll fill this in next time.

Till then I’ll be keeping the configs for my build master and slave on github and as up to date as possible. Feel free to reproduce this work in your own environment if you’re interested. I may or may not keep the build master exposed publicly in the future. For now it’s just intended to be an example and a convenient tool.

TXT Capable Desktop Virtualization System

August 9, 2012 ~ flihp ~ 2 Comments

Having worked on XenClient XT for the past year I’ve experienced the pain of debugging vendors TXT implementations first hand. TXT may be a nearly 6 year old technology but it’s just now coming into use and many vendors platforms have only received internal testing. We’ve found a number of ways for platforms to fail in strange ways and we’ve had to work with the vendors to get their implementations working for a system like XT that uses tboot as part of our measured launch.

For development Citrix has provided me with a number of systems but I’ve been meaning to put one together for myself for some time now. I’ve always liked building my own so I wasn’t thrilled with the prospect of purchasing a Dell / HP system. Home builds are always a bit cooler, a bit cheaper, and more fun in general. That said I was a bit worried about being able to find a motherboard / CPU combo with full AND WORKING VT-x, VT-d and TXT. It wasn’t as bad as I expected. So the following is a breakdown of the home build system I put together specifically to run XT.

Case

I always start building systems with the case. This will dictate size which in turn limits your choices for motherboards. I’ve had a string of successes building systems in Lian Li cases so again they were my first choice. I wanted this system to be as small as possible. Lian Li happens to make probably the best mini-ITX case on the market: the PC-Q02A. This case is tiny and it comes bundled with a 300W power supply. No room in the back of the case for PCI cards either so if you buy this don’t expect to throw a graphics card in it. Whatever you need has to be on the motherboard!

CPU

Since I intend to run XT on this system the CPU has to support the full Intel vPro suite including TXT. This limited me to high-end intel i5 and i7 processors. Since this system will be in a small, low power case I wanted a 65W CPU and went with the Intel i7-2600S. CPUs aren’t really where you want to save money on your build so I didn’t skimp here.

Motherboard

The motherboard is really where vPro and TXT are either made or broken. The BIOS is where CPU features are either enabled or disabled and many motherboard vendors don’t list anything in their docs about TXT compatibility. This is mostly because home users typically don’t really care. In this case we do so some research is required. I played it safe and went with an Intel DQ67EP. TXT and the TPM worked flawlessly. One thing that was a deviation from the platforms from Dell and HP I’ve played with was the TPM came without an EK populated. It’s a simple case of running tpm_createek on the system but because all of the vendor platforms come with an EK pre-populated the XT code doesn’t account for this situation. Easy to work around.

RAM

From here it’s just a matter of getting RAM and hard drive / CD-ROM. Since this system will be running virutalized desktops the more RAM the better. XT doesn’t over commit RAM so if you want to run two desktops with 4G of RAM each you’ll need a bit more than 8G of RAM since the dom0 and service VMs will need a bit too. I picked up 16G of G.SKILL Ares RAM. Generally I run 3 desktops: one Debian Squeeze for development, one Debian Wheezy for my personal stuffs and one Windows 7 for required email and GoToMeetings each with 4G of ram. This system has no problems handling all 3 at the same time.

Disks

Hard disk is always faster and bigger is better. This is where I saved money though since I’ve already got a huge (6T!) NFS server for bulk storage. I went with a modest 120G OCZ Agility 3. I haven’t done any benchmarking but it’s big enough for my root filesystems and fast enough as well. I also put in a Sony Optiarc BC-5650H-01 6X Slim Blu-Ray Reader. I got in on the cheap from an ebay seller. It’s one of those fancy slimline drives so there’s no tray to eject. I hardly ever use optical media except to rip CDs on to my NFS storage. Not sure how much I’ll use this but it’s nice even though it doesn’t match the case 🙂

Photos

I wish there were something in this last photo to give some perspective on the size of the case. Basically it’s the size of a lunchbox 🙂

XT Configuration

Once it’s all put together with XT installed it pretty much “just works”. The USB stack on XT isn’t perfect so some USB devices won’t work unless you pass the USB controller directly through to a guest using Xen’s PCI passthrough stuff. Since XT doesn’t support USB 3.0 anyways I’ve passed the 3.0 controller on the motherboard through directly to my Windows 7 guest to get my webcam working. The Plantronics headset you see in the photo works fine over the virtualized USB stack though and together they make for a pretty sweet VoIP / Video Converencing / GoToMeeting setup. So that’s it. A home build Intel i7 system with 16G of ram, an SSD and Intel TXT / measured boot running XenClient XT. Pretty solid home system by my standards.

Troubles with Ovi Store after upgrading N8 to Anna

January 18, 2012 ~ flihp ~ Leave a comment

I took some time yesterday to upgrade my beloved Nokia N8 to the new(ish) Symbian^3 Anna build and it wasn’t a smooth upgrade. Upgrading through the Ovi Suite went well enough but applications like the Ovi Store just wouldn’t work after the upgrade. The Ovi Store application would install and start but would sit on the splash screen showing the “Loading …” message. At this point I did a hard reset that did nothing.

After combing through a hand full of forum posts I ran across this one in the Nokia Europe discussion boards. Initially I had no idea what this guy was talking about. I guess I’m used to my phone being an appliance so downgrading packages seemed pretty crazy, especially since I had no idea where to obtain the packages (sis files) described in the post. A few web searches later and I ran across the “Fix Symbian” site. Pretty encouraging name all things considered. Anyways all I did was download the sis files from the post titled “S^3 QT 4.7.3 MOBILITY 1.1.3″ which downgrades a number of components in the ” Notifications Support Package Symbian3 v1.1.11120″ package. Once quick reboot and Ovi Store was back up and running.

So I guess the Anna upgrade that Nokia is shipping is broken? Pretty strange really but not something that can’t be worked around thanks to some contributions from the interwebs. Unfortunately the upgrade to Anna didn’t fix the problems I’ve had with my N8 and my wireless access point. I’ll debug this sooner or later, likely when I upgrade my home network with the ALIX boards I got in the mail last week.

Spanish Thruxton

October 28, 2011 ~ flihp ~ Leave a comment

I travel a bunch but I’ve only traveled internationally twice now. Interestingly enough in my short trips to both the UK and Spain I’ve ran into my Thruxton’s foreign relatives. Naturally, the Spanish Thruxton I came across this week in Barcelona is red.

Minuteman Bikeway and the Bike Stop

August 28, 2011 ~ flihp ~ Leave a comment

With today a wash because of Irene, I figured I’d write up a fun bike ride I took last weekend on the Minuteman Bikeway. It’s a fun ride but on a Sunday it’s pretty crowded. There’s a good mix of little kids and Lance Armstrong wannabes, perfect for keeping things interesting.

I covered the whole trail in both directions, even had a chance to stop at a shop called the Bike Stop that’s right on the trail. Be careful going past this place. There were lots of people out there either chatting or getting air and people have this nasty tendency of stopping their bikes on the trail or wandering out without looking.

The shop was nice though and the guys working there where fun to chat up. Always a good time talking to people that work at a bike shop when you pull up on an unusual bike. They always have cool stories and know about some random hardware. These guys had a really nice shop and the snacks were just what I needed. Here’s the evidence:

Mosfet R/R on Triumph Thruxton

June 23, 2011 ~ flihp ~ 5 Comments

A while back the charging system on my Thruxton started failing. I found this out one morning while I was a few hundred miles from home in New Hampshire, my bike wouldn’t turn over. Luckily the place I was staying had a battery charger (dumb luck) and a few hours later my battery was back to full power. My battery then began to die slowly but it got me through the rest of the trip.

At first I didn’t get what was going on. Really I just through my battery was dying but after poking around in some forums I got a tip to fire up my bike and check the voltage that my charging system was putting out. It should put out around 14 volts but it was only putting out 11.5V.

This is a sure sign that either the magnets on your stator is bad (this never happens from what I’m told) or your regulator / rectifier (R/R) is dead. A little more research turned up that the stock R/R on Triumphs are rubbish and generally fail after a few years. Replacing the stock R/R is a pretty standard upgrade on lots of bikes.

There’s a number of after market R/Rs to chose from. I found a few guys who had good results with a Msofet R/R. There’s even a guy that sells kits for the upgrade at roadstercycle. The instructions on the roadstercycle site aren’t very detailed so I figured it might be useful to have a detailed howto (aka lots of pictures) for those like myself new to doing electrical work on their bikes.

Installation

The installation has two main parts:

First is preparing all the wiring: attaching the connectors from the kit to the existing wires from your stator and the power/ground wires provided in the kit as well as running the power and ground wires to your battery.
Second is finding a place to mount your new R/R on your bike. Depending on your bike this may be very easy or very difficult so YMMV.

I started with the wiring because mounting stuff on your bike is usually pretty permanent. This typically involves drilling / cutting and if something goes wrong and the new R/R doesn’t work you’re stuck.

Wiring

So the kit ships with these really fancy waterproof connectors that match up with the connectors on the R/R. There are two of them and they both accomodate 3 wires but one has the center hole plugged. This one is for the power and ground that will attach to your battery. The connector with the three holes open is for the three wires from your stator.

I started with the stator wires. They’re located at the engine casing on the right side of the bike. Follow them up to the connector where they hitch up to the wiring harness. On the Thruxton this is a 3 pronged connector and the three stator wires are bundled together in a black casing.
Sorry for the picture quality (focus is way off). I’m still trying to get the hang of of this new phone.

Cut these three wires right at the connectors to keep as much wire available as possible. You’ll have to run these to the new R/R wherever you decide to mount it. Once the old connector is off, you’ve got to put the new connector on.

The kit provides a bunch of crimp-on connectors:

You’ve got to:

Strip about an inch off the wires casing
Slip one of the provided water seals on the wire. This will be used to plug up the hole in the back of the connector.
Slip on a bit of shrink tube. My stator wires were too thin for a good seal with the plugs so I put on some shrink tube to fill the gap.
Fold the exposed wire in half to give yourself enough surface to crimp the connector
Crimp on the connector, you can even throw a bit of solder on too if you’d like but it’s not necessary.
Slip the shrink tube up over the crimp and shrink it down
Slip the water seal up over the shrink tube

Do this for each wire

Then slip the three stator wires into the back of the connector. Make sure to press each water seal into the connector. If the fit is tight grab some silicon and lube up the rubber plugs.
I’m not sure I put the rubber plugs on in the right direction but the seal will work either way. I switched the direction when I put together the plug for power and ground.

Then do the same thing for the power and ground wires. These wires are much bigger (10 or 12 gauge) so I didn’t use shrink tube this time. Also the rubber stoppers were much more difficult to fit into the connector so keep your silicon handy.

Next you’ve gotta wire the fuse provided in the kit into your new power line and put the provided ring connectors on both power and ground. Nothing special here.

By this point you should have your stator wires set up with the new plug, the power and ground wired into the other plug, and the new power and ground wires ready to hook up to your battery.

Mounting the R/R

With your wires done you can start thinking about where you want to mount the R/R. Be sure you’ve got enough wire to reach the R/R wherever you mount it. BUT FIRST you should test the R/R to be sure the thing works.

Plug in those connectors you just put together, connect the power and ground to your battery and fire up your bike. The voltage across your battery should be between 14V and 14.5V.

If the voltage is right get ready to mount the R/R … if it’s not, well you screwed something up. Sorry. Break out your debugging gear and get to work. Hopefully you just screwed up a connection and you’ll find it quickly.

Once you’ve verified the R/R works pick out your mounting location. I installed a fender elimination kit (FEK) from newbonneville.com a few years back. They still sell a kit but it’s significantly different from the one I bought. Regardless the battery box from the kit has a piece of metal hanging off the bottom to act as a sort of mud guard. The inside (toward the engine, away from the rear wheel) of this is just the right size and location to mount the new R/R.

The Mosfet kit doesn’t come with mounting hardware so you’ll need to pick up some up. I got mine at the hardware store down the block. I think the bolts were 6mm but I can’t remember. Just bring the R/R into the hardware store with you and try the hardware before you buy it. I picked up some lock-washers too for good measure.

Next I drilled the holes in my battery box. It’s impossible to get a drill into the right place without pulling off the wheel and going in through the rear. Remember, measure twice and drill once. Then mount the R/R, run the power and ground wires up to your battery and you’re done.

If you want to get fancy you can secure them with some zip ties. In the pictures you’ll see I haven’t got around to that yet.

Clean up

The stock R/R on the Thruxton is mounted on the front of the bike below the headlight on the same bracket as the blinkers. This is pretty much on the opposite end of the bike as the battery and the stator wires. This means that the stator wires run into the wiring harness back by the battery and extend to the front of the bike to plug into the R/R. The power and ground wires then come out of the R/R to the wiring harness and run back to the other end of the bike where they plug into the battery.

This is completely insane IMHO. You’ll notice I didn’t use any of the existing wire in the harness. All I did was snip the stator wire and tape up the old wire leaving the harness alone. Cutting into the wiring harness should be avoided at all cost. You can do the same to the stock R/R on the front of the bike. Just cut it off and tape up the wires.

Good luck.

2011 ride up Vermont route 100

June 20, 2011 ~ flihp ~ Leave a comment

My vacation last week was spent on the road riding with a few buddies. The highlight was definitely the ride out to Bike Week. We spent the night in Wilminton VT, rode up route 100 to 17, then back down to 89 then on to Alton Bay … with a stop at the Broken Spoke Saloon first naturally.

Here’s the route. In the less than perfect weather it took us about 12 hours including stops but it was worth every muscle ache and every minute in the saddle.

Icon 7614 shocks arrive damaged

May 31, 2011 ~ flihp ~ Leave a comment

After trying a set of KYBs from a Kawasaki ZRX and finding them too big to fit under my Predator exhaust I started looking for a set of shocks with a lower profile. I found these Icon 7614s on the NewThruxton.com. They don’t have all of the adjustments that the KYBs do but they definitely look thin enough to fit under my exhaust and they’re a lot lighter weight.

They arrived two weeks ago but I’ve been traveling for work and just got around to putting them on today. In the photo above they look great but when I unboxed them I noticed some damage on the springs. The damage is super obvious up close. I can only speculate how they were damaged but it probably happened before they were assembled because the rest of the shock body is perfect. But the plastic coating on the springs on both shocks is scratched down to the metal in a few spots. Here’s what I’m talking about:

The damage looks like they rubbed up against something. The reflection of the lights makes it a bit difficult to see at first but I’ve rotated the shock to the left a bit to offset the reflection. I’ve marked up the place where the plastic coating was stripped down to the metal underneath and provided a good close-up. Looking further down the spring you’ll see other places where the plastic was stripped away and there are a few where it’s gone through to the metal.

What a pain. I was really excited to get these on. Even worse than having to go through returning them is that I probably won’t have them on my bike for my upcoming ride up route 100 through Vermont. Not much I can do now but try to get NewThruxton.com to take them back. Not happy.

UPDATE: Added better photo.