Personally I never use built-in USB charging. I have Wurkkos FC11, Skilhunt M150 and H04 and I always charge their batteries in a Nitecore charger.
I find it’s more practical to swap to a spare backup battery and continue using the flashlight rather than having your light out of action because it is in charging mode.
It’s a nice feature to have for emergency charging on 18650’s or 21700’s but for AA sized flashlights I think it’s not necessary.
> This light does not have a USB port or a charging circuit, and it would not be easy to add.
I see, well maybe a future model then. I think it is worth aspiring towards.
The Avr-1 is like the Atmega series in that the flash memory can be partitioned into a boot loader, app, and data. Having a boot loader could allow application upgrade through I2C or similar (I think you were the one who explained this to me) but that would add some code. I think the traditional Arduino boot loader is 2KB so maybe that’s a reasonable amount, though I’d expect smaller is possible.
The 1616 has plenty of space for the existing app plus some enhancements, but if the 3216 doesn’t add significant cost or complexity, I think we can find things to use it for. The price difference on microchip.com seems to be about 20 cents. We could even use the extra flash area for stuff like logging, if we didn’t want to put code in it.
> I find it’s more practical to swap to a spare backup battery and continue using the flashlight rather than having your light out of action because it is in charging mode.
I don’t find this myself, at least with my Fenix BC21. It flashes a red light when the battery starts getting low, but I can keep using it for a while. So when I see the red flash I just remember to plug the light in later that night, before going to bed. It’s similar with a mobile phone. I hate phones with non-swappable batteries, but even with a swappable battery I usually just charge the battery in the phone before going to bed. Taking batteries out of the light is just another clumsy operation that I’d rather avoid. Even professional users like LEO’s in the incan era traditionally charged their lights in charging cradles, rather than swapping battery packs around.
The t1616 leaves us plenty of space for future development. The t3216, as much as it may sound like a good option, is only offered in SOIC20 (large!) footprint, not the 20 pin QFN footprint of the t1616. We could move to the t3217 if we needed to for some reason but that’s a larger QFN chip (4x4 instead of 3x3 mm). The code would port easily (just more pins) but PCBs would need changed. Maybe someday we’ll need it.
I think this flashlight was designed to have the features of the bigger lights like the D4V2 but with the practicality of readily available AA sized batteries. If it was 18650 or 21700 USB charging then I can see how that would be really useful, but I think USB charging seems kind of redundant on a AA light.
Oh! Ok, that is a good reason to stay with the 1616. If it was just the 20 cents (even translating to $1 in the finished light) I’d very much think it was worth it.
That is interesting about the 3217 but I agree we don’t need it, and it seems too big for an AA light. I’d find it of interest in a D4v2-style light which already uses(?) the 4x4mm t1634, and for which we can always use more i/o pins since it has so many aux leds and so on.
Do you think there is space for a JST-SH connector? It would be spiffy to have the light be a Qwiic device. It is about 4x6 mm: JST SH 4-pin Right Angle Connector (10-pack) [Qwiic Compatible] : ID 4208 : $3.95 : Adafruit Industries, Unique & fun DIY electronics and kits (drawing pdf linked where it says “diagram”). Then you could plug it into a usb-dongle style microcomputer board (Adafruit Trinkey QT2040 - RP2040 USB Key with Stemma QT : ID 5056 : $7.95 : Adafruit Industries, Unique & fun DIY electronics and kits), Raspberry Pi Pico, or whatever. If not, maybe a pogo pin contraption could use this 4-pin interface (power, gnd, tx and rx i2c).
There is not space for a JST-SH connector. I’m not sure if you’ve looked at the driver area of an AA-based light before, but there’s really not much room at all there. That said, the driver was designed with programming pads. You use an adapter like this one to connect to the programming pads (note: that is the original design of the programming key, I have since then rearranged the pins so that ground is in the middle… it’s a bit safer that way in case you flip the key the wrong way). UPDI programming (native for the the newer AVR chips) only uses 3 pins: power, ground, and UPDI. Technically, if the driver is already powered (connnected to a battery) you only need to hook up the UPDI pin. No sense in trying to mess with i2c programming or anything of the sort.
Ah quite understandable about the space. I’ve been reading up on UPDI. It looks like it should only require a single contact pad on the board, since it’s a bidirectional i/o line, and the + and - lines can be gotten from the battery contacts. Then there are two kinds of reflashes:
1) hardware devs might sometimes need to unwedge the chip with a 12 volt pulse to the UPDI reset pin, so there are special dongles for that.
2) Software devs and users will normally want to just reflash the app, so if it is set up like an Arduino with a bootloader, it should be possible to reflash off a normal gpio pin from a random MCU board or raspberry pi or pi pico. That is nice because it gets rid of the need for special hardware adapters, imho. UPDI gives bidirectional communication and debugging, and even has GDB support, which will be great. The GDB remote stub will require some code space of its own, I don’t know how much, but I hope it is not large.
I wasn’t familiar with the term Dupont connector but it looks like they are 2.54mm header pins. I wonder if there is something smaller available.
Here’s a tiny pogo pin clip that could be about right for gripping a contact pad: Pogo Pin Probe Clip : ID 1969 : $2.95 : Adafruit Industries, Unique & fun DIY electronics and kits
Is useful have on ni-mh the minimum ramp level as low as possible below 0.2Lm
A 1800k option would be gorgeus to emulate candle or gas lanter.But apart the particular E21A 2K there is nothing in high CRI 3V with standard sizes.
Can be requested to be produced by another Chinese manufacturer such as GT-FC40.
And on sp10s I don’t want to see sharp edge and pineapple knurling anymore
It could go much lower than 0.2 lm, but I don’t see many people wanting it set that way. But you should be able to adjust the PWM ramp and flash new firmware as you see fit.
i would prefer lower than 0.2 lm for supper long run like zebralight
If people want lower than 0.2 lumen just remember that this isn’t going to be just released for enthusiasts. We certainly don’t want more complaints about flat cells because users thought it was off in daylight. This happened on previous revisions.
Perhaps advanced mode could have access to it, but that would require more coding
At low output levels like this the current to the led become less and less relevant and the majority of the power consumption is from the MCU.
Zebralight probably run their MCU at a very low clock to use as little power as possible.
Really ? Never heard of people complaining about Armytek, ZL, Manker moonlight being too low and it’s much lower than 0.2 lm on several of their model.
The driver works with pwm?I like much constant current
You do have a point.
Constant current is often controlled internally by PWM. The MCU generates pulses, the pulses go through a lowpass filter, and it produces a steady analog control voltage. Then the control voltage determines the amount of current the power regulator allows through.
Decreasing output below 0.2 lm might be possible, but it probably wouldn’t increase the runtime by a meaningful amount. It could even have the opposite effect. The LED isn’t the part which is using the most power at such a low level… the power is used instead by the boost converter and the control chip.
For example, the BLF Q8 originally shipped with the ability to run at ~0.01 lm, just barely enough to produce a dim glow in the dark. In this mode, with four good cells, the runtime was about 90 days. It was a special adjustable moon feature in NarsilM… which was cool, but required running the MCU at full speed.
After reflashing the firmware to Anduril, the lowest moon level is about 0.2 lm. However, despite being brighter, it also increased the runtime to about 300 days — because it underclocks the MCU to conserve power. This reduced the precision available for output control, but greatly increased the runtime.
It was a case where people could have less than 0.2 lm OR they could have super long runtime… but not both.
Switching converters do have bad efficiency at low current but even a 30% efficiency at 100uA (TPS61088 used in Zebralights ) or 5% at 10uA (TPS61288) means that the bulk of the power consumption is still the MCU (although it’d be nice to know what is the regulator used in the SP10S). Gchart measured the power consumption with PWM at different system clocks here : Adventures in TinyAVR 1-Series - #29 by gchart
5.5mA at 10MHz which is the sytem clock used, it could be decreased to 5MHz or 2.5MHz (<2mA) using the dynamic underclocking function but then we should check that the output ripple is still acceptable, if not then the RC filter could be modified to better smooth the PWM at the cost of rise/fall time (mostly an issue for party strobe).
There could be further gain using TCD and dropping the clock to 32kHz in moonlight. Or, even better to use the DAC instead of PWM which would then allow Zebralight class moonlight efficiency.
I think the candle lantern simulation can be done with a white led by having a yellow diffuser. I checked and there is translucent yellow or orange 3d printing filament available, though it would be even better if a molded diffuser is made to fit the light.
I would take that trade.
I vote for Firefly levels…
Firefly capability is higher priority for me,
than months of Moonlight runtime
I change batteries much more often than a Firefly runtime limitation of three months
sounds good to me
as long as I can have 0.01 lumen Firefly, not just 0.2 lumen Moonlight
Yeah, the LED was only a tiny part of the total moon power usage on a Q8, and it didn’t even have to deal with converting the voltage. On the SP10, we’ve got that plus whatever extra overhead the power converter requires.
The newer MCU offers some additional features for reducing its power usage, but I don’t know enough about the implementation details to know which methods are feasible here. Like, using a DAC may or may not be possible. And running the system clock in the kHz range instead of MHz range has some, uh, side effects. In particular, it has a tendency to interfere with the ability to reflash the firmware. I found out the hard way that it’s really easy to accidentally put the chip in an unrecoverable state when messing with slow clock speeds.
Another method for getting an extremely long-lasting moon level is to treat it as an aux LED. Set up a passive current path, and put the MCU to sleep. This generally requires using an extra pin, and I’m not sure how it would work on a boost circuit, but it otherwise has worked really well in the past. Instead of 300 days of runtime at 0.2 lm, the Q8’s button LED gets like 0.1 lm with a runtime of 10+ years.
Mike C uses the DAC in his driver and as he mentionned in my thread is ready to share his code if needed.
Loneoceans I think mentionned that he have used the DAC with the 1616 but he hasn’t been online for a few months.
Yeah that wouldn’t work with a boost converter, and while it is simple with FET and linear topology by putting the pin as sink, I think it is more complicated with buck topology and might require extra components.