Not Much New, So Some New Pics of Old Stuff

I finally decided to try my hand at an Instructable and needed some new pics of the bike lighting for it; might as well post them here, too.

The actual instructable itself is here, for the curious:
Bicycle Safety Lighting and Turn Signals From (Mostly) Recycled Parts

These first sets of pics were taken in my carport yesterday evening. The battery for the lights was fully charged beforehand. The pics are in 4 sets, from just before sunset (on the other side of the house from the carport, so no direct sunlight shown) to just after nightfall, and show the bike from each side, with the left turn signal blinking. Where possible, there are images from each lighting condition and angle both with and without the signal, but because the camera has an unpredictable short delay after pressing shutter button and actually capturing the image, I could not get a shot of each even after dozens of tries. I did get many in-between states, oddly enough, where one LED set was in the process of dimming, and the other just beginning to light, which is very strange, since that time period is *extremely* short, compared to the time each LED set is actually fully on (see the video for example timing). None of the in-between pics are posted, as they're not important to how the light works. :-)


A bit before sunset:





After sunset:



After sunset but before full-on dark:




Right about full darkness.


Due to the camera's misbehavior in lighting conditions like these, it's pretty hard to tell the difference between the last two sets. It's also really hard to see the difference between the red and amber LEDs, but there's no such trouble with the camera in better ambient light, nor in person.


For the curious, a quick video showing the blinking turn signal:



The pics below comparing it to car lighting were taken a few days prior, right after work, and unfortunately I'd forgotten to charge the lighting battery for days up to that point, making them all pretty dim compared to the car (otherwise they'd be a better comparison). Hoping to rectify that soon with a professional-grade photographer, and also get video of the bike in traffic in various lighting conditions.



Part of the reason for the pics is to re-evaluate the lighting, to determine if I really need any more lights or at least more surface area for the existing ones, to make them more readily visible, without blinding anyone. Remember: brighter is not necessarily better, because if you make another vehicle's driver or rider have to squint till their eyes adjust to your megawatt spotlights, you risk them hitting something else, or looking away from you and hitting you anyway because they couldn't see the maneuver you did at that moment. I know you know this--you've been blinded by someone's highbeams before, right? Or that tall truck with headlights at eye-level? Yeah, you know you have, and it hurt, too.

Speedo From Hell

I have been having a particularly unlucky couple of weeks, in regards to the whole PDA bike computer/speedometer thing. The PDA I'd been using, that Treo PDAPhone with the battery-eating problem, finally ceased to operate at all regardless of what battery I tried in it. It had been getting only a minute or two of operation even on a full charge, and the unit got pretty hot while running, so it was not unexpected.

Before it died, I had tried a few experiments with other PDAs, to no avail. An original Handspring Visor turned out to only have PalmOS 3.1, so I could not even use IR Hotsync on it, and had no cable for it, so couldn't upload VeloAce to it from the laptop. I did finally get VeloAce on it via beaming it from the Treo before it's death, but it just crashes with a fatal exception due to the old OS version (VeloAce only works on 3.5 and up).

I have an old Samsung PDAPhone that doesn't even seem to have a program memory to upload *to*, and doesn't appear to support any upload or even beaming functions at all, though it does have IR, and it's the only other PalmOS unit I even have. Well, there's the Sony Clie that randomly crashes, usually requring a reset that wipes out the VeloAce program (forcing a full resync with a PC to upload it again, as I have no MemoryStick that will work in the Clie to keep VeloAce on). Not very helpful. Other than that I just have the Ipaq Windows-based unit, which while it works well, it won't run PalmOS based apps. :-(


So that leaves me with the options of buying a speedometer (pretty cheap, but it's still spending money *and* it's buying something *new*, which must be done only when no other option exists, for these projects) or making one from something else (or from scratch). I could probably make a mechanical one reasonably easily, or transplant the one off the carcass of a Honda gaspowered scooter someone donated to me, but I choose not to because it's less of a challenge. :-)

There are two options I could do that I thought of during lunch:

One: use an op-amp-based integrator to convert pulses from the wheel revolution sensor into a voltage that I can display on my super-cheap Harbor Freight multimeter, simply scaling the voltage so that it equals 1/10th of the actual miles-per-hour. Scaling down to 1/10th only needed so I don't have to have at least 20-something volts available to the op-amp system, and can use 3.4volts to power the whole thing, and run it off a Li-Ion phone battery, just as I do the actual wheel sensor/debouncer/IR thing I made for the PDA phone. That way I can put it all in the same project box (there's a little room left), and just run a direct connection to the meter's voltage jacks.

This has the advantage that it is very simple to design and build, but the disadvantage that the meter is pretty big and bulky, compared even to a whole PDA (just a bit smaller than a small paperback book). The screen is big enough to easily read, though, and I can install an LED backlight for it, so I can see it at night, too.


Two: use an old step-counter originally made to count the number of steps you take as you walk or jog for exercise, with a handy little LCD already built-in, and run the wheel sensor to the input where the step-sensor goes, instead. Then the reset button gets wired to a timer that clears it to zero at whatever time period is needed so that the display is zeroed just after whatever the actual miles-per-hour reading would be. If I use 10 magnets on the wheel's spokes, evenly spaced around, that's about 1/10th of a second between resets to read approximately correct.

Now, there is a problem in that the screen will be difficult or impossible to read due to the extremely quickly changing numbers, and would probably have to be kept blanked until actually about to be reset, left on for an instant, then reset and blanked again. This might make the display too dim to read, especially since the screen is very small to start with--about 1/4" high, maybe a bit less.

A possible solution that makes it a little more complex to build is to count one "period", then disable the counter input, so it holds the value on the screen for a second. After that second, it resets and counts again, holds, resets, counts, holds, resets, etc. In theory it should work, and not add that much more complexity. Using a 556 with two timers instead of a 555 with one, and double the number of resistors and capacitors, it only doubles the amount of space it will take up, and perhaps double the amount of power it will draw.


I may build both, and use them at the same time to see how well each works compared to the other. The voltage display version will be more instantaneously accurate, and a realtime readout, while the much smaller stepcounter version will have that 1.1 second lag between updates. Safer to use the voltage display version, I guess. :)


I've been trying to think of any other devices I have that could display a number I could reasonably easily generate from the wheel sensor and *very* simple electronics, but there really isn't much that doesnt' quickly get complex enough to be easier to do in software and either use a PDA or a microcontroller, neither of which I know how to program.


The only other displays I have (or could make) that would clearly display my speed are an analog needle magnetic-deflection display (like from an old analog multimeter), or a line of LEDs attached to a level-meter chip or transistor array. Both of these would run off the wheel-sensor-to-voltage converter, just like the DMM, but would be analog instead of digital displays. The LEDs would be easily visible at night, but hard to see in the daytime, unless I made them so bright that they'd blind me at night without adding an automatic dimmer. Much easier to add a backlight LED to the analog needle display, which would be easily visible without backlighting in the day, so the LED would only need to be just bright enough to make the display visible in the dark, and could be switched off manually or by an ALS when ambient light is bright enough to see it clearly by. I'd need to calibrate the display either way and print out a little chart to stick on it or in it with the appropriate MPH labelling for each position.


In all cases, the wheel sensor can remain virtually identical to what I already have: a one-shot debouncer circuit with a one-shot pulse-creator after it, but instead of driving an IR LED to send the pulses to a PDA, it would directly wire to the input of whichever intermediate conversion circuit I'd use. Easy enough to do, since the IR LED in my setup simply plugs into a 1/8" phono jack (salvaged off some motherboard) on the wheel sensor box anyway.


Calibrating the whole thing I can roughly do with the Sony Clie running off the IR LED, and just compare readings as I adjust the converter(s) for each kind of setup until they match the Clie's readout as I ride at different speeds. If that won't work for some reason (like if the Clie just won't work long enough), I may have to borrow another biker's speedometer temporarily to do it, but it should be easy enough to calculate everything so it's pretty close to begin with, and only have to worry about component tolerances not cancelling out for the fine tuning. :-)