The "stock" firmware is NarsilM, v1.2. Updated version than what came in the Q8, same baseline as the BLF GT. The UI mostly got outstanding reviews out of 100's posted between Amazon and Banggood on NarsilM, not to mention many accolades in video reviews, so it can't be that bad? Slightly better than the "lo-med-hi-strobe-sos" of an UltraFire?
But if you still do wanna upgrade, first challenge is getting access to the driver, then you'll need the programming clip/USB cable, then the latest hex file, probably from here: http://toykeeper.net/torches/fsm/?C=M;O=D. We mostly use AVRDUDE to do the download. There's some really good info already here on BLF somewhere of how to get the cable and software tools you'll need - hope someone else can chime in.
Ahh I see. Yeah it’s NarsilM is much better than simple old style control haha. Anyways. I’ve heard that the sp36 has glued board? And thanks for your answer !!
As I said two weeks ago, and as Tom said just now, the fudge factor is not relevant for a light which uses a voltage divider. Use the voltage divider method instead, by setting USE_VOLTAGE_DIVIDER… just like in the BLF GT cfg and hwdef files.
I had already the voltage divider activated from GT cfg
But at 3V per cell it reads 3.7V on the blinkout
the voltage fudge factor works to –10, but at –15 the voltage readout blinks 2 times then bugs out
I also wrote that the ADC values in the GT file do not change the voltage reading at all
those lines do not work I dont know where it takes place that the voltage reads so I could modify it
this bugs out the voltage reading, and i can not find any TK voltage file or so which calibrates the readings
Lexel - from exactly what you describe, it sounds like the USE_VOLTAGE_DIVIDER is not set, least where you want it to be set.
If ADC_44 and ADC_22 don't do anything, and VOLTAGE_FUDGE_FACTOR does do something, that only means USE_VOLTAGE_DIVIDER can't be set. That looks pretty obvious to me in fsm-adc.c, which is where the voltage readings are done. Pin assignments are critical of course.
no I get definately the reading from Pin7 as if I change the divider or input voltage the voltage readout differs
MCU is set on 5V LDO
that fudge also affects divider while the ADC 22 does nothing
it seems that somehow the divider resistors are read out but are interpretated by the 1S code
I use the original GT config(PWM values are from 1S overwritten) just copied the fudge factor in for testing,
finally editing it out and done it tweaking the divider
on the GT driver 2 weeks ago I did the same correcting the voltage readout difference with the fudge factor
after people said me that affects the voltage reading
{ // use 9.7 fixed-point to get sufficient precision uint16_t adc_per_volt = ((ADC_44<<7) - (ADC_22<<7)) / (44-22); // incoming value is 14.2 fixed-point, so shift it 2 bits less uint8_t result = ((value<<5) / adc_per_volt) + VOLTAGE_FUDGE_FACTOR; return result; }
Tricky thing is the AtoD should be 10 bits, but only 8 bit ADC voltage levels are used -- weird. DEL wrote some really good code for doing this, and I simply stole it (errrr copied it) for NarsilM. Don't muck with something that works, sort of thing.
Didn't check the math/bit stuff but the equation certainly takes ADC_22 into account - depends what units adc_per_volt is in.
It sounds like Lexel just needs to use ADC_22 and ADC_44 as instructed, and set the fudge factor to zero. Or perhaps set it to 1 to add an extra 0.05V, so that 3.89V will read out as “3 9” instead of “3 8”. That’s what it’s there for.
Yes - the fudge factor as used for R1/R2 is just a fudge. Least on DEL's drivers, Batt+ comes direct in to R1, so the diode is not considered. Some drivers had the R1 after the diode (think Richard's maybe?), and I had special handling for that.
-- Looks to me the values are linear - our tables do appear to be linear. Spot checked the 4S and 2S ADC tables in NarsilM.
Quick report on my failure running darkhorse on a gt_mini driver:
With lots of help from zeroflow I got it built and flashed (standard build the way its downloaded, no code mods) and at first it powers up and runs in all modes as it should but when I tried to check the battery it got stuck in a loop where all it does is flash at low power at about ~50hz, it continues to do this even threw a power cycle and the only button response it gives is when you hold the button it stops (turns off) but the moment you release it starts the flashing right back again.
Again this behavior is memorized and comes back immediately after a long power cycle (or just a power blip, doesn’t matter).
I reflashed it and started again with it working in normal light modes but if you do a triple / quad click (trying to check battery voltage) that puts it right back in the error loop and you have to flash it again.
I verified HW by running anduril (still working 100% perfect at this time).
Not expecting a fix as I know darkhorse received very little interest, just reporting my findings.
I’m going to try baton next (not today), will report back on it too.
