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

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.

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

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?

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:

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.

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

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.

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.

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.

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.

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.

toykeeper I changed the pinout

5 3000k
6 5000k

As Lexel noted, making it work properly would require more pins than we have. It also would require redesigning the MCPCB. Maybe some other things too.

More pins means changing the type of MCU, which means rewriting pretty much all the low-level code. That will probably have to happen eventually, but I’m not sure now is the right time. At minimum, it would be a significant delay for this project.

Thanks! That makes things easier. :slight_smile:

I have a different question about the layout though. There are several ground vias directly under the BAT+ ring. They’re masked, but I wonder if there might still be any risk of shorting ground to BAT+ through those vias. I’m not sure how much the mask protects against that. Is that likely to be a problem?

I was talking about the first 3rd of the battery. In the case of barely getting to 70% that was a case where the lantern was running at like 1/4rd power also.

I would suggest two strings of 4 LEDs. One for each color temp. That way the current is the same in each LED and binning variances can’t lead to one pulling more current than the others. A 2S2P battery configuration would be better than 1S4P, but that complicates the battery situation by using unprotected batteries in series which is ill advised.

Why does everyone want to toss an additional 20-30% of the battery life at lower brightness levels (not that much on high)? The reasons you cite for efficiency not being a big concern actually are reasons why the efficiency is even worse in this lantern than lights pulling more current with fewer batteries. The low LED current means lower forward voltages. This means more power is burned off in the driver. The four batteries in parallel mean the per cell current draw is quite low meaning the cell voltage sags less and stays at a high voltage longer meaning more power is burned up in the driver.

Boost drivers aren’t hard. I don’t understand why everyone is scared of them or doesn’t want to use them.

Simple solution: You (Stereodude) design a boost driver board which includes a USB charging interface and fits into the Q8 size host. Also, it must use ATtiny85 or else you must port TK’s firmware to whichever MCU you decide to use. The driver design must not be too complicated nor the parts list too expensive for our Chinese manufacturer to make it reliably and at a reasonable price. Because time is of the essence, we will continue using Lexel’s design until you present yours to the team. Then we will discuss whether yours is good enough to merit making it the new standard. DEAL? :innocent:

I want a boost driver, but I’d rather get a lantern this year than 2020, so I’m happy with the PWM driver or the FET driver. I’m ordering 3, so if I can design a boost driver that fits, I will at most break one. :slight_smile: I’m sure that if a boost driver does get made, it will be open source, and anyone will be free to make one. Also, what you can afford in qty 5 is not what is affordable to a Chinese mfg. at qty 1000+ when they start counting pennies. I can afford 5 $5 FETs to use on my board for a 10% gain, they can’t.

I’ve spoken out in favour of the linear FET driver because it doesn’t have PWM and gets a few more lumens per watt, but I’m fine with the 7135 version if that has more plus points overall. I still don’t feel the need for a boost driver.

I do have a question about the FET driver tint shift, though. Would the tint ramping capability let people manually correct for the tint shift at a given brightness? Or would the shift be in a different direction to the ramp within the colour space?

Tint is not CCT (color temperature). Tint is a deviation form perfect white light (which can be warm, cool or in between, always on the line of the black body radiator). Tint is when the light has a green tinge or is red-tinted for example.

The lantern will be able to change its CCT, not the tint.