E-switch UI Development / FSM

dekozn, a 219B quad would probably work with default settings. Those tend to max out at ~2000 to ~2500 lumens, which is reasonably close to the default ramp’s shape.

That is, assuming the driver works the same as the default, which is calibrated for an Emisar D4.

A single 219B likely wouldn’t work well with default settings, since it’ll probably max out at 500-600 lm. The top half of the ramp would go up really slowly. But I wouldn’t recommend a FET for a single 219B anyway; it’s overpowered for the emitter configuration.

anyone tried andruil in a s42s? I’d love to give it a try but changing the driver while keeping the usb-charging seems to be a pain according to lexel…

What are the parameters for “n” values in the config menu?

Are you referring to the Andúril cheat sheet?

’N’ is just a symbol for ’number of times you click the button.’

For example:

  • If you’re setting the interval for beacon mode, clicking 8 times will make the beacon blink every 8 seconds.
  • If you’re setting the ramp ceiling, clicking 20 times will set the ceiling to 130 (150 - 20).
  • If you’re setting the temperature limit, clicking 5 times will set the limit to 35 C (30 + 5).

Does this answer your question?

I got a Q8 in the mail today… and Anduril now has indicator LED support. It’ll probably change a bit in the near future, because I did kind of a quick hack, but it is at least working.

It also adds two more config settings — indicator state for regular operation, and indicator state for lockout mode. Each one can be “high”, “low”, or “off”. At some point I’ll probably also add a fourth state for “blinking”.

To configure these, go into lockout mode. Then click 3 times to step through lockout indicator modes (one step per triple-click), or do “click, click, hold” to select a main indicator mode (release when it’s at the desired level).

By default, it uses high for regular operation and low for lockout. But this could also be low/high, off/off, high/high, or whatever.

The indicator LED does not blink during use, like during battcheck, but it would probably be relatively easy to add if that’s desired.

This is great news btw! Sorry, haven't been following the progress but it sounds all good. Are you using PWM's to control the brightness? If so, is it the same typical rate, ~15K?

Have you considered or looked at external temp sensor support? Are you having the same issue of I/O pin shortages or have you looked at I/O pin sharing as Mike C has done? I really think for us to take the next step, we need to look at the 16 KB Atmel with greater I/O pin counts - this would solve a bunch of road blocks I'm having. We just need to team up with a board designer and come up with an easy way to dnld the firmware to one of these MCU's. Couple options there - not difficult to do, takes some extra real estate, but we also save real estate because of the smaller foot print of these MCU's, if we go with the square 5x5x5x5 configuration.

From this chart: https://en.wikipedia.org/wiki/Atmel_AVR_ATtiny_comparison_chart

best option seems to be the 1634, pricing/package options here: https://www.arrow.com/en/products/search?q=attiny1634

I have used DS18B20 temperature sensors with Arduino projects in the past and had great luck with them. They use the Dallas OneWire protocol to communicate and as such, only require a single I/O pin for the comms bus. Each sensor has a unique serial number so it is possible to control multiple OneWire devices via the same pin. This also means that the code in a production environment needs to be autonomous in discovering and identifying all the devices on the bus. I am not smart enough to know how heavy the library is on memory so I don’t know if it would even be possible in the smaller processors. I have been looking around at various other OneWire devices in an attempt to justify using this method but so far have not found anything terribly promising. The most interesting so far has been the DS2762 Lithiuum battery monitor. It is pretty big real estate wise and the spec sheet appears to show that the current monitor max is 2.5 Amps, but there may be a way around that. It also includes temperature monitoring so would be one device for both temp and battery.

There are also OneWire Real Time Clock chips that would allow much more precise Alarm clock modes.

goshdogit, yes that answers my question:)

TK, that is awesome!

TK might have used the internal pullup resistor.

+1
Tom, if you and TK decide on the next MCU and adapt the firmware, I believe the rest of us will follow and jump on board very quickly. I say just go for it! (On your spare time that is) :wink:

Finally! :partying_face: You had a long wait.

Awesome! I just reflashed three Q8s to play with this evening.

How about a third setting to select indicator high/low/off when the main emitters are on?

What HOLD_TIMEOUT value are you using on your Q8? I’m still using 15 without issue.

Is the low brightness barely visible or it depends on led forward voltage ? Or with a higher resistor on switch board I can lower the brightness more?

No, I set the pin as input for “low” mode. Same trick I used in Ferrero Rocher.

I haven’t really looked into external sensor support, but I’ve tried to structure code in a way which would make it easy to change between internal and external. Pin shortages haven’t been an issue yet but they probably will be in the near future. ROM space hasn’t been an issue yet either, but again, it probably will be.

If I recall correctly, we’re mostly waiting on toolchain support before going to newer MCUs.

I haven’t changed the default HOLD_TIMEOUT. I think the current value is probably pretty close to Goldilocks for the population average, but I’m kinda guessing.

Instead of high/low/off while the main emitters are on, how about a slightly different approach? Set indicator brightness based on main emitter brightness — “low” for moon to 7135, “high” for 7135 to turbo, “off” while main emitter is off? I just tried this on mine, and it seems to work reasonably well. It automatically stays in sync with the main emitters, it eliminates the need for a mid-ramp blink, and it can still be set independently for the two “off” modes (off and lockout).

No, it’s still fairly bright. It’s about 1/3rd as much power.

Hmm I want high as bright as original with narsil and a very low that I don’t see in daylight just in complete darkness. But still great option. Maybe If I change the switch board led resistor to set low mode low enough for me the high will be bright enough for daylight.

Anyone know what is the cause of this error?

avrdude verification error first mismatch at byte 0×0000
0×00 != 0xa0 content mismatch

I successfully flashing the MCU with Narsil. I then tested the driver and it worked. I changed one line of code built a new hex file and tried to reflash the driver but received the error above. I then tried ti flash the first hex file but received the same error.

I’m about to flash a new MCU, but before I do I am hoping for some feedback as I ended up rendering the last MCU unresponsive after several reflashing attempts.

I know this isn’t the best spot for this but I don’t get much response from the Narsil page. I don’t think a lot of able people follow that thread other than tom and he is a busy man. I always feel bad trying to get his attention. Anyway… TMI :slight_smile:

Clever!

Can we still have an ‘always off when main emitters are on’ option?

It usually means a physical issue with the SOIC8 clip connection or how it’s wired. You can probably just carefully re-clip it and try again.

Perhaps.

For now, it just syncs the indicator to the main emitters. An option to control what it does during use would be a good idea though, since “stay off” seems to be a pretty common thing people want. Not sure where to put it though, unless I add another explicit config mode somewhere.

I haven’t done it yet, but it looks like the Q8 needs a different ramp than the D4. I was hoping they’d be close enough to use the same values, but the ramp on my Q8 looks pretty not-linear with FSM. The mid-ramp elbow is pretty noticeable. I did at least make it use a different voltage adjustment factor for Q8 though, so battcheck should be closer to accurate.

I also need to fix thermal regulation again, since the last time I tried it on a D4 I got weird results. It’s probably okay on a Q8 due to its extra mass, but that needs testing too.

There’s also the blinking indicator thing to add, and maybe an alarm clock function, which both need a half-sleep mode. And perhaps a goodnight config mode. Maybe change “goodnight” to “sunset”, and “alarm clock” to “sunrise”. And perhaps a super-simple muggle mode (and muggle config mode to set safe limits).

With all that, I might actually run out of space. It still has about 1000 bytes left, but space is definitely starting to become a concern. Maybe I can refactor the existing config modes into a single common function — same UI but smaller code.

Kinda just thinking out loud here.

Oh, and one of Dale’s Q8s was acting up; sounds like an extra-noisy switch or something. That could probably use some attention. I have some theories, but can’t test them with my hardware because it’s not misbehaving that way.

And I was doing some “bump testing” to see how the Q8 reacts to being hit during use, and a couple times I managed to get it into a state where it wouldn’t respond… and afterward once it acted like eeprom had gotten slightly corrupted (it had an invalid ramp floor setting, which made a couple things act weird). Not sure what I can do about that.

More improvements?! You really do spoil us, TK.

I update Andúril on my Q8s whenever you announce a revision since they’re so easy to open and reflash.

Will there be a compile-time option to configure thermal regulation for different lights? I’m running Andúril on my D1, D4, and X6R, too.

Did this require reflashing to fix?

I don’t purposely bump my lights looking for an issue, but even with occasional drops I’ve not encountered a power-interrupt with any lights.

I’ve yet to drop a Q8 though. :smiley: