Wight, that made so much sense… but no go same behavior. I have 4 modes defined, none of them 0 modes so as to prevent MCU shutdown. Looked at the code around the line above and that really looked right.
Oops, sorry. I didn’t notice line 409 sleep_until_switch_press();
So here are a couple of things:
- I don’t see why you need line 409 for your application.
- Note the first
ifinside thewhile(1)loop - that’s a problem for you I think. Remember that there’s a difference betweenmode_idx==0and any modes actually defined as 0 (eg PWM=0/255). This firmware is designed around havingmodes[0] == 0… you’ll probably have to iron out a few more little things. - With that said… I hacked it up a little. I removed line 409, I removed the offending IF statement I mentioned above, I removed the IF statement and actions from 435-439, and I changed the initialization on line 411 as described previously. It’s not a great hack, but I think it’s probably going to work for you. STAR_momentary_v1.6w1.c
I got dual switch controls fully working in Narsil a while back. I basically merged the two different firmware versions - best-of-both, post 729 here for latest source code and manual. Not to keen on enabling the tail switch for mode changing though - don't understand the usage scenario. It's great for a power lockout in certain lights, but Narsil has a built-in sequence to lock-out the e-switch, just like commercial lights now (I think mine is better of course 
), and the CPU drain in power saving mode is pretty darn low.
I think you might find when you merge the capabilities of clicky and e-switch firmware (without cutting features), you are out of memory in a 13A -- that was the original reason why I went with the 25's and above.
What is the drain in an eswitch light using the ATtiny mcu's?
Is the power saving mode the same between the 13A & it's bigger brothers?
Ahh, I believe it’s the same between MCU’s. Think power-on #’s are higher cause of running at 8 Mhz, not 4.8 Mhz. Not sure of the exact #’s, but I’ve had 85 based lights sitting for weeks/months on sleep mode. Just going by what others measured/said - been mentioned several times, many others know off hand, sorry, I can’t recall and never measured it. I did recently measure the running MCU with the indicator LED on, then saw it drop to about 1/2 when power saving kicked in. I delay the power savings - normally 10 secs, but when in a low battery state, I keep it running for 6 minutes to periodically flash the indicator LED to show the battery is low, then when it finally goes into power saving mode, I turn off the indicator LED to keep the light alive longer.
Ok, so very close… the tail cap switch does start the light in the lowest mode. But the modes do not switch… I am not at a real computer at the moment, on a laptop with cell tether for network and it is really slow. I appreciate the effort! Really! This is coding over my head… I did not expect to have a problem with simply powering down the MCU.
Thanks Matt
Heh, does a long press work? I think I see what I overlooked. EDIT: no that’s not it, duh. EDIT2: maybe it is, that’s why we shouldn’t do ugly hacks. Check the long press.
This was bugging me so I did some measurements this morn.
Convoy L4 w/13A FET driver: 0.299 mA (139 days to drain 1.0 Ah)
Stock EE X6R: 0.56 mA (74 days to drain 1 Ah)
ZY-T11 clone running a ATTiny85 w/Narsil (Indicator LED Off): 0.326 mA (128 days to drain 1.0 Ah)
ZY-T11 clone running a ATTiny85 w/Narsil (no Indicator LED): 0.302 mA (138 days to drain 1.0 Ah)
Measured a couple other 85 base lights all in the same neighborhood.
Is that from the MCU alone? Or is there perhaps also a voltage divider with resistors of a few Kohm only? Maybe I’m an idiot for believing any of the numbers but the spec sheets for both the 13A and the 25/45/85 claim about 5 µA in power-down mode with the watchdog timer running and one tenth that without. What you’re seeing is nearly 100 times more so something must be off (spec, hardware, firmware).
See over here . It’s not quite what you want as I modified it for pilotdog68’s triple channel driver but it would be easy enough to add a few ifdef’s to make the pin 3 turbo optional. As it is now, it would still work but without a useful turbo timeout. Oh and it isn’t tested yet so it might not quite work at all 
Dunno, it's actually measured off a full up flashlight at the tail using either a wight v009 FET+1 driver or a MTN-17DDm driver, on both a Fluke DMM and a UNI-T UT50B DMM. No watchdog running, just the e-switch will wake it up. No idea if this is the right way to measure it or not. Again, I'm no expert at this stuff at all and don't claim to be. All I did was set the meter to read DC milliamps, moved the DMM lead to the connector marked for mA's, so I think I did it right?
If my measuring method is somewhat correct (no idea), then at least it proves our custom boards and firmware draw less amps than say a stock Eagle Eye X6R.
I can also see it step down when the power saving mode kicks in. I delay it for 10 seconds after turning the light OFF (PWM=0). For example, the ZY-T11 clone with no indicator LED was at 4.91 mA with the MCU running, then dropped to 0.302 mA after 10 secs (sleep mode).
Edit: did A few more tests of stock Olights, SWM, and NiteCore and it's interesting. These are much lower in power saving modes:
Olight S15: 0.001 mA, Olight S1: 0.002 mA
NiteCore MH20: 0.027 mA (button LED blink off), 0.061 mA (button LED blinking enabled)
So, there is something goin on here - why these lights are so much lower in standby than our designs. I thought we can't do any better in firmware (sleep mode with only the e-switch configured to wake it up), so would the 2 voltage divider resistors be actively draining power from the cell?
Edit #2: Again, not sure bout this, but using V = I * R, for 4.2v I calculate the 4.7K and 22K resistors in series would eat 0.157 mA. If so, that's bout 1/2 the current I'm measuring. Partially explains the amps draw at least.
I’m no expert either but I think you have a reasonable method, as long as your DMM is able to measure that low (it looks ok by its spec sheet). I don’t know what RMM actually puts on the MTN-17DDm but his “FET+7135 DIY kit” has 4.7k and 19.1k resistors. So that’s about 24k between GND and VCC, meaning around 0.18 mA drain for 4.2V even if you rip the MCU off the driver. I think there was talk in wight’s driver thread about increasing these resistors for this reason but I don’t remember if it went anywhere.
Edit: Ok so you beat me to it :) But there's still a bit of current missing. Could be the firmware not shutting down everything it should. The missing current is about what the spec sheet gives for a idle MCU (vs powered off), or roughly between 0.3 and 0.4 mA.
I have a question about the STAR momentary firmware offered as an option on the mountain electronics FET+1 7135 driver. I have not gotten to the point of modifying FW code, so this is just a question about what I would get from mountain electronics.
I’m interested in having a very low moonlight. Am I correct in thinking that the moonlight mode and low modes will use just the 7135 chip? If I was to do the custom mode levels, at which PWM % level would the output switch to just 7135 output?
I’m trying to understand the user interface. This is my understanding from what I’ve read.
From off:
short click turns on to lowest mode
long click turns on to highest mode
From on:
short click moves to next higher mode
double click moves to next lower mode
long click turns off?
Is this correct?
Thanks.
Thanks for being bugged 
I tried to measure the drain, but realized I did not have the correct equipment to measure that low.
If Halo’s idea is implemented using the internal vref, then we should see most of that drain gone.
The FET & 7135 are controlled independently, so you can set whatever value you would like in the firmware for each, or a combination of both.
Important Note on this parasitic drain issue - it's being discussed in the 25/45/85 thread here, and they are mentioning the diode, besides the resistors, we use adds to the parasitic drain as well.
I did the tests. First removed the diode, bridged the pad with solder, and saw absolutely no difference in the parasitic drain at all - zero, nothing. Still doing in the 0.30 to 0.32 mA range.
Then I pulled the 22K resistor. The light acted kind of weird, because I didn't re-burn the MCU with firmware not supporting LVP. Anyway, it would settle down, and go into its sleep state. There I measured in the 0.16 mA range, which is about exactly what I expected - it went to half the draw, as calculated from the resistor values.
I've been looking around a lot on the forum, but can't get a definitive answer to my noob question..
I'm planning to build my first triple XPL HI in the DQG tiny 4. Can the BLF driver
be used to flash the STAR momentary firmware to and use it with the e-switch?
Then do I just connect the e-switch to ground and MCU pin 2 (PB3) and should be good to go? Or does it have to be piggy backed?
Or is the LD-2 driver the one to go for?
I already have the BLF driver.
I'm sorry if this is in the wrong thread, but help is much appreciated!
The DQG Tiny 4, reviewed here (https://budgetlightforum.com/t/-/36824), has no room to swap drivers. The LED is mounted on the driver itself to save space. Unless you know a method of doing so, I sure don't know how it would be done. These super compact lights make modding/upgrading difficult, to say the least.
Thanks for your reply!
Firelight2 already dit it with the tiny 3
DQG tiny 3 mod
Since the triple carclo optic is shorter, there is a few mm to play with.
The tiny 4 unscrews really easy, just might need to machine some parts out of the head.
It’s not going to be easy, but I’d like to attempt it.
I already modded a few P60 dropins and a thrunite TI with the 10DD driver from RMM with the XPL Hi. This is a nice step up No guts, no glory.
Since the heatsinking will be “marginal” at best, learning to flash and adjust the settings would be a nice extra skill to learn.
I’ve got all the parts inbound, but can’t find out about the BLF driver and momentary switch options… :question: