The difference between relative and absolute is the sticking point here. And every hour spent on driver design is an hour not spent building lights and shipping them accordingly, which adds a different type of difficulty.
Boost drivers have their own limitations, so there is reason to keep both options and allow people to choose which set of limitations they find more tolerable.
I can see it from a logistics point of view. Itās fairly easy to use the same boost driver do 3, 6, or 12 volts. However, if it were easy to do dual-channel and boost in the same light with the space constraints and all, the quad-lights wouldāve done so long ago. That has me inclined to believe that any non-linear D2 would likely be single-channel.
It turns on aux RGB on low, at low ramp levels, and on high for medium or high ramp levels. This doesnāt depend on which channel is active.
The reason why is because some models have a RGB button which should be illuminated during use, and itās connected to the same pins as the forward aux.
Since some models have this and some donāt, one solution would be to produce two different firmwaresā¦ but that could increase the number of emisar/noctigon builds by quite a bit, and makes things harder for everyone involved. So what it really needs is an option to enable or disable the RGB button while the main LEDs are on.
For me personally, I donāt need the button on while the main emitters are on. But I guess it is personal preference.
A couple of posts up, you can see @wolfgirl42 has done a lot of work.
I didnāt notice it on the ch1 because of the higher brightness of the 519Aās probably.
I love the light in every aspect and it has been my best purchase for a long time. Everyone I show it to has been impressed, especially with the cyan/pink shadows.
I sincerely hope this isnāt the apex and weāll see some progress even though the lights are really nice as they are.
Again Iām talking about buck driver here. It is not the same thing as a boost driver.
As pertains to the D2, would you rather run the emitters in parallel at 3V (buck) or series at 6V (boost)? Or would you rather enlarge the host to maintain dual-channel while going buck-wild? Personally, Iād go with the lower amperage. The best way to drop amperage without dropping wattage is raise voltage; the opposite of what a buck driver does.
How many D2 owners use both channels and emitters at the same time? Probably not many.
That sounds to me like you would go with a larger host.
Check IRC, was looking for a bit of feedback about the work I was doing on making it configurable 
I am planning to order a DT8K and could not find answers to questions regarding the dual channel versionās Turbo behavior. With FET enabled, only ch1 will be driven, thatās clear. But without FET enabled, on a linear 12A dual channel driver, which is true on Turbo?
This is relevant for my targeted configuration with ch1 being 519a 5700K and ch2 519a 2700K DD.
Because, if option a) is true, FET will only be marginally more bright, as 519aās do not benefit from more than 6A, thus making FET only be really useful up to 24A for four 519a emitters.
On the other hand, if 24A were distributed over 8 emitters, they would be more efficient (lm/W), and thus be as bright as ch1 on FET, possibly offsetting the lower CCT and dedoming losses. It would also make for an impressively rosy beam, mixing 5700K and 2200K.
If b) is true, enabling FET would evidently make sense.
Iād appreciate if someone could help clarify this.
Also, is this behavior going to change with the new multichannel firmware by @ToyKeeper ?
Yes, and you should probably be using the new multi-channel firmware.
If I understand correctly, there are one or two flavors which can be used on a dual-channel DT8K: emisar-2ch, and emisar-2ch-fet
They have different behaviors. Iād recommend the no-FET version when possible, because the firmware for that is generally nicer, but if you must have a DD FET, itās an option. Anyway, the channel modes currently are:
emisar-2ch:
emisar-2ch-fet:
You can choose whichever channel modes you want, and disable the rest.
I generally use the emisar-2ch version with no DD FETā¦ and the channel modes depend on what LEDs the light uses. I typically go with modes 1 and 2 only, or 3 and 4 only, depending on whether I want to toggle between different sets of LEDs or blend.
The other channel modes are still available for strobes and such, even if theyāre not enabled in ramping mode. So candle and lightning can use the auto blend, for example.
If none of those channel modes are what you want, itās reasonably straightforward to add more.
If you want the highest power available though, just get a single-channel light. That way, the DD FET powers all 8 LEDs instead of just 4.
Sorry to bother you, but how do I unhide hidden channel modes?
I just got a triple-channel and canāt tint-ramp channel 1 with the others.
Thank you!!!
In ramp mode, use 9H. It goes through channel modes in order. Release when it gets to the one you want, then it flickers for a few seconds. Click while itās flickering. Zero clicks hides the channel, while any non-zero amount of clicks un-hides it.
Thank you, your service is as quick as Hanks!
I have made a triple channel RGB D1K using mostly off-the-shelf parts. Did it some time ago but donāt think I remembered to post it.
Used an XM-L Color G2 HI (RGBW but white is unused) from Digikey (4000k version) and a Ledil Olga-M optic to smooth out the beam, and connected the positives on the MCPCB with a scrap bit of wire. One of the pads ripped off the original switch so I used a spare where one of the red aux leds was broken.
Build pics below
Semi-finished light, with all the soldering done for now. Not my neatest soldering but it was pretty tricky either way.
Eventually I had to tuck the wires neater so that the optic could sit all the way down and focus properly. I 3d-printed a ring that acts as a spacer and holds down the optic in the host. It is made of PLA+ but the light doesnāt get very hot so it should be fine, seeing how itāll only draw 5A at most.
Donāt think I remembered to take final assembly pics or beamshots so Iāll attach them in a later edit. The color blending isnāt as good as I originally hoped, but it still works pretty well. It might become better with some DC-fix on the lens, but I donāt have any right now.
Random notes:
For whatever reason, when using stock firmware, going through the channels wasnāt RGB despite being soldered in the right order, the order when doing 3C being RBG, not sure why they are switched when using the default firmware. Either way, huge thanks to @wolfgirl42 for helping me by putting together some customized FW for this light.
Thereās also a issue with the ramp shapes, but I havenāt figured out that one yet. I think it has something to do with 1 ramp being for dual-emitter and the other 2 being for a single, so when I switch from blue/green to red it gets a lot brighter, despite the moonlight being the same.
Thereās also a few features Iād like to have, specficially one that synchronizes the color of the main emitter with aux, so that it too can behave like rgb aux (on moonlight). Another nice thing to have would be an auto-rgb mode that just keeps the light in hue-ramping.
EDIT 1: More pics
Amazing job! 
Thanks for taking the time to share it with us! 
Itās a side effect of using 3 channels on attiny1634, which has only 2 16-bit outputs. The other output is 8-bit, which causes a big loss of resolution.
I have some ideas for a workaround, but I donāt have anything working yet. Long-term, the plan is to move to AVR DD, which has more and better outputs.
Honestly I would be fine with just 8-bit ramping. Maybe for this use specifically itād be better to just use 8-bit (or mirrored 8-bit) for all channels.
The workaround idea is to use 8-bit rampingā¦ but also finally add delta sigma modulation, which Iāve been meaning to try for years. Itās a method to increase the effective resolution by rapidly changing the PWM level between two adjacent values, to get an average which is somewhere between.
If that works out, Iāll probably use an internal resolution of 15 bits, so the UI can use 0 to 32767, and the top bit is a way to simulate having a carry flag during additions (which the MCU supports, but only in assembly because C doesnāt expose this feature).
