None of that sounds like any Convoy I’ve gotten. Crazy!
Contact Simon, he’ll make it right…
Mine neither. I’ve held probably 20 different convoy lights and the worst exterior I’ve seen is some tiny machine marks on the flat spot on the tube of an S2+.
Got my C8 today. More on that in the next post. But first…
Lightbringer wrote:
Was curious why I could never find a convoy.com or anything, …
This has been brought to Simon’s attention, and IIRC something is being worked on. Web sites aren’t really his specialty, and he’s a pretty small operation, so I don’t think he has had enough spare resources yet to make it happen.
Lazy-R-us wrote:
BD0* … is this series going to get updated drivers with Biscotti?
Not sure, but I think the drivers are compatible so there’s a good chance.
msim wrote:
no light is emitted in any configuration while in moonlight.
Not sure what’s causing that. Mine is working fine on moon. However, the driver is also running twice as fast as expected so it’s very possible that moon’s pulses are only half as long as they’re supposed to be, which would make it rather unstable. The symptom here is that moon would work on fully-charged cells (especially high-amp ones) but wouldn’t work with a nearly-empty cell. Similiarly, it would likely not work after using the light in a high mode for a while, but would work when rested.
gchart wrote:
Not sure why this one starts at 1. (PWM 1/255 for moon)
Looks like that was answered both earlier and later in the thread, but… the pulse speed is explicitly lowered on moon (to 1/16 normal) and low (to 1/2 normal) in order to make the pulses longer and more stable. So, PWM=1/255 should work on pretty much any hardware configuration, assuming it’s only running at 1 kHz. But it seems it might not actually be running at 1 kHz.
gchart wrote:
while I like having the option of a moonlight mode… how often do you pick up a light the size of a C8 and say “I want an almost indiscernible amount of light from you!”?
It’s intended as a relatively universal driver for many different types of lights. For throwers, there are mode groups with no moon, or with high first. For smaller EDC lights, there are mode groups with moon first. Not quite as flexible as bistro, but I put in as many options as I could fit.
msim wrote:
Good news, seems like it might in fact be a fluke. Just did a quick test of my 2nd new C8 that I had left at the office, and it doesn’t show that behavior at all. Moonlight seems to work just fine on my 2nd one.
That is good news!
But I’m still concerned that even one had issues. And, counting mine, that makes at least two which are behaving out-of-spec.
DB Custom wrote:
there are random fluctuations in the components that allow for slight differences and this sometimes trips us up when we’re using parameters that are right at the edge to begin with.
The attiny13a has a known per-unit variability which can interfere with the method used for distinguishing between long presses and short presses. As far as I can tell, it affects maybe one out of every 256 units, at most. It happens because it relies on a quirk of physics which is most definitely not part of the attiny’s official spec.
It works because of the way SRAM reverts back to a default value while power is disconnected. Usually each bit reverts to a value of 1; about 75% to 90% of the bits do this. The remaining ones revert to 0. So, to determine if the light has been off for a short time or a long time, it checks the value of a byte of SRAM at boot time. If the value is the one we previously set, assume power was only off for a short time. If the value has changed, assume power was off for a longer time.
Where this fails is if the value we set, by random chance, happens to be exactly the same as the value it naturally reverts to. The chances against it are huge, but it still happens on rare occasion.
As for being “right at the edge” though, that’s also a factor. Moon mode is very sensitive and hard to get consistent across multiple devices even for big-name brands. And we’re attempting to do it on much cheaper hardware with much wider tolerances. So, even with every precaution taken, it might still have issues occasionally.
DB Custom wrote:
I also once got a driver from a known high quality dealer that had a sense resistor glitch.
Me too. He even sent me one specifically because he was having trouble with it, and it turns out all it needed was a gentle tap of a soldering iron at the right place. Worked fine after re-melting a single contact point.
J-Dub74 wrote:
… having to try to keep up with this thread.
Geez, take a couple days off and there are 75 new messages and a bunch of questions I need to answer!
(life has been a bit turbulent lately, but I’ll try to keep up)
T18 wrote:
ConvoyClearC8 Lens Issue
I actually had to tap the glass on mine to be sure it was there. Totally invisible. Yours probably just needs a bit of care from a lens cloth and some lens cleaning solution. Should be pretty easy to do.
gchart wrote:
I wonder if these drivers will allow the retainer ring to be used in the S-series pills? Does anybody have one that they can test?
I’m not 100% certain, but it looks likely. The C8 I got has a retaining ring and the driver isn’t soldered in, and it has 8×7135. So I think it’ll probably work the same way on the S series, but I haven’t actually tried it.
I got a new Convoy C8 today. Just a few minutes ago, actually. Haven’t even had time to take it apart.
Most of it is nice, but I’ve noticed two issues on mine:
Everything seems to go a little over 2X as fast as intended.
I can’t get it to disable mode memory. (changing the mode group works fine though)
Not sure yet what’s going on there. I’d think the attiny was overclocked or something, except the code was calibrated to run at its fastest speed. But I’ll still make sure the fuses and the ROM match what I was expecting, and measure the PWM speed to double check.
…
Okay, these are the PWM speeds I’m seeing:
Moon: ~1.8 kHz? (hard to measure at low intensity)
Low: 18 kHz
Everything else: 36 kHz
Strobe: 24.8 Hz
The attiny13a isn’t generally capable of running that fast. Normally it maxes out at 16 kHz (plus or minus individual unit tolerances of about 2kHz, so 14-18kHz). Something is definiely weird here. Will have to un-solder some things to get the driver out for more details.
Just now I measured a sample driver I used for development, and found the following:
Moon: 1.0 kHz
Low: 9 kHz
Other modes: 18 kHz
Strobe: 12 Hz
…
Did some quick measurements before I take it apart… On a 4.05V 25R cell, I got:
0.1%: 2.81 lm (0.33%) (visually 1.41)
1%: 26.55 lm (3.13%) (visually 2.98)
10%: 111.5 lm (13.1%) (visually 4.81)
35%: 377 lm (44.5%) (visually 7.23)
100%: 848 lm (100%) (visually 9.47)
Mode spacing: 1.57, 1.83, 2.42, 2.24
The outputs and spacing are significantly different than what I used for testing. Let’s un-solder some things and see what’s inside…
…
Okay, got the driver out. It says on the outside it’s an attiny13a. Which is curious, because it’s going twice as fast as the attiny13a’s spec says it should be able to. 4.8 MHz / 256 cycles per PWM loop = 18.75 kHz PWM, but it’s actually running at 36 kHz. (and the attiny13a usually runs between 3.6 MHz and 4.4 MHz, highly variable per unit and slower than spec… but this one seems to be more like 9.6 MHz?)
Also, the markings on the 7135 chips are different than the drivers used for testing, which probably explains why the output levels are different. These new chips appear to have a more linear response curve, which is good except that the code was calibrated to a non-linear curve.
Maybe it’s using weird fuse settings or the firmware changed. I’ll check…
…
Dangit, can’t get the SOIC8 clip to connect because a capacitor is in the way. The MCU doesn’t have enough clearance on one side. Maybe I can get my janky old clip to connect instead, since I filed the edges off it.
…
Looks like the older clip fits, and it works on other drivers, but I can’t get it to connect to this particular chip. Will keep trying, but it looks like this is as far as I can go for now.
It seems the new drivers have different enough hardware to make some calibration changes necessary. And I’m guessing it was flashed with different fuses or something, because it’s running at the wrong speed. Plus, the driver layout has the really unfortunate quirk of not letting a SOIC8 clip fit. Hopefully I can figure out more of the details soon.
I got a new Convoy C8 today. Just a few minutes ago, actually. Haven’t even had time to take it apart.
Most of it is nice, but I’ve noticed two issues on mine:
Everything seems to go a little over 2X as fast as intended.
I can’t get it to disable mode memory. (changing the mode group works fine though)
Not sure yet what’s going on there. I’d think the attiny was overclocked or something, except the code was calibrated to run at its fastest speed. But I’ll still make sure the fuses and the ROM match what I was expecting, and measure the PWM speed to double check.
…
Okay, these are the PWM speeds I’m seeing:
Moon: ~1.8 kHz? (hard to measure at low intensity)
Low: 18 kHz
Everything else: 36 kHz
Strobe: 24.8 Hz
The attiny13a isn’t generally capable of running that fast. Normally it maxes out at 16 kHz (plus or minus individual unit tolerances of about 2kHz, so 14-18kHz). Something is definiely weird here. Will have to un-solder some things to get the driver out for more details.
Just now I measured a sample driver I used for development, and found the following:
Moon: 1.0 kHz
Low: 9 kHz
Other modes: 18 kHz
Strobe: 12 Hz
…
Did some quick measurements before I take it apart… On a 4.05V 25R cell, I got:
0.1%: 2.81 lm (0.33%) (visually 1.41)
1%: 26.55 lm (3.13%) (visually 2.98)
10%: 111.5 lm (13.1%) (visually 4.81)
35%: 377 lm (44.5%) (visually 7.23)
100%: 848 lm (100%) (visually 9.47)
Mode spacing: 1.57, 1.83, 2.42, 2.24
The outputs and spacing are significantly different than what I used for testing. Let’s un-solder some things and see what’s inside…
…
Okay, got the driver out. It says on the outside it’s an attiny13a. Which is curious, because it’s going twice as fast as the attiny13a’s spec says it should be able to. 4.8 MHz / 256 cycles per PWM loop = 18.75 kHz PWM, but it’s actually running at 36 kHz. (and the attiny13a usually runs between 3.6 MHz and 4.4 MHz, highly variable per unit and slower than spec… but this one seems to be more like 9.6 MHz?)
Also, the markings on the 7135 chips are different than the drivers used for testing, which probably explains why the output levels are different. These new chips appear to have a more linear response curve, which is good except that the code was calibrated to a non-linear curve.
Maybe it’s using weird fuse settings or the firmware changed. I’ll check…
…
Dangit, can’t get the SOIC8 clip to connect because a capacitor is in the way. The MCU doesn’t have enough clearance on one side. Maybe I can get my janky old clip to connect instead, since I filed the edges off it.
…
Looks like the older clip fits, and it works on other drivers, but I can’t get it to connect to this particular chip. Will keep trying, but it looks like this is as far as I can go for now.
It seems the new drivers have different enough hardware to make some calibration changes necessary. And I’m guessing it was flashed with different fuses or something, because it’s running at the wrong speed. Plus, the driver layout has the really unfortunate quirk of not letting a SOIC8 clip fit. Hopefully I can figure out more of the details soon.
I knew I should have stayed in bed today… TK please keep me posted on your findings so I can communicate them directly to Simon. Hopefully there isn’t anything more than a few quirky ones in this first run. I just got mine today too. I don’t have any way to test driver output levels but everything seems about right. I’d guesstimate the lowest mode somewhere between 1 and 2 lumens. I have no problem switching between mode groups and mode memory toggles on and off just like it should. Please PM me with any specifics that need to be sent to Simon.
TK, why don’t you just pull the MCU and flash it, then put it back on? I was told a neat trick to make removing the MCU easy, Put a big dollop of solder on the iron and apply it to all 4 legs at once on one side. It’ll heat up the legs quicker and the entire component will easily lift off within a couple of seconds. Surprisingly, when it comes off the legs are usually separate and clear of excess solder, it seems to go back to the iron.
A general request for anyone who has a new C8: Could you help me check the driver speed?
All you have to do is get a clock, put the light in biking mode, and then count the pulses like measuring someone’s heart rate. Like, count the pulses for 15 seconds and multiply the number times 4, or count for 30 seconds and multiply by 2. Then tell me the number.
It should be pretty close to one pulse per second. So if it’s 40 to 80 bpm, it’s probably normal. If it’s faster than 80 bpm, it’s probably overclocked. I think mine is doing about 110 bpm.
FWIW, the approximate driver speed in MHz is: BPM * 4 * 1.28 / 60. (or, pulses-per-minute times 1280 ms per pulse at 4.0 MHz, over 60 seconds per minute)
So, if you measure 110, that means about 9.4 MHz. A value of 40 would mean 3.4 MHz. The code assumes the chip runs somewhere near 4.0 MHz.
Because I forget so much, I must seize the thought process when it hits… maukka can you say which tint bin is closest to pure white? I have been trending towards 3A , is there one that get’s me closer to pure white in your testing?
The variation is too big to make any conclusions. I’ve had great and not so great samples of 3A, 3B, 3C and 3D. But going by specs, I’d choose 3A or 3D. Even then you might not be able to avoid the horrid green. But I’ve also gotten 3B on the rosier side (assuming Banggood’s product pages were correct…)
The variation is too big to make any conclusions. I’ve had great and not so great samples of 3A, 3B, 3C and 3D. But going by specs, I’d choose 3A or 3D. Even then you might not be able to avoid the horrid green. But I’ve also gotten 3B on the rosier side (assuming Banggood’s product pages were correct…)
Could just be my samples and variations thereof, but I liked 3D and 4A for “purest” white.
Appearancewise, I like 4A and 4D for white-white, the 5As for a little warmth.
Past a certain point, you just have to side-by-side compare them to notice anything. Anyone who’s played around with an audio equaliser of at least 10 bands (preferably 20) knows what I mean. Sometimes what you hear as “better” is just simply louder.
Can you please describe all possible implications of driver running twice faster than expected?
A few implications come to mind:
The blinky modes blink faster
Bike mode’s pulses look less intense
The config mode has shorter windows in which to press the button
The “buzz” for each config option looks less like a buzz and more like a steady low
Changing mode groups takes half as long
Moon mode is probably a bit more voltage-sensitive, but I haven’t tested how much
The driver is basically guaranteed not to make an audible whine, since it’s oscillating too fast for humans to hear
The light output should look extra-smooth with no visible pulses (except maybe in moon mode)
LVP step-down should happen in half the time
The lowest modes might be very slightly less efficient, maybe a few percent
Basically, for normal illumination purposes it doesn’t make much difference. But anything involving timing goes faster. A 25 Hz strobe is outside the ideal range for tactical purposes, and when the UI blinks out numbers they’re harder to count, and configuring the light requires faster reflexes.
Chances are, the factory can fix it by changing a single digit in a script somewhere. But I’ll be sure to send in other updates too, since these new drivers appear to have nicer 7135 chips than the old ones and I want to make sure everything is calibrated correctly.
Oh dang, I find the buzzes, voltage blinks and tap/long tap difference too fast/close as it was on Bistro (personal just me getting older )
Have a few drivers on the way.
So setup and forget about playing around then for me
Oh dang, I find the buzzes, voltage blinks and tap/long tap difference too fast/close as it was on Bistro (personal just me getting older )
I actually slowed that stuff down for this driver, because you’re not the only one who thought it was too fast…
… but then it doubled. D’oh.
Weird how much difference it can make to swap a single bit. The speed doubles by setting the low fuse to 0×76 instead of 0×75.
How unstable/unreliable is the Tiny13 overclocking? Is it unlikely to even work with most Tiny13’s or is it something we could make use of somehow? NOT for this driver, obviously. I’m thinking of new BLF driver designs (or actually firmware) that use the higher frequency on purpose.
—
The Cycle of Goodness: “No one prospers without rendering benefit to others”
- The YKK Philosophy
How unstable/unreliable is the Tiny13 overclocking? Is it unlikely to even work with most Tiny13’s or is it something we could make use of somehow? NOT for this driver, obviously. I’m thinking of new BLF driver designs (or actually firmware) that use the higher frequency on purpose.
It’s not unstable or unreliable. It’s within the tiny13’s spec and seems to work fine. However, the shorter pulses aren’t ideal.
The optimal PWM frequency is fast enough that you don’t see or hear it, but otherwise as slow as possible. So, right at the top of human hearing, about 20 kHz. At 4.8 MHz, the attiny13a gets pretty close (18 kHz), while running it at 9.6 MHz goes excessively fast (36 kHz). The faster speed also uses a bit more power and is a bit less efficient at producing light.
So, running it faster isn’t very useful for flashlight purposes.
Mine neither. I’ve held probably 20 different convoy lights and the worst exterior I’ve seen is some tiny machine marks on the flat spot on the tube of an S2+.
Puzzling how this one made it past QC.
Got my C8 today. More on that in the next post. But first…
This has been brought to Simon’s attention, and IIRC something is being worked on. Web sites aren’t really his specialty, and he’s a pretty small operation, so I don’t think he has had enough spare resources yet to make it happen.
Not sure, but I think the drivers are compatible so there’s a good chance.
Not sure what’s causing that. Mine is working fine on moon. However, the driver is also running twice as fast as expected so it’s very possible that moon’s pulses are only half as long as they’re supposed to be, which would make it rather unstable. The symptom here is that moon would work on fully-charged cells (especially high-amp ones) but wouldn’t work with a nearly-empty cell. Similiarly, it would likely not work after using the light in a high mode for a while, but would work when rested.
Looks like that was answered both earlier and later in the thread, but… the pulse speed is explicitly lowered on moon (to 1/16 normal) and low (to 1/2 normal) in order to make the pulses longer and more stable. So, PWM=1/255 should work on pretty much any hardware configuration, assuming it’s only running at 1 kHz. But it seems it might not actually be running at 1 kHz.
It’s intended as a relatively universal driver for many different types of lights. For throwers, there are mode groups with no moon, or with high first. For smaller EDC lights, there are mode groups with moon first. Not quite as flexible as bistro, but I put in as many options as I could fit.
That is good news!
But I’m still concerned that even one had issues. And, counting mine, that makes at least two which are behaving out-of-spec.
The attiny13a has a known per-unit variability which can interfere with the method used for distinguishing between long presses and short presses. As far as I can tell, it affects maybe one out of every 256 units, at most. It happens because it relies on a quirk of physics which is most definitely not part of the attiny’s official spec.
It works because of the way SRAM reverts back to a default value while power is disconnected. Usually each bit reverts to a value of 1; about 75% to 90% of the bits do this. The remaining ones revert to 0. So, to determine if the light has been off for a short time or a long time, it checks the value of a byte of SRAM at boot time. If the value is the one we previously set, assume power was only off for a short time. If the value has changed, assume power was off for a longer time.
Where this fails is if the value we set, by random chance, happens to be exactly the same as the value it naturally reverts to. The chances against it are huge, but it still happens on rare occasion.
As for being “right at the edge” though, that’s also a factor. Moon mode is very sensitive and hard to get consistent across multiple devices even for big-name brands. And we’re attempting to do it on much cheaper hardware with much wider tolerances. So, even with every precaution taken, it might still have issues occasionally.
Me too. He even sent me one specifically because he was having trouble with it, and it turns out all it needed was a gentle tap of a soldering iron at the right place. Worked fine after re-melting a single contact point.
Geez, take a couple days off and there are 75 new messages and a bunch of questions I need to answer!
(life has been a bit turbulent lately, but I’ll try to keep up)
I actually had to tap the glass on mine to be sure it was there. Totally invisible. Yours probably just needs a bit of care from a lens cloth and some lens cleaning solution. Should be pretty easy to do.
I’m not 100% certain, but it looks likely. The C8 I got has a retaining ring and the driver isn’t soldered in, and it has 8×7135. So I think it’ll probably work the same way on the S series, but I haven’t actually tried it.
Wow Toykeeper you just knocked out a lot of writing! Its almost an essay lol
Light Reviews
Cheap Flashlight Durability Test
Convoy S2+ Written review
Brinyte T16 Artemis tear down
YouTube Reviews
Sofirn D25S Review
Xmund XD-FL3 Review
World band shortwave radio review
Mods and Builds
6th Annual Old Lumens Scratch build entry
7th annual Old Lumens scratch build entry
I got a new Convoy C8 today. Just a few minutes ago, actually. Haven’t even had time to take it apart.
Most of it is nice, but I’ve noticed two issues on mine:
Not sure yet what’s going on there. I’d think the attiny was overclocked or something, except the code was calibrated to run at its fastest speed. But I’ll still make sure the fuses and the ROM match what I was expecting, and measure the PWM speed to double check.
…
Okay, these are the PWM speeds I’m seeing:
The attiny13a isn’t generally capable of running that fast. Normally it maxes out at 16 kHz (plus or minus individual unit tolerances of about 2kHz, so 14-18kHz). Something is definiely weird here. Will have to un-solder some things to get the driver out for more details.
Just now I measured a sample driver I used for development, and found the following:
…
Did some quick measurements before I take it apart… On a 4.05V 25R cell, I got:
Mode spacing: 1.57, 1.83, 2.42, 2.24
The outputs and spacing are significantly different than what I used for testing. Let’s un-solder some things and see what’s inside…
…
Okay, got the driver out. It says on the outside it’s an attiny13a. Which is curious, because it’s going twice as fast as the attiny13a’s spec says it should be able to. 4.8 MHz / 256 cycles per PWM loop = 18.75 kHz PWM, but it’s actually running at 36 kHz. (and the attiny13a usually runs between 3.6 MHz and 4.4 MHz, highly variable per unit and slower than spec… but this one seems to be more like 9.6 MHz?)
Also, the markings on the 7135 chips are different than the drivers used for testing, which probably explains why the output levels are different. These new chips appear to have a more linear response curve, which is good except that the code was calibrated to a non-linear curve.
Maybe it’s using weird fuse settings or the firmware changed. I’ll check…
…
Dangit, can’t get the SOIC8 clip to connect because a capacitor is in the way. The MCU doesn’t have enough clearance on one side. Maybe I can get my janky old clip to connect instead, since I filed the edges off it.
…
Looks like the older clip fits, and it works on other drivers, but I can’t get it to connect to this particular chip. Will keep trying, but it looks like this is as far as I can go for now.
It seems the new drivers have different enough hardware to make some calibration changes necessary. And I’m guessing it was flashed with different fuses or something, because it’s running at the wrong speed. Plus, the driver layout has the really unfortunate quirk of not letting a SOIC8 clip fit. Hopefully I can figure out more of the details soon.
Ohhhh boy. I just placed an order for a batch of those drivers and was planning on flashing a customized Biscotti. Appreciate the play-by-play!
I knew I should have stayed in bed today… TK please keep me posted on your findings so I can communicate them directly to Simon. Hopefully there isn’t anything more than a few quirky ones in this first run. I just got mine today too. I don’t have any way to test driver output levels but everything seems about right. I’d guesstimate the lowest mode somewhere between 1 and 2 lumens. I have no problem switching between mode groups and mode memory toggles on and off just like it should. Please PM me with any specifics that need to be sent to Simon.
TK, why don’t you just pull the MCU and flash it, then put it back on? I was told a neat trick to make removing the MCU easy, Put a big dollop of solder on the iron and apply it to all 4 legs at once on one side. It’ll heat up the legs quicker and the entire component will easily lift off within a couple of seconds. Surprisingly, when it comes off the legs are usually separate and clear of excess solder, it seems to go back to the iron.
I might, unless I can get it to talk to the usbasp otherwise.
… And I just got a hot-air solder station, which might help quite a bit. Haven’t even taken it out of the box yet.
Don’t have my scope to test pwm right now but here’s the relative output steps (fully charged 30Q)
I got 2300Hz PWM on moon using a camera. With a 1/100s shutter speed 23 distinct patterns when moving it very fast across the frame.
A general request for anyone who has a new C8: Could you help me check the driver speed?
All you have to do is get a clock, put the light in biking mode, and then count the pulses like measuring someone’s heart rate. Like, count the pulses for 15 seconds and multiply the number times 4, or count for 30 seconds and multiply by 2. Then tell me the number.
It should be pretty close to one pulse per second. So if it’s 40 to 80 bpm, it’s probably normal. If it’s faster than 80 bpm, it’s probably overclocked. I think mine is doing about 110 bpm.
FWIW, the approximate driver speed in MHz is: BPM * 4 * 1.28 / 60. (or, pulses-per-minute times 1280 ms per pulse at 4.0 MHz, over 60 seconds per minute)
So, if you measure 110, that means about 9.4 MHz. A value of 40 would mean 3.4 MHz. The code assumes the chip runs somewhere near 4.0 MHz.
The bike flasher is definitely about twice per sec.
edit: exactly 120bpm.
Because I forget so much, I must seize the thought process when it hits… maukka can you say which tint bin is closest to pure white? I have been trending towards 3A , is there one that get’s me closer to pure white in your testing?
The variation is too big to make any conclusions. I’ve had great and not so great samples of 3A, 3B, 3C and 3D. But going by specs, I’d choose 3A or 3D. Even then you might not be able to avoid the horrid green. But I’ve also gotten 3B on the rosier side (assuming Banggood’s product pages were correct…)
Could just be my samples and variations thereof, but I liked 3D and 4A for “purest” white.
Appearancewise, I like 4A and 4D for white-white, the 5As for a little warmth.
Past a certain point, you just have to side-by-side compare them to notice anything. Anyone who’s played around with an audio equaliser of at least 10 bands (preferably 20) knows what I mean. Sometimes what you hear as “better” is just simply louder.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
This is really unfortunate.
My new Clear (Black) C8 is in the mail.
Can you please describe all possible implications of driver running twice faster than expected?
A few implications come to mind:
Basically, for normal illumination purposes it doesn’t make much difference. But anything involving timing goes faster. A 25 Hz strobe is outside the ideal range for tactical purposes, and when the UI blinks out numbers they’re harder to count, and configuring the light requires faster reflexes.
Chances are, the factory can fix it by changing a single digit in a script somewhere. But I’ll be sure to send in other updates too, since these new drivers appear to have nicer 7135 chips than the old ones and I want to make sure everything is calibrated correctly.
Thanks, not a big deal to me then, since the configuration was easy enough.
Oh dang, I find the buzzes, voltage blinks and tap/long tap difference too fast/close as it was on Bistro (personal just me getting older
)
Have a few drivers on the way.
So setup and forget about playing around then for me
It is done when it is done
How my BLF Specials generally work, please read before asking Qs
The Q8, Exciting a groupbuy for a Premium BLF special high lumens soda can light!
The GT, A BLF special GIGA thrower
The FW3A, a TLF BLF special small, elegant, powerful triple
Lithium Ion safety 101 important read
Sorry grammarlovers, I am a real King Typo.
Can we keep the 46% mode instead of 35% ?
Recent Reviews: Light Flashlight Painting Buying Guide 2020 // LumeCube 2.0 // Lumintop FW1A // Light Painting Paradise Lightpainter // KDLITKER E6 // Sofirn SP31V2.0 // Convoy S2+
Affiliate links: Neal's Gadgets
Instagram: @stephenk_lightart
I actually slowed that stuff down for this driver, because you’re not the only one who thought it was too fast…
… but then it doubled. D’oh.
Weird how much difference it can make to swap a single bit. The speed doubles by setting the low fuse to 0×76 instead of 0×75.
How unstable/unreliable is the Tiny13 overclocking? Is it unlikely to even work with most Tiny13’s or is it something we could make use of somehow? NOT for this driver, obviously. I’m thinking of new BLF driver designs (or actually firmware) that use the higher frequency on purpose.
The Cycle of Goodness: “No one prospers without rendering benefit to others”
- The YKK Philosophy
It’s not unstable or unreliable. It’s within the tiny13’s spec and seems to work fine. However, the shorter pulses aren’t ideal.
The optimal PWM frequency is fast enough that you don’t see or hear it, but otherwise as slow as possible. So, right at the top of human hearing, about 20 kHz. At 4.8 MHz, the attiny13a gets pretty close (18 kHz), while running it at 9.6 MHz goes excessively fast (36 kHz). The faster speed also uses a bit more power and is a bit less efficient at producing light.
So, running it faster isn’t very useful for flashlight purposes.
Well better add some functions that requires computing to take advantage of the OC
It is done when it is done
How my BLF Specials generally work, please read before asking Qs
The Q8, Exciting a groupbuy for a Premium BLF special high lumens soda can light!
The GT, A BLF special GIGA thrower
The FW3A, a TLF BLF special small, elegant, powerful triple
Lithium Ion safety 101 important read
Sorry grammarlovers, I am a real King Typo.
I’ll get right on that.
The next version’s big selling point will be a mode which blinks out the digits of pi… all of them.
YES! Finally! Flashlights For Nerds™!
The Cycle of Goodness: “No one prospers without rendering benefit to others”
- The YKK Philosophy
Now you're being irrational.
How to Post Images on BLF // Many knives for sale (USA only)
How to move a thread
The math puns are strong with this one…
My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03
Major Projects: Illuminated Tailcap, TripleDown/TripleStack Driver
I was thinking that someone here is in trouble but now I believe there is someone’s are trouble.
Your work is amazing TK.
djozz quotes, "it came with chinese lettering that is chinese to me".
"My man mousehole needs one too"
old4570 said "I'm not an expert , so don't suffer from any such technical restrictions".
Old-Lumens. Highly admired and cherished member of Budget Light Forum. 11.5.2011 - 20.12.16. RIP.
Naw… just bein’ real
Pages