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
Oops, just realized VOLTAGE_FUDGE_FACTOR is used for the voltage divider (as you just said):
static inline uint8_t calc_voltage_divider(uint16_t value)
{
// 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.
yes but i would prefer the ADC 44 and 22 values to calibrate the voltage divider like NarsilM does with the TK.cal file
like I wrote when I change the fudge factor to –15 to get that 0.75V down the readout code bugs out it blinks 2 times then quits working
At last, two things I understand in this thread. 
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.
lone that light to a friend and tell them not to triple click. See how they bring it back.
I actually built the light for my best friend who hates my ZL (cause he’s never taken the time to learn the UI). I figured if I give him a light that works like mine he’d have to learn the UI and could then use my light lol.
Dunno, maybe TK has some ideas. I see the support for battcheck in Darkhorse but the memorized 50 hz thing is odd. Think'n fuses but works ok with Anduril.
Almost like it's treating the battcheck state as a mode, but the mode is busted some how. Probably something not configured right, not sure what.
Of course Darkhorse (new one) is based on the same FSM architecture. I built Anduril in Atmel VS 7. I had to rename some fsm c files because if I added them to the project, they would not complile. The .c files are treated like .h - files -- they are included in spaghetti-monster. I wanted them included in the project so I could do full prject searches. All should work though. Mine compiles smaller I believe, but I haven't tried running my build yet.
Oops. I went to test DarkHorse, and one of the LED wires finally broke off the D4 I use as my main test host. Will have to fix that later.
So I tried it on a FW3A. Seems to work fine. All I had to do was change one line, to include the hwdef-FW3A file instead of hwdef-Emisar_D4. The same could probably be done for the GT-Mini, though it won’t do anything with the button LED. It’d probably also be a good idea to enable BOD in the fuse values, to make sure it actually reboots when power is disconnected.
It may also be worth noting that 3 clicks goes to the beacon/strobe group, and 4 clicks goes to battcheck. It’s a ZL-style battcheck though, so it reads out the value once and turns off.
Just flashed onto my fet+1 set up and seamed to work. If my TA driver shows up today I might try it. Xmas stuff happening today
I’ll check my fuse settings and report back this evening (off to family time now), not sure if I enable BOD or not. Does anduril require BOD to run right? I used the same exact fuses I flash when I program anduril.
To clarify, I have no way to measure the frequency it’s flashing at so take that ~50hz number with a grain of salt… It appears to be slightly slower than once/sec so I just guessed ~50. It appears to be steady speed and always the same low brightness though, definitely the MCU outputting a timed pulse, not just random blips.
Also note this particular driver doesn’t have a switch LED so I can’t say anything as to the switch led’s behavior during the error.
Thanks guys!
could it be stuck in battery check. Mine seams to be about 1 flash a second, but it stops after 4 flashes.
I hope the code is fairly easy to read, understand, and modify. That’s kind of the point of FSM. I was aiming at making the code as close as possible to how people describe interfaces in natural language… like, “in this state, you can do these button presses to get these results”. So the code mirrors that, only in a bit more detail and with more punctuation.
Yeah, it’s a weird way to do things, but I didn’t want people to have to deal with object files and a linker. The build is complex enough as is.
Uhh, I see no problems with the FSM architecture per say, just will take some time for me to fully understand it. For me it's the events and states I need to understand better, as well as some byte saving tweaks here and there. It's all good though! It's pretty phenomenal what you did, and amazing that much functionality can fit in 8 KB, including PID and special blinky modes, etc. Would still like to see pursuit of the 16 KB MCU's with more I/O pins though. Would love at least 2 switches and ability to drive multiple output drivers. Of course it's more than firmware, but this FSM design should port well. There's been some work done on 16 KB MCU's but I think specialized, and unclear about how easy to re-program.
I plan on adopting Anduril, maybe split out my own version, not sure yet but gotta play with it. It's gonna be a challenge to keep it updated though because of the issues with keeping a Windows VS 7 config in sync. Hard for me to invest in Linux at this point. Funny, because I got the same issue at work - the NASA embedded guys we work with are 100% linux, lots of Python scripts everywhere, and we are a 100% win shop. We got Win Python tools working fine, but it feels kludgy.
These are the fuses I used
I’m just getting back into it but I’m gonna look into fuse settings now…
Edit I havent assembled the light yet but on my bench testing setup (with actual driver I intend to use) it’s now working!
Fuses are as follows
One thing I will need to look into is how to raise the minimum level, it’s to low for my hardware and L2 produces zero light which would be pretty confusing to anyone who wasnt very keen on what’s happening FW wise.
Thanks guys!
So according to that I had been trying to run the clock divided by 8 (low fuse 0x62) but have now changed to not divided by 8 (0xE2) however I did not enable BOD.
Would the clock speed difference alone cause issues?
For future reference do I find the answers to what I need fuse wise in the code or do I just have to know? I.e. How do I know to enable SUT0 and CKSEL1 and so on and so forth?
Btw the light is together and running!