Flashlight Firmware Repository

Yes please! There are obituaries for bzr that are dated 6 or more years ago. And there’s also already more than a handful of copies of this bzr repo on github. I just added another one, so I can track my own changes.

In case anyone is interested, here's the Atmel Studio 7 (Windows) Anduril v464 (latest) full folder with all the source code, solution and project file and it all builds, right now defaulted for a Q8 configuration, with the max temp of 85C, default to 55C:

google drive share for Anduril

I tested this exact build on a Sofirn Q8 and it's working very well. Info here on the port to AS7: https://budgetlightforum.com/t/-/47204/907

I found the port to AS7 not very difficult, took some time, maybe 2 hours or so, but not that bad.

Thanks :heart_eyes:

Oops, posted this in the other E-switch UI thread:

I worked on adding voltage Cal to Anduril. I made it work to enter the fudge factor via 1 to 10 clicks. 5 clicks is 0.25, 7 clicks is 0.35, etc. Max of 10 clicks.

Installed this just now on a SP36, previously had NarsilM v1.3 on it, and been testing it - the voltage fudge factor configuration seems to be working fine!

If I set it to 3 clicks, it reads 3.8V. If set to 10 clicks, it reads 4.1V. A difference of 7 clicks is about 1.75V, so this makes a lot of sense. Now if we (or I) could get this rolled in the official Anduril? Seems like a great feature. I was gonna spend the time doing it with NarsilM but it would be a lot more effort, because I also would have had to roll thermal config in.

Nice work Tom E. :beer:

Thanks . It looks like Anduril for the ATTiny85 is at it's code space limit, so adding features most likely means taking something away. For my Anduril builds, I did take away sunset and beacon modes, so you go straight from voltage to temp readout modes, but that saving in code space helped.

Today I hurt myself AGAIN by pointing the light the wrong way while connecting battery.
My branch now has the power-on-indication level configurable. In my config it’s moonlight.
MUCH better now.

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.