Oh boy, sorry we didn't make that clear. Not sure how this all originated, but think the Q8 project was started just before, or about the time the triple channels started catching on. At the time, I probably didn't have the support for 3 channels and a switch LED, but now I do, least for a 1S battery configuration.
The good thing about all this is that DEL really engineered a much improved design to support the ATtiny 25/45/85's, which TA and HQ incorporated into their driver designs, so something really useful came out of this effort, mainly for the Q8, early on. Though TF dragged their feet along the way, we always though we were just couple weeks away, and didn't think an upgrade of the driver was possible without delaying the project. Little did we even think it was possible it would be 18 months in the making...
Thanks for directing me back up the page a bit Tom. I skimmed past Lexels post and didn't even notice that my problem had already been solved. I had already set the out_channel 2 and reassigned the pins. When I flashed that hex the driver would only work on the 7135 channel and not the fet. I did what you suggested to Lexel with the main() and reflashed that hex. It's now working great. Problem solved!
It's hard to believe it was that simple after all the head scratching I did last night trying to make it work. I've reflashed this one probably 10 times all with no luck. Till now.
Thanks for all your efforts Tom and while your all swamped with things to do and feeling like it's to much to handle just remember your one of the key components of what makes this forum great!
Is this the proper place for making feature requests? If so, I’ve got one:
I spent some time poking around the codebase and found something that I didn’t know was there, something I’ve been looking for. In the setups.h file, if you comment out the STARTUP_LIGHT_OFF and STARTUP_2BLINKS variables and build it, the driver will come on max output at power up. That’s a much better operational style for two-switch lights, like the L6. Hit the tail switch and actually get light out! Love it!
Here’s what I want — when I hit that mechanical switch I want it to come on in turbo (like it already does), but if I’m holding down the e-switch I want it to come on in moonlight. (Yes I stole that idea from EagleTac). Looking at the code I thought that would be easy. I tried adding a simple if(isPressed()) check to the STARTUP_LIGHT_OFF codeblock just inside the main method, but that didn’t work for some reason. I also tried adding that check several other places, like after the watchdog timer is started. No work. The only place I actually got it to work is inside the main while loop, but right there of course it basically overrides everything and then I just have a two-mode light - not what I’m after.
I’ll spend some more time poking around, maybe I’m missing something obvious, but just in case some of you smarter people have time and want to tackle it, I’m putting it out here. Thanks all!
I do know that NarsilM can be programmed to go to Turbo, do 2 blinks, go to moon or do nothing when first powered on.
I think your trying to get it to switch between 2 of those options at power on.
Hmmm, interesting idea.
Right now my work around, for my L6 with turbo at power on, is to just cover the head like with my hand or leg then power on and hit side switch. Now I can turn back on in moon if I want.
Yes. I want it to come on in turbo like normal if all I do is close the mechanical tail clicky, but I want it to come on in moonlight if the e-switch is closed at power-up. Basically I just need the code that currently sets it to turbo at power-up (which I’ve already found, its not hard to see how that works…I think) to check the e-switch first and if that input is closed, do moonlight instead. It should be a simple if-else statement, but…that didn’t work for me. I’m missing (or misunderstanding) something.
Its not a new idea so I get no credit. EagleTac’s “tactical” dual-switch lights work like this, like my DX30LC2. Its a good feature.
This is pretty easy to do. I'll work on it in v1.1 which is still "in progress". Haven't had much time to work on it as of late. I've added it to the current OpenIssues.txt file, shown here:
Open Issues ----------- - re-work triple channel ramping tables: add more to the FET range, check/test for different # of 7135's in the bank (5/27: not sure this is necessary now with new 3 chan ramping table) - (from JasonWWW) triple channel mode sets are not completely defined, and are different than 2 chans - need to, at a minimum, document it this way - (from JasonWWW) possible problem with mode memory in 3 chan config - must check it out
Possible New Features --------------------- - besides supporting turbo/max on power up, add support if powered up with the button pressed, come up in moon (lowest) mode - joechina recommended to do a quick ramp to max, maybe even quick fade to OFF to ease tension to the eyes. The Olight A1R does this. - enhancing tailswitch support: full mode sets w/memory (Lexel) - add ability to have timed and temp step down simultaneously (Lexel) - research "bump protection" - tolerate a short loss of power - build in a method to show the current config settings - more blinky modes, like lightning, campfire, etc.
Done Issues/Features
-------------------- - FIXED: Tom E: in mode sets, step down settings wasn't working correctly - FIXED: 1 Lexel/BLF spotted: Blinkies unable to turn off in ramping - FIXED: delay processing of fast click operations to avoid max/turbo flash and allow more fast click options (over 4 doesn't work) - DONE: add in buck driver support cleanly (BLF GT) - DONE: add momentary/tactical mode
In battery check:
You write about percent discharge. I guess more people (including me) find it easier to remember if it would be remaining capacity in the table.
Also nice would be a guess how long the Q8 if it runs on 3.25V.
I also don’t know if it runs 10 min or 1 hour if it steps down.
Maybe a runtime graph could be added when a production version hit our shelves?
So, we got the normal 3 channel TA board working as a 2 channel FET+1 with 1 cell.
Now, what would need to be done to get the TA 20-30mm LDO board to work as a 1 channel FET only 2s+ cells?
I have the 30mm TA LDO built. I'm using the MIC5235-5.0YM5 LDO with R1 of 360k and R2 at 47k, C1 and C2 at 10uf, R3 100k, R4 47 ohm, R5 4.7 ohm, R6 0 ohm jumper, R7 0 ohm jumper, D1 nothing ? , SIR800 FET, and Attiny85V 10SU.
Is the D1 Schottky required with the LDO 2s?
I reassigned the pins in the RegisterSettings.h, made the change in the main() to enable PWM on pin 3, used the Setups-1Chan.h, un commented #define USING_360K, commented out the #define D1_DIODE 2. Fuses are lfuse 0xE2, hfuse 0xDE, efuse 0xff.
When I connect power to the driver, 2s connected to an MTG2, the led erratically flickers for several seconds until it finally blinks 2wice and stops for awhile. It'll ramp up and down, do turbo, bat check, strobes and then all of a sudden it's doing its own thing. It'll ramp to max on its own and I'm unable to shut it off or anything else with the e switch. Sometimes it works but most of the time it's Psycho!
I've swapped the caps, MCU and the FET. I've tried a few different things with the firmware but it's always the same
I'm sure there's something super simple I'm missing. Please help...
However, there is one caveat. For some reason, after booting in moon mode, it refuses to ramp until after turning the light off and back on. Instead of holding to ramp, it needs a “click, release, hold” to ramp the first time. No idea why, and I didn’t see an obvious fix. It still responds for other hold events though, like entering config mode or triggering the auto-lockout after 20 seconds. But I think maybe the “holdHandled” var is getting stuck in the wrong state somehow until after a regular click.
That’s probably a task for reviewers. With so many people getting a Q8 soon, there will probably be runtime graphs in some of the reviews.
Narsil doesn’t really know or care how much battery capacity there is or how the battery’s discharge curve looks, so it isn’t going to be giving any good remaining runtime estimates. When voltage gets too low, it reduces output. Then it keeps going until voltage gets too low again. If this happens when the output is already on the floor, it shuts off. It has no idea how long each step will last. It depends on a bunch of factors, including what kind of batteries are used.
People dislike the failboat 7135 chips because their activation speed is so slow. IIRC, they don’t light up most LEDs until a PWM level of about 6/255, and they’re pretty unstable at the low end so they’re bad for lights with a moon mode. The minimum output also tends to vary quite a bit with cell voltage, which is undesirable.
Other 7135 chips have much better low-end response, and are generally preferred for that reason. Some of the best ones give a nice stable moon mode at level 1/255, some require 2 or 3, and others have even higher floor levels.
NarsilM works on a wide variety of lights, so it’s fairly easy to find a test host for features which aren’t hardware-specific. I’ve used an Emisar D4 and a SRK with prototype Q8 driver, or of course the Q8 works well. Or almost anything with an e-switch and a FET/7135-based driver.
But mostly I use a decapitated D4 with the driver hanging out. Hank sent me some parts which were prototypes or which failed QA, and I use them for development purposes:
Oh, um, also an adjustable bench power supply. It’s particularly helpful for testing LVP. I ended up with a couple due to some phone-related stuff I was doing…
But if one of those isn’t available, it also works to simply hold wires onto a battery.
Thanks TK, I’ll give your code a try. On first glance I see the difference in what we did — I was putting my if-else statement inside the if(ramping) statement instead of outside and duplicating the check. Not sure what the difference is functionally since only one branch of that code is going to run anyway, but I guess there is one. I’ll pull up my edits and compare. Thank you!
