I know its active, but why is it completely ignoring the temperature setpoint?
It’s probably not. It’s probably just rising so fast it predicts it’ll be incredibly hot soon, and the prediction is above the limit even if the current temperature is not.
Anduril - Muggle mode
Currently I have seven lights running this fantastic firmware. And especially after the latest changes that got rid of the ramp lvl 1 flicker.
To me it’s 99% perfect. I only have ONE little detail I would like to change. Muggle ramp ceiling, set to max regulated level?
I have two kids, who often borrow a light. And i put it in muggle mode to prevent them and me from going blind, or melting stuff.
But it’s still too bright at the highest level. The max regulated level seems to be the sweet spot (for me)
BUT, I still haven’t got firmware-compiler-skills 
Is there a friendly soul out there that can compile an anduril.2019-01-05.kid.edition.hex for the D4/D4-219/D4S/D4S-219
Hey TK. Is there a FW3A hex floating around somewhere ? Only link I seen took me to a 404 error.
I just checked out the bzr branch. Having used Anduril for a while but not taken a look at the source code, this is even more impressive.
Normally I work in a totally different are of software development (lots of data, machine learning etc.). I wonder whether it would be feasible to integrate a C-based test framework and write test code for Anduril which would be executable on PCs using stubs in dedicated include files.
Many standard operations (like switching on, strobe etc.) could be tested including their interaction also for different targets. Usually this makes refactoring much easier. As the turnaround time including flashing the driver and testing the lights “by hand” is quite long, this could eventually lead to a considerable speedup in development.
Unit tests (see e.g. List of unit testing frameworks - Wikipedia) could be a good start. A natural evolution is BDD (Behavior-driven development - Wikipedia) which can also be used for embedded systems (example at Using Catch to Write BDD-Style Unit Tests for C — ElectronVector - Test-First Embedded Software)
What do you think?
This should be pretty easy. Look for this part of the code…
#define MUGGLE_CEILING (MAX_1x7135+20)
… and remove the “+20”.
…
Actually, just grab the latest .hex files from my site. I made a one-off build since it was such a small change.
If I understand correctly, it would need to run in an emulator in order to work correctly, since a fair amount of the code is low-level and depends on specific register behavior and interrupt timing and such. Most issues happen in the low-level code, while the higher-level UI code is only rarely buggy.
FSM in general makes refactoring much easier. Most of the FSM-based UIs in the repository only took a single afternoon to create. So I’m not really worried about the UI-level code; it’s more the lower level stuff which could benefit from QA efforts. The spaghetti monster may be locked in a box, but when it gets out, it has teeth.
In my experience, writing the tests and test harnesses tends to take several times as long as the application code. It’s a great thing to have, but it’s a big investment. It’s also difficult to strike a healthy balance of what to test automatically and what to test manually when the correct behavior isn’t really defined yet. Automating the wrong things can actually slow down development, particularly in exploratory areas. But automating the parts which are well-defined can be a good safeguard against regressions.
However, the parts I really want automated tests for are also the hardest parts to automate. Specifically, thermal regulation. I haven’t found a way to test that without using fully-assembled hardware. Each flash/test cycle generally takes over an hour, and tends to involve soldering and measuring and then recharging a battery. And it burns through hardware relatively quickly, so I keep having to get new parts and repair the test devices.
So… I mostly avoid that. And it has become the part of the code which needs the most work. 
Whaaat. Thank you so much :heart_eyes: 
I got a problem with the low mode on the Firmware for my aux boards with LDO I need to set the voltage higher so it lights up at all
but I can not find the code which is responsible for the dimming
What firmware are you using?
FSM with Aux LED support D4S
does not matter if Anduril or IOS v3 problem is the same
Not sure I understand what your after. If its just the ramping tables. It should be in a cfg-emisar-d4s.h file.
there is no ramping table for aux LED Boards
it has
OFF
ON
Low
beacon
but low does not work with my LDO board
Lexel, does your board have batt+, batt- and a signal in from the drivers AUX LED output or does it get all it’s power from the aux output (so it’s only got the 2 connections)?
the D4 board has only 2 wires one on ground other MCU pin 3
for Fireflies I made a 3 wire board to lower the LVP voltage eliminating the MCU Diode drop
same on MF01 Board that uses 8.4V for the LDO/voltage reference and signal to turn bord on or off
both those boards do only know on or off there is no dimming possible
in anduril.c line 501 is where the 7 click stuff is at.
Which one is it that you’re having trouble with?
D4 with LDO
LOW Aux mode
likely the output is too low to work
The reason the low mode doesn’t work isn’t because of a ramping table, or because of anything in the code. It’s a hardware issue.
To solve it, get rid of the LDO. Pull the LED power directly from the MCU pin, with a resistor or potentiometer in the middle, instead of trying to regulate it. When I test the regulation on an adjustable power supply, it doesn’t produce flat output anyway.
This works for 2S/3S/4S drivers too, or even drivers with multiple voltage ranges. For those, regulate the voltage feeding the MCU, then use the MCU to power the aux LEDs.
High mode is direct power, whatever the MCU can provide.
Low power is exactly the same, except with the MCU’s built-in resistor added to the circuit. So the voltage is lower… by a significant amount.
The code has no control over how high or how low the power is. It just adds and removes a resistor.