true
the first version button light would light for a few seconds at startup… I agree its a copy paste error that does not apply to the 2nd version…
I agree it is not safe to fool the charger voltage detector
thanks your thoughts
This would not be the first error I’ve seen on the Wurkkos website, so anytime it says something there that doesn’t seem to occur in reality, I think it’s better to trust reality… 
+1 to that: I’ve been experimenting with a 18350 tube plus battery instead of its ‘normal’ 18650 on my FC13 and there’s visible voltage sag and recovery as seen with 3C after some main LED use, even non-turbo: in advanced mode where it keeps repeating the voltage measurement until I click for it to stop, I can see it sagging down 0.2V and then coming right back.
1 Thank
Thanks for the very complete testing with your TS25! I presume this is with its default 21700 tube and corresponding battery, right?
This IMO could very well explain the differences we’re seeing in your TS25 behavior vs @jon_slider’s: a 18350 would have much more voltage sag than a 21700.
Also, there would be significant ‘looseness’ inside that 20350 tube (at least 2mm more) when using it with a 18350 battery, this could lead to the battery not being perfectly aligned with the contacts in the TS25 (specially at the positive terminal) which could aggravate and compound the problem.
@AK-Adventurist , can you please repeat your TS25 tests with a 21700 tube+battery and let us know how it goes? TIA!
That would be really interesting! I was thinking about some kind of adapter (perhaps 3D printed) that could be screwed/inserted into the flashlight head in place of the usual battery tube, and would be able to supply it with battery power (ie, positive to the head spring/stud and negative to the tube) while leaving the flashing pads accessible so we could connect an UPDI adapter to them.
Of course your idea of using an entire separate board is much cleaner and more manageable.
I do remember seeing a post somewhere (here in BLF? on a blog? can’t remember) by someone who did something similar. A quick search brought this up, it’s on the same vein but not what I remember reading: Adventures in TinyAVR 1-Series - #33 by gchart
I have the 18350 in a 3D printed spacer sleeve, its a press fit right now. 
But I will try it with the 21700, when I can get a chance. 
1 Thank
The datasheet is already pretty good at explaining how the ADC works. If you need a more generic explanation, I’m sure Google knows some good tutorials. Sorry, I don’t have a specific recommendation.
yes… though I dont know why a light with a full battery would unlock itself (mine doesnt). And I dont know why a light with a full battery would blink on standby (mine does not).
In any case, I hope you guys figure out the issues that cause those events, in other lights.
1 Thank
Is there a way to use Linghtning Storm or Candle Mode with Aux LEDs instead of Main ? If not i would love to see this on my Wurkkos TS10.
Thanks for the data, a press-fitting adapter around the battery does eliminate a possible misalignment issue.
There’s one other size-related possible issue I just remembered: when I started experimenting with my FC13 and its 18350 tube, its tail spring didn’t put enough pressure on the back of the battery to assure a reliable contact – so it failed the famous[1] “Maracas test” (turning on the light and shaking it as viciously/vigorously as possible makes it go off, or at least blink – as if the tube was briefly unscrewed and then screwed back again). So I had to pull on the spring end with pliers to force it to extend a little, and that fixed it (but not before the spring came out in my hand and demanded a lot of effort to get it back in place – and I’m still not sure it’s firm enough or if will come apart anytime).
So, I gotta ask: does your TS11 pass the Maracas test? If it does, then only the possible voltage sag issue would remain.
[1] term learned from @1Lumen: Nightwatch NS14 review | 43,000 lumens flashlight | 1Lumen.com
Thanks for the confirmation. Re: the weird behaviors you mentioned, a full battery could perhaps show a larger voltage ‘swing’ when demanded and produce … but it’s hard to know for sure, better to just try and eliminate it as a possible issue as me and @AK-Adventurist are doing right now.
1 Thank
Fixed… for real, this time. In the end it was just one missing character in this line. At least I thought so.
ADC0.CTRLA = ADC_ENABLE_bm | ADC_FREERUN_bm; // Enabled, free-running (aka, auto-retrigger)
Do you see it? The control register is set to the given value. But my changes to bring everything in the right order has moved one important line before this line:
// set the RUNSTDBY bit so ADC will run in standby mode
ADC0.CTRLA |= 1;
So first, bit 1 of CTRLA was set, then everything got replaced with the next line. This is totally my fault because previously the order was switched. Let’s clean this up, it’s not bad to set all control registers at one place because eventually it will result in the same outcome. And let’s use a proper definition instead of the magic number… 1… what?! Why 1?
#define ADC_RUNSTBY_bm 0x80 /* Run standby mode bit mask. */
D’oh! This can’t work, the ADC did never run in standby mode! Depending on the remaining instructions before going to sleep, it finished, or it didn’t.
To sum it up, here is my proposal that should fix this bug and cleans up control register setup a little bit.
--- a/ToyKeeper/spaghetti-monster/fsm-adc.c
+++ b/ToyKeeper/spaghetti-monster/fsm-adc.c
@@ -83,11 +83,6 @@ inline void adc_sleep_mode() {
// attiny1634
set_sleep_mode(SLEEP_MODE_ADC);
#elif defined(AVRXMEGA3) // ATTINY816, 817, etc
- // set the RUNSTDBY bit so ADC will run in standby mode
- ADC0.CTRLA |= 1;
- // set a INITDLY value because the AVR manual says so
- // (section 30.3.5)
- ADC0.CTRLD |= (1 << 5);
set_sleep_mode(SLEEP_MODE_STANDBY);
#else
#error No ADC sleep mode defined for this hardware.
@@ -133,10 +128,10 @@ inline void ADC_on()
ADCSRA = (1 << ADEN) | (1 << ADSC) | (1 << ADATE) | ADC_PRSCL;
//ADCSRA |= (1 << ADSC); // start measuring
#elif defined(AVRXMEGA3) // ATTINY816, 817, etc
- set_admux_voltage();
VREF.CTRLA |= VREF_ADC0REFSEL_1V1_gc; // Set Vbg ref to 1.1V
- ADC0.CTRLA = ADC_ENABLE_bm | ADC_FREERUN_bm; // Enabled, free-running (aka, auto-retrigger)
- ADC0.COMMAND |= ADC_STCONV_bm; // Start the ADC conversions
+ ADC0.CTRLA = ADC_ENABLE_bm | ADC_FREERUN_bm | ADC_RUNSTBY_bm; // Enable ADC, free running mode, run in standby
+ ADC0.CTRLD |= ADC_INITDLY_DLY16_gc; // Delay first measurement to stabilize reference
+ set_admux_voltage();
#else
#error Unrecognized MCU type
#endif
It was a combination of:
- not configuring the ADC to run in standby
- starting the conversion before configuring the delay to stabilize the reference
4 Thanks
Hey hey hey!!! GREAT NEWS!!! 
So I presume that you can no longer get the issue to happen on your TS11, contrary to before that change, right?
If so, first of all, CONGRATS!
And second, with your authorization, I would like to produce a full set of hexes incorporating it, both for TK’s pristine rev 725 and for it with my 8C mod.
1 Thank
The TS25 with the 18350 is compressing the spring over 3/8", its under good tension(assumedly perfect since this tube and cap combo are sold for a 35mm battery, just of bigger dia. )
My TS11 is always loaded with a 18650, I have no need for compact carry on a light that is never carried… Its very tight as well, probably 1/4" spring compression with its(currently) Sofirn SC18 tail cap(and body from a HD15).
I went back to a spring loaded tail cap specifically for testing this, for these reasons you’ve mentioned, and also, in normal use I have No tail spring in my TS11, (Nor on three other lights that run flawlessly) I’m using custom 3D printed tail caps, they are non conductive, so I use a custom flat metal end spacer, and small magnet to connect the batteries to the tube. That way it is tight tension directly to the battery.
If anything it compresses the plastic threads slightly to hold tension. Have had no issues there with anything being loose, but I removed this from the equation on the TS11 and went back to a stock spring cap to make sure a resistance difference from stock wasn’t causing the issues, and have stayed with it for all test since. But there has been no glitch/bug difference with either cap setup.
The TS11 will pass what I call a whack test, either slapping my palm with the light head, or tapping the workbench; no flicker etc… Have not bothered with the TS25, since I never questioned the battery tension there.
1 Thank
Thanks for reporting back.
Now that @SammysHP reports having fixed the issue (at least with the TS11), I’m waiting for his OK to produce new hexes incorporating his fix for all lights, then I will ask you to kindly test both your TS11 and TS25 with it and see whether any issues remain.
Stay tuned!! 
2 Thanks
Correct, seems to be fixed. Tried with different voltages and it’s running for 15 minutes without issues.
Sure, go ahead! It’s GPL after all and I hope that @ToyKeeper can merge it soon.
Next step would be to add better smoothing or a hysteresis because right now it alternates between blue and magenta every second…
2 Thanks
Again, congrats! You fixed something that has escaped a lot of eyes and minds, including mine!
I’m going right ahead and incorporating your fix and producing the two sets of hexes with them. Will again post links here when they’re ready.
1 Thank
One idea for that would be to use a “moving average” implemented by storing the last N (say, 3) measurements in an array, with the newest always replacing the oldest, and then using their arithmetic average as the final value. Maybe I will give it a try once I produce those initial set of binaries…
1 Thank
[quote=“SammysHP, post:467, topic:218045”]
To sum it up, here is my proposal that should fix this bug and cleans up control register setup a little bit.
```
```
[/quote]
This is failing to compile for a lot of lights (including all the Wurkkoses) with the following error:
</s> <s>avr-gcc -DCFG_H=cfg-wurkkos-ts25.h -Wall -g -Os -mmcu=attiny1616 -c -std=gnu99 -fgnu89-inline -fwhole-program -DATTINY=1616 -I.. -I../.. -I../../.. -fshort-enums -B /home/normal/mnt_-_src_-_flashlight/http_-_packs.download.atmel.com/Atmel.ATtiny_DFP.2.0.368/gcc/dev/attiny1616/ -I /home/normal/mnt_-_src_-_flashlight/http_-_packs.download.atmel.com/Atmel.ATtiny_DFP.2.0.368/include/ -o anduril.o -c anduril.c</s> <s>In file included from ../spaghetti-monster.h:62:0,</s> <s> from anduril.c:77:</s> <s>../fsm-adc.c: In function ‘ADC_on’:</s> <s>../fsm-adc.c:132:55: error: ‘ADC_RUNSTDBY_bm’ undeclared (first use in this function)</s> <s> ADC0.CTRLA = ADC_ENABLE_bm | ADC_FREERUN_bm | ADC_RUNSTDBY_bm; // Enable ADC, free running mode, run in standby</s> <s> ^</s> <s>../fsm-adc.c:132:55: note: each undeclared identifier is reported only once for each function it appears in</s> <s>
I presume you have a different set of AVR include files than I have here, where that macro is defined.
Anyway, I’m now having a closer look to try and fix it.