STAR Firmware by JonnyC - Source Code and Explanation

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.

A short tap restarts everything. If it didn’t the mode change wouldn’t work as all that is done at start up. It’s basically only watchdog interrupts (for turbo timeout) and voltage monitoring that is running, everything else is start up code.

That’s what makes clicky-switch lights so “fun” to write code for… it resets completely every time the button is pressed, and must boot fresh after each time. It’s actually a lot like how web application code works; it must start fresh on each page load. Anything which passes between pages must either be sent from the browser each time or saved in a cookie-linked session on the server. Except on torches, the “cookies” are in EEPROM or in a capacitor.

In any case, the star-checking code is not a sub-clause of the OTC-checking code, so it happens regardless of how long the switch was held down.

Is there a way to make a driver running Star OT think/act like it’s turned ‘off’ when it is still getting about 2ma of power?

This is a part of my idea in this thread

How to change the is_pressed() function to positive logic in momentary firmware?
I disabled the pullup resistor and soldered a pulldown resistor to the star and ground

I need it because my headlighe has a switch in front and 3 wires going to the battery and driver

  • +led which is also +batt
  • led which is not gnd so cannot use it for the the switch
  • is the switch - I connected the other side it to +led

If I understand your question correctly, you can do this by simply changing the “return (buffer” part to “return !(buffer” to logically invert the value.

Thanks, I will try it at home.
I’he tried it with ~ but it didn’t work. :slight_smile:

So... how feasible would it be to switch the Vref such that the Int 1V would be used for the OTC measurements and Vdd is used for low battery? I'd like to be able to use this with two and/or three cells, and I figure 5V Vdd as Vref will make the ADC count a bit more accurate. But I now realize that a 1V Vref is much more ideal for the OTC measurement. EDIT: or I may just use 20 and 38 for the Med and Short values...

Anyone have any ideas?

you can increase accuracy by calibrating the specfic PCB+voltage divider+MCU combo. Also you can get 10 bits out of ADC, as compared to 8 which are normally fetched in voltage monitoring. Just don’t do right shift of ADCL, but read both ADCL and ADCH. It’s a matter of do you trust more your regulated vref or internal vref, what’s more stable. For even more accuracy I’d check how voltage divider changes with temperature, ideally both resisotrs should increase R in the same percentage thus negating any temperature drift.

what is OTC?

edit: by calibrating I mean this: Get a calibrated multimeter, and for a number of ADC values throughout the range, note the value that DMM is showing. Then make a “adjustVoltageADC(ADCH,ADCL)” function that would actually have hardcoded values of mapping between ADC and calibrated DMM, and for each ADCH, ADCL pair it would interpolate what the actual voltage is. That’s how I plan to do it anyway.

That should be no problem if you have the space. OTC measurement is only done once (during start-up sequence), once that’s done you should be able to switch Vref before starting up the ADC routine for voltage monitoring. But, just to try cover all bases, I am assuming that changing Vref does not have any affect on the output voltage when cap pin is set high to charge the capacitor.

If you can live with checking for a short press only you could switch to the brown out detection method explained here: alexvh's firmware. Update: Hidden strobe, Ramping and optional mode memory added.. As mentioned, this method can’t detect different off time lengths, but for simple short press checking this method is reliable, easier to code and saves you space.

Off time capacitor.

I have a circuit I have been playing around with with a similar situation where the switch is coming from the positive supply (about 4V). With a pull-down resistor, removing the call out to enable the pull-up on the pin, and ToyKeepers mod above, I have the levels changing without an issue.

works also for me also.thanks.

Just got my USBASP in yesterday. I had been building some hex files while I waited for it to arrive.
I just finished up my Convoy C8 with off-time, no memory, MN-L-M-T. No stars on the 105D complicated it a bit, but once I got the levels I wanted (using on-time STAR) I flashed my off-time and then soldered the 1uF directly onto the attiny pins between 2 and 4. PWM level 4 is the lowest the LED would turn on (2800mA 105D w/ XM-L2).
My SRK clone is next on the list.

Thanks!

Ooh, I hadn’t thought about soldering one there… that’s a clever solution. :slight_smile:

For the SRK, be sure to take a look at ToyKeeper/Ferrero_Rocher/* in my code repo. Everything in there should run on a SRK (with attiny13a) and it’s all enhanced compared to STAR_momentary.