STAR Firmware by JonnyC - Source Code and Explanation

Tom, you keep putting things on my todo list. :slight_smile:

Have you ever tried using git/github or bzr/launchpad? They’re pretty helpful for tracking and generally dealing with code.

We use Git @work, but we have our own server repository. Been using github, but not for my own stuff. I know, really should... I gotta get better organized, overall. I'm off in way too many directions.

Awesome, so it shouldn’t be a big stretch. :slight_smile:

I really need to spend some serious time with git. It’s functionally almost identical to bzr, but everything has different names and options and defaults. And git officially won the DVCS wars, so I should get on board with it. Even Launchpad supports it now, though it’s not widely used there yet.

Followup and new find if interested folks

https://www.fasttech.com/products/0/10012070/2056803-sop8-to-dip8-programming-adapter-socket-module

And a 16 pin one

https://www.fasttech.com/products/0/10012067/2056800-sop16-to-dip16-150mil-programming-board

Thanks to the input of several in this thread I was able to manipulate the code for a 5 hour shutoff on a light using the STAR firmware.

I recently had the timer fail. Instead of shutting off as usual, the light kept running.

Any ideas why something like this would happen?

This was on a light that you had tested working previously? A momentary power glitch or inadvertent MCU reset would be enough to reset the timer.

That’s a good point. It might be a good idea to add a “noinit” attribute to the timer variable, and only set it to zero on boot if the offtime capacitor (or noinit-based offtime sensor) says it was a long press. This would allow the timer to keep counting after a short press or brief interruption.

RMM - yes this the timer on this light had been working. Since I posted yesterday it has failed once again. I’ll test again today to see if it continues to fail.

Toy - as always thanks for the suggestion. I may reach out for a bit of clarification on the specifics of implementing this.

I’ve flashed another circuit with the 5 hour timer for testing and have also had this one fail once in about 10 cycles.

Any additional thoughts here?

Many thanks

It really sounds like it might be resetting or rebooting or something, dropping the timer back to zero. But it’s hard to say for sure.

You could try looking at STAR_noinit for an example of how to let a variable keep its value during short power blips. It might help.

Hi. I am building a driver fet + 7135. I want to flash the firmware of toykeeper blf a6. I want to achieve around 100 lumens on low mode using the 7135 but i don’t have equipment to measure the lumens. Anyone knows what value should should i put ex. 150/255?

What emitter?

xml2 u2

Ok, so according to Match, you get 100 lumens at around 200ma. He tested a T6, but lets assume that the extra gain from the U2 is cancelled out by losses in the lens and reflector.

So 200ma/380ma*255pwm = 134pwm. That should get you close.

That emitter, at 350mA, should put out about 140 or 150 OTF lumens. So, for 100 lumens you’ll want the 7135 chip running at about 69%, or about 175/255.

This is a very rough guess though.

You can get the PWM levels from bin/level_calc.py, if you have the ability to run python scripts. For example, this calculates 9 evenly-spaced levels from 0.5 lm to 1400 lm on a FET+1 driver:

(~/src/torches/trunk/bin/)-]> ./level_calc.py 9 1 8 1400 y 3 0.5 145
1: visually 0.79 (0.50 lm): 0.00/255, 3.00/255
2: visually 2.09 (9.17 lm): 0.00/255, 18.11/255
3: visually 3.39 (39.03 lm): 0.00/255, 70.19/255
4: visually 4.69 (103.24 lm): 0.00/255, 182.17/255
5: visually 5.99 (214.95 lm): 12.30/255, 255.00/255
6: visually 7.29 (387.33 lm): 43.76/255, 255.00/255
7: visually 8.59 (633.53 lm): 88.68/255, 255.00/255
8: visually 9.89 (966.70 lm): 149.48/255, 255.00/255
9: visually 11.19 (1400.00 lm): 255.00/255, 0.00/255
PWM1/FET  values: 0,0,0,0,12,44,89,149,255
PWM2/7135 values: 3,18,70,182,255,255,255,255,0

Thanks for all your suggestions. I think i’ll try in-between what pilotdog68 and ToyKeeper suggests, i’ll try 155. Thanks

Do I understand correctly, the only way to get mode reversing is with a light built around a momentary switch? So a partial press of a tail cap switch will not work to reverse? Please explain this if you can… I am trying to get reversing on a 105c.

I have compiled and flashed standard Star and it does not seem to back up…

Thanks Matt

With STAR that's correct. ToyKeeper was the first one with a firmware that could do reversing with a clicky switch. Take a look over at her repository.

To do reversing on a clicky switch, you’ll need an off-time capacitor… which the nanjg 105c drivers don’t have. You can add one, though.

With an unmodded nanjg, the best it can do is detecting “short” or “long” button presses by checking whether the attiny’s RAM has decayed or not.

For reversing, it needs to detect short/med/long presses, so you can go forward/backward/reset (or forward/backward/mem).

TK, would it involve a modified BLG-A6 firmware or is there one already written? When I use lights and night, more often than not I want a very low mode and would love to go from ML to low and back without being required to go thru high. All of my FET and FET+1 have gone to a slightly modified version of that firmware, except for 1 that is a ramping driver.

I did not get time to pour over the firmware site last night, it may be right there in my face. So, I apologize up front if it is obvious.

Matt