Is there a post somewhere with this info? I can’t seem to find anything.
Except the new Convoy drivers are regulated and support 6V emitters, unlike the simple FET+1 drivers of old. Both the new Convoy boost drivers and Hanks boost drivers use the mp3431, Hank could bump up the max current pretty easily with some higher quality components though it wouldn’t make moonlight mode any lower
There are 70cri and 80cri versions in 6500k, but not easy to come by. I’ve tried the 80cri 6500k dedomed and it’s pretty nice: https://www.reddit.com/r/flashlight/comments/wfn0om/new_nichia_519a_6500k_r8000_80cri_dedomed_in/?rdt=63729
![]()
Does anyone know how hard the XM-L2 Color HI can be pushed? I am thinking staying at 2A to be safe (factory rating is 1.75A), but I’m hoping 4-5A so that it matches colored W2 in output.
Going to build one into an RGB D1K (behind a TIR) but I don’t want to burn out an expensive and hard to find emitter.
Three questions about the 719A:
- What are lumen/candela numbers in the D1 and DM11?
- Will it work with the B35AM driver if I were to emitter swap a light I already have?
- It comes with an OP reflector in the D1; is there also a smooth reflector that’s compatible?
I can probably answer one of these. I have a D1K 719a 5000K, but I also have a D4K 719a 3000K.
For the D1K, I measured 667 lm on turn on, 654 lm after 30 seconds. This seems low, so I need to verify.
For the D4K, I measured 1749 lm on turn on, 1054 lm after 30 seconds.
Thanks for the measurements. I’m most interested in candela for the single-emitter lights.
That does seem low for the D1K. Zebralight gets numbers like that, but Emisar typically drives emitters harder than Zebralight.
You can’t drive the 719a hard so these numbers are to be expected AFAIK.
You can drive the 719A much harder than the rated 1.5A. 3.5A damages it. Convoy seems to be shipping 2A, which should be on the order of 950-1000 lm OTF. 2.5A is probably still safe.
Looks like i’ll have to swap resistor in my D1 719…
I measured my 719A a bit higher in first second, see post here Comparison Original and DIY in B35AM, seems to be the same driver:
HSV would be great, as would a RGB colour fade mode.
HSI please!
I haven’t heard of HSI before, but it’s very similar to the colorspace I’m planning to use.
The UI has a 2-dimensional color space mapped onto 3-dimensional RGB. Ramp sideways to change hue, and ramp up-down to change brightness. But the brightness is a combination of saturation and value:
- Bottom half of the ramp goes from black to fully-saturated color at maximum brightness.
- Top half of the ramp goes up from full color to white.
Additionally, because linear crossfades don’t look great, I’m hoping to use a cosine-shaped crossfade between LED channels. At least, if there is enough space in ROM to hold yet another data table or two.
Probably because the current is too low or because it’s only low and hi?
Next week I test maeerxu and I can send a detailed video if you need
Do you think 3 degrees of control would add too much UI complexity? Or is the MCU not capable of holding that much (I assume) LUT data?
No, it’s simply because linear crossfades almost always look not-great. The standard HSV color model uses linear crossfades, but the result doesn’t look natural:
Do you see how it has six “spokes” like a bicycle wheel? Three bright spokes at yellow, cyan, and magenta… and three dim spokes at red, green, and blue. It almost looks like That’s caused by using linear crossfades.
It’s cheap and easy to calculate, but doesn’t look very good in practice. Moving around the circle makes it feel like it’s going over a series of bumps and valleys with sharp points. Instead, it should feel like it’s only a smooth, flat color change.
So I made a different color model which fits better for this purpose. I’m just not entirely sure where will be enough space for it on the MCU, unless I remove other stuff to make room.
Do you think 3 degrees of control would add too much UI complexity?
Yes, it’s tricky to fit a 3rd axis into the already-overloaded 1-button control scheme.
I’m hoping to have 3 axes to control for at least the fake-white mode, but I’m not sure how yet. It’d let the user set ratios for the 3 channels, then use those ratios in the “white” channel mode. But since channel modes only have brightness plus one free parameter, I’m not sure where to put the other two.
Ok gotcha!
An alternative is add 6 more RGB so with 12 is less linear?
Do you think 3 degrees of control would add too much UI complexity? Or is the MCU not capable of holding that much (I assume) LUT data?
I hope it is possible too, the 2.5D UI limits quite a bit of the color space, and removes the ability to have desaturated colors at lower brightness.
I’m hoping to have 3 axes to control for at least the fake-white mode, but I’m not sure how yet.
Would it be possible to use 4H to ramp the 3rd axis (saturation/whiteness) instead of using the upper half of the vertical ramp?
I don’t remember it being used by anything in the UI, and there’s a few things that I think wouldn’t be as important to keep on an RGB light to make space.
Also, what are the channel modes other than the Hue ramp and 1 channel at a time?