New Convoy C8 – Clearly better

My sincere thanks to you both TK and Tom. This programming stuff is over my head but I will sleep better tonight knowing I have two BLF rock stars on the case! :beer: :beer:

Thanks! It’s good to hear the moon level works; I was worried because it’s so low.

About voltage, I managed to fry my resistor so every reading is 255. Otherwise I’d just generate a new table with better values.

So, to clarify, the table from 192 (4.4V) to 99 (2.2V) gives accurate readings? If so, I’ll rebuild with that and send off the .hex. I think that was the only thing Convoy’s version needed, unless you found other issues with the default code.

About the 750/4 thing, I’m still trying to decide how best to handle that. Working in 16-bit makes milliseconds easier since we need 1000 of them for a single second. However, it takes extra ROM space. In this case, I needed a few more bytes and didn’t have them, so I replaced _delay_ms(uint16_t) with _delay_4ms(uint8_t). Lower resolution, but using an 8-bit parameter saves enough space to be worthwhile. However, it means all delay values need to be divided by 4, preferably at compile time instead of runtime. So I’ve been putting a /4 at each delay, to make it relatively clear how many milliseconds it should be, and that it’s not actually specified in milliseconds. But it still smells a little off.

The n.nV blink rate wasn’t actually tested in this project, but it’s good that you reminded me. I had kind of ignored parts of the code which were disabled for Convoy purposes. I didn’t even try to adjust the timing on that after messing with all the other delay-related stuff.

I'd say based on the measurements, relatively small sample, but spread from hi, med, lo, yes, the 2nd table is more accurate. I'm pretty sure I've done other testing against that table in the past as well.

From what I've seen, the only factors are the location of the diode and the R1/R2 values. The only unknown to me is the impact of a bleeder resistor - thought I'd seen it mentioned but not sure, but this driver doesn't have a bleeder resistor currently.

Thanks!

I usually just measure each new driver directly with battcheck.c, with a full cell and an empty cell, and generate a new table specifically for it. But that doesn’t work so well after damaging the driver. Oops. :slight_smile:

Hi all, first post but long time lurker, and I hope I’m in the right area. First off, I’d like to say thanks to everyone for this wonderful and informative community! I’ve been a member of that other place xD for some years, but more and more I find I spend all that time here now :wink: Also thanks to Simon, ToyKeeper, and JDub for such a stellar product, it feels like a new age in personal lighting when you get something like this in hand for ~$20—kinda mind boggling really. Where do we go from here :partying_face:

I apologize in advance for coming here asking for help, but I couldn’t think of a better resource, and unfortunately I’m wearing my “Dunce” cap as far as figuring this out on my own, even with the powers of Google at my disposal :person_facepalming:

Just got this (Convoy C8 clear with new firmware—exciting!), and it came already in configuration mode when first powered on. I was able to select and set it to my desired preference (Mode 2, no memory), but I can’t get out of configuration mode. When I turn the light on, it will always initiate Configuration (flash once, buzz; for mode selection), then (flash twice, buzz; memory selection); afterwards I can switch from low to medium etc. I can’t get the flashlight to turn on as a typical flashlight as indicated in the beginning of the flowchart, only powers on from Configuration mode onward/downward.

Can anyone kindly help “enlighten” me as to what I’m missing? I’ve tried both full click after selecting Mode 2, and half press (tap) after selecting Mode 2. Primarily focused on terminating with full click, as indicated in flowchart, but after a dozen or so tries I felt like I was repeating the same exact behavior and expecting a different result… I played with it for the better part of an hour, eventually asking my wife to point out what obvious error I’m making (she’s usually pretty good at that ;D). after showing her the text description and flow chart (love that flow chart btw! makes so much sense it should come standard). Also tried manually entering configuration mode via 10+ clicks, although results appear same.

The UI guide as posted by JDub in post #2, and also post #275 also by JDub specifically on selecting Mode 2, have been very helpful selecting Mode 2 and the best descriptions I’ve seen aside from the flowchart, but I still can’t figure a way out of configuration mode. I have also tried removing the battery, and switching batteries (pro/unpro, flat/button), and various forms of meditation :smiley:

I hope I don’t come off as too much of a bother or too confusing, I think both are really stunning, and considering the price it’s quite bewildering the value! I am very excited to see the new firmware released on the rest of the Convoy lineup. Please don’t take my request for advice as an indication that the UI is difficult, because it all ‘flows’ nicely as the flowchart would indicate, and I’m very sold on the idea of user configurable UI, but I could use a note included on how to Exit Configuration :disappointed: You may have made it “idiot proof”, but I guess I’ve developed a “better idiot” :person_facepalming: Thanks in advance!

edited to add:
TL;DR
Can successfully select mode and memory, but can’t exit configuration. Any advice? Thanks!

I’m going to piggyback on Backpack NY’s post to say I received a defective Clear C8 today. Mine is stuck in what I can only assume is .1% or 1% mode. When I first tried the light, all was working perfectly. I followed directions to set it in mode 10. When I turned it back on, it’s stuck in the lowest setting. No amount of short taps or turning it off and on will change the setting. Always dim. I found another post where this had happened to an S2+ using biscotti firmware, but there was no remedy for the problem in that thread. I have tried three different INR18650-30Q batteries. Same results each time.

Edit to add I also enabled memory before the light became stuck in dim mode.

That’s exactly why we sent new code to Simon. Basically, your driver has a few atoms flipped the wrong way. It’s like flipping a coin 8 times and getting tails every time — rather unlikely, but can happen with particularly bad luck. The updated code makes it take a larger sample to avoid this, basically like flipping a coin 16 times, at which point it’s nearly impossible to get all tails.

It can be fixed by reflashing the driver, but that is admittedly quite a pain if you’re not already set up for it. Requires a soldering iron and usbasp device with a SOIC8 clip. The code and .hex file are at the link below, and more info about the hardware and setup are a few levels up in the “README” file:

http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/convoy/files/head:/ToyKeeper/bistro/biscotti/

There are also several other interfaces available if you like those better. I put a new ramping UI on mine which gives access to 64 levels from moon to max, though I don’t have it quite ready for widespread use yet.

Edit: Oh, er, also requires a knife, to cut a trace on the board. On this first version of the driver, an unused pin (5) was connected to ground, which interferes with reflashing. Rather annoying, that. It was one of a few unfortunate surprises between prototype and production. But the new batch of drivers should have this fixed, and moves some other components a bit to make SOIC8 clips fit easier.

That is sound nice. Did you do ramping with clicky switch? That would be great for me! :+1:

Wow! Thanks for the quick reply and thoughtful answer, and direct from “The Goddess” no less! :blush:
My wife and I are in awe of you. Truly amazing capability and generosity in your work! Communities and technologies excel thanks to people like you :wink:

I wish I could say I was capable of reflashing the driver. Biscotti looks so well thought out I wish nearly all my flashlights were such :heart_eyes: I can only imagine how thoughtfully designed your other firmwares are for a given task or array 8) . I would love to learn reflashing one day, but admittedly it’s a ways beyond me. I’ve had your repository bookmarked awhile already now, for future reference in hopes I can understand and apply it one day haha. I’ll shelve this one for now, unless an outdoors buddy doesn’t mind it, and look up what it takes to reflash a driver for when I can pick up a new hobby. For now, please excuse me while I do what I should have done in the first place—order directly from Simon—good excuse to kindly request him to flash Biscotti on an M1… and S2+… and… oops, better sort this before I get anymore ideas :smiling_imp::slight_smile:

Again, thank you for the advice, and especially for all your great work!

Yes, it’s a ramping UI for clicky-switch lights. It works on Convoy drivers and nanjg drivers and, really, pretty much anything. I haven’t actually tried it on a FET+1 or FET+N+1 yet, or on an attiny25, but the framework for those is already there.

You can try it if you like, but it’s not really mature yet:

http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/sandbox/files/head:/ToyKeeper/crescendo/

The ui.txt file describes how it works.

I will try it tomorrow too :smiley:

I will try it today in my 3,5A M1. Thank you!

I tried it on one of RMM’s MTN17DDm FET+1 tiny25 drivers. It works, and the ramp is really smooth when I increase it to 128 steps. With a tiny25, there’s also plenty of room left for extras. I managed to fit it on a tiny13 FET+1 too, but I had to decrease the ramp to 56 steps and turn off some extras. Not as smooth and not as fancy, but it still works fine.

Oh, um, I also got LVP working. No thermal regulation yet though. I’ve been avoiding thermal regulation because I need to totally rewrite the algorithm from scratch and it’s a huge pain to test. And because I don’t really use it myself; I just manually adjust brightness when things get hot.

My driver in the M1 is a new version but green PCB Convoy labeled driver. I cutted the PIN grounding trace which blocked connecting the MCU. And currently running on Biscotti. I read the txt file and I really like how it works.

Works for me TK,

Clear C8 with a Noctigon under an XP-L W2 2B with 4 extra chips stacked on a red Convoy 8 chip driver, 30Q cell rested at 4.15V…

0.01A for 2.622 Lumens
0.05A for 28.221
0.47A for 178.71
1.89A for 624.105
4.89A for 1459.15

Timings are right, easy to enter configuration, enough time on the blinks without being too much.

Wait, what? You’ve got ramping working on a clicky switch?

I just built an MTN FET driver (no chip) for a triple XHP-50.2 that’s making 11,696 lumens, sure would love to have it ramp! :smiley:

I’m about to put it into an actual light for the first time, but I’m waiting for a cell to drain so I can calibrate the voltage. I had a spare S2+ (blue) with triple XP-G2 in it, so I gave it a new MTN17DDm with tiny25 and I’m putting Crescendo on it as soon as it’s calibrated.

Was surprised to see the 7135 activation level. It doesn’t light up until 5/255, even though an older MTN17DDm was working fine at 2/255. Not sure if it’s a difference in the new driver or just random luck. The voltage values seem different too.

After using it in a real light for a bit, I might tweak things more. Like, while waiting, I made it so there’s a way to go backward from turbo back to the memorized level. Seems a bit finicky though; still need to mess with it.

Very cool on the ramping. Given the difference between the number of steps between tiny 13 / tiny 25, does that effect the duration, in time, for the off to ‘full on’ ramping function? Just curious.