New Convoy C8 – Clearly better

TAce is saying in the code for Bistro (before flashing to the MCU) you can set if biking strobe “stutters” or just does a single bright flash every few seconds. He is asking which option is built into biscotti or whatever we’re calling it.

The stutter is the default. That is what comes in the X6/X5 and that is what is in Bistro-mini for Convoy as far as I remember… I sent the primary C8 test light to JDub, he can verify it…. I just remembered I also have it on my ReyLight Brass AA… hang on…

Bistro-mini has bicycle strobe in three places, level 1, 4 and 7. All three have the stutter in the bicycle strobe.

I don’t ever open Bistro in my AVR programmer because it wont re-write it - I always get a ton of cautions and errors with any change. And since I seldom use Bistro due to the bounce-to-moon issue I haven’t seen that option.

And FWIW, I did open the Bistro-mini in AVR and it’s MUCH different, there’s a veritable Library of stuff in there! A simple change I tried to make gave me all the errors in the build so again, I haven’t modified it.

Edit: I’m assuming what you’re asking is found in this section of the code…

#define TURBO RAMP_SIZE // Convenience code for turbo mode
#define BATTCHECK 254 // Convenience code for battery check mode
#define GROUP_SELECT_MODE 253
//#define TEMP_CAL_MODE 252
// Uncomment to enable tactical strobe mode
#define STROBE 251 // Convenience code for strobe mode
// Uncomment to unable a 2-level stutter beacon instead of a tactical strobe
#define BIKING_STROBE 250 // Convenience code for biking strobe mode
// comment out to use minimal version instead (smaller)
#define FULL_BIKING_STROBE
//#define RAMP 249 // ramp test mode for tweaking ramp shape
//#define POLICE_STROBE 248
//#define RANDOM_STROBE 247

Yeah, the only way to access the single flash version is by editing the code for bistro. By default it is the stutter option. It does take up a lot more space then the single flash though so I was not sure if TK may have gone to the single flash for the tiny13.

Far as the errors go, we were talking about this in the firmware thread a week or 2 ago. TomE posted some things to get bistrol to compile on Atmel studio, I gave up awhile back and just use linix for it now. I might try atmel again at some point.

Correct, if you comment out “#define FULL_BIKING_STROBE” by changing it to “//#define FULL_BIKING_STROBE” then it will only give a single flash instead of the stutter.

Looking at that sinpit of code, it looks like TK simply edited out all the options for bistro to get the size down to Tiny13 sizes. I should look at the full code, with an OTC added to a 105C I wonder if it would work like bistro on the 13A with most of the features removed. I have some 105c’s to use up but had not decided on a firmware.

After my initial problems, it’s compiling fine for me too. You just have to get all the directories right for the header files. Definitely different than everything on the 13 was.

Anyways, wrong thread

Yeah, we should move this discussion to the firmware thread.

I like how TK set’s it up, can’t wrap my damaged cells around the code to make changes anyway, so… shrug. Some famous person once said “It is what it is.” (Yes, I know, it was Justin… aka Old-Lumens)

Should Bicycle Lights Blink?

This makes a certain amount of sense.

It is telling that German laws regarding bicycle lights favor non-blinking lights. IMO, Germany now has the most farsighted bicycle laws of any nation. Front and rear lights are required to be standard equipment on all new bikes. A short search led me to this quote: "Lighting: Non-blinking front headlamp to illuminate the road of white or pale yellow color. A red rear taillight that stays lit when stationary. [see § 67 StVZO in German.]"

Ultimately, these are issues that need to be given thorough scientific study. Anecdotally, you may prefer bicycle lights that do not blink. That, however, does not mean very much. Whether bicycles with non-blinking lights are involved in fewer accidents than those with blinking lights can only be determined by well-designed studies.

the C8 you linked there does not have the new driver.

The only Convoy light that uses the new driver right now is the clear anodized Convoy C8 which also uses XPL-HI among other changes. More lights will be getting the driver upgrade but the migration is going to take some time. Until then, you have two options to get the new firmware in many Convoy lights.

  1. If you’re handy enough to do a driver swap Simon has the drivers with the new firmware ready to go. The new driver boards with the Biscotti firmware are red and can be purchased here. .
  2. If you’re tech savvy enough (and have the hardware) to flash driver firmware yourself the files are available in ToyKeeper’s firmware repository.

In answer to your question about the Nitecore chargers in Simon’s store being authentic, yes they certainly are. As will34 and Texas_Ace said, you will not find fake products in Simon’s store. You can shop there with complete confidence. Keep in mind there are a few stores even on Aliexpress that have been caught selling fake Convoy lights. If on Aliexpress make sure the store name listed near the top of the page is “Shenzhen Convoy Electronics Co., Ltd”. :+1:

You need to fix PWM level in current firmware version. Now they are too high.

Could you explain? What is too high? The amps?

Now sure how the PWM would be too high. high = better since it won’t produce any while or visible flicker?

My personal lights are usually loaded up with stop-motion strobes because I like the effect it has on moving water and other motions. I don’t generally include any tactical strobes at all.

Yes, which is why it was initially called bistro-mini. :slight_smile: It was as much of bistro as I could fit on a tiny13. Actually, I still need to merge some changes back into bistro itself, since I found a few extra ways to save space.

I picked a default bike mode based on what I liked, not based on actual research. If anyone has studies or polls showing that a different behavior would be better, I’d be happy to change it.

I don’t understand either.

The attiny13a can generally do PWM from about 128 Hz to 16 kHz. The lower speeds make visible flashes, while faster speeds sometimes make an audible whine. Ideal would be about 22 kHz — fast enough to look smooth, too high to hear, and otherwise as slow as possible for efficiency reasons.

The PWM speed can be fine-tuned on a single-channel driver like Convoy uses, but I didn’t attempt to make it faster than 16 kHz because people usually seem pretty happy with that speed. By setting the PWM ceiling to 180 instead of 255, the pulses would be about 22 kHz. However, this would only work on medium and high modes because the moon and low modes actually had to be slowed down to make the pulses long enough to activate the LED. It could be an option for later though.

As is, the default 5 modes run at 1 kHz / 8 / 16 / 16 / none. With a few extra lines of code it could be made to run at 1/8/22/22/none. On nicer drivers (RMM FET+1) I’d normally do 8/16/none/16ish/none. (by “ish” I mean half PWM where it alternates between medium and maximum without ever turning off) But the code this time was a compromise to maximize compatibility on a wide range of hardware.

How awesome would it be , if it had the bistro batt check instead of strobe (for me at least) :wink: .

Replied in the firmware thread to keep this thread semi-on topic. Flashlight Firmware Repository

Sorry, the volts+tenths method uses more room, and Simon wanted something simpler for a wider audience. So it does the 4-blink method instead. Otherwise, I agree.

I love it , even with the current setup.
Already using it in 2 fet drivers and 1 8x7135(+4 7135 chips).

I didn’t say anything about the PWM frequency :wink: I was talking about the levels of the PWM.

Now you use the following values:

With them, the driver has the output power levels 0.2% / 1.5% / 12.5% / 25% / 46% / 48% / 100% (instead 0.1 / 1 / 10 / 20 / 35 / 50 / 100)
I propose to change the values on

With them, the power levels will be closer to stated values.

ToyKeeper, you did a brilliant software, thank you. I now use it in all my flashlights.

Oh, I had it closer to that initially… but then I measured the power draw on each mode and adjusted the PWM values until the power measurements matched the spec. The PWM-to-power-usage curve was less linear than I expected, and it was consistently non-linear on the drivers I tested.

I’ll measure again when I get a production light, and adjust the levels if they’re not right. Maybe even make a new slow-ramp testing mode which goes through each PWM level one at a time while I log the measurements, so I can graph the shape of the curve.

On drivers with a more linear response, the default PWM levels will be a bit weird.