TKâŚcould you please share some hints on when can we expect 1634 sources?
Itâs hard to say for sure. It would have been out by now, but people keep asking me to help them clone Emisar products, so I keep pushing back the release date. Iâm not in the business of helping people undercut my clients.
I see, thanks for clarificaiton.
I suppose thatâs the problem with open source.
Personally, I prefer the design and execution of Hankâs lights and Anduril is icing on the cake. I will always choose his lights compared to the clones. I would hazard a guess that a lot of other flashaholics would too.
Not sure if this is the correct thread to ask but⌠I have an Astrolux C8 with a bleeder resistor on the driver and a lit tailcap. Everything worked well but the turbo step down was too quick so I changed TURBO_TIMEOUT to 255 in the A6 firmware (blf-a6.c) and flashed it to my C8. I didnât specify fuse values when flashing. Upon testing I noticed I couldnât step backwards anymore. Is this due to a core timings change somewhere in the firmware? Should I play around with the resistors again to get the modes working properly? If it helps, I bought the C8 new from BG one year ago.
Not sure if this is the correct thread to ask but⌠I have an Astrolux C8 with a bleeder resistor on the driver and a lit tailcap. Everything worked well but the turbo step down was too quick so I changed TURBO_TIMEOUT to 255 in the A6 firmware (blf-a6.c) and flashed it to my C8. I didnât specify fuse values when flashing. Upon testing I noticed I couldnât step backwards anymore. Is this due to a core timings change somewhere in the firmware? Should I play around with the resistors again to get the modes working properly? If it helps, I bought the C8 new from BG one year ago.
Sounds about right, the fuse settings. Had the same issue after flashing my BLF A6. The timing was way off. After reflashing it with the correct fuse values, it worked correctly again
Doesnât flashing without specifying the fuse values leave them unchanged? Or are you saying I need new fuse values for the (presumably) newer firmware?
Fuse values, are based on what type of MCU you are flashing. ATtiny13, 25, 85 etc.
I have an Astrolux C8 with a bleeder resistor on the driver and a lit tailcap. Everything worked well but the turbo step down was too quick so I changed TURBO_TIMEOUT to 255 in the A6 firmware (blf-a6.c) and flashed it to my C8. I didnât specify fuse values when flashing. Upon testing I noticed I couldnât step backwards anymore. Is this due to a core timings change somewhere in the firmware? Should I play around with the resistors again to get the modes working properly?
It probably needs different values for the OTC calibration. The CAP_SHORT / CAP_MED values might not match the hardware.
Specifically, it may be a good idea to use the blf-a6
branch of the code instead of trunk
, because itâs what the light probably shipped with. The copy in trunk has had updates and the calibration is set back to a default which I think matches MtnElectronicsâ drivers instead of Banggoodâs drivers.
Looking at it now, the blf-a6 branch uses values of 245 and 180, while the trunk branch uses 190 and 94. So that may be what youâre running into.
Banggoodâs drivers donât really have the standby drain configured very well to begin with, and the lighted tailcap makes it worse. Hereâs what I measured a few years ago. The blue line is ideal, and is what trunk uses by default. The red line is what Banggoodâs drivers do. And when you add a lighted tailcap, it follows an even higher line.
Thanks TK, very helpful and informative post as usual. Iâll check it out on the weekend.
Update: worked like a charm!
I just wanted to post a suggestion for improvement.
When clicking 4 times to exit lockout, it would be nice the if the behavior were:
4-clicks, the light turns on to the last memorized mode
click, click, click, hold, the light turns on to moonlight and starts ramping up
5-clicks, the light turns on to ramp ceiling
click, click, click, click, hold, the light turns on to ramp ceiling and starts ramping down
etc.
Essentially, the fourth click should act as if the light were already out of lockout. This makes sense since if youâre taking the light out of lockout, the next thing youâre going to do is probably turn it on.
I just wanted to post a suggestion for improvement.
When clicking 4 times to exit lockout, it would be nice the if the behavior were:
4-clicks, the light turns on to the last memorized mode
Iâve considered doing something like this⌠making it so anything which exits an âoffâ or âlockoutâ mode will also turn the light on. That would mean 4 clicks to exit lockout would go to the regular ramp mode instead of âoffâ mode. And it might also mean 6 clicks to enter muggle mode would turn the light on.
However, I have no plans to do the other changes mentioned:
click, click, click, hold, the light turns on to moonlight and starts ramping up
5-clicks, the light turns on to ramp ceiling
click, click, click, click, hold, the light turns on to ramp ceiling and starts ramping downetc.
Essentially, the fourth click should act as if the light were already out of lockout. This makes sense since if youâre taking the light out of lockout, the next thing youâre going to do is probably turn it on.
Basically, it sounds like the suggestion is: Reduce the âexit lockoutâ mapping from 4 clicks to 3 clicks, and force the button timing to reset after the 3rd click so it will start counting from 0 again. This would mean 5 clicks to access the ceiling, 6 clicks for battcheck, 7 clicks to go immediately back to lockout mode, etc.
But I intend to keep 5, 6, 7, and other clicks the same as they are now â momentary moon without unlocking the light. The most likely changes are:
- Maybe remap 3-click aux LED controls to 7 clicks, to improve consistency between âoffâ and lockout modes.
- Maybe remap 4-click âexit lockoutâ so it goes to an âonâ state instead of âoffâ.
Ah I didnât realize you are able to adjust aux LEDs in lockout. That complicates things somewhat.
Anyways what you are describing sounds like what I was suggesting.
The most likely changes are:
- Maybe remap 3-click aux LED controls to 7 clicks, to improve consistency between âoffâ and lockout modes.
- Maybe remap 4-click âexit lockoutâ so it goes to an âonâ state instead of âoffâ.
Both sound sensible :+1:
A thought just struck me, and I have to put this out thereâŚ
Imagine a website that can build a custom anduril.hex file for you
Imagine a GUI, with some simple drop down menus and boxes to tick.
Select host, select emitter. Select or deselect what extras you want.
Perhaps an advanced menu where you could rearrange what 3 clicks, 4 clicks does, etc.
And then boom, it spits out a freshly assembled .hex
I would wish that in the ramp config of the stepped ramping there was a forth option to adjust the speed of the ramp. I would like it to be a bit faster.
I would also like a way to adjust the button release timeout from a menu for the light to turn off way faster. Like with computer mouse, I prefer quite fast double click, with anduril I tend to activate turbo while I donât need it.
I kind of think a cool option would be to adjust the turbo level in the software, rather than having to flash a lower turbo version. I think itâd be useful to be able to lower the turbo level to the same as max ramp, meaning double click from off OR on would go to max regulated mode. Basically disabling the FET channel. For the FW3A, the light is really too small to sustain turbo for more than a few seconds anyway, so the option to disable the fet altogether would be interesting. Sort of a better muggle mode, since the FET channel is really what muggles need protecting from.
ToyKeeper, one thing that doesnât feel right for me with anduril both in stepped and stepless ramping but particularly in stepless ramping is when Iâm ramping up and stop too soon (âa tad more light should be just fineâ), there is no way to immediately go a bit up.
When inside the window delay, 1H goes down but 1C + 1H also goes down.
Would it be possible to change this ?
I know that I would prefer 1H to always go up and 1C + 1H to always go down because it is how it works outside of the window delay, but to not confuse people who got used to how 1H actually works, would it be possible to have 1C + 1H to go up immediately ?
This is controlled by the compile-time option USE_REVERSING. If you are able to compile Anduril yourself, you can comment that option out in anduril.c (or #undef it in the model config).
IMHO the timeout should be shortened from 1s to maybe 1 or 2 times hold time.
I kind of think a cool option would be to adjust the turbo level in the software, rather than having to flash a lower turbo version. I think itâd be useful to be able to lower the turbo level to the same as max ramp, meaning double click from off OR on would go to max regulated mode. Basically disabling the FET channel. For the FW3A, the light is really too small to sustain turbo for more than a few seconds anyway, so the option to disable the fet altogether would be interesting. Sort of a better muggle mode, since the FET channel is really what muggles need protecting from.
I agree that it could be a useful feature to be able to set the limit of turbo on the fly. Disabling the FET all together probably isnât feasible as it is used for all unregulated modes, just PWMed to achieve the desired brightness.
Coincidentally, I have a few BLF A6 drivers Iâm looking into doing just that (reducing turbo level in the firmware though) so I can use them in single emitter lights without risk of frying the emitter.