SiteRelEnby

joined 1 year ago
[–] [email protected] 1 points 1 year ago

1ms shouldn't be too hard (would just have to have the code to handle it be in the main loop, ideally, rather than an event handler). If it's significantly under 1ms might be a problem.

 

Since the first M44s will probably be in the luckiest people's hands in a few days, and it is shipping with the new anduril multi-channel branch (unless that changed last minute similarly the buck to boost driver change - but multichannel will still end up as the main branch at some point anyway), thought this would be useful, especially for people not on BLF, where most of the discussion around anduril development happens. Also, note that everything here is subject to change as multichannel is still technically a development branch rather than stable.

You might have seen the LT1S Pro already, which runs Anduril and has 3 independently controllable sets of main LEDs (warm, cool, and red), as well as channel modes that use more than one set of LEDs in a programmable way (e.g. ramping from red to warm white to cool white as brightness increases), but I'm guessing the M44 is going to be most people's first experience with multichannel. I will resist the temptation to go too heavily into technical details here, but if you're interested, here's the bzr (ugh...) repo. It's in C, fairly well documented, very heavy use of feature flags and a few optimisations that seem weird at first but make sense after some familiarity with the codebase. For building for your own modding purposes I'd recommend my Docker builder fork.

So, what's changed?, you might ask. Here's a quick list:

  • On lights with a single set of main LEDs, by default very little will be changed (PWM is significantly improved on some lights with lower lows and a smoother ramp, various bugfixes, etc.) as only the main LED channel is enabled. This means all of the familiar button shortcuts are the same. On dual channel lights, there will by default be several channels enabled - at the time of writing these are: first LED set, second LED set, both LED sets tied together at 50%, tint ramping, auto tint, aux channels (see below), which you cycle through with 3C.
  • On most lights with more than one physical set of LEDs (including aux), additional channels can be enabled, such as using the aux LEDs as a channel (red aux in particular works as a great moonlight mode)
  • When more than one channel mode is enabled, 3C will advance to the next channel mode, and switching between stepped and smooth ramping is moved to 6C.
  • When the light is locked, 3H will cycle through channels
  • Some channel modes (such as tint ramping or autotint) have a user-controllable arg. This is adjusted with 3H, and what it does is dependent on the channel mode - for example, in the ramping mode, it ramps (or instant switches, see below) between main channels, or when in autotint mode, it swaps the two channels around (e.g. on a red/white 2 channel light, swaps whether one colour is the one used at low or high brightness). On channels with adjustable args, momentary turbo is moved from 3H to 4H (IMO this convention makes accidental face-turboing too easy 🤣, but it is what it is... if there's a lot of negative feedback about that here, I'll try to convince TK to change it).
  • To configure channel modes, use 9H while the light is on (advanced UI only). The light will cycle through each channel mode in turn, previewing them using the LEDs. Release on the channel you want to configure, then 0C to disable the channel, or 1C to enable it. This means that while you can't buy an M44 that's physically a single channel, it's easy to turn it into a single channel light. Disable every channel mode but "both", and instant single virtual channel.
  • The channel ramping/switching options on dual channel lights have changed - it is still the first item on the 9H from off menu, but now the number of distinct steps - 0C enables smooth ramping, 1C locks mix to 50%, 2C enables instant channel switching (2 steps), 3+C gives a stepped ramp (e.g. 3C has one middle mix, 4C has two, etc.).
  • To change the channel mode used for blinkies, 3C while in battcheck mode. This will cycle through all channel modes including disabled ones, e.g. if you want your blinkies to use aux instead of main emitters, but you don't want the aux in the main mode rotation.
  • When the light was on and is turned off, the battery status is now displayed with the RGB aux for several seconds. This can be configured with 7H when in battcheck mode - n clicks = n seconds; 0C disables the feature.
  • There is one known significant bug: On lights without forward facing RGB aux (e.g. D1, K1), the aux channels do not work properly as the light tries to display the battery status at the same time. I've pointed it out to TK so hopefully it will be fixed.
  • Currently, not all lights are supported. attiny85 lights probably never will be due to code size, but all the t1616/1634 lights will eventually be.
  • Tactical mode - this is actually the last feature added before multichannel dev builds went public, but I don't think many lights at all are shipping with it yet. Activated with 6C from off, gives you 3 slots with instant-on on 1/2/3/H. 6H to configure, N clicks = level N. level 151 is party strobe, level 152 is tactical strobe, etc. My personal favourite config is level 150, a light-dependent level that's appropriate for general use, then level 152 (tactical strobe).

Something else I've been trying to get merged or otherwise implemented is a shortcut to go back one channel - if you have a lot of channels enabled (on some of my dev builds I have 16) - if you think that's something that would be interesting to you, I'd definitely be interested to see how many people.

While I'm not ToyKeeper but I am probably one of the more knowledgeable people around about anduril (I've fixed several bugs in this version and make modded versions), so if you have questions or suggestions for this post, feel free to ask/post them.

If you're looking to try it out, I usually maintain builds of the current latest version. The current one is 721. Builds (with small one-line bugfix added by me that will probably be in the next release): https://mega.nz/folder/tssySIjb#ysEIdciNIEh9epgCBjpsO. emisar-2ch is a special build that should work on most dual channel Hanklights (D2, D4/KR4 family, DT8/K DM1.12, etc.). Also note that as of v721, no lights are currently supported for using the FET where one is usable in a dual channel setup. It's probably coming soon, and it's on my projects list to hack on too.

[–] [email protected] 1 points 1 year ago

https://spicy3dprints.com sells some really nice battery cases, including small sizes.

[–] [email protected] 1 points 1 year ago

Glass "occlusion devices"?

[–] [email protected] 1 points 1 year ago (2 children)

I don't really know much about neopixels, what do they need in terms of control, does it have to be a constant signal or can they just stay in a mode until another mode is set? How many MCU pins do they need?

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago) (5 children)

Aux can't be set to anything but high or low, so advanced colour mixing can't be done, if that's what you mean.

It is possible in theory to use some colours on low and some on high at the same time, but the brightness difference would make the low invisible.

Also, it can't be done with PWM because the MCU wouldn't be able to sleep when the light was off/locked, and there aren't enough free PWM counters IIRC anyway.

Maybe if there was a smarter RGB LED, that could have 3 values set via serial and it has a chip on it to do the processing and adjust its outputs, but such a device would be too large to fit where the current aux LEDs go on any light.

[–] [email protected] 2 points 1 year ago

Well, the fact that I don't feel comfortable using that specific term aside (in terms of not being from a related culture), not specifically. Always liked sharks but they were never my favourite animal specifically. Personally, I'm more wolflike with some dog traits. Maybe a bit of fox in there somewhere too.

[–] [email protected] 1 points 1 year ago

Spinnnnnnnny...

[–] [email protected] 3 points 1 year ago* (last edited 1 year ago)

Maybe a bad reflow giving poor heat conductivity to the MCPCB? Since the temperature is measured at the MCU, that could result in an LED overheating without the MCU going into thermal protection in time.

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

In general, recharging them before use is better - if you're preserving battery life as much as possible the ideal profile is to charge them to ~4.1V, use until ~3.5, then store at 3.6-3.7 until charged for next use, ideally minimising time sitting at full. Going below 3.4ish takes progressively more out of the battery life.

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

Everything but lithium primary or eneloops in a light with a mechanical switch will have battery self-discharge (bonus: neither of these two battery chemistries leak). An e-switch adds a bit more parasitic drain, so the best bet for a light that won't be used for a long time is CR123A or white eneloops, and if you're not sure what the switch type is, you can just break the contact of the batteries.

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago) (1 children)

Hmm, if a watch counts as a light, then technically my most expensive light purchase is my phone...

...oh no. Quickly, what light costs more than an S23 Ultra? 🤣

[–] [email protected] 3 points 1 year ago

The world would be a lot better if there was a lot less of it. Simple as that.

view more: next ›