STAR Firmware by JonnyC - Source Code and Explanation

Because I'll be running an ATtiny13A from a regulated voltage, would it be better to switch the ADC Vref to Vcc rather than the Internal reference?

It seems like this would allow finer control of battery voltage monitoring. Of course the resistors will still be across the battery and the values will need to be tweaked.

Do I only need to change the REFS0 bit in the ADMUX register and adjust the low voltage stepdown values? Or is it even worth the bother?

-Crux

Looks like changing that bit is all you need to do to change Vref, but I haven’t tried it myself. If you’re using an off time cap you’ll have to make a few more changes though.

I didn't think about that... I have figured that too much capacitance on the output of the regulator will affect the click times, may have to add a bleeder resistor to hasten the discharge. But this will (slightly) increase current draw with no benefit to the LED current. Not a big deal for big batteries.

ToyKeeper, thank you very much for your work on this code. I can’t wait to use it in practice. Now I need to find time to try it in practice.

Regardless of actual battery voltage (tried varying it with lab PSU), I always end up as ADCH=128 and ADCL between 106 to 110.

Don’t know what to try next. The ADC routine is the standard one from Star_offtime. Went through datasheet, seems everything is the same as with tiny13a, but I’m no expert in uC programming.

Hey guys, I’m looking at doing a dual PWM build but I’m wondering, does the alternate PWM output stay on once it get’s to the set-point above and if so, what would be the best way to turn it off, so it’s only one or the other outputs? I’m wanting to make it so moonlight is a separate emitter (and it’s own 7135) and that emitter turns off above moonlight.

Yes, it stays on. Check out Toykeeper's STARRY mod, or alternatively just change the code from

void set_output(uint8_t pwm_lvl) {

#ifdef DUAL_PWM_START

if (pwm_lvl > DUAL_PWM_START) {

// Using the normal output along with the alternate

PWM_LVL = pwm_lvl;

} else {

PWM_LVL = 0;

}

#else

to

void set_output(uint8_t pwm_lvl) {

#ifdef DUAL_PWM_STOP

if (pwm_lvl > DUAL_PWM_STOP) {

// Above this level alternate will turn off

PWM_LVL = 0;

} else {

PWM_LVL = pwm_lvl;

}

#else

And also define a DUAL_PWM_STOP value. Toykeeper's method is much simpler, and more in line with what how the momentary firmware works.

Ok thanks man. One more question, now that I’m looking at it- what’s the best proper way to enable moonlight when using the alternate PWM output? Before [when using a single PWM, before the new stuff came around] if I wanted to make moon be on without having to solder the star I would do this:

if ((PINB & (1 << STAR2_PIN)) > 0)

Is that still how I should do it or is there a better way?

edit: stupid smileys

With JonnyC's firmware if you use the secondary PWM output then moonlight is automatically enabled, since the firmware was originally designed as a firmware to get an exceptionally low moonlight (obviously not to control two different colors, otherwise the interface would be different).

In short: no need to change anything. I would take a look at what Toykeeper has done, as it may be easier for you to do what you want with your project.

In the starry-offtime firmware, the only solderable star is the one which toggles mode memory. All the other pins are used for other things.

So, you’d probably want to just do something like this in the #defines at the top:

// PWM levels for the big circuit (FET or Nx7135)
#define MODESNx             0,2,12,100,255
// PWM levels for the small circuit (1x7135)
#define MODES1x             3,0,0,0,0
#define MODES_PWM           PHASE,FAST,FAST,FAST,PHASE

Edit: You might also want to remove the HIDDEN_MODES bits too, which aren’t actually hidden yet. I’ll go back and hide those on a day I’m feeling a little better.

Ok thanks, and I’ll have a look at TK’s FW now too.

What I’m trying to do is make a driver to run my new 17650 light as an EDC, I want to have a triple in it with a nichia 219 powered by 2 or 3 7135’s for a good moonlight (plus low and medium modes) and then have it switch that off and turn on a FET that powers 2 XP-L’s for medium-max (to help with runtime from the little cells), does that seem doable?

I’ve made the changes you specify above and compiled, I got 5 warnings (but all were preexisting), it’ll be a few weeks before I have a board to test this setup tho.

edit: it’s a tail clicky only

That will work, no problem.

If it takes that long, I’ll probably have the BLF A6 firmware done (or released, anyway). It should work too, and does a lot more than starry-offtime. I branched it off to a new file because it barely even resembles STAR any more.

It’s actually a little more indepth than I described above, I don’t know what the A6 FW is but doubt it would be what I need, thanks for the offer tho (and thanks for whatever it is in general).

In this application in actually going one step further and using a head twist as another control method (whether it’s loose or tight). I’ll do a thread on it once it’s done, according to you guys the FW Should be good, just waiting on the board for it to control it all.

Ah, I have a host here waiting for me to mod it and write firmware including a head loose/tight sensor. I just haven’t gotten to it yet.

Nothing supports that yet, but it’ll be interesting to add.

The BLF A6 is a group buy currently in progress, with wight’s hybrid FET+1 driver in a tube light. It’s kind of groundbreaking in several ways. Take a look here for more details:

Here’s how I implement it for my use, feel free to expand on this method (if anyone needs a driver for a different light let me know, it will be harder than simply sizing this one down ~2mm but not to much I dont think. I dont use any sort of head sensor or monitor for a pull down, I simply use the head tighten to supply GND to the FET’s source.

Oshpark Projects (post 1524 in case you have different page display settings)

This has probably already been discussed and the current work is pretty far advanced but I need to go back for a sec with this question to simple star off time WITHOUT dual PWM; exactly when does the MCU check which stars are pulled down? Is it continuous at every mode change or does it only do it at full reset (when the light either reverts back to the start or to the saved mode, i.e. a long press of the clicky).

Thinking of a way to add a moonlight switch, not to instantly jump to moonlight, but a way to select if moon will be in the mode rotation or not by grounding it’s star with some sort of mechanical switch. Would that work or does it not check the stars enough?

It doesn’t matter which firmware version you look at, all STAR_on_time and STAR_off_time work the same way… they check the stars every time they are powered on.

Note that the stored mode will change when moon is enabled/disabled. (assuming that memory is enabled)

It’s pretty straightforward to see all that in the code: note that the star-checking/modes-setup happens before the main WHILE() loop.

Yep, I got that. Your right it’s very straight forward, what I dont know, and I still dont get after reading your reply is whether it checks it after every tap of the tail switch when it’s just changing modes, or if it only checks it at the initial start up after a full reset (the time when it either reverts back to the start or back to the memorized level).

I guess I could reword my question; Does a short power cycle to advance to the next mode restart the whole thing and re-initialize (thus checking the stars) or does only a full reset cause it to initialize again?

A short tap should re-check the stars.