Has the latest firmware for a D4V2 made the Aux LED cycle rate way slower. I just got a brass D4V2 and the cycle rate is way slow and not consistent. The rate changes between about 1.5 seconds and 5 seconds. I also have had a very hard time accessing advanced functions. Battery check and changing between ramped and stepped modes are good examples. Seems like I’m not clicking fast enough? I have 2 other Emisar’s a D4V2 and a D4SV2 and have no such problem. No problem on the other dozen or so Anduril powered lights I own.
I made a separate thread relating to my ongoing issues, but thought I’d ask here. I’ve been trying to figure out the OTC memory on a FET+7135 driver. I flashed the offtime-cap25.hex to an attiny25 but a short press (~.5 sec) always gives me a value of 255. I guess a value of 255 until about 4 seconds or so, then it starts dropping off to lower values. Obviously this shouldn’t be happening but I’m using the correct components, I believe-1 uF cap for the OTC. I tried various other caps of lower ratings which made little difference. What’s going on here?
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:
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.
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.
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.
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’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.
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
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 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.