Hmm. Those two weren’t on the list, but I did have some other ideas for a future project…
I don’t suppose you have any idea which MCU I’d need for that last one?
So lexel, what do you think, is clicky reset to first or last-used mode good enough, or should I add an explicit clicky reset mode configuration? I wasn't excited about your signaling use case much, but having one siwtch come on in turbo and one come on it moon, actually does sound pretty nice. Just using reverse modes doesn't do that. They'll both default to turbo. I think this could be a nice option.
There are probably too many variations of this to entertain them all. It's possible to have the eswitch do forward modes and clicky do reverse. Or one switch does "hidden modes", Or have two modegroup configurations, one for each switch (actually I really like that). It's possible to have eswitch do crescendo, and clicky step through modes. It's possible to add two more switches and turn into into a nintendo game controller (Then there could be combo moves!). There's really no limit here, but obviously some are simpler than others. Just changing the reset mode of the clicky switch independently of the eswitch is probably very simple.
Of course this dual switch stuff has only had very minimal testing on a bench so far, a few versions ago, so there may be a couple of wrinkles to iron out. Getting OTSM working was higher priority, but it's mostly the same part of the code.
There are basically 3 practical solutions
1. Light up when power is applied to max or a high output, even when the mode order is low to high ignoring mode memory,
similar like Klarus XT series, which got 2 different eswitches and the forward clicky is the 3. eswitch as the battery is never disconnected from the driver
2. Light up with last mode the light was used, also when mode memory is disabled
3. As standard Bistro light up last mode memory or the first in your mode order low-high or high-low when mode memory is disabled
OK, right now option 3 should just work, with the right component selection and firmware configuration. ( normal C2---not OTSM-sized---and probably the existing dual-switch firmware, I'll recheck it).
Yeah, but maybe I'll aim toward option 1, in that case I'd make the particular mode a compile configuration. That helps anyway since turbo can move around, and it's easier to switch modes than define an output level override. Also, configurable is nice.
I do like the idea of tail switch double tap to get turbo (double because it would usually already be in the on position, with e-switch sleep), but I don't normally like my light starting in turbo. Ok, this sounds good. As for signaling, I generally just use the phone.
So the present dual switch tripple build is actually OTC, not OTSM (because OTSM was broken then). OTC doesn't work for this. Even if you leave off the OTC cap, then power-off will probably get read as a short click. So I need to reconfigure it with e-switch and OTSM. For now, you can just comment out USE_OTC and uncomment USE_OTSM, but I'll make that the default in the next release. It should be anyway now.
I can share my F-2. I made a dedicated thread for it: Mike C drivers: v8 series, ATtiny1634 based.
Just know that this current version is untested (it is on it’s way from OSH Park). Order at your own risk, I have screwed up before and will again! I can also share my customized 84 MU Eagle library part, I use it for the 841 as all pins are the same.
If you build and populate the board, PA5 (MISO) has a via for flashing but is otherwise unused, so this pin could be used for additional testing of inputs/outputs. I don’t have a shareable baseline firmware yet, but will share one in the above linked thread when I do.
how hard is it to port Narsil Triple v1.4 to another MCU and add LVP divider on another pin taking the code sections from Narsil v1.2
I know Tom E is busy with Q8 Narsil final code, but hes not the only capable programmer here
If this works out great a 30mm version for Convoy L6 planned?
I’m not very familiar with Narsil’s code, but in general most of the MCU and pin layout details can be abstracted out to make these things compile for multiple targets. Some of that is already done, by defining the layout and MCU type at the top of the file (or on the command line), but any new MCU will require some adjustments to that. Of course, hardware-specific features still require deeper changes… like we’re not going to get 3 PWM channels on a tiny13, since it lacks the features needed to do that.
So I realized (or re-realized, that happens often it seems) that dual swtich with OTSM has an issue. Eswitch needs 220kohms (ish) to keep parasitic drain down. OTSM needs max 4kohm (ish... but actually that high is already having a 20% impact on OTSM performance, would have been more without the powersavings option) to keep C1 discharge time fast for power-off detection.
These are directly contradictory. There are a few possible solutions:
1) Do nothing about it. you've got two switches anyway, just use the eswitch when walking around and lock out power with the clicky when done. A person is bound to forget this though. On the other hand, at 1mA of drain that's still 3000 hours off a 3Ah cell, which is a 125 days! So even if you forget, it won't drain overnight. I will drain significantly in a few weeks.
2) compromise, try to reduce C1 by 10 times, DEL doesn't like it, but it might work ok. Then you can increase the resistances by 10 times, 40kohm, so that gets you to 1,250 days... not too bad.
3) Need an active pulldown. This would basically require a depletion MOSFET, normally open, so when power goes down, it opens and drains C1 fast. It's an extra component on the board. I guess this requies another diode too, or some combined part. Hmm, seems there are ldo's with active pulldowns that could do it. This doesn't just replace the usual LDO though. There needs to be a barrier before C1 and one after C1.
By the way, this has nothing to do with the lexel option 3 solution. That's an OTSM firmware used without the OTSM cap.
Regarding OTSM, I ran my light down to LVP twice. No issues really. OTSM keeps working all the way to the end (2.7V LVP). I had long press set at 1.25s, so I don't know beyond that. I've changed the default to 1.5 since 1.25 feels a touch too short, and there's 3 or 4 s available.
The "worst" behavior I found was that when the LVP stepdown triggered it just marched its way straight down to off, when it seemed like there was enough juice to turn it back on in moon mode. I have trouble even caring. It was 2.8V and playing with it in different modes for about 2 minutes completely finished it off, so it's not like there was much left to save. Otherwise, no issues.
4) Make a dual switch dedicated firmware option/definition that always has a mode active if the power is on.
I almost like it for a second, but then not really sure. You want to be able to turn the light off from the side switch. I suppose it could be an ultra-low moon, just to remind you its on. Not loving it, but it's better than nothing. And actually an firefly mode can use less power than than the 1mA drain, so in that's sense it's not bad. I'm on the fence.
I take it back, an ultra low moon can't use less current than 1mA. The lowest I got the mcu itself while running PWM was 2.1mA, after adding idle sleeps. Still it will save you power for the most part, when you don't forget to turn it off.
You know I'm not really sure reducing C1 matters in this case. There's of course already a HUGE cap buffering the mcu itself from voltage spikes. C1 is at most buffering the diode/LDO from voltage dips really, not even spikes (the diode still passes spikes to C2) and also the voltage divider. Part of the solution may just be getting a diode that can take it. The question is how much does the noise on the voltage pin matter. For OTSM itself you don't want pin bounces. For >1S lights you'd like good voltage readings. I'm just not sure how low it can all be pushed. 0.1uF is a pretty standard bypass cap, but for logic not ADC, and probably not for environments slamming 5A of current on and off, so yeah, the 1uF number seems sane, just not sure where the limit really is.
If you want to be able to do that, then it’s not the best option, no. I don’t see why you would want to if you have a power switch, but that’s irrelevant.
Just a matter of ergonomics. One nice thing about a side switch is just where it is under your thumb when holding the light at your side. I don't always walk around in police tactical mode with my thumb at my ear. Actually the tail switch still works well at my side, if I want to see something behind me.
Actually between the two options, I'd rather just have the power switch not be OTSM, just a dumb switch, and get full control at the eswitch, assuming a tail power switch and side e-switch. Fortunately there are in-betweens for that route too, OTC or noinit. I'd probably just go with noinit in that case. If I need revers/hidden modes, can still use the side switch for that. Better than being forced to use the rear switch for off.
I agree with the ergonomics, I use my hand held lights that way while moving around underground, using the side switch to change modes. I just don’t need to turn it off that way.
You know, I’ve been really tempted to do that. I don’t have any dual-switch hosts, but I do at least have a test light with an e-switch for development. I think it could be very simple:
While off:
- Click the clicky switch to turn on at the last-used level.
- Hold the e-switch and click the clicky switch to turn on in moon or turbo, depending on preference.
While on:
- Press and hold the e-switch to ramp. Release and hold again quickly to ramp the other way.
- Press the e-switch once for turbo, once more to return to previous level.
- Press the e-switch twice for battcheck, once more to return to previous level.
- Click the clicky switch to turn off.
It’d save the current level to eeprom every time ramping stops, and then the clicky button would easily be able to do signalling and other momentary use, in addition to its normal purpose of turning power on/off.
Offtime doesn’t need to be measured at all.
I recall several people asking for something like this… so I suppose I should probably make it. I’ve been procrastinating because I don’t have any hosts capable of using it. I’d imagine it should work fine on a common tiny13, though tiny25 and FET+1 would be preferable.
I finally had a chance to catch up on this thread. Wow!!!
I found myself having many comments along the way but I was kind of late to the party:)
However, regarding programming from a smart phone, even if programming from the led is not possible yet, programming from USB should be possible? The config options of this “new” HD firmware is SCREAMING for a smart phone app.
Some of the recharge lights out there have a couple extra data pins unused on the USB port. Programming from a computer is tedious, but programming from s smartphone is acceptable family fun even at the dinner table 