Ok great, that reduced me down to 2 errors!
I’ll search for the file it wants next.
Edit: Found the .h it was wanting. Built! Thanks guys (gonna leave all the pics but reduce their sizes. If anyone needs them in a future search just right click and open image in a new tab for full size)
Try to paste this:
./.o: …/./.c
instead:
./blf-a6.o: …/./blf-a6.c
Edit. Nevermind
Hey everyone, I’m sure this has been asked and answered before, but I can’t seem to find it.
Can the A17DD driver that comes in the BLF A6 and Astrolux S1 be flashed with any other firmware? I’m looking for the A6/S1 form factor but without the forward/reverse style UI (A6 or Bistro). I’m gifting the light to a hunter that’s looking for a simple 3-mode setup with memory, but I also would like the programmability to add a moon mode later if he wanted it.
I know I could build a light using the S2+ host and a driver from Mtn Electronics that would allow for the guppydrv or Biscotti firmware, but I want to be able to buy a complete light and only flash new firmware if needed.
Thanks!
JonnyC
You can use the same firmware and just remove what you don’t want. This is the easiest way.
It seems to me that most of firmwares which work in FET+1 configuration should works.
In the blf-a6 directory, there’s a file called tk-otc.c. It’s specifically intended for use as a base for creating custom builds for A6 hardware. It sounds like you probably want to comment out the “OFFTIM3” bit, change the hardcoded mode group values, and set memory=1.
Hey JonnyC, I recently my Babka firmware over to the A6. I’m remote right now, so all I have is a GDrive link:
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:
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 