For us complete laymen a section with just hex files along with a brief description would really be great, but Beggars can’t be choosers right!!
For now, I added something like that to the INDEX file. It lists each project with a one-line description, pulled from the ‘meta’ files in each project directory. The meta files aren’t all complete though, or reviewed by the owners of the projects they describe.
hex files for me is difficult - there's so much tweaking that needs to be done now, depending on the driver board. Plus I got a zillion mode combos goin on... Wish I had a super batch build job that I could run to generate all possible combos, but might result in dozens . Basically I have to mod the source code for every build - very little direct re-use.
hex files for me is difficult – there’s so much tweaking that needs to be done now, depending on the driver board. Plus I got a zillion mode combos goin on… Wish I had a super batch build job that I could run to generate all possible combos, but might result in dozens . Basically I have to mod the source code for every build – very little direct re-use.
Well my youngest Son is going to Michigan Tech next year for computer engineering maybe I can talk him into helping out. LOL
I actually went to college for computers in 1987 and was learning a little bit of this kind of thing before I dropped out. I was pretty good at math but doing math in hex was something else! Probably don’t have to do that anymore?
Too much partying, chasing girls and that kind of stuff and that was it for me. Went back after leaving the military but not for computers. Still I’ll have to give compiling hex files a shot here in a while. For now I’m just happy to be building some of my own drivers. I should have started last year this time maybe by now I would have something to offer instead of mooching from you guys.
—
I’m a junky, I mod lights so I can sell lights so I can buy more light to mod so I can sell lights to buy more lights to mod.
I generally mod the source for each build, tweaking modes and levels and values and so on. I copy the original source file to one named after my light or named after the person I’m building it for, tweak it, build it, and keep the files around for later reference… but I don’t add them to the code repository unless there are significant functional changes.
It’s nice that STAR and guppydrv allow the end user to change the configuration, but the attiny13a is so limited that even those firmwares need to have a few different builds to support different types of lights and drivers. And the majority of the limited space goes to runtime configuration options.
But code which isn’t designed for runtime configurability… will generally need to be recompiled for each light and each person instead of using a pre-built hex file. And if it’s only modified within its intended range, like tweaking the #defines, I don’t find it worthwhile to commit that change to the repository.
Basically, take the default #defines as an example, a suggestion. But you’re usually supposed to change those and rebuild for your personal needs.
Well my youngest Son is going to Michigan Tech next year for computer engineering maybe I can talk him into helping out. LOL I actually went to college for computers in 1987 and was learning a little bit of this kind of thing before I dropped out. I was pretty good at math but doing math in hex was something else! Probably don't have to do that anymore? Too much partying, chasing girls and that kind of stuff and that was it for me. Went back after leaving the military but not for computers. Still I'll have to give compiling hex files a shot here in a while. For now I'm just happy to be building some of my own drivers. I should have started last year this time maybe by now I would have something to offer instead of mooching from you guys.
- I started out as an EE major in '75 after high school. took my first computer course of Fortran on cards (don't drop the deck!), and later dropped out, then went back to a tech school for programming, then continued CS courses at night. Never got a BS degree but took all the CS courses... in about '81, bought the IBM PC - 1st version, DOS 1.0, etc. for like $3,500, stripped down. Added my own memory chips to get it up to 64KB - the fun began...
Well my youngest Son is going to Michigan Tech next year for computer engineering maybe I can talk him into helping out. LOL I actually went to college for computers in 1987 and was learning a little bit of this kind of thing before I dropped out. I was pretty good at math but doing math in hex was something else! Probably don’t have to do that anymore? Too much partying, chasing girls and that kind of stuff and that was it for me. Went back after leaving the military but not for computers. Still I’ll have to give compiling hex files a shot here in a while. For now I’m just happy to be building some of my own drivers. I should have started last year this time maybe by now I would have something to offer instead of mooching from you guys.
- I started out as an EE major in ’75 after high school. took my first computer course of Fortran on cards (don’t drop the deck!), and later dropped out, then went back to a tech school for programming, then continued CS courses at night. Never got a BS degree but took all the CS courses… in about ’81, bought the IBM PC – 1st version, DOS 1.0, etc. for like $3,500, stripped down. Added my own memory chips to get it up to 64KB – the fun began…
That is very cool. Our high school had apple computers in the mid 80’s and I could do the “if and then” statements with the best of them and ended up being the teachers assistant my senior year.
The first time I saw a computer was at my Mother’s job. She worked for a place in Saginaw Mi. that did the payroll for the City and a bunch of other large businesses. I remember going there to see the huge rolls of tape and all of that. I’m sure that was Fortran and probably some of the very earliest commercial use of computers. Time-cards turned into paychecks, I think the place was called Fullerton if I remember correctly.
Funny for me really, considering we are family of farmers. But farming is more and more high tech now. I sold feed for a while and we used a program out of Michigan State for figuring out the optimal feed requirements for dairy cows. We tested all of the feed grown on the farm and then balanced that with the stuff we sold. My Father sold fertilizer and they did the same thing for that. My Grandfather could do the math in his head faster though. LOL
—
I’m a junky, I mod lights so I can sell lights so I can buy more light to mod so I can sell lights to buy more lights to mod.
In '78-early 80's, the job market was insane. I had multiple job offers coming out of the tech school - 6 month certificate in computer programming - oh boy... You switched jobs every 6-12 months to get a 10%-20% or greater bump each time. I got 20%+ counter offers just to stay at a couple of jobs.
All that doesn't make me an expert at Atmel/AVR programming though, so the learning never stops... It still blows me away that they can fit so many components/features into 1 tiny chip.
hex files for me is difficult – there’s so much tweaking that needs to be done now, depending on the driver board. Plus I got a zillion mode combos goin on… Wish I had a super batch build job that I could run to generate all possible combos, but might result in dozens . Basically I have to mod the source code for every build – very little direct re-use.
Here is one way to achieve customization of firmware without recompiling and only editing one hex file. The EEPROM can be loaded from a hex file. Configuration data can be put into the EEPROM hex file, edited, and programmed to the MCU. Since the EEPROM hex file is separate from the program hex file, it can be programmed by itself.
This would beneficial to those who have the equipment to program the MCU but not the software programming skills.
hex files for me is difficult – there’s so much tweaking that needs to be done now, depending on the driver board. Plus I got a zillion mode combos goin on… Wish I had a super batch build job that I could run to generate all possible combos, but might result in dozens . Basically I have to mod the source code for every build – very little direct re-use.
Here is one way to achieve customization of firmware without recompiling and only editing one hex file. The EEPROM can be loaded from a hex file. Configuration data can be put into the EEPROM hex file, edited, and programmed to the MCU. Since the EEPROM hex file is separate from the program hex file, it can be programmed by itself.
This would beneficial to those who have the equipment to program the MCU but not the software programming skills.
You don’t need software programming skills to change mode levels. All you need to do is change a few numbers. Star is basically written for easily defining modes, mode direction, memory, timeouts etc etc… It’s pretty easy to grasp.
Is there any idea of what the "OFF" current of momentary firmware can be? Any ideas whether the current is in the few microamp range? Or are we talking tens or hundreds. Do any of the mom. firmwares go to sleep mode when "OFF"? Would using the reset pin PB5 for the switch input allow for deep sleep? (It would probably remove the possibility of short/long press detection.)
I'd like to run from a single AAA cell where capacity is quite limited.
Is there any idea of what the “OFF” current of momentary firmware can be? Any ideas whether the current is in the few microamp range? … I’d like to run from a single AAA cell where capacity is quite limited.
From what I recall, I measured the “off” current on Ferrero_Rocher to be about 0.36mA with the green indicator LED on (dimmed), or about 0.33mA with the indicator off. About 1.23mA with the indicator on full. So, anywhere from ~10 to ~45 days of standby time on a 10440 cell.
But that’s without seriously optimizing for standby power; IIRC it can get significantly lower with the right code. Atmel published the specs but I don’t recall the actual numbers.
What I want to know is how you fit an e-switch into a 1xAAA light.
What I want to know is how you fit an e-switch into a 1xAAA light.
Oops LOL I didn't mean an e-switch AAA, like an EDC, that would be tricky (but possible). I was thinking of retrofitting a headlight driver as it already has the e-switch. What I'd like to design for is say 80% remaining capacity after 30days of standby. (or 90 days better yet) If you use all the capacity in standby time then its no good.
The tiny13a draws 2uA in power-down, but requires a reset or power cycle to recover (correct me if I'm wrong). That's why I wondered about using the reset pin for the e-switch input. I'd also need some way of disconnecting the ADC resistors to eliminate their current.
Noob question. Would starry-offtime work on a standard Nanjg 105c? I'm thinking I need to make the following changes:
Quote:
#define FAST 0x23 // fast PWM channel 1 only #define PHASE 0x21 // phase-correct PWM channel 1 only //#define FAST 0xA3 // fast PWM both channels //#define PHASE 0xA1 // phase-correct PWM both channels
Noob question. Would starry-offtime work on a standard Nanjg 105c?
A standard nanjg has no offtime capacitor (OTC) so starry-offtime wouldn’t work on it. However, basic STAR and STAR_noinit should work, and so should anything listed under “mem decay” or “ontime” in the INDEX file (as long as it’s also listed under attiny13a).
You should also make sure that the switch type matches — clicky or momentary. I’m guessing you have a clicky.
Sorry, I meant Nanjg 105c with an otc installed. I was just hoping to use some of the advanced features of starry-offtime but was unsure about the secondary channel bits. I'm currently running STAR offtime on the driver in question.
Ah, okay. It should work then. But if it has only one power channel, you’ll want to use only the primary PWM (MODESNx, not MODES1x, and swapping the fast/phase defines like you already did).
You might also get more mileage out of the blf-a6.c or tk-otc.c firmware, which are similar to starry-offtime but more mature. But you’ll need to adjust the ADC values for offtime and voltage (which can be measured with the firmwares in battcheck/* or copied from reference values).
It also currently requires changing a line of code in the battery check mode, but I’ve been meaning to fix that for easier use on single-channel drivers.
I appreciate it! I'll give the blf-a6 and tk-otc firmwares a shot. I presume I shouldn't try to use the battcheck mode on either firmware with a single-channel driver for the time being. (I'd change it myself if I had a clue what's going on... but I don't. )
I presume I shouldn’t try to use the battcheck mode on either firmware with a single-channel driver for the time being.
Oh, it’s a simple change. Look for the “void blink” function and change its set_output(0,20) to set_output(20,0). This moves it from the second power channel to the first; otherwise it won’t light up at all.
I know it’s written in here somewhere, in several threads I guess… Anyway, when is phase correct PWM preferred over fast PWM? If I understand correctly, phase correct can produce some noise. But as the possibility to select it exists in a lot of firmwares there has to be a situation where it is beneficial. What would that situation be?
Phase mode is helpful to get moon modes between what fast mode provides. It also is required to make the emitters shut off completely in some cases on e-switch lights, because fast PWM still emits even at level 0 on some drivers. It is also less sensitive to low batteries, so the low modes won’t sag as much. And some people just prefer it, despite the whine and slower flashes.
Thanks for the explanation, I’ll test it someday. It makes sense except for one part. If one wants to shut off the emitter completely, why not just turn off the pin?
If one wants to shut off the emitter completely, why not just turn off the pin?
It would probably work, but it’s usually easier to just set PWM=0. Fast PWM will still output a brief spike even at zero though. IIRC, someone also tested a slight difference with PWM=255, where phase was slightly brighter than fast (fast has a brief downspike even at 255, I think). So as a general default, it’s usually a good idea to use phase at moon and turbo but use fast for everything else.
Adding pin logic is untested, I think, and would use a bit more room in an already-cramped space. It’s also redundant if there is already logic to put the MCU into sleep mode while “off”.
I suppose it’s a minor issue at worst, so nobody has spent much time on it.
To turn off the pin only one additional row of code is needed, but I guess your right with it being not needed. Thanks for taking the time to explain it.
Guys, Is there 1 mode-100% ( or star choosable 1 mode) 105c firmware awailable guys? Currently i am bypassing the atttiny13 in order to achieve this , and ofc warnings and cut-offf are lost this way
Guys, Is there 1 mode-100% ( or star choosable 1 mode) 105c firmware awailable guys? Currently i am bypassing the atttiny13 in order to achieve this , and ofc warnings and cut-offf are lost this way
Hi Mitko,
I have a couple of “1 mode” firmwares you may like;
100% only, with Low Voltage Protection enabled (will flash 3 times & drop down to 30 (out of 255) output when 3.2v is reached).
100% Turbo for 2 mins, then steps down to 110 (out of 255). Retains LVP as per above.
These are for Clicky switches.
I can throw them into Pastebin, or email them to you if you like.
When using a zener modded board for use with an MT-G2 do we need to just adjust the ADC values or swap out the resistors as well to get it into a specific range?
Guys, Is there 1 mode-100% ( or star choosable 1 mode) 105c firmware awailable guys? Currently i am bypassing the atttiny13 in order to achieve this , and ofc warnings and cut-offf are lost this way
You should be able to do that in many of the available firmwares, simply by removing all modes except turbo. This is generally done at the top of the file by changing or removing #defines.
For example, in STAR, I think all you need to do is comment out the “MODE_*” lines except for “MODE_TURBO”. This should give you a light which is 100% or off, with gradual ramped step-down to about half power after the light has been on for a while (default is 2 minutes).
It appears that the code will also step down by half each time the voltage is too low, except it won’t go below the lowest level… which could be an issue when there is only one mode. You can probably fix this by hard-coding a minimum instead. This is untested, but here’s an example of the changes needed:
(there was a diff here, but it didn't format correctly and was untested)
Edit: The forum doesn’t seem to like raw code and is reformatting some of it incorrectly… instead, try going here for a 1-mode version of STAR which I tested on my bench power supply to make sure LVP works:
Thanks, that is great!
I’m a junky, I mod lights so I can sell lights so I can buy more light to mod so I can sell lights to buy more lights to mod.
hex files for me is difficult - there's so much tweaking that needs to be done now, depending on the driver board. Plus I got a zillion mode combos goin on... Wish I had a super batch build job that I could run to generate all possible combos, but might result in dozens
. Basically I have to mod the source code for every build - very little direct re-use.
Well my youngest Son is going to Michigan Tech next year for computer engineering maybe I can talk him into helping out. LOL
I actually went to college for computers in 1987 and was learning a little bit of this kind of thing before I dropped out. I was pretty good at math but doing math in hex was something else! Probably don’t have to do that anymore?
Too much partying, chasing girls and that kind of stuff and that was it for me. Went back after leaving the military but not for computers. Still I’ll have to give compiling hex files a shot here in a while. For now I’m just happy to be building some of my own drivers. I should have started last year this time maybe by now I would have something to offer instead of mooching from you guys.I’m a junky, I mod lights so I can sell lights so I can buy more light to mod so I can sell lights to buy more lights to mod.
Let's see.....
One hand....playing with the old Commodore
Other hand....partying and being crazy (at least me)
Other hand wins! ....except Bill Gate's house is 50k+ square feet
It's the simple things that we take for granted that cost us the most
Ευκαιρία λέει πιάσε με από το μέτωπο γιατί μόλις έχω περάσει δεν θα με πιάσειs
I generally mod the source for each build, tweaking modes and levels and values and so on. I copy the original source file to one named after my light or named after the person I’m building it for, tweak it, build it, and keep the files around for later reference… but I don’t add them to the code repository unless there are significant functional changes.
It’s nice that STAR and guppydrv allow the end user to change the configuration, but the attiny13a is so limited that even those firmwares need to have a few different builds to support different types of lights and drivers. And the majority of the limited space goes to runtime configuration options.
But code which isn’t designed for runtime configurability… will generally need to be recompiled for each light and each person instead of using a pre-built hex file. And if it’s only modified within its intended range, like tweaking the #defines, I don’t find it worthwhile to commit that change to the repository.
Basically, take the default #defines as an example, a suggestion. But you’re usually supposed to change those and rebuild for your personal needs.
That is very cool. Our high school had apple computers in the mid 80’s and I could do the “if and then” statements with the best of them and ended up being the teachers assistant my senior year.
The first time I saw a computer was at my Mother’s job. She worked for a place in Saginaw Mi. that did the payroll for the City and a bunch of other large businesses. I remember going there to see the huge rolls of tape and all of that. I’m sure that was Fortran and probably some of the very earliest commercial use of computers. Time-cards turned into paychecks, I think the place was called Fullerton if I remember correctly.
Funny for me really, considering we are family of farmers. But farming is more and more high tech now. I sold feed for a while and we used a program out of Michigan State for figuring out the optimal feed requirements for dairy cows. We tested all of the feed grown on the farm and then balanced that with the stuff we sold. My Father sold fertilizer and they did the same thing for that. My Grandfather could do the math in his head faster though. LOL
I’m a junky, I mod lights so I can sell lights so I can buy more light to mod so I can sell lights to buy more lights to mod.
In '78-early 80's, the job market was insane. I had multiple job offers coming out of the tech school - 6 month certificate in computer programming - oh boy... You switched jobs every 6-12 months to get a 10%-20% or greater bump each time. I got 20%+ counter offers just to stay at a couple of jobs.
All that doesn't make me an expert at Atmel/AVR programming though, so the learning never stops... It still blows me away that they can fit so many components/features into 1 tiny chip.
Here is one way to achieve customization of firmware without recompiling and only editing one hex file. The EEPROM can be loaded from a hex file. Configuration data can be put into the EEPROM hex file, edited, and programmed to the MCU. Since the EEPROM hex file is separate from the program hex file, it can be programmed by itself.
This would beneficial to those who have the equipment to program the MCU but not the software programming skills.
one year rookie
You don’t need software programming skills to change mode levels. All you need to do is change a few numbers. Star is basically written for easily defining modes, mode direction, memory, timeouts etc etc… It’s pretty easy to grasp.
https://www.flickr.com/photos/akrylamid/
Is there any idea of what the "OFF" current of momentary firmware can be? Any ideas whether the current is in the few microamp range? Or are we talking tens or hundreds. Do any of the mom. firmwares go to sleep mode when "OFF"? Would using the reset pin PB5 for the switch input allow for deep sleep? (It would probably remove the possibility of short/long press detection.)
I'd like to run from a single AAA cell where capacity is quite limited.
From what I recall, I measured the “off” current on Ferrero_Rocher to be about 0.36mA with the green indicator LED on (dimmed), or about 0.33mA with the indicator off. About 1.23mA with the indicator on full. So, anywhere from ~10 to ~45 days of standby time on a 10440 cell.
But that’s without seriously optimizing for standby power; IIRC it can get significantly lower with the right code. Atmel published the specs but I don’t recall the actual numbers.
What I want to know is how you fit an e-switch into a 1xAAA light.
This is very good!
Thanks!!
If anything can go wrong, it will.
Matter will be damaged in direct proportion to its value.
Oops LOL I didn't mean an e-switch AAA, like an EDC, that would be tricky (but possible). I was thinking of retrofitting a headlight driver as it already has the e-switch. What I'd like to design for is say 80% remaining capacity after 30days of standby. (or 90 days better yet) If you use all the capacity in standby time then its no good.
The tiny13a draws 2uA in power-down, but requires a reset or power cycle to recover (correct me if I'm wrong). That's why I wondered about using the reset pin for the e-switch input. I'd also need some way of disconnecting the ADC resistors to eliminate their current.
If I only had more time ...
Noob question. Would starry-offtime work on a standard Nanjg 105c? I'm thinking I need to make the following changes:
and/or zero out "#define MODES1x" so it reads
Am I at least in the ballpark? Thanks in advance.
A standard nanjg has no offtime capacitor (OTC) so starry-offtime wouldn’t work on it. However, basic STAR and STAR_noinit should work, and so should anything listed under “mem decay” or “ontime” in the INDEX file (as long as it’s also listed under attiny13a).
You should also make sure that the switch type matches — clicky or momentary. I’m guessing you have a clicky.
Sorry, I meant Nanjg 105c with an otc installed. I was just hoping to use some of the advanced features of starry-offtime but was unsure about the secondary channel bits. I'm currently running STAR offtime on the driver in question.
Ah, okay. It should work then. But if it has only one power channel, you’ll want to use only the primary PWM (MODESNx, not MODES1x, and swapping the fast/phase defines like you already did).
You might also get more mileage out of the blf-a6.c or tk-otc.c firmware, which are similar to starry-offtime but more mature. But you’ll need to adjust the ADC values for offtime and voltage (which can be measured with the firmwares in battcheck/* or copied from reference values).
It also currently requires changing a line of code in the battery check mode, but I’ve been meaning to fix that for easier use on single-channel drivers.
I appreciate it! I'll give the blf-a6 and tk-otc firmwares a shot. I presume I shouldn't try to use the battcheck mode on either firmware with a single-channel driver for the time being. (I'd change it myself if I had a clue what's going on... but I don't.
)
Oh, it’s a simple change. Look for the “void blink” function and change its set_output(0,20) to set_output(20,0). This moves it from the second power channel to the first; otherwise it won’t light up at all.
But I have a few other improvements to make too…
I know it’s written in here somewhere, in several threads I guess… Anyway, when is phase correct PWM preferred over fast PWM? If I understand correctly, phase correct can produce some noise. But as the possibility to select it exists in a lot of firmwares there has to be a situation where it is beneficial. What would that situation be?
https://www.flickr.com/photos/akrylamid/
Phase mode is helpful to get moon modes between what fast mode provides. It also is required to make the emitters shut off completely in some cases on e-switch lights, because fast PWM still emits even at level 0 on some drivers. It is also less sensitive to low batteries, so the low modes won’t sag as much. And some people just prefer it, despite the whine and slower flashes.
Thanks for the explanation, I’ll test it someday. It makes sense except for one part. If one wants to shut off the emitter completely, why not just turn off the pin?
https://www.flickr.com/photos/akrylamid/
It would probably work, but it’s usually easier to just set PWM=0. Fast PWM will still output a brief spike even at zero though. IIRC, someone also tested a slight difference with PWM=255, where phase was slightly brighter than fast (fast has a brief downspike even at 255, I think). So as a general default, it’s usually a good idea to use phase at moon and turbo but use fast for everything else.
Adding pin logic is untested, I think, and would use a bit more room in an already-cramped space. It’s also redundant if there is already logic to put the MCU into sleep mode while “off”.
I suppose it’s a minor issue at worst, so nobody has spent much time on it.
To turn off the pin only one additional row of code is needed, but I guess your right with it being not needed. Thanks for taking the time to explain it.
https://www.flickr.com/photos/akrylamid/
Guys, Is there 1 mode-100% ( or star choosable 1 mode) 105c firmware awailable guys? Currently i am bypassing the atttiny13 in order to achieve this , and ofc warnings and cut-offf are lost this way
Hi Mitko,
I have a couple of “1 mode” firmwares you may like;
These are for Clicky switches.
I can throw them into Pastebin, or email them to you if you like.
Isn’t 3.2v too high?
Can you send me these files too?
₪₪₪₪ ΟΥΔΕΝ ΚΡΥΠΤΟΝ ΥΠΟ ΤΟΝ ΗΛΙΟ ₪₪₪₪
My YouTube channel
Flashlights & edc gear
K40M F16
When using a zener modded board for use with an MT-G2 do we need to just adjust the ADC values or swap out the resistors as well to get it into a specific range?
Pastebin &nbs
You should be able to do that in many of the available firmwares, simply by removing all modes except turbo. This is generally done at the top of the file by changing or removing #defines.
For example, in STAR, I think all you need to do is comment out the “MODE_*” lines except for “MODE_TURBO”. This should give you a light which is 100% or off, with gradual ramped step-down to about half power after the light has been on for a while (default is 2 minutes).
It appears that the code will also step down by half each time the voltage is too low, except it won’t go below the lowest level… which could be an issue when there is only one mode. You can probably fix this by hard-coding a minimum instead. This is untested, but here’s an example of the changes needed:
Edit: The forum doesn’t seem to like raw code and is reformatting some of it incorrectly… instead, try going here for a 1-mode version of STAR which I tested on my bench power supply to make sure LVP works:
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/h...
Pages