The executive summary is that an SKS Chainguard, Sugino XD2 double, and old Campagnolo derailer are not a compatible combination; there was no way to make it all fit. It may be that the bottom bracket (115mm, absolute minimum width) was a hindrance.

I had hoped for something like this which we had on some rental bicycles in England:
Chainguard on an English rental bike w/ derailer
but I could not find that particular chain guard, and in hindsight it looks like the cranks are curved in a way that helps it work.

I tried lots of bending and shaping, but it looked like I would never get the clearance that I needed. I think the main impediment might be the pedals.

Here’s a Flickr set documenting all the steps; I could annotate this a little better, if someone wants me to do that. I documented my mistakes, too (accidentally put chain guard on with chain trapped behind, had to dismantle to bring around, one of the adjusting screws was insanely tight).

I was originally somewhat enthusiastic about the possibilities for self-driving cars, because (in theory), they would make it much easier to carpool and/or run point-to-point transit instead of one-large-size-fits-all buses on inflexible routes.

But then, I thought about how much these cars would initially cost, and who their initial market would be. Early adopters are not buying this buying it to carpool; they’re buying it so that they can get work done on their horrible long commutes.

And then I read that Google thus far had only made it work by mapping Mountain View down to the last detail, and mapping is labor-intensive. Getting the rest of the country mapped is going to be costly. On the other hand, with their algorithm, unless you have the data, you don’t have a self-driving car. How convenient for Google. But how to get the data?

And then I realized that it gets back to the first customers — if their main value from the car is for their daily commute, which is repetitive (probably) long, if a self-driving car is instrumented well enough to record the route, the early adopters will buy the cars, train it for their commute, and it will ship the road data to the mother ship. After some small number of training runs the car can drive itself — not everywhere, but on the commute, and for each customer, that is what is important.

Note that this is far from the crazy utopian vision of self-parking cars that deal with that particular hassle, and it’s not cars traveling bumper-to-bumper in an energy- and road-space conserving pack, and it’s not cars automatically negotiating their way through signal-free intersections — it’s for the commute. Eventually this will lead to enough mapped roads to actually count as “coverage”, and people will be able to buy cars and expect that they’ll know the way. But I don’t think that the cars will be programmed to optimize road use or energy consumption. Recall who is buying them and what for — the most likely goal is to drive in a way that someone riding inside and using a laptop or reading a book will not get carsick.

I’m being called in as IT consultant by my wife, who uses SPSS.
Today, mysteriously, it started INTERMITTENTLY failing with messages
like “Serialization scheme was not recognized” and “Could not instantiate a required server object”.

My snap answer (knowing that it has Java in it, and knowing that “serialization” is a magic word) was to suspect some sort of a Java version mismatch — but I didn’t see any evidence of a recent update at all. I go looking online, and all the advice tends to revolve around Java, but none of it has been updated (I looked inside the application’s package contents, nothing looked new there, there was no other new Java on the box). One thing that looked a little peculiar was in ~/Library/Application Support/IBM/SPSS/Statistics/22/Eclipse/configuration/nl/en_US/ . There, org.eclipse.osgi and org.eclipse.update had both been touched TODAY, “right around when the problems started”.

So WTFF Eclipse doing in my wife’s SPSS “Application Support”? She does not use Eclipse.

So I shut down SPSS (took it minutes at 100% CPU, ???) moved the IBM folder over out of the way (made sibling directory “NOT”, moved IBM and the other sibling SPSS folder into NOT) and restarted. This appears to have made things better.

Short trips in cars

April 9, 2014

Discussions about replacing car trips with bicycle trips often focus on commutes, and whether those are too long or too unpleasant/unsafe. However, it turns out that commuting trips are only about a quarter of all trips, and also disproportionately not-short, so this makes cycling look less practical than it actually can be. Here are bar charts, taken from data from ORNL about vehicle use in 2009, where the heights of the charts were chosen to (1) be roughly in proportion and (2) split evenly into four parts on the cumulative-amount scale. Each pair of bars shows the number of trips of a particular length in miles (blueish bar), together with the sum of all trips that long or shorter (reddish bar). The first chart, with height to scale, shows how this is distributed for commuting vehicle trips only, the second chart shows how this is distributed for all vehicle trips.

Thus, it’s easy to see that half of all vehicle trips are five miles or less long, versus commuting, where the median trip distance appears to be closer to 8 miles (extrapolating on the 5-9 scale). Note also that there are more “all trips” that are three or fewer miles long and not commutes (76.5 billion total, comprising 11.4 billion commuting trips and 64.1 non-commuting trips) than all commuting trips combined (60.8 billion).



Short trips, however, don’t amount to that many road miles. Putting people on bikes may make cities quieter, cleaner, and safer, and their riders healthier, but it won’t put that big a dent in fuel use.



Excel version of the spreadsheet used to make the charts.

Original spreadsheets from ORNL.gov.

The charts were produced in Numbers, exported as PDF (which is a vector PDF), then imported into OmniGraffle (Pro), with the irrelevant bits of the PDF quickly pruned out as objects. The four charts were then exported as SVG (which is what the “Pro” gets you).

This does not count carbon taxes (ought to be 25 cents per gallon) or pollution taxes (in the range of $1 to $1.50 per gallon, based on location) or noise taxes or crash risk to others (in theory insurance captures this, but insurance may not pay out if a smashed pedestrian or cyclist was “at fault” — but without the speed and bulk of the car, harm would have been smaller) or congestion costs. This is just the cost to build and maintain the roads. The images links to the spreadsheet containing all data and links to documents from which it was obtained; these are all government sources, either EIA, FHWA, or Federal Reserve.

No, bicycles do not tear up roads, nor do they pollute or make noise. Their crash risk to others is many times lower, and because they take up so much less space their congestion costs are correspondingly lower.

It is common to read car aficionados claim that people on bicycles don’t pay “their fair share” of the roads, even though anyone with a lick of sense would worry that a gas tax not adjusted for inflation since 1997 might not be covering costs — right now, it’s only covering about half, and the rest comes from other taxes.

However, it is also true that cyclists don’t pay any tax or user fee specifically targeted at the roads; sure, the drivers are 50% subsidized by other taxes, but cyclists are 100% subsidized (that the subsidy for drivers is four orders of magnitude larger(*) is irrelevant, of course, we’re talking about the principle here). This compromises our smugness, and that cannot be allowed. We must devise a user fee for bicycle riders, and pay it. Furthermore, we must not just pay 50% of costs; we should pay 100%, so that we may remain the smuggest of the smug. It may be a high price, but for smug, it will be worth it.

The best route for administering this user fee is through bicycle tires. Bicycles don’t run on any special fuel, but they do consume tires at a steady pace, and there is even some correlation between the size of the load and the size of the tire — larger tires, expected to carry heavier loads and last longer, could be assessed a higher fee.

How much should this fee be? The standard, conservative formula for road wear is that it is proportional to miles driven times the sum of the cubes of the weights on the wheels — that is, a 3000lb car with 4 wheels has 750lbs per wheel. Cubed and summed, the result is about 1.7 billion (1.7e9).

A moderately heavy cargo bike might weigh 400lbs, or 200 per wheel. Cubed and summed, you get 16e6, or about 105 times less. That car might get 25mpg in city driving, and pays an average tax of about 50 cents per gallon, or 2 cents per mile. Given that this is only 50% of cost, the full price would be 4 cents per mile. (Yes, gas taxes ought to be $.50 per gallon higher, if we are to stop subsidizing car use from other revenues. Can’t you feel a good smug coming on?). Since the bicycle does about 100x less damage, a fair user fee for a cargo bicycle traveling 1000 miles would be about $.40. In my case, at about 2500 miles per year, a whole shiny dollar. Per-tire, since a tire lasts about a year for me, $0.50.

However, my calculations are not exactly fair to all the non-cargo bike users. Someone who weighs only 170lbs riding a 30lb bicyle has only half the weight per wheel as my bike (when well loaded), and thus does only one eighth as much road damage — that is, $0.05 per 1000 miles. To account for this, I would tie the bicycle user fee to the tire size, since that correlates loosely with load; for a 60mm tire, it should be about $.50, but for a 30mm tire it should be closer to $.10 or perhaps even less. Perhaps a tiered pricing scheme would be best — $.50 for 60mm or more, $.35 for 50mm or more, $.20 for 40mm or more, $.10 for 30mm or more, and $0.05 below that, because those tires wear out faster and their users tend to be lighter yet. (Fine tuning these numbers might take a little more analysis, but they are clearly in the ballpark.)

It’s a stiff price, but I think it’s necessary to preserve optimum smugness and superior attitude. We’ll pay our full share, not just our fair share, and we can look can drivers in the eye again and say “hah! who’s the freeloader now?” We can call the highway department, “goddammit, I PAID MY ROAD TAX, why aren’t these potholes fixed?!” It will be awesome.

(*) back-of-the-envelope estimate — about 100 times as many people putting serious miles on a car as putting serious miles on a bike, and a bike is at least 100 times less damaging to the road, and a typical car is driven at least 3 times further. Roughly, 30,000x more road damage done by drivers, assuming they’re all driving average-sized cars.

This is the plan, anyhow. N-1, I designed long ago, finally built, and with the exception of broken wires, a confuso (OVERFLOW vs OVERVOLTAGE), and a units error (4000Hz “ticks” versus 1Hz “seconds”), it appears to work. The only remaining mystery is why not all the zero crossings are detected; I went so far as to determine that the cause is on the analog side, and I think before I worry too much about it I will check to see if it matters, or if I can fix it in software.

So, why do I think this one is better? First, it is not sensitive to the LED load; it just runs whatever you put there, pulling the right amount of current form the hub. Second, it has a switchable doubler, so the lights come on at low speeds, but then the doubler turns off at high speeds for more efficiency and less need to limit current. Third, you can do whatever the heck you want with timing and flashing patterns. Fourth, on the advice of Wiley, it uses screw-down terminals, which is a good thing (most first controller just died, from a corroded+broken wire) and allows easier repairs in the field. Fifth, it has “everything”; it can be reprogrammed in place, it can supply at least a half-amp of 5V current for phone charging, it has an optional input for solar panels if that’s what you want, it has a shunt for overvoltage protection, and it has a switched optional input for batteries (or capacitors) for a standlight.

The prototype (which proved most of this would work) has several flaws; among them, I was still suffering from the delusion that I could stick it in side a frame tube. That’s not such an awesome idea. Making it in one compact lump allows all the capacitors to be lashed down tight, allows the screw terminals, and reduces the need for extra wires. The whole thing is relative compact — 5cm by 10cm, with a bit of the BuckPuck sticking off the end, and the capacitors piled about 3cm high.

Tiny84OpAmpBuck

And there’s a wee bit of software….
Read the rest of this entry »

Follow

Get every new post delivered to your Inbox.

Join 171 other followers