Good, LVP is the most important bit anyway.
Bat check is another nice feature to have, also 2 pwm channels support. But that could get complicated.
Is you pwm fast for the lower pwm levels & phase for the max output mode, as is often recommended?
None of my firmwares support dual-pwm even though they’re kinda prepared for it. As you say it will get a tad complicated as different people will have different opinions on how it’s going to be used. Just setting both outputs to the same value is easy though. And yes I’m using phase for full output (mostly just doing as ToyKeeper says :laughing::
I haven’t thought of battery check, yet. Don’t think I’m gonna bother with it but you should never say never. If I do it I think I’m gonna hide it in 30 short presses or something like that. Will maybe have to throw out something else to make it fit though.
Hi TK, do you have any ramping firmware in your repository?
Yes. To get a list, browse to the index file, and search for “ramp”:
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/view/head:/INDEX
Is there any firmware in the repository that has a good formula for smooth PWM brightness adjusting? The ones I have looked at all have a predefined arrays. I’m looking to avoid that and would rather do it with coding. Increasing by the same amount just doesn’t work very well. So far I haven’t come up with one that smoothly and evenly goes from moon to 255.
Take a look at ToyKeeper/Ferrero_Rocher/Ramping_UI_Table.c and the ramp_calc.py tool. It calculates a small variety of visually-linear ramps with an arbitrary number of steps. I find that 64 steps works well for a 2-second ramp, though Ideally I’d like more steps per second. I only used 64 because it was the most I could fit.
Calculating a smooth ramp on the device itself is difficult because it doesn’t do floating point math and doesn’t have much space. It’s much much easier to use a table instead, even if it’s a large table.
In any case, the models I’ve tried are logarithmic, quadratic, and cubic. I personally like logarithmic ramps because it gives me more resolution toward the lower levels, but cubic is technically more correct. Quadratic gives sort of a compromise between the two.
Additionally, the lowest levels can benefit from using PFM (pulse frequency modulation) in addition to PWM (pulse width modulation), because the lowest few PWM levels produce pretty large visual jumps in brightness. PFM can smooth out those lower levels, but it only works on single-channel drivers (no FET+1) and it can be very sensitive to battery voltage.
I’ll check it out, thanks.
I have a ramping clicky, is there a ramping MOM anywhere? For an 8X ~ 12X Nanjg...
Yes, that’s what the one a couple posts ago is — a ramping UI for momentary switch lights like the SRK or Roche F6: ToyKeeper/Ferrero_Rocher/Ramping_UI_Table.c
For a nanjg-based driver, you might need to recalculate the ramp values. By default it’s calibrated for a FET driver or a 32x7135 driver, but regular nanjgs need a higher zero point. The ramp_calc.py tool can generate new values for you; just tell it the lowest PWM value which actually produces light and adjust the goal multiplier… it might take some trial and error to get it to produce the right number of steps though.
I'll check into it.
Thank you!
Hi guys, I’ve been playing around with the blf-a6 firmware for a light that I’m trying to build. I’ve compiled it and it just doesn’t work just a quick flash then no output. I have tried a different firmware on the driver to confirm it work and that’s all good so has to be the firmware that’s causing my issues, yet I can’t see what the matter is.
Any chance you could give it a look?
Thanks
Pyro
I actually did end up implementing batcheck, put it at 30 short presses. Using a five step scale and ToyKeepers values it works quite well. Took a battery directly from the charger and it showed five. Used it for a day and it showed four. Used it for another day and it showed three and now it’s down to two. Will see what happens when it goes down to zero. I took away low battery step down though, don’t like it anyway. Low battery shut off makes more sense to me so I kept that, haven’t tested it yet though. Now it’s summer around here and the sun is up all the bloody time so not much time for testing firmwares. Testing inside is just boring. I wrote this firmware almost as a joke but it’s actually growing on me. It’s kinda the ultimate flashaholic firmware as it’s empty from the beginning and you must program everything yourself. Seven modes possible so five normal levels, strobe and sos ought to be enough for everybody yes. 
You got a ton of compiler errors. Start with installing avr-libc as the headers are missing.
I didn’t get any errors when compiling in a avr studio. How odd?
Isn’t the “output” you pasted yours? Or maybe that is something that is automatically generated? If so then you can ignore my previous comment.
codepad.org seems to be a compile/interpreter as well - not just file sharing, so I think it tried to compile your code. = that explains it.
guardior - which exact driver/board are you using? Are you sure it' a DD+1, and if so, connected on the same pinouts as TK has it configured for?
Ahhhh that may be causing some issues here then.
No no, I’m still only on 105d. And will be for some more time, I’m not really good with soldering but trying to learn.
He meant the pasting site so you can safely ignore my comment. But finding bugs in that code is not easy as there are tons of ifdefs and whatnot.