Yeah I don’t think anyone was being rude, I thought there was a simple answer and there wasn’t. Its better to get responses that I wasn’t expecting rather then no response so I thank everyone for that.
A reason that is easily overlooked for using a simple and well-tested driver design:
We are developing flashlights in cooperation with a chinese manufacturer (Sofirn) who is halfway around the globe for most of us. We can not pay a visit to check what’s going on, everything must be communicated via the internet through cultural and language barriers, and they are not the most technically advanced flashlight manufacturer around. We chose this manufacturer because they are prepared to work with us and they are able to sell the lantern for the budget price we like to see.
Anything what is new to them is received with reluctance, for them to get used to it takes time, and progress must be meticulously checked by us at every stage because they can knowlingly or by naivety change any detail at any moment, possibly ruining the design. New stuff can always be done, but the process can be made more easy and will speed up by keeping it simple and familiar for them.
Sofirn is accustomed with the type of driver we are now using in the lantern, it is very much like the Q8 driver. It is different in some details (the tint ramping requires some changes in the PCB design) but they understand it and have the components in house. Furthermore, here on BLF is so much knowledge on this type of driver that we can predict pretty well beforehand how it will behave in the lantern, with just some finetuning of the software.
Without knowing details about driver designing, from what I pick up, designing a buck driver is already challenging enough for BLF (but can be done by some of the driver guru’s around) but then it must be prototyped and tested and both the hardware and software finetuned in the lantern. And Sofirn is for sure not able to do much tuning, so for several stages in the design process prototypes must be sent around the world for testing. This is a much longer process, the reward in the end is a better more efficient driver, but only achieved with lots more effort.
All i am waiting for now is any updates from Barry form his engineers, and if Lexel can build a driver test unit to send Toykeeper to test the firmware on.
Same here. I don’t know if Lexel will build the test driver, but Barry mentioned to me tonight they will need a driver prototype to work on for the lantern.
Several more first time posters showing interest in this lantern, including asderferjerkel, Mediocre99, and skroober, as well as turbiny’s second post on BLF. Welcome to BLF
Note I somehow managed to skip 1066, so I put the last interested person, T18 there.
Master interest list can be accessed by most at the links below:
I see this mentioned often but has anyone ever had an issue doing this? I’ve mixed fully charged cells with partially discharged cells and haven’t experience anything out of the ordinary.
there are a lot of factors as to it/how much trouble one could experience doing this. State of charge of the cells, internal resistance of the cells, the resistance of what is connecting them, the peak current capability of the cells, and others. It’s not a sure problem in every instance, but its also not a good practice to do routinely. Just like ideally you don’t charge cells on a pile of newspapers. Probably nothing happens, but if a cell did overheat, then you have lots of fuel to get your fire started. Especially the way BlueswordM created the scenario. Three charged cells trying to dump current into one discharged cells is definitely a bad practice.
I have a damaged Skyray King here which suggests the issue is more than an urban legend. The “balance out, quite quickly” thing can happen fast enough to melt springs.