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:
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.
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:
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.
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?
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.
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?
i went to build an emisar 3 channel and noticed there is not uv option. will there be an option to add uv 365 in future? i wanted to build white red uv. ty
sorry if mentioned before. this thread is huge
You can’t have UV with the plastic TIR optic, it blocks all UV light.
Maybe. There could be a mode for that, if there’s room. I’ll need the black-to-color-to-white ramp to make the user-defined color patterns work though. The color pattern animates continuously, but if the user presses the button, it goes into “overdrive” until the button is released. This was originally used for lightsabers, to produce a “clash” effect when hitting something, but it can also give an interesting effect for light painting.
To be determined.
Probably a “white” mode, a stepped color mode (r, r+g, g, g+b, b, r+b), a smooth color mode, perhaps a hidden second copy of the above (same UI, different colors) so you can assign different colors to different strobes and such, a random color mode, maybe a warm-to-cool auto tint mode… and some UI modes which bypass the channel modes entirely and just control colors directly.
It allows saving the channel for the ramp mode, the blinky modes, and each strobe group mode. So if you want a red candle, a pink bike flasher, a white party strobe, a variable color tactical strobe, blue lightning, and white aux battcheck… that’s a thing it can do now.
I wanted the same build, there might be an option in the future, but it will not have aux on the front, the optic blocks UV so it is drilled out and uses a small OP reflector instead.
The front AUX might not be there though, the reflector is too big for the holes in the aux PCB.