E-switch UI Development / FSM

1034 posts / 0 new
Last post
Tom E
Tom E's picture
Offline
Last seen: 42 min 9 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14978
Location: LI NY

I worked on adding voltage Cal to Anduril. All coded, compiled, ready to test. I made it work to enter the fudge factor via clicks. 5 clicks is 0.25, 7 clicks is 0.35, etc. Max of 10 clicks.

Installed this just now on a SP36, previously had NarsilM v1.3 on it, and been testing it - the voltage fudge factor configuration seems to be working fine!

If I set it to 3 clicks, it reads 3.8V.  If set to 10 clicks, it reads 4.1V. A difference of 7 clicks is about 1.75V, so this makes a lot of sense. Now if we (or I) could get this rolled in the official Anduril? Seems like a great feature. I was gonna spend the time doing it with NarsilM but it would be a lot more effort, because I also would have had to roll thermal config in.

 

Wooo Hooo!! laughing

manithree
manithree's picture
Offline
Last seen: 37 min 16 sec ago
Joined: 01/12/2013 - 01:08
Posts: 602
Location: Orem, UT, USA
d_t_a wrote:
ToyKeeper wrote:
bquinlan wrote:
will files for the Astrolux HL01 eventually be added to the /torches/fsm/ download list?

That probably depends on whether Astrolux gives me a copy of the source code they used.

It’s one of like a dozen apparent license violations I’ve been meaning to chase down…

So, it looks like as of now, these flashlights use Anduril, but have not released the actual source code used (ie. unknown which Anduril “build target” they were based on:

Astrolux EC01
Astrolux HL01
Astrolux FT03S

Haikelite HK04

Well, crap. The Astrolux EC01 is one of my favorite torches right now. My son has one, and I have 3. Now that I’ve sent all that money their way, I find out they’re violating the GPL. I figured since they say right in the titles of their product pages that they’re using Andúril, that they would have done it right.

Agro
Agro's picture
Online
Last seen: 1 min 49 sec ago
Joined: 05/14/2017 - 11:16
Posts: 6868
Location: Ślōnsk

Another observation:
When I’m in voltage blinkout mode with the cell I have in the light now, the first result is either 2.6V or 3.6V (not sure, the light turns on and off as I do the clicking), probably 3.6V. But later it shows consistently 3.7V.
Is it that turning it on for the split second drops cell voltage by 0.1V and the first blinkout starts before the cell recovers?

Quadrupel
Quadrupel's picture
Offline
Last seen: 7 hours 7 min ago
Joined: 12/03/2017 - 10:40
Posts: 754
Location: Lithuania

Tom E,
Great feature, but it will be used once after flashing firmware and forgotten

Tom E
Tom E's picture
Offline
Last seen: 42 min 9 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14978
Location: LI NY

Quadrupel wrote:
Tom E, Great feature, but it will be used once after flashing firmware and forgotten

True, hopefully, but that's the point - just like thermal config settings. I'm tired of re-flashing simply to tweak these settings, like I've been doing for years with Narsil. Also, there's been a lot of complaints in production lights on the inaccuracy of the voltage readings, so we will have a fix for that.

Tom E
Tom E's picture
Offline
Last seen: 42 min 9 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14978
Location: LI NY

Agro wrote:
Another observation: When I'm in voltage blinkout mode with the cell I have in the light now, the first result is either 2.6V or 3.6V (not sure, the light turns on and off as I do the clicking), probably 3.6V. But later it shows consistently 3.7V. Is it that turning it on for the split second drops cell voltage by 0.1V and the first blinkout starts before the cell recovers?

I've noticed this in my Anduril lights as well - usually a 0.1V variance, but not sure if it happens in Narsil as much. Well, the D4SV2 is a 1634 light, so the low pass filter is enabled in the cfg-emisar-d4sv2 file. Just reviewed it, and it's the same low pass filter I implemented in Narsil, actually first written by DEL. DEL's/Narsil's implementation is interrupt driven for the A-D conversions, and best as I can tell, so is Anduril, but the interrupt processing is deferred. Her interrupt handler is 1 line of code in fsm-wdt.

 The only difference I can see between Narsil and Anduril is that Narsil throws away the first, or every other ADC voltage reading, and Narsil doesn't defer the processing.

 So the cell will lag under load - I've certainly seen this, though I thought it was with more weak type cells, like 16340's, etc., but maybe even on a good cell, the lag could be seen as a small dip.

hodor
hodor's picture
Offline
Last seen: 4 hours 38 min ago
Joined: 07/11/2018 - 03:58
Posts: 1064
Location: UK

Awesome Tom E, sounds like a very worthwhile addition!

Agro
Agro's picture
Online
Last seen: 1 min 49 sec ago
Joined: 05/14/2017 - 11:16
Posts: 6868
Location: Ślōnsk

I guess that battery sag could be fixed by blinking number of volts , reading voltage again and blinking 0-1 numbers for full volts and then the decimals. Careful not to blink 4.9.
Or better: blindly do 2 blinks and then the rest.

Tom E
Tom E's picture
Offline
Last seen: 42 min 9 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14978
Location: LI NY

Might be easily fixable by a delay. I recall from DEL, there was a reason to skip the first reading... This was back in the day of the Q8 development.

The low pass filter we use is still subject to 1 off glitchy readings - it's not doing averaging of any kind.

Agro
Agro's picture
Online
Last seen: 1 min 49 sec ago
Joined: 05/14/2017 - 11:16
Posts: 6868
Location: Ślōnsk

This seems beyond my skills so far though…

Mike C
Mike C's picture
Offline
Last seen: 1 week 1 day ago
Joined: 01/22/2014 - 08:03
Posts: 2585
Location: Sweden

Tom E wrote:
I recall from DEL, there was a reason to skip the first reading…

It’s in the datasheet. If swapping between temp readings and reading VCC, then this applies: “The first ADC conversion result after switching voltage reference source may be inaccurate, and the user is advised to discard this result.”

Another thing to consider when reading MCU VCC as battery voltage is that the voltage drop over the diode is only the same if the current draw from the MCU is always the same. Alterations in current draw from MCU do lead to alterations in voltage drop. It’s different depending on diode of coarse, but the drop over the diode is not fixed, it is current dependent. I didn’t bother about it with the good old fashioned 7135 & FET drivers but it became much more noticeable when I started powering some components (like digi-pot) directly from the MCU pins. I went back to using a voltage divider.

Tom E
Tom E's picture
Offline
Last seen: 42 min 9 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14978
Location: LI NY

Ahh - ok. I'll have to check Anduril again for support of this. Is it true then using the external voltage divider would solve all the flaky problems we see in voltage readings/reports?

It's a shame because with a FET+1 driver, pin #7 is a spare but we stayed away because of the extra amp draw in e-switch lights. I've used higher values for the voltage divider resistors to reduce the parasitic drain and it seemed to work well.

Mike C
Mike C's picture
Offline
Last seen: 1 week 1 day ago
Joined: 01/22/2014 - 08:03
Posts: 2585
Location: Sweden

For me it was a no brainer with the divider because of current draw when turning digi-pots on/off and having 4 output channels on/off made the readings pretty bad. I had moved on from the 85 when I started doing these kind of things so pins wasn’t an issue.

I’m using the 3217 now so I definitely don’t have a shortage of pins. The negative side of my voltage divider does not go to GND, it goes to another pin so I can control it’s connection to GND. When shutting down on E-switch lights I just set to high impedance input and turn on the pull-up resistor, that entirely eliminates parasitic drain from the divider.

Tom E
Tom E's picture
Offline
Last seen: 42 min 9 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14978
Location: LI NY

That's a nice feature, to eliminate the parasitic drain.

Agro
Agro's picture
Online
Last seen: 1 min 49 sec ago
Joined: 05/14/2017 - 11:16
Posts: 6868
Location: Ślōnsk

Tom E wrote:

In case anyone is interested, here’s the AS7 Anduril v464 full folder with all the source code, solution and project file and it all builds, right now defaulted for a Q8 configuration, with the max temp of 85C, default to 55C:


 google drive share for Anduril


 


 


I wonder what would it take to merge that into the main source tree…
What kind of maintenance would be needed? I guess only adding cfg files?
Tom E
Tom E's picture
Offline
Last seen: 42 min 9 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14978
Location: LI NY

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.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 14 hours 12 min ago
Joined: 01/12/2013 - 14:40
Posts: 10804
Location: (469219) 2016 HO3
Tom E wrote:
Btw, I don’t see any config file in the repository for the HK04 – is HL doing this stuff on their own?

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

Agro wrote:
Can we as a community put some pressure on them to release the code?

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.” Sad

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.

manithree wrote:
I figured since they say right in the titles of their product pages that they’re using Andúril, that they would have done it right.

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.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 14 hours 12 min ago
Joined: 01/12/2013 - 14:40
Posts: 10804
Location: (469219) 2016 HO3
80T wrote:
Is Anduril able to use both AUX and Indicator LED’s at the same time as long as the driver has the required hardware capabilities / pins ?

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.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 14 hours 12 min ago
Joined: 01/12/2013 - 14:40
Posts: 10804
Location: (469219) 2016 HO3
Tom E wrote:
I worked on adding voltage Cal to Anduril. All coded, compiled, ready to test. I made it work to enter the fudge factor via clicks.

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.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 14 hours 12 min ago
Joined: 01/12/2013 - 14:40
Posts: 10804
Location: (469219) 2016 HO3
Tom E wrote:
Agro wrote:
When I’m in voltage blinkout mode … the first result is … 3.6V. But later it shows consistently 3.7V.

I’ve noticed this in my Anduril lights as well – usually a 0.1V variance…

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.

Tom E wrote:
Her interrupt handler is 1 line of code in fsm-wdt.

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.

Tom E wrote:
I recall from DEL, there was a reason to skip the first reading…

The low pass filter we use is still subject to 1 off glitchy readings – it’s not doing averaging of any kind.

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.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 14 hours 12 min ago
Joined: 01/12/2013 - 14:40
Posts: 10804
Location: (469219) 2016 HO3

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. Silly

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.

Tom E
Tom E's picture
Offline
Last seen: 42 min 9 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14978
Location: LI NY

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.

trakcon
trakcon's picture
Offline
Last seen: 4 hours 14 min ago
Joined: 01/23/2019 - 15:50
Posts: 452

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

Mike

Tom E
Tom E's picture
Offline
Last seen: 42 min 9 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14978
Location: LI NY

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?

Tom E
Tom E's picture
Offline
Last seen: 42 min 9 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14978
Location: LI NY

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: http://budgetlightforum.com/node/70329. Whether this is doing the right thing or not, not sure (maybe just delaying the inevitable?), but it's helping.

 

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 14 hours 12 min ago
Joined: 01/12/2013 - 14:40
Posts: 10804
Location: (469219) 2016 HO3
Tom E wrote:
Have you seen or heard of a need to calibrate the R1/R2 voltage divider lights?

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.

Tom E wrote:
most of these all look great and match to the light so well…

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.

Tom E wrote:
What’s the stable temp set for on these, or can it even be defined that simply?

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.

Tom E wrote:
there has been complaining goin on about the thermal mgt in a few of the Anduril lights … MF01 Mini for example … somewhat of a fix for it — a copper heatsink.

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.

Mike C
Mike C's picture
Offline
Last seen: 1 week 1 day ago
Joined: 01/22/2014 - 08:03
Posts: 2585
Location: Sweden

ToyKeeper wrote:
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…

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?

iamlucky13
Offline
Last seen: 1 hour 29 min ago
Joined: 06/22/2018 - 09:18
Posts: 1041
Location: USA

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

Tom E
Tom E's picture
Offline
Last seen: 42 min 9 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14978
Location: LI NY

Mike C wrote:
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?

That's just plain cheat'n! smile

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!

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 14 hours 12 min ago
Joined: 01/12/2013 - 14:40
Posts: 10804
Location: (469219) 2016 HO3
Mike C wrote:
You are using old MCUs… Maybe it’s time to move on?

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.

Pages