Flashlight Firmware Repository

Nope, no changes. In fact Richard at MtnE sells the 25, not the 25V. Only difference is low operating voltage, but the LVP kciks in before you should get that low anyway.

It should work on a non-V model. That’s actually what I used to write it.

Thanks Tom and TK. I will give it a try. I succeeded in flashing all different kinds of firmware from TK’s repository, but now I’ll have to find out how to work with these new *.h files. Will do some research now. If I think that’s over my head, I could just use the bistro.hex file, right?

edit: ok, I think I found out how to deal with these header files.

The headers are something I’m still deciding how best to set up.

Originally, I told the code to include “…/foo.h” so it would automatically look in the right place. But that makes it not work when all the sources are copied to a single directory, or when a project is one layer deeper. To fix that, I can include “foo.h” without the … for parent directory, but the build options will then need a “-I…” to add the parent to the default include path. Maybe a “-I…/…” too. Simple fix on a command line, but it means one more step when using AVRstudio.

It’s weird trying to support foreign build systems. Normal software doesn’t have these issues. Normally you’d ship a Makefile and force everyone to build in the same way, but AVRstudio doesn’t like that approach. As builds get more complex though, it gets harder to build with different tools. So I’ve tried to keep it pretty simple, but duplicating code all the time feels like scratching a chalk board.

@ TK and other awesome people

Ok, most of what you’re saying might be over my head, don’t even know what that foo.h is. I really don’t understand much of programming and flashing, and I wouldn’t be able to flash my drivers if there wasn’t some good tutorials here at BLF. My workflow is: compiling the code with Atmel Studio and than flashing the .hex-file with avrdude via command line, just like in hoop’s tutorial.

Now with your new headers, it’s not that hard to do it, in fact it’s easy once you know how it works. I just right-clicked the project in the solution explorer at Atmel Studio~~add~~>existing file, search for the directory, chose the file, click add. That’s what I did with all the headers that need to be included.

Another change from the way it is in hoop’s tutorial, quite important for someone inexperienced like me, is, because we’re using Attiny25 now, I had to adjust the command lines. t25 instead of t13 and other fuses.

test:
avrdude -p t25 -c usbasp -n

erase:
avrdude -p t25 -c usbasp -u -e

flash bistro:
avrdude -p t25 -c usbasp -u -Uflash:w:bistro.hex:a -Ulfuse:w:0xd2:m -Uhfuse:w:0xde:m -Uefuse:w:0xff:m

I know it’s really basic stuff for people like you or Tom…

When I found out how to do the above, compiling and flashing went just fine.

But it’s not my day today, hand-soldered the A17-HybridS, flashed it (wanted to check if firmware and driver are running as they should and do calibration afterwards), however, ruined a Convoy C8 then, because I destroyed the driver retaining threads. By the way the Convoy C8 has one of the worst driver retaining rings I’ve come across, really crappy. As if that wan’t enough my 60W soldering iron flew of the bench and in a really stupid reflex I caught it, ouch, that hurt, still does. Should’ve stopped there. But wanted to test out this awesome firmware. With the C8 ruined, I went ahead and grabbed a EE X6, thought something like “yeah, feels more like quality” and installed the driver. Works, but first mode doesn’t. Maybe too low of a value for the LED to light up?

I haven’t even read how the UI works and all, but one thing I noticed in an instant: it has soft transitions between modes and I LOVE THAT! This is something I’ve dreamed about for quite a while now. That is just awesome, you, TK, are just awesome!

No more typing for me, my hand really hurts…

Thanks for the tips chouster. I follow the same process as you, so I’ll probably reference this post when I get around to using the bigger mcu’s

The lowest mode is probably just too low for the hardware it’s running on. I’ve seen anything from 1 to 9 as the lowest effective PWM level, and it varies depending on the exact type of 7135 chip, the emitter, the battery voltage, etc.

Things aren’t going so well for me today either. I’ve managed to fry and replace a 7135 chip, and the new one needs a higher moon mode. I accidentally flowed a FET right off a board, burned myself three times, made a mess of flux, keep breaking things, and can’t seem to get anything to flash today… except for a bright emitter flash followed by an unexpected moon mode.

I feel a bit like this dude now:

Reflex catch…. Oww :weary: I’ve had that impulse to catch falling hot objects.

I liked that change. Noticed it shortly after you added it but neglected to comment.

For my e-switch 45/85 version, I provide the whole set of files, all folders, all headers, ZIP'ed up, 100% ready to be built using Atmel Studio 7.0. Its easy - one UNZIP. I'm using all or most of TK's header files. I hope you (TK) don't change it. I understand not everyone uses Atmel Studio 7.0 for Windoze, but it is probably the most popular development environment.

hi there.

Is the LD-1 or LD-2 firmware open to public??

And what is the mcu an LPC1343 ?

Unless something has changed, definitely not public. led4power explained why in a lot of detail early on when I asked, but basically he would like compensation for the time/effort - can't blame him at all for that. Not sure bout the MCU, but pics show the MCU's marking, like here: https://budgetlightforum.com/t/-/29463 and here: https://budgetlightforum.com/t/-/33825. It's a product like other products we buy, but also he contributes to the forum and seems to have good support.

Am I crazy, or is there a spreadsheet or tool I can use in conjunction with battcheck that calculates the ADC values for me? Like I plug in the ADC values that battcheck reads out for 4.2v, 4v, and 3.7v, and it will spit out the ADC values for 2.9v or 3.1v?

Howdy, everyone.

I’m pulling my hair out trying to program a nanjg driver.

It doesn’t seem to matter what I do but I can’t get the low modes to work at all. It just skips them no matter what firmware I’m using. Do I need to change the caps or something?

This is for a fellow member who is taking the light on a trip with him and it’s really important that I get it right.

This is what he wants on the light.

20ma, 60 ma, 160ma, 750 ma, 3 amp turbo with memory.

I’m trying to start with a simple 3 amp nanjg. I put an new atiny13a on it but nothing is working on the low modes.

Any ideas?

What firmwares have you tried? If you are using programs that use dual-pwm (like most of the newer FW’s), the lower modes won’t light because the nanjg just has a single pwm channel.

I tried a few different ones and then tried to turn off the dual PWM. I tried the Dr Jones Mini too thinking that one would at least get me into the lower range.

Any suggestions for an older firmware that might work for me? Doesn’t have to be exact I can play around with it.

I would try one of the old versions of STAR that never had dual-pwm just to be sure that wasn’t it.

Can you clarify exactly how it’s behaving?

Ok I’ll give that a shot.

What it’s doing is just ignoring the low modes. So when I put current on, there is Nothing, Nothing, Medium, High. So if it’s four modes I have to click past the first two modes because there is no light in the first two modes.

Assuming you don’t have those modes set to a pwm value under ~5, it certainly sounds dual-pwm related.

Yes. If you can run python scripts, battcheck.py can calculate the ADC values for you. It just needs an input file with two measurements, one for a full (ish) battery and one for an empty (ish) battery. It will then calculate other values based on a linear model.

For example:

(~/src/torches/trunk/ToyKeeper/battcheck/)-]> ./battcheck.py readings/tk-s7.volts 
Line: 179 - 4.09V
Line: 136 - 3.15V
#define ADC_44     193
#define ADC_43     189
#define ADC_42     184
...
#define ADC_22     93
#define ADC_21     88
#define ADC_20     83

I’m also adding this info to a README file in battcheck/ .

I did go in and set the pwm higher and I still had the same problem. Toykeeper suggested that in a PM.

Whats a good single pwm firmware?

I still can’t get over the idea that I’m just missing something really simple.