Flashlight Firmware Repository

My list of Anduril mods:

  • raise max temp ceiling to 90C (used to be 70C)
  • add calibration of voltage reading via standard configuration method: click "n" times for 0.05V per click to enter the fudge factor
  • make the version # a version #, not date (using 11 for now...)

Rest of changes are standard compile time config settings, like:

  • for the MF01 Mini, keep the AUX LED on when the light is ON (std method of dimmer to brighter)
  • turned off sunset and beacon modes

I think that's it.

Agro - the power on brightness setting sounds useful. Do you have other mods? Is yours posted/downloadable?

https://code.launchpad.net/~nisjuk/flashlight-firmware/nisjuk2

I did many changes related to lockout mode:

  • 3 clicks from lockout unlocks and starts the light
  • 3 clicks+hold from lockout starts ramping from moon
  • 3 clicks from any other mode goes to lockout (note: this does not apply to muggle and momentary modes which I removed in my config)
  • (config change only) I have aux LEDs on high when off and low when locked out to indicate whether the light is locked out
  • After 5 minutes off the light locks out by itself
  • after power is connected the light starts locked out rather than off
  • (IIRC config change only) mode memory is reset every time the light is locked out so I always know the mode the light will start with (either the default or moon)

I like this WAY more than stock.

I also changed the 3-colour aux voltage indication to 5-colour….but it doesn’t work because of the issues I mentioned earlier.

Interesting... thanx!!

We need programming for those of us that just follow instructions and don't need-or care-about coding knowledge. That would mean a Windows GUI interface and a simpler to use cable (I shake too damn much to hold pins on a driver) like the two way radio programming software we used in that business: 1) read from radio 2) make changes 3) write to radio. Done. Finis'. Happy new programmed light.

I fully agree.
Exposed programming pads are a big step forward but there’s still a lot of room for improvement.

I’ve made a guide on how to set up macOS for flashing (setting up the environment, getting the latest revision of Anduril, flashing), but am lacking options for putting the .pdf up in a secure way. I could host it as a Google doc, but that allows showing my full name which I’m obviously somewhat hesitant to do so.

Anyone have any suggestions?

I got excactly the same issues here,
Driver acts like next mode memory until I wait like 20 seconds
seems newer MCUs do discharge the capacitor far slower than older

I simply soldered 1M Ohm across the OTC and adjusted the values a bit to get it work

By secure, do you mean restricted access or just anonymous?

I’d love to read your guide as I gave up trying to get the USBasp working on macOS myself and just used an Ubuntu VM.

More anonymous, and a place that it won’t be deleted after x days of no views :slight_smile:

I’ll flick it across to you anyway in PM, but still after a long-term home for it. Or I could just get hosting :weary:

That’s really cool. I’ve long lamented the imprecise nature of the party strobe’s pulse length. It’s easily visible that the pulses aren’t the same length. I had considered controlling the pins directly as digital outputs instead of using PWM, but it appears that slower hardware PWM is simpler and more accurate.

I may have to see if I can merge this in, for the devices which are capable of supporting it. :slight_smile:

The indicator LED code was originally made for the BLF Q8, which has low enough power usage that it doesn’t really matter if it’s turned off or not. It’s not much higher than the battery’s self-discharge rate, and when the battery voltage is low, the button light fades out before long anyway.

However, on newer devices which use higher-powered aux LEDs, LVP is more important so I added it. I just never got around to adding it to the indicator LED code. All of that really needs to be refactored and cleaned up, since it’s currently a mess with two or three similar but different sets of code for different types of extra LEDs.

It would be really handy to have a way to get data directly out of the light like that. :slight_smile:

Instead, I’ve had to do things the slow way, blinking out numbers one digit at a time and writing them down.

Doing this turned out to be pretty educational though, since I discovered there was quite a bit more noise in the signal than I expected. And I found that the noise was highly dependent on what the light was doing at the time. Measurements were pretty clean while the light was at rest, but during use I got a lot of noise even with really heavy oversampling.

Rewriting things to optimize for noise reduction resolved a lot of issues I’ve seen over the past couple years.

Thanks! I know we already chatted via private messages, but I just wanted to say in public that this has been very helpful.

I’ve been working on merging this since late December, and finally published a new revision yesterday after finishing a bunch of testing. It ended up being a much bigger project than I expected, but it all seems to be working now and I hope others will get similar results.

Maybe. I’ve been meaning to move it to git for a while, because it’s much more widely used. I just really don’t like some things about Git. In particular, I want to find a way to get its branching to do what I need first. Git’s branch features are one of its weakest points, and although it recently got something vaguely similar to how Bzr works, it’s a shallow implementation which leaves a lot to be desired.

I generally have at least a dozen different branches in progress, many of which are long-term and/or private, and each has its own working tree with meaningful state that shouldn’t be part of the repository. That’s trivial to do in Bzr because it’s the default and recommended workflow… but it goes against much of Git’s design so things quickly get awkward. It’s also weirdly tricky to interact with other instances (like GitHub) in terms of single branches instead of entire repositories. It generally grabs or sends all branches and checks out master, which is frequently the wrong behavior.

It looks like if I want similar branch functionality, I’ll probably end up with many many local copies of the entire repository… and then merges end up being much more of a pain.

In general, I’ve found that the default behaviors in Git are almost always the opposite of what I want, so I end up needing a lot of overrides and workarounds. This has greatly slowed down the migration process. I’d love to go back to 2005 and slap Linus around a bit to convince him to change the design.

Probably not. I can’t run it, so I can’t maintain it.

Yes, a recent update slowed down the rainbow mode because people thought it attracted too much attention.

About 3-click actions not responding, there seems to be an issue of some sort which is very difficult to reproduce on purpose. Usually it can be resolved by cleaning the electrical contacts and making sure the parts are put together tight enough.

However, there are some brand new builds which might help too. I’ve tried to make it much more tolerant of electrical noise, and it may react better now when there is a weak ground contact or something.

There are many requests for that and I think it would be really worthwhile to support Atmel Studio. Though personally I don’t understand why because my personal experience with it was very bad.

What kind of maintenance would it need?
What if there were members interested in maintaining it?

I'm using AtmelStudio for Anduril and been posting my full projects. It was easy-peezy

I implemented to DarkHorse indicator led, lockout and candle mode support from Anduril for my headlamp drivers, but i dint find out how to enable LVP for indicator led :frowning:

It is not implemented. This is a fairly simple change near
// TODO: turn off aux LED (s) when power is really low

And how TODO? There is no code and im not a coder :smiley:

I see that we’ve had a discussion about it before. :slight_smile:
Sorry, I can’t give you a better advice than this. I won’t add this code to the repo before I test it.And I don’t have an adjustable PSU yet….

It’s not that simple. TK is right, a refactor is in order. Fixing it at the spot of the “TODO” won’t get all the cases.