I don’t know how to run it tho.
EDIT: Figured it out thanks!
You’re on windows? You need to have python installed and the level_calc.py script is then run from a command line prompt.
A little windows how-to would be helpful I’m sure. Anyone up for it? I don’t even have a windows pc at the moment. 
Sure I’ll make a how to next week now that I’ve figured it out.
Can anyone help me with this. I have a FET + 7135 driver, i just removed the FET because i want to use one 7135 only. I am using the blf a6 firmware. I thought that i will get a very stable moon mode using only one 7135 but i was wrong. At 4.2v i get around 1 lumen(just my estimate) on moon mode. But at 3.7v i get a very dim moon mode. At 3.6v the moon don’t light up.
Here is my code
// PWM levels for the big circuit (FET or Nx7135)
#define MODESNx1 0,0,0,0
// PWM levels for the small circuit (1x7135)
#define MODES1x1 3,12,42,255
#define MODES_PWM1 FAST,PHASE,PHASE,PHASE
At 3.6v on high mode i can still get 350mA so i don’t know why moon mode doesn’t light up at the same voltage 3.6v.
Don’t use “FAST” PWM mode for moon. Try using PHASE instead, and it should be a lot more stable.
The reason is because the LED takes like 2 to 5 “frames” to visibly light up, depending on voltage. With FAST mode, it’s only powered for 3 out of every 256 frames, and the first 2 to 5 of those frames are dark. After voltage drops low enough to need 4 frames, it won’t light up at all.
With PHASE mode it instead lights for 6 out of every 512 “frames”. So, it still gets dimmer with voltage but even with a nearly-empty cell it should still light up at least a little bit.
I’d suggest using PHASE for moon and turbo, and FAST for every other mode.
Thanks. I’ll try that.
Hi TK,
I am using your Firmware for Ferrero Rocher driver and I was wandering what is the maximum number of ticks I can use for the turbo timer? I need to be out about 10 min.
EDIT: Also I dont see where to set the turbo low at. What is the default?
The turbo timer is a 16-bit integer, so the maximum value is 65535 (one less than 2 16). Each “tick” should be about 0.016 seconds. 10 minutes * 60 seconds / 0.016 seconds per tick = 37500 ticks per 10 minutes.
The turbo function in Ferrero_Rocher.c simply steps down one level as if the user had told it to drop one step. So, it should go to the second-highest level.
Awesome, thats just what I need. Is there any option on this firmware for a linear ramp down from turbo to high vs the drop ( like in star firmware)?
Nope. But if you want a ramping interface you could use Ramping_UI_table.c instead.
I think a ramp UI would be a bit much for this project. Are you aware of any e-switch UIs that do have the smooth drop from turbo to high?
Offhand, I can’t think of any… but I might be forgetting something.
It's certainly do-able to ramp down smoothly - haven't thought of implementing mine that way though. You could just do the math - how fast you want the transition done, and how many levels it takes. I usually setup a med mode (next mode down from turbo) to be in the 35-40% range. 255 down to 35-40%, is 255 down to 102 (40%) is 153 steps, so if you want it done in ~2 secs, it's 1 step down every 13 msecs. Well, our timer interrupts are 16 msecs, so, 1 step per interrupt is: 2.45 secs.
That ramping would be pretty easy to implement. For 35%, it would take 2.66 secs.
Easy for smarty pants like Tom E and TK maybe :) For VOB, well.....?
I use both your UI and TKs in my personal lights. For hand held I like yours for the one click off, and I use TKs Ferro in my headlamp. The light I am building now is a head lamp, but its for someone else and it gets hot fast on turbo. I set the timer, but when it kicks down to the next lower mode it just feels like a crash. I am afraid that if I give it to him like this he is going to feel let down or as if something is wrong.
Ideally I would like the drop to take more like 15 seconds. If implementing this is something you think you can explain to a noob I am all ears.
If not I'm sure I could scare up some candy in my shop for a little trade action
.
Ahhh - I'm using the Ferrero Rocher in my F6, and contemplating using it in a couple of swm C20C's I bought as well, since the driver fits in perfect and has the window built-in already. The C20C is just a little better, more compact version of the F6. Like it for not having that darn SS tail plug that is a PIA for modding the tail spring, and the tail spring is uncoated steel - ugh. The C20C was a great deal at $30 but Illumn sold them out - I was able to get 3, very moddable just like the F6's. I probably contributed to them selling out with my blabbing bout them 
.
Hhmm - hate to commit to anything at this point, but if you have some time, I'd probably get to it. Stretching it out would be pretty easy as well, and would be a nice feature. Dunno if it can fit in 1K for a 13A though - might need a Tiny25. I'd have to see...
Whenever is fine. I does not have to be quite that long, but I would need it to be in the 13A so I will take whatever fits in that. just let me know. PS: Not kidding about something in trade if you like :)
K, I'll look into it.
If the realtime battery status LEDs are turned off, there should definitely be room to add a slow turbo ramp-down.
It has been quite a while since I touched any of that code, so I don’t recall how much room is left but IIRC it wasn’t much when all the features are enabled.
I would certainly not need those. I am only using the very basic driver functions.
Yes - current size is tight - my build for the Roche F6 is 986 bytes, leaving 38 bytes spare - not enough. But if you don't want the LED support (?) confused, why are you using this firmware then? That's the main feature.
With REDGREEN_INDICATORS commented out, it reduces to 970 bytes - not much savings. Adding comment out of LOWPASS_VOLTAGE results in 916 bytes used, 108 bytes free. Maybe with this space it would be do-able.
Oops, re-compiled with flags back on and it's 1012 bytes -- ???