NarsilM - configurable e-switch firmware for Multi channels, v1.3

The only way I see 'byInitADCTimer' is undeclared is if you commented out VOLTAGE_MON:

#define VOLTAGE_MON // Comment out to disable - ramp down and eventual shutoff when battery is low

Is it commented out? Commenting out disables stuff, but not everything I see. I'll have to see about fixing that. I've never built firmware without LVP, so not sure why you'd want to do that.

I commented this out as I thought its ok when I enable R1/R2

one error still there
Severity Code Description Project File Line
Error ‘TIMED_STEPDOWN_SET’ undeclared (first use in this function) NarsilM B:\Bilder\Export\Flashlight\NarsilMulti\NarsilM.c 1522

Message each undeclared identifier is reported only once for each function it appears in NarsilM B:\Bilder\Export\Flashlight\NarsilMulti\NarsilM.c 1522

Ok, so far so good.

The TIMED_STEPDOWN_SET is defined in the RampingTables.h file. Could it some how got deleted or commented out? It's needed. I see it's there for two 3 channel table definitions, so should work. Did you add in your own table? If so, maybe you left out the TIMED_STEPDOWN_SET #define?

I just copied that ramping table I posted above in the ramping table file

it seems that in previous Narsil it was defined as TURBO_DROP_SET

changing it to TIMED_STEPDOWN_SET compiles the project

one thing for 2S LVP over R1/R2 maybe do automatically ignore the diode compensation?
I got there an odd pheonmen that SD is set 0.1V per cell below ramp down, but its a bit over 0.2V per cell above

I also discovered that the modeset file has for triple channel has only 7 modegroups, thats not like the 2 channel with 12 modes that are described in the manual

I dropped in your triple (8x7135) ramping table last night, downloaded into a Lumintop SD26 and a Manker U11. Looking very good, better than mine. There's still slight pauses at the channel transition points, but I haven't been able to completely eliminate that in the past. I had better luck with the 2 channel ramping table. I haven't been able to figure that out on the triples.

I see it's not documented, but a quick search will tell you the D1_DIODE setting is only used in 1.1V ref method (no R1/R2), and not used at all if you are using R1/R2. When using the R1/R2 resistors, look up tables are used to convert the AtoD readings to a voltage level.

I don't know what this means: I got there an odd pheonmen that SD is set 0.1V per cell below ramp down ??

For mode groups, yes - only 8 mode groups for triple channel configurations - I stopped there. I'll have to re-visit this. My priority has been for the two channel projects.

Of course in defining mode groups and giving them some sort of % output rating, it gets pretty impossible to be accurate for the multitudes of possible hardware builds out there. I based the percentages on approximately 1,500 lumens output on the full FET. Of course on a full FET, a BLF Q8 can do 6,000 lumens, while the OTR M3 does only 1,400 lumens, or my 16X super light can do 37,000 lumens. A max level of a single 7135 is ~10% (150 lumens) given the max level on the FET is 1,500 lumens, but it's only ~0.4% on the 16X super light.

In triples, it's worse because of the additional bank of 7135's - it could be 8 7135's, or 6, or 12. You could also stack a 7135 on the single 7135, so that will throw off everything as well.

In your case, you are building the driver so you have a canned set configuration, and it could be documented accordingly. I can't write a manual for every possible user of the firmware. For ratings of % output, even you can't define that because the modder buying your driver is the one that knows the light design - what kind of LED's, how many LED's, cells used, etc. I really don't want to get into writing manuals for every possible modded light out there.

Things were much simpler back in the day of straight use of one channel of 7135's.

I set
#define BATT_LOW 31 // Cell voltage to step light down = 3.0 V
#define BATT_CRIT 30 // Cell voltage to shut the light off = 2.8 V

on 2 Channel NarsilM 2S LDO this was tested on 6 drivers
ramp down voltage= Batt_low was 6.33-6.37V
SD voltage=Batt_crit was 5.87-5.9V

with this numbers I expected 0.2V between ramp down and shut down in a 2S light

if doing a ModeSet table for all lights
I would simply not use % levels that are related to the max light level, as you said it depends single LED or quad light build

I would just say this mode has 50% of 7135 bank
or another level 100% AMC bank+50% FET

for triple Modegroups I just added the 5 special modes you got in 2 channel and manual as well
so the triple channel is then consistent with the manual, easier to add there some code than doing different manuals for 2 and 3 channels

// #8: 3 modes (10-25-50) ~10% ~25% ~50%
PROGMEM const byte mode7135Set8[] = { 255, 255, 255};
PROGMEM const byte mode7135sSet8[] ={ 0, 110, 255};
PROGMEM const byte modeFetSet8[] = { 0, 0, 0};

// #9: 3 modes (2-20-max) ~2% ~20% max
PROGMEM const byte mode7135Set9[] = { 40, 255, 0};
PROGMEM const byte mode7135sSet9[] ={ 0, 40, 0};
PROGMEM const byte modeFetSet9[] = { 0, 0, 255};

// #10: 3 modes (2-40-max) ~2% ~40% max
PROGMEM const byte mode7135Set10[] = { 40, 0, 0};
PROGMEM const byte mode7135sSet10[] ={ 0, 200, 0};
PROGMEM const byte modeFetSet10[] = { 0, 0, 255};

// #11: 3 modes (10-35-max) ~10% ~35% max
PROGMEM const byte mode7135Set11[] = { 255, 255, 0};
PROGMEM const byte mode7135sSet11[] ={ 0, 170, 0};
PROGMEM const byte modeFetSet11[] = { 0, 0, 255};

// #12: 4 modes - copy of BLF A6 4 mode
PROGMEM const byte mode7135Set12[] = { 20, 230, 255, 0};
PROGMEM const byte mode7135sSet12[] ={ 0, 0, 200, 0};
PROGMEM const byte modeFetSet12[] = { 0, 0, 0, 255};

Ahh, I see the problem. In setups.h, it says:

#ifndef VOLT_MON_R1R2 // if using R1/R2, change the LVP settings in the calibration header file
#define BATT_LOW 30 // Cell voltage to step light down = 3.0 V
#define BATT_CRIT 28 // Cell voltage to shut the light off = 2.8 V
#endif

So if you use R1/R2, you have to set the LVP voltage values in the calibration header file: tk-calibWight.h

I forgot about this. These might not be so simple to move to the setups.h file, but I should have documented it more clearly.

The settings currently are:

#define ADC_LOW ADC_32 // When do we start ramping down
#define ADC_CRIT ADC_30 // When do we shut the light off

Edit: For the mode set levels, I thought about that but for the end user, it sure would be confusing. Guess it all depends who the NarsilM reference manual is targeted for - a user or an integrator/modder.

ok got it with the LVP settings

to get the 3 channel modes to match the manual you can add the 5 modes,
I am sure some more code lines need to be changed to get it to 12 from 8 modes

of course if people want to adjust the modes for their lights to match they have to edit the values for the channels,
but at least the modecount should be the same on all version

Yea, that's what I'll do - add the mode sets for the triple configuration to get it back to 12.

I pm'ed you and The Miller about the mode percentage definitions. It's sort of a big deal for the Q8 -- dunno if it makes a big difference but the the % values are all off considerably. Hoping to just update the manual for the Q8 (separate manual from the NarsilM manual).

fot the triple build its probably better to write the mA for the 7135 modes and the current plus % of the FET

BTW, when the Q8 code is completely finalized, could you save a copy of what was sent to Thorfire? I’d like to keep a snapshot of the exact release code in the repository.

Sure, hopefully I'll know when that happens. ThorFire is just not responding for a while now...

Is it possible to get a normal non LDO TA board to do 1 channel NarsilM? I want to build a 2 cell L4 convoy with mtg2.

UTorch UT01 has that special engineer mode, where you can set your moon mode by selecting from a selection of three different level options in each of the regular modes, very neat to be able to set your moon all the way low or up two slight increases and then go on to the next regular mode and choose out of three levels there as well, and as it is for each mode in that light, real fun, this UI is just spectacular reading, sure would love to use it.

Possible, yes. DEL has a board specifically designed for the L4 though, 2 channels, though not sure of zener/LDO support. I assume you want a zener, not LDO for some reason.

Whack it on the table a few times and
see if it starts working …. oh, wait ….

Yes I wanted to use one I already have, if I can. 2S Zener mod fet only 1 channel 26mm TA. Can it be done? I have no problem air wiring a pin if need be.

Boy, just don't have time right now, but it certainly can be done in firmware, fairly simply I believe. TA puts the FET on pin #3, normally it's on pin #6 for single channel or two channel drivers. So it's doable - could re-assign the pins, build NarsilM for one channel, and good to go. It would have the ramping table and mode sets. Not sure how they all would work out for you, but they can be tweaked as well.

Might need some code mods, not sure. The single channel config for NarsilM is set for pin #6, FET or 7135's.

NarsilM is updated in my repository.

Also, I tested it a bit… though I made no attempt to test thermal response or the indicator LED (I have none).

I don’t think I found any important bugs, but here are some possible smaller bugs:

  • Ramping UI:
    • After version readout, another double-click appears to go to turbo? (then another double-click to strobe) Sometimes instead of turbo, it’ll blink once at maximum then turn off, and a double-click still goes to strobe afterward.
    • Moon is separate from the ramp. (might be intentional?)
      • With moon set higher than default (PWM=7), I see odd behavior during long-press-from-off: It comes on initially at PWM=7, but if I keep holding it, the light drops to a lower level and ramps up.
      • With moon set higher than default, I can still ramp down to PWM=3, even if it’s lower than what moon is set to.
      • With moon set to PWM=1 or PWM=2, moon can’t be memorized because it’s below the bottom of the ramp.
  • Mode Set UI:
    • Blinkies can get kind of “stuck”. To make this happen:
      • Short-click then click-and-hold from off to enter battcheck mode.
      • Turn the light off.
      • Double-click. It should go to level 2, but instead it starts blinking out the temperature.
    • Undocumented: After a steady mode locks in, a quick click then click-and-hold goes to turbo. (off then reverse, really)

The main things I’d change are some of the mappings from UI actions to state transitions. Those aren’t important, but here are some ideas:

  • Ramping UI:
    • Instead of double-click from turbo to strobe, do double-click from turbo back to the previous ramp level. This way it’s double-click to enter and double-click to exit.
    • Instead of triple-click to battcheck, do triple-click to strobe and quad-click to battcheck. This makes strobe immediately accessible from off, and puts strobe and battcheck on the same actions as Zebralight.
    • Instead of quad-click to lock-out, do five (or maybe more?) clicks to lockout.
    • In blinky modes, hold the button to navigate forward/backward through modes. Reverses the same way as ramping.
  • Mode Set UI: No changes.
  • Other: Possibly add a Baton-like UI which uses the Mode Set UI settings? Basically the same as Ramping UI, but with discrete levels instead of a smooth ramp.

I hope at least some of this is useful.

Darn, quoting your post mangles it up badly.... No time to fully respond right now but you got some very good points there, excellent feedback!!

Looks like might be 2 bugs and/or some unintended behavior. Other things are behavior as intended/designed.

Agree - the moon mode custom setting has some quirks to it, and how it's related to ramping. I was always well aware of it, just didn't get into working/thinking out something better.

But, really really like some of your suggestions - dang, might have to work on those real quick, but having no time right now.... Really like your suggestions on the 2X+ click changes... Not familiar with the Zebra UI - would be an advantage to have some consistency there though with it.