How To Build a Flashlight With Perfect Modes (picture heavy)

That is true for 7135 based drivers, but there is only one AVR controlled boost driver I know of, the NANJG-112A. Unfortunately, this one is nowhere to be found anymore.

sixty545: Add these:

delivery date

dec.16 105 Attiny13

dec.28 105A PIC for the 5-pack (doh...)

@Tido: I'm more into 18650 lights anyway.

I wonder how difficult it is to build a reasonably good 3A buck driver (for XM-L on 2*18650) with a µC though...

So, what we have now on KD SKU S009742 is…
My 5-pack delivered last week was with PICs. Ordered them early this year.
Too bad, I’d much prefer atmels too.

The picture of the 5-pack SKU: S009835 at KD is in fact showing the 105A with PIC !

The picture of SKU S009742 shows 105 with ATtiny13.

I can tell because I have both and the numbers are printed at different spots.

[Edit:] And welcome, boffid !

A very good point. By looking closely at the pictures they are indeed different! One seems to have an empty place for a resistor (besides the mcu) while the other looks like having a cap and no place for resistor.
Time to order some singles perhaps…

Good news, everyone. Although I still haven't managed to teach the toaster to feel love, I made some good headway on the BLF-VLD-PIC front. I've flashed a NJG-18 with the driver code and the result was better than expected. The PWM frequency is high enough not to result in any visible flicker (somewhere between 500Hz and 1kHzh) and mode programming actually works. The lowest low isn't anywhere near of what can be achieved with the Atmel's hardware PWM, but maybe I can find a way to work around that.

On a side note, did you ever notice that short blink some flashlights make when the mode memory kicks in? I used to think this was a deliberate feature, but it actually is a result of the missing hardware PWM. Interrupts have to be disabled during EEPROM writes, so the interrupt driven PWM gets suspended.

Good news indeed.

Yes I saw the memory blink using the AK-47C. But the NANJG 105A also have memory snap-in after 2 sec. but don't blink!

Can anyone suggest why the Mr.Lite J4 driver will only strobe on 14500 (This is the same driver as the BLF AA-Y4E but starts on high. It works fine with NiMH, but not with 14500 where all it'll do is strobe. I'm probably going to replace the driver anyway since I accidentally dedomed the XR-E in it and swapped in a reflector and an XM-L but if a quick spot of solder somewhere can sort out the existing driver, it would be useful to know. I can't make it strobe with an NiMH.

I don't see any voltage monitoring circuitry on the board, so it's unlikely that the driver software detects an overvoltage situation. From the software's point of view, everything is fine as long as the MCU gets enough power to run. Maybe the boost circuit is broken and shuts down when it detects a too high input voltage, then starts up again, shuts down... and so on.

But this is just idle speculation, I'd need to prod around the PCB with some measuring equipment before I could say anything definitive.

That sounds like a lot of work.

If you want it for interest, I can send it to you once I've done a driver swap in the light.

Thanks for the offer, but it would probably just end up in a drawer and get thrown away in the end, when they ship me of to a retirement home. Forty years from now...

I received my driver from Shining Beam (which he ran out of stock of as it's no longer on his site). It's a NANJG 101-AK with 4x7135's and an Atmel ATtiny13A.

I have been having a hard time keeping up with all of the information here as I'm really starting out from scratch on any of this stuff. So before I even dive into the programming I need to understand how the circuit is setup. There is one capacitor (brown SMD at C1) and two resistors (R1 10k, R2 3k), along with a diode. Referencing this diagram from a similar driver, found in the first post of this thread http://www.candlepowerforums.com/vb/showthread.php?t=192206&page=1, it seems as though the capacitor isn't used to condition any signals but to possibly maintain power to the MCU if the battery disconnects for a slight second (it's not very big, so I don't know how long it could power it.

PB1 (pin 6) is used with PWM to switch on the 7135's to drive the LED.

PB2 (pin 7) is connected to R1 (which connects to Vcc) and R2 (which connects to ground). Is this used for low-voltage monitoring? If so, how exactly does this work? I can't quite understand how the resistors are hooked up and what effect they would have.

PB4 came soldered to GND I assume to pull the pin to low triggering the MCU to keep us in a 3-mode group. After removing the solder, the light had more modes, although I couldn't quite figure out what the sequence was (although I assume there are 3 to 4 groups of modes or something with the ability to switch in between).

So I guess my last questions are, what capabilities does this board have without modifying it? Can that capacitor actually be used to determine short clicks vs. long clicks? Can PB2 be used to determine voltage levels, I assume through ADC? And if so, how do I even know to look for on PB2?

Tido, by the way, I downloaded your code and I must say I am really impressed. I'm just learning C and bitwise stuff, so I can mostly understand it, but it is really well organized and commented. I think this would be a huge hit over on CPF.

- Jon

The diode provides polarity protection for the MCU, the capacitor is there to filter out noise on the power supply line. Its job is to stabilise the supply voltage in case of very short (< 1ms) voltage sags. It won't be able to keep the MCU powered for more than a few milliseconds, especially if it also gets drained by the voltage divider, which is what the resistors are doing.

Yes, the two resistors form a voltage divider. It is used to bring down the supply voltage into the 0V - 1.1V range, so it can be measured by the MCU's analog-to-digital converter. If you are interested in how this works, please take a look at the README, where I tried to explain things in more detail.

I would guess that the drivers from shiningbeam use either a custom firmware or the firmware found in the AK-47s. The famous stars are just connected to I/O pins and the MCU basically checks which pins are pulled to ground on start-up. The mode group is then selected on this data. You could try soldering other I/O pins to ground and see if the mode group set-up is changing.

The capacitor is much too small for that and besides, it would need very good fine tuning of the components used to get mode switching via brown out detection working. I gave it a try some time ago and got nowhere. If you want the short/long power off distinction, the only reliable way is to use the resistor-diode-capacitor circuit we have discussed earlier in this thread. Take a look at this post on how to do it in an incredibly beautiful way.

Thanks for your praise. Personally, I think it has way too much #ifdef'ed code blocks, but it is the only way to cram this much configurable functionality into the tiny program space. The comments are as much for my own sake as they are for others. This was my first AVR based project and it really helps to "mumble along" to yourself in this form, while trying to figure out how to do things on a new system.

As for the CPF, the guys over there are free to use the code, as is everybody else. It's open source, after all. But I'm really put off by the general sentiment and rampant pack mentality over there, not to mention the petty power-crazy moderators.

Tido, you’re awesome. Thanks for the detailed response! You answered all of my questions. I now understand that that the resistors are used to divide the voltage (down to 1.15v on a 5v source), I just have to try and understand how voltage dividing works – but I’ll figure it out.
I agree with your CPF comment, at least with the moderator issues.
Once my cable and programmer show up, I’m going to try out your code. I may try playing around with having the number of short presses you do put you in that mode number, but I’ll have to look at your code in more detail. Thanks again!

Well, I received everything that I needed. I assembled the USBtinyISP programmer, connected the clip from Ebay to the correct pins inside the USBtinyISP and connected it up to the ATtiny13A. The clip connected easier than I thought and avrdude was able to connect property to the MCU. Decided I would be gutsy and flash a compiled hex after changing a few parameters in Tido's code, and success - it flashed! I didn't think it would happen this easy.

I connected an XP-G mounted on a heatsink to the driver board, connected up a battery and gave it a shot. It turned on! (sorry, but I didn't even expect this to happen). I tried to cycle through modes, but it seemed to stay on one mode. The mode seemed like some type of SOS, but I couldn't notice any pattern. So I decided to program it again with the PROGRAMMABLE define disabled. Flashed it again successfully, but when I connected up the battery, the LED went on for a split second then cut out. Checked the connections, tried a different XP-G, and no dice. I reflashed it with the Simple.hex file, and no power. I think I may have somehow killed the MCU or something on the board.

I really rushed this, kind of taking a shotgun approach, because I knew the driver and LED were cheap and figured "what the heck". Shining Beam doesn't have this driver on his site anymore, but I should be receiving some other boards like them from DX in 1 to 2 years (ha). Once I get those I'll take things slower. I should really get a bread board with a switch to turn the light on and off as my jerry rigged way of doing it isn't the greatest for testing it out, let alone seeing if the mode setup will work out, and I can't install the setup into my Mag host until it's flashed with the right program and set to be installed for good.

Well, I will certainly do some more reading. I have a feeling I have to set some fuses and do some more complicated stuff. Right now, flashing it with the hex file from either Simple or Programmable result in the LED not turning on. However, it does turn on when flashed with Fixed Modes, although it's only running at about 100mA, so I assume it's starting in a low mode and is unable to switch to another mode.

My first guess would be the fuses. Please try using '-Ulfuse:w:0x79:m -Uhfuse:w:0xed:m' (Brown-Out Detection at 1.8V, 4.8MHz internal clock, Self-Programming and SPI enabled). If this doesn't work, you could try recompiling for ATtiny13A. Maybe the ATtiny13A is not that much of a drop-in replacement for the ATtiny13(V).

Thanks for help again Tido.

I read the fuses and they where lfuse 0x72, hfuse 0xfd. I set the fuses to what you provided, which changed the clock and a few other things. However, there's no difference in how the LED acts. I compiled your code in AVR Studio set for ATtiny13A, flashed the hex, and no difference.

I might just wait for the drivers from DX to show up and try those.

EDIT: Durrr...I didn't flash the eeprom :P Seems to be working now, so time to play around with some different options.

seems like more people are programming flahlights

http://www.youtube.com/watch?v=TZ5rtmIpjNw

I heard about a (hopefully better) C compiler for PICs, MicroC. The demo has a limit of 2KB - enough for the 12F629. Migh be worth a try.