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.
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.
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.
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!
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.
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.
Ever heard of search services? Nah just kidding, as the previous poster showed a pastebin is a place where you can put code to get it away from the forum flow and also get line numbering and syntax highlighting if wanted. You ask a question which only a few people can answer and the rest that can’t don’t have to scroll past your code in the forum if you put at a pastebin instead. If you’re interested you just click the link to the pastebin and you can see the code there.
1. I currently have blf-A6 configured so that “turbo” isn’t the last mode in the group. I think because of this, the turbo stepdown isn’t working. Is there any way around this, or does turbo have to be either the first or last mode?
2. This may not be something fixable by firmware, but I have noticed that OTC times speed up dramatically as the light gets hot. The values I have are perfect for forward/reversing normally, but after the light heats up even the shortest of taps makes the mode go backwards.
3. This firmware is in my light with red and white led’s. The small circuit goes to the red. On the last mode in the second group, it should be full-on red and no white, but the white led’s do light up at a moon level. Is this just leakage through the FET, or did I crew something up in the firmware?
But the end effect is the same.