Does Tom E’s version even have memory? (The stock JonnyC versions which have memory all use wear leveling to prevent this issue from appearing.)
I think you wanted Pin 2 & Pin 4.
I’d ask Dr. Jones if you paid for it. Without the source, how’s anybody going to fix it but him =\
If that’s Tom’s eswitch. He uses PB3 (mcu pin 2) as the e-switch default . It shouldn’t flash when the power gets connected though.
*Yeah wight went over Jonnys code and seen the wear leveling. murphys law kind of guy
I’m not sure which firmware you used there, but I make a point of including a brief flash on boot on all eswitch-only firmwares I make. It lets me know the power is connected and the chip is booted, and any issues afterward are therefore some other type of problem. I don’t think I’ve seen this behavior on other people’s firmware though, unless you count Zebralight.
However, e-switch firmwares generally won’t make light just because they have power. Getting light requires activating the switch, so the switch must be wired up correctly. If it won’t activate, I’d check for switch issues.
This was my problem. Thank you.
That said WOW
Oh my GOSH>>>>>>!!!!!!!!!!!!!!!!!!!!!!!!!
Let it be know that from hence forth
JonnyC and TomE are legends of flashlight
history FOREVER!
That one click OFF is the most un sung hero of the world. OOOOOOOH how I have dreamed of this. No looooooong press for OFF. NO cycling through stobe, but STILL IN THERE!!!!!!!!!!
Had I written a Christmas list I could not have asked for a thing more!
I guess I’d better try it then 
Coolabs came in today, finished the blfdd light. I noticed something interesting putting firmware in my light. I looped this line in making the beacon off while monitoring button clicks.
PWM_LVL = 0; _delay_ms(50);
I assumed it would keep the FET closed, but it didn’t. When you loop the above it makes very little amount of light on fast pwm 
You can put your face into it and see the die clearly. Maybe someone is interested in that- thought it was pretty cool. If you want to try it, code is at the bottom. Hold the button for ~3 seconds to get beacon and you’ll see in between pulses. Could be an even lower moon
It’s a known “bug” that PWM=0 will still produce a little bit of light when using fast PWM on a high-powered driver (FET, or 32x7135). In phase-correct PWM mode, this doesn’t happen.
I’ve been meaning to tweak my ramping UI firmware to take advantage of this, but have been too busy so far.
Well known to you It’s kind of cool, can get something lower than PWM 1. It does turn all the way off with PWM 0 least on mine. But looping it on 0 causes the lowest moonlight and it’s not ghetto looking either, it’s a nice light up of the emitter. The only time seen this low was playing around with the buck drivers sense resistors, got a similar output.
Maybe running as default when you turn on the tail switch instead of sleep?
That would let whoever has the light know they left the tail on while still being almost parasitic. Just enough light to keep the ring glowing too maybe.
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.