E-switch UI Development / FSM

[Tom_E]

I can't edit Lexel's quoted copy of my post, but I updated my own.

Got my pics mixed - that was an Haikelite HK04 driver... Think I can break Lexel's quoted copy by removing those pics - should be in that MF01 mini folder anyway.

:FACEPALM: :FACEPALM: (double stupid of me...)

More importantly, Lexel - any ideas on why or if there's potential or possible heat issues with this driver?

[Lexel]

@ToyKeeper

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.

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.

The new revisions are not in the firmware trunk?

[treellama]

The code is in the FSM branch on Launchpad

So, it’s not in the master branch yet

[Lexel]

@treellama

The code is in the FSM branch on Launchpad

So, it’s not in the master branch yet

I can not find it

[treellama]

FSM branch:

https://code.launchpad.net/~toykeeper/flashlight-firmware/fsm
https://bazaar.launchpad.net/~toykeeper/flashlight-firmware/fsm/files

[gchart]

@ToyKeeper

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.

Sorry, I’m a couple months late to the party. I’m feeling the itch up get back into firmware after a little hiatus. Hopefully dust off my T816 dev board and make some progress with Anduril.

Compiling for the 1 series on Linux is pretty easy, you just need to download and include the Atmel Device Family Pack (DFP). Sample build script (also linked in my 1 series thread)

http://www.ghart.com/blf/firmware/bin/

Where I need to start off is to make sure I can build for the 85 or 1634 so that I know my Anduril files are downloaded properly and I’m familiar with the process. I’m sure I saw a primer somewhere, but I can’t seem to find it…

[oweban]

So I’m looking at making a build of Anduril for the GT90 (if nobody has done that yet) - I’ve traced out the driver as such:

(note that there’s some components I’m not 100% sure of - I need to finalise those)

The pinout looks to be the same as a D4/D1/D1S, sans the 7135. What I’m thinking is drop PWM1_LEVELS to 0? Would love to be pointed in the right direction

(note - K G D are the e-switch)

[Tom_E]

Might have a couple of minor things wrong there. The 4R7 resistor should be between batt+ and the reverse polarity protection diode - this one is important for the 25/45/85's.

Pin #6 for the FET gate looks all good and typical in our BLF FET drivers. I'd replace the SIR800DP because it's probably a Chinese fake, with a SIRA20DP FET - better.

I think pin #3 drives the resistor bank for low amps, including moonlight.

Pin #7 can be ignored - think that's TK's pin to read a signal back from the LED for possible light programming.

I've done a very similar Anduril config, but haven't done one for the TA resistor bank - don't know what it max's out to. TA should be able to help.

[oweban]

Thanks Tom - I’ll look into it more. I’ll take the driver out tonight and take some good high-res photos, but I used ChibiM’s photo (from his “modding” post) and then used a multimeter to test connectivity.

Good to now about the FET though.

[thefreeman]

Hello,

Not sure I should ask here or in the other thread, I’m trying to get an understanding of this stuff to hopefully mod a MF01 with tint ramping with lexel dual buck driver, looking at the lantern config file I see that it isn’t thermally regulated, and there’s this comment part about USE_SET_LEVEL_GRADUALLY

also, the set_level_gradually() thing isn’t compatible with tint ramping

(but unsetting it here doesn’t actually do anything, because the thermal regulation define enables it later… so this is mostly just a note to make this compatibility issue explicit)

In the fsm-ramping.h file it says this is for adjusting “brightness very smoothly” , so how not very smoothly it will adjust the brightness during thermal regulation without this ?

[oweban]

Updated circuit diagram for GT90 driver (will stop going on about it after this):

Sounds like find a hwdef with single channel then generate the ramp based on that. (Thanks to SammysHP)

[SammysHP]

Here’s my little sketch:

[Tom_E]

Yeah, there is definitely a lower channel not showing in the diagram above - there has to/must be two channels. SammysHP's diagram looks more reasonable.

The big bank of resistors in TA's drivers in controlled from the MCU as a lower channel - I'm positive of that.

Did you PM TA about it? Or post to a thread he actively monitors and replies to? I doubt he follows this one.

[oweban]

Yep, he’s way better at drawing diagrams than I am. I sent him a good pic of the board all in one and he’s come up with that

I’ll have to PM TA, haven’t yet.

[Texas_Ace]

The GT90 driver uses the same firmware as the GT70. It is the same driver as the GT70, They just adjusted the resistor values to work with the GT70 firmware instead of adjusting the firmware for some reason.

So any firmware that works with the GT70, would also work with the GT90.

I don’t remember off hand the pinout of the MCU but it was a standard pinout when I made it.

The resistor bank handles the low modes, then it brings in the main FET, this gives a smooth ramp compared to just using the main FET (although the changeover can be tricky to get smooth).

It then uses the voltage divider for LVP.

Another pin is used for the e-switch

Another pin for the lighted switch.

Pretty standard stuff, the above diagram looks like the right pinout at a glance.

Here are some pictures to help:

This is a layout file for diptrace, it is hard to read as it is only setup to make routing the pins in diptrace easier, not to look at. Still could help:

[Texas_Ace]

I think this is the latest firmware for the GT70 but I recently moved all my data around as I am rebuilding my NAS, so not 100% on that.

GT70 firmware

[oweban]

Thanks TA, very much appreciated

[bquinlan]

Is this a reasonable place to put feature requests? There’s one that came up over on reddit that I think was a good idea, if practical.

Could you add an option to automatically go into lockout mode after some period of inactivity? It would be another way to reduce the chance of burning a hole in your pocket while interfering very little with normal use of the light. If you could set the timeout in minutes with a maximum of 60 or 90 I suspect a lot of people would find it useful.

[Agro]

It is already implemented in my branch:
https://bazaar.launchpad.net/~nisjuk/flashlight-firmware/nisjuk2/changes

I agree it’s very useful.

[bquinlan]

@Agro

It is already implemented in my branch

Nice! I’ll have to give that one a try.

And I would love to see that merged into the main version.

Thank you!