Flashlight Firmware Repository

Thanks for the explanation, I’ll test it someday. It makes sense except for one part. If one wants to shut off the emitter completely, why not just turn off the pin?

It would probably work, but it’s usually easier to just set PWM=0. Fast PWM will still output a brief spike even at zero though. IIRC, someone also tested a slight difference with PWM=255, where phase was slightly brighter than fast (fast has a brief downspike even at 255, I think). So as a general default, it’s usually a good idea to use phase at moon and turbo but use fast for everything else.

Adding pin logic is untested, I think, and would use a bit more room in an already-cramped space. It’s also redundant if there is already logic to put the MCU into sleep mode while “off”.

I suppose it’s a minor issue at worst, so nobody has spent much time on it.

To turn off the pin only one additional row of code is needed, but I guess your right with it being not needed. Thanks for taking the time to explain it.

Guys, Is there 1 mode-100% ( or star choosable 1 mode) 105c firmware awailable guys? Currently i am bypassing the atttiny13 in order to achieve this , and ofc warnings and cut-offf are lost this way

Hi Mitko,

I have a couple of “1 mode” firmwares you may like;

  • 100% only, with Low Voltage Protection enabled (will flash 3 times & drop down to 30 (out of 255) output when 3.2v is reached).
  • 100% Turbo for 2 mins, then steps down to 110 (out of 255). Retains LVP as per above.

These are for Clicky switches.

I can throw them into Pastebin, or email them to you if you like.

Isn’t 3.2v too high?
Can you send me these files too?

When using a zener modded board for use with an MT-G2 do we need to just adjust the ADC values or swap out the resistors as well to get it into a specific range?

You should be able to do that in many of the available firmwares, simply by removing all modes except turbo. This is generally done at the top of the file by changing or removing #defines.

For example, in STAR, I think all you need to do is comment out the “MODE_*” lines except for “MODE_TURBO”. This should give you a light which is 100% or off, with gradual ramped step-down to about half power after the light has been on for a while (default is 2 minutes).

It appears that the code will also step down by half each time the voltage is too low, except it won’t go below the lowest level… which could be an issue when there is only one mode. You can probably fix this by hard-coding a minimum instead. This is untested, but here’s an example of the changes needed:

<code>
(there was a diff here, but it didn't format correctly and was untested)
</code>

Edit: The forum doesn’t seem to like raw code and is reformatting some of it incorrectly… instead, try going here for a 1-mode version of STAR which I tested on my bench power supply to make sure LVP works:

http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/head:/ToyKeeper/STAR_1mode/

Both. Your voltage divider must also read directly from the input source, since reading after the zener diode will always give you the zener diode's voltage.

@TK i hope this question fits here if not, please someone direct me where this is more appropriate :slight_smile:

I have been thinking about if you only want a nice low moon/max of one 7135 chip/and full blast DD in a driver, do we even need an FET for this?

Couldn’t the attiny13a simply connect the battery to the led & and shut down the 7135, similar like what DrJones did in his “Glow” driver

But instead of a glow mode from “An additional 100k resistor bypassing MCU and AMC7135s, while the MCU switches the 7135s off” you do the same but without the resistor to get full DD on one channel & a nice regulated 7135 on the other.

And another idea :slight_smile: if you don’t want/need the max possible output from the FET driver PWM level 255 for max amps, could you lets say start at a lower percentage, for example PWM level 128 and then pseudo regulate this so that when the volt drops & amp drops it automatically raises the PWM level to get a stable regulated output from a FET driver?

I’m trying to get LVP working on an MTG2 build.

I am using 22kohm as R1 and 2.2kohm for R2. I ran TK’s battcheck with my power supply at 6.2v and it spat out a value of 136, and 130 for 5.9v.

I plugged those into STAR offtime, flashed the driver, and reconnected my PS.

I started at 6.4v and slowly lowered the voltage and…… nothing happened. I let it run at 5.5v volts for about 5 minutes and LVP never kicked in.

I reflashed and retested again with the same results.

I gave up and put batteries in the light to use it that night, and immediately LVP kicked in. I removed the batteries and checked them, they’re both at 4v.

Any ideas what’s going on? Do I need to set my PS to a higher current?

DD directly through the attiny would blow it in no time. Remember: V=IR (think of the attiny13a as a VERY high resistance switch).

To fully regulate current you need a sense resistor (with additional losses), but you could alter PWM based on battery voltage as well (I think that someone has already tried this).

Were you measuring the power supply output with a multimeter? If the current is set low, then the voltage will automatically drop down to the voltage needed to maintain that maximum current.

I think that's beside the point though, since your values are in the ballpark. Your batteries might be sagging down to the LVP level.

I have checked it’s accuracy with a DMM, but not at the time I was doing this. The ‘Constant Voltage’ light was on at the time. I don’t think it’s battery sag, because it kicked in on low mode ~350ma.

I was using a FW that previously had LVP disabled, so maybe I messed with it more than just commenting it out and don’t remember now. I’ll retry but starting with a stock FW this time.

edit: just redid the battcheck with dmm this time, and got the same values.

So I started over completely, and it still isn’t working correctly.

I decided to disable LVP, I’ll just be careful with this light.

Hey there.

I’m using TK’s BLF-A6 firmware wherever I can so I can get familiar with at least one program. It worked great with Wight’s FET + 1 (using both channels). I fine-tuned it with Battcheck. Offtime didn’t need any tinkering as it was right on even though it doesn’t have a pull-down resistor. I found where it checks for memory, and set it to on. I gassed everything in the hidden mode, save for battcheck. I didn’t test parasitic drain after LVP shutdown.

Then I installed it on Wight’s 22mm 16X1735 single-channel driver. The only thing I had to change was to put battcheck on the first PWM channel and put values on the lower main levels as they were zeroes. It was reassuring that the battcheck firmware blinked out values within 1 of the FET + 1 driver from 4.2 down to 2.7 volts on the Fluke.

I have a couple questions:

I had a hell of a time with offtime medium presses on the 22mm 16X driver. I started at 470K on the pulldown resistor. I ended up using 910K, and medium presses were still too quick. So I loaded TKs Offtime_Cap firmware. A fast press gave me the expected 255, and medium presses gave me values of 156, 144, 148 and 140. The firmware was set to 190, so I changed it to 140, and everything is working. Given the values I got, was 140 the correct value to enter? Should I have entered a lower number to capture longer presses? How low can I go and still recognize the 156 press?

Next, I tested the LVP. Everything went fine, with the light throttling at 2.8 volts and going dark at ~2.75 volts. With the light dark (but still on), I put the Fluke on amps, and measured 270uA coming from the battery. That seems high, as the 13A’s datasheet shows the draw at 190uA when active, and 24uA when idle. Is there a way to get this 270uA down? Maybe the unused second PWM channel is doing something?

Thanks

I tried the medium press thing, including several different OTC values, and just can't get into it. If it's not on a momentary switch I don't want medium presses because I can't consistently do it without some sort of feedback. It's also a pain to get things consistent between different drivers and parts. I can see someone doing it for that "one light" they use a lot and become really accustomed to, but for lots of lights it's a huge pain in the butt. It's a cool idea, but just not one that in practice I really like. Of course, that's just my opinion, and everyone else is entitled to theirs.

~200uA is about par for the course if the attiny isn't sleeping, plus you've got the voltage divider draining a few uA no matter what, and probably the pulldown resistor putting a drain on things if the MCU isn't going to sleep.

That’s me and moon mode and/or a bazillion levels. Just give me 3-4 well-spaced levels—like mode2 in the A6 firmware.

I didn’t care about medium presses either until TK came out with on-board battcheck, which is accessed with a medium press. Battcheck is a really nice feature IMHO.

Edit:

I sure can see where setting up drivers for medium presses in a production environment would suck. Get the OTC/pull-down resistor (if applicable) close, flash offtime-cap, get the right number, program it in, flash battcheck, verify the numbers, modify the c file, compile the hex file, flash, test. Tedious to be sure, but what you end up with is a means to access hidden modes and useful features like battcheck, bike strobe, etc.

Do you suppose there is a need out there that I can fill?

Sorry, I don’t really do hardware. :slight_smile:
(and this was already answered above)

Yes.

I actually did this already in my “cypreus” firmware, only it uses the technique to pseudo-regulate moon mode instead of turbo… and it uses PFM instead of PWM. But the basic method is still roughly the same. Feel free to try it, modify it, etc.

I haven’t actually tested STAR much, only the derivatives I’ve made. It sounds like the MCU is getting useful voltage readings, but either the power supply or the firmware is doing something unexpected.

It was already mentioned, but for LVP tests I have to leave the amps cranked up to force CV mode instead of CC mode. I’ve never had any issues getting results this way, so I get the impression it’s more likely the firmware… especially since the batteries behaved strangely.

Also, it was brought to my attention today that I forgot to tag projects with LVP to make them easier to find. So, in the near future I’m hoping to go through each project and actually test the LVP so I can tag the ones where it works. It might take a little while though…