Its caused by the 380ma 7135’s I think. They will not run as low as the 350ma 7135’s.
If only the 0.1% doesn't work chances are that your 7135 are too slow.
Not all 7135 are equal, some are slower and don't work at very low duty cycle (wich is the case with low light level)
From what i have seen even mixing "bad" and "good" 7135 can prevent the whole lot to work at low duty cycle
Edit : I am too slow too ;) and i didn't know that the 380mA ones are slower (never used them)
I forgot to mention that the driver’s moonlight (in STAR off-time firmware) worked with a 319A before Biscotti is flashed. Now the driver’s 0.1% doesn’t work with the 219C.
Does that mean that even if the driver is unmodded, a 380mA one is still prone to this issue? 
I’ve read about 380mA 7135s being slow a few times on here. Before that I’d always assume that 380mA ones are superior.
Edit: the extra 7135s I tried to stack are pulled from another 380mA 7135 3.04A driver.
I am new in flashing FW so maybe I'm talking nonsense but I think it may be related to the fuse setting, maybe your clock is too fast.
I don’t know much about the configurations. I know that I used 0x75 and 0xFF for the low and high fuse respectively though.
I had a FET+1 driver with one 380ma 7135. I flashed it with NarsilM, the moonlight would not work just as you described, on but no light.
I unsoldered it and soldered on a 350ma 7135 and all was fine. NarsilM has a settable moonlight and at the lowest setting the led barely glows.
More info in this thread.
whatever the firmware understands on 0.1%
technically you can only go as low as 0.4% 1/255 from PWM 8bit value
as the AMCs tend to be not linear at very low PWM levels you can get 0.01% or off with standard PWM value of 3
to get the 380mA stable running at about 5 to 7 should be used
Shot mtn-e a email. Richard could tell if it works with Biscotti without code modification or not.
The moonlight mode my have to be raised in the code.
I am new to flashing and coding firmwares and I just dumped the .hex file that I downloaded from the flashlight firmware repository. I am not sure which part in the code is responsible for the PWM values, but it looks like that the mode group I use (group 2) is set like this: 1,2,3,5,7,0,0,0
So I should edit “1” and change it to a higher value, like “2”?
you have to look for code with 255 on Turbo
this are just shortcuts on values listed in the pwm table
Bistro Modegroup looks like this
the pwm table should be like
1,3,5,10,25,70,130,255,0
likely weith more values
The stock PWM value for the lowest mode is 1, no wonder why the moonlight doesn’t work everytime… Time to take my Mini C8 apart to re-flash. I hope it works this time.
Edit: Richard also replied that a higher PWM value is needed for the 7135s to work properly. He has had some that needed up to a value of 10.
That type of FET+1 setup only has 1*7135, for the Qlite driver that I’m using, it has 8*7135. Does the Attiny13A use all 7135s for the moonlight? Would replacing a specific 380mA 7135 on the driver with a 350mA 7135 solve the issue?
I think all 7135’s are used in each mode. I’m not for sure if a dual channel was ever implemented with a 105c 8-7135 type board.
The fet+1-7135 board was derived from the 105c by comfchair’s idea. It wouldn’t be hard for someone to make that board into a dual channel, I just don’t know if anyone ever did. About the only gain to using a dual channel would be the ultra low moonlight from a single 7135. Which the “raptor claw” 350ma 7135 would work the best at.
Look at each of the 7135’s VDD pin. If they are all tied to one pin on the attiny then they all are on together. If one 7135 runs to a different pin then its a dual channel.
It can be seen in HKJ’s test.
I’m sidetracking a bit here, but I don’t feel like starting a new thread. Would it be possible to implement the BLF A6 firmware that is intended for dual-channel drivers into 7135-based single channel drivers? The forward/ backward mode switching function is enticing. Would the full functionality of the firmware be lost as Attiny13A does not have as much space as Attiny 25?
I would think it is possible. You could reflow on a attiny25 and cut the trace at the vdd pin of one 7135. Then run a small wire from the appropriate pin on the attiny25 for the second channel on that single 7135 VDD pin. Toykeeper would be the one to ask. The pins in the firmware could possible be associated wrong on the qlite driver for it to work straight out of the box.
If you use a attiny85 NarsilM or anduril code could possible even work. Toykeeper would know. 
I encountered two errors when attempting to compile the .hex file from Biscotti.c:
receipe for target ‘main.o’
tk-attiny.h: No such file or directory
Do I have to change anything else in the code or add something to the library? I’m not sure what exactly should I do to fix the errors.
Edit: I have just went through Comfychair’s guide on compiling a .hex file, now I have eliminated all the other errors but it still failed to compile. Now it says ‘memory overflow’.
Edit 2: I was using Atmel Studio 7.0 and I figure that I should try AVR Studio 5.1. Now the build succeeded without errors. Let’s see if the 219C will light up in moonlight.
you need all the dependancies in the same folder including tk-attiny.h and other files
Ouch, I just burnt my thumb when I was concentrating on heating the pill. It doesn’t hurt at first but the pain intensified after ointment is applied. 
I’ll resume later on. Does the .hex file being successfully created means that there is no ‘memory overflow’ issue? I have just finish flashing the driver before I got hurt. The light doesn’t light up after a brief test with crocodile clips.
I got the dependencies problem solved, and now the only problem is memory overflow. I was at 11xx bytes/ 1024 bytes. I changed the optimization level to ‘optimize for size’, but it is still 1064 bytes/ 1024 bytes. I only defined the MCU as Attiny13A and change the PWM value from 1 to 4, did I do anything wrong?