STAR Firmware by JonnyC - Source Code and Explanation

Correct.
Intended behavior for “offtime short-cycle” would be to go to medium, if I’m not mistaken. In offtime mem, short-cycle shouldn’t be come into play for button taps. Only full / long clicks (which discharge the OTC below the threshold for a long click).
Now, I’ve never had or used a short-cycle light so this is just from my understanding of them.

It’s a pain, isn’t it?

Using the best available components helps reduce the temperature sensitivity, and getting drivers from a high-quality source (or building them yourself with a consistent method) helps reduce variation between individual units. But even in the best case it’s still not as consistent as an e-switch.

Two improvements under discussion at the moment are replacing the OTC with a bigger cap plus a resistor (to make the drain more consistent) or attempting to make the MCU detect power-disconnect events, go into super-low-power mode, and keep running long enough to measure button timings. Both are likely to require hardware changes, and the last one might not even be feasible since a 22uF C1 is probably not big enough to run the MCU for more than a few milliseconds.

For personal use, I just calibrate the OTC individually for each light, using a metronome, with drivers from RMM. That gets them about as close to ideal as currently possible.

On the other end of the spectrum, Manker’s drivers are particularly inconsistent and often pretty far out of spec. :frowning:

As for offtime short-cycle, I guess I was wondering which specific conditions should reset it to moon:

  • Long-press followed by an immediate short-press? (yes, I assume)
  • Long runtime followed by a short-press? (not sure)

Or should it behave more like TheStar, which cycles through regular modes but not blinkies? That is, unless the user quickly cycles through all the regular modes twice. So, it short-cycles back to the first matching regular mode, but does not specifically short-cycle back to moon.

The only short-cycle UI I’ve actually used is the ontime version, which is fairly straightforward.

  1. yes. Go to moon.
  2. no. Just go to next mode / normal short-press behavior.

I’m not sure if I understand.
Should short-cycle skip moon, since it’s a bit of a special mode? You could if you want but I don’t know if that is standard in most short-cycle implementations.

Oh, it’s not that TheStar skips moon
 it just acts (usually) like a boring 5-mode light with memory. But if you cycle quickly through those modes twice, it’ll enter the blinky modes.

I don’t know what to call that style of memory and cycling.

I found it a bit awkward, personally. If I’m on medium and I want blinky 2, it means tapping a bunch of times to go to medium, high, turbo, moon, low, medium, high, turbo, moon, low, medium, high, turbo, blinky 1, blinky 2. Then after using it a while, getting to blinky 3 will take a bunch of taps too, since the next one goes back to moon.

However, it is rather good at keeping the blinkies out of the way when you don’t want them.

Instead of that, I just went with offtime no-mem. It lets me decide whether to go to the next mode or back to the first, simply by tapping for less than or greater than half a second.

Fixed that for you. :wink:

TheStar is build with an assumption that the hidden (blinky) modes are not used very frequently. Usual TheStar config is 3 modes + hidden extras.

Note that the version in your repository packs in “too many” hidden modes, just to showcase them. An ordinary user can’t memorize them and/or find the correct one when needed => using only 1-3 extras is highly recommended. (for example: Moon, bike flasher, strobe)

Offtime no-mem is good if you usually want to use one of the first modes. (Low, med - or High, med)
The advantage of TheStar (or any FW with ordinary short-cycle memory) is that it allows you to leave the light on a desired mode and turn it on with that mode when needed


For example:
Click-click-
click-Moon> turn the light off -> wake up at 2am -> turn the light on (moon) => don’t accidentally wake up other family members
Click-click-
click-Strobe> turn the light off -> go to a walk -> face an attacker -> turn the light on (strobe) => STROBE!

Yes. Usual TheStar has Moon as the 1st hidden mode, but it can be (of course) added as a normal mode if used “too often” to avoid two cycles of modes to access it.

Thanks!

It was in kind of a dusty part of my head.

Oh, that explains a lot. I had wondered about that.

Code updates are always welcome. Newer TheStar code is on my todo list and everything. :slight_smile:

I'm not sure that explains it right. Go to the source for the best definition of short cycle memory: http://drjones.nerdcamp.net/

Short-cycle memory is a special UI that allows to have memory and many modes without the need to cycle through all of them.
With classic memory you have a few modes, and if you want to go back to the first mode, you have to cycle through the remaining modes.
With no memory, you always start at the 1st mode and don't always have to click through all the modes, but you have no memory.
With short-cycle memory, a mode is memorized (i.e. if the light is switched off an on again, it comes on in that previously used mode), but when you change modes again, it will restart in the first mode instead of the next mode, so you don't have to cycle through all the modes. This combines memory with the advantages of a no-memory-UI. It effectively hides every mode behind all it's predecessors and is very effective if you have your favourite modes in front and blinkies or other rarely used modes at the end. I call it "short-cycle" in contrast to the classic cycle-through-all-modes memory, but it was actually invented by sixty545 at BLF.

It's a great way to avoid hi and blinky modes when those modes are defined at the end of the mode list.

I am trying like hell to finish my D01, but can’t make STAR Momentary work the way I want it to


Ok, so I added the tail switch to my D01 and modded STAR Momentary to these modes


#define MODES 1,39,150,255 // Must be low to high, and must start with 0
#define ALT_MODES 255,255,255,255 // Must be low to high, and must start with 0, the defines the level for the secondary output. Comment out if no secondary output
#define MODE_PWM PHASE,FAST,FAST,PHASE // Define one per mode above. 0 tells the light to go to sleep

When I turn the light on via the tailcap switch, I still have to hit the momentary button to wake it up. After that it cycles through the modes fine and the tail cap of course shuts it off. What am I missing? I really wanted to hit the tailcap to turn it on in low and the cycle the modes
 With the 0 levels gone, should not the cpu boot and give me the lowest mode with out a side button press?

I have decided that it takes an interrupt to wake up the MCU, that interrupt is generated by the side switch. How do I disable the requirement for an interrupt and force the MCU to boot with power applied via the main tailcap switch?

I know someone has made this work
 I have looked at the STAR dual switch, but it is not built for dual PWM channels. I guess that I could abandon the channel that runs the 7135 and go purely FET and run that code. What are the other options for dual switch code?

Thanks Matt

The first thing that happens when the MCU receives power is what you see in int main(void) - if we take a quick look at that we see that some setup is done, then it drops into a while loop looking for mode changes. If there is no mode change, it does not attempt to set the output. In my opinion, the fastest hack is probably to just change line 411:
uint8_t last_mode_idx = 0;
to
uint8_t last_mode_idx = 1;

This will make it appear that a mode change has occurred every time the light is powered on. The mode change will be from mode 1 to mode 0 and it will set the output to be appropriate for mode 0.

Wight, that made so much sense
 but no go same behavior. I have 4 modes defined, none of them 0 modes so as to prevent MCU shutdown. Looked at the code around the line above and that really looked right.

Oops, sorry. I didn’t notice line 409 sleep_until_switch_press();

So here are a couple of things:

  1. I don’t see why you need line 409 for your application.
  2. Note the first if inside the while(1) loop - that’s a problem for you I think. Remember that there’s a difference between mode_idx==0 and any modes actually defined as 0 (eg PWM=0/255). This firmware is designed around having modes[0] == 0
 you’ll probably have to iron out a few more little things.
  3. With that said
 I hacked it up a little. I removed line 409, I removed the offending IF statement I mentioned above, I removed the IF statement and actions from 435-439, and I changed the initialization on line 411 as described previously. It’s not a great hack, but I think it’s probably going to work for you. STAR_momentary_v1.6w1.c

I got dual switch controls fully working in Narsil a while back. I basically merged the two different firmware versions - best-of-both, post 729 here for latest source code and manual. Not to keen on enabling the tail switch for mode changing though - don't understand the usage scenario. It's great for a power lockout in certain lights, but Narsil has a built-in sequence to lock-out the e-switch, just like commercial lights now (I think mine is better of course ), and the CPU drain in power saving mode is pretty darn low.

I think you might find when you merge the capabilities of clicky and e-switch firmware (without cutting features), you are out of memory in a 13A -- that was the original reason why I went with the 25's and above.

What is the drain in an eswitch light using the ATtiny mcu's?

Is the power saving mode the same between the 13A & it's bigger brothers?

Ahh, I believe it’s the same between MCU’s. Think power-on #’s are higher cause of running at 8 Mhz, not 4.8 Mhz. Not sure of the exact #’s, but I’ve had 85 based lights sitting for weeks/months on sleep mode. Just going by what others measured/said - been mentioned several times, many others know off hand, sorry, I can’t recall and never measured it. I did recently measure the running MCU with the indicator LED on, then saw it drop to about 1/2 when power saving kicked in. I delay the power savings - normally 10 secs, but when in a low battery state, I keep it running for 6 minutes to periodically flash the indicator LED to show the battery is low, then when it finally goes into power saving mode, I turn off the indicator LED to keep the light alive longer.

Ok, so very close
 the tail cap switch does start the light in the lowest mode. But the modes do not switch
 I am not at a real computer at the moment, on a laptop with cell tether for network and it is really slow. I appreciate the effort! Really! This is coding over my head
 I did not expect to have a problem with simply powering down the MCU.

Thanks Matt

Heh, does a long press work? I think I see what I overlooked. EDIT: no that’s not it, duh. EDIT2: maybe it is, that’s why we shouldn’t do ugly hacks. Check the long press.

This was bugging me so I did some measurements this morn.

Convoy L4 w/13A FET driver: 0.299 mA (139 days to drain 1.0 Ah)

Stock EE X6R: 0.56 mA (74 days to drain 1 Ah)

ZY-T11 clone running a ATTiny85 w/Narsil (Indicator LED Off): 0.326 mA (128 days to drain 1.0 Ah)

ZY-T11 clone running a ATTiny85 w/Narsil (no Indicator LED): 0.302 mA (138 days to drain 1.0 Ah)

Measured a couple other 85 base lights all in the same neighborhood.

Is that from the MCU alone? Or is there perhaps also a voltage divider with resistors of a few Kohm only? Maybe I’m an idiot for believing any of the numbers but the spec sheets for both the 13A and the 25/45/85 claim about 5 ”A in power-down mode with the watchdog timer running and one tenth that without. What you’re seeing is nearly 100 times more so something must be off (spec, hardware, firmware).

See over here . It’s not quite what you want as I modified it for pilotdog68’s triple channel driver but it would be easy enough to add a few ifdef’s to make the pin 3 turbo optional. As it is now, it would still work but without a useful turbo timeout. Oh and it isn’t tested yet so it might not quite work at all :wink: