Guide: how to flash ATtiny13a based drivers (NANJG, QLITE, etc.) with custom firmware

I see, can you tell me the mode of operation of your firmware? I mean how to use it’s modes. I saw a picture for crescendo on how to operate it, do you have one?

Update: Does anyone know whether Toykeeper’s BLF A6 firmware will work with a Convoy S2+ 1400mA?

A6 firmware: after tweaks, yes. It’s made for an attiny13a, but for dual-channel by default. In this case, that’s a FET + 1x7135. Change it to be single-channel and you should be set - a 105c has only one channel, typically 8x7135’s.

Operation of my ramping firmware: check out the top (lines 8-18) of the C file for instructions. I don’t have a fancy graphic made up.

I see, I was going to use 4x7135’s. I heard some of the modes in A6 were unregulated, will that be a problem with S2?

Ok I saw the C file and I got a basic Idea. I didn’t want a fancy graphic, just wanted to know how it operated.

“Unregulated” isn’t really a problem… more of a “feature” of FET drivers. FETs try to pass thru as much juice as possible, whereas a 7135 will allow a regulated 350mA (or 380mA) to pass. Assuming 350mA binned chips, 4x7135 will regulate to 4x350mA = 1.4 amps. That’s great if you are trying to achieve a specific power (amp) output. But for those seeking maximum output, they use a FET.

Good to hear that. My intention is use the light as a lantern, I needed more modes in Low and Mid, which is why I found BLF firmware to be suitable but the A6 flashlight output was overkill for a lantern. That’s why I would like to use the S2+ with BLF firmware.

If you know of any other simple firmware that has more Low and Mid modes do let me know. I wouldn’t be using Turbo at all.

Last week i received the BLF X6 driver from Banggood; sadly the MCU was locked down, so i couldn’t try Crescendo with it :frowning: According to this post i received the old version. I could try to replace the MCU, but i think it’s a bit too much of a hassle…

I just ordered a driver….hope it arrives unlocked.

Are the attiny 13/25 based drivers sold by mtnelectronics locked down or can they be reprogrammed?

It should be fairly obvious. If you see firmware options, then it has to be unlocked. If their is a specific driver your not sure about, just list what it is and maybe someone can tell you for sure.

Oops, I got gChart’s babka mixed up with his ramping UI in an earlier comment. Fixed.

Mtn’s drivers are reflashable, but the presence of various firmware options doesn’t mean that they must be. It’s chosen by the fuses at flash time, and Mtn sets the fuses to make it reflashable.

FWIW, making it reflashable is legally required for anything with my code on it, since it’s licensed under GPLv3. So you can usually assume a driver can be flashed if it ships with anything I made. But not always — as adrianoab1 found, banggood used the wrong fuse values on some of their drivers. :person_facepalming: I have asked them to never do that again, and tried to explain the legal requirements, but due to the way business works there I can’t guarantee anything.

No, BLF-A6 doesn’t work on a Convoy driver. It needs an extra capacitor in order to do medium-press detection, and it also assumes the driver has two power channels instead of one. However, Biscotti and Babka work and are somewhat similar to BLF-A6.

Crescendo can also work on a Convoy driver, and I used to keep the default build configured for that purpose, but you’d probably be better off using gChart’s ramping UI or a tiny25-based driver.

On my Convoy-driver lights, I normally use the S7 (or brass-edc) firmware. It has no runtime config options, and uses that space for a bunch of fancy blinky modes instead. It’s pretty old, and primitive, but I still like it. One of my favorite lights (a Convoy S7) has S7 firmware and a 4x7135 driver with Nichia 219b emitter.

You might want to take a look at MtnElectronics’ “Moonlight Special” driver. It sounds like it’d be right up your alley, and comes pre-flashed with a variety of UIs. Not sure if he offers it with tiny25, but if so, it should also work well with Crescendo.

Thank you ToyKeeper; I thought mtn’s driver would likely be reflashable. Therefore that would be an excellent choice especially for anyone in the US.

Thanks Toykeeper, I’ll check them out. :slight_smile:

Update:
I was just wondering whether is it possible to change the firmware for tiny lights like the BLF A01?

To be honest TK, this is one little thing that has put me off slightly working on bistro derivatives and I've even briefly contemplated rewriting parts for this reason and for the large parts I have re-written I'd probably allow them to be used even in LGPL or possibly even BSD or MIT if someone asked (and while as part of bistro they fall under bistro license, I own copyright to those parts and can relicense those parts). I find gplv3 is VERY antagonistic and very heavy handed. There is an issue, like with web software, where people can make changes and allow use of those changes through a web interface without "distributing" binaries and thus avoid sharing the changes, and I'm partially sympathetic to fixing that. I believe there are licenses now that deal with that for web software, but I don't know details, and I'm not sure if in GPLv2 distributing hardware with a binary on it counts as distributing a binary for the purpose of requiring sharing the code, but I believe that yes it already does and covers that which is why android code is made available (but I'm not expert here, could also just be because they need to distribute updates).

GPLv3 goes much farther. It doesn't say the software must remain open, it tells people what they have to do with the hardware and that's going too far to me. It's also shooting itself in the foot because HUGE amounts of money that could support GPLv3 projects have been quickly cut off and that support evaporated in many cases. This didn't cause hardware to open up, it caused software to close off. There are actually good reasons to lock down devices for security, although I'll say, as much as it irritates people Samsung's knox fuses are a good compromise. You loose your keychain if you reflash and secure payment software won't trust your device ever again, but you do get to reflash. Still I have no desire to force anything about this onto anyone. The big companies already had incentive to give back and they mostly did, because by playing along they kept a community of people working on stuff that they would in turn find use for again in the future. Ok, that wasn't always pretty, but I think in long run social shaming and need for that relationship put some limits on the problems.

I also take issue with some of the linking stuff. Just because my code is free, I don't feel the need to tell anyone who uses it that their code should be and it's not even really clear that my license has authority over their code. There's a recent low level preliminary judgment against HANCOM that may set precedent for licenses acting as contracts which would strengthen the possibility of such authority, but that is still far from settled. If not for the need to include header files, or maybe this contract interpretation, it wouldn't even be a debate. It would be like BLF or maybe Thorfire declaring we dictate rights relating to any lantern cover that "links to" and requires a Q8 to do its thing. FSF philosophy goes too far.

Is there a beginner’s tutorial on flashing flashlight firmware? I’m interested to learn (not sure if it would be too difficult for me or not…)

I’ve ordered some tools (from AliExpress) mentioned in above message:

- “USBASP USBISP AVR Programmer USB ISP USB ASP ATMEGA8 ATMEGA128 Support Win7 64K”

- “Programmer Testing Clip SOP8 SOP SOIC 8 SOIC8 DIP8 DIP 8 Pin IC Test Clamp”

  • “10cm 2.54mm 1pin female to female jumper wire Dupont cable”

Not sure if those are complete or anything else needed?

Also, for a beginner (no experience) like me, is a Convoy S2+ flashlight (w/ old firmware 5/3-mode group) be a suitable ‘subject’ for flashing firmware? If so, which firmware is applicable?

Is soldering required? (I think my soldering skill is poor… I don’t have advanced tools, just a basic 40-watt soldering iron)

Also, I think I need a pair of tweezers to remove the head/pill (sorry I don’t know the correct terminology yet but will review them…) of the Convoy S2+?

~

The Convoy S2+ Desert Sand (Biscotti pre-installed) I bought from Simon’s AliExpress store (sometime September 2017), had a too-fast driver, so maybe it’s not fixed?
(I was hoping to get this fixed by reflashing Biscotti onto it). But prior to doing that, I want to experiment flashing on the cheaper (from flash sale) Convoy S2+ (old firmware) — I wonder if the old flashlight driver also accepts Biscotti?

I thought the first post in this thread covered that part, didn’t it?

Note: I recently contact Simon and he confirmed that the new drivers he use have their MCUs locked so you can’t upload your own firmware. Not a problem for me since I can easily replace the MCU with my own unlocked one, but if you’re not good at soldering SMD components then I suggest get an unlocked driver.

About the firmware most firmwares that are stated as reverse clicky will work, if they don;t slight modification in the code will make them work.

That’s a sad news…

Thanks for clarifying some of the points… I haven’t done my homework, I did read the first post, but haven’t checked out the linked pages, plus I have little (or almost none) knowledge at the moment about flashlight drivers… (my notion of “flashing firmware on flashlights” is like flash-updating a PC’s BIOS firmware, or updating the wifi-router firmware, or updating the firmware of YZXStudio USB meter… which I have a little experience of)

So it seems I couldn’t fix the too-fast ‘timing’ issue of my Convoy S2+ Desert Sand Biscotti if that’s the case… 8-( That was one of the first reason I want to learn about flashing flashlight firmware.

The Convoy S2+ (old firmware) uses reverse-clicky tail-switch (this Convoy comes from GearBest flash sale, so I’m guessing they might be older stock and maybe have the still unlocked variant?) How do I confirm if they can be flash-updated with a different firmware? (pardon if there are some points I still don’t understand about flashlight firmwares…)

I think you can buy flashable drivers in 17mm for only a few dollars.

It’s a shame you can’t buy from MTN Electronics. You could get a new 17mm 3A qlite driver for $4.20 plus can get it custom flashed for $1 more.

I put a Qlite driver in my S2+ with Guppydrv. It’s great.

Maybe you could buy a driver directly from Convoy with the latest version of Bicotti installed?

Then learn to reflash later.

You could fix the timing issue for your S2+ biscotti, there was another thread here in blf explaining about that, just some modifications in the code it seems.

How do you know if your mcu is unlocked? just upload the code and see if it works. :wink:
even if it is locked, you can simply swap the mcu with an unlocked/blank one like I do.

Beware that the S2/S2+ has the driver soldered to the pill (there’s a pic in this review thread) and it can be an absolute pain in the butt to get it removed! (The pill acts as a heatsink pulling away the heat from your soldering iron.) The mcu is on the underside of the driver so you have to remove it from pill to flash. I would suggest you try something like a Convoy M1 that uses a retaining ring to hold the driver rather than solder. For practice and testing purposes you can also simply mount an LED to an old computer heatsink and wire a Nanjg driver to it leaving it dangling (I do this to test my flashing results). Yes, you will want a selection of good tweezers and possibly “”snap-ring pliers”:Amazon.com .

I would recommend trying out “STAR” firmware as it’s pretty basic and easy to adjust modes and such.

-Garry