Flashlight Firmware Repository

This is what my mode sets look like

PROGMEM const uint8_t modegroups = {

//1, 2, 3, BATTCHECK, RAMP, 0, 0, 0,

1, 5, 8, 10, 0, 0, 0, 0,

2, 5, 8, 10, 0, 0, 0, 0,

6, 0, 0, 0, 0, 0, 0, 0,

6, 0, 0, 0, 0, 0, 0, 0,

6, 0, 0, 0, 40, 0, 0, 0,

6, 0, 0, 0, 0, 0, 0, 0,

ONE7135, TURBO, RAMP,0,0,0,0,0, // 7: special group A

RAMP,BATTCHECK,6,ONE7135,TURBO,0,0,0, // 8: special group B

RAMP, 6, 12, 19, 29, 40, 0, 0, // 9: special group C

6, 19, 32, 0, // muggle mode, exception to “must be 8 bytes long”
};

You can reduce the number of mode groups instead of just repeating the same one, it would be a lot easier to select the one you want later that way. Or put some other completely different mode groups in there just in case you want something else later, thats what I do.

Also there is no need for a 1 in the mode groups unless you just want it that way. 1 is the same as moon mode, you can simply enable moon mode to allow for a 1 mode if you desire.

So the first entry in my ramp table will be the moon mode? I was wondering how to edit that…

In any case this was my first try to get it working. Any ideas why I would be getting the behavior I posted earlier?

Yes, moon mode is the first entry in the ramp table and Turbo is the last.

You can define the one7135 and all7135 channels as well to make it easier to keep track of in the mode groups as well.

What does your ramp table look like? Also I would try using the OTC calibration that TK has in the repo, assuming you are using an X7R 1uf cap. It has worked fine for me so far.

Been look'n it over. Your first level is PWM value of 2 on the 7135, so probably won't work on a 380 mA 7135. Are you using the 350's?

Can't find anything to produce the results you are getting, but I can't follow the logic. "modegroup" defaults to 8, and not understanding how that works through the count_modes() function.

Your #define of ONE7135 seems to be wrong, should be 7 not 4 for your tables, if I understand that.

The 5th mode group seems to wrong with an entry of 40 in there.

I think you would have to take baby steps, one thing at a time, if you didn't do this already. First try verbatim bistro-tripledown as-is, and if all good, try your mods.

To me, this doesn't make sense. It appears it will power up using mode group #8, which is a special test mode set, "special group B"

Ditto, try bistro as is first then start making changes.

okay :weary:

It’s my own fault this is so frustrating. I put the OTC in a terrible spot on this driver so every reflash is a struggle

In any case I don’t have a “ONE7135” mode. I had it commented out originally and that gave errors, so I just let it be there. I don’t plan to actually use it.

Which driver? The tripledown?

X2R TripleStack

edit: so the unmodified .c file seems to work fine when compiled with my modified calibration header. The moon level is just too low to make my abused XM-L light up with the 380 7135. Also my LVP values are apparently exactly 0.1v too high.

So I guess I’ll go back through and clean up my modified mode groups, the error has to be there somewhere.

I think I see the problem. I think I am getting into programming mode, I just can’t see the blinks.

Can you tell me how to read this bit given my ramp size is 10?

That would be 2 for a RAMP_SIZE of 10, which I think you have there. Division there truncates.

So PWM 2, or ramp 2 so PWM4 ?

It's used as a parameter to set_level(), so it's an index into the ramping tables, not a PWM value direct.

Also, it's used in the function toggle(), where its multiplied by 3/4, resulting in a value of only 1! So, in one case it's a ramping level of 2, another case it's a ramping level of 1.

Ok, think I see what's goin on, and why you are seeing 3 modes. You are using mode group 8, and you have it configured as follows:

RAMP,BATTCHECK,6,ONE7135,TURBO,0,0,0, // 8: special group B

So, the first 2 modes are accessible thru reverse navigation, therefore your first mode should be level 6, the ONE7135 is your 2nd, and TURBO your third mode.

TURBO is defined as max FET.

So, you should see levels 6, 4 then 10, but you are describing/measuring what appears to be 5, 6, then 10? Maybe?

Are we sure moon is just ramp level 1? Because I have tried multiple LEDs and they should be lighting up at PWM 3, but I’m getting nothing.

edit: I think the firmware is working fine. The issues I’m having seem to involve the differences between the 13a vs 25, made worse by my not having any 350ma 7135’s on hand

Yea, in the function count_modes(), if you have moon mode enabled, it adds it as level 1.

Yea, I'm always using 350's now - you would not believe when I'm seeing using PWM value of 1 with these 350's - amaz'n the LED lights up, but oh so very very low... Not sure if this is only working with our new driver design - DEL's changes, or not.

Well the same driver (with 380’s) was perfect at PWM 3 on the 13a, it even lit up at PWM 2. But with the 25 it takes PWM 5 just to light up, a more usable level at PWM 6.

………………

Can I change the order of programming mode?

I want:

  1. Muggle
  2. Mode group
  3. Memory
  4. moon
  5. Temp Cal
  6. medium press
  7. Mode order
  8. Reset

edit: figured it out. I think I’m finally happy with it. With all of 2 mode groups! :partying_face:

Odd, I also get it to light up fine with PWM 2 on the tripledown, I only use 350 7135’s, never saw the point to the 380’s honestly. Twice the price for an extra 30ma?

Maybe it is the stacked design?

it was working fine on this exact driver with 3pwm. All I did was swap the MCU. Maybe it’s the fuses I’m using? Regardless, I get the same exact light from 6pwm,so I’m not worried too much.

I’ve got a normal mode group, a blinky group, and I’ve changed muggle mode to be charging mode on the X2R. It just shuts off the LED so I can charge next to my bed

You might try reflowing the MCU real quick, sometimes the solder joint is just not quite right. I have had many times where I chase a problem only to eventually touch a soldering iron to the part and then it suddenly works, even though the joint looked perfect to start out with.

Its giving me the same light as before, and pulling the same amps as before, it just takes a higher pwm number. So it’s not a problem, just took a while to figure out.

What’s the best way to get temp monitoring working well? Pot the MCU to the bottom of the emitter shelf? It’s throttling up and down too much