Got it, thanks.
The calculator doesnāt try to line up the ramp table to land on 100% for the 7135ās, this is something that has to be adjusted manually. It is already done in the triple channel flavors of bistro.
As mentioned, it doesnāt even try to do anything complicated with 7135 channels.
I generally find that the difference between ā350 mA steady plus 700 mA PWMā and ā1050 mA steadyā is neither visible nor easily measurable. It could potentially make things a percent or two more efficient, but those who care can adjust the ramp after itās generated. Getting it to exactly hit all the sweet spots would make things a lot more complicated and make the ramp look less smooth.
At some point in the future though, with 3-channel drivers getting more common, I may try to get it to swap which 7135 channel is pulsed at different parts of the ramp. And if it doesnāt make things look bizarre during actual use, I may even share the code. These things arenāt quite linear though, so swapping channels around based on a linear model is likely to put some small zigzags in the ramp. Itās not an issue for lights with only a few levels, but on a smooth-ramping UI it would be pretty obnoxious.
It already has an āelbowā each time it changes which power channels are active, but at least those elbows meet at the corner. Switching from 1x7135 to 3x7135 to 3+1 would give it two elbows, of which one might not quite make a clean corner. On the left is what happens now when things are slightly miscalibrated, and on the right is what the more-optimized approach might look like:
Iām thinking about Bistro on AT85. Is it enough to define F_CPU, EEPSIZE, V_REF and BOGOMIPS or is it something bigger?
I havenāt tried bistro on tiny85, but I think you could probably just copy/paste the tiny25 clause in tk-attiny.h and make a tiny85 section, then do the same with a script to compile it and flash it. Definitely check to make sure the fuses are right though, to avoid bricking a MCU.
In any case, it most likely needs only superficial changes. Probably just that one header file. And maybe either change the eeprom code to use a uint16_t or leave EEPSIZE at its smaller 8-bit value. It might glitch if it tries to use 512 bytes of eeprom with an 8-bit index.
OK, thanks.
I have flashed bistro on a tiny85 several times. I use the same HEX file as the 25, I only change the flash command to a T85 instead of the T25. It has worked fine for me.
I'm having trouble with getting battcheck-25 working on an 26mm TA, FET only, zener mod build. I first encountered this a couple weeks ago with another driver build and Texas_Ace suggested that it was because there was no 7135 on the board. I installed the 7135 and it worked like it should and I was able to get the readings I needed but after that I was unable to flash the mcu while on the board and I could never figure out what was causing the problem so I built another one.
I intend to remove the 7135 after I get the battcheck reading since this is for a 3S build.
So with this new driver I am able to flash the firmware (based off of bistro-texas-avenger-FET-only-XHP35.c) and it works fine except the otc timing is too long and the voltage calibration is off.
When I flash battcheck-25.hex I get nothing. I swapped the 7135, thinking maybe it got fried. Nothing. Swapped it again, nothing. Reflashed, nothing. I started poking around with the DMM checking voltages and touched one of the legs on the 7135 and now it looks like the LEDS are lit with 350ma constant. No blinking, just constant on. 
I'm stumped and getting frustrated with this zener mod mess... Anybody have any suggestions?
Iām assuming the reason there is no 7135 chip is because the higher voltage would fry it.
Instead of modifying hardware, you could also change the pin battcheck uses to display its measurementsā¦ change the definition of PWM_PIN and PWM_LVL, assuming you need to swap between pins 5 and 6, or there may be somewhat bigger changes needed to get it to use pin 2 or 3 instead. Those two have different PWM functions and use different init code.
About the OTC timingā¦ well, I expect being too long may be a difficult problem to solve, or may require adding a low-value resistor somewhere. The OTC works based on the voltage of a capacitor, and the capacitor might possibly get higher voltage than usual due to the serial cell configuration. Iām not sure. Or a different capacitor may be getting higher voltage, bleeding off into the one used for offtime measurement. In any case, you might need to add a resistor somewhere to help it drain faster.
But Iām only guessing about that. I usually avoid serial-cell configurations because of all the headaches they inflict. An awful lot of BLF stuff was designed with an assumption that cell voltage and LED voltage are pretty close to the same, and a zener or LDO might not be enough to completely correct for that assumption. For example, 7135 chips tend to fry at higher voltage, capacitors drain slower, LVP may not function quite the same, etc.
7135ās tend to fry when driven at 3S levels, even 2S has proven unreliable for me. When they fry the can stay shorted and that would easily cause the flashing issues.
Using another battcheck that is setup to flash the FET would be ideal but also hard to do if you are not familiar with the tiny pinout and settings. It was never worth my time to figure it out so I just skipped having LVP at all on my series lights.
What pin do you need the output on? What kind of MCU? I should probably add a .hex compiled for this sort of thing.
I have never taken the time to memorize the pinout of the mcu but for this use case having it output on the FET channel of the tripledown / TA driver with a tiny25 (which could also be used with the tiny45 and 85) would be the ticket. Most likely with some PWM to drop the output since it would be the FET, a 10-15pwn should be more then enough.
Soā¦ pin 3 maybe? Or was that on pin 2? IIRC, both 7135 channels are on the primary counter on pins 5 and 6, so the FET is probably on 2 or 3.
I just checked the schematic and looks like it is pin 3 / PB4
I don't know what to tell you guys. This driver will work with any TA bistro hex but the battcheck 25 doesn't work. The 7135 has held up to 12+ volts now for at least a good 30 minutes just trying to fry it.
When I tried them, if I manually turned the 7135 on it would work but would not work if the MCU tried to turn it on. Drove me nuts for days until I pulled them all off and tested them individually. I replaced installed a new one and it worked for a second and then did the same thing.
Although if the battcheck could be setup to use the FET then that would solve the problem.
Thanks! Itās on my todo listā¦ but Iām not sure if itāll happen until my office is reassembled. A lot of it is out of commission until a replacement PC shows up, and tracking says that should happen on Tuesday. I assume itāll take at least a day to get it set up, but itāll be nice to have a working desk again.
TK, Iām having trouble trying to compile a CRESCENDO for my TA drivers.
AtmelStudio 7 indicates 2 errors:
recipe for target āmain.oā failed - Makefile line 79
āPHASEā undeclared (first use in this function) - main.c line 365
Could you please help me solve this problem?
My advanced thanks.
Crescendo is more than one file; it uses headers from its parent directory. To build it, you should generally check out the entire repository (or at least the specific project and its parent directory).
Additionally, it only has build scripts for command line use. If you want to compile it in a different environment youāll need to re-create the build options. Check bin/build.sh to see what those are.
Thanks TK for your reply.
Iām trying to make a .hex file to flash to an TA driver.
I already pasted to the Atmelstudio project directory these files from your firmware repository:
group_calc.py
meta
soft_start.py
tk-attiny
tk-calibration
tk-delay
tk-random
tk-voltage
Is there a missing file that needs to be pasted to the project directory?
How to check bin/build.sh?