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

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.

Sort of both. Higher modes tend to be cooler and whiter, while lower modes tend to be warmer and greener. The tint ramping can change the warm/cool balance, but it can’t change the white/colorful balance.

On this diagram, lower current levels tend to make the tint go to the right (warmer) and away from center (farther from the dotted line). Higher current generally makes tint go left (cooler) and toward the dotted line. The tint ramping can adjust things on a left/right axis but not an up/down axis.

For example of how current changes tint, maukka measured the Olight S1 Mini’s tint in different modes. At lower modes, it gets warmer and greener:

To minimize any warm/green shift, the lantern could use PWM at full power to keep the tint as close to white as possible. The lantern could also potentially use 3 emitters per channel instead of 4, to increase the current going to each emitter.

For an example, let’s say the lantern can make 600 lumens and it’s running at 33% brightness on a visually-linear scale. That works out to about 33 lumens total, at ramp level 50 of 150. With a 4000K tint it uses all 8 emitters, at about 4 lm each.

  • A constant current driver then delivers only about 10 mA to each emitter. On the Olight chart above, this would be somewhere between “moon” and “low”.
  • A PWM driver instead delivers 350mA to each emitter, producing about 150 lm per emitter, but only for a short time. Visual brightness looks the same, but the tint coordinate would be somewhere between “mid” and “high” on the chart above.

However, the chart shown is for a different emitter, and I don’t have data on the tint shift effect on LH351D. It may behave differently. Most LEDs follow the same general pattern though, where the lowest levels are the least white. When we increase efficiency by using those low levels, we also reduce the quality of light coming out.

So the question is whether to prioritize tint or efficiency.

Since the lantern is using high-CRI emitters, I’ve been assuming that tint is the priority, so an AMC7135-based driver would probably make the most sense for that purpose. But if efficiency is more of a concern, it could definitely use a linear FET driver with medium-CRI emitters. It’ll make significantly more lumens per Watt, delivering higher output and longer runtimes.

Thats why were hoping the manufacturer can source the LED tint bins from Samsung listed earlier to keep the tint either close, on or below the BBL.

I had originally planned for the lantern to use 3 emitters per channel then went to four per channel. If three emitter will work better i can re-design the LED star for a 3 + 3 LED config, but like you said above, there is not much data & tests on how the 351D reacts to higher currents as its such a new LED.

As long as you change the name of the lantern from the “Ultimate” to “We couldn’t be bothered to do it right.”

Hey, you’re the one who said boost drivers are ‘right’ AND you’re the one who said boost drivers are ‘easy’. Why would we need a name change if doing it right is easy for you?

Since the lantern is based on the Q8, I am assuming that it can only accept button top batteries right? Or will this lantern be designed with a battery carrier?

Thank you to The_Driver and ToyKeeper :+1:

I understand the tint shift issue now. I’m unlikely to have a problem with tint shift unless it’s truly dire - CCT and CRI are the things I notice - but I agree that we should have the best quality light for everyone, especially since this is going to be a high CRI lantern (the feature that sold it to me).

If the 7135 driver with high frequency PWM is the favourite among the rest of you to achieve that, then it’s fine by me. High CRI and ramping from 3000K to 5000K are my must-haves; I’m not going to lose any sleep over the odd bit of efficiency here or there.

Because any help I was inclined to give vanished. I will roll my own driver for my lantern keep it to myself.