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

Unfortunately, yes :frowning: And it seems it is not a one-off production issue in my case: I asked the guy on reddit who posted the first photos of the same driver variant you and I have. And he confirmed his unit has the same LED color scheme. It’s annoying, I know…

I try to persuade Barry to revise the indicator scheme as follows:

Green: Lantern fully charged

Green blinking: Lantern being charged

Blue steady: Lantern in reverse charge mode (powerbank mode)

Blue blinking: Low voltage

Amber: Standby switch illumination (off/low/high/beacon) as usual in older revisions of LT1

Any better ideas? I guess red is not available since they now have blue included?

IMHO, green works great for flashlights but lanterns are something your eyes are often looking at. So, a warm and less distracting color like yellow/red works best.

:+1:

Coincidentally, this is exactly how I want to rewire mine at the moment :slight_smile:
At some point I planned to throw out the blue LEDs altogether and go with a Green-Red-Amber(as standby) scheme, but now I’ve grown a bit fond of them.
Do you know by any chance what series resistor (designated “R_ind” in the silk screen) value was used for the amber LED in the original drivers?
Unfortunately I don’t own an old LT1 to check…

Sorry, I wish I could help but I am not that skilled. :( Lexel as the original driver designer seems unavailable for months now. Maybe DBSAR or someone else can chime in to check for the right resistor.

My mods so far: LT1 mods - Imgur gallery

Maybe someone finds them useful for inspiration…

Yeah it showed different colors when it was tubeless vs. tubed.

Here is the old LT1 (left) being charged by the new LT1 (right)

Here is the old headless LT1 (left) being powered by the new LT1 (right)

And here are the LED states i’ve seen so far:
orange steady= standby
orange steady + small red light= charging
green steady=connected to power source + fully charged
blue+orange=charging another device

I haven’t yet seen any blinking so far.

I’ll try to get it back open again later and find that IC # for you. Worried about having to resolder those wires!

That inconsistency in the power output indication in the photos must be related to the built-in load detection feature of the PD controller. The only significant difference in the two scenarios from the controller’s POV is the required current. Which is relatively high in the “tubed+standby” case and very low in the “tubeless+standby” case. The latter was probably not high enough to trigger the load detection, which usually has a threshold around 50mA. Basically, in the tubeless case, the new LT1 did not notice it was connected to something.

Thanks. If you do, try to take multiple pictures from multiple angles for a better success rate. And be careful with those wires :wink:

You’re totally right. Just quickly checked and it doesn’t trigger that charging/blue LED state until I set the old LT1 to it’s highest setting.

Ok here is the IC in my “Sofirn 1.0” Powerbank LT1

It’s an ETA9742

I’m really confused now…
So many variations.
Is the original LT1 version 1 capable of being programmed to Anduril 2.0? If so, I may go that route. I’m not needing my LT1 to double as a power bank. I would NOT want the active power/standby switch light to be green, as showing in the newer release. That would annoy me to no end…

Yes, it is. I’m using mine with Anduril 2 for months. :slight_smile:

Yeah if you can upgrade it to 2.0 that seems to make the most sense for you. But just to be clear, the powerbank version I got maintains the orange standby light.

Cool! Thanks for the photo.
We were right then, that is indeed a completely different controller. From another manufacturer (which I admit, I have not even heard of).
What’s very strange about that IC is that it is laking any connection with the CC pins in the Type-C connector, which the whole power-role detection and switching scheme of USB Type-C is based on.
It handles all that somehow solely based on the VBUS (device power) pin. Not how the guys at USB-IF intended it, for sure. But hey, if it works, we cannot complain, right :smiley:

I assume this variant of LT1 driver has fixed resistors wired to he CC lines. Meaning that it advertises itself in a fixed, hardcoded role. But this also means that its actual role and advertized role is going to be inconsistent in 50% of the cases: either when sourcing or sinking power. That should be fine for “dumb” devices (chargers w USB-A sockets, old LT1) but could be problematic with “real” Type-C / PD devices, which actually make extensive use of the CC pins.
I hope I am wrong about that, but nevertheless it could not hurt to do some tests with different devices, with a C-to-C cable, to see how it behaves with them.

With the other driver variant, there are no such concerns, its controller (IP5310 from Injoinic) is a “real” Type-C device, with built-in CC-pin handling logic, Type-C DRP Try-Src statemachine, all bells and whistles.

Thanks for looking into this.

I have some headphones I could try charging with it. Would you say that this setup could potentially damage real Type-C devices? Would it harm something like an iphone, which still uses lightning cables?

Sorry if I frightened you with the things I wrote. Actually, I think it is very unlikely that it would harm any connected equipment, I would not be worried about that if I were you (although I obviously cannot say this with 100% certainty without knowing the exact schematic of the driver and the detection mechanism used by the IC and deep-diving into the gritty details of the USB specs). What I could easily imagine, are some special cases in which it just refuses to work together with some devices (e.g. won’t charge when connected to a USB-PD charger; won’t charge from a powerbank, or it won’t source power to a powerbank (*); things like that…).
(*) Normally when you connect two powerbanks with the same role-priority or no role-priority together, the outcome of “who is powering whom” is random. That might not be able to happen here. The powerbank is just an example, the same holds true for other dual-role Type-C gadgets.

Odd, the orange LT1 i received from Sofirn a few weeks ago had the other original driver, (see the photo) but i do see teh slight imperfection in the machining in the head same as your photos show. it looks like their CNC had a hiccup in that area where the bail handle folds down.

Its just too hard. I was going to buy a second LT1 but have no idea what I will get.
Maybe wait for a few months until Sofirn stabilises their models. If they ever do.

I am afraid we will not get any detailed, official clarification on "what is what" anytime soon. :(

I have now seen four different driver revisions...

First revision 4.3 Updated revision 5.0 with type C-C compatibility fix Unknown new (intermediate?) revision 2021 with PD/reverse charging and Andúril 2 New (official?) revision 2021 with PD/reverse charging, revised flashing pad layout and Andúril 2

Wow… I know i have been a bit out of the loop for the last year due to my big move, life alterations, getting ill, and trying to get back on my feet, meaning i was not as directly involved, or aware of driver changes. I have been however watching the LT1 te4am chat group, but there has been no updates from Barry with Sofirn or other team members during my downtimes… I wish Barry would have consulted with the team, ( all of us active members on the design/development team for the LT1: (Myself, ToyKeeper, SIGShooter, Barry0892, Phlogiston, Lexel, sbslider, BlueSwordM, bmengineer, Lux-Perpetua and amishbill) were the team that contributed to the LT1.

Interesting test… That shows the new version (Powerbank enabled) should be able to power a second LT1 as a “tag-light” meaning one LT1 can power two separate LT1 head units from one body set of cells, (but with a reduced run times, as its likely the same as running two separate LT1 lanterns with only two cells in each lantern, ( as the LT1 can run with even a single 18650, or two, three or for cells by design intentions.