Building a better bike tail light

I realized a bit later that when I removed turbo it was more than just the step-down code… It removed the highest mode too.

If I re-add turbo (10 total modes instead of 8, with a higher solid mode and a higher flasher too), the levels end up like this:

  • Moon: 0.2% / 1.4 lm (more like 0.5 lm after being on a higher mode)
  • Low: 1.5% / 11 lm
  • Med: 12.3% / 87 lm
  • High: 45% / 321 lm
  • Higher: 100% / 710 lm

These are adjustable of course, but this is the default inherited from STAR. Well, except I bumped “moon” up by one PWM value, since its old value varied between 0.05 lm and 0.25 lm and it seemed like too big a jump between there and “low” in the moon-low flasher mode. Also, I’m planning to use this with a 700mA driver instead of the 3040mA driver I’m testing with, so it’ll probably be lower on the actual hardware.

The moon mode seems to be at its lowest just after I’ve used the highest mode. Then it slowly brightens over several minutes of use. It really isn’t regulated very well. The low and medium modes seem to maintain a fairly constant brightness, but high and higher definitely droop when they’re on for a while. This could easily be due to my cheap test setup though, instead of an actual driver issue.

TK, I am glad to see this post. I have done a lot of work coming up with the ultimate tail light for bikes.

I have come up with a very good setup with standard drivers. All the work so far on custom drivers have focused on solid modes since the blinky modes are so unpopular.

The drivers I run are the 17-mode NANJG drivers found at various outlets. I use two modes for most daytime commutes: the normal hyperflash, and the excellent Police mode.
Efficiency is the key element I was trying to achieve. A 2hz flash would be great. I find that the most efficient mode is the Police mode - 5 rapid flash and a pause. The normal strobe is about 50% duty cycle. Oddly enough, the built in 1/2hz flash is less efficient than the hyper-flash (strobe). Police mode is about 35-40% duty cycle.

I also found the XM-L to be most consistent. The driver supplies the correct voltage until the last 5 minutes of battery life. This is based on 1050ma (3x 7135). Adding another 7135 doesn’t seem to make a significant difference in daylight. Reducing by one, however, does.

I also found that a single 7135 with constant drive and running a mode on two more really reduced the effectiveness of the flash. I use this for a headlight, but on a tail light, in daytime, no use.

How do you plan to get around the lower Vf of the red LED? I have been curious about that. It seems a lot of energy is going to go into the current limiters and you might even end up with a heat problem. I will be curious to hear your findings on this. Obviously, a red LED would be perfect, but I suspect these will require a buck driver in the long run.

I solved the red tint using Rubilyth film. On glass, they stick very well, on plastic, just maintain the backing material. If the emitter is close to the material, it will require replacement every couple of years as it degrades from the heat.

Last, I absolutely recommend spherical lenses! The best host I have found is the Tank 007 TK736. Lots of clones for this one, but the built of the TK736 is great and easily modified for the larger 26mm lens. This really give a great sight cone angle and evens out the beam strength. You don’t get that “on-axis” blinding that you do with focused beams. Rather, the cone of light is very even to nearly 90 degrees (inclusive). The wonderful thing about using the spherical lens is that they are very efficient when the emitter is close to the lens. It is focusing that makes them less than desirable in normal flashlight use. Since, as cyclists, we prefer the defocus mode, we gain on the efficiency factor.

Battery capacity has been the other boon to the quest. With good cells, runtimes can now reach a full day’s ride. I always run 2 in the back in order to have redundancy.

I will be following this thread with great interest in what kind of modes you come up with. I still cannot see myself programming the PM but you do give me hope that a bike friendly efficient setup can be achieved. Let me know if you need some evaluation done.

Those drivers are the closest I found in a stock driver, but it wasn’t really what I wanted.

The flasher modes on mine currently do four rapid flashes and then pause (except that at the bottom of its duty cycle it’s not off, it’s just on a lower level). The overall duty cycle for it is about 2.7. The 2Hz flash (well, heartbeat-style flash) only stays on for a millisecond or two, so its duty cycle is closer to 0.27. If my numbers are anywhere near correct, I figure that gets me about 250 hours of runtime on “heartbeat” or about 40 hours on the low-med flasher, using a 550mAh 16340 battery. These are early estimates though, and I’ll have to tune everything after the rest of the hardware shows up.

I’m not too worried about the heat. At the ~12.5mA average drive current it’ll have on the low-med flasher mode, that’s about 50mW of total power. I think about 10mW will go out the front as photons, 20mW of heat comes from the emitter, and another 20mW of heat burns off at the 7135 chips. I think it can handle 40mW of heat with no problems.

I don’t plan to run it for long on the highest mode though, since it’ll eat the battery in like 45 minutes and might overheat. That’ll be about 1120mW of heat at the emitter (should be okay) and 1120mW of heat at the 7135 chips (might melt them off or damage them). Then again, since it’s only a watt or two of heat, it might still be fine. If I get really worried about it I could pot the driver, but I don’t think that will be necessary.

I considered that, and I’ve even tried it, but the beam just isn’t wide enough. The widest aspheric I’ve seen gets about a 90-degree beam spread, and I’m looking for a minimum of 170 degrees. Ideally, it’d be more like 270 degrees, but I haven’t found a way to do that yet. So, I’ll settle for 170 degrees on the back and 170 degrees on the front.

I’ll be adding at least two layers of DC-Fix to the lens to get the beam spread out. I’m not sure if that will really be enough, but I’ll find out during testing. One layer gets the 170 degree beam pretty easily, but it still has sort of a hotspot. Hopefully two layers (one on each side of the lens) will be enough, since things get a little awkward with more than that.

Based on the data available to me, I think 15 hours of runtime (well, biking time) will be the minimum, and it might be able to achieve much much more depending on how well it actually works in practice. But I’m not really trying to achieve daytime visibility. I only really care about night riding and dusk.

I’ve done a lot of testing on the timer trying to get it down precisely for my needs. I’ve also lowered my WDT to 250mS (from 500, meaning where it was 2WDT ticks/second my FW’s now use 4WDT/sec which has helped to improve the accuracy/repeatability greatly).

If you need help with this I can post the code to change the timer, just let me know if you need it, I’ll be at my computer in a little bit. I can also give you some of my test results that show the exact value’s to use to get 30,45,60,90 and 120seconds on the dot (well not 100% precise but timing with a stop watch as fast as human reaction time allows).

Thanks. I might prefer a 250ms (or faster) WDT for more accurate mode memory timings. Feel free to post the code. :slight_smile:

As for timings with _delay_ms(), I’ve found it pretty effective to just assume there are about 750 “ms” in a second, and then try to measure/tweak from there. It seems to generate different code for different delay values though, and the amount that time gets stretched or compressed seems to vary based on the requested duration. The resulting code size also changes for different values. So, again, all I can do is measure, measure, measure.

Additionally, I think the generated code is likely to change when I upgrade my avr-gcc from 4.7.2 to whatever is current. Measurements from one version might not apply to others.

BTW, do you know if the WDT’s real-world frequency changes when the CPU speed changes? Another firmware I’m planning will make heavy use of CPU clock changes, and I’m a little worried about how to provide a consistent UI when time itself keeps getting faster and slower. It’d be awesome if I could make the WDT tick at a consistent speed regardless of the CPU clock, especially if that speed can be close to 10 times per second.

awesome work on the firmware TK, it’s not a trivial task. I really like the on-and-flashing modes too, that’s one of the highlights of the mobydrv that DrJones made.

It’s kinda tricky to make a torch into a good bike light, especially a rear light, for the reasons you’ve mentioned - limited side visibility, mounting and use of a clicky switch. I’d go ahead and make what you’re planning to make, then have a think about making your own host. It’s not particularly hard, especially if you use an alu project box or square alu tube. I built a really bright one using a triple red XP-E wired parallel with a built in 18650 and USB>li-ion charger. The driver is a kinda clunky 7135 set up using a flashing red 5mm LED to switch on a 2nd bank of chips to make 350mA on/ 1.4A flashing. I’ll be watching this firmware and others as I need to swap out the failing clicky switch and driver for a e-switch and proper driver.

I must be missing something in the threads. What are you actually doing to get 170 degrees of coverage?

To get 170 degrees of coverage (sort of), I added diffuser film to the lens. It’s still brighter in the center and dimmer the farther out it goes, but it’s still pretty visible as long as there is a line of sight to the lens. Here is a comparison of the beam spread with and without diffuser:

Here is another light with the same stuff on the lens, lifted somewhat off the ground to show the beam pattern better:

It looks like this from the front: (smiling Mickey is a coincidence)

One nice thing about this approach is that it’ll make me visible from a greater distance behind, so cars should be able to see me easily from more than a mile back on the road. But from the side they’d need to be much closer to get the same level of brightness. The way I’m mounting the light though, it’ll be angled slightly downward. This should help make it less obnoxious to someone biking right behind me, since they won’t be getting anywhere near the full brightness — their eyes are well above the brightest part of the beam.

Thanks for clarifying that. I use a diffuser on the front light that make the beam more “rectangular”.

Honestly, I have much less concern using standard off-the-shelf blinkies on the back for night riding. With good batteries, many will demand serious attention from drivers. Less so, of course, when you hit the well lit streets.

I also have the advantage that the light is reflected from other surfaces. This does help with side vision but at a great reduction of effective lumens.

I should look into how to make a high angle red diffuser where the emitter is smack dab in the middle of a sphere. It can’t be that hard :slight_smile:

I use to ride with valve-stem lights. They drew a lot of attention when cars were close, but at any significant distance, they just were not big enough.

I put the first light together tonight. I’ll have pictures and details later, but for now I think it’s almost bed time.

It went together pretty quickly except for one thing… The attiny13a on this AK-47A driver really really didn’t want to be flashed. It was getting corrupt data almost every time I tried to flash it, often not even getting its device identifier string correct. I didn’t get a functional ROM onto it until I reduced the ROM size to 98 bytes, and even then it didn’t work on the first try. Later I managed to get a ~900-byte ROM onto it, and I’ve been afraid to touch it ever since. It isn’t doing mode memory correctly though, and I need to tweak the levels and modes, so I’ll need to flash it again sometime. Maybe after I’ve built the other two lights. I really hope the other two flash more easily.

I’ll post more later… but for now, just a close-up of the red XP-E2 mounted on a Noctigon. It’s a lot smaller than it looks:

Oh, nearly missed it; sure, you can put NLITE, luxdrv, MiniDrv and MiniMo into the repository. Good idea, thanks for managing the repository :)

Hi, I’ve been stalled due to other projects, but today I tested the output of this light at 700mA with a 16340 cell. The actual modes still need to be tweaked, but this at least gives me an idea of the range I can expect:

  • Moon: 0.98 lm
  • Low: 3.50 lm
  • Med: 19.6 lm
  • High: 75.5 lm
  • Maximum: 173 lm

So, I’m actually getting more output than I expected — 173 lm instead of 142. And that’s after putting DC-Fix on both sides of the lens, using a battery which wasn’t fresh from the charger, so I suspect the output could be perhaps 15 or 20 lumens brighter in ideal conditions.

I’ll have to build a second host before I can tweak and test anything else though, since the first host’s MCU is extremely difficult to flash. I hope the second one will be easier.

Waiting for pics :slight_smile:

^^this

That’s pretty good output for a tail light. What is the Vf at the emitter for this? Just curious how hard the 7135’s are working at 700ma.

I haven’t tried to measure the Vf, but the data I found suggested it should be about 2.3V at 700mA.

Sorry for the delays… I still haven’t assembled the other two hosts so I don’t have pics yet or final firmware. I did fix my firmware flashing hardware though, so hopefully it’ll be easier to reflash now. And I got a chance to try it on the road… I don’t remember now whether I was using the first or second flasher (first, I think), but from about a third of a mile away it was about as visible as a car tail light… with plenty of room to get brighter if necessary.

As you guys know I have lots of color XP-E2’s in all sorts of different projects (using several different regulation methods and DD) and I’ve actually found the Vf to by a good amount higher than in DJOzz’s tests even at much lower currents. I haven’t measured specifically at 700mA but at 120mA I’m reading 2.6-2.8v over the emitter.

These are all DTP mounted and all from the same exact batch (ordered 30 of each color at once from digikey). My findings have been consistent threw 8 different lights, some running 7135’s, some running my dual transistor CC circuit and one DD (tho I obviously can’t measure that one at lower current levels).

When I was making the very first RGBW driver everyone was jumping on my telling me the red emitters couldn’t handle it and would die instantly, that is simply not the case, these things are amazingly resilient and can handle nearly the same voltage (and just as much current) as the B and W and even G ones can.

I have been following the data in these but something just isn’t adding up…

170 lumens at 700ma? 2,7Vf at 120ma? This doesn’t jive with the spec sheets or the graph:

It’s very possible that my cheap lux meter gives skewed results based on the tint. However, it does visually look like it’s about as bright as my ZL H51w, as much as a red light can resemble a white light.

I guess the only reason I have held off on the red emitter project is the status of the AMC7135’s in the loop. At lower currents, they will be working harder and the peak charge on the cells will give them a jolt. It almost makes more sense to attain the 700ma (RMS) using a high rate PWM and just removing the high mode (if that is the goal). This allows more 7135’s to manage the load and the efficiency should be increased significantly. Since most flash modes are 100% on, these too would want to be limited to the PWM settings for the 700ma max. I don’t know how hard this is to manage in coding.

In my world, a red bike tail light is comfortable at 1.0 amps (3x 7135) using aspheric lenses (wide beam angle). I would have no qualms with driving this with 4x 7135 and a 75% PWM. Anything to keep from wasting energy in the form of heat in the driver.

What I do welcome is runtime. Right now, at 1.05A NANJG 47-AK using the police mode (16 mode driver) I get 10 hours on a 3400mah cell. This is the most efficient flash mode I have. This is what I am interested in when it comes to bike lights; highly recognizable and efficient flash patterns based on a known output levels.