New Convoy C8 – Clearly better

The older C8 does not step down, but I don’t think it needs to. I’ve never ran mine for really long periods on turbo, but I can say that it does not get real hot like the smaller S2 lights. The big head really helps keep it from getting too hot. If your still worried, then you can reflash the firmware yourself or else buy a new driver with a new firmware in it that can stepdown.

I ordered my C8 from MTN E and got Richard to flash the firmware to guppydrv. Not only does it have lots of mode options, it also has a user setable stepdown to 50 percent. It’s time based. I use this option on my 7135x8 S2+, but don’t see the need on my C8.

Now if it’s the new C8 with biscotti, I’ll let someone else answer, as I’m not sure.

What the heck are you trying to do?

Thanks for the detailed reply. I’m mainly worried about what would happen if it got turned on accidentally or if I gave it to someone and they just wanted to run it at 100% all the time. Sounds like this may not be an issue.

I do know that GB also stocks a 7135×6 version with the XM-L2 which may be an option too.

I just tried it for you. A new version 8x7135 Convoy C8, without the new firmware, stood on its tail in a room at about 18C, gets noticeably warm but not uncomfortable to hold (about 45C) after 20 minutes. Walking about with an airflow and heatsinking from your hand and it would be less. It’s got the mass of metal and surface area to get rid of the heat so it doesn’t need a step down. The LED is unlikely to be near its temperature limit.

Heat’s more of a problem with tube style lights with 8x7135 drivers which can get too hot to touch and souped up lumens are everything torches which have turbo mode with step down.

As for it being turned on accidentally in a backpack, they have anodised tail cap threads and so if you think there’s a danger of that loosen the tail cap by a quarter turn and it won’t turn on.

I’d guess the 6x7135 option appeals to people who prefer a longer battery life against lumens.

Thank you! This answers my question perfectly.

You also bring up a good point that the 6×7135 config would have a benefit of longer run time too.

It had been previously suggested that to lower the reflector (ie., get the emitter further into the reflector) would provide improvement.

Sorry, I didn’t remember that in this conversation.

You can probably just take the plastic centering ring and rub it on sandpaper to make it a bit shorter.

Take care that you have enough clearance between the reflector and the soldered wires so they don’t get shorted.

I don’t know any details on lowering the reflector for the C8, just on other models. I’ll let someone with C8 experience answer your question.

Keep on mind this thread is mainly about the new clear model and it’s new firmware, not a C8 mod thread.

Any chance someone could flash their red Convoy driver with new firmware and make sure everything works? :slight_smile:

The updated code is here:
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/convoy/files/head:/ToyKeeper/bistro/biscotti/

I managed to break the voltage divider on mine so I can’t check to make sure the values are correct. I’m guessing it should be fine since it’s the same values as before, but I can’t measure it directly until I get a new driver.

Anyway, this is pretty much the same biscotti as what Simon is currently shipping, but with a couple small things tweaked to hopefully make it more reliable and more tolerant of hardware variations. The specific things I want someone to check are:

  • Does battcheck mode give correct values?
  • Does moon mode light up?

If I understand correctly, Simon is ready to produce new drivers with this version if there’s nothing wrong with it.

Does this new version also address the “SRAM decay lottery” thing?

Yes, it should make that about a thousand times less likely. And it should also be tolerant of random eeprom contents (or at least should correct itself after tapping the button a few times).

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.