Hi, sorry, I’ve been avoiding this thread until I had a day free. I’ll just put all my replies into one, for now:
No, it’s not expected to work correctly on smaller higher-powered lights. The code is configured for the BLF X5/X6 project. If you want to use it on something higher-powered in a host with less heat capacity, you’ll need to modify the code accordingly. The thermal code is pretty bad though, so don’t be surprised if it does weird things like bouncing back and forth across the place where it should settle.
Running it at 4MHz, you’ll probably need to change significantly more details to make it work correctly. Everything will run half as fast, including thermal regulation, blinky modes, ramp-up, etc. And you’ll likely get an audible whine on most of the output levels. You can fix a lot of the timing by cutting “BOGOMIPS” in half though.
Sorry, I’ve really procrastinated about that. I know better methods are possible, but I haven’t done it because I’ve been a bit overloaded lately. Also, thermal regulation is kind of a pain in the ass to test.
It can be pretty frustrating at times.
Wait, does your ramp automatically reverse at the end? It’s much more common to stop at the end, or at least stop temporarily before turning around. I personally prefer to just stop at each end instead of ping-ponging.
Er, nevermind. Just read your next post. It was turning off, not reversing, and you fixed it.
I’m looking forward to trying this.
What about this instead?
“Hold” ramps in the same direction as it was ramping before, unless you release and hold again within 1 second, in which case the ramping direction will reverse. This way you can turn around quickly and easily to get to exactly the desired level, without having to go all the way up or all the way down first.
My Ferrero Rocher UI does that sometimes, and I consider it a bug. Holding from off should probably go to moon and stay there, requiring a release-and-hold-again to ramp up. I haven’t fixed it yet because I ran out of space, but was planning to fix it next time I mess with ramping.
I had the same happen on my first clip. I had some pins push back / recess themselves a few times before that, and was always able to pull them back out… but the sprung-out pin was harder to fix. It’s working again now, but it motivated me to buy a couple extra clips.
Those are two of the reasons why I made everything in bistro use the ramp instead of doing it with mode group levels like STAR or BLF-A6. It was kind of a pain refactoring everything, but afterward it made a lot of things easier.
Agreed, I don’t see much point using FAST on a 25/45/85. It would run at 31 kHz, which is faster than needed to avoid being audible, and fast enough to reduce PWM stability on low modes. Slower PWM is more stable and more consistent.
I’ve been using PHASE for moon mode even on tiny13, to make it less voltage-sensitive, but on the 25/45/85 it can use PHASE for everything. It’s nice.
I’m curious. Why 142 exactly?
Also, did you have to manually tweak the values at the point where the FET kicks in, and at the highest few modes? If I use the values my ramp calculator produces, I get less-smooth results at those two points. So I’ve been meaning to at least fade the 7135 out at the top instead of going directly from 255 to 0, to reduce the brightness “pop” between the two highest modes. Not sure exactly how to smooth out the channel transition in the middle though.