Thanks everyone! I’m at the point where I’m done tinkering with lights (for now), so I’m not even excited out modifying firmware. However, I want to be able to offer friends and family an excellent light at a cheap price. Normally I gift out C8’s which are easy to add Biscotti to, but this friend wants a smaller form factor. I wish the A6/S1 was offered with Biscotti, but it seems like Babka might fit the bill! I sent you an access request on that google drive link gchart. Otherwise I will try modifying tk-otc.c. Thanks to both of you!
Can anyone recommend an e-switch firmware that either can already be compiled to work like I’m about to describe or be the best starting point for me to make changes from?
-Single taps of the electronic button are on/off (it’s single mode, 100% only)
-Holding the button or double clicking or really anything else that single taps is a hidden strobe mode.
-Has battery monitoring
That’s all I need. Trying to recycle some e-switch hosts to UV lights for my next GAW now that I’ve amassed some cool UV emitters.
TK, I don’t know if this a big thing to do or not, but could you replace the symlinks in the repository with proper files? Symlinks break everything under bzr + Windows. The main repo used to work fine , but it looks like a few symlinks got carried over from the FSM branch.
Unfortunately bzr has no option to ignore them (so you could paste them later by hand).
That’s odd. It sounds like either a checksum collision happened in the Windows Defender database or a file got marked erroneously. I’m not sure if it’s something I should try to fix. I could probably change some spacing or comments to change the file’s checksum, but no-op changes like that are typically discouraged and it might not even work.
Right, I should replace those.
It’s hard to avoid symlinks sometimes, and it’s weird that Windows still sometimes doesn’t have them 40+ years after they were invented. The feature was added to NTFS 3.1 in time for XP, but it wasn’t made available to user programs until Vista. More importantly, it’s not in FAT or FAT32 or exFAT, so support depends on how the user’s hard drive was formatted.
Anyway, fixed in the latest branches for trunk and fsm. Instead of linking to supported configs, the build scripts now just copy all configs before each build.
That was exactly it, thanks so much!
Great, thanks a lot. 
I wasn’t even aware Windows has support for symlinks. But then again, I don’t get why bzr can’t just parse the link and include the target. Hmm……
BTW, in the GT builds, is there a reason why the PWM levels are at 10% current (and not lower)? The LM3409 can go lower than that, this would make proper moon levels possible I think…
Because that is what DEL determined to be the most effective on the hardware he designed. I didn’t test other settings, because it seems to work pretty well already.
Hi,
After playing a bit with fsm / anduril I took the liberty of fixing two smaller bugs.
One was that the main LEDs on the D4S are on when changing the standby-aux-led-mode (locked mode, click-click-hold)
The other one was a more configureable strobe-selection since I for myself don’t want a lightening mode.
Hardcoded IDs killed the candle mode as soon as one other mode was removed.
For now, I pushed the changes to this branch: zeroflow-fixes : Code : Flashlight Firmware Repository
Is this how you want changes to be handled with your repository?
Yay!
This is literally the first time anyone has ever branched the repository on Launchpad. It might also be the first time anyone bothered to match indentation styles.
That really makes things a lot easier for me. Thanks!
Anyway, I’ve reviewed the code and made some changes. After some testing, I’ll get it merged and published. The changes so far are:
- -fshort-enums, to reduce ROM size.
- Re-replaced switch/case clauses with if/else, to reduce ROM size.
- Rotated candle mode to index zero, saves another 20 bytes and makes it default again.
- Applied the enum approach to eeprom handling, to make things less hardcoded.
- Made it possible to disable all strobe-group modes.
- Reduced ROM footprint of aux LED fix.
- Fixed some spelling errors.
The compiled size is now slightly smaller than before the branch, even with the aux LED fix added. I’m taking a break for now, but should be able to test things shortly.
@ Toykeeper, I came across something in Anduril today that puzzled me a bit. I had the opportunity (because of a misplaced item) to use my D4 with Anduril as a bike light last night and this morning. What puzzled me was that it did not seem like I could ramp the light down in intensity in bike flasher mode, which is in the strobe group I believe. I tried ramping up, releasing the switch, the pressing and holding to ramp down. I just managed to ramp all the way up, which put a bit a crimp into battery life, especially as I was running an 18350 cell. When I got home tonight, I found that in bike flasher mode one needs to click, release, and then click and hold to ramp down. In ramping mode, there are two ways to get the intensity to ramp down. One is to click, release, and then click and hold. The other is to click and hold, which enables ramping up, then release, click and hold again, which starts ramping down. For some reason I have trained myself to always do the latter (ramp up then down, less efficient) rather than just click once then hold to ramp down. I will be doing this from now on, so when I do use my D4 as a bike light again I will remember the way to ramp either way.
Guessing this is a bit of an oversight, and not intentional?
Tested, merged, and published.
I added some other stuff too, which reduced the overall ROM size a bit.
The most recent builds are here:
http://toykeeper.net/torches/fsm/?C=M;O=D
It’s a known issue that I left in to save a bit of space. While writing that part of the code, I didn’t really feel like duplicating all the auto-reversing logic from the main ramp. IIRC, the auto-reversing added enough bytes that I wasn’t sure it would be worthwhile.
It should probably be fixed, but it may not happen until a day when I’m feeling clever enough to find a way to do it without increasing the code size.
I also tried that, but couldn’t get the existing size-checking macros to work…
Otherwise: Yay, my first code changes to an existing open-source project were accepted 
I have a question regarding Firmware in general. So I was reading through the code of Ramping OSv3. I got some basic C knowledge because I learned that like fifteen years ago in School and haven’t done much since then. But what I couldn’t find is where are the events defined? Like ev_click1 etc.?
Or another example would be the power levels. How does the driver know what power level 1 or 150 is?
That’s defined somewhere in the parent folder. Should be in fsm_events.h or so.
Everything in the Anduril folder is just the UI code while event handling, PWM modes, ADC reading and so is done in the fsm code
Antivir false positives are bugs and should be reported as such.
Though my experiences with such reports were plainly terrible.
As to symlinks- ms has its own link format. And *nix compatibility is not a feature they desire.
For that, look in anduril/cfg-*.h, which defines the ramp values for each supported hardware target.
Please help me with bistro firmware. The Hi-Lo mode order doesn’t work properly. It creates random modes like if i am on mode group 6 which has 7 modes including moon, the hi-lo mode order creates modes like high-low-high-moon-high-low-moon. I tried different mcu and downloaded the stock hex file from repository but still the same. What seems to be the problem?
Might be switch bounce. Have you tried a different switch?