Location: (469219) 2016 HO3 // I get way more privmsgs than I can respond to, so please ask in a public thread if possible, for a faster answer.
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
Location: (469219) 2016 HO3 // I get way more privmsgs than I can respond to, so please ask in a public thread if possible, for a faster answer.
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.
Location: (469219) 2016 HO3 // I get way more privmsgs than I can respond to, so please ask in a public thread if possible, for a faster answer.
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!
Location: (469219) 2016 HO3 // I get way more privmsgs than I can respond to, so please ask in a public thread if possible, for a faster answer.
g_damian wrote:
Does someone have instructions how to compile narsilm 1.2 under linux? the Makefile seems to be prepared for windows only…
Edit: figured it out. Will create repository for linux later.
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.
Location: (469219) 2016 HO3 // I get way more privmsgs than I can respond to, so please ask in a public thread if possible, for a faster answer.
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?
Location: (469219) 2016 HO3 // I get way more privmsgs than I can respond to, so please ask in a public thread if possible, for a faster answer.
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.
in the end I had to set in the firmware an offset of +30
it seems the firmware does not like negative temperature values,
at least to blink out the value, if its also affecting the internal reading this gets a problem
this would mean on very cold lights that go into thermal stepdown while they are like -10°C
I had a similar issue myself that took while to figure out. Indoors I couldn’t get the bug, but outside it stepped down (it was below 0°C outside, and not very warm inside the hut). At first I didn’t know why it stepped down so I programmed a separate step-down blink for voltage and temperature, and also if level is critical or not. It turned out that my issue was that when the readout goes below 0, the unsigned integer roles around to 255, causing the software to think the light is burning up at 255°C. Maybe similar issue you are having?
So I just removed role around to 255 on my 85 based drivers. I was low on space so I didn’t implement negative readouts. Now that I have double the space I’m considering implementing negative readouts, because sometimes I use my bike light to see approximately how cold it is when cycling in the winter. As it is now I can see when it’s below 0°C, but not how much below.
Location: (469219) 2016 HO3 // I get way more privmsgs than I can respond to, so please ask in a public thread if possible, for a faster answer.
If I recall correctly, I did fix this in RampingIOS… but I completely removed and replaced all the thermal code there. The patch wouldn’t really apply to NarsilM, since the two projects have both diverged significantly from their shared ancestor. The RampingIOS patch could still be a general guide for implementing something similar in NarsilM though.
I can’t really apply the code from FSM / Anduril either since it has no common ancestor at all, and virtually no code which overlaps with Narsil.
Location: (469219) 2016 HO3 // I get way more privmsgs than I can respond to, so please ask in a public thread if possible, for a faster answer.
At a quick glance, NarsilM seems to be using a uint8_t for its temperature value, so it can’t represent anything colder than freezing. It also appears to use a uint16_t for the initial raw value, from which it subtracts 275, which could set the value to 65,5XX during cold weather.
To fix only the negative temperature issues, it might work to simply use signed 16-bit values for all of this, and maybe add some checks to make sure it’s above 0. But I’m just guessing.
Hi Tom,
some suggestions for the next version of NarsilM.
I would suggest to double the time to enter settings. From 8 seconds to 16 seconds or 20.
(Edit: The 20s would interfere with the jammed button protection)
And change the clicks for RAMPING and MODES in the settings.
I think he has a point making NarsilM more robust against wrong operation.
If I handle someone the light I tell “don’t press for longer than 8 seconds”.
I think extending the time can help. The only backside would be if some switches often between MODES and RAMPING. But I guess most stay in one UI.
I guess you used 8sec to be able to switch quickly between RAMPING and MODES.
The sequence to change is:
Hold the button till it blinks the first settings, then one or two clicks and then hold the button till the lamp confirm with four blinks.
In retrospect I think it would also better to change the first setting to
1 click = RAMPING
2 clicks = MODES
Today it’s reversed.
Only for the reason RAMPING is mostly used and people try to switch off the lamp if it starts blinking.
changing the 8 to 20 seconds is just one line in the Narsil.c file
CONFIG hold – if it is not locked out or lock-out was just exited on this hold
//———————————————————————————————————————————-
if ((byLockOutSet 0) && !momentaryState)
{
if ((!ramping && (wPressDuration CONFIG_ENTER_DUR) && (fastClicks != 2) && (modeIdx != BATT_CHECK_MODE))
||
(ramping && (wPressDuration == 500))) // 8 secs in ramping mode
same for Modes to extend 2.5 to more in the setup file
#define CONFIG_ENTER_DUR 160 // Config mode entry hold time – 160=2.5s, 128=2s
I changed the register and PB port in the register settings but it does not work
It seems I have to change something in the channels.h file as well, but that code does not really make sense to me so I cant change it
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
[Reviews] Miboxer C4-12, C2-4k+6k, C2, C4 / Astrolux K1, MF01, MF02, S42, K01, TI3A / BLF Q8 / Kalrus G35, XT11GT / Nitefox UT20 / Niwalker BK-FA30S / Sofirn SF36, SP35 / Imalent DM21TW / Wuben I333 / Ravemen PR1200 / CL06 lantern / Xanes headlamp
[Mods] Skilhunt H03 short / Klarus XT11GT, XT12GTS / Zebralight SC50+ / Imalent DM21TW / colorful anodisation
[Sale]
Drivers: overview of sizes and types
DD+AMC based drivers Anduril or Bistro OTSM 12-24mm, S42, 24-30mm L6, Q8, MF01(S), MT03, TN42
Anduril or Bistro 8A buck driver for 20-30mm, MF01/02/04, TN40/42, Lumintop GT, MT09R
UVC and UVC+UVA drivers
programming key
Remote switch tail DD board with FET
Aux boards:
Emisar D1, D1S, D4, D4S, D18, Lumintop FW3A, Fireflies ROT66, Astrolux MF01, Tail boards like S2+
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.
On my yesterday built L6 is pretty low! Almost can’t see it.
Reviews: Olight Seeker2 pro, Lumintop GlowI, Sofirn SP36, Convoy 4X18A, Convoy M21C, Brinyte SR8 Rescue Angel, Astrolux MF01 mini, Astrolux FT03S, YLP Sherp S15, Sofirn SP40, YLP Panda 3R and Unicorn, Armytek Prime C1 Pro, Acebeam M50, Imalent MS18, Convoy M3, Nitecore TIP2, Imalent RT70, Wuben T70, Sofirn SP32A, Thorfire VG15S, Thorfire VG10S, Thorfire TG06S
Mods: Imalent MS18 dedoming, Astrolux MF01-20K, Small sun T08 MT-G2, Eagle eye X6 triple XPL, Ultrafire F13 MT-G2, Convoy C8 XHP70, Solarstorm T3 triple XP-L HI
Big flashlight measurement and beamshot collection
3D printing stuff for flashlights
My flashlight related Instagram
My Flashlight related Youtube channel called Zozzlights
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
[Reviews] Miboxer C4-12, C2-4k+6k, C2, C4 / Astrolux K1, MF01, MF02, S42, K01, TI3A / BLF Q8 / Kalrus G35, XT11GT / Nitefox UT20 / Niwalker BK-FA30S / Sofirn SF36, SP35 / Imalent DM21TW / Wuben I333 / Ravemen PR1200 / CL06 lantern / Xanes headlamp
[Mods] Skilhunt H03 short / Klarus XT11GT, XT12GTS / Zebralight SC50+ / Imalent DM21TW / colorful anodisation
[Sale]
Drivers: overview of sizes and types
DD+AMC based drivers Anduril or Bistro OTSM 12-24mm, S42, 24-30mm L6, Q8, MF01(S), MT03, TN42
Anduril or Bistro 8A buck driver for 20-30mm, MF01/02/04, TN40/42, Lumintop GT, MT09R
UVC and UVC+UVA drivers
programming key
Remote switch tail DD board with FET
Aux boards:
Emisar D1, D1S, D4, D4S, D18, Lumintop FW3A, Fireflies ROT66, Astrolux MF01, Tail boards like S2+
civilgear.wordpress.com
1 blink: moon to ~160 lumens (maximum level for the 7135 current regulation chip).
2 blinks: Above ~160 lumens (direct-drive FET is engaged).
2 blinks when turning on: Just lets the user know power is connected.
civilgear.wordpress.com
I tried to use the ramp to 80% for normal 3 Channel output
but it is notworking
turbo is very low almost like moonlight
P.S.
I added turbo after the last used mode and it works
so ramp size is 140 and 141 value is turbo
[Reviews] Miboxer C4-12, C2-4k+6k, C2, C4 / Astrolux K1, MF01, MF02, S42, K01, TI3A / BLF Q8 / Kalrus G35, XT11GT / Nitefox UT20 / Niwalker BK-FA30S / Sofirn SF36, SP35 / Imalent DM21TW / Wuben I333 / Ravemen PR1200 / CL06 lantern / Xanes headlamp
[Mods] Skilhunt H03 short / Klarus XT11GT, XT12GTS / Zebralight SC50+ / Imalent DM21TW / colorful anodisation
[Sale]
Drivers: overview of sizes and types
DD+AMC based drivers Anduril or Bistro OTSM 12-24mm, S42, 24-30mm L6, Q8, MF01(S), MT03, TN42
Anduril or Bistro 8A buck driver for 20-30mm, MF01/02/04, TN40/42, Lumintop GT, MT09R
UVC and UVC+UVA drivers
programming key
Remote switch tail DD board with FET
Aux boards:
Emisar D1, D1S, D4, D4S, D18, Lumintop FW3A, Fireflies ROT66, Astrolux MF01, Tail boards like S2+
Does someone have instructions how to compile narsilm 1.2 under linux? the Makefile seems to be prepared for windows only…
Edit: figured it out. Will create repository for linux later.
Done: https://bitbucket.org/dmn/narsil
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.
I discovered today an odd behavior on the GT v1.2
The driver starts to step down at about 3.45V cell voltage, not sure why, in the tkcalwright is written 3.1V
thermal and cell voltage readout shows no error
[Reviews] Miboxer C4-12, C2-4k+6k, C2, C4 / Astrolux K1, MF01, MF02, S42, K01, TI3A / BLF Q8 / Kalrus G35, XT11GT / Nitefox UT20 / Niwalker BK-FA30S / Sofirn SF36, SP35 / Imalent DM21TW / Wuben I333 / Ravemen PR1200 / CL06 lantern / Xanes headlamp
[Mods] Skilhunt H03 short / Klarus XT11GT, XT12GTS / Zebralight SC50+ / Imalent DM21TW / colorful anodisation
[Sale]
Drivers: overview of sizes and types
DD+AMC based drivers Anduril or Bistro OTSM 12-24mm, S42, 24-30mm L6, Q8, MF01(S), MT03, TN42
Anduril or Bistro 8A buck driver for 20-30mm, MF01/02/04, TN40/42, Lumintop GT, MT09R
UVC and UVC+UVA drivers
programming key
Remote switch tail DD board with FET
Aux boards:
Emisar D1, D1S, D4, D4S, D18, Lumintop FW3A, Fireflies ROT66, Astrolux MF01, Tail boards like S2+
How can I change the ramping speed in v1.2?
And is a voltage divider the only option for battery voltage sensing? Or can it compare the VCC input voltage with the internal reference as well?
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.
I was unhappy with my last hack to get the light start up at moon when powered on
I use this code and it seems to work
#ifdef STARTUP_MOON modeIdx = 1; // Turbo modeIdx = modesCnt – 1; Moon modeIdx = 1 if (ramping) { modeIdx = outLevel = rampingLevel = 1; SetLevel(outLevel); }
#endif
STARTUP_MOON is defined in the config file
I am wondering if its possible to let the light blink 2 times then go to moon as well
[Reviews] Miboxer C4-12, C2-4k+6k, C2, C4 / Astrolux K1, MF01, MF02, S42, K01, TI3A / BLF Q8 / Kalrus G35, XT11GT / Nitefox UT20 / Niwalker BK-FA30S / Sofirn SF36, SP35 / Imalent DM21TW / Wuben I333 / Ravemen PR1200 / CL06 lantern / Xanes headlamp
[Mods] Skilhunt H03 short / Klarus XT11GT, XT12GTS / Zebralight SC50+ / Imalent DM21TW / colorful anodisation
[Sale]
Drivers: overview of sizes and types
DD+AMC based drivers Anduril or Bistro OTSM 12-24mm, S42, 24-30mm L6, Q8, MF01(S), MT03, TN42
Anduril or Bistro 8A buck driver for 20-30mm, MF01/02/04, TN40/42, Lumintop GT, MT09R
UVC and UVC+UVA drivers
programming key
Remote switch tail DD board with FET
Aux boards:
Emisar D1, D1S, D4, D4S, D18, Lumintop FW3A, Fireflies ROT66, Astrolux MF01, Tail boards like S2+
Just a very odd behavior
the temperature readout was blinking constantly
in the end I had to set in the firmware an offset of +30
it seems the firmware does not like negative temperature values,
at least to blink out the value, if its also affecting the internal reading this gets a problem
this would mean on very cold lights that go into thermal stepdown while they are like -10°C
[Reviews] Miboxer C4-12, C2-4k+6k, C2, C4 / Astrolux K1, MF01, MF02, S42, K01, TI3A / BLF Q8 / Kalrus G35, XT11GT / Nitefox UT20 / Niwalker BK-FA30S / Sofirn SF36, SP35 / Imalent DM21TW / Wuben I333 / Ravemen PR1200 / CL06 lantern / Xanes headlamp
[Mods] Skilhunt H03 short / Klarus XT11GT, XT12GTS / Zebralight SC50+ / Imalent DM21TW / colorful anodisation
[Sale]
Drivers: overview of sizes and types
DD+AMC based drivers Anduril or Bistro OTSM 12-24mm, S42, 24-30mm L6, Q8, MF01(S), MT03, TN42
Anduril or Bistro 8A buck driver for 20-30mm, MF01/02/04, TN40/42, Lumintop GT, MT09R
UVC and UVC+UVA drivers
programming key
Remote switch tail DD board with FET
Aux boards:
Emisar D1, D1S, D4, D4S, D18, Lumintop FW3A, Fireflies ROT66, Astrolux MF01, Tail boards like S2+
I had a similar issue myself that took while to figure out. Indoors I couldn’t get the bug, but outside it stepped down (it was below 0°C outside, and not very warm inside the hut). At first I didn’t know why it stepped down so I programmed a separate step-down blink for voltage and temperature, and also if level is critical or not. It turned out that my issue was that when the readout goes below 0, the unsigned integer roles around to 255, causing the software to think the light is burning up at 255°C. Maybe similar issue you are having?
So I just removed role around to 255 on my 85 based drivers. I was low on space so I didn’t implement negative readouts. Now that I have double the space I’m considering implementing negative readouts, because sometimes I use my bike light to see approximately how cold it is when cycling in the winter. As it is now I can see when it’s below 0°C, but not how much below.
https://www.flickr.com/photos/akrylamid/
I think that ToyKeeper has mentioned something about negative temperature fix for RampingOS.
If I recall correctly, I did fix this in RampingIOS… but I completely removed and replaced all the thermal code there. The patch wouldn’t really apply to NarsilM, since the two projects have both diverged significantly from their shared ancestor. The RampingIOS patch could still be a general guide for implementing something similar in NarsilM though.
I can’t really apply the code from FSM / Anduril either since it has no common ancestor at all, and virtually no code which overlaps with Narsil.
At a quick glance, NarsilM seems to be using a uint8_t for its temperature value, so it can’t represent anything colder than freezing. It also appears to use a uint16_t for the initial raw value, from which it subtracts 275, which could set the value to 65,5XX during cold weather.
To fix only the negative temperature issues, it might work to simply use signed 16-bit values for all of this, and maybe add some checks to make sure it’s above 0. But I’m just guessing.
Add a default offset like 50. Then an unsigned integer can represent -50°C to 205°C. Should be enough.
https://www.flickr.com/photos/akrylamid/
Hi Tom,
some suggestions for the next version of NarsilM.
I would suggest to double the time to enter settings. From 8 seconds to 16 seconds
or 20.(Edit: The 20s would interfere with the jammed button protection)
And change the clicks for RAMPING and MODES in the settings.
Here has one and his friends problems. They accidentally end up in the settings aka wild blinks.
alternety, one of his later posts: http://budgetlightforum.com/comment/1294306#comment-1294306
I think he has a point making NarsilM more robust against wrong operation.
If I handle someone the light I tell “don’t press for longer than 8 seconds”.
I think extending the time can help. The only backside would be if some switches often between MODES and RAMPING. But I guess most stay in one UI.
I guess you used 8sec to be able to switch quickly between RAMPING and MODES.
The sequence to change is:
Hold the button till it blinks the first settings, then one or two clicks and then hold the button till the lamp confirm with four blinks.
In retrospect I think it would also better to change the first setting to
1 click = RAMPING
2 clicks = MODES
Today it’s reversed.
Only for the reason RAMPING is mostly used and people try to switch off the lamp if it starts blinking.
I found a review with another grafik of the UI from NarsilM v1.0
http://www.candlepowerforums.com/vb/showthread.php?443580-Review-Thorfire-BLF-Q8-5K-lumen-designed-by-FLASHAHOLICS!
changing the 8 to 20 seconds is just one line in the Narsil.c file
CONFIG hold – if it is not locked out or lock-out was just exited on this hold
//———————————————————————————————————————————-
if ((byLockOutSet 0) && !momentaryState) { if ((!ramping && (wPressDuration CONFIG_ENTER_DUR) && (fastClicks != 2) && (modeIdx != BATT_CHECK_MODE)) ||
(ramping && (wPressDuration == 500))) // 8 secs in ramping mode
same for Modes to extend 2.5 to more in the setup file
#define CONFIG_ENTER_DUR 160 // Config mode entry hold time – 160=2.5s, 128=2s
[Reviews] Miboxer C4-12, C2-4k+6k, C2, C4 / Astrolux K1, MF01, MF02, S42, K01, TI3A / BLF Q8 / Kalrus G35, XT11GT / Nitefox UT20 / Niwalker BK-FA30S / Sofirn SF36, SP35 / Imalent DM21TW / Wuben I333 / Ravemen PR1200 / CL06 lantern / Xanes headlamp
[Mods] Skilhunt H03 short / Klarus XT11GT, XT12GTS / Zebralight SC50+ / Imalent DM21TW / colorful anodisation
[Sale]
Drivers: overview of sizes and types
DD+AMC based drivers Anduril or Bistro OTSM 12-24mm, S42, 24-30mm L6, Q8, MF01(S), MT03, TN42
Anduril or Bistro 8A buck driver for 20-30mm, MF01/02/04, TN40/42, Lumintop GT, MT09R
UVC and UVC+UVA drivers
programming key
Remote switch tail DD board with FET
Aux boards:
Emisar D1, D1S, D4, D4S, D18, Lumintop FW3A, Fireflies ROT66, Astrolux MF01, Tail boards like S2+
I got a problem changing Output pins
I changed the register and PB port in the register settings but it does not work
It seems I have to change something in the channels.h file as well, but that code does not really make sense to me so I cant change it
[Reviews] Miboxer C4-12, C2-4k+6k, C2, C4 / Astrolux K1, MF01, MF02, S42, K01, TI3A / BLF Q8 / Kalrus G35, XT11GT / Nitefox UT20 / Niwalker BK-FA30S / Sofirn SF36, SP35 / Imalent DM21TW / Wuben I333 / Ravemen PR1200 / CL06 lantern / Xanes headlamp
[Mods] Skilhunt H03 short / Klarus XT11GT, XT12GTS / Zebralight SC50+ / Imalent DM21TW / colorful anodisation
[Sale]
Drivers: overview of sizes and types
DD+AMC based drivers Anduril or Bistro OTSM 12-24mm, S42, 24-30mm L6, Q8, MF01(S), MT03, TN42
Anduril or Bistro 8A buck driver for 20-30mm, MF01/02/04, TN40/42, Lumintop GT, MT09R
UVC and UVC+UVA drivers
programming key
Remote switch tail DD board with FET
Aux boards:
Emisar D1, D1S, D4, D4S, D18, Lumintop FW3A, Fireflies ROT66, Astrolux MF01, Tail boards like S2+
Pages