The lowest floor value is actually one, not zero.
If you click zero times, the floor or ceiling value doesn’t change.
This is great because you can change just the floor or just the ceiling without reprogramming the other.
If you have changed the floor and ceiling and would like to reset them back to the lowest and highest values, you would click once for each.
Got it thank you goshdogit, I appreciate your help. I like the moonlight as low as possible.
Today I merged the code for RampingIOS V3 into the FSM branch, then merged FSM into trunk again. So everything is up to date and the Emisar D4S code is public. Here’s the new interface:
The UI diagram is sort of an awkward mix of Anduril and RampingIOS V2, but I hope it’s readable:
Right side of the ramp: The straight black dashed arrow to ceiling has two arrow tips
Is that an inkscape glitch or a new meaning? 
That’s intentional. It means it can go up or down, but up has priority.
Basically, it reverses like Narsil, but the direction resets to up after the button is released for more than a second. It only goes down if the button was released less than a second ago, or if it’s already at the top.
This way, there is no need to remember which direction it going last time it ramped.
To go down, either hold, release, and hold again… or do a click-release-hold.
Hi Toykeeper. I was wondering if there is a place in Anduril where I could lower the moonlight mode just a notch or two? Or is it already at the lowest possible setting?
I was finally able to successfully get atmel studio to build the hex file, I just don’t know where to find the brightness settings.
Nope.
The lowest-mode brightness is determined by a bunch of factors, and virtually none of them are part of the code. The best the code can do is increase its clock speed at low levels in order to spend less time in the stable part of each pulse. This cuts down moon’s runtime dramatically, and makes it quite a bit more voltage-sensitive (worsens dimming on a low battery), but it can sometimes reduce the overall brightness. It’s really not consistent from one light to the next though; results are pretty random.
In any case, the lowest it can do is level 1/255, which it already does. Unless you run the FET at level 0/255 in “fast” PWM mode at a fast clock speed, which uses a significant amount of extra power and can produce anything from a dull glow to about 10 lumens, determined mostly by hardware factors.
You could also try replacing the 7135 chip with a cheaper/worse one with slower activation speed. That would make each pulse rise slower, which could make moon lower (or even make moon entirely invisible). Or maybe attach the main LEDs and a resistor to the indicator LED pin, and enable indicator LED support. Then it’d have a special moon mode available while “off”, with brightness determined by the resistor value.
Which pin on the attiny85 is the indicator led pin and could this also work with a BLF A6 driver using a transplanted attiny85.
I know the indicator LED is a WIP anyway, but what about using the pin to pull the center of 2 diodes in series either up (lower LED on) or down (upper LED on) or leave it floating (for either “off” or both LEDs on, depending on the supply voltage and resistors)?
This could be used for a number of things, but basic voltage readout makes the most sense to me.
FWIW, I gave FSM / Spaghetti Monster a logo of sorts. It’s pictured in comment #2 on this thread.
When I say the spaghetti is locked in a box, this is what I mean. This is what’s locked inside, hiding under the hood, making the engine run.
It might work, but I don’t think anyone has tried it. You could probably use the OTC pads for a switch, and then use the other spare pin next to the OTC for the indicator LED. And probably remove the voltage divider resistors on pin 7, to reduce standby power drain.
You could do that if you like, but you’d have to make hardware for it first. Also, I’m not sure how to tell the attiny to leave a pin floating.
Wow! That’s really well done!
I saw only tangled spaghetti at first and was confused. :partying_face:
Set the pin as input without internal pull-up.
If the LED resistors are placed on the switch board, only this has to be modified, no modification to driver board needed.
Nice idea, kikkoman!
I have a quick question about anduril.2018-08-22.EMISAR_D4.hex
I just flashed it to my two Nichia D4’s.
Finally made the switch from Narsil to Anduril. So far so good \o/
BUT, i can’t get thermal throttling to work.
I have configured both of them at 22C (22 clicks) ambient before heating/using them.
And set ceiling to 25 clicks, wich should be 55C.
But when the lights reach 55C they don’t throttle down, they just keep going 
And when i do a temp readout afterwards they happily blink out 57 or higher… So the temp sensor seems accurate
The Nichia D4 is pretty much a worst-case scenario for thermal purposes. It generates more heat more quickly than pretty much any other light, and the Nichia LEDs have a significant risk of damaging themselves when used at full turbo.
Because of this, Emisar uses a special build for that light, with the maximum power capped at 80%. This helps avoid emitter damage. It’s also recommended to use a relatively low temperature limit on that configuration, like the default 45 C. Or, even better, just don’t use full turbo for more than a few seconds at a time.
When it’s active, Anduril’s thermal regulation makes smooth adjustments which generally can’t be seen by eye. They show up on a lux meter, and can be graphed with zak.wilson’s “ceilingbounce” app. But it doesn’t jump from one level to another like the stock firmware does. Additionally, both the stock firmware and Anduril will tend to exceed the target temperature for a while when the light goes from zero to turbo, before stabilizing at the requested temperature. If you run it at a lower level, it generally won’t get too hot, but full turbo (especially with 219c emitters) gets so hot so quickly that it can’t adjust fast enough to stay under the target temperature.
In any case, I don’t recommend relying on thermal regulation at full turbo on that hardware. Regulation should work fine at a more reasonable ceiling level, but turbo has the potential to damage itself before the regulation even has a chance to work.
Thanks Toykeeper, if I get time in the near future I may just give it a shot to see how it does.
Found the sweet spot @ 40C. Now it regulates as it should at my ramp ceiling, and at turbo.
And as you said, it’s in way smaller and faster increments. Very cool 
Thank you :heart_eyes:
Thanks, but it’s hardly a new idea. I’m pretty sure this is how most mfr’s do it (unless they have an abundance of output pins).
At most, you’d have to run a wire to the LDO output if it’s not routed to a pad. If there’s a series resistor for the LED , it may have to be bridged.
What are common LDO voltages, by the way? 5v for 2s, 2.8v for single cell?
When I’m back from vacation I’ll figure something out. I’m extraordinarily bad at programming, unfortunately, but hardware shouldn’t be an issue.
Is it possible you upload a Atmel studio project as well for D4S?
That’s not likely. I could probably be convinced to convert the repository to git and github, since bzr is more of a niche tool. But I don’t even have the ability to run Atmel Studio. It only works on Windows.
If someone could upload a working atmel project that would be wonderful. With the D4s Anduril files I get 24 errors when trying to compile and the regular D4 Anduril compiles fine.