E-switch UI Development / FSM

No idea - I'm totally confused with that mgt UI. I use git at work every day, not on the web, but with a master repository.

I got base mods to Anduril itself (anduril.c), fsm-adc, setup files, and of course added the project and solution files for Atmel Studio.

Also added voltage reading calibration to the UI - 4 clicks std method.

Yes, I assume so. I didn’t even know it existed.

That would be helpful.

I don’t think it’s a lack of willingness though… more a lack of understanding how free software works and what is required of people who sell it. The license is easy to satisfy, but seem hard for people to understand when they have never encountered anything like it before.

Usually when I bring it up, manufacturers are just like “Oh, that one uses Anduril, and the other one uses NarsilM. You’re welcome.” … and then I’m like “Knowing the name of the firmware doesn’t help; what is required is a file containing the exact source code used on the product, and a way for everyone to get that file.” :frowning:

It’s also hard to get info about Astrolux products in general, since it’s basically a reseller brand name which gets put onto products from other companies. Some are from Mateminco, but there are other OEMs too.

Nope. It seems like, more often than not, companies make no attempt to read or understand the license. They put “Anduril” in the marketing materials to help promote the product, and sometimes they’ll add a “Thanks, ToyKeeper!” somewhere, but I don’t remember the last time a company actually satisfied the license without me bothering them repeatedly with detailed instructions about what was needed.

Thanks aren’t needed. Source code is needed.

Yes, and it’s used on the D4v2 titanium and brass models.

But the button light and the aux LEDs run in sync with each other. They don’t have separate independent modes. The button LEDs mirror whatever the main LEDs or aux LEDs are doing, depending on which of the two is active at the time.

And then there’s the Noctigon K1 RGB button LEDs, which sort of do a hybrid of both.

The aux LED / button LED code really is a mess though, and could stand to be completely rewritten to make it cleaner and more straightforward. It kind of just built up over time as projects needed it, without being explicitly designed.

That’s pretty cool.

It supports two different voltage measurement methods though, and I’m not really sure how to user-calibrate the other one.

The VCC pin method is simple and merely adds a constant fudge factor to adjust the response curve. However, the voltage divider method draws a line between two arbitrary points, and those points are anything from 0 to 1023. So that would be harder to do user calibration for.

Also, the UI doesn’t generally know or care which method is used. It could access the #defines to find out, but it’d need to implement two different voltage calibration modes and select one at compile time.

This is a good start, but there’s still more to do in order to make voltage calibration work on all supported devices.

It’s definitely possible for the cell voltage to change between readings, especially between the first and second, especially if the memorized brightness is high.

But there’s also another way it can change… the code wasn’t doing very good noise reduction. It was getting a pretty wide variety of different values for no reason other than electrical noise and sensor jitter.

Fortunately, I fixed that. Actually spent a lot of the past couple months fixing that, testing a bunch of different solutions, and finally settling on one which is simple but effective. And the code is now in the repository, as of like an hour ago.

Any variation in measurements now is almost certainly a real change in the signal, not an illusion caused by noise.

Yeah. I was getting a variety of bugs caused by race conditions, so I made the order of execution more explicit. Also, I’m still kinda hoping to implement a PWM-DSM hybrid algorithm to adjust brightness between PWM steps… and that requires very tight interrupt timing, so I needed to move as much code as possible out of interrupt handlers.

Now the race condition bugs are fixed (as of mid-November), and it’s theoretically ready for the PWM-DSM thing, if I ever get around to doing it.

Yeah, the first measurement is junk, and the attiny manual says to ignore that first value.

About averaging, I tried a bunch of different methods and algorithms for that, in hopes of getting a more stable signal and increasing the effective resolution. What I found was that it worked great while the light was at rest, but during actual use the data was too noisy. Even with 2048X oversampling, the signal was still noisy sometimes on hardware with high-amp cells and a FET.

So I eventually gave up on getting extra resolution, and instead focused on eliminating noise as much as possible.

It now samples continuously, with everything left-adjusted so it’s 16 bits… 10 bits of signal and 6 bits of noise reduction. It’s basically 10.6 fixed-point numbers. Each time it gets a new sample, it adjusts the running average up or down by 1, meaning it takes 64 samples in a row to move the needle by 1 full 10-bit unit.

This way, if it’s measuring a value of 100, the raw values may fluctuate randomly between 90 and 110, but the lowpassed value only fluctuates between ~99.95 and ~100.05. So it’s much more stable.

Then it adds 0.25 to that value and does a floor() operation, which makes it a very very steady value of exactly 100. Any change in this number represents a true change in the signal, rather than just random noise.

The value still updates quickly, since it samples a few thousand times per second. But the data it spits out is very, very stable now.

Sorry to post so many times in a row… I’ve been trying to fix the code for ADC, voltage, and thermal regulation for months now, and I finally got it working well.

0-8-15 User motivated a lot of this, since he did a lot of work to fix thermal regulation after I half-broke it in the mid-November update. (it worked, but was too slow and allowed high-power lights to get pretty hot) So he did a bunch of experiments and coding to make it respond better. He used 2560X oversampling with a new thermal algorithm, and got pretty good results on D4 and D4S.

When I tried it here though, I found it was still sometimes unstable and required extra tweaking to make it work on other hosts, and there were several details in the code I wanted to fix before merging. So that got me started down a rabbit hole which was deeper than I expected.

Pretty soon, I had gotten a bit lost in ADC signal processing algorithms and PID theory and a bunch of other stuff, and none of it wanted to work right.

Eventually though, I set all that aside and kinda started over, thinking through it from scratch one day in the shower. By the end of the shower, I had an idea worked out and a pretty detailed plan for the code. So I tried it, and … it worked. A couple small things needed tweaking, but overall it basically just worked.

The shower is the best place to write code. :stuck_out_tongue:

I’ve been testing it on a variety of different hosts for the past few days, and so far everything has been fairly close to an ideal response… even without tweaking anything per host.

So I merged it (and the K1 branch, while I was at it, since I wanted to test on K1 too) and finally uploaded the code today.

Testing would be helpful, to get some independent verification that it works.

Here are my results so far. Everything used mild fan cooling unless otherwise noted:
(small house fan about 1m away on its lowest setting, to make a gentle breeze)

D4v2:

D4Sv2:

BLF Q8:

Noctigon K1 W1:

FW3A 219B (test by Bob_McBob with no cooling):

FF E01:

FF PL47 G2:

MF01S: (graph is weird; the ceilingbounce app had some sort of bug during the test)
(also, this particular MF01S is a prototype which is known to have unstable output)

MF01-Mini: I tested both turbo and the ramp ceiling, because this thread indicated regulation problems at the ramp ceiling level. Here are the results for both. I let the second test run until the battery was empty, to see how the rest of the graph would look:


Prototype of an upcoming light:

The code is in the FSM branch on Launchpad, and I uploaded some new .hex files for testing too.

I’m not considering it stable until it has had more testing, but if no big issues are found I’ll probably mark it as stable and merge it into trunk.

Edit: Added MF01-Mini test results. Also, if anyone was wondering about those small but sharp-looking stairstep adjustments later on in the graphs, they’re not actually sharp. Here’s a close-up of one. It took 32 seconds to adjust output by about 3%, moving up one small step every 4 seconds:

Each of those 8 steps is the smallest adjustment possible using the given hardware’s PWM controls. The changes are not visible by eye during use.

Thanks TK for all the info. I'm definitely interested in the new algorithm you got there. Regarding the voltage divider option, yes - this is required for more than 1S battery setups, or 6V/12V LED output, etc. I recall DEL saying the voltage divider method is more reliable/accurate from one unit to the next. We had a back and forth conversation about this, not sure if it was posts on BLF or pm's/emails. I recall thinking - why did I ever drop the R1/R2 support? For example, standard Nanji drivers had R1/R2. But of course it was to further drop parasitic drain. Now, I use higher resistor values values for R1/R2 for 2S configurations.

In NarsilM, I implemented voltage divider support as well, but also used DEL's method for it. Just checked and I'm not doing any filtering on the voltage divider reading, but I'm using DEL's "crude low pass filter" on the internal reference source.

Have you seen or heard of a need to calibrate the R1/R2 voltage divider lights? Guess I could check the BLF GT threads.

TK, those results look great to me! Thanks so much for all the work you put into this.

Mike

I agree with the shower btw... The take away from those graphs is, wow, we got way too many amps for way too little heatsink. The K1 W1 is the only one doing decent.

The graph on the Q8 looks outstanding though - about perfect, settles down after 7 minutes to a nice sustainable level. Actually most of these all look great and match to the light so well, for example the D4 v.s DVS.

What's the stable temp set for on these, or can it even be defined that simply?

TK - I'm not sure why there's not more posts about this! The more I look at these graphs, the more impressed I am!!

You probably didn't/couldn't keep up but there has been complaining goin on about the thermal mgt in a few of the Anduril lights, but mostly the ones that apparently are not configured properly - no special Anduril configuration. The Astrolux MF01 Mini for example, but "man of light" came out with a nice, somewhat of a fix for it -- a copper heatsink. You should check it out here: https://budgetlightforum.com/t/-/59714. Whether this is doing the right thing or not, not sure (maybe just delaying the inevitable?), but it's helping.

Yes, it still seems to vary… especially on drivers mass-produced for cheap.

I mostly just decided I was okay with a precision of +/- ~0.15V, since it’s not easy to get a mass-produced attiny device to measure more accurately than that… but it would be nice to tighten up those tolerances or make it user-correctable.

TBH, I was surprised it worked. I didn’t even tweak the thermal parameters for each build target. I built in some configurable new knobs designed to be set differently for each model of light, but I didn’t end up needing to use them.

They were all set to the default temperature limit, which in most cases is 45 C. The user can raise that to get more light, but I wanted to do the testing with a relatively low limit because it makes regulation more difficult. The ambient temperature was about 18 to 20 C, and I used factory reset to calibrate the sensor as if it was 21 C.

The K1 has a default limit of 55 C, because most of its heat comes from the driver instead of the LED… and the driver can tolerate higher temperatures than the user’s hand. It has so much thermal mass that the outside of the light usually doesn’t get very warm during use, and most of the heat is concentrated inside at the driver.

I haven’t tested a MF01-Mini with this change yet. Will have to try that. I’m guessing it’ll probably behave similar to a D4S, which was one of the lights with the most thermal regulation problems in older versions.

You are using old MCUs. ATtiny85 datasheet specifies that internal voltage reference 1.1V can be 1V to 1.2V, same with the 1634. The limits of the same internal 1.1 vref in the newer 1-series 3217 is 1.078V to 1.122V. Already there is a huge gain in accuracy. Added bonus is that the internal temperature sensor is factory calibrated. I’ve not needed to calibrate a single one of my 3217 based drivers for either voltage or temperature.

The 85 is getting close to 15 years old. Maybe it’s time to move on?

This looks great. It confirms I will ultimately have to reflash my original D4.

That's just plain cheat'n!

I'd gladly move on, but I need all the same support we got now for the 85:

  • many OSHPark driver board layouts and designs
  • hoping all components can be hand reflowed (nothing super tiny)
  • easy programming
  • Anduril support

If we had all that, and I assume costs would be reasonable on the IC parts (under $10 maybe?), I'm there, sign me up!

I can add support for the 1616/1617/3216/3217 chips whenever there’s toolchain support for them, but that’s not really up to me.

Even then though, I still plan to support older hardware… the whole point of having a kernel on these is to abstract out the hardware details as much as possible so hardware and software can be mixed and matched. I don’t want to abandon all the nice lights people already have.

There's no toolchain support? I see those devices listed under AtmelStudio, so I would think the underlying support in the toolchain it uses would be there?

Tests are still running, but so far the MF01-Mini looks totally fine. It regulates to a stable level more quickly than older versions, and then stays pretty flat afterward. So far I’ve tried starting from turbo and starting from the ramp ceiling, with similar results on both. I don’t see any of the bouncing he observed.

However, the stable level on this MF01-Mini appears to be only about 400 lumens… which is pretty embarrassing compared to the D4Sv2’s stable level of ~1200 lumens in similar conditions. Perhaps that’s a matter of having SST-20 in one and XP-G2 in the other, but I think the difference is too big to be explained by just that. The two lights are almost identical in size, shape, and power level… so it’s really weird that one can sustain 3X as much light as the other.

Looking at older tests though, I see the same result. 1000+ lm on both D4S lights I’ve measured, and about 400 lm on this MF01-Mini. It seems man of light had similar results, even with an added heat sink… 400 to 600 lm. So I wonder why it runs so much hotter.

Support in gcc exists but is still in somewhat early stages… like, someone got it working in November, and as of a month ago it appears to still be in “patch it yourself” territory instead of having compiled packages available. Debian still has avr-gcc 5.4.0, and it looks like the newer chips may need 8 or newer, so that’s another thing to figure out. Then there’s also the matter of finding ways to flash the chip, getting it into flashlight driver designs, etc.

It’s getting there, but it’s going slowly.

Here's my latest Anduril w/tweaks: https://drive.google.com/drive/folders/1jdx8U3LruVaAzHQi7MOk2UqsE5VW7wKK?usp=sharing

It's the zip file with TE v1-1 in the name. Summary of changes:

  • added a few more config files of custom mods
  • raised default temp from 45C to 60C
  • raised max temp from 70C to 90C
  • added voltage calibration - clicks are for 0.05V increments, 5 clicks is 0.25V, 7 clicks for 0.35V - only for internal reference voltage measurements, not external voltage divider configurations
  • disabled goodnight mode and beacon mode, added version # display in it's place and changed the version # to a simple 2 digit #, for vn.n format

I added MF01-Mini test results to my earlier comment:

MF01-Mini: I tested both turbo and the ramp ceiling, because this thread indicated regulation problems at the ramp ceiling level. Here are the results for both. I let the second test run until the battery was empty, to see how the rest of the graph would look:


For some reason, this light gets the “brighter on a low battery” thing a lot worse than most. Maybe it’s getting an unusually large portion of its heat from the driver instead of the LEDs? I’m not sure why, but it’s the same pattern I’ve seen on every MF01-Mini test.

If anyone was wondering about those small but sharp-looking stairstep adjustments later on in the graphs, they’re not actually sharp. Here’s a close-up of one. It took 32 seconds to adjust output by about 3, moving up one small step (0.39) every 4 seconds:

Each of those 8 steps is the smallest adjustment possible using the given hardware’s PWM controls. The changes are not visible by eye during use.