That’s right, and I’ve described that earlier here: [New + Review] YLP Unicorn 1.0 (1x18650, LH351D, backlit side switch, magnetic tail, TIR lens, ramping) - #122 by Inferion
Which one of these do I use again? The shipping discount is real.
The 10 degree beaded optic is like 10% or less loss in lux with no visible rings anywhere. hot spot fades into corona which fades into spill.
The 5 degree smooth has basically the same hot spot (it’s not more throwy) as stock but changes the corona up a little, maybe slighly less rings but it’s still not smooth by TIR standards.
The 15 degree smooth turns it into a bat signal (10-15% loss in lux) but the hotspot is very wide, smooth and round with corona and spill fading to nothing quickly. (reminds me of my Carclo smooth narrow triples with LH351D)
I think I like 10 degree beaded the best of the ones I tried followed by 15 degree smooth.
Good info. Optics are on my long list of things to order.
I never got round to ordering the unicorn with the discount though so I’m waiting/hoping for that again.
Just received the light and sadly notice some dirt/finger print on the inside of the lens. Is there anyway to open it and clean?
Press the head against a sticky/rubbery surface and unscrew the bezel.
It can be unscrewed? Not press fit?
Yes it can be unscrewed.
And without OpAmp, like in Unicorn? MCU+FET and nothing else?
That’s weird. In my view, programmers are also PCB and schematic developers. These tasks can’t be addressed separately. And there are enough people to write programs.
I don’t think so. Problem is the technical feasibility of these ideas and they can be anything – this doesn’t affect the implementation of the current regulator. There are will still be the same approaches and requirements, no matter what we use for UI. Even type of driver doesn’t matter much. Linear, Impulse, with external stabiliser or software, for 50mA or 50A…
It is, for now, but I’m thinking to move to a pre-calculated tabular version. That’s faster, more flexible and convenient and takes similar amount of memory.
I now have a resolution of 160 steps, and it is enough. 160 steps is not so much for a tabular version with a depth of 16 bits (a total of 320 bytes per profile). This also does not affect the thermal control, because it takes effect after the UI with all its transformations. It modifies the Iref, that was set by UI before it arrives at the input of the current regulator. This is a system mechanism, isolated from the UI. And it does not cause any problems, so the UI can be implemented as you like …
Clones of fairly simple interfaces, which I can write in a few hours myself? Could a completed engine be so flexible and versatile to allow you to implement at least some non-standard functionality as quickly?
What I need right now:
- Do you have a stack of returns a step back implemented in FSM (I’m still struggling to do this with so many branches, and I haven’t gone beyond one step)?
- And what about predictions of further actions of the user in order to execute commands even before completion of their activation by user? With an analysis of the commands themselves, to make exceptions like “if you now need to preload the turbo, but it will be followed by the moonlight - it’s better not to preload the turbo, because a prediction error is more harmful than a good forecast”. It used to be easy to do, but now the interface has become amorphous and this mechanism should automatically change its behavior according to the situation. And without it, the interface is laggy.
- How does it work with context, transmitted between commands to each other (transmit brightness to a beacon, for example)? To manually drag through the variables?
- How easy is it to implement a configurable UI like Unicorn? Will it facilitate this task?
I’m not familiar with FSM. If it has necessary functionality for implementation of all that, than it’s interesting indeed.
It may help. If you reserve at least 16 first registers (R0-R15) for assembler inserts, the problem can be considered solved. It remains only to figure out how to explain to GCC which cells in RAM to use to communicate with assembler interrupt handlers.
And I have a 4-channel buck on ATtiny24 (located on one side of the 17mm board), and there all 4 channels work in CTC mode (250kHz, 32 steps) without any issues. Since unused Comparator C is only available on timer 1, the timer 0 is reset by interrupt of the timer 1. And thanks to ability of the assembler to strictly plan clock cycles - everything works as it should. In addition, 32 cycles are enough for the DSM of all 4 channels and there is still time left for the background loop.
And another example:
I once developed an ultrasonic positioning system for industrial machines in rooms (where GPS does not work, and its accuracy is worse, than millimetre, anyway). There the slightest jitter of the transmitter led to noticeable errors in measuring the distance to it, and again the assembler came in handy. With it, the main influence became the air flows in the room …
There are fewer latency requirements thanks to hardware synchronization of OCRXX timers over timer overflow events. But this does not cancel the requirements for code execution speed. DSM must have time to calculate everything before the end of the PWM period. And this is, well, a dozen or two clock cycles for several channels. There is no time even to save the context onto the stack…
That we’ve been translating for more than a week this time >_<…
[From translator] And this one as well. That’s on me. Sorry, I’m kinda busy and lazy. Bad mix, I know.
What do you think if I write in Russian and you will try to deal with google translate? ))
Haha sorry inferion! I tried that before this light was released and the prototype was on Fonarevka, Google translate didn’t do a very good job at all.
Just spent few hours playing with my new Unicorn 1.0 and I am impressed.
Swapped stock TIR lense for 25degree from Convoy store.
UI is very good. Lighted button is fantastic. Tint is very good. FW3A will stay at home for some time now 
"That’s weird. In my view, programmers are also PCB and schematic developers. These tasks can’t be addressed separately. And there are enough people to write programs."
That's about 98% false - I've been programming for 42 years and can't design a PCB or draw a schematic. Here on BLF, it's again, not 100% true, maybe about 50% false. I work with EE's every day - they do the board designs, I do the firmware -- it works for me.
I heard there is a mod to make the button easier to press, but I can’t find the info on Fonarevka (and google translate is awful with Russian). Does anyone know how to do it or can link to the posts showing it?
I haven't tried it very much yet with Russian to English translation but maybe it's worth taking a look at www.deepl.com. It's working with artificial intelligence and translates quite well between German, English, French and some more languages.
I’ll give that a go, can’t even find the mod itself even though I read some of the members there talking about it vaguely.
Thanks for the measurements! Looks like they got a good tint bin compared to the other LH351D 4000K emitters we’ve come to known. It’s still on the green side but on high, it looks fairly acceptable.
Does the Yajiamei optics lower the DUV?
It already comes with similar optics and no glass so I don’t think it made much difference
That could work in case of little mutual integration. But otherwise I don’t know what schematic will look like with routing taken into account, how PCB engineer would like to change schematic and how programmer would want to change it, accounting for features of MCU and software.
For you to design convenient for rouring schematic, you have to understand routing. Moreover, I have to change schematic during routing. Somewhere some parts could be thrown away, somewhere they shoud be added, and somewhere it’s more convenient to rearrange functions of MCU legs.
To devise the least redundant schematic you have to understand the limits of MCU and that’s programmer’s job…
PCB engineers also have to be proficient in cirquit analysis and transients, even more than cirquit engineers. And cirquit engineers have to be really good at MCU architechture and methods that will be used by programmers. (E.g. calculation of ADC lines)
And so it turns out these three guys have to be good in these three subjects simultaneously, and to work in concord somehow.
Here: Показать сообщение отдельно - YLP Unicorn 1.0 - волшебная рабочая лошадка!
A cap, made out of hard material, is put on a “stub” in the cover of the button. And black piece of plastic, that stick out of button itself, should be grinded off as deep as height of the cap:
I’ve used small electrolytic capasitors, but I didn’t like the “click” I got.
Another option is to use these pistons:
But I haven’t tried that.
I got mine in on Saturday. I really love the light! It has replaced my Zebra SC62w-L2 in the rotation.
Once I got it into ramp mode, I was happy. I do wish it would go lower. I love that it has no PWM visible anywhere in the range. The tint is pretty darn good, but the beam is a little ringy.
I use mine a lot too. With 10 degree beaded optic there is no rings and fills a good niche for me as something between multiple TIR (triples,quads) and reflector (too throwy for close up)