As long as the emitters are on good copper stars and thermal management is adequate, you can easily push the emitters beyond the specs shown on data sheets, guys here routinely hotrod them w/o issue…albeit the heat produced goes up faster than lumen output, unfortunately, once you get past the spec sheet data of course 
I understand that, Warhawk, but the discrepancy here is the Vf at a lower current. According to Cree, the Vf is only 2.65V for a 1A draw. At 350ma, the Vf should only be 2.2V. The only logic for why an XR-E2 red emitter would run at 2.835V at only 200ma is that a 2A break-in period fundamentally changes the specification of the emitter.
I also noted that MTN Electronics sanctions (loosely stated here) 1.9A on a Noctigon with adequate heat-sinking. Again, I am not questioning the findings. Awareness here definitely deserves more study on my part. And trust me, Cree will be in the loop to get to the bottom of this. To date, I have not seen such a huge discrepancy in their product line.
I had to go look at the source code again, but what I’m using now is:
- Bright for 5ms, then dim for 65ms.
- Repeat the above 3 times (4 blinks total).
- Dim for 720ms.
- Repeat the whole process at a rate of once per second.
So, it’s bright for 20ms total and dim for 980ms, meaning the duty cycle is actually (0.02 * bright) + (0.98 * dim). Both are using PWM at 19 kHz, so a 5ms bright flash is actually 95 individual pulses (0.005 * 19000) at a speed too fast to perceive.
On my S7-219B, I find this sort of flasher works well as a handlebar light, alternating between levels 3 and 5 (med and max, 42lm and 342lm). Those modes run at 187mA and ~1800mA, resulting in an overall draw of 219mA ((0.98 * 187) + (0.02 * 1800)). With a 3100mAh cell, that gives me just over 14 hours of run time on a mode which is extremely visible. My alternative would be to run on mode 4 all the time (155 lm, 745mA), which would give me a bit over 4 hours of run time.
The main difference for the tail light is that it’s red, pointed backward, and running at lower levels. Plus, it has even more diffuser film to make the beam wider.
What is the rise time of each pulse? I’m guessing you are not reaching full output in the 5ms bright modes with this high frequency rate (19kHz)?
Rise time is one of the variable difficult to account for in the runtime equation. It actually increases runtime but lowers output if clipped.
I can see how the S7-219B remains distinctive. My brightness ratio was closer to 3/1 which washed out the flash too much. You have a near 9/1 ratio. 14 hours is still an impressive runtime!
I will have to retest my police mode against a 3100ma cell (or new 3400mah cell since all my 3100’s are well used). I have a 1.4A and a 1.05A XM-L light I can test. The frequency of the police mode is 5 fast flashes per second (approx.) and no reduced on-time.
Rise time of each pulse? Heh. 5ms is way more than enough. My true strobe modes have a duty cycle of 0.3ms, and even that is plenty.
TL;DR: The rise time for a common attiny+7135+emitter setup is roughly a millionth of a second. Ish.
First, some measurements for reference:
On my Convoy S7-219B host with 5x7135 (380mA), or 1900mA total… with a Nichia 219B and a reflector which rides too high (loses like 20% of its output due to that)… I got the following readings:
|. Mode |. Lumens |. PWM |. Current |. Runtime on 3100mAh cell |. Efficiency |
| Moon: |>. 0.14 lm |>. 6 |>. 2.6mA |>. 49.6 days |>. 54 lm / A |
| Low: |>. 7.3 lm |>. 14 |>. 36mA |>. 86 hours |>. 203 lm / A |
| Med: |>. 42 lm |>. 39 |>. 187mA |>. 16.5 hours |>. 225 lm / A |
| High: |>. 155 lm |>. 120 |>. 745mA |>. 4.16 hours |>. 208 lm / A |
| Higher: |>. 342 lm |>. 255 |>. ~1800mA |>. 1.7 hours |>. 190 lm / A |
My S7-219B has a 0.14 lm mode and a 7.3 lm mode, running at efficiencies of 54 lm/A and 203 lm/A respectively. Based on the difference in efficiency I think the moon mode (0.14 lm) runs into rise-time limitations, but the low (7.3 lm) mode does not. So, let’s use that to work out the approximate rise time.
The maximum mode is 342 lm, and I’ll use the relative outputs as an approximation of the duty cycle. So, 0.14 lm is a 0.04% duty cycle and 7.3 lm is a 2.13% duty cycle. Both are running at 19 kHz PWM. So, the pulses happen every 19000th of a second. 2.13% of that is 1/890,000th of a second. But what about the moon mode? 0.04% of 1/19000 is about one 46.4 millionth of a second.
So, based on this I’m guessing the 7135s and emitter can emit short pulses somewhere between one millionth of a second and one forty-millionth of a second. A 5ms pulse is no problem whatsoever.
Going from specs instead of measurements, the attiny13a runs at 4.8 MHz. Its 19 kHz PWM mode has 256 individual “frames”, and non-coincidentally, 19000 * 256 = ~4.8 million. I’m using a PWM level of 6 for the moon mode, meaning it’s on for 6 frames then off for 250 frames. However, the output is 0.04% while the “on” frames are 2.34% of the total. Quite a difference. For the 7.3 lm mode, it’s a PWM level of 14… so, 5.47% of the frames are on, but the output is only 2.13% of the total. From this, I’m guessing that the full output takes about 9 or 10 frames to achieve. … and I just sanity-checked that against the next-brightest mode, and that checks out too.
So, going by that… I think the time to rise to full output is about 1/500,000th of a second. Again, 5ms (1/200th of a second) is no problem.
On this device, it’s about 6 frames to get any light at all, or about 9 frames to get full output. Not sure what’s happening in those first 5 frames (7135s warming up?), but the last 4 frames account for 1/1,216,000th of a second to go from zero to max.
I don’t know the true number for the rise time. At 9 kHz PWM I can get a useful moon mode at a PWM level of 1… which gives a shorter estimate than the results from 19 kHz PWM. But I’m pretty sure the rise time is somewhere in the ballpark of a millionth of a second, plus or minus a factor of three. And since I completely ignored fall time, it could be off by another factor of two. But it’s easily close enough for my bike-light-and-party-strobe purposes.
This is only valid for an attiny13a using 7135 chips and a Nichia 219B emitter; I don’t know what the actual limiting factor is. I think the numbers are nearly the same for recent Cree products though, at least for XM-L2 and XP-G2 and XP-E2. Original XM-L seems to have a significantly slower rise time.
Sorry for all the math, it was a good question and I wanted to figure it out in public.
rise time per PWM pulse, not the on time.
I suspect the rise time is a 7135 limitation rather than the MP and I am not sure what that is. Comfy had posted some good images of a scope reading I need to find again. edit: post 6 here… FETs and gate resistors - scope images
The emitters will take a few frames to “warm up” and that residual heat is cumulative in the high rate pulses. This is fairly straight forward and will change from one emitter version to the next.
Nice work on the characterization, BTW. 
Ah, yes. For my true strobe modes, I use PWM=255… so the PWM rise isn’t really an issue. For the bike flasher, it uses a PWM level which may or may not have individual pulses. The handlebar light spikes to 255 so it’s not affected, but the tail light spikes to a lower level and thus has the 95 individual pulses in every 5ms flash.
Thanks! It’s good to see some more direct measurements. Going by the graphs he posted, it appears the actual rise time is about 1/220,000th of a second. That’s toward the outer edge of my guesses, but still within the error margin I was expecting. Not bad, for a cheap DMM, a cheap lux meter on a milk carton, and some napkin math.
(20 microseconds per 78 pixels, ~18 pixels from zero to max output, so about 4.6 microseconds for full rise)
Yep, and that varies with the circuit too.
Just for grins I put 3.95V on one of my SuperFlash road-salvage lights. It is a red “brand X” emitter driven to ~200ma and 1.85Vf across the emitter and that is with a 2R0 resistor inline. there is definitely signs of PWM on the light as you can see strobing when I move the light around on the wire or move my hand in front of it. It has no heatsinking to speak of except the robust copper traces on the fiberboard. According to Planet Bike, this is a 1/2W LED that is now being driven at 0.8 watts. And yes, it is a bit warm but touchable. I’ll see if the characteristics change on this one through a burn-in.
I suppose I should try to measure the emitter voltage next time I build a bike light or take one apart. I haven’t actually done it before, but it seems simple enough… I just need a third and maybe fourth hand to hold everything in place while measuring.
Correction… my 1/2 watt emitter is actually driven to 0.37 watts (1.85V at 0.2A ). That mean somewhere in the circuit I am loosing ~.43 watts. No inductor in this circuit so it has to be linear.
And yes, this thing is painfully bright in my dark lab.
I am seeing how long this thing will manage regulation. It could take a while. It is just now down to 3.83V :weary:
Much better practice to solder DMM leads directly to the emitter pad’s than to try to hold probes on it.
Now this is interesting… input is down to 3.57V and the Vf on the emitter rose to 2.0V and the total current is now at 180ma 0.36W across the emitter and only a 0.28W loss across the rest of the circuit. The output is still quite intense.
Edit: now there is some wild variation that can only be explained by thermal characteristics. This morning the cell rested back up to 3.6V under load and the turn-on current is still 180ma but the Vf is only 1.56V.
Edit: 3.31Vin at 120ma and 1.65Vf. Thermally much more stable and notably cooler than 4.0Vin. These lights are optimized for 3.0Vin and less. I’m surprised I didn’t blow something at turn on.
Final numbers is 3.0Vin at 105ma and 1.54Vf and notably dimmer and much easier to look at.
This would almost make a nice direct drive emitter on a 1.5V alkaline cell.
ToyKeeper,
Just wanted to let you know I used your code in two pair of L2M’s I built. I disabled the LVP (simply pulled the resistors) and am running 1x 7135 each to the XP-E2 (one each Red and one each Amber). These are emergency lights I keeps in me and my wife’s cars. After having to tow my sister’s car home (with a strap) about 4 miles a few months ago after dark with absolutely zero power (so no brake / tail lights, used my H52 to have something back there) I had been looking for a solution to keep in the cars. These give me the option of a red or a yellow flasher and at such low current (and no LVP) they run several hours from a single CR123.
LVP as in low-voltage protection?
I think you could just remove the “#define VOLTAGE_MON” line to disable that. In any case, I’m glad it’s working and useful for you.
I still need to build the other two tail lights, and fix the firmware on the one I’ve been using. And I might (maybe) even have time soon! 
you obviously don’t live in Virginia, as that would be a terminable offense in VA: such an action would actually be considered suicide-by-cop
FWIW, I finally got back to the firmware for this light. It has some significant improvements now…
- Added a battery check mode.
- The modes are now 5 solid modes, 3 dual beacons, 1 heartbeat beacon, and the battery check. In that order.
- Mode memory is enabled and working, to make sure the light stays on the same level if power gets briefly interrupted by a bump in the road.
- Timing (in general) and the moon mode are calibrated better now.
- Managed to reduce the overall ROM size, so there’s room for more stuff if anyone wants to add anything.
The battery check mode will blink 0 to 5 times, wait a couple seconds, re-check the voltage, then repeat. The blinks represent:
- 0 blinks: < 3.0V
- 1 blink: 3.0 - 3.3V
- 2 blinks: 3.3 - 3.6V
- 3 blinks: 3.6 - 3.9V
- 4 blinks: 3.9 - 4.2V
- 5 blinks: > 4.2V
You can basically think of each blink as being 25% of a full charge. I know li-ion capacity doesn’t correlate with voltage on a linear curve, but at least it gives a decent idea when the battery needs to be charged again.
As always, the latest is available here:
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/head:/ToyKeeper/tail-light/
Is this for the Atmel tiny13a?
Yes, it’s for the common attiny13 used on many common budget drivers. I’m using a one-sided variety with just two 7135 chips. IIRC, it’s called an “AK-47” driver. I’ve used virtually the same firmware on other attiny13-based drivers though.
glad to see that you're still cracking on with this TK :) Garrybunk referred me back to this thread after talking about some different strobe modes. I have to say I completely forgot about the work you were doing, sorry! I'm starting to read through some different firmwares so I can begin understanding what's going on. I should really go and read the manual and learn it properly, but that's competing with me reading at least 3 textbooks too..
So, I figured out that this is the on-and-flashing part:
while(1) {
if(mode_idx < SOLID_MODES) {
sleep_mode();
} else if (mode_idx < DUAL_BEACON_MODES) {
for(i=0; i<4; i++) {
PWM_LVL = modes[mode_idx-SOLID_MODES+2];
_delay_ms(5);
PWM_LVL = modes[mode_idx];
_delay_ms(65);
}
_delay_ms(720); How do you adjust how many pulses are in the group? Am I right in understanding that it's a 5ms pulse, 65ms wait, 5ms pulse then 720ms delay before repeating? How do you set the ratio - is that mode_idx-SOLID MODES+2? I'm presuming that you select a mode, then the pulse is that mode + 2 mode levels up? So moon flashing = moon on/ med flash? So I can control the ratio between on and flashing by either specifying how many mode levels up the flash is or what the jumps between the mode levels in the code are? What would I need to do to insert this code into JonnyC's Star momentary? (ie. are there any dependencies I need to worry about).
Sorry for all the Qs, I'm right at the beginning of my understanding and some of these Qs will no doubt look painfully embarrassing in a few weeks/ months :) Thanks!
It pulses four times and then rests…
- High 5ms
- Low 65ms
- High 5ms
- Low 65ms
- High 5ms
- Low 65ms
- High 5ms
- Low 65ms
- Low 720ms
So, the total there is 1000ms, with an average power draw of (( low * 0.98) + (high * 0.02)). If low was 100mA and high was 500mA, this would give an average of 108mA… so just 8mA extra in order to dramatically increase visibility.
By default, it flashes between the specified level and two levels higher. I find that this provides a nice ratio, usually. However, the timings and ratios should be pretty easy to modify just by changing some values in that part of the code.
That is a lot less trivial. It’ll involve making up brand new logical structures to facilitate blinky modes, which STAR normally doesn’t have. I’m not sure off-hand what the best method would be; it probably depends on the other details of the interface you want.
So, what kind of interface and modes do you have in mind?