New Convoy C8 – Clearly better

Where to buy those W2 emitters?

Got mine today from Fasttech. I was worried that it wouldn’t come with the new firmware, but it did :slight_smile: I set it up with 5 modes, no flashing modes, no memory. Starts up on turbo. I like it, I like it a lot!

I have some C8s on the way. I just installed one of the new drivers from BG into an Ultrafire zoomie. V6 0D XPL. Driver works great. Used #2 with 5 modes. Very nice zoomed in. Definate improvement for the C8. Started with group 1 and the blinkies. Versatile 8X driver!

I realize this thread has been idle for a while. J-Dub74 arranged with Simon to send me a handful of these new drivers to trouble-shoot, the red ones, running Biscotti which are fast. I got them, think Tuesday, and last night made some progress. There were 5 drivers sent in various 7135 configurations - I verified all had the fast speed symptoms (high frequency strobe, fast bike strobe, etc.). I pulled the C1 cap off of one and verified it's good - in the 10-12 uF range. Then I was able to read back the fuse settings and firmware from one of the 13A's (removed from the board), using this AVRDude command:

avrdude -p t13 -c usbasp -u -Uflash:r:flash-dump.hex:i -Ueeprom:r:eeprom-dump.hex:i -Ulfuse:r:lfuse-dump.hex:i -Uhfuse:r:hfuse-dump.hex:i

as specified here: http://flashlightwiki.com/AVR_Drivers

and the low byte value was set to 0x7A (9.6 Mhz), not 0x75 (4.8 Mhz), so what TK and others speculated was correct - the fuse settings were set incorrectly, causing the 13A to run at double it's normal speed, the speed the firmware was expecting it to be.

This is what the fuse settings are:

http://www.engbedded.com/cgi-bin/fcx.cgi?P_PREV=ATtiny13A&P=ATtiny13A&M_LOW_0x0F=0x0A&M_LOW_0x80=0x00&M_HIGH_0x06=0x06&B_SPIEN=P&B_SUT0=P&B_CKSEL0=P&V_LOW=7A&V_HIGH=FF&O_HEX=Apply+values

This is what they should be:

http://www.engbedded.com/cgi-bin/fcx.cgi?P_PREV=ATtiny13A&P=ATtiny13A&M_LOW_0x0F=0x0A&M_LOW_0x80=0x00&M_HIGH_0x06=0x06&B_SPIEN=P&B_SUT0=P&B_CKSEL0=P&V_LOW=75&V_HIGH=FF&O_HEX=Apply+values

J-Dub74 is relaying this to Simon now, so hopefully they can get it fixed.

I'm gonna do some more testing with them to get a better understanding of why they have been hard to re-program for one thing. The C1 cap and D1 diode are a little too snug up to the 13A, so the common Pomona clip a lot of us use doesn't make good contact on the 13A pins. I have a black clip that appears to fit fine, but still has a problem making a good connection.

Checking the Ali store, Simon has sold an insane amount of these drivers here, in a short time, like 272 orders as of now. Dunno if they were all going out with this problem or not.

Tom, thanks for the update! Planning to order a clear C8 as soon as it’s sorted out.

I haven’t noticed any problems with my clear Convoy C8 with the new firmware. Am I missing something? I set the program I wanted and have no plans on changing it. 5 modes with no memory starting off on turbo. No strobe or any other flashing modes.

Uhh, dunno all that has transpired. If it's the double speed firmware you have, and you don't use the flashy modes, then the PWM's are running super fast, and probably not running efficiently - not at the output levels TK expected. Also the moon mode might not work when the battery gets low - not sure of that though. Yea, in your case, not much noticeable. On turbo/max, there's probably no difference at all.

Tom, I have no idea if I have the double speed firmware or not. I’m not all that sensitive to PWM. Funny thing is, I hate plasma tv’s because I see flickering on white backgrounds when my friends don’t see what I see with them. Go figure! I’ll run the battery run low and see if the moon mode still works. I’ll report back.

The new Convoy firmware/driver in my three S2+ are all running faster than intended. Though I’m not complaining as I prefer the higher output medium modes. Changing mode groups requires fast reactions though!

Thanks for checking that. I’ve been (and still am) a bit overwhelmed with other things…

In any case, the super-fast drivers should mostly work fine… as long as you don’t mind the blinky modes going 2.3X faster than spec. And, as mentioned, moon mode might be more voltage-sensitive than expected. Battery life might be a few percent less than expected too. It’s not recall-worthy, but it’s still unfortunate. Change just half a byte and it’ll behave as intended.

Glad you were able to track it down, Tom (and that it’s something easy to correct)

Mine seems to have crashed. I was exploring the mode groups, options, and taking measurements. While I was switching to another mode group something messed up and now it’s stuck in a single, sub-lumen, moonlight mode.

Config can no longer be accessed.

…and I thought it was me. Yes you have to be fast at config but it certainly is an improvement. I’m satisfied and hope others are well with it.

If Microsoft made flashlights…

Microsoft? I though VW had something to do with this? :stuck_out_tongue:

Made a bit more progress this evening. Read back in the fuses and code of two more of these drivers, so all 3 read in so far have the low fuse byte set to 0x7A.

Also I see that pin #5 of the MCU is grounded on these drivers, making it grounded to pin #4 as well. No idea why they did this, but if I cut the trace to isolate pin #5 it seems then I can connect up to the MCU with the USBASP programmer -- this worked on two drivers so far. The black clips seem to have better side clearance than the blue Pomona clips. On some boards though, the R1/R2 resistors can get in the way of the black clip, but not sure if it's enough to not connect.

I'll post pics.

I often wonder why they (manufacturers) choose to change things that work good for the worse without any apparent reduction in cost…

It’s probably just a personality somewhere, see’s something he wouldn’t do that way, changes it, moves it on all smug in his decision and whatdyaknow, doesn’t work. Power play, more or less.

Ok, feeling much more confident now that the grounding of pin #5 is why we cant get the USBASP programmer to flash firmware. I had the pin grounded on one driver - repeatedly tried, but could get it to connect. I was able to cut the trace from pin #5 clean, and now I am able to connect both with the black clip and blue clip.

the MOSI signal used on pin #5 by the programmer is pretty critical. MOSI is output from the USBASP, and MISO (pin #6) is serial input to the USBASP.

Interesting on a 105C, pin #5 is Star 2, so if Star 2 is grounded, same problem I'd think. For Star 3 and 4, they are not used by the USBASP.

This shows where to cut the trace on pin #5. It's tricky, because you still need GND connected to the 4.7k resistor:

Might be hard to see here, but this driver below has the trace cut, but I also cut in between the 7135 GND on the right and the 4.7K, so, had to add a jumper to the 7135 above. I flashed the low byte fuse to 0x75 on this one and all is working properly so far on the bench. Timing of strobes is corrected.

Need to install this in a light and bang on it for a while.

Dunno bout the other problem of getting stuck in a moon mode - hard to relate that issue to this one. It seems like the EEPROM got corrupted, but that doesn't explain it all. Really it should not be run at that high of a speed though - makes the config UI difficult at a minimum.

I'm kind of amazed so many of these lights and drivers have been sold with this flaky fuse setting. The driver with this firmware is a great deal though.

Excellent find Tom! I opened up my clear C8, and even with additional 7135’s stacked I was able to slice that trace to separate pin 5 from ground. Now the timing works fine, changing modes is as it should be. I had already re-flashed the MCU so now all is well. Thanks for finding this, such a simple thing to do to get the firmware fully operational on this light. :wink: