Hmm, 2S plus 7135 chips is still a bit risky since the chips tend to fry. Did anyone ever try those higher-voltage 7135 chips? It’d be awfully nice to have a simple current-control PWM chip for serial-cell drivers.
Otherwise, it should be possible to generate a 2S ramp by dividing the values to keep the chips under a safe limit. Not sure what that limit is though; maybe I have info on it somewhere… Looking at one of RMM’s builds, I see a limit of 37/255 for 2S. He turns the 7135 chip off for FET modes though, so it might have a bump in the ramp. This is all a bit fiddly.
Haikelite is about to release a light with a driver that is a Texas Avenger derivative and uses 12V LEDs.
Either they went as far as to make it a FET-only driver or they can show us 7135-like chips that work.
in 2S its not the voltage that is killing the AMCs its a dynamic reaction of the FET hard on/off while the AMCs gate is active that kills them, DEL added 2 caps that should fix this quite successful on currents up to 20A
7135 pin compatible chips are availiable, but they have problems with Moonlight modes you need to reduce PWM frequency for them or change the coder for longer on Cycle
Ah, interesting. I should probably look at multi-cell stuff more often…
I wonder how moon would look. I’ve taken to reducing the PWM frequency on the lowest modes lately, which should at least help somewhat with the issue described. Most modes run at 8 MHz, but when it gets low enough I cut the clock speed in half, then at the bottom of the ramp I cut it in half again. This makes moon more efficient, more stable, and less hardware-sensitive.
At super-low levels like that, I found I was seeing like 6 mA power use — 5.5 mA to run the MCU and 0.5 to run the LED. By underclocking the MCU and using idle states, I got moon down to about 1.7 mA, even though the bottom level is putting out somewhat more light. It’s probably like 1.0 mA for the MCU and 0.7 mA for the LED. I haven’t been able to try it on a higher-voltage light though, and I expect the behavior might be different.
Is it possible to get on those newer Buck and Boost drivers to use the free pads to use NTC thermistor on an unsued input
I also get frequently requests on dual e-switch input, or even triple, just something like safe current mode to this extra button by click and hold it for 3 seconds or so
Hi guys! I’m new to Narsil, just got a BLF Q8 and have a question. While in ramping, when the main light is clicked on, the indicator switch blinks sometimes once whereas sometimes it blinks twice. What does 1 blink versus 2 blinks mean? Also, right after I ramp the light up or down it will blink once or twice as well. It seems to blink only once if the output is on the low spectrum and twice for the higher spectrum.
Oh and another simple one, when the head is loosened and then tightened, the light blinks 2 times, is there any significance or is just letting me know it’s made contact?
Thanks!
Sorry for the late response… I normally just use the bin/build-85.sh script in my firmware repository. It seems to work fine on NarsilM. I think v1.2 may have had a typo on one of the #include lines though, a capitalization issue, which made it throw an error.
I initally started out using Makefiles in the repository, but almost every project uses the same build and flash commands and I got sick of trying to keep all the Makefiles in sync. So now it mostly uses shared build scripts instead.
The ramping goes at 62 fps, with 150 total steps. To change the speed you could either make it go at two/three/four frames per step, or change the number of steps in the ramp table.
It should be able to measure voltage either through a divider or direct on the VCC pin, by setting the relevant option in the code. I don’t recall what the #define for that is though.
So in the channels.h, where “SetLevel” for the specific channel configurations gets defined, I could simply change “level -= 1;” to “level -= 2;” to skip every second ramp table value?
No, that part just converts values of 1-150 to 0-149.
You probably want to look in NarsilM.c for something like “outLevel = ++rampingLevel;” or “outLevel = —rampingLevel;”, and make it move by 2 each time instead of 1. That should double the ramp speed.
Or you could just give it a shorter ramp in RampingTables.h. That’s generally the preferred way to adjust ramp speed.
