<<  Page 13 of 14  >>


Runaway Starter

“Hmm, I shouldn’t be going anywhere with the car making a noise like that.”

I pulled back into the driveway, and turned off the ignition.

The engine went off, but the growling noise that had disturbed me continued.

I got out of the car, opened the hood, and looked. The engine wasn’t vibrating the way it does when it’s running; so, as my ears had already told me, whatever was making the noise didn’t involve pistons and cylinders and such. So was the noise electrically powered, or was fuel leaking someplace and burning? No smoke was coming out of anywhere I could see. Should I disconnect the battery? Go get a voltmeter and see whether the battery is draining? Or perhaps go get a fire extinguisher? Could combustion from a leak really be that regular and uniform, even inside some hidden space from which no smoke could escape? (In retrospect: no; and disconnecting the battery would be the right thing to do even if there were a fire.)

I stood there trying to figure out what to do for a minute or two, until the noise stopped with a bang, accompanied by a bit of smoke blowing out from behind the engine.

When, after some pondering, I tried turning on the car again, it wouldn’t start. After jacking up one side of the car, and going under it to fasten an alligator clip to a starter terminal (the starter being down behind the engine, in roughly the same area the puff of smoke had come from), I found that the starter solenoid seemed to be working: the voltage on its output was zero until I turned the key, then went to eleven volts and some. But by the same measurement, the starter motor was broken — since it didn’t run, and since it couldn’t just be jammed: the current draw of a starter is large enough that the voltage would be lower than that.

I finally got around to considering the possibility that the starter had run away, something I don’t recall ever hearing about, but of which Google quickly found me many examples. Of course how the starter would have run away was not entirely clear, since the starter solenoid was now working properly, as were all the circuits feeding it. But if it had stuck on, the bang at the end might have unstuck it. In any case, the starter plus solenoid being a complete assembly, it was clearly time to pull that assembly off and order a new one.

A variety of places on the net sell starters; I chose one from Amazon — about a hundred dollars for a new starter, NSA brand. Curiously, the refurbished starters on offer mostly went for more than that. The one that had failed was, to judge from the part number on a sticker on it, itself a refurbished unit, from the “Quality-Built” corporation. On their website, they advertise that the solenoids on their rebuilt starters have “100% new contacts”, among other things.

With a new one on its way, it was time for the fun part: failure analysis. The starter was held together by two bolts that ran the whole length of the motor. Removing them was a bit difficult; they came out a bit bent in one place. Then the front of the starter came off easily, revealing a planetary gear set, a one-way clutch attached to the output gear (and loosely mounted on a helical spline), a lot of grease, and nothing at all wrong.

Taking off the other end of the motor, though, revealed a scene reminiscent of Chernobyl. The whole volume was packed full of black-ish, somewhat fluffy debris, including bits of copper and of graphite brush. This explained the bang: something had gotten loose, slammed into something else moving fast, broken it, and a chain reaction of destruction had ensued. Here is a photograph of the recognizable pieces that remained; the photo can be clicked on to bring up a larger version:

Broken starter bits photo

That area of destruction was also the place in which the aforementioned bolts were a bit bent. But the real place of interest was the solenoid contacts. Being crimped in place, that portion could not be disassembled nondestructively; I got it apart by filing off the crimp. Here is a photo of the contacts (again, click for a larger version):

Solenoid contacts photo

This is a decent contact design. The contacts are copper. The copper washer that closes the contact is loosely mounted, so that it can rotate, evening out its own wear. It can also swivel a bit to make good contact even if one of the two fixed contacts wears down (as one has). It lasted through several years and thousands of starts, so I can’t complain too much. But in the end it wasn’t enough to reliably switch the hundreds of amps that a starter draws. The contacts, which started out smooth, roughened from sparks upon opening. Eventually they roughened to the point where the resistance was high enough to generate serious heat, and to weld them together. The places where they welded are clearly visible in the photo, as fresh copper which was exposed when the weld was cracked away.

My impression is that the way to make contacts like this reliable is to make them out of silver rather than copper. But silver costs money. A thin layer of silver won’t do it, because silver gets eroded too, in this duty. And even a thick layer of silver eventually fails.

The drive gear off the old starter wasn’t much chewed up by the runaway. Nor, getting under the car and looking at it, was the ring gear. Properly hardened steel seems to have been used throughout.

The replacement starter looks good, and has worked fine so far. The only curiosity about it is that it comes with a two-year roadside assistance plan. This is rather odd, since the cost of two years of AAA roadside assistance is about the same as the whole cost of the starter. Of course the plan that comes with the starter is not provided by AAA, but rather by another company, “Auto Road Services Inc.”. That company advertises on their website that:

For just pennies per unit, you too can give your customers the added value of FREE emergency roadside assistance, and your company the marketing edge over the competition.

which of course tells me, the customer, the most that their plan could be expected to be worth to me: “pennies”. After their profit and overhead is taken out, it might even have a negative expected value. According to the plan description that came with the starter, one has to call their 800 number, use the roadside assistance provider that they dispatch, pay him his full fee, then send in lots of paperwork to them to get reimbursed. The ways in which they could sleazeball this are too numerous to mention. Not that I care; I’m just glad the starter’s manufacturer didn’t spend too much on this marketing gimmick.

One thing I noted when Googling for “runaway starter” is that some people advise against doing the obvious, and disconnecting the battery. Now, it’s true that in general, disconnecting the battery while the engine is running is a bad idea: it’s called a “load dump”, and can cause the voltage to rise excessively, damaging the car’s electronics. But in this case there’s zero danger: the alternator, which is what produces the excess voltage in the load dump scenario, is not running in the first place. Even if it were running, the runaway starter is sucking down so many amps that the voltage could hardly rise. The “load” that gets “dumped” in a load dump is the current going into the battery; but here current is coming out of the battery.


Setting text width in HTML

This blog quite intentionally has very little formatting. “Quite intentionally”, because not only does it save my effort, but also lets mobile devices with tiny screens format the text the way they want, without having to fight my formatting. But there’s one piece of formatting code I use: limiting the width of the text column. That is a principle of typesetting that I disliked at first, but eventually accepted: long lines are just too hard to read; the eye too easily loses its place when scanning back to the left to get to the start of the next line.

Though a lot of sites limit text width, usually, from what I’ve seen, it’s done badly:

  • Specifying text width in terms of pixels. This produces annoying results for people with bad eyesight who use huge fonts, and for people who have portable devices with lots of microscopic pixels (such as what Apple calls a “retina display”), and who thus also use huge fonts (that is, huge when measured in pixels). It also can fail for people who have displays narrower than the specified number of pixels, since they can end up with lines that go off the edge of the screen, and need to keep scrolling the screen back and forth for each line that they read.

  • Specifying text width as a proportion of the screen width. This won’t overflow the screen, but may produce columns with annoyingly many or annoyingly few characters.

The best way to specify text width is relative to the font size. HTML provides the “em” unit, which is the width of the character “m”. About 35 of those translates into about 75 characters of average text, which is what Lamport’s LaTeX manual says is the maximum width one should ever use. (Personally, being an exceptionally fast reader, I don’t mind twice that width; but this blog is for other people to read, not for me. And above twice that width, even I start to get annoyed.)

One can set the width using HTML tables to divide up the screen into columns whose width is specified in “em” units; and there’s not too much wrong with that. But a width specified that way might be too large for smaller screens. Fortunately the CSS standard provides a way to set an upper bound on the width, without using tables:

<style type="text/css">
    .foo { max-width:35em }
</style>

The above goes in the “head” section of the HTML file. To use that style, one then writes:

<div class="foo">
    Text whose width is to be limited goes here.
</div>

It’s simple, and precisely what is needed: it produces a column 35em wide, unless the screen is narrower than that, in which case the column fits the screen. The “class” attribute can also be set for other HTML elements, such as <body> or <p>, so one doesn’t need to add extra <div>s if one doesn’t want to.


Blogging software

The weblog software that people seem to choose by default these days is Wordpress. Wordpress has a lot of features, is widely used and liked, and is offered as a free single-click install by a lot of web hosting providers. But several of the Wordpress blogs I follow have been hacked at some point. When I looked into blogging software, the reason became clear: Wordpress is a large piece of software, written in PHP, a language which originally was designed arose in a world where security concerns were much less significant, and which has addressed those security concerns (and other evolving needs) by adding things, not by a fundamental redesign. (UPDATE: it appears I was being far too generous to PHP in saying that it had been ‘designed’.) The result is a rather large, complicated language, which is hard to learn well enough to master all the security issues. Also, Wordpress uses an SQL database to store weblog entries, comments, and such, which opens up possibilities of SQL injection attacks. The single-click install is easy, but upgrading is not so easy; and if one runs the software for any length of time, one has to upgrade much more often than one has to install.

A lot of other blogging software, too, uses SQL databases to store weblog data. But databases add complexity; for one thing, to back up a database-driven weblog means issuing special commands to back up the database, in addition to doing the normal backup of the weblog’s files. The added complexity might be worthwhile if there were any real need for a database, but there normally are few enough weblog entries that using a file for each one is quite practical; and once written, they seldom change.

I suspect that the reason why blog software commonly uses databases is that PHP makes using SQL easy, and doesn’t make other ways of storing data as easy. In any case, it’s quite inefficient: even though weblog pages hardly ever change, the PHP/SQL combination means that each time a user asks to view a web page, a PHP process gets started up (or woken up), sends queries to an SQL server, receives the results, and rebuilds the web page using them, adding the headers, sidebar, and other formatting that the user has chosen. The sidebars often take further SQL queries. Due to this inefficiency, database-driven blogs are routinely brought to their knees when they draw huge traffic (as in “slashdotting” or “instalanche”). Right when a weblog is getting the most attention is exactly the wrong time for it to fail. There are various optimizations that can improve this — for one thing, PHP can be left running (WSGI) run inside Apache (mod_php) rather than re-started for every request (CGI); and there are also plugins which cache the resulting web pages rather than rebuilding them every time. But installing and maintaining one of those plugins is additional work; and even they don’t bring the efficiency up to the level that static web pages naturally have.

Of course you can easily move a Wordpress blog to wordpress.com, and let them handle issues like caching and keeping the software up to date. That’s how they make their money: by selling advertising on the blogs they host, and/or charging those blogs for premium features. The blogging software they give away is not a revenue source; indeed, if they were to make it too easy to maintain, they’d be sabotaging their revenue source.

I don’t grudge them their revenue — the people who write blogging software do need to eat — but personally, I feel like going to the other extreme. Thus this blog is done in PyBlosxom, a small file-based blogging package written in Python, which I’m using in static-rendering mode, where rather than being run each time someone visits, it is run once and generates all the web pages for the entire blog. PyBlosxom’s default mode has the author writing blog entries in HTML; I’m using a plugin that provides for writing them in Markdown.


<<  Page 13 of 14  >>