I added two “features” to the pcb before sending the design out, both of which were untested in the initial prototypes. The main feature I wanted to have was “motion detection”, so the taillight would shut down should the bike become idle for a period of time. No need to be wasting precious photons while the bike is leaned up against a tree or parked in a bike rack. Motion detection is provided by a roller ball switch, intended to replace the old fashioned mercury switch. A tiny gold plated ball rolls around in a plastic and metal cage, completing electrical circuits during its travel. The light’s micro-controller recognizes these impulses and continues to let the light function. As soon as the tilt switch stops changing state, resting as either a short or open circuit, the uC begins a count. When that count totals some arbitrary number, the light returns to a standby mode with the SMPS in shutdown. The uC then watches the tilt sensor for the state to change again and upon a change, resumes the previous operational mode.

The second feature is a battery minder circuit. Using a 2.5v precision reference, the micro-controller samples the battery voltage using its on board ADC. The idea is to detect a weak battery condition and operate the SMPS at a lower duty cycle, to make the most of the remaining power. The assumption here is that some light is better than no light in terms of safety. One of my pcb bugs lies in this circuit. The Microchip 12F683 uC I selected for this project is an 8 pin device. Its voltage reference pin is also multiplexed with the programming clock. In my design, I had made the error of connecting the vref pin directly to the voltage reference output, which is biased with a 1k resistor to the Vdd rail (bat +). So effectively, I have a very strong pull-up to 2.5v on that pin. This made programming the PIC impossible as it could not detect clock transitions. I will try salvaging these PCBs by changing to a 10k or 20k bias resistor on the reference, or cutting the trace leading to the Vref pin and soldering a 10k+ resistor in series, since we don’t need any current on that pin, just voltage.

Once I polish the code a bit more, I’ll be looking for a few folks to send a sample units to in exchange for reviews and feedback, down the road I would like to sell these either as a kit or a pre-assembled unit.

Feature-wise, this revision adds nothing over the previous light, all the changes are in board design. Firstly, the artwork was redone using polygon pours instead of straight point to point wiring (traces). The revision two switcher was running pretty warm, mostly because it didn’t have much copper to dump the heat into.

The switcher’s ground pin is now tied directly into a very large copper pour, as are the Vin and Switch pins. Using a burning finger temperature probe, the chip remained at or below T_body even operating in constant on mode at full power. Compared to the revision two board which saw the switcher running quite hot in constant on mode.

The current sensing resistor was moved a lot closer to the feedback pin. With a feedback voltage of 190mV, the tiny resistance of the trace was actually affecting output. Shortening the trace to roughly 1mm has helped a great deal.

Finally, the layout for the battery clips was fixed, and generous polygon pours were drawn around the pads. The spring clips are now soldered down very firmly and hold the batteries quite well. I have yet to take this unit on the trail, so we’ll see if a rubber band is required or not to retain the batteries while bouncing along.

I plan on making one more prototype before sending the design off to Custom PCB or Gold Phoenix. I think I’ll eliminate the battery clips on the chance excessive force could cause one to separate from the laminate and severely damage the pcb. I also want to try a board that hosts both driver circuit and LEDs. Additionally, I plan to add a tilt / vibration sensing switch (roller ball switch), so inactivity of the bike can be detected and the light switched off to save on batteries.

Thanks for reading!

This year I’ve been going on a lot of bike rides with friends, sometimes on public roadways, sometimes after dark. My bike has a nine watt 500 some odd lumen headlight, which makes it easy to see where I’m going, and definitely makes me visible head on. The tail of my bike however still has the stock reflector, plus the little reflector stripes in my shoes, not exactly high visibility. Not wanting to pale in comparison to the headlight, the taillight is a three watt 140 lumen beast powered by three AA rechargeable batteries.

The light is based on a boost converter from National Semiconductor, the LM3410. I’m using the 525kHz SOT-23 version, the LM3410Y. Originally I had trouble with the chip self destructing, as discussed on the Linear1 forums. It was hypothesized either the inductor was underrated or the diode was too slow. Ordering parts for another project later in 2008, I bought some better inductors and diodes, which more closely resembled the specs of parts used in National’s web bench simulator. So, lacking sufficient rear light, I rekindled this project and have a “working prototype” that’s gone on two rides with me so far.

The basic function is fairly simple. The 3410 is a constant current boost (step-up) driver. A small inductor is used to ramp up the input voltage, from 3.6vdc nominal to 15.4v at approximately 200mA. The current is monitored by a one ohm resistor. A pair of output capacitors help smooth out the ripple and an input capacitor helps the batteries cope with the high demand current (as high as 1.5a in some cases). I’m using nickle metal hydride batteries, which have a rather low internal resistance – they’re designed for high demand applications and when fresh, barely sag at all under the load.

Originally I had planned on carrying the batteries directly on the PCB, using some through-hole spring clip battery holders I found in the Sparkfun library. However, AA batteries must be bigger in Colorado than they are in Michigan, because using Sparkfun’s layout gave me about a quarter inch gap between the spring and the battery. The pads were also woefully undersized for physically mounting the clip and holding it securely enough to survive the stress of batter insertion and extraction. So I dropped their layout and drew my own that looks exactly like it, but is based on measurements from a real AA battery.

Along for the ride is a Microchip PIC microcontroller, the 12F683. It provides a bit of user interface for the light, creating different blink patterns as well as putting the light into a “stand by” mode, with the switcher shut down. I’ve programmed several blinking patterns, and somewhat organized them into “modes” which I can select using the little button.

A year ago, I didn’t have any sort of enclosure in mind. The led array was assembled on a ‘standard’ sized protoboard, so I probably thought about using a plastic or aluminum prototype enclosure. However, this year, I was thinking it would be a nice fit for a large mint tin. After printing out some mock-ups and messing around with battery configurations, I settled on using three batteries and having the electronics crammed into one side of the tin with the led array mounted in the lid of the tin. This setup might have worked, except for the battery snafu. I’m using a plastic three cell holder right now, and the extra thickness it adds is preventing the lid from completely closing. It closes enough that the light is easily held shut by some big rubberbands, and it survived bouncing around under my seat for two short rides. The next revision will have the battery situation resolved and I might have a better mounting solution by then too.

Overall I’m very pleased with the outcome of this project. I have more parts on order to make a few more lights for my other bikes and friends, and I want to experiment with other array configurations and colors. There are a two videos of the light on my youtube channel, but they’re nothing to get excited about.

Thanks for reading!

I figured this would be a good easy project I could finish in a day, so I drilled out a piece of pine board and set to soldering up some 3mm leds. I wasn’t very careful, so the little matrices look kind of ugly, but it all works and you can’t see the wires in the dark!

It didn’t take very long to toss three of these nine led matrices together. Assembling them into a twenty-seven led cube was a bit trickier. I used some gator clips to hold parts of the cube while I soldered it. Eventually I finished all the connections and had a passable cube with fairly even spacing.

Assembling the matrix is a pretty straight forward task. All you really do is tie all the cathodes together. Each matrix will become one row in the finished cube. Electrically, the cube is built as a 3×9 array, three rows and nine columns. You could probably build it the other way around, anode rows and cathode columns, but it is easier to sink a large current than source it. I think the MAKE: software only lights one led at a time, since they’re relying on the microcontroller to both source and sink current. My design is a bit different. The mcu sources current to each anode column, and N channel fets sink current for the entire row. The N channel is easily able to sink a few amps, so the cube can light an entire row at once without having to multiplex the individual leds.

In order to keep the PCB layout simple, the connections are spread all over the place in terms of the registers inside the pic. It would have been cleaner to organize eight of the nine columns as a single 8bit register on the pic, leaving only one bit left over to deal with. Instead, I’ve created symbols for each column, and set them individually from 9bit numbers.

Each anode column is current limited by a 75 ohm resistor. The value chosen was rather arbitrary, since the leds have such a low duty cycle, a lower value would have afforded me more brightness when the cube is battery powered. I can tweak the brightness a bit in the software, changing the scan rate the rows are multiplexed at.

That’s pretty much it. I’ve found there’s not a lot you can do with only 3x3x3 and 1 color, but it’s still kind of fun. Trying to think in three dimensions while drawing the animation frames is kind of tricky. I started with excel, but that wasn’t very useful – I spent more time copy and pasting formulas than I did ‘drawing’. Luckily my buddy Dan helped me out with that. He whipped up an awesome little php script that lets you draw animations 27 leds at a time, and it formats the resulting numbers so I can copy and paste them right into the code.

There’s a few videos of the cube doing various things on my Youtube Channel. Here is perhaps the most interesting one so far.

Thanks for reading, and Happy New Year!

The basic menu consists of options for setting the time and date; minute, hour, day, date, month, year.   The basic options are pretty self explanatory.  I have also planned some more advanced options:

1. Adjustable display brightness – Varying the duty cycle and refresh rate of the matrix can effect its brightness.  I need to make a simple scale for these variances to allow for two or three brightness levels.

2. Adjustable scrolling speed – The program draws the same information several hundred times per ‘scroll’, changing this counter affects how fast the display appears to scroll.

3. Selectable time format – User can choose between 12 hour AM/PM time and 24 hours ‘Military’ formats

4. Message Mode – User can enable / disable scrolling messages as well as display a single message, a random message or messages in sequence.

Other than that, the code is still pretty basic.  I’ve completed a bunch of internal fixes, like the scrolling code now handles messages of variable lengths. up to sixteen characters.  I’ve also created i2c eeprom reading routines to extract menu prompts and other text strings I’ve stored in the eeprom to save flash space on the chip.