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

Has anyone tried the BLF A6 clip on this light? Will it fit? If yes, then can be a deep pocket carry light. :slight_smile:

Do you have any specs for the clip (like diameter and width of the round part)?

Wizard Pro clips fits, but sticks 1cm above the tail (bezel down config).

Clip slot is 22.5mm diameter and just under 5mm tall.

Top of the clip slot to the head of the light is 50mm.

I didn’t find any video showing the YLP Unicorn on YouTube, so I made a quick demo video:

Very nice :+1:

You can use coupon BLF-10, with 10%-discount.

BLF A6 clip. Fits tightly, maybe a little too deep in the pocket, but ok for normal use.

Aww too bad, while it fits, the light can’t tail stand anymore.

What if you try it on the head side? Might have a bit more play, but shouldn’t be too long.

Btw. I ordered a clip a few hours ago. :slight_smile:

That doesn’t look like it fits at all.

I haven’t had a whole lot of time with this light still, since I’ve been moving into my new house and then doing home improvement. My Zebralight has been on me nearly 24/7 through all of this, but I admit there were a few times I wanted a magnetic tail. However, I’ve needed a light that I can turn immediately to whatever mode I chose, as well as rely on to drop on concrete or drop a case of laminate flooring on top of it and know it will still work. If I had some time spent carrying the unicorn, hopefully it would be that light, but for now I’m just not familiar enough with the UI.

My thoughts so far though:
It is nice and compact, even if it’s a bit longer than my SC62/FW3A/D4. The side switch is very nice for me, Hank Wang needs to take notes. The optic is fine - a tiny bit of ringiness on white walls, but the general beam profile is super useful. I’ve yet to see how it crosses a parking lot, but I expect it will be fine, especially compared to FW3A/D4 that need to ramp way up for any kind of distance. The clip works for me, the knurling is very nice in-hand but scary for my pockets. The crazy modder in me hates the tail spring design, and that’s ignoring that it’s off-center…

As far as it being a ZL killer, it’s not there yet. The zebralight is still more compact and handles heat better with the unibody design. I don’t mind the ZL UI, so that doesn’t factor in for me. The optic is very close - if there weren’t minor centering issues and/or ringiness, I’d definitely put it ahead of the ZL reflector. It’s definitely winning on support and mod-ability (mostly emitter/optic swap, but still).

^ Agreed on basically all points. My SC64 LE still gets much more pocket time and use (due to TRUE moonlight, boost driver, and my confidence in its durability), but the magnet and beam profile make me want to carry the Unicorn almost as much. For a light less than half the price of a Zebra that’s pretty great.

Default values “out of the box” are the same. Mid for main mode, High for additional one. However, they can be set separately for every UI (preset), because they are stored in memory separately.

No, I can’t. Every non-essential entity has been thrown out for the sake of simplicity of interface, while keeping flexibility. That’s why everything has to be done through slots.

Yes, exactly.

They are automatically saved to the workspace (Basic UI) in to EEPROM. Additionally, they can be copied to the one of three available presets. However, I want to change that logic to just four presets, which can be simply selected. Without any loads and saves in to workspace.

Stored in RAM. Only changes are written to the EEPROM and only during shutdown. That way load on EEPROM is reduced. Memory of modes wears the most, if it is used with ramping. One write operation for every shutdown, if brightness has been changed during operation. However, Unicorn has delayed shutdown, so when you switch something through shutdowns, it doesn’t count.
100’000 cycles – stated durability. In fact, it could be 3’000’000. I thing flashlight will be reduced to ash earlier.

I drink cider :).

Yes, I have estimated amount of #ifndef. How to debug that?
Also I’ve spent some time searching for entry point ( main() ), until I realised, that this project has loop()… Arduino?…

I have such interest in that question for the following reason. I’m interested in combining my Indigo with your Anduril, if it is relatively easy to accomplish. We can take familiar to people here front level of interface, and place it on top of good system algorithms, that allow to create good linear regulator on the same FET. It will be even cheaper and more compact than existing solutions on AMC7135+FET. Writing interface on assembler is perversion, but necessity, because it is not clear, how to implement system part on C. And that slows project down, because everyone is afraid to use assembler. And I can’t always support that all, can I? We’ve got “Maidans” here, so it’s hard to find time sometimes.

I don’t mind having lots of good flashlights in the world. But I can’t produce them all by myself (for mass production), and companies don’t like open source projects :slight_smile: . But here is such a unique situation with these Narsil/Anduril – maybe it’s possible to help project in some way and at the same time push forward my own ideas.

In every Indigo I did the same (but with assembler). I wouldn’t say that thing is easy and clear. It’s tedious and worse than piecing a puzzle. There are a lot of recursions and lots of paths had to be kept in mind, if one want to get convenient interface, that can get you anywhere along with context. For me that is the most unpleasant part of work.

I write on C and assembler. And for AVR I see no possibility to use C for mentioned things, that are, on the other hand, can be easily written in assembler. With ARM problem isn’t that critical, but these MCU are worth using only in especially huge projects.

Without inline assembler this thing requires unacceptable amount of resources. There are many channels (Unicorn has 3), and they work on frequencies of tens and hundreds kHz. If you will manage to implement something like this on C, that would be interesting.

There is no wear levelling. Only wear reduction. Levelling is present in Meteor, because there are a lot of constantly changing data stored for self-calibration and at the same time a lot of free EEPROM. There are common memory for every UI and not much user data to be stored. Unicorn is another story: Every UI has independent space, store a lot of data, there aren’t much memory (128 byte), and half of it is allocated for factory settings copy (storing such things in flash is luxury). At the end, it leaves us with 16 bytes for single preset, where full configuration for particular interface should be stored. There are nothing to level wear with. Moreover, such algorithms are complex: Beside regular count of write cycles and data remap, they can find defective memory cells and put them in reserve. And use them later when there are no healthy cells left, etc. Such things require lots of memory and thorough testing, because glitches can occur many years after production, when first defective cell is detected or algorithm will stuck on last cell, continuously wearing it out. Brr…

Sorry about the #ifdefs. I have been meaning to clean out some of those. They grow like weeds, as I add hardware and software options people ask for. But much of it has become messy and needs cleaning.

It does not use Arduino. However, FSM provides an Arduino-like style for writing UI code. The actual main() is in fsm-main.c. UI code has setup() and loop() instead. This is documented in spaghetti-monster.txt.

Good system algorithms are good. :slight_smile:

Most of the work remaining in FSM is to improve the system algorithms. I have a long list of tasks waiting. Most of these make little or no visible difference to the user, but they are still an important part of the foundation.

It works on a linear FET driver. This is used in the Emisar D1S V2. There is also a version which runs on a regulated buck driver, in the BLF GT. 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.

It may be difficult to merge assembly and C, but there are ways to do it. I think perhaps one of the biggest changes is less about the language though, and more about the abstract ideas used. 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?

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

I used a different method, which has some benefits and drawbacks. The perceptual brightness curve is calculated on a computer and saved to a table, so the firmware uses perceptual brightness steps instead of linear power. This makes the ramp shape easy to adjust for a wide variety of hardware, but the resolution is lower and it makes thermal regulation difficult. So that might need to change, and it is not an easy change.

Some companies are afraid of open source projects. However, many companies love open source. They get years of work for a low price. Usually it is not very difficult to explain open source software to companies in a way they understand:

  • With proprietary software: You get what you pay for.
  • With open source software: You get what you pay for. Everyone gets what you pay for. You also get what everyone else pays for.

Overall, everyone pays less and gets more.

It sounds pretty unpleasant. That is why I made FSM. With it, I was able to create clones of a few popular flashlight interfaces in just a few hours.

The Olight Baton clone is the simplest and easiest to read, and makes a good introduction to how to use FSM. I also made a copy of ZebraLight’s UI and called it DarkHorse, but I don’t think anyone uses it.

The next day, I started on a clone of the Meteor. UI1 and UI2 were simple to do, but I stopped halfway through UI3 when I noticed it uses short clicks and medium clicks in addition to longer hold events. FSM provides events for short clicks and longer holds, but nothing for a medium click. So I stopped for the day and then never got back to it.

With UI1, UI2, and half of UI3, it compiles to 3818 bytes. So it currently fits on attiny45, but a finished version would probably need attiny85.

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

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.

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.

Ah, okay. I have not attempted to detect and track dead cells. Without that though, wear levelling is pretty easy and does not require much code.

Wear levelling is probably not needed though, since these eeproms last a long time. I did not bother using wear levelling for config values. It is used only on the dual-switch version. With a tail clicky switch, power is disconnected frequently so I used wear-levelled eeprom to store the memorized brightness level.

Anyway, long message! It is good to talk to someone who understands these things. I hope we are not boring everyone.

That’s easy:

register uint8_t output asm("r3");

This shows how to assign variables to registers and how to use assembler inside of a C program. Here’s another example:

uint8_t delay_seconds;
asm volatile (
  "ldi %[i], 5"    "\n\t"
  "0:"             "\n\t"
  "rcall  delay_s" "\n\t"
  "dec    %[i]"    "\n\t"
  "brne   0b"      "\n\t"
    : [i] "=&r" (delay_seconds)

If you are working directly with registers, in some cases it might be wise to tell gcc not to use it via the option:


i also posted review of Unicorn, there is bunch of examples how it performs

video has english subtitles.

Great review, saw it already a few days ago. Shows almost every aspect of the Unicorn.

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!

Anyone out there able to get the head off of this light?
I just tried with a strap wrench … nope - Mine seems to be locked on.


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

I just tried again, with 2 strap wrenches …. the awesome knurling is so aggressive, it destroyed the rubber strap while turning.
Head still glued … :smiling_imp: