[New + Review] YLP Unicorn 1.0 (1x18650, LH351D, backlit side switch, magnetic tail, TIR lens, ramping)

bmengineer · 2019-10-17T20:27:21.000Z

Dang Inferion, you sure have a lot of these things!

contactcr · 2019-10-17T21:11:26.000Z

Inferion:

timbo114:

pre-production sample in photos - maybe that’s why it wasn’t glued eh?

Here are release versions: Показать сообщение отдельно - YLP Unicorn 1.0 - волшебная рабочая лошадка!
But everything unscrewed as expected.

Just to summarize this link basically says they headed up the head first and it released by hand (kind of like hot glue I guess). So it seems the key is HEAT!

Inferion · 2019-10-17T21:28:48.000Z

contactcr:

Just to summarize this link basically says they headed up the head first and it released by hand (kind of like hot glue I guess). So it seems the key is HEAT!

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

contactcr · 2019-10-19T18:43:28.000Z

Which one of these do I use again? The shipping discount is real.

contactcr · 2019-10-20T18:04:58.000Z

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.

hodor · 2019-10-21T12:06:48.000Z

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.

bts · 2019-10-23T03:59:29.000Z

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?

SammysHP · 2019-10-23T04:07:09.000Z

Press the head against a sticky/rubbery surface and unscrew the bezel.

bts · 2019-10-23T04:10:30.000Z

SammysHP:

Press the head against a sticky/rubbery surface and unscrew the bezel.

It can be unscrewed? Not press fit?

timbo114 · 2019-10-23T04:37:39.000Z

Yes it can be unscrewed.

Inferion · 2019-10-23T06:30:57.000Z

ToyKeeper:

It works on a linear FET driver. This is used in the Emisar D1S V2.

And without OpAmp, like in Unicorn? MCU+FET and nothing else?

ToyKeeper:

The main reason these are not used more often is because there are not enough circuit engineers to keep up with the demand for new circuit designs.

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.

ToyKeeper:

I think perhaps one of the biggest changes is less about the language though, and more about the abstract ideas used.

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…

ToyKeeper:

If I understand correctly, Indigo calculates brightness or power on a linear scale, and does math inside to convert linear brightness into a curved ramp?

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.

ToyKeeper:

That seems like a good way to do it, and has advantages like high resolution and straightforward thermal control.

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 …

ToyKeeper:

With it, I was able to create clones of a few popular flashlight interfaces in just a few hours.

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.

ToyKeeper:

I think I found a gcc option to bind registers, or restrict which registers it can use. Maybe that helps?

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.

ToyKeeper:

I implemented a 4th PWM channel in C, using a PWM timer interrupt to turn an extra pin on and off. It works, but sometimes it flickers when two interrupts happen at the same time. So I hope to greatly reduce the time used by each interrupt, to improve timing consistency.

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 …

ToyKeeper:

To implement DSM seems much the same, except instead of turning a pin on or off, it would change the duty cycle for built-in hardware PWM. It seems like it should work, but I haven’t tried it yet.

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…

ToyKeeper:

Anyway, long message!

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.

ToyKeeper:

It is good to talk to someone who understands these things. I hope we are not boring everyone.

What do you think if I write in Russian and you will try to deal with google translate? ))

bmengineer · 2019-10-23T10:35:17.000Z

Inferion:

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.

dropman · 2019-11-19T17:40:49.000Z

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

Tom_E · 2019-11-19T19:05:18.000Z

"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.

BurningPlayd0h · 2019-11-19T20:16:04.000Z

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?

Lux-Perpetua · 2019-11-19T20:23:04.000Z

BurningPlayd0h:

[…] google translate is awful with Russian […]

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.

BurningPlayd0h · 2019-11-19T23:10:22.000Z

Lux-Perpetua:

BurningPlayd0h:

[…] google translate is awful with Russian […]

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.

SKV89 · 2019-12-01T19:11:40.000Z

contactcr:

Low, Mid(ish), High:

CCT = 4073K (Duv 0.0034)
Color Rendering Index (Ra) = 94.1 [ R9 = 80.6 ]

CCT = 4099K (Duv 0.0029)
Color Rendering Index (Ra) = 92.8 [ R9 = 76.9 ]

CCT = 4172K (Duv 0.0004)
Color Rendering Index (Ra) = 91.8 [ R9 = 74.2 ]

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?

contactcr · 2019-12-01T23:29:07.000Z

It already comes with similar optics and no glass so I don’t think it made much difference

Inferion · 2019-12-10T00:54:15.000Z

Tom E:

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.

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.

BurningPlayd0h:

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?

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.