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

As I said simple copper tube around central bolt could be used as heat pipe.

Of course we can wait tests and think about this after.

Is the one pad not to near on the shelf for the driver?
Die Q8 hat eine geschwungene Ausformung, ca. wie die blaue Linie

We do if we have to pay for it. This is Budget Light Forum :wink: Granted, I don’t know much about PCB manufacturing but that drilling certainly looks like it will add something to fabrication time. And I’m pretty sure time is money, even in China. But given how they work, if it’s a problem, they’ll just quietly remove them lol Something to watch out for.

Anyway, if it’s needed to handle the thermal load on the FETs then it’s needed. Never had any problems running FETs in linear mode myself but better safe than sorry.

You pay for area and extra services,
For example ten 10x10cm tray with 4 separate boards
4.99$ Even with 1000 drill holes

The extra services get pricey
Gold plating chemical ENIG 12$
Hatd gold 100$
Purple color 22$
4 layer 40$
0.2mm min. drill size 30$
0.1mm solder stop mask 50$
Blind/buried viases 200$
And so on

When procuring PCBs in commercial quantities the traces come for free, as long as they are within design rules.

The most costly thing about them is the number and different sizes of the drilled holes, each of which has to be done individually by the CNC machine, the maximum stack of boards, the pannelisation etc. all affect this.

This is the dominating factor when getting quotations for production (no, not small quantities of prototypes, where the setup costs dominate and details like number and different sizes of holes are less relevant and usually just ignored).

The smaller the diameter of the holes, the more costly. Those carbide drills don’t sharpen themselves

Specify thousands of 0.3mm vias, and prepare to be laughed at by production engineers.

Specify more different size holes than the machine has toolholders for, and again, prepare to be mocked.

I say again, each of these holes has to be drilled individually, one at a time, using an expensive carbide drill which might not even last one pass of a stacked panel, and if it breaks badly can potentially write-off the entire job.

And the way you have placed them, you might as well write “tear along the dotted line” on the silkscreen.

It seems to me that there has been a bit too much negativity in this thread, so I wanna say that I think this project looks incredible, and thank you to all those involved in making it a reality. Your work is very appreciated.

And it’s been said before, but to those dissatisfied with the current direction, we all look forward to seeing your alternative design.



Will the battery shelf measurements big enough for protected cells up to length 69.5 mm / diameter: 18.9 mm ?

What about RGB LED for the Switch to display the current battery voltage level?
Or even an separate small two number LCD to show either percent or voltage?

My suggestions for covering the USB-Port against dust and splash/crumbs:
Either an slide port cover like this kind:

Or an removable which could be fixed with an small cord:

This is looking great guys. Let me put in one more vote for USB-C PD, if it’s financially viable, it would be super awesome and make this a very modern design. Plus my phone and laptop all use USB-C so it would be mighty useful for me. But if not, that’s ok.

Thanks for all the hard work, I’m so excited!

That’s not what I see from the PCB layouts posted.

Just one linear FET driver, not two, no separate connections for balancing two different colour temperature LED banks, and the layout is seriously messed up around the FET on the posted layouts (will never work). I’ve tried to reverse engineer it but the layout makes no sense, it’s all over the place and shorts itself out at several points around the FET.

Agreed, it does look like a rip-off of led4power’s design. But it makes no provision for the lowest modes, firefly, moonlight etc. which led4power does by simply driving them directly from a separate MCU pin through a high value series resistor, PWMed as necessary.

To try to do that all using just a big FET in linear mode with a (very basic, none-differential) Op-Amp for feedback is difficult enough to cover just say 8 bits=255 levels for ramping = 7 useful discrete levels.

If intending to PWM the thing for lowest modes, then e.g. the Op-Amp had better be tuned carefully with the FET and LED characteristics to have a hope of working predictably. Op-Amp selection will be critical. The characteristics of the FET and the LEDs may dominate anything beyond obtrusive visual PWM.

As will the selection for minimal standby power in e.g. E-switch applications. Micropower/minimal offset voltage/high differential gain/gain-bandwidth product, temperature stability etc. etc.

Presumably this has all been bread-boarded successfully so I needn’t worry.

I know we argue with each other a lot, but I have a lot of these same concerns.

If I understand correctly, this design has not been built or tested. It’s still pretty theoretical, so we don’t really know how well it would work. The general concept performed well in the BLF GT — a constant current circuit regulating power from 10% to 100, and below that it used PWM at 10 to make lower levels work. But I don’t think BLF has done that with a linear FET opamp before.

The first linear FET design, using attiny85, had issues with too few pins. It sacrificed control of the button LEDs, and it put the enable function for three different circuits on one pin. This basically makes the “PWM for low modes” useless at in-between tints like 3500K and 4500K, but, assuming it doesn’t break the USB circuit, it should still work at exactly 3000K, exactly 5000K, and exactly 4000K (ish). It makes some parts of the color space inaccessible. And it means the main LEDs would have to be at 10% power or higher, depending on tint choice, in order to function as a power bank.

So there’s a newer design, using attiny84. More pins should fix those two issues. However, it isn’t a supported MCU platform yet, so it adds a significant delay while I write a hardware abstraction layer and port firmware to the new MCU. And then there’s still the unknown factor of how well the linear FET opamp would work.

This project is already over 2.5 years old, and I’d like to get it to production soon. So I’m personally leaning toward using the 7135-based driver. It’s simple, its behavior is well-understood, it meets or exceeds the project’s goals, and it already “just works” today.

The dual linear-FET design with a bigger MCU is very interesting, and may forge a new path forward for BLF drivers… but I’d prefer to work on that as its own R&D project instead of adding risks and delays to this project.

Well, perhaps we could use a buck driver since it already works, but would that work well with tint ramping?

Since the forward voltage of a 4P array at 2A is extremely low(2,78V), using a buck driver with a dropout voltage of 0,3V would basically mean stable brightness over the course of the entire runtime down to 3,08V.

Agreed. Make it a triple bank 7135 design, 1, 2 or 4 as Mike C does. Modulate the 1 driver to vary power, switch in the extra 2 or 4 as desired, to a maximum of 7 (more than enough.)

That gives us modulated 1 driver from firefly to moonlight and useful.

Then 2, 3, 4, 5, 6 and 7 times the current. A bit linear I agree, but somewhere in there there will be a useful setting for someone. You could even make it ramp. logarithmically.

Superbly efficient, just works.

Charge it up with a simple TP 4056. USB connector type, well I have my opinion but I don’t really care if it goes the wrong way.

Powerbank output ? I don’t particularly care. But easily done, hells bells I can buy one at Poundland that works nicely, including a quite decent 18650, maybe I’ll take it apart and try to identify the chip.

This could all be done yesterday and would definitely work.

The BLF GT has a buck driver, designed for the GT. But we don’t have a buck driver for the lantern, and don’t have the other required parts either, like a battery carrier or a MCPCB. So, even in the best case, it adds more development time… and it also would require a bigger MCU to make it work, same as the dual-linear-FET design, so it adds both hardware and firmware development time.

It’s a good thing to do sometime, to make more advanced lights… but it’ll take a while and I think it would be more appropriate later, like for the LT2 instead of the LT1.

I am not following this thread but did notice the talk about the Constant current FET driver.

For reference the Texas Commander uses this design and is open source (it was designed without directly working off LED4powers design but ended up pretty similar as he did a really good job). It took a fair amount of work and tweaking to get it working but the prototype drivers worked quite well, as long as the total power dissipation was kept under ~2-3W (on a 17mm driver, a 46mm driver could get away with a bit more and either should be plenty for this light).

Might be something to look into if there is trouble with the design. The thread is around here someplace. I never really messed with it after the prototype since it did not have all that many practical uses at the time and LED4powers driver was basically the same thing.

For this light it should work fine though, although I think people are too hard on the PWM 7135’s. They are simple, they work and 99% of people would not be able to tell the difference.

I will say to pay very careful attention to all the low voltage parts, paths and grounds, particularly around the FET and other high current areas. They played havoc on the Texas Commander signal stability at first. This was where I first learned about proper grounding and signal routing.

As i said before its impossible to please everyone, there will always be a couple who wants things “their way” or no way. I just ignore them.
So far we have well over 1000 interests on the list here & climbing, and i have another100 interests from locals, friends family, etc. I remember there was a few who cried & whined during the Q8 & GT projects because they didn’t get their way. We have taken any suggestions and ideas seriously and implemented many along with experience tests & trials. The pointless & impractical ones we ignored.

I agree with Toykeeper 1000% , As we know, everyone can talk about changes, ideas, etc forever. We are close now to getting a prototype for the manufacturer to build & test then get into production. After the nearly 2 year long chat & idea designing on this project, its time now to stick who what we have achieved & planned and go forward to make it a reality.

Indeed. Having read the Q8 thread from the start, I can predict there will be more “but it should be done this way” comments as it gets closer to shipping. And some even once it has shipped. I’m fairly certain you’ve put more time into this than anyone else and probably have better understanding than most of the actual needs through all the testing you did.

AMC version has pretty much only 2 channels with 8 bit, so moonlight will be not possible
or even color mixing at low levels will be very bad in few steps
To get the used 6*AMC +1 for better resulution we would need 4 MCU pins so this would be delaying as well

While the FET PWMed CC uses 3 channels and should get per color about 10-11 bit resulution

The powerbank boost pin that was in original design on the MCU can be separated, so it wont be affected by the CC PWM of the FETs

We could have an early prototype driver already if there would be a budget for it

TOM TOM get a board with just 2 copper planes and one with a few hundred viases for thermal conduction and try to solder a wire on both and you will see that one is literally sucking your irons heat away make it hard to solder,
It is common on bosrds, just look at Astrolux MF01/02 or other drivers like Acebeam/Thrunite you see thermal viases on many of them, the more copper the better it conducts heat, even if some PCB material gets drilled away

Chineese fabs have production costs you can see on Elecrow or similar websites you can make 1000 47.5mm drivers without extra drill costs for 335$ It does not matter if you make 250 10x10cm or 40 25x25cm boards just the board area counts for production costs

I do not see on my designs any short circuits you say they are there or non functional circuits if you are not able to get the function of a OPAmp variable resistor MOSFET circuit reverse engeneered thats your problem, the board has no design faults like you declare they are there

Moon mode works just fine on 4x7135. It’s slightly higher than with 1x7135, but that only means a difference of, um, … *<i>does a quick measurement</i>* … 0.35 lm instead of 0.20 lm. Either one should be fine for a lantern. With a 360-degree beam, it’ll probably look dimmer than a regular moon mode anyway.

Color mixing at low levels has coarse resolution though, because it’s based on integer math. For example, if it’s running at brightness level 240/255, there will be 241 possible tints. But at 10/255, there are only 11 possible tints. The firmware deals with this by remembering what tint the user wanted, and picking the closest one available at the current brightness. At low levels, the user can see distinct steps while changing color, but at higher levels it should be too smooth to see any steps. Fortunately, only low levels are affected and human color perception is pretty bad in low light, so it shouldn’t look weird in practice.

Here’s how that looks. First, this represents the BLF lantern’s color space in its actual 8-bit resolution — 256 brightness levels tall and 256 tints wide, with the image sizes doubled to make it easier to see. Red is for the 3000K emitters, blue is for 5000K. So, it gets warmer toward the left, cooler toward the right, and brightness goes up and down. This is the actual resolution of the simple AMC7135 chip design, so I hope it is clear that there are a wide range of choices available. The user can set the lantern to run at any point within this space:

If we zoom into the bottom (cut off the top 224 levels, stretch it vertically, and increase the brightness to make things easier to see), here is how the bottom 32 levels look. See how there are visible patterns? That’s where the coarseness starts to be perceptible.

… and if I cut off the top half and increase brightness again, it becomes even easier to see how the lowest 16 levels look.

This is what I mean by saying the tint resolution gets coarse at the bottom of the ramp.

A 3+1 / 3+1 driver (or 4+1 / 4+1 or 5+1 / 5+1) could increase resolution at the low end by splitting each individual region into slightly smaller pieces, like it does on the “moonlight special”, but nobody really proposed that because the tiny85 doesn’t have enough pins or enough PWM channels.

Same thing with a 4-pin dual-linear-FET design, where each channel has its own current control and its own independent PWM. The resolution at the bottom should be a bit finer, but it needs more pins and it’s a little harder to quantify than a 2-channel design. The bottom technically still ends up with exactly the same horizontal coarseness as before, but the vertical steps should be closer together. Basically, instead of 350mA on one channel and 1400mA on another, it does ~12.5% to 100% via constant current and anything below 12.5% via PWM. So, the brighter of these two methods handles brightness levels 32 to 255. And the lowest 32 levels use 8-bit PWM at 12.5%, so there are 255 steps going from 0 to 32 in increments of 0.125. It effectively sub-divides the bottom steps. I hope that makes sense.

With a 3-pin dual-linear-FET design (shared PWM pin), things get complicated and entire sections of the color space disappear. Like, if the user sets the tint to 3100K, that’s 95% warm and 5% cool, but that combination isn’t possible because 5% is less than the stable constant current floor. More generally, since it can’t PWM one tint without PWMing the other, it doesn’t work at tints where the two channels need different duty cycles. So it could do 3000K and 3222K, but nothing between… even at high brightness where the resolution should be pretty fine. And the gaps get bigger as the brightness goes down. So I’m hoping to avoid that.

I’d like to stick with a proven 2-pin design for now, instead of letting feature creep drag this project out even longer. The 4-pin design is awesome, but perhaps would be better used in next year’s model.