[esm@logic.net ~]$ _

Well, I finally did it: I converted my personal Subversion repository to Mercurial. Looking at svn log, I created the original repository back in late 2002, and since I was tracking svn trunk at the time, I would have been on some intermediary version of the 0.14.4 alpha. Ye ghods, that seems like a long time ago. I still remember how happy I was that svn had stabilized to the point where I was comfortable switching from CVS (at the time, I just dumped my old CVS repository history and imported everything as it sat on disk). I can't count the number of times I've had to do an svnadmin dump/svnadmin load cycle on that repository since creating it, either because of format changes, bugs, or because I did something stupid; it always felt a little like PostgreSQL upgrades in that respect. ;) It's served me very well for eight years (well, longer than that, but prior use was mostly as a toy), but the lure of distributed repositories and easy merges beckoned.

So, it's done. Turns out that hg convert works pretty damn well; it appears to have retained all history without any problems, and dropping a clone of the hg repo in place of my existing checkouts was basically a non-event. Trac bolted up to the converted repository without a hitch with the Mercurial repository module, and hgwebdir means I finally have a consolidated web and native interface to the repository again (when I moved to lighttpd, I lost mod_dav_svn, and ended up resorting to svnserve to provide a public read-only interface). Overall, conversion was a snap.

If anyone is curious about the configuration details, I'm running hgwebdir under lighttpd with FastCGI. The lighttpd configuration looks like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

fastcgi.server += (
  "/hg" => (
    "hg" => (
      "socket" => "/path/to/hgwebdir.sock",
      "bin-path" => "/path/to/hgwebdir.fcgi",
      "check-local" => "disable",
      "disable-time" => 1,
      "min-procs" => 1,
      "max-procs" => 1,
    ),
  ),
)
$HTTP["request-method"] !~ "^(GET|HEAD)" {
  auth.require = (
    "/hg" => (
      "method"  => "digest",
      "realm"   => "admin",
      "require" => "valid-user"
    ),
  )
}

hgwebdir.fcgi is just a modified version (paths changed) of the script that ships with Mercurial. From the above, I'm just serving all things Mercurial up as /hg/, and requiring authentication for anything other that GET or HEAD requests, so visitors can browse it read-only, but authenticated users can push changes. hgweb.config just contains:

1
2
3
4
5
6

[web]
baseurl = /hg
allow_push = *

[collections]
/path/to/hg/repo/parent = /path/to/hg/repo/parent

That's it. (But, unless you're familiar with every layer sitting on top of your repository, I'd probably suggest changing allow_push to something more restrictive.)

Continuing in my "useless information you never knew you didn't need" series of automotive documentation, I just spent an hour making my eyes bleed staring at Sumitomo's connector inventory to try and track down the plug used by the WRX boost control solenoid. I'm pretty sure at this point that it's the the exact opposite part as the Evo BCS connector: M(6188-0266) for the male connector (the part that's molded into the solenoid itself), and F(6189-0249) for the female plug (attached to the car's wiring harness).

The only difference between this plug and the Evo version is that the little notch (key) is on the left side of the bottom of the plug, rather than the right side. Annoying little gratuitous differences like this are why I hate automakers. :p

I was one of the lucky ones, and got in on the SparkFun "free day"; basically, they gave away $100 off of any order (with no minimum, so you could literally just order $100 of stuff) to anyone lucky enough to be able to submit an order during the ordering period, which was pretty tricky given how badly their servers melted under the load. :-)

Anyway, one of the things I picked up was an Arduino starter kit; an Arduino Duemilanove (the guts of the system), along with a bunch of small sensors, LEDs, and other widgets to help you build stuff with it. Learning a new toy like this always requires that I give myself a real project to tackle with it; if I don't actually "scratch an itch" with it, it ends up getting relegated to "cute toy" status pretty quickly.

As luck would have it, a project presents itself: my wife hates our "programmable" (and I use the term loosely) thermostat, and I'm not prepared to pay a king's ransom for what is basically a small microcontroller and about $15 in parts. So, tonight's project was diving into reading a simple 10K thermistor, and producing some kind of useful output. Turns out, it was much easier than expected. I borrowed a bit of code from both a tri-color LED example, and some example thermistor code, and produced the following sketch that displays green when the temperature is comfortable (by my definition, anyway), red when it's hot, blue when it's cold, and gradiants in-between leading up to the extremes.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107

// Fading LED colors based on temperature.
// Ed Marshall <esm@logic.net>

#include <math.h>

int redPin  = 9;    // Red LED, connected to digital pin 9
int greenPin = 10;  // Green LED, connected to digital pin 10
int bluePin = 11;   // Blue LED, connected to digital pin 11
int wait = 50;      // 50ms (.05 second) delay; shorten for faster fades
int DEBUG = 0;      // DEBUG counter; if set to 1, will write values back via serial

void printDouble(double val, byte precision) {
  // prints val with number of decimal places determine by precision
  // precision is a number from 0 to 6 indicating the desired decimal places
  // example: printDouble(3.1415, 2); // prints 3.14 (two decimal places)
  Serial.print (int(val));  //prints the int part
  if( precision > 0) {
    Serial.print("."); // print the decimal point
    unsigned long frac, mult = 1;
    byte padding = precision -1;
    while(precision--) mult *=10;
    if(val >= 0) frac = (val - int(val)) * mult; else frac = (int(val) - val) * mult;
    unsigned long frac1 = frac;
    while(frac1 /= 10) padding--;
    while(padding--) Serial.print("0");
    Serial.print(frac,DEC) ;
  }
}

double Thermistor(int RawADC) {
  // Inputs ADC Value from Thermistor and outputs Temperature in Celsius
  //  requires: include <math.h>
  // Utilizes the Steinhart-Hart Thermistor Equation:
  //    Temperature in Kelvin = 1 / {A + B[ln(R)] + C[ln(R)]^3}
  //    where A = 0.001129148, B = 0.000234125 and C = 8.76741E-08
  long Resistance;  double Temp;  // Dual-Purpose variable to save space.
  Resistance=((10240000/RawADC) - 10000);  // Assuming a 10k Thermistor.  Calculation is actually: Resistance = (1024/ADC)
  Temp = log(Resistance); // Saving the Log(resistance) so not to calculate it 4 times later. // "Temp" means "Temporary" on this line.
  Temp = 1 / (0.001129148 + (0.000234125 * Temp) + (0.0000000876741 * Temp * Temp * Temp));   // Now it means both "Temporary" and "Temperature"
  Temp = Temp - 273.15;  // Convert Kelvin to Celsius                                         // Now it only means "Temperature"

  return Temp;
}

void setup()
{
  pinMode(redPin, OUTPUT);   // sets the pins as output
  pinMode(greenPin, OUTPUT);
  pinMode(bluePin, OUTPUT);
  if (DEBUG) {           // If we want to see the pin values for debugging...
    Serial.begin(9600);  // ...set up the serial ouput on 0004 style
  }
}

void loop() {
  double Temp;
  double TempCalc;
  int TempScaled, RedLED, GreenLED, BlueLED;

  Temp = Thermistor(analogRead(0));

  // We'll say that 15C - 30C is our "comfortable" range.
  // < 15 is very cold (solid blue), > 30 is very hot (solid red).
  TempCalc = (Temp - 15) / 15;
  if (TempCalc < 0) {
    TempCalc = 0;
  } else if (TempCalc > 1) {
    TempCalc = 1;
  }
  TempScaled = (TempCalc * 512) - 1;

  if (TempScaled > 255) {
    TempScaled -= 256;
    BlueLED = 0;
    GreenLED = 255 - TempScaled;
    RedLED = TempScaled;
  } else {
    BlueLED = 255 - TempScaled;
    GreenLED = TempScaled;
    RedLED = 0;
  }

  if (DEBUG) {
    DEBUG += 1;
    // Only perform debugging output every 10 loop iterations.
    if (DEBUG > 10) {
      DEBUG = 1;
      Serial.print("Temperature: ");
      printDouble(Temp, 3);
      Serial.println("C");

      Serial.print("Red: ");
      Serial.print(RedLED);
      Serial.print("\tGreen: ");
      Serial.print(GreenLED);
      Serial.print("\tBlue: ");
      Serial.println(BlueLED);
      Serial.println();
    }
  }

  analogWrite(redPin, RedLED);
  analogWrite(greenPin, GreenLED); 
  analogWrite(bluePin,  BlueLED);  

  delay(wait);
}

I hate the internet. No really, you all suck. I ask Google where to find 10mm ID (well, 10.3mm, to be exact) copper crush washers locally, and I get back a million hits leading to forums where dozens of people are asking the exact same question, with a lot of "uh, I dunno, it was at my local [insert auto parts store here], the guy behind the counter found them for me". Why would you want them? Most Mitsubishi brake line banjo fittings require them, as do Mitsu and Subaru turbo oil feed banjo fittings.

The answer is NAPA, and the part number is UP 24951: "Washer - Sealing", in their brake parts lineup. To the next guy on the Internet searching for them, there you go. :)

Kerberos as a site-wide authentication mechanism has it's benefits, but the software that's typically used to drive it is getting a little long in the tooth. ksu, the kerberized equivalent to su, is only a partial implementation of what su does; there's no argument to ksu that says "this is a login shell, please set up the necessary environment". Even su has a couple of failings; in particular, if you're an X user, you're probably familiar with how su - doesn't bring your X authentication data along for the ride.

So, I fixed both of those a while back, with a really ugly shell script. Just in case anyone else might find it handy, here it is:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

#!/bin/sh

# Replacement for raw "ksu" in kerberized environments;
# behaves more like "su -", and retains xauth data.

if [ $# -lt 1 ]
then
    echo "Usage: `basename $0` <target user> [ <command> [ <arg> ] ... ]"
    exit 2
fi

TARGET_USER="$1"
shift

# be a basic login shell if no command is specified.
if [ -z "$*" ]
then
    TARGET_CMD='-l'
else
    TARGET_CMD="-c '$*'"
fi

# FD 4 becomes stdin
exec 4>&0

xauth list | sed -e 's/^/add /' | {
    # FD 3 becomes xauth output
    # FD 0 becomes stdin again
    # FD 4 is closed
    exec 3>&0 0>&4 4>&-

    exec /usr/bin/env -u PATH -u LD_LIBRARY_PATH \
      /usr/krb5/bin/ksu "${TARGET_USER}" -e /bin/bash -l -c "
        xauth -q <&3
        cd
        exec /usr/bin/env DISPLAY='${DISPLAY}' "'"$SHELL"'" ${TARGET_CMD} 3>&-"
}

So, new battery in place, I was ready to take the Laser out for a good flogging. The alternator, less than a year old, had other plans. Fired the car up, and wouldn't you know that the lights were giving me a nice disco show? So, in a less-than-a-year-old alternator, the voltage regulator was already dead; we have, at most, ten miles on that alternator.

Pep Boys, you guys suck. Seriously.

That being said, a lifetime warranty makes me feel a little bit better about the situation, and I'm pretty much a master at swapping the alternator on the Laser at this point. Ten minutes to pull it, half an hour to run over to the store to get it tested/replaced, ten minutes to slap it back on, and viola: the car fires up and idles perfectly. So, I dumped fresh oil in the engine, trans, and transfer case (which was close to empty; I love DSM driveshaft yokes, really I do) as a matter of preventative maintenance, and took the car out for an extended drive.

Obviously, the brakes were a little unhappy; the car has been sitting for a year without much movement. After knocking most of the rust off the rotors, I noticed the car was still bogging quite a bit, which I initially attributed to corrosion around the wheel bearings. After an afternoon of burning off the year-old gas, the car was back to coasting properly, accelerating without hesitation, and generally behaving like it did when it was last running properly, as long as I was very cautious with the brakes; give it a bit too much, though, and bam, the driver's side front caliper would freeze shut, and it would take a block or two of driving to get it to back off.

So, last weekend, we bled the brakes; the rears went without incident, as did the passenger-side front (although some rather nasty stuff came out of the lines). The driver's-side front, however, wouldn't bleed at all; we were basically standing on the brake, but nothing was coming out of the caliper. Nice.

My answer? Screw the 1-pot OEM brakes, since I have a nice set of 2-pot calipers from the 2g sitting on the floor of the garage (the 2g has since been switched over to Evo calipers all around). I've cleaned them up a bit, and while I think a rebuild kit is in order, it looks like they'll work out perfectly; I just need a new set of front rotors (the old pads look fine, with a ton of meat left on them). I just need to finish disassembling them, clean them up a bit more and apply a couple of coats of high-temp paint, and slap it all back together. I also need to do a bit of research to see if I ought to be doing anything with the proportioning valve, but the worst case is that I just run it as-is, and deal with a little understeer.

But, the good news is that, aside from one caliper, the car runs perfectly; it's still a sloppy car to drive after getting used to the WRX and the Evo, but that could be fixed cheaply with a decent set of springs (it already has Koni Yellows). Assuming I can get the brake issue sorted out, I have a low-budget winter project in mind: an Evo ECU swap.

We've been getting everything ready for winter around here, and besides just cleaning the yard up, we have quite a few vehicles in the driveway that need a little pre-winter TLC. Which means hooking the Laser up to one of the other cars to jump it and keep it running for a little while: in other words, a huge pain in the arse, so I don't do it as often as I should. Well, as long as I've got it jumped and running, I might as well take my seasonal stab at what the heck is wrong with the electrical system with it, right? ;-)

The last time I played with it, we determined the alternator was cooked, so we did a cheap swap at Pep Boys. I've been going through the possible trouble areas every time I open the hood, and I think I'm down to the battery at this point; that poor little Optima had a hard life, and it's finally done. The problem I was having before was that it would hold a charge for a while (well enough to fire the car and keep it running for a while), which would fool me into thinking I had something else taxing the electrical system. But it's dead as a doornail now; no charge being held whatsoever, so it's blatantly obvious where the problem was.

The upshot is, between this and the alternator, we've likely found the root of the issues we've been chasing the whole time. So, it's probably time to budget a few bucks for a new battery; at a minimum, I'm going to need a workable battery for the Eclipse if I ever get around to firing it, so it's not like it'll be wasted if it turns out something else is causing problems on the 1g.

The sad thing is, every time I go out and fire that car up, I'm shocked at how smoothly that car idles. It's not your typical 17-year-old hoopty that chugs at idle, sputters when you rev it, etc; it idles cleaner than the Evo (which isn't saying much, considering what I've done to the Evo lately, but still). It's a shame I've let it sit there untouched for so long.

My non-geek friends should probably just tune out now. My geek friends who don't care about my car hobby probably won't care too much about this either. ;)

I've written a rudimentary, but automated, SH2 disassembler in Python. It's licensed under the GNU General Public License (Version 3), and can be downloaded from here:

http://dev.logic.net/hg/sh2dis/file/

(You'll need all files from that folder ending in .py, or just click on "zip" in the left-hand sidebar to download a zipped version of the whole project.)

This is not an IDA Pro replacement. That being said, my motivation was not having to point folks who are interested in ECU development toward a $1000 code analysis package that they'll only end up using 1% of. And let's be honest: those people I pointed at IDA probably just ended up pirating it. :(

As of now it has no user interface at all, simply a demo application (dis.py) that, given a ROM image from an Evo VIII or IX (and probably most other 7052- or 7055-based platforms, such as the Hayabusa ECU), tries to perform an automatic disassembly by following interrupt vectors.

Segment handling is modeled after IDA, and I've tried not to torpedo the possibility of implementing other processors (specifically, H8/500, HC11, and HC16, all of which I have a personal interest in), but I just haven't had the time to think about that yet. The output doesn't currently include IDA's comment-based cross-references, although that information is tracked and could be added pretty easily. It automatically labels "known" (ie. from the platform docs) vectors and registers, and can follow most branches; it's not smart enough to recognize a few known jsr/jmp table patterns, but it's on the to-do list. Branch handling is done by doing very basic register assignment tracking, and there's a ton of room for improvement here (but it seems to be good enough for "in the wild" Evo ROMs right now).

It requires Python 2.6. Python 2.5 and 3.0 will not work, period, full-stop. I'm not interested in porting to Py3k just yet (it needs a little wider adoption first), and I'm making pretty heavy use of 2.6/3.0 string formatting, making it a PITA to make it compatible with 2.5 at this point.

In case it's not completely obvious yet: this is NOT end-user software. The target audience for this is other Evo developers right now, and probably only those with a solid working knowledge of both IDA and python. Knowing SH2 assembly wouldn't hurt, either. ;)

Performance is not quite where I'd like it to be right now; it takes about 30 seconds on my old dev machine (Dual PIII 1GHz, Linux) to run through a complete disassembly and output, which feels a bit slower than IDA's automated analysis. I'll be very honest, I'm not worrying much about that just yet, since there's so much additional work to be done elsewhere. (If anyone reading this feels like tackling the main bottleneck, it's in sh2.py, in disasm_single(); a short-circuiting instruction matching scheme in there, perhaps along with better opcode storage in sh2opcodes.py, would probably cut runtime by more than half.)

It's probably extremely buggy, and the source is certainly a mess as it sits right now. Bug reports and patches are welcome.

Dear Apple,

Go to hell. Apple's insistence that there is an "unclear patent landscape" is about as obvious and transparent a maneuver as you can get; it's a thinly-veiled market protection tactic, and we all see it for what it is. As for the the lack of native hardware support, call it what it is: you don't have hardware decoding for Theora in the current generation iPod and iPhone. Whose fault is that again? Right. You're acting in your shareholder's best interests, surely, but you're pissing off everyone else who has to play in the sandbox with you.

So, go to hell.

Sincererly,
Teh internets.

P.S Google, you too.

As the first part of eventually getting Erica's wagon an upgraded turbo, I've started planning out the fuel system for her. Her goals are very modest; she wants the car to be responsive in day-to-day traffic, and I'm sure she'd like to be able to at least keep up with my Evo. ;) So, fueling isn't a huge deal; running under the assumption that she won't be running E-85 (she's quite adamant about that, although I'm still hoping to change her mind), a 255lph pump should be plenty for most 40-50lbs/min turbos.

Originally I'd planned on picking up the usual choice: a 255lph HP Walbro pump. After doing a bit of searching, I came across TRE, a company out of California selling what appeared to be "Walbro clones"; they even carry the same part number designations. I suspect they're simply a reproduction from another country, but TRE seems to care enough about the perception of their product that they went to the trouble of having an independent company (RC Engineering) test their output, and give a one-year warranty on them. The biggest plus was that they claimed to not have the typical Walbro "whine"; if you've ever had a Walbro pump, you know exactly what I'm talking about, and it's annoying, especially for a pure street car like my wife's. After seeing a few other folks getting them and being generally happy with them, I decided to take a chance and give it a shot. If you don't see an update here about them within a year or two, you can assume it worked out fine. :) Installation was a snap, and the kit came with everything necessary to install them, along with a "pump cozie"; a foam rubber sleeve that should do a good job of further reducing noise. As for the sound: you can hear it power on when you turn the key, but once the car is running, it doesn't make a peep. Perfect.

Next up will be fuel injectors; I've had my eye on a set of Injector Dynamics injectors, which are basically flow-matched modified Bosch OEM injectors. While it's a bit much for her application, I'm planning on grabbing a set of their 1000cc injectors; plenty of headroom for alternative fuels later, if necessary, and the price is close enough to not matter much. The upshot with these, besides the flow-matching, is that Tony at T1 supplies voltage latency compensation values for them at a variety of common base pressures, which should make tuning for them a breeze.

After that, I have an adjustable fuel pressure regulator that I was originally planning on installing on the Eclipse sitting on the shelf that I'll probably install for her, along with converting her fuel rails to a parallel feed configuration. In stock form, fuel is fed to the two fuel rails serially; that is, fuel enters one rail and feeds those injectors, then flows to the other rail to feed the second set. The result can be a pressure drop in the second rail, and potentially inadequate fueling to one or both injectors in that rail. The fix is pretty simple: deliver fuel to both rails in parallel using a y-fitting to split the flow, then connect the output of the rails together at the fuel pressure regulator. Simple enough to say, but we'll see how accommodating the stock lines will be to a reconfiguration, or if I'll have to fabricate a bunch of new lines for this.

Finally, the plan is to pick up a turbo for her. I have my eye on the new Forced Performance HTA68 turbo, which is a heavily-modified Mitsubishi 16g. The price is decent, and responsiveness should be on par with a typical 16g (with improved top-end), so it should be a good fit for her application.

Sometime next year, once all of this is done, we'll need to focus on improving charge air cooling; either a front-mount intercooler, or a larger top-mount. But that's down the road a bit.