Flashlight Firmware Repository

At a glance, it looks like it has off, medium, low, high. So, LVP stepping down goes high, low, medium, off. Yes?

You could either modify the logic for LVP… or throw out the idea of using mode_idx at all for step-down and modify PWM levels more directly. Not sure which would be easier. I prefer the second approach, but it’s harder to fit into STAR-based projects.

Yes, looks like you are right. I noticed your mod to the next_mode() function, and the seemingly odd mode ordering. You probably have to have a special prev_mode that's used for LVP only, skipping mode 1, or to make it more flexible, skip a previos mode that has a higher PWM value, but that's a bit more involved. Depends how much code space you have, and how flexible you want it to work.

You are still in the tiny world of the 13A with this driver .

Is there a different way I can order the modes to keep medium hidden but also lvp linear? Like, if I swap the order of low and Medium, can I get it to skip over medium in normal mode order? Like, “when switch is pressed: if mode is low, go to high. If mode is not low, go to low”?

I’m not too worried about jumping to the 25/85 because I like a very simple user experience. Though I did buy a 25 for my 7G3CS because I want the temp monitoring.

Well, lots of options. Like TK said, you could simply hard code LVP. I'd tend to keep the mode table in proper order so LVP works fine, but skip the next to last mode (med mode) in next_mode(). When LVP kicks in, it doesn't limit use of the higher modes, so normal nav still works and it won't be broken.

If you have enough room left, you can do anything you want. The only real limitation is ROM space.

Most of the logic you described seems pretty straightforward too. Just add some extra clauses to detect the mode and step down in different ways, and it should be fine. Or you could perhaps do it in less space by using a mode change table… like each entry would define what “stepping down” means from that mode. Here’s a rough idea of what I mean:

uint8_t modes = {0, 0, 0, 255};
uint8_t altmodes = {0, 255, 30, 255};
uint8_t stepdowns = {0, 2, 0, 1};

void stepdown() {
  mode_idx = stepdowns[mode_idx];
}

I suspect Tom’s suggestion would be simpler though. :slight_smile:

That works. How do I make it skip the next-to-last mode?

Something like this:

if (++mode_idx == (sizeof(modes) - 2))

++mode_idx;

if (mode_idx >= sizeof(modes))

...

...

Ok - you'd be adding the first 2 lines, and modding the 3rd line to remove the ++. This is all in the function: next_mode().

Hope I made this clear enough. Basically you detect if the mode is incrementing to the 2nd highest mode. If so, increment the mode index again.

I think I have everything working now. I haven’t actually tested LVP yet, but I don’t know why it wouldn’t work as the mode order is now back to “normal”.

Would one of you mind looking over it to make sure there isn’t some hidden screw-up that will cause me grief later? thanks

once again, mine is on the right, stock STAR is the left.
Diff check

edit: JK, now I’m back to having the problem that when power is cycled when in mode “0” it doesn’t come on in mode “3”. :frowning:
plot twist: So if I hold the button for 2.5 seconds it enters mode “0” (off). If I then remove power for <5 seconds, when power is reapplied it is still in mode “0” (no bueno). However, if I remove the power for >5 seconds before reapplying, it comes on in mode “3” as it should. Any ideas here?

There's something that's keeping power goin for 5 secs - no other explanation I can think of. Cap? Something?

Oops, forgot to update here.

That issue was on my “power supply.” I decided it wasn’t a big deal, so I installed it in the light anyways. Miracle of miracles, once in the light that weird behavior went away.

U mean a bench PS? Ohhh - if so, would explain the 5 secs shutdown... My bench PS is super slow on shutting down.

FWIW, I did some tests a while ago for the mem-decay method of detecting short presses. If I drain the OTC, it seems to take about 0.5s for the memory to decay. If I leave the OTC fully charged, it seems to take about 4s for memory to decay.

Just a thought. I don’t even know if you’re using that method.

It’s actually just a cheap buck converter I use to test drivers, but I have a omten switch in series anyways.

Hhhmmm. Something wasn't right bout that setup I guess? if it worked once in the light.

I’ve had other issues with it before, especially with turbo timers. Idk if it’s ripple or what.

For instance on this driver, I have the timer set to 2 minutes. Its 6*7135 (2.3amps). If I have my buck converter limited to a lower output, like 1.5amps, the turbo timer steps down wayyyy early, like 1 minute instead of 2. But if I don’t limit output on the “power supply”, the timer works just fine.

I don’t understand it, but I’m slowly learning that if something isn’t acting the way the firmware says it should, try it on a battery before freaking out.

I do my initial tests on a batt 90% of the time - an old TrustFire in a holder w/red&black wires ended with alligator clips. Sometimes if it's more risky, I'll go slowly up with the bench PS. I'm usually carefully continuity testing everything out first, so not much risk applying power.

Oh, on a variable current / voltage power supply, with current limited, the voltage can do some weird things. You can only limit one or the other, basically, and the other will adjust itself accordingly.

I’ve been finding that even voltage calibration seems to work better with a battery than with a power supply (and a DMM to confirm voltage in real time).

Do we have a Yezl Y3 Star firmware - el switch and a tail switch, several modes switched through the el switch and an offtime memory?

I do. On the 25/45/85 thread, have a dnld link but it requires a 45 or 85. Blew past 2KB code, so the 25 won't cut it. It's also fully programmable (64 possible mode combos) and I posted an instruction manual (2 pages) on it's operation. Didn't upgrade a Y3 yet, but I'll have to do 4 of them shortly. Have the dual switch (e-switch/power) version dnld'ed in a X6R and works well so far.

Great, but can it be applied on wight`s A17dd ver 0.44 and tinny13? The last Y3 i modded was with that driver, el and tail switch and TK Ramping UI table firmware, V6 1D dedomed and 210k cds, came out exellent but now i need the firmware i mentioned