*BLF LT1 Lantern Project) (updated Nov,17,2020)

DBSAR, thanks! I definitely want one.

Interested.

The list in the OP only gets updated periodically. I also maintain the “master” list which gets updated everytime I reply to an interest post. Sometimes it gets updated before I reply to an interest post. The master list has to ways to look at the data.

interest list sorted by entry number

interest list sorted by user names

You are definitely on the list, and if you can view the google doc links you can see it for yourself. If you can’t view the links, then you will just have to trust me until the OP gets updated.

geetee03 has interest list number 893.

I will add the interest list sorted by user name at times has the last few entries on the end not sorted, as that is a manual step I do periodically. geetee03 is last on that list until I sort again.

Awesome, glad I’m on the list! Thanks for clarifying.

Your MCPCB looks fine, I can’t find any reason why it shouldn’t work, but what are your final thoughts about the charging solution before we skip to the next topic?
And could toykeeper please make a short overview about the modes and funktions that are already implemented or planned before we talk about adding new ones? (Do we even have memory left ?)

some information here

Interested.

Plus tint ramping, probably on “click, click, hold” in almost any mode.

The charging option is defintiely a planned part, but will have to leave that in more capable hands.

I can’t see it in that diagram if “stepped” modes are an option instead of ramping, ( such as set mode groups as moonlight-low-medium-hight)

Yes, the “stepped ramp” is a mode group, like moon-low-medium-high or whatever the user configures it to do.

The actual button presses involved are the same as the smooth ramp, so… click for on/off, hold to change brightness. But it uses a user-defined mode group. The result is very similar to an Olight Baton interface.

Ah ok nice :slight_smile:

Common negative? I am surprised based upon how all of the other drivers are designed

it can be split into two negative contacts if needed, i will leave that to the driver designers & programmers to determine.

This is how I would do it as well, it is less wires to run and they would go to the same place anyways.

Right, and everything I learned so far with these things (which is still a looong way to go) is they are regulated on the negative side. I would have thought common positive.

Thats what i was thinking too.
if its a negative side regulation, then its easy to flip the 2 positives with the negative & reverse the LEDs on the pads if negative-side controlling is easier.

Yeah, it needs the +/- labels swapped so it’s common positive instead of common negative.

Generally BAT+ goes directly to LED+ with nothing in its way, while BAT- goes through fancy stuff on the driver before becoming two LED- connections.

The Astrolux S41 did it backward initially, and they had to change it. For a while they were putting LEDs on backward while they went through their old stock of backward MCPCBs, but that was still better than having the battery short directly to itself.

good to know. :slight_smile: I will change the positive to Negatives then.

Wow! Super impressive work!

Thanks EVERYONE who is giving this amazing project life!