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

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.

To go further off-topic, how about the ATTiny 1616 ?
I did some comparisons while looking around for my own driver.

Also, having a 2nd quasi-standard MCU for more demanding drivers next to the ATTiny85 would be something nice to have.

Biggest drawback possibly is that it is only supported in the newest 8.1 gcc release, many needed code-changes and that you need a different programmer.

Primary advantages:

  • Many more PWM pins (for example, Timer0 has 4 compare registers in 16-bit mode and 8 in 8-bit mode)
  • DAC support
  • Single-Wire programming (UPDI Port)
  • Small 3x3x0.9 20-pin VQFN package

+1

Also re: MCU pins, don’t forget that we can use a dirt cheap shift register to control the 7135s that are not being PWM’d. So 3 MCU pins for discrete steps, and PWM on 1 7135 for each color channel. It would require integration into the firmware, although coding for such a thing isn’t the most burdensome, but I’ll let TK speak for any difficulties that might be specific to the FSM firmware.

logic example in pseudo code:

totalRamp = 255
numChips = 8
stepsPerChip = totalRamp / numChips

chipsToShiftOn = currentLevel / stepsPerChip
remainder = currentLevel % stepsPerChip
pwmLevel = mapRemainderToByte(remainder)

shiftRegOutput(color, chipsToShiftOn)
pwmOutput(color, pwmLevel)

I agree with using what we have currently developed to get this light into production, and can imagine a V2 ~6-9 months behind would be a reasonable thing for those not able/willing to mod the V1.

For a V2, a buck driver really does make sense to me in this specific application. How it stacks up in real world efficiency is another question though. The 7135s are going to be shedding a lot of voltage the entire runtime. Only positive thing there is that it’ll be fully regulated, but that’s a lot of wasted energy that I’d love to try and eliminate.

This 1S buck driver development (again, not for a V1 lantern) would pay huge dividends to the rest of the community, who are once again forced back to 7135 drivers with the majority of ‘non-hotrod’ builds using the latest emitters. 2A would be okay, 3A good, and 4A great. I’ve been out of the loop for a while on the driver development side of things, so maybe something close to this already exists?

Cheers! And thanks to all for their past and continued efforts :beer:

Have you toured a PCB manufacturing plant and spoken to the production engineers about what makes their job most difficult ?

Usually daft designs, but they struggle on and make them anyway.

I have, many times, but mostly working on very exotic boards with upwards of 16 layers, blind and buried vias, polyimide dielectrics, Invar constraining layers, Z-axis expansion requiring innovative through-hole plating techniques (actually no through-holes), etc. Designed to last indefinitely, exoatmospheric. So I am a bit fussy.

Here are a couple of vids. showing how a basic 4 layer board is constructed:

Take a look at the German way: https://www.youtube.com/watch?v=T7S40GYESbY

Then contrast with the Chinese way, quite possibly where your PCBs come from (they make multi-project panels).: https://www.youtube.com/watch?v=ljOoGyCso8s

Cringe worthy Mansplaining on this one.

But in both cases, note that the drilling operation is the key mechanical process, each hole drilled individually, with a physical drill. Everything else is just lamination, photo plot exposure, developing, etching, plating, QC etc. which costs the same for any design. It is drilling the holes that costs money (drill wear and machine time, let them get blunt and no amount of plasma de-smear will fix it before applying black-hole/shadow process to get the electroplating started.)

On the Chinese video, drilling is at 13”22’

On the German one, 3”30’

In both cases, rather glossed over. Because it is a key technology for commercial competitiveness, if you can work out how to do it better/faster/cheaper that gives you an edge.

If you get into commercial production quantities, you will learn this.

Just imagine the capital equipment costs of setting up a modern PCB Fab, the staffing and training costs (they have to be really good, not easy to find, most youngsters don’t have the discipline), then there are the environmental controls, all those chemicals, heavy metals, etc.

You can’t just pour e.g. copper sulphate down the drain anymore. it would also be a waste, if you might need it to plate-up things then you can, but you will need a chem-lab to control the process (you need one anyway, one skilled educated person can do that, but OMG it would be a boring job.)

Bye the way, these rapid prototyping services are stupidly cheap. They are giving away the boards for barely the price of postage and packaging, it’s really altruism, hoping to encourage young engineers, and/or get the production contract. If they had been available when I was learning I might have taken a different direction.

If you will PM me an e-mail address, I’ll send you some jpegs showing my observations. It may just be that your software has rendered the design files incorrectly, happens all the time in PCB layout.

At the risk of being boring, here is the video that I should have posted first. Newbury Electronics, some of the nicest people, who really know their stuff, I’ve used them a lot, as I suspect have many UK people.

You’ll learn more from this one I think.

Eventually, yes. But not until the toolchain is more commonplace. For example, debian/stable uses gcc-avr 4.9.2 and debian/unstable is only updated to 5.4.0. So I’m sticking to architectures which are supported in those.

I’ve noticed people drawing a distinction between the words “lamp” and “lantern”, but I’m not clear on what the difference actually is. Can someone define it for me, please?

That spec looks perfect for my purposes :slight_smile:

Personally, I’d rather see two ports. That way, the plug / unplug mechanical wear will be spread out. Charging input via Micro USB or USB-C, powerbank output via full-size USB-A or USB-C.

I’m also not convinced by the idea of USB Power Delivery, because I don’t know how a Power Delivery port works with old-style USB devices. How would the single Power Delivery port figure out whether to take a charge from an old USB wall wart or send power to an old USB-chargeable phone?

I agree with this. The way to maximise the reliability of electronic components is to stop well short of their maximum ratings.

Do you draw these images yourself, ToyKeeper? You always seem to have one to hand for every occasion! They’re really nicely done, I smile whenever I see a new one :slight_smile:

Of course not, silly.

I just strike a pose and levitate the camera for a quick selfie.