What people are seeing as “silver” or a glittery/metalic surface is just light reflection.

That might explain both the color and the spots with continuity. If the anodized layer is really thin, it could still appear silver… and might have areas thin enough to conduct. Generally anodizing darkens the surface, so I figured it would need a silver dye to lighten things up again.

What people are seeing as “silver” or a glittery/metallic surface is just light reflection.

That might explain both the color and the spots with continuity. If the anodized layer is really thin, it could still appear silver… and might have areas thin enough to conduct. Generally anodizing darkens the surface, so I figured it would need a silver dye to lighten things up again.

I’ll have to check with Simon on the details but I think you may be spot-on. I remember him being disappointed in the first several attempts at clear anodizing because it was too dark. He said it looked almost like the grey color he was already selling. It could be that they had to go with a thinner anodization layer to achieve the desired look.

My black 3/5 mode C8 has a feature which I find annoying: when the light has been in a particular mode for more than a few seconds, doing a half-press does not cycle it to the next mode. It just blinks off and comes back in the same mode. I guess it is supposed to be a ‘mute’ function but I don’t care for it.

My black 3/5 mode C8 has a feature which I find annoying: when the light has been in a particular mode for more than a few seconds, doing a half-press does not cycle it to the next mode. It just blinks off and comes back in the same mode. I guess it is supposed to be a ‘mute’ function but I don’t care for it.

All Convoy lights with that driver respond that way. The intent is to guard against unintended half-presses changing the mode after the user has selected a mode they intend to use for a while.

If you half-press twice in rapid succession, the light will change to the next mode, with subsequent single half-presses also changing mode until the light is left alone for a few seconds again.

varbos wrote:

Does the new C8 with biscotti have this same quirk ?

I don’t think so, but I don’t have one of those lights, so you might be best waiting for someone else to confirm that.

The new ones with Biscotti don’t do that. When we started using he Off-time capacitor it was to do away with that. All the old Nanjg 105’s and Qlites had that type of action, you had to bump it twice to nudge it forward after it’d been on for a bit.

Biscotti in the new Convoy’s brings a wealth of change, virtually all good.

My black 3/5 mode C8 has a feature which I find annoying: when the light has been in a particular mode for more than a few seconds, doing a half-press does not cycle it to the next mode. It just blinks off and comes back in the same mode. I guess it is supposed to be a ‘mute’ function but I don’t care for it.

Does the new C8 with biscotti have this same quirk ?

As far as I can tell, there wasn’t actually any intent behind that. It was an unfortunate side effect of the way it implemented memory.

The “on-time memory” it used worked like this:

Light turns on. Read the mode number from eeprom, and go to it.

Write the mode number plus one to eeprom.

Wait a second or two.

Write the current mode number to eeprom.

Wait forever.

So, if you leave it on for more than a second or two, next time you use it it’ll go to the same mode. If it was on for less than a second, it goes to the next mode. It doesn’t attempt to measure how long it was off.

Biscotti uses off-time memory instead. The behavior is determined by how long the light was off. So, during use, a quick tap always goes to the next mode. This is almost universally preferred. The main downside is that it’s more sensitive to what happens while the power is off, so a lighted tailcap can interfere with the “off time” measurement.

If it is writing something to eeprom every time we switch modes, could the memory eventually ‘wear out’ ? Or is eeprom write endurance sufficiently high for this not to be a problem during a typical lifespan ?

I don’t know if the old 3/5-mode firmware uses wear leveling. If so, the ROM should take at least a few centuries to wear out. If not, it should still take at least a decade. And those are both low estimates. Biscotti should take nearly a thousand years, even with quite a bit of daily use, before it ever starts thinking about having eeprom wear issues.

<—— filling out post-it note that TK guarantee’s Biscotti for 1000 years, logging it at 4/28/2017.

I’ll be watching you!

So, the eeprom is rated for 100,000 erase/write cycles minimum per byte… but in actual testing people tend not to encounter any failures until more like 10 million write cycles. So take 100k as a lower bound and 10M as an upper bound.

With only 32 bytes used for wear-leveling, let’s find out how many times a day you’d have to press the button to make it fail in 1000 years or less:

100,000 * 32 / 365.24 / 1000 = 8.76

10,000,000 * 32 / 365.24 / 1000 = 876

So… to make it fail in 1000 years, you’d have to press the button at least 8.76 times per day (every day) or potentially up to 876 times per day. I’m pretty sure some other part of the light would wear out first, like … the switch.

For example, on MTNs website for the Qlite driver it says the driver has low voltage protection then it says guppydrv is an option. It doesn’t say you lose the LVP with this firmware.

Maybe Richard should point this out as I had no idea.

In my 2 lights that have guppydrv I use protected cells. The one I’m working on right now, I had planned to use an unprotected one. I guess I can switch to a protected battery for it. Ah wait, that one was gonna use 2 26350 which are unprotected only. I may need to switch to a different firmware.

Richard DOES point that out. He states that the light will downshift but will not turn off.

Which means that it’ll run in the lowest mode till the battery is dead.

If you use the newest Bistro you’ll have a similar number of mode choices, it’s on the list as 9 but by changing H-L/L-H you’re doubling the list. Bistro allows you to set it up as you like, at will, including changing memory by toggling it on or off. You decide if it has 2 levels or 3 or 4 or 5 or 6 or 7 or 8 or 9, at will. You decide if it has moon or not. Also gives you choices with strobes, in a hidden group you back into. And the ability to reverse to a lower mode can go a LONG way towards saving battery life. Bistro is also on an FET+1 driver, so your lower modes are more efficient, pulling from a single 7135 chip instead of 8 or the FET.

Okay, so guppydrv has more of a low voltage warning as opposed to low voltage protection. You’ll know when the battery gets too low, but if the light gets turned on by accident and you don’t realize it, then it can drain the battery dangerously low. Is that correct?

When the light is on a higher level and the cell is draining you can usually see that and you’ll know, but by shifting down to lower modes you don’t notice the dimming, so say it shifts down and you’re still fishing, still using the low to bait hooks and what not. The light stays on, you forget it’s on low by it’s own device and in the morning you find your cell at a shocking 2.1V. Oops! Some chargers will accept this, some won’t. An isolated occurrence like this shouldn’t do harm to the cell, but there ya go, it’s up to you to monitor it where true low voltage protection will shut the light off at a safe cell level.

It’s a plus in some cases, you don’t have total darkness without warning, but of course you’re supposed to stop and swap cells when it drops down… you DO have a spare with you, don’t you?

I agree with you Dale, i am always excited when i see something new from Convoy because: a) it is not going to cost an arm and a leg; b) it is going to be very good quality; c) when properly modded it is going to put to shame everything in that price range.

Anyways i do really like to see proper thrower from Convoy, not that the L2 or even the L6 when modded are bad but i do want something that can push 500kcd or even more

Hello all, I am hoping I can get some help. When I compile the .c to .hex in avrstudio 5.0 it is successful. However when I try to write the flash to the attiny13 avrdude gives me an error (ERROR: address 0×0410 out of range at line 65) it then has the path to my .hex file. Can anyone please tell me what I am doing wrong?

Thank you!

EDIT: When I build the .hex file in atmelstudio 7.0 it gives an error stating the 1084 bytes 105.9% Full. What gives?

In both cases, the .hex file is too big. You’re probably missing some compiler options, like -Os and -std=gnu99 , which tell it to optimize for size. See bin/build.sh for the full set of recommended compiler options.