LED drivers and Accessories you want, but don’t exist

The parts cost more than 10€. I sometimes bought more parts than I needed (for example 4 MP3431, or 4 of each tiny25v version with the right package, to hopefully get rev E parts), and it cost me around 58€ (for 3 to 4 drivers). If you just buy the necessary parts for the driver, and more sets, it will be cheaper. Idk, maybe 15€ less (so 43€ for 3 drivers, without boards).
And 3 boards cost 5$, I will make it a little bit smaller for less sanding.

BTW, here’s a programming socket for $40 (free shipping to my place):
https://www.aliexpress.com/item/QFN20-MLF20-WLCSP20-Adapter-IC550-0204-009-G-Programming-Socket-IC-Pitch-0-5mm-Clamshell-Chip/32676558392.html?spm=2114.search0104.3.10.H8ZL1Q&ws_ab_test=searchweb0_0,searchweb201602_1_10152_10065_10151_10344_10068_10345_10342_10343_10340_10341_10171_10541_10562_10084_10083_10561_10304_10307_10301_10060_10155_10154_10056_10055_10539_10537_10312_10536_10059_10313_10314_10534_10533_100031_10550_10103_10073_10551_10102_10552_10553_10554_10557_10142_10107,searchweb201603_25,ppcSwitch_2&btsid=aaf308f6-4c9a-41ec-88f4-177c5a275951&algo_expid=989691e9-b513-44ae-9744-c9d3b7ee472f-1&algo_pvid=989691e9-b513-44ae-9744-c9d3b7ee472f

If you only use those, the MCU has to come off the board if you later want to update the firmware. I still think it’s better with vias on the board for acupuncture style flashing, providing that you can fit the vias. As a driver and firmware developer I make sure to fit them myself:

hmm sometimes these quotes won’t die after a link.

PWM's aren't even fixed on the attiny25. See my bistro-HD code, especially the timer interrupts. Ok, of course hardware PWM is fixed, but you can do whatever you want with interrupts. Only issue is I may recall those chips can do hardware PWM in some nice sleep modes, and that wouldn't work so well with software PWM. Mostly though I don't mind clocks being tied to pins. There's a point where there's too many options. That many pins in that small a space doesn't sound too easy. 8kb not enough for a flashlight? Wow. You must have run with that plan to accept data through light from the led and setup a TCPOFL network. If you want to do a lot of dynamic stuff like better regulations of various types I suppose I can see it though. Narsil is about maxed out now.

The vias are nice of course but on this boost driver, I'm not sure there's a way. Really though flashing a bunch is mostly for development, on my EDC I'd prefer not to keep flashing it (but then I don't have much else for development). I'd take a boost driver like without easy flashing if that's what's required. Seems like a nice driver.

If you have the programm socket you can flash the driver before soldering
Saves time

For reflash later instead viases small solder spots take less space

There are also 2x3mm small SMD. Onnectors, but then the wiring gets more complex

Those drivers are 4 layer so more expensive right?

I hit the 8kb limit because I have multiple UI types and everything configurable by button presses. That could all fit, but I had very little room left for a bunch of experimental stuff and found myself having to take code out for it. As the 841 uses the same footprint and is (for me) the same price, there really was no reason not to switch. But yeah, in normal end user firmware 8kb is enough by margins.

I managed to fit vias on my GXB17 rip off design. I have the boards but haven’t built one yet:

I’m quite sure I can squeeze the vias in on a new board modified with the boost circuit discussed here as it appears to use less components. Updating firmware is of coarse not needed for everyone, but as I’m always coding something I like to be able to.

Mine are 4 layers but that’s not a problem because in terms of community interest, my boards and firmware don’t really have any. A saving of $0.82 per 17mm board is for me really not worth the hassle of trying to squeeze everything into 2 layers. Of coarse the additional copper thickness option isn’t available for 4 layer boards, but I don’t see that as a show stopper.

Your boards look pretty cool and your firmware likely better. But isn't your work all closed source? (which is cool,but not what this project is I guess) and I suspect this will stay open, and in that spirit 2-layer as you point out, and at least for this proto it's getting bistro-HD which fits on this attiny25 and is open, and is an incremental continuation of the previous community project. Of course people just buying a driver would likely buy yours. I would have a year ago. A lot of the "community interest" (not that bistro-HD has so much either) does it to build up the open source toolbox though, because that's fun, maybe even more than to make our own lights work.

Do you think it's possible to get the vias on a 2-layer board? What about with the attiny25 (it's also only 4 mm)?

You are correct Flintrock, my involvement in this has been primarily to expand the open source driver options. If someone wants to rip it off and make or even sell their own closed source version, please do! More options, more better in my book.

Yeah, and well it's not even all about open source but about the community path. I've seen some probably really great open source code too that still gets ignored. I'll gladly admit that I "took advantage" I suppose you could say of bistro popularity with HD, or you could say I supported the popular thing. People don't generally like too much change and too many choices and like to stick near something they know for awhile. The main thing HD did was just fix one big issue with previous bistro boards. You can keep using bistro over some fancy new thing, but it's hard to keep using old bistro when there's a new bistro that's basically the same but fixes one clear problem in your light. Even that though has probably been used by less than 50 people, maybe less than 20. Of course there really aren't that many people building and flashing their own boards.

Jesen, I haven't seen your work, will have to check out. Sorry if I stepped on anything here. Schoki asked about getting HD for this in PM, and it's basically already done, just not released (it's just a config anyway). Anyway, as you say, more options=better.

As for "ripping off" I kind of agree. Bistro was already gpl3 though from TK. I figure I own completely copyright to large parts of the stuff I've added and so could open those bits up to BDS or MIT or such but I'd consider if somebody asks. Of course in a world of Chinese flashlights, you have to figure it could happen without asking too, so whatever.

And MIke C I wouldn't say your work doesn't have community interest. Certainly your early testing and discussion of the OTSM concept inspired me to figure out how to get it working on existing less-efficient hardware (another big focus of HD, wide existing hardware support) and there's been a bunch of talk about your use of these newer chips and even skewer flashing (which I like because it's back-side accessible and probably easier to secure than clips). There's some discussion of possibly some HD commercial boards on attiny25 in the short term, but moving toward these newer chips long term, so you've been inspiring things. Not sure if any of it will materialize exactly in that way.

For a lower power buck/boost I found LTC3119. Has 5A switch current, 2.5V to 18V input, 0.8V to 18V output, will run down to 0.25V after startup.

Sense resistors are a hurdle with regards to efficiency and power handling. MOSFET VDS feedback is a far more reasonable way of sensing. It seems that there already are some commercially available noRSENSE controllers. Look, for example, at this little beauty: LTC3785 - 10V, High Efficiency, Synchronous, No RSENSE Buck-Boost Controller

Cheers :-)

P.S.: that sh1t owns!

I did share some 85 firmware for boards some time ago and shared a couple of boards for it because there was interest, but the problem is that my firmware is locked to my boards. I spent quite a bit of time writing instructions so that people could use it, and in the end it turned out that no one was interested enough to actually read any of it. I totally understand that, most firmware here is compatible with boards from multiple designers, but after that I just don’t bother because it takes too much time to do write ups that hardly anyone will read.

Sure, once the boost circuit discussed here is tested, I can attempt to make a two layer version in Eagle with the vias. If I succeed I can share it with some basic firmware, but as I only work with the 1634 and assign pins to my liking, I kind of have a feeling that a Bistro compatible 25 version will be much more of interest to the community.

In terms of new chips, I think there are a few that are waiting on the 1616 and/or 1617. I didn’t want to wait. They aren’t easily available to me, no AVRDUDE support and higher pin density than the 4x4mm 20 pin package. The 1634 is available, package size is as small as I want to go, 16KB programming space, AVRDUDE support, 17 usable I/Os and has 0.1 uA parasitic drain in power down sleep mode. That’s all I’m interested in really. I don’t use the Full Duplex USARTs, QTouch, I2C interfaces and all that other stuff. If anyone wants some help migrating to it, I’m here, but for my own boards and firmware I’ll just carry on as usual.

@ Mike C:
Hi Mike,
would you mind to share the best drill size of the vias for your programming wires?
I’m currently designing my first flashlight board and intend to use this technique if my additional attempt with pogo pins doesn’t work as expected.

I’m using 0.9. I had 0.8 before but sometimes via sizes are not exact in OSH Park fabrication, so on some boards 0.8 was too tight. Note that I might not be using the same pins as you. I got some pins I bought from Fasttech that work but wanted longer so I’m also using cut up copper paper clips.

0.9 can be a bit loose, so I have to take care when flashing. I’ve bricked a few MCUs on driver boards because of glitches when flashing. Now I use a development board for firmware development where I have soldered on the connections, and when flashing actual driver boards I’m very careful to test the connection multiple times before actually flashing. I don’t have room for those 3x2 connectors, so this is how I do it.

Thanks!
I’m designing a Q8/SRK board, so there is space for a 6x1 row of connector pads. Found some info about pogo pin board design and will try this also.

http://blog.spitzenpfeil.org/wordpress/2013/11/12/the-pogo-key-1-27mm-avr-isp-adapter-take-ii/
https://easyeda.com/feather/ispogo-oA5nFXR93

I had a similar idea but a round one that would match up the vias on my 17mm boards, but for each new design they change places so I just skipped it. For a SRK sized board it’ll work fine.

Funny asking about Vds control (to regulate normal FET drivers) was my almost my first post here, got a lot of negative reaction. Some of that was about software though, which I get now (although easy enough on bigger chips). There's also sensefets, which is a little different I guess. FM I don't know what you're designing, but there is a buck design for SRK already, never tested though. It's slightly degraded by the controller needing PFET's, but it should still hopefully put out 12A to 15A at 6V or maybe even 12. That's a bunch of power.

So Flintrock, you have a version of Bistro-HD that will run on the MP3431 driver Schoki made? This is very exciting to me. As cool as the Narsil ramping is, I ended up changing my Narsil flashed TA driver back to standard mode groups in my Convoy L6, I found that I never really used ramping and appreciated having a few set modes more.

Personally I think between 3 and 5 modes is about right, 3 if just L-M-H, 4 or 5 if there will be a ML, Turbo, or both.

High should be set as the maximum continuous output the light can sustain thermally, with low and medium appropriately spaced based on that. Moonlight should be about as low as the driver can handle with turbo as high as the emitter or driver can handle.

Does Bistro-HD have temperature compensation built in? On my drivers I have a thermistor mounted on the driver PCB and one remote mounted on the MCPCB and would like to use both of those to automatically ramp down the output at set temperature limits.

I’d also like to potentially ramp down the output based on battery level at the bottom of discharge rather than just a hard cutoff.