STAR Firmware by JonnyC - Source Code and Explanation

In my opinion ontime with “no memory” is 100% intolerable. It’s the polar opposite of offtime with “no memory”. Look forward with hope. :wink:

FWIW, the off-time firmware expects the capacitor to be on the star normally used to toggle memory. So, there is no “no memory” option. You’ll probably have to add that yourself, but it’s not too hard. The issue is that end users won’t be able to toggle it.

Personally, I’d rather sacrifice the mode-order star for this instead, and retain the moon toggle and memory toggle. Always low to high, but at least people can have memory if they want it.

BTW, if you enable mode memory without the capacitor, it’ll still take two clicks to change modes. It’s really annoying. Sometimes it’ll take one click, sometimes two, depending on how long the light has been on.

I still find it preferable to ontime with memory. I don’t really mind short-cycle memory, since the most-used modes are generally at the beginning so they never take many clicks to access… and the least-used modes are at the end where they can be ignored most of the time.

Hmm. I’ve only used ontime with no memory on the bench. Maybe if I used it on an EDC things would seem different. Make no mistake: I also strongly dislike the “sometimes one, sometimes two” taps required by a standard ontime-with-memory firmware.

Agreed. Ontime without memory is preferable to ontime with memory, but still not ideal.

We can probably all agree that on-time anything is worse than off-time anything :) A lot of us "grew up" with on-time w/ memory, so for me I was entirely used to it. But anytime I gave a light to a friend and tried to explain how it worked I realized how horrible the UI is.

Hoop - Awesome, awesome, awesome shop. A new flashlight company, hell yeah! I'm excited to see what you can do.

Thanks Hoop. I'm pretty much speechless. Just gotta say love the garage.

I’ve run into a problem, I’m not sure why.

I built up one of these: DD driver w/ low parasitic drain for e-switch lights. I used 10uF for both input and output capacitors on the LDO (a 3.3v LT1761).

Then I flashed it with STAR_momentary w/ voltage-mon disabled. (how do I properly refer to the commit I used? Is there a concise way to communicate this information? ba5fb9efbd5ad11e0edd4008123301532ac0a277 ?) (for my own reference - 2014-12-20_STAR_momentary_v1.6+no-voltage-mon.hex)

The problem is that in the highest mode (Turbo) only a long press works. A short press doesn’t switch from Turbo to Off. I can step through the modes forward as expected - 0,3,14,39,125,255, but it does not loop from 255 to 0. I can step backwards 255,125,39,14,3,0 and have it loop from 0 to 255 as expected. Turbo does have an MT-G2 at >8A, but I don’t see how that would have an effect on my momentary input to the MCU, especially when we consider that it does recognize the long press. Any ideas? Thanks!

Crap, that sucks. When you are in turbo and a short press doesn't turn it off, will another short press bring you to the first mode? I remember there was an issue with the PWM output not getting set to 0 before going to sleep for some crazy reason that makes me hate AVR programming, which is why I added this stupid line of code...

_delay_ms(1); // Need this here, maybe instructions for PWM output not getting executed before shutdown?

That seemed to fix it, but maybe it isn't enough. Are you able to (I hope!) reprogram the driver with ease? Maybe you can try commenting out the "sleep_until_switch_press()" call when it shuts the light down for being at the 0 index mode and see if it works then. This is not a solution, but it will be a way to debug it.

Thanks JonnyC! Good question, I didn’t connect the dots on my own. This is such a high current setup I can barely get my thoughts together during my brief, brief tests.

Yes, two short presses takes me to the first mode. I can go back to “off” with a long press. It seems that the problem is exactly as you suspected.

Unfortunately the driver is in a difficult to reach position. (oops!) I’ll build another for testing. Once there’s a solution I can take the other out and flash it. :slight_smile:

I’m eyeballing the sleep_until_switch_press function now. I guess this is the sort of thing where the debugger that was recently discussed could be very useful; many important things happen in that function and in the WDT_off() function it calls.

I guess you suspect that a slightly longer delay could band-aid the situation?

Son of a beach!! It was an actual bug. On December 13th I added an extra mode but did not add the corresponding "FAST" to MODE_PWM. Not sure exactly how it manifested itself in this behavior because I don't know how the code would react to an array index out of bounds. Whatever the case, it broke it.

Please pull the latest copy or just add another "FAST" to the MODE_PWM list. Sorry to anyone that this affected!

I just ordered some 1uF 0805 caps for off-time memory but I also have a cap from a stripped nanjg of mine and I wonder if I can use it for this? What are the specs of the standard caps on a nanjg?

It’s been said that it’s a 10uF cap. I’m confident it’s >4uF. 10uF may work fine, but you’ll probably need to adjust your offtime value. EDIT: for some additional info, look in the first 5 pages or so of this thread for HarleyQuin’s post(s) on the subject. HarleyQuin tried much smaller values than 1uF and was able to get those to work.

Caps on my seven 105Cs (both 8x7135 and 6x7135 versions) are all in the 3.5-4.2uF range

Heh, maybe I should have been confident about a different number.

I tested somewhat recently to see when the ATtiny13A would start working properly. Now that you call me out, I think I tried 1uF, 2uF, 3uF, and then got tired and went directly to 5uF. Ahh, here we are: Phase Correct PWM So much for confidence! :wink:

AK-47A 3x7135 with the same ATtiny13A has 1.6uF capacitor :slight_smile: Guess it depends on the load for ATtiny to drive.
On the other hand, 101-AK-A1 4x7135 has 7.5uF cap…

BTW, it’s a good idea to use PHASE on the highest and lowest mode. This prevents the moon-like fast PWM=0 mode from sticking around while the switch is pressed, and helps the light to shut off entirely.

On the lowest mode, PHASE can usually get lower than FAST, so that’s a benefit. And on the highest mode, PHASE and FAST are no different so you may as well use the one which won’t trigger the moon-while-pressed bug.

Out of all the firmwares I’ve made, the Ferrero_Rocher.c one is the most similar to base STAR. It might be worth a look in case there are any improvements you’re interested in. The main things are UI (press-and-hold ramps down and shuts off) and a battery check mode (from off, short-press then immediately long-press).

Has anybody looked with an oscilloscope if PWM 255 is 100% on?
Edit: I found the answer by changing my search words. PWM 255 appears not to be 100% on: Test/Review of Qlite Rev.A 7135*8 Multiple Modes Circuit Board 3.04A

On the graphs there, I see a small dip in the PWM each cycle on the highest mode. The qlite runs in fast PWM mode though, which I’ve had a suspicion might do that. Just like it always turns on a little bit even when the value is zero, I had heard that it might not stay fully on in turbo. It’s hardwired to turn on at the beginning of each cycle and turn off at the end.

However, I think phase-correct PWM is better about that. It never turns on at zero, and I think at the other end it also never turns off when the value is 255. We could probably verify by measuring lumens on fast PWM=255 vs phase-correct PWM=255, but I’m not sure how big the difference would be.

Yes, Qlite is never 100% on because they must have used inverted PWM, meaning inverted output values...

0 = On

255 = Off

From the datasheet...

With fast PWM, a 0 PWM_LVL (OCR0A) means it is never fully turned off (there's 1 blip of being on out of 255 clock cycles). In Qlite's inverted PWM case, 0 meaning max output, it means it's never fully on, but it can be fully off. We are using non-inverted PWM, so it can be fully on, but it can't be fully off. This is taken care of with putting the driver to sleep so we don't allow the light to run with PWM_LVL = 0 (except as you noted ToyKeeper, it happens when you hold the button to move to the off mode, as long as you hold the button it will sit in this state). I believe this should only happen when the mode order is H-L, correct?

I took your advice and updated the 255 mode to be PHASE. I can't test it because I don't have a FET driver, but you already said it works. I could have also been done by changing the code so that it forces PHASE whenever PWM_LVL is 0, but this is an easier fix.