I’ve flashed this crescendo-25.hex
in a MTN 17mm FET+1 driver with Attiny25
with fuses : lfuse:w:0xD2:m -U hfuse:w:0xDE:m -U efuse:w:0xff:m (I don’t know if this matters)
But there is a problem, the driver turns on as soon as you put the cell in the flashlight, and the electronic button doesn’t work. The driver is always ramping up and down and the only way to turn it off is removing the cell
Here is a video
I’d appreciate some help, it’s my first try flashing drivers
Anthon, I think crescendo is meant for clicky switches, not for e-switch. You could probably adapt the code, but the pre-compiled hex won’t work directly.
Thank you, I was going crazy!!
Leviatan tried my newer dth_Momentary.c code and confirmed that it works.
Crescendo is for lights with clicky switches, the kind which physically disconnects power. It doesn’t pay any attention to e-switches. So, the behavior you saw is technically correct.
For an e-switch, you should try something listed in the INDEX file as “Button-Type: momentary”. If you’re looking for a ramping UI, I think the only option for that hardware is Ferrero_Rocher/ramping_UI_table. However, if you give it a tiny85 instead of tiny25, you could also run NarsilM, RampingIOS, or any of the FSM-based interfaces (Anduril, Olight, Zebralight, Meteor, …).
BTW, did you get your tiny25 to respond again? A few posts ago you were having trouble with it. It sounded like you might have used the tiny13 fuse values on a tiny25, which doesn’t work well, so I hope it’s not bricked.
That’s good news. Thanks!
I’ll try to get the code in the repo updated too.
Is this still an issue?
Normally the “short” presses are around 0.3s or less, but the timing really depends on how fast the driver’s charge drains while disconnected from power. There isn’t generally time to do a full “click”, only a quick half-press. So it only really works on a reverse clicky (forward clicky is too slow). This can be changed by adding capacitors on the power input, or otherwise adjusting the capacity and rate of discharge. For example, swapping the 19.1K/4.7K resistors for 191K/47K should greatly slow down the discharge.
It may also be helpful to mess with the unused pins (or not) to help adjust the discharge speed, but I haven’t experimented with that.
I’m not really sure what you mean by changing the length of the ramping. It should go to one end of the ramp then the other end, then keep going back and forth until it’s interrupted. That might change if I get around to changing it though, because in retrospect it seems a bit odd to let the ramp ping-pong itself instead of just stopping at the end.
Thank you ToyKeeper
No, my Tiny25 was bricked because of the Fuse values, I replaced it with another one
But now I replaced it again to a Tiny13A, tried to flash Baton.hex and Ramping_UI and both work but with bad behaviour, I can’t turn off the flashlight, when I single click from ON the brightness decreases but keeps turned on
Thanks for the directions! I have a C8 that came with biscotti, I should compare the resistor and capacitor value (it's still "new", didn't want to open it directly). I tried setting the pull ups on all the free pins to reduce the power consumption but I have no way to monitor actually so not sure what it does. I also tried taking the init_mcu routine from Flintrock's implementation with no luck. I am using the reverse clicky switch of a convoy S3.
About the length of the ramping changing, I suspect the RAM byte containing the increment decays most of the time, the "ramp_dir" variable:
for (;; ramp_level += ramp_dir)
Uncommenting that fixed it:
// Just in case (SRAM could have partially decayed)
ramp_dir = (ramp_dir == 1) ? 1 : -1;
I am not familiar with the driver that you are using, but both those firmwares are using PB3 for the switch, that would be pin2:
+-\/-+
RESET 1| | 8 Vcc
2| | 7 SCK
3| | 6 MISO
GND 4| | 5 MOSI
+----+And the pin registers ''closed" when grounded. Is your switch between pin2 and ground?
Also both of those are for 1 main white led and then small (indicator?) leds. So you might need to comment out "#define REDGREEN_INDICATORS" and re-compile (but only one channel will be in use).
If ramp_dir isn’t a 1 or –1, something else is wrong. It should detect SRAM decay and reset the value to something valid. The long_press isn’t being detected correctly, and I’d suggest starting there to get things working. Perhaps try changing long_press to a uint16_t?
I’m going to try this
Can I put the value I want in #define TURBO_TIMEOUT ? Says 5625 for 90s and 7500 for 120s but I’d like at least 240s (value of 15000?)
TBH, I’m not sure turbo even works. At least, if you’re talking about Ferrero Rocher’s ramping UI, I think the turbo code may just be a vestigial leftover from whatever came before. It’s disabled by default and has likely never been tested.
I tried and behavior still is the same. I am giving up the convoy driver for now. I had a quick look at the one in my C8 and the resistors are the same. The capacitor is not super accessible, so I’ll measure it another time. I’ll try again once I have some smaller resitors or a 1uC cap for OTC. Do we know if Simon did any adaptation to biscoti’s code before flashing?
I wanted to have something work, so I opened my BFL A6. Crescendo works as expected and I was able to play with different ramps 
It worked so well that I opened my astrolux S41 that has the same driver to try and get a lower moonlight level. blf-a6 and tk-otc are working if I flash the pre-compiled hex, but if I compile myself, I need to hold the button ~4 seconds for a long press to register. I thought this might be related to my version of avr-gcc (7.2.0), so I got a docker with avr-gcc 4.8.2 and re-compiled but I still have the longer delays. I’ll play with CAP_SHORT/CAP_MED to correct that, but I cannot understand how the pre-compiled version’s timing are OK.
I am using flash.sh from your repo to flash with 0x75 and 0xFD for fuses as documented in blf-a6.c. What version of avr-gcc are you using?
The blf-a6 driver should work pretty well with crescendo, though the blf-x6v2 driver is better (tiny25). The FET+1 design makes the ramp look quite a bit better than a single-channel driver.
As for the button timing with blf-a6, the gcc version isn’t relevant. It depends on the values for CAP_SHORT and CAP_MED. The values need to be calibrated for the specific driver, since the OTC discharge curve varies a lot on different hardware. The battcheck/README file explains the calibration process.
Here are some examples that I measured. RMM’s driver has the best behavior here, while Manker’s production driver has the worst behavior:
Nice graph! It matches the behavior of my driver. I changed the define and am now very happy with my FET+1
I can as well confirm no issues at all with crescendo. Thanks for the firmwares and thanks for the support!
Does anyone have a code that could be added to the jonnyc momentary firmware to enable a lockout. I have modified a Klarus Mi7 ti with a nanjg 105c FET+7135 (comfychair style) driver and I have no way of locking out this little 1000 lumens pocket rocket. If there’s a firmware that uses a lockout by changing to the attiny25 on the 105c, I can do that also. I also have some of the BLF X6 X5 Astrolux drivers on the way if that would make a better candidate.
It’s a must to get a lockout on this flashlight, it gets very hot in under 30 seconds. In my pocket, a accidental button press could be disastrous.
Any help is very much appreciated, thanks.
Hmm… The Ferrero_Rocher/Baton firmware has lockout, but it doesn’t have FET+1 support. Otherwise, every e-switch project I’m aware of with lockout requires a tiny85. Would that be an option?
Can I just simply solder the 85 on the 105c. I thought the pin out was different.
I can probably go with any driver that has a 17mm diameter for a single cell, but it does take a lot of work to rework it with a different driver. I’d rather not go that route if there’s another option, but if it has to be then I’ll try it.
The attiny85 is larger. I’ve not yet tried it but the legs of the attiny85 can be bent under and then solder pasted to the smaller attiny13/25 footprint. I think MikeC has done that. Try a search for info on the forum. I believe you need a hot air station to do this.