E-switch UI Development / FSM

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 :wink:

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

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:

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

Thanks TA, very much appreciated :slight_smile:

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.

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

I agree it’s very useful. :wink:

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

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

Thank you!

I had made a (configurable) version as well: GitHub - SammysHP/flashlight-firmware at autolock-configurable

I’m guessing that keeps the MCU awake until the lockout is activated. What’s the effect on standby drain from that?

It just wakes up a few times per second, the same way as it already did before (required for LVP, aux LED).

Btw it is already included in Anduril 2

Oh, cool beans.

Yes, sorry, the auto-lock feature is in the anduril2 branch. It’ll get merged after I finish solving the Rubik’s cube of button mappings, and after some extra testing.

It doesn’t keep the MCU awake while counting. It uses sleep ticks for the timing instead of waking ticks. This keep power usage low, but also makes the timing less precise.

In particular, there are about 7.8 sleep ticks per second, which it rounds up to 8 for integer math purposes… so it ends up with “minutes” which are about 62 seconds long. I should probably revisit that part of the code to see if there’s an easy way to improve that.

I’m also trying to make it easier/faster to use lockout mode most of the time instead of “off” mode. Because some lights just can’t be trusted in a pocket.

(found the above in one of your posts in an LT1 thread)
I’ve noticed something on my lights that I’ve recently updated (3/18 builds). When I use voltage check, often the first (and sometimes second) readings are way low. I’ve gotten voltage checks that go 3.3 -> 3.8 -> 3.9 (and then stable at 3.9) and similar results. It’s pretty frequent, and I made sure to check when the light had been out of use for a while (rather than, for example, after a turbo run where the cell voltage might be rebounding). This is also happening both on a few lights using ATTiny85 pin 8 to read voltage, as well as one using pin 7 to read voltage from a voltage divider.

Any ideas? My FW3A is among those that I flashed and is therefore affected, and did not behave this way on whatever original firmware version it was running (something old, it’s a purple version). (None of the other lights ran Anduril before, so I made sure to check that one too.)

I can think of a way that would happen on FW3A since it doesn’t have aux LEDs (and thus doesn’t have sleep ticks enabled).

The way the ADC code works now depends on whether the light is awake or asleep:

  • If asleep, the raw ADC value is used directly, so measurements reflect the exact value at that moment.
  • If awake, the raw ADC value goes through a very strong lowpass filter which takes a few seconds to adjust to large changes.

So on lights with blinkable aux LEDs, the value gets reset to the raw battery value every time the light is turned off, and then waking readings happen more slowly.

But if the light doesn’t measure while asleep, like on the FW3A, it only has the slow adjustment mode. It would retain whatever value it was last at while awake, regardless of how long it’s asleep, and then adjust slowly from there next time it’s on.

I suspect it could be fixed with a small change in the code where it decides whether to use the lowpass filter or not… something which checks whether the light just woke up. The thermal code already has a mechanism like this; it’s only voltage which doesn’t… and it likely only affects lights which have sleep ticks turned off.

Which lights are behaving this way?

I took a first stab at fixing it, but I still need to test it. If it works, it seems to cost about 14 bytes.

My Supfire M6 does it the most, and it’s using the 3/18 ROT66 build currently. The driver is a Lexel derivative of a TA triple-channel for the Q8. (I can post further details if needed.)

I’ve also reproduced it on my FW3A and my Convoy L6. I can’t remember if I’ve gotten it on my D4. I’m trying to narrow down the conditions under which it happens… The M6 seems to miss every time, although sometimes it’s way off (as much as 0.5V) and others just 0.1V. (I’m comparing the first reading to the stable readings I get one or two readings later, and not dealing with the actual voltage calibration.)

Both the FW3A and the ROT66 have TICK_DURING_STANDBY disabled. Basically, if there is no aux LED, or no “blinking” mode on the aux LED, it probably has no “sleep ticks” and is thus likely to have this bug.

If you have one which is relatively easy to reproduce the problem on, and also relatively easy to flash, I sent up a potential fix in fsm branch r486.

I tested it on an original Emisar D4, and it appears to fix the problem. What I did was:

  • Turn the bench power supply down to 3.0V.
  • Turn the power off, click, and turn the power on to force the light to reboot.
  • Turn the light on for a few seconds to let it read voltage, then turn it off.
  • Change the bench PSU to 4.2V.
  • Click 3 times to enter battery check.

Before the change, it’d take about 3 cycles to reach the correct voltage. After the change, it goes to the correct value immediately (though sometimes it’s 0.1V off initially, and then corrects by the time it hits the 2nd cycle).

I have not tested thermal behavior in this version though… so that’s a big item on the todo list before it can be considered safe. In addition to the normal regulation behavior, I need to test some corner cases involving large temperature changes while the light is in standby mode. Will probably need to use a hair dryer or something, to artificially cause large temperature swings.

I’m not expecting any problems, but the change did touch some thermal code… so I consider it high-risk. And thermal testing is unfortunately time-consuming.

Further testing seems to point towards your suggestion. I haven’t gotten around to building the new Anduril version yet, though. Procedure to reproduce:

  • Give the light a brief turbo run. Just get the voltage to sag a little bit
  • Turn the light off from turbo
  • Let the light sit. could be a few minutes, or hours if you want, but long enough the battery voltage will be normal
  • Go from off -> battcheck
  • Observe at least three battcheck readings, or until they are stable.

I’ve reproduced it on the D4 easily now as well with this method. A ten-second turbo blast and turned it off, came back an hour later and batt-check’d it. 3.0, 3.5, 3.8, 3.8 (etc.)

I could potentially just enable sleep ticks on all build targets… and it would make sure the issue doesn’t happen. But I’d prefer to fix the issue properly instead of making sleep ticks mandatory. So that’s what I did.

It’s just difficult to do thermal testing at the moment, so I haven’t verified yet whether it’s truly safe or if there might be some weird effects on corner cases involving large temperature changes while asleep.

I'm inclined to go with this version/fix. Need to grab a snapshot of Anduril this week to incorporate in drivers I'm building/preparing. Let me know if you have plans to test further soon, if not, I'll grab it today.

Thanks TK!!