*BLF LT1 Lantern Project) (updated Nov,17,2020)

[ToyKeeper]

@Lexel

pinout

PB0 enable of Boost USB and the opamps

PB1 3000k

PB2 voltage divider 220/47k for LVP

PB3 switch over 1k

PB4 5000K

Is there any chance of using PB0 and PB1 for 3000K and 5000K, and PB4 for USB/opamps? The chip likes having the two PWM channels on PB0 and PB1. I’m hoping for something like this:

                 ----
         Reset -|1  8|- VCC
 (PB3) eswitch -|2  7|- voltage divider (PB2)
   (PB4) opamp -|3  6|- 5000K (PB1)
           GND -|4  5|- 3000K (PB0)
                 ----

Otherwise, the second PWM counter gets involved, and it runs at a different speed, and things get a little weird.

Also, how slow can the PWM signal can be without causing problems? I usually underclock the MCU at low levels to make the bottom of the ramp more efficient, but I’m not sure that’ll work with a linear FET.

If I understand correctly, the 7135 version might be something like this?

                 ----
         Reset -|1  8|- VCC
 (PB3) eswitch -|2  7|- USB enable (PB2)
 (PB4) aux LED -|3  6|- 5000K (PB1)
           GND -|4  5|- 3000K (PB0)
                 ----

[Captain_Joe]

I´m in for one!

[Madtoffel]

Thanks for the clarification ToyKeeper :+1:
I actually thougt that we need one of the 7135s to drive the button led :person_facepalming: , I really shouldn’t read this while doing something else…

[Stereodude]

@Agro

I see over 4V for about 600 mAh which is 18% of capacity, not 1/3.
Voltage decreases pretty much linearly to 90% capacity, from 4.15 to 3.4V. Then it falls off the cliff.
Over that 90% capacity, with Vf of 2.82 linear driver is about 75% efficient. Over the last 10% it’s about 91% efficient.
Overall efficiency is more like 78%.
A 95% efficient driver would increase runtime by about 22% in the lowest modes, less in the higher ones.

I didn’t say over. I said average. The midpoint of the voltage of the first ~1200mAh at a low discharge current (which it will be because there are 4 in parallel) is ~4.0V. My numbers were right for the scenario I outlined.

[Stereodude]

@ToyKeeper

Well actually…

* GD&R *

Tint changes with current, and is usually best (whitest) when the current is in the medium-high range of an emitter’s power capacity. Tint is generally worst at very low power levels, or when the emitter is heavily overdriven, but fine anywhere in-between.

Here’s a video of a single emitter changing color due to different power levels being used. The light on the right is alternating between 350mA constant current and 350mA via a pulsed FET. The light on the left is only there for reference. http://toykeeper.net/torches/blf-a6/tintshift.avi (sorry for the bad video, I should re-do this demo sometime)

For the lantern, the risk is using too little power, causing unnecessary tint shift because the emitters aren’t running hot enough to get to their ideal range. If it’s only 1.4A total, split across 4 to 8 emitters, that’s 175 to 350 mA per emitter at the highest brightness. This is low enough to get some tint shift, but not a lot. However, a constant current driver will get worse tint shift as the total power goes down, while a PWM driver keeps a constant tint.

But between a linear FET or a buck/boost driver, tint shouldn’t be any different. They both shift the same way at low levels. The only style which doesn’t is PWM.

At least the effect doesn’t seem particularly bad on the LH351D. I notice it a lot more with XP-G2.

A constant current boost driver can be PWM’d. Some of them can also change the LED drive current without using PWM. As I stated, the use of a boost driver doesn’t cause any tint shift issues that weren’t there before.

[Agro]

@Stereodude

@Agro

I see over 4V for about 600 mAh which is 18% of capacity, not 1/3.
Voltage decreases pretty much linearly to 90% capacity, from 4.15 to 3.4V. Then it falls off the cliff.
Over that 90% capacity, with Vf of 2.82 linear driver is about 75% efficient. Over the last 10% it’s about 91% efficient.
Overall efficiency is more like 78%.
A 95% efficient driver would increase runtime by about 22% in the lowest modes, less in the higher ones.

I didn’t say over. I said average. The midpoint of the voltage of the first ~1200mAh at a low discharge current (which it will be because there are 4 in parallel) is ~4.0V.

I stand corrected

@Stereodude

My numbers were right for the scenario I outlined.

I thought you meant to say that with GA and Vf of 2.82, average efficiency of linear driver would barely scrap 70% over entire discharge.
Now I think you meant over the first 1/3 of discharge.
Is that correct? If no, could you clarify how did you come up with the number? It’s quite different from mine.

[ToyKeeper]

@Stereodude

A constant current boost driver can be PWM’d. Some of them can also change the LED drive current without using PWM. As I stated, the use of a boost driver doesn’t cause any tint shift issues that weren’t there before.

Fair enough. The BLF GT uses both methods — current control for 10% to 100% power, and PWM below 10%. But it needs two pins to control one power channel… one for current and one for on/off. That’s what the lantern was going to do while using DEL’s design, before the tint ramping was added.

I’m guessing that a boost design for the lantern would keep the cells in a 4P configuration, but the emitters would be two channels each configured as 2S2P? That should keep the voltages far enough apart for a boost to work. And then instead of burning off excess voltage, the driver’s heat would instead come from voltage conversion.

[sbslider]

great discussion over the past few pages, I learned a bunch.

[fixed_it]

@ToyKeeper

With a linear FET design, a PWM signal goes from the attiny to a circuit which averages it into a smooth analog voltage. At 4.2V and 50% PWM duty cycle, the output signal is a steady 2.1V. This tells the FET how much power to allow through. But the same 50% duty cycle on a low battery at 3.0V only averages out to 1.5V. So the brightness changes with voltage.

To avoid the problem of brightness changing with voltage, the attiny needs to receive a constant input voltage. Let’s say that’s always 5.0V exactly, using some magic on the VCC input pin. Then a 50% duty cycle always averages out to 2.5V, and the brightness stays the same regardless of whether the batteries are full or almost empty.

You should try compensating in software instead. You could recover a pin and the drain of the voltage divider. And you no longer need the magic circuitry for VCC either.

[Lexel]

wrong a boost driver needs also Vcc 2.8V and voltage divider for the MCU

reason is it needs an analog control voltage to set the output current

to use all solutions with CC+PWM on both channels would simply need an MCU with 7 or more free pins

[twodollarbill]

@ToyKeeper

Some thoughts on this…

Advantages to PWM / AMC7135 chips:

• Better tint. LEDs get less white at low power, and these are expected to run at fairly low current. PWM runs at a consistent power level and produces a consistent tint regardless of how many lumens are coming out, but a constant current driver has more visible tint shift when not running at full power.
• Can keep the button LED. PWM doesn’t require as many MCU pins, so we could still have a lighted button with multiple modes. The linear FET option may also have higher parasitic drain in standby mode, due to needing a voltage divider to measure battery status. This effect could be very small though, if done right.
• Manages heat better. The 7135 chips spread heat across a wider area and have thermal regulation built in, so they don’t overheat. However, a linear FET concentrates heat into a smaller space on the driver, which means the driver itself may need heat sinking.
• Better low modes, usually. The “raptor claw” 7135 chips have good performance in low modes, so the bottom of the ramp should be pretty low and pretty stable. However, a linear FET tends to have difficulty in really low modes, so the bottom of the ramp might not be very low or very stable.
• Simpler driver design, easy and pretty much risk-free.

Advantages of a linear FET:

• Higher efficiency in most modes. More lumens or more runtime. At the lantern’s power level though, this effect may be small, like only a 5% or 10% difference.
• The parts might cost less.
• Can potentially be modded for higher current by changing a sense resistor, but this also increases the risk of driver damage due to heat.

I’ll get things working on whichever one is used, but personally I lean a bit toward the simpler option even if it’s a bit less efficient.

I trust ToyKeeper’s opinion on stuff like this and based on her list alone, it looks like the AMC driver has more pros than the FET driver.
However, it seems like the majority of votes so far have been for the FET driver. I’m not knowledgeable enough to understand why.

Can anyone explain their reasoning for wanting the FET over the AMC?

[sbslider]

I voted before seeing all the details. I still wonder how/if we can be assured of getting the “raptor claw” AMC chips. I am only think I know what I have read on here, and my impression is that one can not guarantee getting these parts in general. But that may be if one is buying in small quantity from Chinese stores. Lexel thought the FET was a better choice, and he has lots of experience designing drivers, so there is something to be said for that as well.

Two established, experienced people, two different points of view. :question:

[DBSAR]

@ToyKeeper

@sbslider

@DBSAR

if we can get the tint ramping feature integrated.

There is no doubt in my mind that Toykeeper is fully capable of this. The hardware is easy (and done), the firmware is not much different than what already exists in Anduril.

I already have most of the code written. I just haven’t been able to actually try it since the hardware doesn’t exist yet.

The light operates the same as any other Anduril light, but with one key difference: While the light is on, in almost any mode, the user can “click, click, hold” to make it change tint. This happens smoothly without significantly affecting total lumen output. If the color changes in the wrong direction, let go of the button and do it again.

Good work Toykeeper. Lexel mentioned he can make a prototype or two at a cost, or it may be possible Barry can get one or two built to send to you for testing.

[LichtAn]

The boost driver is just out of question because of higher costs? What costs are we talking here? 5$? 50$?

[DBSAR]

@Lexel

lets go with the FET, most people dont care about 10% average efficiency gain for a more compley and costly boost driver

pinout
PB0 enable of Boost USB and the opamps
PB1 3000k
PB2 voltage divider 220/47k for LVP
PB3 switch over 1k
PB4 5000K

Agree on that to go with the the standard FET (or AMC) over a Boost driver for this application, as with four high capacity cells and the lower amp loads the efficiency wont be that big of a concern.

[Pezo]

@Lexel

lets go with the FET, most people dont care about 10% average efficiency gain for a more compley and costly boost driver

pinout
PB0 enable of Boost USB and the opamps
PB1 3000k
PB2 voltage divider 220/47k for LVP
PB3 switch over 1k
PB4 5000K

You don’t actually need an extra pin for measuring VCC, have a look at AN2447
This way we could still have the button lighted from the MCU.

Regarding the app note, you don’t even need to use division (which is a lot of code) if all you care about are a couple of thresholds and not the actual VCC value.

[fixed_it]

@Pezo

You don’t actually need an extra pin for measuring VCC, have a look at AN2447
This way we could still have the button lighted from the MCU.

TK knows about that trick. It can’t be used if Vcc is regulated.

[Pezo]

@fixed it

TK knows about that trick. It can’t be used if Vcc is regulated.

Ah yes I hadn’t considered that. However, you don’t need to regulate VCC, you only need to regulate the high voltage of the PWM outputs used for the DAC… I’ll have to think about that.

[ToyKeeper]

@fixed it

@Pezo

You don’t actually need an extra pin for measuring VCC, have a look at AN2447
This way we could still have the button lighted from the MCU.

TK knows about that trick. It can’t be used if Vcc is regulated.

That’s how the code currently works by default. The pin7 voltage divider trick is supported too, but it requires a different config when compiling.

[ToyKeeper]

@fixed it

You should try compensating in software instead. You could recover a pin and the drain of the voltage divider. And you no longer need the magic circuitry for VCC either.

No. I’ve tried. It doesn’t work well at all.

CV-based circuits need a good solid voltage source, and an attiny is not a good voltage regulator.