E-switch UI Development / FSM

212 posts / 0 new
Last post
goshdogit
goshdogit's picture
Offline
Last seen: 2 hours 36 min ago
Joined: 12/03/2015 - 21:28
Posts: 404

I’d like to flash Andúril to one of my Q8s.

I successfully reflashed my D4 with the v2 firmware, but I’m still a total n00b with the process.

I’m still confused about the fuse values. Are these dependent on the hardware, firmware, or both?

How do I know what to use for the Q8 and Andúril? Do I simply reuse the values that come with the Q8’s stock NarsilM 1.0 firmware?

Also, when I attempt to build a HEX file with Amtel Studio 7, I get two errors:

  • recipe for target ‘main.o’ failed
  • spaghetti-monster.h: No such file or directory

I’ve downloaded spaghetti-monster.h, but I’m unsure of where to place it for ‘#include “spaghetti-monster.h”’ to see it.

EDIT: I’m making progress! I now understand I need to place all of the .h and .c files in the project directory for the #include commands.

EDIT 2: I got a successful build! The ‘Hey, you need to define ATTINY.’ error made me lol. Big Smile

Please forgive my ignorance, I’m in waaaaay over my head here!

MascaratumB
MascaratumB's picture
Offline
Last seen: 7 hours 32 min ago
Joined: 10/29/2016 - 12:12
Posts: 788
Location: Portugal
ToyKeeper wrote:
MascaratumB wrote:
Hum, don’t know if the FW3A creators/developers team would agree/appreciate that but…why not? Big Smile

I checked first. Part of why I waited was to make sure people didn’t mind.

Ohh, I was talking about the “Mithril” name for the FW3A, not about the firmware Wink
Independently of the name of the flashlight, I’m sure I’ll love that firmware on it!!! All my lights have “conventional” clicky modes, so a ramping mode, also with clicks, and extras like those you’re inserting on it, will be awesome!!
Once again, thanks for the efforts on these masterpieces Thumbs Up

DB Custom said: "Hide your billfold, cut up your credit cards... you're a perfect candidate for full blown flashaholism and will soon need dedicated flashlight cabinets. [...] Have fun! Modding is next... :P" 

Reviews : Amutorch S3 - XPG3-S3 /  AM S3 vs Neal 219c  /  Amutorch AM30 - XHP70.2 / Nitefox UT20 / Sofirn SF14 & SP10A 

Mods and tricks: 1 / 2 / 3 / 4 / 5                                                                    Convoy S2+ TIR Lenses on: XML2 / XPL-HI

 

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

goshdogit, it’s intended to be built with the bin/build-85.sh script and flashed with the bin/flash-85.sh script. These are written for unix-like systems though, so it’ll require adaptation to build in Windows.

It’s also a good idea to grab the entire repository to retain its directory structure, so all the files will be there. This is easy with bzr installed, or not so easy otherwise. Perhaps I should get in the habit of doing .zip releases of the entire repository, since that’s easier in Windows.

FWIW, this is what I’d normally do:

  1. bzr branch lp:~toykeeper/flashlight-firmware/fsm
  2. cd fsm/ToyKeeper/spaghetti-monster/anduril
  3. ../../../bin/build-85.sh anduril
  4. ../../../bin/flash-85.sh anduril.hex

The build uses fsm-*.c and fsm-*.h in addition to the files in the subdir for the current UI… and some of the tk-*.h files in the parent directory. Basically, it relies on having parent directories in the include path with the “-I.. -I../.. -I../../..” options in the build script.

goshdogit
goshdogit's picture
Offline
Last seen: 2 hours 36 min ago
Joined: 12/03/2015 - 21:28
Posts: 404

ToyKeeper wrote:
goshdogit, it’s intended to be built with the bin/build-85.sh script and flashed with the bin/flash-85.sh script. These are written for unix-like systems though, so it’ll require adaptation to build in Windows.
Thanks for the reply! I managed to download the header files individually and got a successful build.

I’ve got about 30 browser tabs open between two desktop machines and a tablet, but no Linux box. The last time I used unix was on a Sun Workstation in the tail-end of the ‘purple logo’ era. Big Smile

Can you offer any guidance for the fuse values? I read some stuff that made me worry about bricking the 85 by using the wrong values.

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

The fuse values are in the flash-85.sh script.

joechina
Offline
Last seen: 8 hours 15 min ago
Joined: 03/05/2016 - 08:23
Posts: 561

Me looking at Narsil and Andùril:
It is sick to operate that amount of stuff with one button.

SmileSilly

joechina
Offline
Last seen: 8 hours 15 min ago
Joined: 03/05/2016 - 08:23
Posts: 561

Can we have an easter egg?
Tapp 12 times and the lamp blinks out la cucaracha in morse code?

goshdogit
goshdogit's picture
Offline
Last seen: 2 hours 36 min ago
Joined: 12/03/2015 - 21:28
Posts: 404

ToyKeeper wrote:
The fuse values are in the flash-85.sh script.
SUCCESS!

I’m currently being mesmerized by “Lightning Storm” mode on a BLF Q8!

ToyKeeper, thanks so much for all of your amazing innovations and willingness to help others!

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

I think you may be the first person to actually try this UI. Feedback is appreciated.

If you’re willing, I may also want to try to add support for the lighted button and ask you whether it works. I don’t have hardware for that yet.

goshdogit
goshdogit's picture
Offline
Last seen: 2 hours 36 min ago
Joined: 12/03/2015 - 21:28
Posts: 404

ToyKeeper wrote:
I think you may be the first person to actually try this UI. Feedback is appreciated.
I’m honored! I will fiddle with Andúril and report back with my thoughts. I’m loving it! I just put it on my D1, too.

ToyKeeper wrote:
If you’re willing, I may also want to try to add support for the lighted button and ask you whether it works. I don’t have hardware for that yet.
I feel awful that you don’t have a Q8 to play with yet! As you mentioned when photos of the internals appeared, it’s easy to reflash because of the long emitter wires. Remove the two driver screws and you’re in.

I’ll be glad to test the illuminated switch when you add support. I didn’t put these pink 0603s in to remain dark! Wink

I took a class in C (or was it C++?) in high school, and I’m having fun browsing your code and attempting to understand what’s going on. It’s nicely commented. “Sleep dammit! (but wait a few seconds first)” Big Smile

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

BTW, to turn the indicator LED on or off, I’m thinking maybe triple-click in lockout mode? This would configure whether the button stays illuminated while the main light off. Unless there’s a better place to put this option.

I could instead put an actual config mode inside lockout, for all settings related to standby behavior, but so far it looks like there’s just one option.

I’m also thinking maybe it should do something different with the indicator LED depending on whether the light is off or locked. Like, one could blink while the other is steady.

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

Speaking of sleep… I finally made it go to idle mode during regular output (and goodnight) mode, since the MCU doesn’t really need to do anything timing-sensitive. It keeps PWM active, and the voltage / temperature measurements, and the WDT timer, but it doesn’t need to do any actual processing.

This only reduced power use by 2mA, but that’s still useful. It means the lowest firefly mode went from 5.6 mA to 3.6 mA.

Was hoping to reduce it by 4mA, but that might not be possible without turning off some features it needs, like the ADC, or reducing the clock speed (which would make PWM slower).

goshdogit
goshdogit's picture
Offline
Last seen: 2 hours 36 min ago
Joined: 12/03/2015 - 21:28
Posts: 404

ToyKeeper wrote:
BTW, to turn the indicator LED on or off, I’m thinking maybe triple-click in lockout mode?
I like that idea. I don’t like the indicator toggle in Narsil when you ramp and quickly power off the light. When I want to ‘park’ the light and set memory, I tend to inadvertently disable the indicator. Don’t tell Tom! Big Smile

ToyKeeper wrote:
I’m also thinking maybe it should do something different with the indicator LED depending on whether the light is off or locked.
Yes. It seems intuitive that a solid indicator means ‘ready’ and a non-solid indicator means ‘locked.’

Do I remember you making reference to a ‘heartbeat’ or ‘breathing’ mode? Or something like a MacBook’s ‘sleep’ indicator?

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

I tried a couple other things. Running at 6.4 MHz seems to drop the PWM speed from 15.6 kHz down to 3 kHz. So that’s no good. I was expecting 12.5 kHz, not 3.0 kHz.

Turning off brownout detection reduces standby drain by quite a bit. Granted, it’s basically dropping from zero to even zeroer, but still. 24.7 uA with BOD enabled, or 0.35 uA without.

0.35 uA. That’s 0.00035 mA or 0.00000035 A. I had to use my Fluke to even measure it, since my regular DMM couldn’t.

So I think I’ll be leaving BOD off… It’s not really used in FSM and it increases standby power by a factor of 700.

It has no effect on non-standby modes though. So, I’m still at 3.6 mA or higher for firefly mode.

Dropping the clock speed to 4 MHz works. Moon mode is then 2.5 mA, but PWM runs at 7.7 kHz instead of 15.6 kHz. So I made it change clock speed depending on the brightness. The bottom ~dozen ramp levels run at 7.7 kHz and everything else runs at 15.6 kHz. This gives more stable and more efficient moon modes without making higher levels audible or strobey.

Long story short, I managed to decrease the lowest level from 5.6 mA to 2.5 mA, while also increasing the brightness from about 0.01 lm to 0.10 lm. This means a usable moon mode’s runtime went from 18 days to 50 days on a 3000 mAh cell. And standby time went from 14 years to 977 years. Not that the cell would last over a decade anyway.

Flashy Mike
Flashy Mike's picture
Online
Last seen: 49 sec ago
Joined: 01/14/2016 - 16:38
Posts: 753
Location: Germany

@Toykeeper:

Why don't you use fast pwm with 4 Mhz clock speed all the time? You will still get 15.6 kHz pwm frequency then. I know the problem of not getting zero output with fast pwm and addressed it with:


#define PWM_FAST        0x03
#define PWM_7135        OCR0A
#define PWM_FET         OCR0B
#define PWM_OUT_7135    0x80
#define PWM_OUT_FET     0x20

void output_on()
{
    // In fast PWM there is a short output peak even when PWM set to 0,
    // we just deactivate the PWM output override in this cases.

    TCCR0A = PWM_FAST |
        ((PWM_7135 != 0) ? PWM_OUT_7135 : 0) |
        ((PWM_FET  != 0) ? PWM_OUT_FET  : 0);

    TCCR0B = 0x01;
}

void output_off()
{
    TCCR0A = 0;
    TCCR0B = 0;
}

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

I’m not really worried about getting zero output on PWM=0, since it doesn’t apply to standby mode and it’s easy to add a clause to work around it in set_level(). I’m more concerned about getting a stable moon mode which isn’t voltage-sensitive. The activation time for the 7135 chip is long enough that 15.6 kHz doesn’t really work well at the low end. So, I normally cut speed in half on the lowest modes.

The difference here is that, instead of going from FAST to PHASE mode for moon, it’s going from 8 MHz to 4 MHz.

I don’t want to use fast PWM on higher modes since there’s an issue with PWM=255 not being completely on. It has a short “off” blip each cycle much like PWM=0 has a short “on” blip. And I don’t want less than 15 kHz on higher modes since it’s audible. So those really should be 8 MHz in PHASE mode.

However, it might be worth dropping the speed further at the low end, perhaps using fast PWM at 2 MHz to get 7.7 kHz with even lower power usage. Maybe that could save another half-milliamp or so at moon level.

Edit: Nevermind. That actually increased power use. It ran at the right speed, but using fast PWM also turns on the FET at each PWM pulse (even at 0)… so moon is significantly brighter and power use is higher too, despite the lower clock speed. I guess that’s the answer for “why not use fast PWM?” — because it tickles the FET.

Instead, I can run moon (and just moon) at 2 MHz, a few low modes at 4 MHz, and everything else at 8 MHz. All phase-correct. This gets moon down to 2.1 mA at 4.2 V or 1.3 mA at 3.0 V, and it’s still reasonably stable. Higher modes are unaffected.

So, runtime on moon should be up to about 73 days now.

Flashy Mike
Flashy Mike's picture
Online
Last seen: 49 sec ago
Joined: 01/14/2016 - 16:38
Posts: 753
Location: Germany
ToyKeeper wrote:
I don’t want to use fast PWM on higher modes since there’s an issue with PWM=255 not being completely on. It has a short “off” blip each cycle much like PWM=0 has a short “on” blip.
Have you ever seen this blip at PWM=255 on a scope? According to specs it only happens at PWM=0 (in non inverting mode).
Quote:
The extreme values for the OCR0A Register represents special cases when generating a PWM waveform output in the fast PWM mode. If the OCR0A is set equal to BOTTOM, the output will be a narrow spike for each MAX+1 timer clock cycle. Setting the OCR0A equal to MAX will result in a constantly high or low output (depending on the polarity of the output set by the COM0A1:0 bits.)
ToyKeeper
ToyKeeper's picture
Offline
Last seen: 3 hours 26 min ago
Joined: 01/12/2013 - 14:40
Posts: 6406
Location: (469219) 2016 HO3
Flashy Mike wrote:
Have you ever seen this blip at PWM=255 on a scope?

Nope, I don’t have a scope. But a few years ago I tested turbo output both ways and found it was slightly higher in phase-correct mode. That was on attiny13a though, not attiny85v.

In any case, can’t use fast PWM because it tickles the FET when it’s not supposed to be active.

Flashy Mike
Flashy Mike's picture
Online
Last seen: 49 sec ago
Joined: 01/14/2016 - 16:38
Posts: 753
Location: Germany

Don’t know why the FET is involved in your setup. Checked my test setup (on breadboard, not a real light) right now with scope and couldn`t see anything unusual regarding the FET. Also programmed my BLF Q8 (own firmware) to use PWM=1 (7135 only) as lowest setting and measured 3.5 mA (at 4 Volt, 4 Mhz clock and fast PWM, CPU running normally, not idle). All LEDs glowing. When sleeping 23 uA (with BOD). Just for comparison.

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

I also measured about 3.5 mA. It was a downgrade from the 2.5 mA current I was getting before.

The FET is involved because the 7135 chip and FET share a counter. Pins 5 and 6 both do PWM, but they’re tied together. So in fast mode, they’re both affected by the quirk which turns the pin on at PWM=0. This might not be an issue on 3-channel drivers with the FET on pin 3.

The speed of the FET varies with different hardware though, so on some it won’t light up at all at level 0, while on others it’ll be bright enough to see by in the dark.

Flashy Mike
Flashy Mike's picture
Online
Last seen: 49 sec ago
Joined: 01/14/2016 - 16:38
Posts: 753
Location: Germany

In my light the FET is not involved. In my code PWM (OC0A and OC0B) is disconnected from the output ports for PWM=0. There is no PWM signal at all in this case. The pins are constantly low when PWM=0.

But I did some investigation with my scope and I guess I found the cause for the difference in current at same clock speed and different pwm modes:

With PWM=1 and fast PWM the duty cycle is twice as long as with phase correct PWM. Due to the way fast PWM works the relationship of pwm value and duty cycle is not linear. So the higher power consumption we see with fast PWM over phase correct PWM is just the about 1.3 mA additional LED current caused by the doubled duty cycle.

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

I added some dynamic CPU speed management directly into FSM today, instead of doing it in only a few modes of Anduril. If the option is enabled at compile time, it’ll underclock the CPU to save power in a couple circumstances:

  • When the brightness is low enough that CPU power draw is a significant factor in efficiency. (or, low enough that the slower speed shouldn’t be audible)
  • When the UI uses a delay function, like between beacon blinks.

This makes moon mode and all other low modes (like beacon, lockout, goodnight, battcheck, etc) more efficient.

With stuff like this dynamic CPU underclocking, abstracted hardware support, and the multitasking framework, it really feels a lot like writing an OS kernel. It’s much simpler, of course, but still pretty similar.

Agro
Offline
Last seen: 10 hours 55 min ago
Joined: 05/14/2017 - 11:16
Posts: 904
Location: Ślōnsk

TK, some time ago I suggested looking at Vf to read junction temperature.
It was a bad idea, I understand that now.
But how about using it as an indicator of temperature gradient or at least direction?

Agro
Offline
Last seen: 10 hours 55 min ago
Joined: 05/14/2017 - 11:16
Posts: 904
Location: Ślōnsk

Got Haikelite MF02 today. This light has a really hopeless UI. I thought about reflowing the LED with XHP35 HI, but it won’t work, a full driver swap is needed to make it a good light.
But nevertheless it has a solution to one hardness that I have with D4 UI, which is shared by Andúril.
As a new user of this UI, I would frequently start turbo, want to step back, click once instead of twice and pollute the mode memory with turbo.
Now I don’t make this error, but nevertheless I often have problems to return from turbo. I keep double-clicking, the mode doesn’t change. I don’t really know why. Maybe I somehow have turbo memorized too? After a few trials I unscrew the battery tube.
MF02 steps down from turbo with 1 click. That’s way more natural for me. And if you want tu turn off, you just click again. You can do it very fast, a regular 2-click turns it off.

As we’re on it, I have another note.
I really like mode memory. But only as long as the light’s memory is not longer than mine. Today I blasted myself with a high level again. Not directly, but the reflection from the earth was painful nevertheless.
I believe adding a time limit to mode memory would largely solve the problem.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 3 hours 26 min ago
Joined: 01/12/2013 - 14:40
Posts: 6406
Location: (469219) 2016 HO3
Agro wrote:
how about using it as an indicator of temperature gradient or at least direction?

The driver already uses the temperature’s derivative to decide what to do. It works pretty well, especially in the newest version. That’s how it starts steering before reaching the turn.

Agro wrote:
I keep double-clicking, the mode doesn’t change.

I ran into some click-detection issues in the D4 code… issues which have been in every open-source e-switch light I’ve seen for years. In the D4 it seemed to have difficulty detecting very fast clicks or very fast double clicks. I’ve also heard about some similar issues in the Q8, where once in a while, on some lights, clicks just don’t register.

That’s part of why FSM is a complete from-scratch rewrite using different techniques. One of the things it fixes is click detection.

Agro wrote:
one hardness that I have with D4 UI, which is shared by Andúril … pollute the mode memory with turbo.

That doesn’t happen in Anduril. It was one of the first things I fixed. Double click to jump up, single click to turn off, and the next single click goes to the previously-memorized value… not turbo.

However, there is one caveat to that — if the ramp ceiling is lower than turbo, and the user does a double-click from off to reach the ceiling, then does a double-click to reach true turbo, it will then remember the ceiling level. This can be avoided though, by turning the light on with a single click and then doing a double click to true turbo. Or by setting the ceiling to the highest level.

I’m undecided on whether that should change, whether return-from-true-turbo should always return to the brightness the user was at before, or if it should specifically exclude moon and turbo from that.

Agro wrote:
time limit to mode memory

The driver can’t measure time while it’s off, so making memory time out isn’t very feasible unless I increase the standby power significantly to keep the WDT active. There are features I’d like to try which require this though, like an alarm clock mode and a locator flash, so it’s on the todo list.

Agro
Offline
Last seen: 10 hours 55 min ago
Joined: 05/14/2017 - 11:16
Posts: 904
Location: Ślōnsk
ToyKeeper wrote:
Agro wrote:
how about using it as an indicator of temperature gradient or at least direction?

The driver already uses the temperature’s derivative to decide what to do. It works pretty well, especially in the newest version. That’s how it starts steering before reaching the turn.

Agro wrote:
I keep double-clicking, the mode doesn’t change.

I ran into some click-detection issues in the D4 code… issues which have been in every open-source e-switch light I’ve seen for years. In the D4 it seemed to have difficulty detecting very fast clicks or very fast double clicks. I’ve also heard about some similar issues in the Q8, where once in a while, on some lights, clicks just don’t register.

That’s part of why FSM is a complete from-scratch rewrite using different techniques. One of the things it fixes is click detection.

Agro wrote:
one hardness that I have with D4 UI, which is shared by Andúril … pollute the mode memory with turbo.

That doesn’t happen in Anduril. It was one of the first things I fixed. Double click to jump up, single click to turn off, and the next single click goes to the previously-memorized value… not turbo.

However, there is one caveat to that — if the ramp ceiling is lower than turbo, and the user does a double-click from off to reach the ceiling, then does a double-click to reach true turbo, it will then remember the ceiling level. This can be avoided though, by turning the light on with a single click and then doing a double click to true turbo. Or by setting the ceiling to the highest level.

I’m undecided on whether that should change, whether return-from-true-turbo should always return to the brightness the user was at before, or if it should specifically exclude moon and turbo from that.

Agro wrote:
time limit to mode memory

The driver can’t measure time while it’s off, so making memory time out isn’t very feasible unless I increase the standby power significantly to keep the WDT active. There are features I’d like to try which require this though, like an alarm clock mode and a locator flash, so it’s on the todo list.


Thanks for the answers TK.
I’d like to add that the memorization of turbo when I wanted to return to regular mode only aggravated the problem that I had anyway – that the action that was natural for me did something different from what I wanted.
I trained myself to do it right now, but I strongly feel I would have been happier with MT02 style return from turbo.
goshdogit
goshdogit's picture
Offline
Last seen: 2 hours 36 min ago
Joined: 12/03/2015 - 21:28
Posts: 404

I’ve been using Andúril on a BLF Q8 and an Emisar D1 for a few days now.

In short, I love Andúril and I want it on all of my lights! Love

I have some ideas for changes and additional features. I know nothing about programming or the time, effort, and space these features may require, so I’m not gonna hold back. Wink

My favorite features

  • moonlight mode during lockout
  • adjustable momentary output
  • momentary disabled only by power cycling
  • double click from turbo returns to previous output level
  • memory for previously used strobe mode
  • adjustable brightness for bike flasher
  • ‘Lightning Storm’ mode

Ramping

  • option to disable click & hold for ramping down? (ramp changes directions like Narsil)
  • option to disable blink at max regulated output?

Good Night mode

  • option to adjust starting output level?
  • option to adjust time until power off?

Possible bug

  • dimming bike flasher to minimum enables an unbelievably low steady output

I’m not sure what TempCheck is telling me. On a Q8:

  • room temperature light – 8 long blinks
  • after 15 sec turbo – 1 long blink, 1 short blink
  • after 30 sec turbo – 1 long blink, 2 long blinks
  • after 1.5 min turbo – 1 long blink, 7 long blinks
  • after 3 min turbo – 1 long blink, 9 long blinks

More blinkies, please! I realize these are silly and may take up valuable space. If not implemented officially, I may need to learn some C. Big Smile

  • party strobe with random brightness / speed changes
  • defective lightbulb mode
  • candle mode
  • other fun blinky modes TK is holding out on Party

How about a ‘Muggle Mode?’ I’d like to hand the light to someone and say “Click to turn it on and off. Hold the button to adjust the brightness.”

Part of the fun of owning awesome flashlights is sharing them, especially with muggles. I’ve discovered that many of them, even after training, will randomly mash buttons and enter config mode within seconds of holding the light. Some have been known to turn the light off and forget where they put it. An optional beacon mode at ‘power off’ would help shorten hide-n-seek times.

Some ideas for ‘Muggle Mode’

  • disabled only by power cycling
  • uses preset, adjustable ceiling level
  • disables true turbo
  • option to disable double-click shortcut, or become shortcut to ceiling
  • memory works the same as usual
  • disables click & hold to ramp down, holding the button allows ramping both up & down (like Narsil)
  • disables advanced features and config modes
  • disables blinks at max regulated output and at ceiling
  • option to disable power off, instead entering a beacon mode

If I knew anything about programming, my list of suggestions would probably be much shorter. Big Smile

Andúril is my new favorite UI, and I would happily use it as-is until TK’s next ‘greatest UI ever.’

Flashy Mike
Flashy Mike's picture
Online
Last seen: 49 sec ago
Joined: 01/14/2016 - 16:38
Posts: 753
Location: Germany

Especially for muggles I password protected config mode in my firmware. I don’t want the security settings (voltage, temperature) to be changed.

goshdogit
goshdogit's picture
Offline
Last seen: 2 hours 36 min ago
Joined: 12/03/2015 - 21:28
Posts: 404

Flashy Mike wrote:
Especially for muggles I password protected config mode in my firmware. I don’t want the security settings (voltage, temperature) to be changed.
Neat idea!
Tixx
Offline
Last seen: 1 week 1 day ago
Joined: 08/27/2015 - 22:34
Posts: 89
Location: United States

I thought the double click being touchy was just me. Thanks for the info!

Pages