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

Fair enough. I was handwaving:

4×3500mAh cells = 14000mAh

1mA for 14000 hours = about 580 days = about 19 months.

I’ve seen people leave their emergency stuff unchecked for that kind of time - torches with leaky alkalines being the classic example :person_facepalming:

I’m like you, I prefer the switch LED to be constantly on when used as a locator. I have tunnel vision, so flashing LEDs are harder for me to find, especially if they only flash briefly every 5 seconds or something. I won’t even see that while I’m scanning around to find it, unless I’m supremely lucky and scan across it just as it flashes.

Besides, flashing things annoy me, which would incentivise me to recharge the lantern when the switch LED started flashing at half charge :slight_smile:

I’ve just realised I should do some flashing LED tests sometime and figure out what flash cycle would work best for me. I find myself speculating on something in the region of 1-2Hz at about 80% duty cycle, so it’s lit most of the time for visibility, but signals the user by blipping off rather than flashing on.

For sure. People here would probably welcome the chance to give back a bit, given your efforts to the community.

Regardless of my financial plight & current mess i have to figure out to deal with and keep my head above the water & keep from drowning so to speak, - i am still pushing on to get this lantern into a production reality for everyone here. Right now i need someone to help with creating a good CAD drawing of the lantern design based from the drawings i done, and a driver design to present to Barry for the factory to help them to continue on the lantern production prototype. Some driver stuff been worked on by some of our small team members, and the firmware is in the capable hands of Toykeeper.

What I measured on the Q8 is about 0.1 mA on high, or about 0.03 mA on low. That works out to about 16 years or 53 years of standby time with the button LED constantly on.

Anything over a decade is considered negligible since the cell will probably self-discharge faster than that.

In any case, I wouldn’t worry about parasitic drain while the lantern is off… even if the button is glowing. :slight_smile:

Sorted. Real data always trump handwaving :slight_smile:

There’s a way to change the brightness of the button of the Q8?

Only by changing the current limiting resistors on the board.

Though I think I remember TK had a different code load of software that slightly changed the intensity.

Not quite right.

With the original firmware the current through the switch LED is controlled only by the series resistor(s) on the switch PCB. A few k Ohms. The drive from the MCU is configured as a low-side driver (AKA “open collector”) which switches hard to ground.

The trick is instead for firmware to configure the MCU pin using the internal pulldown resistor, instead of switching it hard on. The internal pulldown is many times higher impedance than the external resistor(s), so provides a much lower current through the switch LEDs.

Serendipitously just enough to make them glow usefully.

This configuration can persist whilst the MCU sleeps. There would be other ways of dimming the switch using PWM but they would require the MCU to be awake, and taking much more power.

Tom E went to great lengths to minimise parasitic drain whilst the Q8 sleeps. It is more than good enough with the original firmware, though some of us prefer e.g. amber LEDs rather than green, and larger resistors/dimmer light.

But the possibility of using the MCU pin intelligently to give high or low levels to the switch LED is interesting, but yet another configuration option for a torch that frankly I can’t memorise. So many options, so little time, do you just want ramping (no) or modes (where do we start ?).

I’ve got the kit to flash it with e.g. Anduril, but I’ve never used it. Perhaps I should try, but these days I just like a torch with firefly/ultra-low. low, medium, high, turbo. Last mode memory, and a simple sequence to either start from ultra-low and move up, or straight into turbo and move down.

With of course a few hidden flashies, a short dazzling strobe burst to wake up dozy drivers whilst walking my dog home on dark country lanes. Not continuous, just a couple of seconds per button press. And a beacon flash that could last several nights if I got stuck on an expedition and had to activate my EPIRB.

Yes, the Q8 button can do two brightness levels if you change the firmware. To do this, it activates the MCU’s internal pullup resistor during low mode. Two resistors in series instead of one, so lower current.

Here’s the power draw I measured on a Q8 with various firmware and options:

  • 0.13 mA: NarsilM, button high
  • 0.03 mA: NarsilM, button off
  • 0.10 mA: Anduril, button high
  • 0.03 mA: Anduril, button low
  • ~0.02 mA: Anduril, button blinking (estimated; 0.10 / 8)
  • 0.00 mA: Anduril, button off

A stock Q8 with NarsilM is about 0.03 mA higher due to having BOD (brownout detection) activated. It’s similar to LVP, but implemented much deeper and in a way which responds faster. However, IIRC, it doesn’t activate until 1.8V. I haven’t found it to be necessary, though it does in theory protect against the possibility of the MCU glitching out and running random instructions at low voltage.

This isn’t a firmware thing though; it’s a matter of which fuses are set while flashing. The user can flash Anduril with BOD enabled too, and it’ll run about 0.03 mA higher, but the bin/flash-85.sh script currently doesn’t use that option.

It’s also worth noting that even the highest measured standby drain is negligible on a Q8, so the actual power use below that doesn’t really matter. About the only time it makes a difference is when the button light is off, because power usage is so low that disconnecting power won’t reboot the MCU. Like, in that mode, I can change the batteries and the MCU doesn’t reboot, because it has enough residual charge to keep going for a few minutes without batteries. If I want to force a reboot, I have to press the button while the batteries are out.

Edit: If Anduril is built with “sleep ticks” enabled, which is required for the button’s “blinking” mode, the no-battery runtime is limited to about half a second. This is because it wakes up every half second to generate and process a “sleep tick” event. Average standby power use with this enabled is probably a little higher, but it’s only a small amount. Maybe 0.01 mA.

Basically, standby power use is the sum of a few factors:

  • ~0.002 mA: MCU by itself
  • ~0.03 mA: if BOD is enabled
  • ~0.01 mA: if sleep ticks are enabled
  • ~0.03 mA: button light in low mode
  • ~0.10 mA: button light in high mode

And these all vary with voltage. The values here are an average, approximately what it uses at 3.7V.

Shame it’s not built into NarsilM, I find the Q8’s button light much too bright, wish it could be toggled to be the same as the GT (low / high toggle)

edit: it’s still my favorite light though, a 1/8 turn shuts off the button anyway (D4S will probably take my #1 for fav light when it arrives)

Hey I’m interested in one. Can I still get in on that?

Certainly. I will add you to the list sometime tomorrow. Welcome to BLF. :beer:

You can unscrew the button ring an darken the LEDs with a Sharpie.

djypo added to interest list at number 950

c_wolg added to the interest list at number 951
interest list sorted by entry number

interest list sorted by user names

The user name list often as the last few entries not sorted in, so if you don’t find your name in alphabetical order just look at the end of the list.

I still love the idea of charging/power bank but of course I rather it be a fantastic lantern first and foremost. If it’s not going to add much to the cost I’d love to have that function.

I love the idea of a battery bank charger. However, I don’t see it being able to be implemented without increasing the cost greatly, or having a poor implementation. I feel that it would end up as a cheap add on.

**Hello everyone,
Just checking in to see if anyone here know of anyone in the forums who could do up a CAD type drawing based on my cross-section drawing of the lantern? I believe Barry needs something like this to help his engineers to further work on the lantern production prototype design.
Also i believe they will need something in a perimeter & specifications for the driver PCB schematic and the components that is need to be used for it, along with the adaption of either the USB charger/bank circuit on the same board, or as a separate board connected with leads & a connector. I believe that is what is needed to get this project rolling further, as i am lost on that ability to handle the driver design and a good CAD type drawing for the factory to study. I know DEL had started something for our project, but he went missing in action over 5 months ago before he could finish an initial driver. Then sbslider stepped in to help, but i don’t know if he as to much on his plate to really put time in on it. Toykeeper has the firmware abilities taken care of. TheMiller who also had a lot of input & provided a lot of help on this project when it got started, but sadly also went MIA over 4 months ago.
-Even though i have returned home after my trip east to a financial mess and a ton of stress involving my finances & future,
I am still here to try my best to my ability to make the lantern a relativity for everyone…
Regardless of my personal situation at home, the BLF lantern has been a dream of mine for many years, and working with a team of great people here at BLF, and i wanted to make this project a success for everyone on BLF, and to make it become a reality like the Q8, GT, etc all did with help & team work, and its something that been worked on doe so long and hope we can make it a realty together. I know ToyKeeper can handle the firmware, but we do need an established driver design that uses known quality components and does what it needs to do for the lantern.

- Dennis

I would gladly pitch in if I could but unfortunately I have zero knowledge or ability in regards to that.

I do CAD for work, I can take a look at it. No promises, it really depends on how complex it is.

I can offer you this as a baseline. Please be aware that I just did my best to make your sketches 3D - but I did not give thoughts to correct dimensions, spacings and what not.
The battery tube was copied with measurements from the BLF-Q8.

Things I know which would need work:

  • Side-Button as the space around it is too small
  • Remove Fins at the bottom and add cooling fins at the top
  • Correct inner dimensions for the top half of the BLF-LT
  • Missing Charging-USB Port
  • Missing Guts: Glass ring and the middle support are just for looks, but the PCB, MCPCB Switch and so on would also need to be added as a component.
  • And many more things which would need proper dimensions added to it.