Power LED upgrade for Luxor 65 bicycle lamps

Luxor 'Le Martelé' lamp set. Photo from jp weigle.

I'm a huge fan of the Luxor 65 series of bicycle lamps, especially the hammered aluminium  'Le Martelé'.  It took me a while, but after a few months on French Ebay I managed to acquire a set.  Naturally, I want to upgrade them with modern power LEDs, as I've done with the classic Sturmey Archer lamp set.  Both front and rear lamps use a nicely designed lamp holder that snaps into the reflector/lens base with a pair of spring clips:

For the rear lamp I can use a screw base bulb with a super bright red Cree XP-E LED.  For the front lamp, I wasn't satisfied with the way my LED bulb sat in the reflector, so designed a heat sink that could be clamped into the opening of the reflector with set screws:

Here it is machined in copper:

Heat sink for Luxor 65 LED upgrade

and with a Cree XM-L LED mounted directly to the nub that pokes through a slot milled in the PCB:

The holes for the set screws weren't quite in the right place to grab the base of the reflector so I had to drill and tap new ones for a 4-40 set screw.  Here's how the LED/heat sink assembly clamps onto the base of the reflector:

Original set screw hole was in the wrong spot!

Here's how the original bulb holder fits:

Notice the double dip in the middle of the edge of the reflector base.  I failed to notice this when placing the holes for the set screws!

The final result:

The light is bright and very floody, much like my LED upgrade to the Sturmey Archer headlight. The beam does not produce a concentrated hot spot, which makes me wonder if this is a limitation of using LEDs with 100-140º viewing angles in reflectors designed for incandescent bulbs with  >180º spreads.  Some lux data will be required to sort this out.

Here's the matching Le Martelé rear lamp with a LED bulb replacement:

Sturmey Archer headlight Cree XM-L power LED upgrade

Raleigh Superbe's Sturmey Archer headlight. Photo by lowercase design

I really like the Sturmey Archer lamps that equipped later model Raleigh Superbes.  The older Raleighs (and other English 3 speeds) seem to have come with a variety of different lamp styles over the years.  My best guess is that when the Superbe hit North American shores in full force in the late 1960s and throughout the 1970s, Raleigh/Sturmey Archer had standardized their lamp offerings, which resulted in the now classic chromed bullet head lamp and tail lamp.  This version of the lamp set is what I see most commonly on the streets of Toronto, as well as in Flickr feeds.  They aren't especially rare and certainly don't show the craftsmanship and quality of the earlier French lamps, but a Sturmey Archer light set can still command  prices of well over $100 on Ebay.  They can even occasionally be found as a NOS.

The output from the incandescent bulb is rather pathetic.  This is mostly due to the low output from the Sturmey Archer Dynohub that typically powers the lamp, possibly exacerbated by the seemingly low quality of the reflector.  Halogen replacements are available from Reflectalite, but even these are rated at a rather paltry 18 lumens.  I tried upgrading the bulb with an screw base LED replacement, but found the output rather disappointing. I even went to the trouble of making a custom screw base power LED mounted on a copper heat sink.  This produced a big floody beam, but the flimsy bulb holder that mounts the bulb in the reflector probably wasn't up to the task of supporting the extra weight of the power LED's heat sink.

So, back to the drawing board.  To start, I thought I'd replace the flimsy stamped bulb holder with a copper heat sink.  The reflector is made of coated metal, so it shouldn't have any problem with carrying the weight of the heat sink, which can be wedged into the opening in the reflector in the same fashion as the original bulb holder.  This time I decided to use the super high output Cree XM-L, which is rated at 290 lumens @ 700 mA.  As in my previous designs for the Cree XPG, a nub pokes through the PCB so the LED's thermal pad can be soldered directly to the heat sink. Something like this:

Design for Sturmey Archer headlight heat sink

Looks a bit like a top hat. Here it is machined in copper:

Copper heat sink for Sturmey Archer headlight power LED upgrade

It flares out a tiny bit where the bottom of the pillar meets the rim.  Here's the heat sink with a Cree XM-L soldered on to it:

This is how the original bulb holder fits in the reflector:

and here is the copper heat sink mounted in the same opening:

Copper heat sink mounted in reflector of Sturmey Archer headlight

It fits very snugly in the reflector and doesn't feel like it's going anywhere.  A dab of Loctite wouldn't hurt though.  The LED sits low in the reflector, about where the original bulb's filament would be.

Sturmey Archer headlight with Cree XM-L power LED upgrade on copper heat sink

Coupled with an upgraded LED bulb for the rear lamp and a Dynohub magnet upgrade, a modern and powerful dynamo system emerges.  It will eventually even be possible to add a standlight and flasher.  The lamp is still a victim of its original optics, which obviously aren't nearly as good as the highly optimized optics of modern bike lights, but the high output of the Cree XM-L does result in a bright, floody beam.  Certainly enough for cruising around city streets in relative safety and quite possibly enough to illuminate a poorly lit country bike path.

I'm thinking of making this LED upgrade available, along with an LED upgrade for the matching taillight.  Let me know if you're interested either by commenting or by emailing me directly (bottom of page).

The XM-L can be run at up to 3A to produce a whopping 943 lumens so a battery powered retrofit could produce an impressive amount of light, although it remains to be determined if the heat sink would be adequate.  That would require some performance testing.

Programming an Attiny10 with AVRISP mkII and AVR Studio 5

Jump to Attiny10 programming tutorial if you want to skip my long winded preamble.

I've been tinkering with my dynamo powered LED flasher circuit recently. While the standlight works well, the blinking circuit requires that a 5W Zener diode shunt all 500-600 mA of dynamo current during the off cycle of the flash. At a frequency of about 2 Hz and a duty cycle of about 50%, I didn't think this would be a problem, but the damn Zener hits 100°C within a minute and showed no signs of slowing down, suggesting that I was taking it to within an inch of its life. I got some advice about using a power transistor to shunt the current, but using a 20W transistor still resulted in the device getting too hot too fast. I don't have room to put a big heat sink on it so I finally gave up on trying to shunt the current and getting rid of the off cycle energy as heat. I'm sure there is an elegant solution out there that allows the energy to be recaptured rather than wasted, but I'm already running the rear red LED close to its maximum current. Instead, I decided that I could do away with a flashing front light and just flash the rear light. This way, the dynamo is never disconnected from the load and the Zener does not need to shunt any current except in the case of a connection failure.  A low side N-FET seems to do the trick, shorting out the red LED when the transistor is on:

N-MOSFET shorts red LED when ON

Anyway, in the process I also decided that I wanted a flash that was below 50% duty cycle.  Ideally around 30% or so to better mimic the strobe pattern of commercial LED flashers.  You can achieve this with a 555 by adding a diode, but I thought I'd try using a microcontroller to generate the flasher's pulse instead.  Why, you might ask, would I want to do something so complicated? Adding a microcontroller to a bike light seems kind of overkill. Well, it turns out I can do it in a smaller package with fewer parts for less money (and learn something along the way). Win!

In my previous design I was using a 555 astable oscillator to generate the pulse.  The smallest package size is SOIC8, which is pretty bulky as far as surface mount devices go.  The smallest microcontroller I could find was the Atmel AVR Attiny10 that comes in a breathtakingly small SOT23-6 package.

TI CMOS SOIC8 555 timer ($1.72) next to SOT23-6 Attiny10 ($0.89)

Surface mount devices are pretty annoying for prototyping, but the advantage of their tiny footprints becomes readily apparent when you need to cram a lot of parts into a small pace.  Once I realized how useful SMDs are for creating physically small circuits, I accepted that the prototyping complications were worth it.  Getting the Attiny10 onto a breadboard requires a little adapter from the nice people at Proto-Advantage.  I soldered it using a soldering iron. Not as tricky as it seems.

Attiny10 on SOT23-6 to SIP board

Attiny10 programming tutorial


The Attiny10 part of the Atmel AVR family.  The Attinies are the baby siblings of the microcontrollers that are used in the Arduino development platform.  You can even program some of the Attinies with the Arduino, such as the Attiny85.

Unfortunately, the Attiny10 (and variants 4/5/9) won't work with the Arduino IDE and it isn't entirely clear if you can compile C for it, leaving assembler (ASM) as the most straightforward option for programming the whopping 1024 bytes of Flash ROM.   It took me a few days of fiddling around to get an Attiny10 to put out a pulse to blink my LEDs.  I've put together a little tutorial about programming the Attiny10 to fill in the blanks I found in online documentation, both official and in forums and the blogosphere.  Perhaps this  will make things a little easier on the very rare occasion that another layperson might want to program an Attiny10 using the available Atmel tools.

[rant]
Engineers seem to, rather annoyingly, assume that everyone using their products or protocols is also an engineer and their technical documentation reflects this assumption.   They seem to communicate by some Borg-like collective knowledge (otherwise known as an Engineering Degree) that is mostly impenetrable to the rest of us.  This is often a barrier to the minority of wannabe engineers who want to occasionally parachute into the engineering world to get something specific done without actually becoming, you know, an engineer.
[/rant]

This is a tutorial aimed at programming the Attiny10 in assembler using the Atmel AVRISP mkII programmer and AVR Studio 5.  By extension, it should also work for all members of the Attiny4/5/9/10 family. It really is just about connecting the Attiny10 to the AVRISP and being able to load hex code onto it because even this can be a frustrating challenge for the uninitiated. The Attiny10 datasheet, the AVR Assembler User Guide and Instruction Set are wonderfully indecipherable documents that you need to refer to for actual programming in assembler.  There is also this huge tutorial.

Adding to the confusion is the fact that there are numerous accounts that AVR Studio 5 is either incompatible with the AVRISP mkII, the Attiny10 or both.  As of January 2012, I can say that AVRISP mkII, AVR Studio 5 and Attiny10 all play nicely together on Windows 7.

So, let's start:

Step One: Get what you need

You need an AVRISP mkII programmer, AVR Studio 5 and some Attiny10s to get programming.  A breadboard and a SOT23-6 to SIP/DIP adapter will also come in handy.

There are a bunch of AVR programmers out there. I chose to use the AVR branded one, the AVRISP mkII, which is a little pricer than the USBTinyISP but requires no assembly.  One gentleman was so averse to using the available Atmel tools that he made his own programmer and his own IDE.

AVR Studio 5 is a rather huge and cumbersome piece of software that I'm sure is great for managing complicated multi-thousand line projects written in C.  You may or may not be able to compile C for the Attiny10, but you can definitely use AVR Studio to write assembler and use the very handy simulator to debug your code before flashing your Attiny.

I'm pretty sure you could also use AVR Studio 4, which is now mature.  In fact, many people seem to have delayed upgrading to AVRS5 because it is considered buggy.

I'm sure you could also use avrdude instead of AVR Studio.  It has been documented to work with the Attiny10. I have a strong aversion to command line interfaces, so avrdude was out (dead give away that I'm not an engineer...).

Step Two: Connect the programmer

After downloading and installing AVR Studio 5 you should be able to connect the AVRISP mkII to your PC and see a green light glow inside, next to the USB connector.  An exterior LED is red to indicate that there is no external power (weirdly, the AVRISP, despite having Vcc and GND connections, cannot be used to power the Attiny during programming).

Confusingly, the Attiny10 and its ilk are not programmed using the same 3 wire MISO/MOSI/SCK ISP protocol used by other AVR microcontrollers.  Instead, they use the 2 wire Tiny Programming Interface, or TPI.  What wasn't at all clear to me from the various documentation available was how you connect the AVRISP mkII to an Attiny10.  The AVRISP mkII User Guide makes no mention of TPI. The mkII is documented as being compatible with the Attiny10, but I had to really hunt around to confirm the pin connections from the programmer to the Attiny10.

Pin connections from here

AVRISP mkII	Target	ATTINY10
connector	pin name	pin number
1 MISO	TPIDATA	1
2 VCC	VCC	5
3 SCK	TPICLK	3
4 MOSI	–	–
5 RESET	RESET	6
6 GND	GND	2

The programmer's Pin 1 is opposite to the red mark on the cable and is marked with a hard-to-see arrow/triangle.  I hooked it up wrong the first time, so double check that you've identified pin 1 correctly!

AVRISP mkII connected to Attiny10

From left to right: (1)MOSI/TPIDATA, (2)GND, (3)TIPCLK, (5)VCC, (6)RESET

You need to connect an external 1.8-5.5V power source to VCC and GND before you can program the  Attiny10. The programmer's exterior LED will go from red to green when it senses the external power. I use a 3.7V lithium ion battery for power.

Step Three: Program the Attiny10

Launch AVR Studio 5 and make a new assembler project: File:New Project... In the dialog select the AVR Assembler Project template.  Then select Attiny10 from the Device Selection dialog that pops up.  Write your code (I wanted to blink an LED, so I grabbed and modified some ASM I found here - if you follow that link note that the Attiny10 has PORTB instead of PORTD).  This performs a nested decrement of registers.  Two registers for the ON delay and three registers for the OFF delay (ie. longer OFF time than ON time). This is what my code looks like:

 rjmp RESET  ;go and set up PORTB as an output 


;name registers (selected >r15 arbitrarily)
 .def  counter1  = r16
 .def  counter2  = r17
 .def  counter3  = r18 


;set some variables 
 ;time1 and time2 set the value for the final loop in each delay
 .equ  time1   = 170 ;between 0 and 255
 .equ  time2   = 1
 .equ  led     = 2 ;LED at PB2 
   
RESET: ;set PB2 as an output in the Data Direction Register for PORTB
 sbi   DDRB, led  ;connect LED to PB2 (Attiny10 pin 4)
      
flash: ;main loop  


 cbi   PORTB, led ;LED off - cbi/sbi swapped for N-FET switching (ie.LED is OFF when FET is ON)
 ldi   counter2, time1 ;load counter1 delay         
 rcall onDelay            
 sbi   PORTB, led ;LED on           
 ldi   counter3, time2 ;load counter3 delay
 rcall offDelay
 rjmp  flash  ;return to beginning of loop


onDelay:       
 clr   counter1  ;clear counter1 


loop1: ;nested loop that decrements counter 1 (255) x counter2 (time1) times (ie. 255*time1)
 dec   counter1  ;decrement counter1 
 brne  loop1     ;branch if not 0     
 dec   counter2  ;decrement counter2 
 brne  loop1     ;branch if not 0     
 ret      
                
offDelay: ;same as onDelay but with a third loop     
 clr   counter1
 clr   counter2 


loop2: ;decrement counter 1(255) x counter2(255) x counter3(time2) (ie. 255*255*time2) 
 dec   counter1
 brne  loop2         
 dec   counter2
 brne  loop2          
 dec   counter3 
 brne  loop2 
 ret     

This is pretty rudimentary. It basically just kills time by pushing bits around registers.  A more elegant solution would be to set up an interrupt triggered by the Attiny10's 16 bit timer (more on that another time).

Build your code by selecting Build:Build Solution.  This converts the ASM to machine code.  If it builds successfully it will generate a .hex file in the project's folder. This is the file you need to load onto the Attiny10.  You can simulate your code by going to Debug:Start Debugging and Break and and then hitting F10 to step through the instructions and looking at how the contents of registers and ports change, etc.

When satisfied, you program the chip using Tools:AVR Programming. Select AVRISP mkII in the Tool drop down list and Attiny10 in the Device list.  TPI will come up in the Interface list by default.  Click 'Apply'.  If there is a connection problem, you will discover it here.  This is the time to make sure that the Attiny has its own power and is connected to the AVRISP correctly.

Go to Memories and click '...' to select your project's .hex file if the contents of the Flash box aren't pointing to it already.  Then click 'Program'.  The programmer will load the code and then you can test it out.

I found that the programmer needed to be reset by unplugging it from USB and then reconnecting it before I could get each upload to run properly on the Attiny10.  I chose PB2 (pin 4) to blink my LED because it isn't connected to any programmer  lines, but the other lines should work even if connected to the programmer, so long as it has USB power. If the programmer is off then the Attiny10 didn't like being connected to it.  Once satisfied with your program you can disconnect the programer lines and operate it stand alone:

Attiny10 blinking an LED

These are the two sites I found most useful for learning the ins and outs of Attiny10 programming:

http://irq5.wordpress.com/2010/07/15/programming-the-attiny10/
https://sites.google.com/site/wayneholder/attiny-4-5-9-10-assembly-ide-and-programmer

There's also information scattered all over the avrfreaks forums.

Beautiful retro styled lights by Kimura from Jitensha Studio

Browsing around today I came across these for the first time:

Kimura flashlight

Kimura tail lamp

They are Kimura lights from Jitenshi Studio, a bicycle shop in Japan that specializes in high quality touring and randonneuring bikes.  The lights are handmade by one Mr. Kimura.  They're not inexpensive ($195 USD for the flashlight, $125 for the taillight), but the quality looks amazing, easily rivalling similarly priced offerings by Schmidt or Supernova, but with infinitely more retro charm.  Too bad Mr. Kimura isn't in the business of making dynamo lights.

Mounting a vintage flashlight on a front rack seems to be a popular way to dress up your vintage (or modern classical) touring/randonneuring bike.  Historically I think these flashlights served as auxiliary lighting for bottle dynamo systems when stopped. Here is a particularly gorgeous example from the Velo-Orange site:

Vintage flashlight on a bike.  Image from Velo-Orange.

The tail lamp is especially intriguing.  I wonder if the lens is pulled from a mass-produced light or if it was made specially for this application.  They also have a nice selection of reflectors.

Dynamo digital buck converter: progress report

Inspired by this thread at CPF, I built a prototype of a digital buck converter using the Arduino development platform.  The point of it is to extract more power out of a hub dynamo without adding extra LEDs in series.  To rehash: modern hub dynamos typically saturate at about 500-600 mA and their voltage is primarily determined by the load, so the easiest way to passively get more power of them is to add more LEDs in series.  Each LED gets the same current in the series circuit, while Vf of the whole series circuit goes up by the forward voltage of each additional LED. White LEDs typically have forward voltages of about 3V, and most hub dynamos easily put out 6V at low speeds, making this a viable arrangement.  Even 3 series LEDs with a Vf of 9V can produce a lot of light at low speeds, although the minimum speed that reaches Vf will, of course, be higher than with fewer LEDs.  However, I'm primarily interested in single LED designs for retrofitting into vintage lamp housings.  With proper heat sinking some white power LEDs can take well over 1A.  In order to extract more current out of the hub we need a buck converter that converts the higher voltage available from the dynamo at higher speeds into more current for the LEDs.  This is done by switching the buck converter with pulse widths below 100% duty cycle.  Here's the schematic:

Schematic for Arduino-controlled digital buck converter for hub dynamo

This is a synchronous buck converter that uses two switches rather than a single switch and diode.  This increases efficiency by reducing switching losses (ie. the voltage drop across the diode).  MCP14628 is a MOSFET driver specifically designed for digitally controlled SMPSs;  when UGATE is high, LGATE is low and there's a buil charge pump to drive the high side FET.  The PWM signal comes from the Arduino.   This circuit worked fine with a bench top power supply, taking a higher voltage input and converting it to a higher current at Vf of the series LEDs.  However, when I connected it to a dynamo Q1 kept getting fried.  This was probably due to Vdyn (rectified DC dynamo input) spiking when the load is disconnected while Q1 is off, exceeding Q1's maximum Vgs.   I added D3 to  take care of this (Vgs(max) of these FETs is 30V).  Despite this, I still would occasionally fry Q1.  C3 and D2 were added to protect the high side FET from getting zapped by exceeding its Vgs, this time perhaps due to parasitic inductance of the long wires in my messy breadboarded prototype.  C3 and D2 seem to work and during normal operation Q1 doesn't get fried anymore. However, when the load is disconnected or I mistakingly set the duty cycle to 0% in the software, Q1 gets toasted.  I asked for help here, and am starting to get some answers.  Making C3 larger might be a good start.  It is situations like this one where my complete lack of electrical engineering training becomes a bit of a barrier to progress...

The ZXCT1009 is a high side current monitor that is used as feedback for the PWM signal.

Here's what it looks like on the breadboard:

Buck converter spaghetti!

Pretty messy, which is certainly reducing efficiency.  Once it's tidily committed to a PCB I hope the efficiency will go up a bit and there won't be as many issues with parasitic inductance.  I'd also like to double the switching frequency from 32 KHz to 64 KHz so I can use a smaller inductor.

Here's how my buck converter performs with 2 series LEDs with a Vf of about 5V powered by a Sanyo H27 dynamo:

Current versus speed of a dynamo powered buck converter at different duty cycles. Switching frequency is 32 KHz

The advantage of dropping the duty cycle appears just over 20 km/h, although it is quite modest.  Above 30 km/h I think the converter is getting a worthwhile amount of extra power, roughly 200 mA (1W or about 40% more).  Efficiency is roughly 80%.  I need to test other duty cycles and perhaps go below 50%.  Thus far it seems like there's not much peak power tracking to be done.  A simple implementation would be to leave the duty cycle at 100% below 20 km/h and then drop it to 50% above that.  The H27 saturates at around 500 mA, whereas other hub dynamos saturate at slightly higher currents. Perhaps they also have better low speed performance and if they can generate a higher output voltage at lower speed then there might be more of an advantage to using a buck converter.

There is another microcontroller-based dynamo LED driver out there.  Its performance seems to be considerably better than mine;  it produces surprising amounts of power at low speeds, whereas mine can only begin to harvest more power out of the hub just before it saturates.  To be fair, because of my specific application, I am measuring current into two series LEDs rather than total power output, so this is a bit of an apples to oranges comparison. However, there is no denying that this converter seems to perform better at speeds below 30 km/h. I naively speculate that its switching topology is something other than buck, but really I have no idea how it's done or how complicated or expensive the implementation is.

I'm not entirely sure if the complication of a buck converter is worth the effort.  Human perception of brightness is commonly described as logarithmic, meaning that a linear increase in actual luminous flux does not result in a correspondingly linear increase in the perceived brightness.  I've not really found this put very succinctly on the Internet, so this might be an oversimplification (and hopefully not entirely incorrect).

Whether or not this whole exercise is mostly academic remains to be determined...