With respect to the speed sensor problem, I've been down this road before and posted about it here:
http://www.endless-sphere.com/forums/viewtopic.php?f=2&t=8613
If you can skip through the interjections, you'll see where I went - oddly, I can't find the solution I posted ANYWHERE, though I see where I discuss "the ultimate" solution for guaranteeing a rock-solid speed signal you can take to the bank. I'll have to see what I did with the pictures associated with that and re-post, I guess. I'm hoping I didn't imagine actually posting about it, as I clearly remember taking some pictures, drawing schematics, and writing about it...
The synopsis of the whole thing is this, though... The blue wire CAN be used, somewhat, for speed - what's happening is that the pulse you get out of it is, if I recall, six times what it should be. If you have 23 pole motor, you're going to see 138 pulses per wheel rotation. The CA can't divide by a number like that...
What I tried first was to wire up a single-chip "divide by 6" circuit and placed it (wrapped in shrink-wrap) inline with the signal. That seemed to produce a signal that was useable. I still can't find my original post, but the picture of the thing, prior to shrink-wrap, is still sitting on my server...
It's almost like the original signal on the blue wire is firmware driven - one pulse per step in the commutation process. I can't imagine how you can get exactly SIX times too many pulses an other way. And that begs the question of how representative that signal is of what's REALLY happening.
I've never been a fan of using single hall signals for speed, and (in actuality) pulled this little divider circuit OUT of the controller I tested it in, and replaced it with a sexier external solution that only produces a pulse if the wheel moves through a complete commutation cycle (all six phases). I found it necessary to do this when I discovered that a single hall signal will "judder" when the wheel stalls or is under great load. The difference this made was quite marked, but I've since discovered that this phenomenon varies with the hall sensors used in the wheel.
I've really gotta get out there and compile the empircal data I've gathered on this whole speed thing and make a thread out of it. The other big thing a lot of folks don't realize is that, if you carefully measure the circumference of your wheel and plug that straight into the speed equation (or your Cycle Analyst), you're going to get an exaggerated speed/distance out of the thing that can be as much as 5 or 6% (depending on your tires and weight). The EFFECTIVE circumference of the wheel for this purpose is closer to the line you'd get if you drew a circle whose radius took into consideration the fact that your tire is actually somewhat compressed with you sitting on the bike. The fact that the tire tread "creeps" somewhat as you roll along needs to be considered, too, and this will vary with tread pattern and riding surface. I did a lot of head scratching over this, comparing my device (which I call the "Anal Cyclist") with a real CA (just to be sure I wasn't buggering up in my own firmware - I was happy that my device agrees EXACTLY with the CA) and my GPS. Owing to the fact that the GPS can introduce some factors of its own (satellite handoffs that might cause you to "jump" a few metres here and there), I went and tried my test route in the car. My car's odometer and the GPS agreed almost exactly. But I still wanted a better test, so checked myself out against some real "mile markers". My results were consistent! My rear wheel, with a Michelin Pilot "Urban" tire on it, measures 2071mm around. To get the correct speed/distance (as real-world and other comparative measures indicate), I have to tell my CA that my wheel is actually 1977mm around!
Yes, "Anal Cyclist", indeed
I'll see if I can scare up a wiring diagram for that divider thingy if anyone's interested. I believed I used a 74LS92 and a single .1uf cap (standard decoupling practice for TTL devices). The thing installs INSIDE the controller.
Edit: Upon posting this, I realize that you SHOULD be able to get a meaningful reading with a CA if you're using a Crystalyte motor. The 400 series has only 8 poles and the 5x series have 12. If you plug 48 or 72, respectively, into the "Number of Poles" on the CA - you SHOULD get a number that's somewhat close to the truth. I believe the CA can divide by 99 - which wasn't enough for a Golden or 9-Continent, which have 23 poles and would thus require division by 138.
I'd be very interested to know if the unbuffered "blue wire" signal produces the correct result as-is this way.
