Yup, that sounds like the issue I’ve been trying to figure out. About all I know about it is to add a second or bigger cap though, or maybe add a little one between VCC and GND, or something along those lines. I’m really not an electrical engineer.
TK - so are you gonna go with the extra cap? Are you still researching it? Is this happening on the X6/X5 driver version?
I'm wondering if there's any other effects - reduced amps or any other flakiness. Have you noticed any side effects?
Update:
The other really annoying issue has been the bright flash/blink, switching from Hi to moon/low. I added back the 12K resistor across the FET gate and it seems to eliminate it. I made some code changes to zero out the PWM outputs upon init, but that alone didn't help. I left those zero settings in the code though, because the state it's in now is perfect.
I tried a lot of firmware tricks to try to eliminate the turbo->moon flash, but nothing seemed to make any difference. It seems to be entirely a hardware issue.
About the extra cap, I’ve been away for a few weeks and can’t do much testing. However, I should have a fix to test when I get back home.
Adding a 12K resistor across the FET gait (to gnd) seems to have fixed it perfectly. I tested it on the bench and the flash went away totally, completely. Then, made the same resistor mod to a wight FET+1 driver, ATtiny25V, extra 10 uF cap stacked, running my own ported version of what started as STAROffTime (OTC). Installed the driver in a new style Convoy L2 w/UCLp, de-dedomed XM-L2 U2 (oopsy!) U4 1C on a Noctigon and got:
EFEST 26650 4200 @4.21v - 5.24A tail
1636 lumens @start, 1608 lumens @30 secs, and 282 kcd measured at 5m (1062 meters)
So I'd say the resistor and cap certainly don't seem effect performance, so far so good.
Cool!! Thank you for the trobleshooting.
I’m sure this information has been laid out somewhere for the simple-minded, but I don’t understand all of the “include…… .h” all over the code. This must be the reason I’ve stuck with blf-a6 code from May.
Grab a copy of all the .h files, tk-attiny.h, tk-calibration.h, tk-delay.h, tk-random.h, tk-voltage.h and place them in the same folder as bistro.c or blf-a6.c. You use to need to have the files in a particular folder but TK changed that, I believe the files in her main repository now include that change. You actually don’t need tk-random.h unless you enable random strobe in bistro but no harm in just grabbing a copy of everything.
So i need to do something with those files every time I want to change one of those settings?
Only if the setting you want to change resides in one of the .h files. For example LVP values and OTC values are in tk-calibration.h.
Thanks for explaining. What was the reason for moving it to this format?
I’m going to avoid the change for as long as I can, I would have to completely change how I store/archive/flash my firmwares.
It makes some things easier. Sharing code among different firmwares, doing updates. Also once you get use to it, some things are easier when using it. Once you set the LVP and OTC values for a particular board, you make a folder for that board and drop the tk-calibration.h (and the other .h files) in there. Build bistro.c or blf-a6.c from within that folder and it will use the correct values for that board.
So if you have 4 board layouts that could use slightly different LVP or OTC values, you don’t have to tweak 4 different copies of bistro.c or blf-a6.c.
It was really easy testing new builds from TK’s testing repository. Grab a new bistro.c, drop it into the folder with my tk-calibration.h set up for my board and build.
I guess I can see how that can be helpful, it just doesn’t mesh with how I do things. One day I’m sure I’ll assimilate, but
Today I managed to get bistro running on PD68’s very nice DoubleDown Board. 3x XP-L HI, FET (PSMN3R0-30YLD) + 2x AMC7135. Had some issues with flashing but once flashed it ran like a charm, no issues whatsoever. Wonderful Firmware TK! Here’s a little little minor correction, if you don’t mind:
should be
I went with _delay_ms(RAMP_SIZE * 3/8), because I like it that slow and TURBO, BATTCHECK, RAMP as hidden modes. RAMP is sweet. I’m still playing around with it and have been for while… Made it ramp nice and dim just on the 2x AMC’s for example, looks very cool.
Thanks so much for creating and sharing another milestone.
Hello friends.
This is a firmware that pyro1son kindly put together (from blf-a6) that uses pin3 to toggle a FET output for my TripleDown driver. It works great except for one thing: turbo/timer step-down isn’t active. Can anyone tell me what I need to do to get that working? I can’t figure it out. (I don’t want to keep pestering pyro because he has already spent a lot of his time on this for me.)
Hey I don’t mind but it’s now beyond my knowledge fixing this issue.
I’ll take stab at it…
In lines 542 and 601 we are checking if output == TURBO to decide if anything needs to be done about the turbo mode.
Problem is that output == 255 when in turbo mode, and TURBO is defined as being 245 - This condition will never go true.
So try changing the definition of TURBO to be 255 (up in line 114)? Lines 541-545 seems to be the only place where pin 3 is switched on. Not sure how it could have worked before?
I do not see pin 3 switched off anywhere, you may need to patch this in around line 602 for turbo step-down to actually do anything with the FET. Something like:
PORTB &= ~(1 << FET_PIN);
Somewhat related, line 544 may be messing with the OTC. Better form would be:
DDRB |= (1 << FET_PIN);
Thanks for the help! Let’s see how well I follow what you said…
-
The reason a number different than 255 was used for ‘Turbo’ is so that we would still have 255 as a valid option on the main PWM channel without triggering the FET. Can the end goal still be accomplished with 245 as the shortcut?
-
As far as Pin3 not being switched off anywhere, I know it switches off in normal mode cycling, but are you saying the language (on line 602) of stepping down to the second-highest mode wouldn’t automatically turn off pin3?
-
So you’re saying that the entirety of line 544 should be just “DDRB |= (1 << FET_PIN);”
instead of
“DDRB = (1 << PWM_PIN) | (1 << ALT_PWM_PIN) | (1 << FET_PIN);” ?
I don’t follow that at all, but I’ll make that change if you think it will help overall.
There is always a way :).
I assumed the FET has to turn on when you are in mode 4/4 or 7/7. When does it turn on? I do not see it happening in the code…
Yes, it will switch off in normal mode cycling (or, more correctly, not turn back on as the mode is being set up after each boot). But you will need to add some logic to have it turn it off after the turbo time-out - if required.
Yes. The shorter code sets the PWM_PIN pin for output, without messing with the other bits in the DDRB register. It is just shorthand for DDRB = DDRB | (1 << FET_PIN). The current code does keep the two PWM outputs alive while activating the FET output, but does not take into account that the OTC pin is also set for output somewhere else in the code. That may, or may not, give weird long press/short press detection.
When does it happen in the code? I have no idea… pyro did that 
that code that I linked is what pyro sent me. I changed the mode levels for testing. What i’m using is this:
On the driver I have it set up with one 7135 on the small circuit, 3 on the bigger circuit, plus the FET. With my little power supply I can see what kind of power the driver is pulling to tell what’s happening. As I cycle modes I see it go ~0.38A -> ~1.1A -> 2.0A (psu limited, it’s the FET)
Ok that makes sense to me. Now, what do I need to add for that to work and where do I need to add it?
I don’t really understand most of that, but one thing stuck out to me. Where/why is the OTC pin set for output anywhere?