*BLF LT1 Lantern Project* (first code for all 3000 GB list sent)

9899 posts / 0 new
Last post
joechina
Offline
Last seen: 1 day 10 hours ago
Joined: 03/05/2016 - 08:23
Posts: 1435
Location: Germany

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

fixed it
Offline
Last seen: 3 days 20 hours ago
Joined: 12/08/2015 - 14:27
Posts: 396
Location: Canada

Lexel wrote:
Who cares if the fab has increased drill work
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.

Lexel
Lexel's picture
Offline
Last seen: 11 hours 24 min ago
Joined: 11/01/2016 - 08:00
Posts: 5527
Location: Germany

fixed it wrote:
Lexel wrote:
Who cares if the fab has increased drill work
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 10×10cm 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

Tom Tom
Offline
Last seen: 8 months 1 week ago
Joined: 09/10/2017 - 08:30
Posts: 1163

Lexel wrote:

Who cares if the fab has increased drill work
Even if it looks like swiss cheese those viases conduct heat much better than a simple copper plane on both sides, you see it a lot on boards with thermal load on it

I have let made MF03 board with this via density and it works, a test with MF02 with 0.3mm viases and less space between then did not fully cover with copper as it was more than 1000 per square inch, also 0.35mm viases work a lot better

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.

PocketSammich
Offline
Last seen: 8 hours 10 min ago
Joined: 04/01/2017 - 03:55
Posts: 24

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.

shirnask
shirnask's picture
Online
Last seen: 6 min 13 sec ago
Joined: 03/21/2016 - 23:58
Posts: 1071
Location: Louisiana

PocketSammich wrote:
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.

Thumbs Up
angerdan
angerdan's picture
Offline
Last seen: 17 hours 26 min ago
Joined: 11/01/2015 - 10:07
Posts: 433

DBSAR wrote:
Current design Specifications for the BLF LT1 Lantern will be close to these below:

-Specifications:
- uses up to four button-top 18650 LiIon cells (in parallel configuration) Driver based from Lexel, Firmware from Toykeeper (LT1-Anduril)
- Lighted electronic switch, (same as Q8 but with amber or yellow LED.
- USB charging, (either USB-micro, preferably newer USB-C input

– Up-coming available accessory kit will include:
> padded woven storage sleeve storage case.
> upper “wide-hat” plastic white hood brim/reflector for increasing light downward when hanging above outdoors.


AWESOME!

Will the battery shelf measurements big enough for protected cells up to length 69.5 mm / diameter: 18.9 mm ?
https://enerprof.de/shop/batteries/enerpower-battery-3-6v-3500mah-button...

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?
https://de.aliexpress.com/item/10000-Lumen-7R8-Lantern-Lamp-Torch-7x-Cre...LCD-Display-4×18650/32626441348.html

My suggestions for covering the USB-Port against dust and splash/crumbs:
Either an slide port cover like this kind:
https://www.delock.de/produkte/N_20652/merkmale.html

Or an removable which could be fixed with an small cord:
https://www.delock.de/produkte/S_64013/merkmale.html?setLanguage=en
https://www.delock.de/produkte/S_64015/merkmale.html?setLanguage=en

beastlykings
beastlykings's picture
Offline
Last seen: 2 days 8 hours ago
Joined: 12/29/2017 - 17:06
Posts: 193
Location: Michigan, USA

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!

Tom Tom
Offline
Last seen: 8 months 1 week ago
Joined: 09/10/2017 - 08:30
Posts: 1163
ToyKeeper wrote:
The FET-based driver uses a linear FET design to achieve constant regulated current. It is not direct-drive. Instead, it’s like two of led4power’s constant current drivers. They’re also based on a FET.

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.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 3 hours 18 min ago
Joined: 01/12/2013 - 14:40
Posts: 10090
Location: (469219) 2016 HO3

Tom Tom wrote:
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.

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.

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.

BlueSwordM
BlueSwordM's picture
Offline
Last seen: 2 hours 23 min ago
Joined: 11/29/2017 - 12:34
Posts: 5452
Location: Canada

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.

My very own high current Beryllium Copper springs Gen 3:
http://budgetlightforum.com/node/67401
Liitokala Aliexpress Stores Battery Fraud: http://budgetlightforum.com/node/60547

Tom Tom
Offline
Last seen: 8 months 1 week ago
Joined: 09/10/2017 - 08:30
Posts: 1163

ToyKeeper wrote:

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.

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.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 3 hours 18 min ago
Joined: 01/12/2013 - 14:40
Posts: 10090
Location: (469219) 2016 HO3
BlueSwordM wrote:
Well, perhaps we could use a buck driver since it already works…

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.

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 8 hours 12 min ago
Joined: 03/24/2016 - 07:44
Posts: 8566
Location: Everything is brighter in Texas

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.

DBSAR
DBSAR's picture
Offline
Last seen: 5 hours 38 sec ago
Joined: 02/11/2013 - 23:28
Posts: 6102
Location: Ontario, Canada

PocketSammich wrote:
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.

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.

That Canadian flashlight guy & Lantern Guru -Den / DBSARlight

DBSAR
DBSAR's picture
Offline
Last seen: 5 hours 38 sec ago
Joined: 02/11/2013 - 23:28
Posts: 6102
Location: Ontario, Canada

ToyKeeper wrote:
Tom Tom wrote:
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.

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.

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.

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.

That Canadian flashlight guy & Lantern Guru -Den / DBSARlight

fixed it
Offline
Last seen: 3 days 20 hours ago
Joined: 12/08/2015 - 14:27
Posts: 396
Location: Canada

DBSAR wrote:
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.
Lexel
Lexel's picture
Offline
Last seen: 11 hours 24 min ago
Joined: 11/01/2016 - 08:00
Posts: 5527
Location: Germany

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 10×10cm or 40 25×25cm boards just the board area counts for production costs
https://www.elecrow.com/pcb-manufacturing.html

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

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 3 hours 18 min ago
Joined: 01/12/2013 - 14:40
Posts: 10090
Location: (469219) 2016 HO3

Lexel wrote:
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

Moon mode works just fine on 4×7135. It’s slightly higher than with 1×7135, but that only means a difference of, um, … *does a quick measurement* … 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.

zeroflow
Offline
Last seen: 5 days 58 min ago
Joined: 05/23/2017 - 02:15
Posts: 189
Location: Austria
ToyKeeper wrote:
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.

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 3×3×0.9 20-pin VQFN package

lexvegas
Offline
Last seen: 1 week 4 days ago
Joined: 07/24/2018 - 14:20
Posts: 91
Location: USA

ToyKeeper wrote:

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.

+1

lexvegas
Offline
Last seen: 1 week 4 days ago
Joined: 07/24/2018 - 14:20
Posts: 91
Location: USA

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)

JaredM
JaredM's picture
Offline
Last seen: 2 hours 56 min ago
Joined: 10/31/2011 - 13:33
Posts: 611
Location: Pittsburgh, Pennsylvania

BlueSwordM wrote:
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.

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

Tom Tom
Offline
Last seen: 8 months 1 week ago
Joined: 09/10/2017 - 08:30
Posts: 1163
Lexel wrote:
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 10×10cm or 40 25×25cm boards just the board area counts for production costs https://www.elecrow.com/pcb-manufacturing.html

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.

Lexel wrote:
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 revers e engeneered thats your problem, the board has no design faults like you declare they are there

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.

Tom Tom
Offline
Last seen: 8 months 1 week ago
Joined: 09/10/2017 - 08:30
Posts: 1163

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.

https://www.youtube.com/watch?v=QWuUGm7m4qs

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 3 hours 18 min ago
Joined: 01/12/2013 - 14:40
Posts: 10090
Location: (469219) 2016 HO3
zeroflow wrote:
To go further off-topic, how about the ATTiny 1616 ? … 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.

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.

Phlogiston
Phlogiston's picture
Offline
Last seen: 53 min 13 sec ago
Joined: 10/27/2016 - 16:57
Posts: 888
Location: Scotland

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?

DBSAR wrote:
Current design Specifications for the BLF LT1 Lantern [here ]

That spec looks perfect for my purposes Smile

Agro wrote:
A single Type C port would be sufficient. With USB Power Delivery standard, that single port can be used as both input and output. For the long term, removal or Type A slot shouldn’t hurt anyone.

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?

Tom Tom wrote:
Don’t listen to the “max power, push the LEDs to the max. 30 seconds on turbo is great, let it burn” idiots. Balance in everything. This is not a torch, it’s a lantern, designed for the long-run. Don’t over-stress anything, keep it to manufacturers’ data sheet parameters, then it might be supremely reliable and out-last most of us.

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

ToyKeeper wrote:
lohtse wrote:
This is not the lantern you are looking for! (say is with a hint of jedi)


This is not the meme you’re looking for.



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 Smile

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 3 hours 18 min ago
Joined: 01/12/2013 - 14:40
Posts: 10090
Location: (469219) 2016 HO3
Phlogiston wrote:
ToyKeeper wrote:
lohtse wrote:
This is not the lantern you are looking for! (say is with a hint of jedi)


This is not the meme you’re looking for.



Do you draw these images yourself, ToyKeeper?


Of course not, silly.

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




nastynate
Offline
Last seen: 2 days 13 hours ago
Joined: 09/05/2018 - 23:42
Posts: 25
Location: United States

Just to comment more on the USB C train, another benefit is the increased durability of the USB C port of the previous standard of micro USB. USB C as a spec is built like a tank, as compared to micro USB where I have personally experienced a number of cables and even a few ports going out over time. Granted I personally have not had a USB C phone for as long as I had been using micro USB, but I do feel that usb C would help the long term durability of the flashlight. This of course is in conjunction with the other benefits of USB C, being that it will likely be the ubiquitous port for the next 10 years, is reversable, can exchange power easily both ways, and saves space compared to USB A. Plus a single USB C port is easier to protect against water than a micro USB/USB A combo. I really hope this light comes with USB C. I’ll still buy one if it doesn’t, but it’s just one of the main reasons I got excited for this lights development anyways.

DBSAR
DBSAR's picture
Offline
Last seen: 5 hours 38 sec ago
Joined: 02/11/2013 - 23:28
Posts: 6102
Location: Ontario, Canada
nastynate wrote:
Just to comment more on the USB C train, another benefit is the increased durability of the USB C port of the previous standard of micro USB. USB C as a spec is built like a tank, as compared to micro USB where I have personally experienced a number of cables and even a few ports going out over time. Granted I personally have not had a USB C phone for as long as I had been using micro USB, but I do feel that usb C would help the long term durability of the flashlight. This of course is in conjunction with the other benefits of USB C, being that it will likely be the ubiquitous port for the next 10 years, is reversable, can exchange power easily both ways, and saves space compared to USB A. Plus a single USB C port is easier to protect against water than a micro USB/USB A combo. I really hope this light comes with USB C. I’ll still buy one if it doesn’t, but it’s just one of the main reasons I got excited for this lights development anyways.

If Barry can source the USB-C interface plug/port without increasing cost per lantern to much we will go with USB-C. (as its the future format for much everything atm.

That Canadian flashlight guy & Lantern Guru -Den / DBSARlight

Pages