Thanks. Right after posting earlier I grabbed updates on the main branch and found that the dual_pwm bits had been merged in.
Also, I got bzr-git working, which lets me use bzr to access git repos. This is much much easier for me, and should greatly simplify merging in changes.
Edit: ā¦ and itās all up to date now. (plus, future updates should be much easier) I should note that the dual_pwm/ dir is gone though, since it got merged back into the main STAR code.
Er, the lowest mode is really hard to predict, and highly dependent on hardware (driver, emitters, battery, etc).
For example, Iām getting 0.1 lm from a triple-219B driven by a FET, using fast PWM=0. But that 0.1lm drops down to like 0.00001 lm when the cell gets down to like 3.7V.
On the same hardware, if I use phase PWM=1 instead, the minimum level is about 3.6 lm (drops to about 0.9 lm at 3.6V).
On nanjg/qlite drivers, the lowest mode seems to depend mostly on the exact bin of 7135 chips used.
Basically, youāll just have to try it and find out.
So, I put together a test light today with an off-time cap on the driver, and I adapted the cap-reading code from STAR off-time to fit in with my ās7ā EDC code. I also added another cap threshold for medium presses, so it can detect short/med/long presses.
I havenāt really tweaked it yet, but it seems a short press is about 0 to 0.7s or so, a medium press is about 0.8 to 2.0 seconds, and a long press is anything over 2 seconds. These are mapped to ānext modeā, āprevious modeā, and āreset to mode 0ā, respectively. I think the timings need to be shorter, but I can calibrate it later.
If the user does a prev-mode action at mode 0, itāll go into semi-hidden ānegativeā modes, so it gives quick access to turbo, my favorite strobe, and battery check. Also, a next-mode action from any negative mode will always return to mode 0; no need to cycle back up through them again. Doing next-mode at the end of the main sequence will loop back to 0, instead of going through the negative modes.
Iām considering making back-from-zero change the mode group instead of doing just limited ānegativeā modes, but Iām not sure if Iāll bother.
Anyway, this went together pretty quickly and it seems to work well. Now I have firmware ready to go for my Cypreus, as soon as the emitters arrive (tomorrow or the next day).
Not sure what bits REFS0 and ADLAR are setting in ADMUX. They start 0 Iām pretty sure though. Hereās a link on the basics- donāt see the bits for those two giving it a quick glanceā¦ I guess could just lave REFS0 out and it should be 0
Thanks fellfromtree. I went ahead and tried it before I saw your post and sure enough, leaving out REFS0 keeps it set to zero. (so vref is based on Vcc)
FYI for in the future, if you download the ATtiny13A datasheet you can just search for ADMUX and it will list the register, what the bits mean, and what their default values are.
I don't think it is directly measuring voltage, but instead using the VCC as the reference voltage instead of the internal 1.1v. You could use it as the reference voltage with zener mod drivers or with an external voltage regulator (both with 2S+) since the voltage input will remain constant, but with 1S cells it would be pretty much useless. You would still need a voltage divider because the voltage you would be measuring against would still be higher than the reference. You can use it, however, for other measurements (like a temperature sensor) without needing an additional divider.
Ah gotchaā¦ So your comparing it between the divider and vcc. Learn something new everyday thanks.
*Edit Wait wouldnāt it be the other way around. Cause the zener going to keep the voltage the same? The voltage will drain as the battery drains in 1s. Am I missing somethingā¦ Oh nm I see what your saying 1.1v internal is always going to be 1.1. Still need the divider to get the voltage from B+ā¦ Itās too early for this sh
Oh yeah sent my inlaw over your site yesterday. He saw my private video of the yezl blowing things up on dd and caught the lumen disease. Heās a pic guy though, so heās talking about 3 phase pwm and all that other stuff. Canāt wait to see his lights really
Digging up an older concept here and hoping for some help.
I was hoping the above change in code would allow me to skip having the turbo timeout step down as an independent mode. My sense is I am one step away.
Hereās what Iām after: Low (1 value), Medium (2 value), Turbo (3 value) to step down (4th value).
As the FW is written, in order for me to have this I actually have 4 click through modes of Low, Medium, Step Down, and Turbo. Iām looking to have the turbo step down mode ONLY accessed following turbo time out. So in the end Iāll have 3 click through modes, but in operation 4 output modes.
I tried the above recommendation and then attempted to comment out ā#define mode_high_w_turboā but I was left with an error in line 259 āmode_high_w_turboā undeclared (first use in this function)ā. I assume the code is trying to reference the line I commented out but I donāt see it, and definitely donāt understand it.
With no working knowledge of C (other than reading through this whole thread), I was hoping I could get some help.
Not sure which version of firmware you are looking at. Have you identified where in the code you are when the turbo times out? If so you should be able to set desired PWM_LVL and not store the mode.
Should be something like (simplified): āif ticks = turbotimeout and mode = turbo then {ā
There you should be able to do a āPWM_LVL = XXXā (desired value).
Mike C is right, the concept works fine. You donāt need to comment out #define mode_high_w_turboā, maybe thatās your mistake? Comment out other modes until you have only 3 user accessible modes (low, high-w-turbo, and turbo). Set those to your desired levels. This will give you 3 modes, then do the modification to āPWM_LVL =ā discussed above:
// #define MODE_MOON 8 // Can comment out to remove mode, but should be set through soldering stars
#define MODE_LOW 14 // Can comment out to remove mode
//#define MODE_MED 39 // Can comment out to remove mode
#define MODE_HIGH_W_TURBO 39 // MODE_HIGH value when turbo is enabled
#define MODE_HIGH 120 // Can comment out to remove mode
#define MODE_TURBO 255 // Can comment out to remove mode
RMM is correct. I was working on measuring the entire throw of a potentiometer. Pots are setup as voltage dividers, so I need a V+ to hook up to one leg of the pot, Vcc is an easy source for that. The middle leg goes to an ADC, then the third leg goes to GND. To use this Iāve got to measure against Vcc. Really Iām going to have to toggle Vref back and forth so that I can cheaply measure both Vbat (against 1.1v using a divider) and also the pot (against Vcc).
Youāre both correct. The error was in my thinking. It had not occurred to me to let the āhigh_w_turboā supplant my āmedā mode while reprogramming the turbo to default to a PWM level OTHER than the āhigh_w_turboā setting. All is well and thanks for the help.
Crap - haven't checked this thread for a long time... Sorry. Someone get me up-to-date. Anyone (oops VOB) still need the hex file?
I've been having lots of troubles as of late - can't seem to program any of the custom BLF boards. I would even think programming a ATtiny13A detached should work, but can't get that to work either. Anyone know if that should be possible? I got 6 of the 8 pins wired - all have good continuity all the way back to the USB dongle. The cable setup I have works perfect with stock Nanjg boards.
Boy... Wonder if I got a bad batch of Tiny13A's, or the wrong flavor?
Every BLF custom board Iāve tried has been flashableā¦ Ferrero Rocher F6DD, RMM BLF17DD, RMM BLF22DD, and RMM 32x7135 SRK. Some with off-time cap. Plus several flavors of nanjg/qlite.
If the soldering isnāt perfect, sometimes itās finicky about connecting and I have to try a few times or forcefully hold the clip on, but usually it just works. However, when connecting the clip I usually wear a headlamp and sometimes stereo loupes so I can really see if the connection is good.
I have 6 pins connected, using a SOIC8 clip from Digikey and a cheap usbasp from fasttech. Some of the SOIC8 pins are getting worn though, so I might need another chip clip sometime.
With only 5 pins connected (oops, didnāt know at first I needed VCC), flashing was really flaky and verification never worked.