Flashlight Firmware Repository

Jack - TK should really respond to you on this - she's the keeper Smile. She implemented a nice short/long press detection on using a cap - it's pretty standard now and is being used in the BLF EE A6 group buy light (https://budgetlightforum.com/t/-/31076). I've built a couple of lights with the same firmware. I much prefer an e-switch light for short /long press's though - easier, more consistent, much better UX/UI.

Ohh - haven't seen you on BLF for a while, hope all is well. If you just came back recently, there's lots to catch up on. RMM's website: http://www.mtnelectronics.com has many of the latest things we are building - parts, drivers, hosts, etc. Triples and quads have gotten to a whole new level, as well as insanely high amps in smaller and smaller lights.

I just did some browsing on the wiki - didn't know it was still maintained - there's lots of out-dated info there, but also lots that's still very useful. I can't find how to participate and post to it though. I never used BLF-VLD, always went with my own version of luxdrv, but now, luxdrv is pretty out-dated. I use OSHPark custom drivers almost exclusively now - the" FET+1" drivers where you get best of both - high powered modes from a FET, low modes off a single 7135.

Hey, yeah I’ve been away for a while, just peeking back here and there. I still have my triple nichias to be finished so might get to it hence need to make or find in the new large amount of FWs that has popped up something that I can learn from. Datasheet for ATtiny is nice but it says zero about an API itself/the functions, header files, Atmel specific libraries to talk to the chip. Will have to move my programming environment to current PC.

MTN has new offers yes, seen it but it’s mostly an option for US only. Plus I already have the FET+1 drivers built for over a year, only running with FET and not using the single 7135 on secondary PWM output for moon nor low mode. Didn’t get to make the FW back then. MTN doesn’t say much about FET specs or the UI/click behavior.

What other new parts are there?
I’ve noticed the new Convoy S2+ red metal switch, but apart from that don’t see any newer hosts. Same old stuff.
What is new in triples? Noctigon + Nichias or XPs with Carclo, probably same as ever. Except now people have the option to cheap out with KD lotteries and the newer Nichias that have lower CRI?
High amps and small lights never mix well, anything 120x25mm sized can only run high amps for so long before getting hot. I guess smaller drivers with higher output are available? 15 or 10mm? But no high amps boost/buck 17mm Nanjg105c sized? Or has it been achieved? No copper pills instead of brass by default, still has to be made by someone and moded. Any new small high amps switches and springs?

Yes FET+1 I have. But I did a 105c Nanjg mod, took 7x7135 off and added a single FET, Vishay 424DP. The budget way instead of buying a $15 driver premade that wasn’t available anyway :smiley: No one was making these yet to sell, and from POV it wasn’t feasible to do so. It maybe works for already established shops to make $1 on an expensive driver. I’m surprised though that they don’t ride it out all the way, have it made in Asia in bulk, not “solder it on OSHpark PCBs in the shop”, probably reflects how many they sell, very few.

So what drivers are there that support double PWM output, hence support FET+1?
Plus short/long press. I guess I will need to modify the UI anyway, I think someone made it before, there aren’t that many options for UI with a single button but it’s not the usual.
No memory, which needs short/long press to work right. And short press mode advance.
As in, 1xshort advance mode, long reset to default.

I run nLite now but that’s the usual messy UI without short/long and hence incomplete no memory. It works, sort of, only one light shows PWM noise though, no idea why, maybe nLite doesn’t run as high PWM freq. it’s one light of 3 that does it.

What is outdated on Wiki? I can check it when I get back to programming and update that part. Last add was probably nLite link there on the drivers page. Tools seem to be the same and still working. WinAVR is dead for real so there is AVR Tools instead. You have to register, then you can edit. True almost no one does, which is a shame since it’s crazy for anyone to go through these 1000 posts threads to find that hidden piece of useful information about drivers and FW.

Oh boy. lots of Q's - not sure if I can answer all. The Red Convoy S2+ is a great little light - my favorite tube EDC without an e-switch - it's a perfect match for the BLF-A6 firmware. But I prefer e-switch lights mostly. The meteor M43 is the big thing now, but availability is scarce. OSHPark, I believe, is a revolution in the evolution. For $2-$4 you can qty 3 of custom made drivers. I've reflowed and programmed a ton of them, as many others have.

The Eagle Eye X6 was probably the biggest group buy deal ever, here on BLF, but had it's issues - it never achieved the stock amps it was supposed to get, and the UI never matched exactly what we requested. The Eagle Eye A6 also represents another phase of evolution - collaboration of BLF hobbyists and china manufacturers to finally get something to market we really want: custom driver, custom high end firmware pre-built in the budget quality light, bringing the state-of-the-art us modders are doing to the masses at a significant cost savings.

CREE, of course, is advancing but with noted concerns the new LED's can't take as high as amps anymore. Where older XM-L2's could achieve 6.5A, now the new ones do about 5.1A at max from a single cell DD setup.

For the best DD+1 and tap/med/long OTC cap support, seems like ToyKeeper has the best firmware offering - the BLF A6 driver, in her repository: http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files

For the wiki, I just got approval today for posting/updating. There are all sort of areas lacking:

  • XM-L2 U4 missing
  • other LED's also seem to be missing the latest bin now available
  • no mention of the XHP50 and XHP70 (latest hot rod LED's)
  • the manufacturer and website listings are wayyy dated
  • the review listings are dated by a couple of years, and light-reviews.com is listed before CPF and BLF - weird because light-reviews.com has the latest review dated June 2013 and latest news is from Aug 2012
  • the "popular drivers" is way out of date - today you can buy a true buck driver in 3 different sizes, up to 4-5A, buy the kit of parts if you want or assembled, and program it the way you want with a selection of assorted firmware drivers -- this is a huge advance after many disappointments in trying to do exactly this in BLF over the last 2 years or so
  • the terminology section is fantastic, but also dated. For example, OTC should definitely be there -- it's an indication it's dated

I'm not saying it's not hugely valuable - it is. The technical ref areas are outstanding and still applicable and relevant. I don't see how a team of people can keep this updated - it's a huge effort.

What was the other firmware you tried? I think you said the driver has two power channels, but does it use a FET and a 7135 or is it all 7135s or is it some other type? What kind of emitter is it hooked up to? How much programming have you done before?

Depending on your compiler setup, it may also be unable to fit the compiled code into 1024 bytes, since blf-a6 is 1022 bytes by default and any compiler changes can make it significantly bigger even without touching the code.

Did you try the default blf-a6.hex file, and did it behave any differently?

I’m not familiar with the BLF VLD… must have been before I got involved.

The capacitor for detecting long/short presses is very common now, and works pretty well. It has also been extended to detect short/medium/long presses to allow for more detailed interfaces. Some firmwares use a different trick to measure “off’ time without a capacitor — set part of the RAM to zero, then check whether it’s still zero when the light comes back on. The RAM decays to mostly 1s after about half a second, so this can distinguish between short/long presses without extra hardware.

The closest we have to a detailed firmware index is the index file you already found, which is pretty brief. I didn’t think of mentioning wear leveling, since pretty much everything does that. Feel free to add that to the meta files yourself though, if you like. I’m happy to accept patches, and all help is greatly appreciated. :slight_smile:

Also, feel free to add links and such to the wiki. I haven’t attempted to edit the wiki but it sounds like a good idea. That’s kind of the same reason I started a code repository; there was too much information scattered in too many places, so I wanted to collect it into one place to help people find what they need.

An e-switch definitely offers more possibilities. I’d like to have more e-switch lights, but they also kind of need a better MCU and more development effort in order to work well. I can fit a lot more features into 1024 bytes on a clicky-switch light than on an e-switch light.

I’ve also noticed an obnoxious issue with clicky lights using an offtime capacitor… the OTC drains at different speeds depending on temperature, so it’s hard to do a medium or long press when the light is cold. Instead of the usual ~0.6s for a medium press, a near-freezing light took more like 6 seconds. I run into this when biking in the colder months.

Maybe I should use memory decay instead of OTC to measure the short press, and keep using OTC for longer presses. I don’t think the memory decay is as sensitive to cold.

RMM and wight both designed some nice dual-pwm drivers in a variety of sizes and configurations. I’d suggest browsing RMM’s store and wight’s driver index thread to find more details.

As for code, there are a few projects with dual-pwm support, listed under “dual PWM:” in the repository index file. Quite a few support off-time switching with no memory, listed under “OTC” and “mem decay” and “offtime” in the index, and Memory :: “none”.

STAR should give you something similar to NLITE but with more features and options. Starry-offtime adds a couple more options. Or the blf-a6 and cypreus2 code currently have the most features available for dual PWM, but that might be more complex than you want, with lots of hidden blinkies and such.

I'm near to finishing my collage code but the lockmode don't work basicaly i've copy paste.

All works fine unless lockmode

It’s a FET +1 driver hooked up to an XP-L and XQ-E, I used a firmware I had flashed to a different driver I build and that all worked fine. I have done no programming but can understand the basics of whats going on in the code (just about).
I will give it a go with the default hex file later and see it that works.

Yeah I know mtn ships to Europe now. But I have lots of stuff planned before trying out dual-pwm. I’m not really interested in the EE A6 either as I think it’s way too small to be running DD. If it was a Convoy M1 I would have signed up for one though. I could of course get the A6 and move the driver to a M1, will have to think about that.

@Jaimelito

Ever heard of pastebin services? :stuck_out_tongue:

That’s interesting. Do you want the two emitters to light up at the same time, or at different times? I’m not aware of any FET+1 drivers which were intended for two independent LEDs…

Hah, I have same-sized lights running at 3X the power of the BLF A6. It just requires being more careful with the light… You can run 15 amps in an 18650 tube light for short periods of time; just don’t leave it on high modes for very long.

I generally won’t run a light that size at more than one amp for any extended amounts of time, and usually the highest I use is 350mA (98% duty cycle) with a 1Hz full-power stutter (2% duty cycle), for an average of about 500mA or 600mA. This works well for biking, and the air flow keeps the light not only cool but actually cold.

Basically, I treat it as a 1-amp light with a really nice blinding turbo mode and bright party strobes.

I want them separate so one group of modes for one and another group for the other. I’m using a FET +1 with cut traces to give two different LED - outputs.

Just given it another go building it slightly differently and it WORKS!!! So excited managed to finish my build! :slight_smile:
Only thing is on the second group in the two lower modes both LEDs come on but not in high or in the first mode group. Odd but I can live with it for now.
Here is the new code I used.

That’s because you used fast PWM, which still turns on for about half a clock tick each cycle even at level zero. If you switch that to phase-correct, it shouldn’t turn on the main LED while the second LED is on.

This only happens on the FET channel because the 7135 channel isn’t powerful enough to make the effect visible.

Actually, it's because the 7135 isn't fast enough to react to a half-a-clock tick (@18kHz). But the end effect is the same.

P.S. Thanks TK, for all your help, you are much appreciated!

Interesting.

I have a 32x7135 SRK driver which still lights up at fast PWM level 0. I guess with enough of them in parallel it can rise high enough to barely light the emitter at that speed. But yeah, the rise time is slower so it’s not normally visible until like six ticks or so on regular nanjg drivers.

Ahhhh I shall make that adjustment! Thanks for all the help guys! :slight_smile:

I don’t understand you, what’s the meaning of “pastebin” ?