New Convoy C8 – Clearly better

I got it, compiled/built in AS 7.0 -

Program Memory Usage : 1000 bytes 97.7 % Full
Data Memory Usage : 16 bytes 25.0 % Full

Will be testing moon mode and the voltage reading shortly. Got a couple of the new drivers, trace cut to be able to program.

I'm assuming the headers come from working up the tree, the tk-calibration.h file dated July 4th 2016?

I see the moon mode lighting up (uses PHASE PWM value of 1), but the voltage values seem off a bit. Readings are generally higher, but in the low range, 3.1V reads as 3.3V. I enabled full n.n blinking to test it with real batteries.

I use 4 tables: for 19.1K and 22K R1's, and then with a diode before R1 or after R1. With these 2 variables you get 4 possible sets. Mine I've tested extensively. These should be the only variables effecting it, though I'm not familiar of what the impact is of a bleeder resistor.

These Convoy drivers use a 19.1K resistor (labeled 28C) and have R1 after the diode. So my table for this configuration seems to match up better on this driver. Here's your table:

#define ADC_44     194
#define ADC_43     189
#define ADC_42     184
#define ADC_41     178
#define ADC_40     173
#define ADC_39     168
#define ADC_38     163
#define ADC_37     158
#define ADC_36     152
#define ADC_35     147
#define ADC_34     142
#define ADC_33     137
#define ADC_32     131
#define ADC_31     126
#define ADC_30     121
#define ADC_29     116
#define ADC_28     111
#define ADC_27     105
#define ADC_26     100
#define ADC_25     95
#define ADC_24     90
#define ADC_23     84
#define ADC_22     79

Here's my table for R1=19.1K after the diode:

#define ADC_44     192
#define ADC_43     188
#define ADC_42     184
#define ADC_41     180
#define ADC_40     175
#define ADC_39     171
#define ADC_38     167
#define ADC_37     163
#define ADC_36     159
#define ADC_35     154
#define ADC_34     150
#define ADC_33     146
#define ADC_32     141
#define ADC_31     136
#define ADC_30     132
#define ADC_29     128
#define ADC_28     123
#define ADC_27     119
#define ADC_26     116
#define ADC_25     111
#define ADC_24     107
#define ADC_23     103
#define ADC_22      99

Notice they are close/exact at 4.2V, some difference at 3.6V, and by 3.1V, they differ quite a bit, and that's where I'm seeing the biggest difference in your table on the Convoy driver: a 3.1V cell blinks out at 3.3V.

Ohhh - also ran into a compile problem when enabling full n.n blink out. I made this change:

#define BLINK_SPEED (187) // 2017-03-17 TE: this was 750/4

It didn't like the 750/4 because it did the math as a 16 bit value, then truncated to a 8 bit value. Also made this change:

_delay_4ms(252); // 2017-03-17 TE: This was BLINK_SPEED*3/2

because of the same reason. Not sure if it's the Atmel VS 7.0 compiler, and just happening under Windows, or not. Had to disable bike strobes, SOS, and remove some mode sets to get it tot fit in 1024 bytes, but it works!

Edit: More info. I tested moon mode across 2 of the driver versions: 6 7135's (2.1A) and 8 7135's (2.8A) and on 3 different cells at 4.1V, 3.6V, and 3.1V and all combos worked fine.

Also -- I had to slow down the blink rate of the n.nV blinking in half because for some weird reason, I just can't count blinks going that fast - I can't. I tried many times, and just can't tell the difference between 6 blinks and 7, and it's even a little hard to see the difference between 2 and 3 blinks. Once slowed down, no problems counting then at all.

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: