Ha! I meant L4 too :)
Every time you turned off the light it would just default back to off, unless you set the lowest mode to something other than off then I'm pretty sure it would default back to that mode.
I haven’t seen this mentioned anywhere so I guess it’s a no brainer to connect the switch to ground? But do I wire star 4>switch>GND for the Dual Switch version?
Yes.
Dang wight. You fast. :bigsmile: Thanks again.
Edit: Anyone in the mood for a sandwich? 
Everything worked well and looks fairly trim and proper. I don’t think it warrants its own thread, but what I did was remove all of the components from the stock driver contact board and then made the necessary connections for the switch and power. One leg of the switch is jumped to ground, the other leg is connected to a wire which wraps around the flat side of the board and makes its way up to star 4. I didn’t have any really tiny wire (or bother to use a single strand of copper) so Kapton tape was necessary to prevent the switch wire from shorting on the driver retaining ring after the driver was installed. The mode spacing I went with was 12,70,255. It isn’t night time yet but the spacing seems pretty good. I gas de-domed an XM-L2 U3 on a 16mm noctigon (didn’t have any 20mm ones) and bolted it up. The holes that the stock LED board mounting screws “thread into” are actually not threaded at all, but they are the perfect size for a 4-40 cut tap so I tapped them and used some 4-40 BHCS. 3/16” is a good length.
Now I just have to make the rifle mount. I’ll update this post when I’m done with it in a few hours.
————————————————-
Edit: There we go. Now off to the folks to see if it fits….
Edit: nope, I underestimated the size of the barrel. I’ll remake it with a hinge and a pull pin screw so the light can be removed instantly. My parents have too few lights to let it sit on the rifle unused so it should be removeable easily. Good point about the physical connection of the driver in this application wight; I hadn’t considered it much. Fortunately it is only a .22 and has virtually no recoil so I think the solder joint on either side of the switch housing will suffice in this instance.
No problem. Your work looks good. One thing to consider, especially for a rifle light IMO, is the physical connection between the two PCBs. It looks like your only rigid physical connection is the switch casing being soldered onto the GND ring of the driver. If that’s the case consider adding epoxy or something to stiffen up the bond. In fact, consider air-wiring that connection and then using epoxy/whatever to do the physical connection. Just my two cents!
Woah! Snazzy looking. :heart_eyes:
I realized that I’d spoken out of turn as soon as I saw your snazzy barrel-clamping mount made up for such a small barrel. I agree with you.
How did you make that clamp? That's really nice. Are you hiding some nice machines and machining skills from us? ;)
Looking back at your posts:
1.) Very nice firmware flashing guide!!
2.) Did you ever develop those Mag heatsinks?
Thanks fellas. :bigsmile:
Yea, I’m a professional machinist and happen to have a Haas vertical machining center in my garage. I really need a turning center though. In due time…
I did develop the mag heatsinks but I’m still working on the battery carriers. It’s going to be a whole kit.
Ive recently thought about offering machining services to BLF. I saw Nitro’s x6 heatsinks thread and thought… I could beat the price he was quoted by a few dollars per part. I’m more focused on starting a full fledged flashlight manufacturing company at the moment though.
There we go. This new clamp design is almost sufficiently complicated, just how I like it. (when you see my mag heatsink you will get the joke)
On second thought… I think I will make a post about this L4 build when it’s done. Enough derailing this thread!
Edit: From concept to reality. It better fit this time cuss that took like 13 hours…. (I used my “micrometer eyeballs” on the barrel because I didn’t bring a measuring tool) I made the “T screw” handle bigger so it would be easier to use. More shots to come in the post I’m making about the build.
Say fellas, I think I will use the STAR firmware to customize the driver functionality in my mag kits, but one change I need to make is memory off by default.
I presume I need to change the following line, but how exactly?
memory = ((PINB & (1 << STAR4_PIN)) > 0) ? 1 : 0;
That is one sweet looking bracket you made Hoop. Have you a picture of your mill?
Just swap the 1 and the 0, and it’ll reverse the meaning of having that star soldered. So, “0 : 1” instead of “1 : 0”.
Or if there’s still room left, you could add a second line to logically invert it: “memory = !memory;”
With drivers that don’t have an off-time capacitor, I definitely prefer this “no memory” or “short cycle memory”, so it always takes 3 taps to access mode 3, always takes 5 taps to access mode 5, etc. Going from 3 to 5 still takes 5 taps because the saved mode resets back to zero after the light has been on for a full second.
But I like off-time methods even better. It can still have no memory, but it then becomes one tap to go from 4 to 5, and one medium tap to go backward from 5 to 4, instead of taking 5 taps and 4 taps respectively. And it will always start in the first mode after being off for a few seconds, regardless of what you did before. (short cycle memory has sort of a bug where if you tap 4 times quickly and immediately shut it off, it’ll start on mode 5 next time because it wasn’t on long enough to reset back to zero)
The other thing I like about off-time methods is that it allows for shortcuts or “negative” modes. Basically, turn it on, then instead of doing a short press to go to the second mode, do a medium press to go backward. It can do something different in that case, like turbo or battery check, or whatever. There can even be more than one “negative” mode.
Oh, um, but if you want the end user to be able to configure the modes, regular STAR firmware is the way to go (and a driver with solderable stars on the back).
Thanks ToyKeeper! Since my mag kit will be targeted to the general public I want it as simple as possible, so no memory. Three partial presses of the mag switch to get to mode 3. Always start in low mode from OFF.
I actually made a thread on CPF about the whole garage conversion. I bought all the required components and made the fixtures for a 900 watt Nichia 219A lighting setup for the garage but still haven’t finished it…. Will be over 40,000 lumens of passively cooled light from my fixtures once I bother to finish it.
I just tested out my mag kit with the fresh STAR firmware and no memory. I don’t like how it functions. Just like you said, it always starts from low when changing modes from an existing mode, so if I am in medium and I want to go to high, it takes three clicks instead of one. Ideally the mode would be changed every time with a single click, but from off it would always start on LOW.
I’ll have to give off-time firmware a try once I get some caps in…
In my opinion ontime with “no memory” is 100% intolerable. It’s the polar opposite of offtime with “no memory”. Look forward with hope. 
FWIW, the off-time firmware expects the capacitor to be on the star normally used to toggle memory. So, there is no “no memory” option. You’ll probably have to add that yourself, but it’s not too hard. The issue is that end users won’t be able to toggle it.
Personally, I’d rather sacrifice the mode-order star for this instead, and retain the moon toggle and memory toggle. Always low to high, but at least people can have memory if they want it.
BTW, if you enable mode memory without the capacitor, it’ll still take two clicks to change modes. It’s really annoying. Sometimes it’ll take one click, sometimes two, depending on how long the light has been on.
I still find it preferable to ontime with memory. I don’t really mind short-cycle memory, since the most-used modes are generally at the beginning so they never take many clicks to access… and the least-used modes are at the end where they can be ignored most of the time.
Hmm. I’ve only used ontime with no memory on the bench. Maybe if I used it on an EDC things would seem different. Make no mistake: I also strongly dislike the “sometimes one, sometimes two” taps required by a standard ontime-with-memory firmware.
Agreed. Ontime without memory is preferable to ontime with memory, but still not ideal.