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
1 Thank
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.
3 Thanks
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.
2 Thanks
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.
2 Thanks
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.
yeah i understand many plastics filter uv rays. but i saw somewhere glass tir lens. wouldn’t that work? if it was glass? idk, maybe i read the description wrong and glass tir doesn’t exist
edit*
found what i saw
43mm
34mm
There aren’t any glass TIRs in the right size (that I’ve been able to find, 10mm), and also there are plastic TIR lenses meant to be used with UV (-A, B, and C), they’re usually made of silicone.
Using a reflector is just a cheaper alternative to a custom TIR while keeping compatibility with a ZWB2 filter.
1 Thank
reflector makes more sense now being the huge difference zwb2 filter makes.
i can’t wait!
@ToyKeeper I see you posted a new 3ch firmware, is that one for the “151” model code? Or does that matter?
The emisar-d4k-3ch firmware is only for model number 0151.
The details might change, depending on if Hank wants any more changes made. For now though, it has 8 channel modes plus another 7 for RGB aux.
- main 2 LEDs only (8/16/16 wiring) or LED 4 only (16/16/8)
- 3rd LED only
- 4th LED only (8/16/16 wiring) or main 2 LEDs only (16/16/8)
- all 3 channels (equal amounts)
- 2ch blend (3rd + 4th LEDs, 8/16/16 wiring)
- 2ch blend (3rd + 4th LEDs, 16/16/8 wiring)
- 3ch blend (HSV style)
- 3ch auto blend (red-warm-cool style, led4-led3-main2)
Modes 1-5 are enabled by default, and 6+ are hidden.
The user can set a channel mode for ramping, blinkies (battcheck), and each strobe group mode. The “hidden” ones are only hidden in the main ramping mode, and I recommend turning off as many as possible so it’ll be easier to switch between the ones which remain. Like, enable only modes 1 and 5 if you have W1 or a color on the main 2 LEDs and warm/cool white 519A for flood on LEDs 3 and 4.
I’ve only been able to test it on a RGB model, which isn’t really what it’s intended for. The RGB model is 0152, and the proper firmware for that isn’t available yet.
It’ll show voltage colors during use on the button if you have a RGB button. It also supports a single color button, but it doesn’t show voltage and I haven’t been able to test directly since I don’t have one with that type of hardware.
This build is also the first to use the new “smooth steps” feature. It rounds off the edges in stepped ramp mode, and when turning the light on/off. The user can enable/disable the feature, but it’s currently hidden deep in a menu… Advanced UI → Ramp → 10H menu → Option 5: 1 click for smooth steps, 0 clicks for hard edges. It’s on by default.
While getting this build ready, I made some API changes which will require fixing every other light… so I plan to do that soon and then publish a whole new batch of builds. The “smooth steps” thing should work on everything with a 16K or bigger MCU (attiny1634, attiny1616). Old 8K models could do it too, but would need other features turned off to make room.
4 Thanks
Thank you!
Another question, when you say the RGB model (152): the triple channel I have is:
- Main: Two SST20 red
- W2 Green
- W2 Blue
But, it shows a 151 model code. So does that mean that when you make the 152 available, the 152 would be more applicable?
Yes. You have the 0152 hardware, but the firmware doesn’t exist yet so it uses 0151 firmware for now.
In the mean time, the current 0151 build should be nicer than the earlier 0151 build it shipped with:
https://toykeeper.net/torches/fsm/anduril2/anduril.2023-08-28.emisar-d4k-3ch.hex
Er, also, for anyone who tries it… could you let me know if your LEDs 3 and 4 go in the correct order when changing channels? It has been tricky to confirm the order, to make sure the firmware’s channel order matches the web store’s channel order. If those aren’t right, I may need to swap the two 16-bit channels in firmware to put them in the right order.
1 Thank
I put on the 8/28 build - they do cycle as you wrote in your earlier post. However, (with my RGB) the W2 Green channel and W2 Blue channel (only) do not ramp up/down. With all the channels on, I don’t see those same (W2 Green and W2 Blue) ramping up/down either - only the two SST20 red ramp up/down. Same with the “mode 5”, where the W2 Green and W2 Blue are on together - it will not ramp up/down.
I tried to take a video but it is kinda garbage.
That’s very strange, and not what I see on mine. Definitely needs more investigation, since it shouldn’t be doing that.
When cycling through the modes with Ramp 3C, does it go red, green, blue, white, blue+green? I’d like to confirm that’s the order it uses. Mine does red, blue, then green… and I’m not sure if it’s because Hank swapped LEDs 3 and 4 on the MCPCB, or if it’s because the firmware has the two channels mixed up. It should be RGB, not RBG.
When swapping modes (3C): Red, Blue, Green, white, blue+green. Here is the order:
1 Thank
Thanks, it sounds like maybe the firmware needs to swap its internal definitions of LEDs 3 and 4.
I’m still trying to figure out what would cause blue and green to not ramp though. If it worked in channel modes 4 and 5, but not in modes 2 and 3, it would make sense. But all four of those modes aren’t ramping the blue and green LEDs, I don’t know what would cause it.
They ramped when using an older firmware version, right?