Teardown pics on fonarevka
Thanks for that link hodor, I’ve now got a unicorn AND a Russian bride ordered!
Oh I didn’t see those for sale. You must be seeing targeted ads based on your browser history 
Yes, there is in one preconfigureode, you can add it to the others:
Put the head into the freezer for around 10 minutes.
When you take it out tap around the edges (if necessary) on a plastic surface,
Use a rubber glove to get a good grip.
It should come right off.
I’ll hold off. I really value moonlight modes of 0.5 lumen or less.
I’m sure your voice isn’t bad, most everyone hates the sound of their own voice. But, thank you for doing text reviews. I like to read (pictures are good too), and I basically never watch video reviews. It just doesn’t work for presenting the information in a good way to me.
Yeah, it’s an interesting light. I was a bit confused about the interface at first, until I found out it’s using attiny25 instead of attiny85. So now it makes a lot more sense why things are the way they are.
About the UI, it’s a bit difficult to talk about in detail since it can be different for each person. However, the short version is: There are three save slots plus an active workspace to load them into. Each slot can have its own selection of ramping vs discrete levels, and its own mappings for what the button presses do. If I understand correctly, those mappings are global in the sense that they remain the same in every mode including “off”, so 4 clicks from off should do the same thing as 4 clicks while on, or 4 clicks from strobe mode.
I’m not sure on the details for how to configure each of those save slots, but it’s in the advanced manual somewhere. It seems to be the sort of thing one would only do once, while referring to the manual, and then write down one’s personal configuration somewhere to remember how to use it. Or just use the defaults.
The discrete step mode has 5 hardcoded steps, while ramping mode is smooth. The output range goes from about ~3 lm to ~900 lm.
Skimming the Russian forum with Google translate suggests that sub 3 lumen caused problems / instabilities so I wouldn’t hold your breath - fnskb may be able to clarify further though.
I agree that genuinely low firefly / moonlight modes are invaluable in EDCs and headlamps. I may still buy the Unicorn though as the host seems good and the firmware very intriguing.
Yes, this is a technical necessity. This driver circuit cannot work stably with lower currents, which are needed for a real moonlight.
Therefore, the minimum is 3 lm.
But instead we have controls without PWM at any brightness, 3-850 lms 
Are you sure about that? When I removed the clip some paint from it rubbed off onto the anodizing, but it cleared up just as easily.
Yeah, unfortunately, that’s an issue with any single-channel FET-based light, regardless of whether it uses PWM or constant current. And more generally with almost any type of power circuit, there is only limited resolution to work with.
In this case, let’s say the highest mode is 850 lm and there are 8 bits (255 steps) worth of resolution. That means each step is 3.33 lumens… which is probably why the bottom mode is rated at 3 lm.
To work around this, people sometimes use 10 bits of resolution instead, for 1023 steps. And in that case, the step size could be as small as 0.83 lumens. But with most circuits, the bottom end tends to be fairly unstable so we can’t count on the bottom few levels being as reliable as the rest.
Pushing the resolution up farther gets difficult too, because it slows down the cycles. When using PWM, the pulses end up too far apart so it looks like a strobe light. Or when using constant current, slower cycles require bigger inductors to smooth out the signal so the entire light gets bigger and more expensive.
A more effective method is to use multiple power channels instead. So, for example, take the BLF-A6. There is one channel which goes from ~6 lm to 1600 lm in 6 lm steps… and one which goes from ~0.2 lm to 130 lm in 0.5 lm steps. The end result is that it goes both lower and higher and provides significantly higher resolution where it matters.
I’d like to see the bottom channel go even lower though, like 0.1 to 30 lm in 0.12-lm steps. Then perhaps a middle channel which goes up to 300 lm in 1.2-lm steps. And on top, a third channel which goes up to 3000 lm in 12-lm steps. This just requires more pins on the controller, more components on the driver, and slightly larger firmware.
I suspect I’ll be fine with the 3 lumen low, as much as I love my sub-lumen moonlights. I just won’t use it for “don’t wake up the wife” duty.
Thanks for the insights on low-level moonlights, TK. I understood it before as basically “can only PWM 8x7135 so low, so split one off into its own channel and PWM it alone”, but it’s interesting to see the issues presented by other driver types.
One more measurement to add - with the locator LED on beneath the switch, the standby drain is 67 μA.
In this case, physical resolution of ADC is +–512LSB (10 bits, signed) and effective resolution is even higher (~24 bits). Analog stabilizer has to sustain 3 lm in spite of changes in outside conditions. 24 bits math with integration of rounding error (accounting of remainder of division) is used, which is bare minimum.
That problem is easily averted with the use of uncompromising application of Delta-sigma modulation (DSM).
For example, utilized here PWM has 137 steps (just a little bit more than 7 bits) and frequency 29.2 kHz, however effective resolution is 137*2^16=8978432 steps, which is a little bit more than 23 bits. I can set PWM frequency and required resolution independently. But modulator imposes restrictions on frequency of interrupt calls:
//Modulator (PWM Extension)
//R0 - ZERO
//R3:R2:R1 - PWM
//R5:R4 - PWM_DSM
//R6 - PWM_BUF
//R7 - SREG1
over1: in R7, SREG //Timer1 Overflow Interrupt
mov R6, R3
add R4, R1
adc R5, R2
adc R6, R0
out OCR1B, R6 //PB4
out SREG, R7
reti
//-------------------------
//PWM Init
main: ldi R25, LOW 32768 //PWM = 42.5LSB
ldi R26, HIGH 32768
ldi R27, 42
cli
mov R1, R25 //PWM = (42<<16)+32768;
movw R2, R26
sei
rjmp PC //while(1);
This code requires 16 clock cycles, so one can’t reduce PWM resolution lower than 5 bits (32LSB). It is speed limiting code block, so optimisation is of high priority. In impulse drivers I use 5 bits 250kHz PWM + 16-24 bits DSM = 21-29 bits 250kHz with clock frequency 8MHz (without PLL, it causes only harm).
C- code looks like that:
uint32_t pwm=0; //PWM Value (global)
//Modulator (PWM Extension)
void TIMER1_OVF_vect(void){
static uint32_t pwmdsm=0;
pwmdsm += pwm & 65535;
OCR1B = (pwm + (pwmdsm & 65536))>>16; //PB4
pwmdsm &= 65535;
}
//-------------------------
//PWM Init
void main(void){
cli();
pwm = (42<<16)+32768; //42.5LSB
sei();
while(1);
}
However, it is much slower. Assembly code just overflows the variable of the fractional part of the PWM and the carry flag adds to the integer part of the PWM. The larger the fractional part, the faster the whole bit of rounding error adds up, and the more often this integer value is added to the LSB PWM. For example, if we have a 42.5 value in PWM, then it is 42 in the high byte and 32768 in the two lower bytes. These 32768 will overflow uint16_t once every two PWM periods, and the PWM duty cycle will jump between 42 and 42+1 with a ratio of 50:50. This is the simplest implementation of a 1st order modulator, but it is quite fast and efficient here.
Such modulation has a number of useful properties. It gives a blue distribution to the quantization noise spectrum (blue noise). So quantization noise is displaced into the HF region — the lower the frequency, the lower the noise amplitude. Capacitors and our eyesight can do reduction this modulation very well. For example, for indication I use pure DSM (1 bit), just manually switching MCU pins. In Meteor, this is modulation at a frequency of only 5kHz per channel and a resolution of 16 bit, which does not prevent the backlight from working quite comfortably in a wide brightness range. Unicorn has a slightly higher frequency.
That way, we have 23 bit PWM and 24bit PI regulator. The regulator smooths the noise of the ADC in a natural way, averaging its readings and allowing you to adjust the LSB fraction. However, in the linear regulator there is a problem - it makes little noise. Oversampling does not work well. I had to artificially increase the current ripple by lowering the PWM frequency on the MOSFET gate, and it still was little help. At some point, oversampling simply ceases to work and the regulator falls to full zero. Therefore, minimum is 10mA (1.5LSB). At the same time, the remaining error in ADC, along with the 20x amplifier, something around +–0.2LSB is the usual result.
Yes, low currents can be obtained right from MCU pin through a resistor. From <20mA and up to sub-microampere values. Using DSM.
As you can see, resolution is not a problem here. The real problem is the lack of noise from the operation of the regulator at low currents. By the way, 137 was not chosen by chance - this is a prime number that gives the minimum correlation of noise from PWM with the ADC sampling frequency (clk / 256).
And ~110 μA with the Red + Green indicator LEDs :)…
P.S. That is the runtime chart for vertically standing flashlight in closed room:
At 130 min I entered room and made a draft. That’s how thermal control works in Unicorn. If someone has rugged lines - you do something wrong.
It’s an interesting idea for sure. It basically does a dynamic trade-off between effective resolution and PWM speed. At low resolution it’s fast, while at high resolution it’s slow. But I don’t buy that it can actually do 23.098 bits worth of effective resolution, because on a 8 MHz controller that would give a cycle speed longer than one second. At that point, it’s not helping with resolution… it’s just making the signal less stable.
But at less extreme resolutions, the speed would still be fast enough to be useful. For example, 16 bits could run at 122 Hz, which would not be very noticeable when it is only a ripple instead of a full on/off pulse.
Digital resolution may not be an issue with that method, but it’s still limited by analog resolution. Getting a single drop of water from a fire hose is difficult regardless of the method used. Much easier to get a single drop from a syringe.
If I understand correctly, a low-resolution sensor may have been used. It can be difficult to find phones with good light sensors. I am lucky to have one with 13.3 bits of resolution (10,000 levels), but with newer phones it is common to have only a few bits worth.
In any case, it is impressive what you have achieved with the Unicorn. Welcome to BLF!
Great first post Inferion and welcome to BLF. Looking forward to the discussions to come.
Yes, the steps in the graph are just low measurement resolution - that’s why I only mark every 10% on the grid. I’ve been meaning to hunt down a finer sensor, but I really want to get away from using a phone to record and haven’t found a good luxmeter that will either record or output to a PC at a good price. It’s on the to do list, but certainly those little steps aren’t caused by the light
That graph looks very smooth.
How/why is the thermal regulation so much better than the typical budget flashlight we are accustomed to ?
Is is because of lower max output (so smaller range of scenarios to cope with) ?
Or improved driver/components ?
Or better algorithms ?
Very interested in replacing the LED on the XP-L HI V2 3C. Please tell in more detail about the replacement procedure