definitely understandable. ( especially with the higher cost of shipping to the China engineers.
No, you have that the wrong way around. FET+PWM (or in DC FET= “Turbo”) is the least efficient way of driving an LED. But can give spectacular output when over-driving LEDs. Irrelevant for a lantern, actually undesirable.
Look at all the chatter about which FET, cell, LED, host, reflector, MCPCB, copper addition, spring mods. etc. can, in combination, give “Max Power”—-) for a few seconds before they overheat. Really not relevant for a lantern IMHO.
FET+1, the staple BLF driver architecture, uses 7135 linear up to 350 mA, then the FET kicks in (inefficiently) above that. The single 7135 also allows the efficient firefly and moonlight modes that would not be possible with just a crude FET. And would have some utility in a lantern.
Linear drive, typically using a bunch of 7135s, either banked up in sophisticated manner like Mike C does, or double-down or triple-down, or just one bank sized for max. output, with fast PWM to dim down, is a decent compromise of efficiency, cost, complexity, ease of design.
Personally I wish the 7135 had never been invented. It has stifled innovation for so many years because it works and scales so well, and is inexpensive. Due to being cloned (sometimes well, sometimes not) by so many others (I don’t even think AMC exists any more).
What Led4Power is doing is much more clever, but proprietary. And I fully agree it should be proprietary, speaking as a professional electronics engineer who has to make a living.
This has always been the case for BLF hardware, there is a great reluctance to actually publish schematic diagrams and bills of material for review and critique, I have mostly had to reverse-engineer them from e.g. the OSHpark layouts.
I see that this is also the way that some BLF designers are now working, in some sort of collaboration with manufacturers. Be it hardware or firmware. And I support that. OSHpark and the various open source software models are fine, but not something that I particularly embrace. Engineers should be paid for their efforts by commercial manufacturers, no matter how derivative they are.
If they choose to give away their unique innovations, circuit design, algorithms, hard-won empirical knowledge, that’s down to them (I would not). If they simply re-purpose derivative works from others, that’s down to their conscience as to whether they also acknowledge their inspiration.
Decent work should be rewarded. Whether financially, or by seeking popular acclamation, or the worthiness of “charity”, or otherwise.
Motivation is a complicated subject, particularly on social media like this, we are all different, there are no simple truths.
What’s wrong with having things which are good, cheap, and easy? A thing doesn’t have to be difficult or expensive to be worthwhile.
One could also argue that it enabled hobbyists to innovate because it lowered the barrier to entry; without it we might not have any of the cool stuff we have today. Or one could argue that aluminum shouldn’t exist because it’s too good at too many things, and it’s cheap, so it has stifled innovation of more interesting materials.
Open-source doesn’t mean not getting paid. It’s free software because it’s free as in speech, not free as in beer. Here’s a summary of the two main models for these things:
- With proprietary software, you get what you pay for.
- With open-source software, you get what you pay for, everyone gets what you pay for, and you get what everyone pays for. More people get more value without individually having to pay more, and its openness reduces the risk for everyone involved.
Conscience… and the license. Attribution is legally required in almost all free software licenses, because it’s a necessary part of making copyrights work.
Thanks TK. I wanted to say something but I knew I couldn’t do it justice. I was hoping you’d come along. 
:+1:
+1 …. now that’s funny~
This 
There is no equivalent to the software model licences as regards hardware.
Which, I think, is why there is this reluctance to put up schematic diagrams and BOMs here. Most seem to be copies of application note circuits, when studied. At most we get a link to an OSHpark layout to reverse-engineer.
Circuit designs cannot be protected the same way as code, AFAIK. Certainly not the type of drivers we have, even the most esoteric, it has all been done before, they really are not very complicated.
By the way, with all the SW open-source models, has anyone ever exercised their rights if they thought they were being ripped off ? Perhaps they have, maybe they got somewhere, I don’t know, not my area.
And, to be frank, it is the hardware that costs actual money and is the most important thing for manufacturers to optimise. Just saving a few pence by removing or using lower spec. (but still satisfactory) components, or innovative circuit design, intelligently is of great interest to manufacturers.
If the code source is given away for free (but, hopefully you get paid for adapting it to the device) that’s fine by me.
But hardware design, component selection, PCB layout, prototyping, testing, requires expensive tools, skills, knowledge, time, expert materials procurement etc. to do it properly, and is a rather rigid discipline. Not something to be dipped in and out of.
Or done remotely, from a WiFi laptop anywhere in the world. You actually have to check in to the Lab and use the (very expensive) kit to see what’s actually going on.
Quite different from simply connecting a clip and having a few goes until you have something workable.
The PogoPin connector will be transformational I hope.
I’ve seen code written by engineers. So I can say with some authority that software is not something to be dipped in and out of either. Just because you don’t know how difficult it is to do correctly does not mean you can dismiss it as trivial. Good software is what makes or breaks a lot of products these days. For example, put bad software in a car and you no longer have a car.
The pogo pin connector is already ordered by me
the topic is also public as well as the pattern for drivers
who says this is a fully open source project?
Even open source firmware or driver design can be under open source rights
for example forbid the commertial use of it without making an agreement with the programmer or designer
also open source for code means usually laying the source code open, but noone is forcing Toykeeper not just to make the hex file public
on the other side having just the Gerber uploaded to Oshpark means you do not get the design file
this is still the decision of the one who makes the design, if I do not want to post it the only way to get a driver is reverse engeneerring from a lantern
BLF do not nessesarely means open source for everything, or the guys developing not getting payed
But making it open source is a tribute for the community,
you forget how much effort in some things like Toykeepers firmwares is spent
like someone wrote if you are not happy with the driver make your own design and see how many hours you will spend,
even reverse engeneer a driver takes hours in the complexity of the current FET driver
indeed well said all these projects take hours, days & months of work.
So I spent time at lunch today updating the interest list. huey18 spent some time and effort automating this, but not all folks wanting a lantern are following his instructions for request, and also there is a problem with the listbot updating last I saw. Anyway, I added another 25 lights to the interest list since I took a short break, the total is up to 1004. I know there is an error of at least one, but hopefully everyone that wants one or more will get the code or whatever once this goes live. Don’t hold your breath for that, but things are moving these days.
I noticed I’m not on the list (I had expressed interest for one in post 1776). Could you add me for one?
This is something we can quantify, though. At a glance…
- The firmware repository has a total of 723 revisions, or 622,556 lines of patches (including everyone’s code, not just mine), committed over a period of about 4 years.
- According to sloccount, the FSM project has 9,171 lines of code, which it estimates would take one average programmer 2.05 years to write, or would take a team 8.4 months, for an estimated cost of $115,336 (or $276,808 including corporate overhead). I think it has a tendency to estimate high though.
- Some other projects according to sloccount (without overhead costs):
- BLF-A6: 18 days, $2,846.
- Bistro: 2 months, $9,268.
- Crescendo: 2.8 months, $13,048.
Just a ballpark idea of the amount of effort involved in these things.
OK, something to bear in mind if I’m only running the light with one cell - not all cells are rated for that.
Two or more cells should be fine, though. I haven’t seen any 18650s that wouldn’t accept a 1A charging current.
Believe me, I appreciate those efforts. The majority of the lights I use nowadays run firmware ToyKeeper wrote. I’ve also benefitted from things like the BLF A17DD driver designed by Wight, and it looks like I’m going to benefit from Lexel’s driver for this lantern.
Thank you.
I definitely missed you, sorry TheShadowGuy. You are on the list now.
I updated the OP interest list up to # 971 with the last .rtf update you sent me.
Wow!!……. Is now a good time to ask for a loan? 
Those are only estimates, the amount that a standardized tool thinks it would cost to develop the same thing at a traditional software company. But that’s not how the code was created.
Would be nice if I was actually paid what sloccount estimated though.