Or just add some status LEDs and use the Roche F6DD firmware. It keeps one status LED on at all times at about half power as a locator, plus the LEDs give you info about battery voltage under load (green/orange/red).
FWIW, the standby light is barely more than the MCUās parasitic drain. With the light completely off and the MCU in sleep/powerdown mode, the parasitic drain is 0.33mA. With the green LED on but dimmed, the drain is 0.36mA. So, it costs almost nothing extra to leave that slightly on.
Leaving the green LED fully on costs more though; then it runs at 1.23mA. And a lowest-possible moon mode on the main LED is even more ā it depends on the exact hardware used, but 5mA is a common amount for moon on a single emitter on a 8x7135 board.
For a 25R 2500mAh battery, that translates to 10.5 months of standby time with everything āoffā, 9.6 months with the green LED barely glowing, 2.8 months with the green LED fully lit, or about 21 days with the main emitter in moon mode.
Voltage measurements are not performed while the light is in standby. That would drain the battery faster and require removing other functions to make room in the firmware.
And I'm now using a 1.8K resistor on the green LED, your measurements were from one using a 1K resistor. Should be almost halved from that.
Nice ideaā¦ I like the green led. Just need something to let the user know his tail switch is on
Can the lower mod be little lower on that firmware?
I like moon mode to be very low.
Voltage measurements are not performed while the light is in standby but it remains with the color it was while was ON. So if it its red while it is ON, it will glow red on stand by.
The non-ramping version has a lower low (uses phase-correct PWM in levels 1 & 2): http://75.65.123.78/RocheF6/F6DD_v03/
FWIW, I finally added a battery check mode to my clicky-switch firmware (based on STAR). Itās what I use on my EDC lights, like a modded Convoy S7 or a CNQG brass beauty.
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/head:/ToyKeeper/s7/
This firmware has a lot of modesā¦ five solid modes across the full brightness range, three dual-level flashers, a heartbeat beacon, three fixed-speed motion-freezing strobes, two variable-speed strobes, and the battery check. Short-cycle memory to avoid the need to go through all the blinky modes when theyāre not wanted. Itās a lot to fit in just 1024 bytes!
Mostly, Iām just happy that I no longer have to remove the battery from my EDC to find out if itās ready to be recharged. 
Yeah, previously the STAR_momentary program shut down the output (went to sleep) when PWM = 0, but RMM had me change it so that 0 is a valid mode so that he can utilize the Fast PWM "bug". Going to sleep is entirely dependent on the MODE_PWM value for that mode instead of the PWM value. That feature is in the latest version of the program from Github.
BTW JonnyC, what is your view on STAR derivatives which no longer follow the main purpose of STAR? Is it obnoxious having that sort of thing here?
Iām wondering, because I love having STAR as a base for other firmwares, but I took out the star solder-based config bits to make room for tacos (er, more modes)ā¦ so it kind of misses the point of being simple, solid, and end-user configurable.
Awesome work Jonny. I still have to check out your changes Toy. But I came to a realization last night sleep lol
You donāt even need boards with the tiny13a. If you can modify the output on a buck driver you just need to glue 2 resistors (4 total) top and bottom of the tiny and wire it up to the existing FET and vcc to the existing mcu. Disconnect the eswitch from the existing mcu and cut the gate, wire your new pwm in. You would then have voltage monitoring (not sure this even works on a buck because itās series cells- probably better to stick protected cells) from the divider and full control of the fet.
Trying to find the cheapest solution to having a ~6a buck with modes on the Y3 Iāll have to try all this new stuff out when the next light gets here- takes awhile to get hereā¦
You could even add in a smaller fet for a second out on a lower amp light but it would add another 2 resistors, and you would have to be careful in programming so one is closed while the other is on. I think can do dual outputs (only one out at a time) like that for next to nothing and still have a 2-3s light. Is there a tinyavr compatible chip that does 4 out? Not sure if fitting 2 tinys in would fit yet for something like that 4 color XML. Or do we have to invest in the PIC equipment Cereal uses.
I think this is a great place to discuss derivatives. I'm assuming there are people out there that downloaded STAR and used it in stock form by configuring the options, even though the majority of the discussion here is about custom, one-off programs. I see this thread as just a continuation of Tido's original thread with a more configurable, perhaps easier to work with codebase to start from.
And yeah, the idea behind "STAR" was just that you could solder different stars for different options (ala NLITE), but the more features are added the less purposeful that feature is since the user will need to enable/disable so many options at compile time that they don't need the solderable ability. But I'll keep the name "STAR" just for consistency.
I could be the only one whoās having trouble with your posts, but Iād really appreciate it if you put some more effort into making your posts easy to read. They seem to be very stream-of-consciousness or something.
Iāll try to reply to what you wrote, but what you wrote may not be what you meant.
IN ORDER:
- Youāre correct about not needing a PCB for the ATtiny13A - itās just a lot easier that way. What youāre referring to is often called ādead bugā style wiring. As an example, hereās a picture of ImA4Wheelr doing it in post #176 of his HX-1175b thread.
- Why do you say 4 resistors though? You need 2 for a voltage divider andā¦ what? What are the other two resistors for?
- Correct, youāll generally use the VCC intended for the original MCU, regardless of whether youāre using dead-bug wiring or a child-PCB.
- You will not cut the āgateā signal. That term has a specific meaning and the gate signal / trace does not need to be modified for any of this. Instead you would modify the trace for the PWM signal.
- RE: the italicized stuff about voltage monitoring. Voltage monitoring will work fine as long as you choose appropriate resistor values.
- For buck drivers you do not directly control the FET, the buck controller does that. The MCU simply feeds the buck controller a PWM signal. The buck controller establishes a duty cycle where it turns the FET off part of the time - the PWM signal from the MCU tells the buck controller how much additional time it should turn the FET off for.
- Adding an additional, separately controlled [smaller] FET does not make sense with a buck controller. IMO it doesnāt make much sense for a DD driver either. Remember, the FET is not there to limit the current - itās there to be controlled by the buck controller. A FET with more on-resistance will simply lower the efficiency of the buck circuit, not lower the output current!
- Good news!
There is plenty of AVR hardware out there which can do whatever your heart desires. The ATtiny25/45/85 all seem to have 6 PWM channels. Theyāve also got other nice stuff, like additional flash space and a temp sensor IIRC. The ATtiny25 is available in the exact same package / form factor as the ATtiny13A-SSU we currently use. (The 45/85 are both very slightly larger.) We use 150mil or 8S1, the larger chips are 208mil or 8S2. Frankly Iām not entirely sure what the limit on actually using all those PWM channels simultaneously is. There are only 2 timers and our use case may [probably does] prevent them both from being used for PWM. If the Tiny25/45/85 canāt do 4x simultaneously in our application it Iām sure another AVR product can. For anything beyond the ATtiny25 youāll be forced to switch to a QFN style package. EDIT: hmmm.
My advice is to make sure youāve got both feet on the ground with your understanding of a buck driver. Read some stuff on the internet, look for simplified explanations. An animation of the various states used by a buck driver is probably useful. Once you understand how a buck driver operates youāll see the mechanism for limiting current. This will make it clear why adding an additional FET in the way you described is not a good idea.
Donāt be discouraged, keep working on it!
I know I know Thanks for posting, I was on my way to blowing something up tonightā¦ I just got all my parts in from digikey and dan sent a couple of old dd boards to play with (should thank him publicly for doing thatā¦ you guys are really cool). Let me research a bit more and when the light comes in- Iāll post a build on itā¦ Instead of filling up jonnys thread.
I do have a bad train of thought anymoreā¦ I canāt blame it on anyone, except maybe my wifes trying to poison me! nawā¦ it is what it is unfortunately :disguised_face:
Donāt sweat it, but please do proofread! Write, take a break, then read/re-read.
and LOL @ wife excuse
Check this page out for attiny differences. The attiny25/45/85 are code compatible with each other, but not exactly with the attiny13a. The 25/45/85 can do 6 PWM outputs (assuming you have the model with enough pins!)
It still seems to me that we should be doing most of our custom drivers with attiny25 chips instead of attiny13a. It costs a few cents more, but can do significantly more complex tasks. The extra ROM space alone would be a big help for making deeper user interfaces or adding end-user configuration options.
Iāve got some 85ās here which I plan to give a test run soon just as a proof-of-concept. Assuming I can get STAR running easily Iāll pickup some ATtiny25s on my next order from wherever.
I tried to make something which reacts to an e-switch like a Zebralight, but I ran out of room really fast. Perhaps Iāll try implementing the Olight Baton interface first instead.
There really is no reason not to go to the 25 for more advanced UIs. They don't cost much more and are pin compatible. Even the 85 will work on the same pads if you fold the leads underneath, if you need more space. Once we get the port to the 25, the 45 and 85 are the same thing, and if you want to scale up to more outputs, just move up to the higher pin count version and keep the same firmware.
Looked at that pin layoutā¦
It looks like only 3 outs on the 25-85ā¦ Unless you go with more pins. OC1B, OC0B, OC0A unless your using the same pin for 2 outs maybe?
That link is a good compare. It saws 6 pwm but wondering does that mean 3 outs with 2 per pin