I'm always keeping a spare USB AVR complete w/cable and clip around now. The clips specially can start having problems with use. The first black cheaper one I used had pin problems - pins just loosened up and would back out on attempting to clip to the MCU. Became a real PIA fiddling with them all the time. Then a blue Pomona failed on me - one of the pins sprung out of the plastic tabs holding it in, and just couldn't get it to stay. This problem was probably my own fault though, abusing it to fit on MCU's in tight spaces.
I basically got the ramping mode operational in Narsil, accept for the To Do list below. There were a lot of little bugs along the way, but looks like it's operating pretty clean now, so far that is... Ramping can be chosen via the configuration settings, so you can still choose one of 12 mode sets, or ramping.
Code size is now 5496 bytes, 67.1% filled, so still lots of free space.
So the basic ops is fairly simple:
From OFF:
click to last level it was on
hold ramps up from moon to max level in 3 seconds, smoothly (currently 64 levels)
double-click to max level
From ON:
click turns it OFF (this level is restored on the click from OFF)
hold ramps up, accept if it is on the max level. If on max, hold ramps down all the way to moon in 3 seconds, and stops there
All the Narsil special/advanced features are now working in ramping mode:
lock-out works: From OFF, 2 quick clicks followed by hold (same as non-ramping)
battery voltage check: From OFF, 1 quick click followed by hold (same as non-ramping)
both modes of the configuration UI working - to access the main configuration setting, hold the button for 5.5 seconds, 2.5 secs longer than a ramping sequence
in ramping, locator LED is toggled by a triple click from OFF
Couple things still To Do:
turbo timeout (currently only works in normal mode sets, not ramping)
Low Voltage Protection - needs to be modified to lower levels (currently only steps down modes in a mode set)
This looks sweet Tom!
I have ordered the hardware to flash the AT85
And I already know which srk will be using the prototype Q8 driver
NICE!!!
So intuitive!
Sorry, I can't answer that in any certainty, but total guess is yes, because I don't think anything in the MCU is boosting or regulating voltage, but really dunno. Do you think it makes a difference to the FET or 7135's, because it just acts as a ON/OFF switch, not used directly as power out of the FET or 7135's?
I’m considering the limitation of the PWM signal being strong enough only to control ~32 7135 chips. I am thinking that if the PWM signal went to a fet whos output was connected to the PWM pins of the 7135’s, an unlimited number might be able to be switched.
Hhmm, don't think the waveform of the signals are the same - the gate input, and the FET output, but I could be wrong. I have a modded MtnE 7135 SRK driver with the full up 32 7135's, and 18 more piggybacked, total of 50. I got it in a Fing 5X, getting like 18A out of it, which is close or at the max. It works great, up to 8 PWM modes using PHASE PWM (I don't use FAST mode anymore), running on a 85. Not sure, but might not have tested it for LVP operation...
Nice. Yea, I was thinking a FET might be fast enough not to mess with the waveform too much but idk. Another option might be to use two MCU pins PWM’ing in parallel to a bank of 7135’s.
Got the final open issues for ramping done and pretty much tested now. I have the new Narsil installed in 3 lights:
Supfire M6 (Indicator LED, FET+1, 3 U3's, does about 5,000 lumens)
SupFire M2-Z (FET+1, C8 size side switch, modded with an XPL)
ZY-T11 clone (indicator LED, FET+1, XM-L2 T6 4C)
The timing for one full ramp was taking about 3.6 secs, so I reduced it now to ~2.8-3.0 secs, and looks much smoother now with no noticeable flicker. I increased the # of steps to 142 (was 64 steps).
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.
It sure is a PIA - haven't gotten to it myself yet, but looks like I'm gonna have to.
Yes, stops at max, but when at max, a hold will reverse ramp (hi->lo) and stop at moon.
Yes, I saw your post or two recommending this - I copy/pasted in my notes. I really want to implement it that way, but I'm being accused of having too complex UI's as it is, so not sure if it complicates things or not... Still undecided, but I like it
OK, this one is on me. I totally mis-understood what you wrote up here: https://budgetlightforum.com/t/-/72707/19, and also blueb8llz wrote up here: https://budgetlightforum.com/t/-/72707/10. Both of you were describing it the same way, and mis-understood it both times. I'll have to consider this, maybe work it in sooner rather than later. It kind of changes things though, and will be more likely to get crossed up with my current quick click-hold to display battery status, so may have to change that.
Same here. I always keep a full spare handy now.
142 is just how it turned out. I used the 64 levels, but bumped only 1/3 WDT's to get about 3 secs. Problem was a noticeable flicker, and also thought the 3 secs (actual ~3.5 secs) was too long, so I took the frist 29 levels on the 7135, multipled by 2.5, and the remaining levels by 2, so:
29*2.5 + 35*2 = 72.5 (72 used)
I filled in all the in-betweens with mid-points, etc. to get it somewhat balanced, and looks real smooth now. I did notice the lack of an overlap between the 7135 and FET levels, which I thought odd since you overlapped the A6 levels. Hard to say there's a noticeable jump, or anything.
142 should take ~2.3 secs, but I'm finding it seems to really take 2.8-3.1 secs, and I dunno why. The WDT should be 16 msecs, but seems to actually take longer in this case, but I'm not really understanding that. There's something goin on I can't track down maybe, or the 16 msecs is not as accurate as I thought.
As with everything else I mentioned, it’s just my personal preference. I like being able to reverse without going all the way to the end first.
It’s really a matter of what you want it to do… I don’t see why it would interfere with “click, hold”, but I haven’t looked much at the code either. It basically just needs to set the ramping direction to “down” when it came from an “off” state, so it wont ramp up.
Oh, okay. I didn’t think about the timing.
You filled it all in by hand? There’s a tool to generate those numbers.
I just updated the ramp calculator today, so it’ll handle any number of channels:
It probably needs the last few 7135 modes ramped down to 0 though, instead of dropping directly from 255 to 0. I haven’t put a smooth down-ramp into the calculator yet.
If I leave the 7135 channel on, it reduces the turbo output a bit. So I turn it off during turbo, but then it makes the ramp jump visibly between the final two modes. So it seems like the ideal solution is to ramp it down smoothly at the high end.
Just fyi, I'm really doing the ramping for the Q8 SRK project, as was requested, but no specs to go by, so I want it simple, but not lacking. A difficult compromise to obtain as you know, with one switch, one LED for biofeedback.
The click-hold UI interference is meant as a usability issue - unintentional actions, I'm trying to avoid. If a click goes to moon, then most likely the user would want to quickly proceed with a hold to ramp up, thus possibly stumbling on a click-hold for battery status.
Yes, filled in the values manually. The bump in brightness at the max was actually useful - visual que you made it there. I did realize what was causing it. Actually, was think'n to make it more pronounced .
Ok - finally got a python setup on my Win PC!!! I used https://www.python.org/downloads/windows/, and downloaded the level_calc linked above, and can run it fine. This should help big time, because might be tweaking the 142 levels down a little more. Thanks TK!!!
I used