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 
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.
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.
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 
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 
I see that we’ve had a discussion about it before.
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.
I tried hard - no results, I guest only TK can fix it
Hi all, Is there any problem with the code of dthoang(dth_Momentary_v1_1.c) ?
I flashed it on my attiny13a, and I see nothing but the blink-on-power.
The driver won't respond to any of the e-switch controls.
I tried flashing STAR-MOMENTARY for example, and it works with no problems.
What might be the problem?
Thanks
Hi everyone I need your help, I have tried the Star-Momemtary code, wonderful code, but I have to ask if you can change some points, I use it with a piezo button and I find it too sensitive, how do I increase debounce for avoid accidental ignition, or you have other things to propose, I also accept your ideas
Thank you so much