CNQG Brass AA light

LED Flashlights – General Info 1 x AA / 1 x 14500 Flashlights
1

Hi, I just got some CNQG brass AA lights (as announced by Ric here). It’s probably best known by this picture:

For what it’s worth, here is my own size comparison for it. From left to right, they are: Convoy S7 w/ clip, Cypreus Tri-EDC (copper) w/ clip, original 18650 CNQG Brass Beauty, 1xAA CNQG Brass light, L3 L10. Aside from the small size (roughly on par with a L3 L10!), it also shows the difference in color between aged copper, aged brass, and shiny new brass.

They’re fairly decent as-is, but I’m hoping to mod them. Ideally, custom firmware and a Nichia 219B emitter and probably some diffuser film on the lens.

First, the light is small and pretty and works well on Eneloops. I haven’t tried a 14500 cell, since the spec sheet doesn’t indicate they would be compatible.

I got three units, because Banggood had a good sale on them. One uses XP-G, the others use XP-G2. I think the tint is 2C (~5600K), though it wasn’t specified. It’s a bit cooler than a 3B and slightly warmer than a 2A.

What I can’t figure out is what the MCU is. It’s not a common attiny13a so it won’t be able to use the common firmwares BLF has made, but I don’t know what it is or if it’s flashable. I see two 6-pin chips on the driver:


Any idea what kind of chip is controlling it? I might be able to get the label from the sanded-off chip by opening the other two lights, but I’m not sure if they’ll be any different.

If the MCU won’t be reflashable, I wonder if there might be other drivers available in this size (14mm). I think I saw some custom BLF drivers for 1xAA lights, and may need to look them up again.

I measured the lumen output of the two XP-G2 units (my XP-G is still in pieces for pictures), and got the following:

  • Low: 7.12 to 7.50 lm
  • Med: 100 to 110 lm
  • High: 178 to 200 lm

The second light either had a higher charge on the battery or had higher output natively, I’m not sure. In any case, this should give a ballpark idea what the output is… roughly 3.75, 55, and 100. I’d prefer if the medium mode was more like 20 or 25%, and if it had an additional moon mode.

These lights use PWM, and it’s kind of slow and audible. What I measured was:

  • Low: 298 to 305 Hz (varies per unit)
  • Med: 984 to 1000 Hz
  • High: None

The lights each came with a bunch of extra O-rings and a spare lens. This is good, since some of the installed O-rings were broken, and I plan on putting DC-Fix on the lens. And if the size is right, I may have some other uses for the extra lenses.

I’m looking forward to using these as mod hosts, after I figure out what I need to do to change the firmware or the driver. They’re small and pretty and good candidates for some upgrades.

Update: It’s not an MCU, and won’t be reflashable. To change the UI it’ll need a different driver entirely. There are some very helpful posts in this thread, especially #77.

2

Any chance UV light might show the sanded code?

3

As usual, I guarantee that this light does not have an MCU. It’s got a single-level 3W boost controller, PAM2803, and it’s got an IC which generates PWM modes and that’s it. The missing LVP isn’t a problem here for this NiMH/Alkaline/Lithium-primary driver.

How to identify the PAM280x family.

4

Nope, no such luck. I don’t see a label under UV or on the second light I disassembled.

I find it curious though, how one of the six pins appears to not be soldered. It’s like that on both the drivers I checked.

5

For your modification to the light are you interested in running a boost driver like it has now, or a 14500-only linear or DD driver? Is the stock driver 15mm?

6

Oh, that makes a lot of sense. I wasn’t familiar with those before.

Any idea what that second 6-pin chip is?

It sounds like I won’t be getting a different UI on this unless I replace the driver entirely… and in that case I might need to use Li-Ion unless I can find a suitable boost driver.

The driver is 14mm in diameter.

I prefer to use Eneloops if possible, but if that isn’t an option I can probably find some unprotected 14500s small enough to fit.

Mostly, I want to give it a UI similar to what I’m using on its bigger sibling, the 18650 brass light. I’m not terribly concerned about the brightness of the highest mode, since on a light this size I’d rarely want more than 50 lumens anyway. The high end is mostly a bonus in that it would make single-millisecond strobes brighter.

7

There may be nothing to see even on an unsanded chip, take a look at the second picture here: (post#77). As you can see, the modes chip features only an orientation mark. That’s another DQG driver and it appears to be exactly the same BOM and circuit.

8

The second 6-pin IC is a purpose-built item for flashlights, it has a baked-in logic section for generating 3 duty cycles of PWM. Some modes chips have some minor configuration options available via the pins, but in the end they are just a simple [permanent] arrangement of logic gates. See my post #17 over here for a tiny bit more information. I know my examples are awkward, unfortunately it is difficult for me to convey what a big difference there is between an MCU and a simple IC like this.

9

No, it makes sense now. I didn’t see the other thread before; it’s very helpful.

The product page claimed this had an “AK47” driver, which I’ve used on other lights and has an attiny13a. However, it appears to have virtually nothing in common with an actual AK47.

I’ll probably be shopping around for a 14mm driver soon.

10

I was confident that you’d understand the differentiation fairly easily, but for others with less technical understanding I remain at a loss on how to communicate the difference. Maybe they simply don’t need to know.

I don’t see AK47 on the product page.

So the driver is 14mm, not 15mm?

11

Sorry, it was the banggood product page which said this. CNQG didn’t specify a driver type. At least it’s easy to access, since it uses a retaining ring and the pill is easy to pull out.

Yes, it’s 14mm.

12

I laid out a 13mm DD driver with “big” parts recently. It requires slightly special work and is double sided.

13

Would it be possible to rework this circuit so that an Attiny could generate the pwm modes? There are a lot of members that prefer eneloops but are out of luck when it comes to programmable drivers. Maybe someone in the eneloop community with overlap to eagle could take this up and generate an Oshpark 500mA boost driver with 13A mcu?

14

Sorry but quote is not working correctly. That first paragraph above is from an earlier wight post.

15

To me the pinout of the modes IC looks similar enough to an ATtiny10 to get away with it on your stock driver.

  • GND matches
  • PB1 has an output compare, so I assume it can do PWM
  • VCC is in the correct place, although PB2 is also attached.
  • The offtime cap is hooked up to the RESET pin, a problem we discussed in another thread recently. Fortunately there’s plenty of space to cut that trace and airwire the cap across to PB0 which also has an ADC - no problem.
  • ADC will be comparing the cap against Vcc since there is no internal Vref.
16

To fix the quote, insert a space between the end of my link and the end quote tag.

Unfortunately there simply is not space for the entire boost circuit plus the large 150mil ATtiny13A plus the required FET for doing PWM on the output signal. They won’t all go onto one side of a 14mm PCB with edge clearances. (Or without, probably.)

The way these drivers work is they power the modes chip or MCU from the boost circuit, so you can’t use the SHDN pin of the boost controller or the MCU will shut off as soon as it tries to start using PWM! Therefore they use an FET between the boost controller’s output and the LED to implement PWM on the LED which will not affect the MCU’s Vcc beyond making it fluctuate wildly. Apparently the PAM2803 features overvoltage protection which caps the voltage the MCU sees to about a 5.12v sawtooth, see the graph on page 5 of the datasheet. http://www.diodes.com/datasheets/PAM2803.pdf

17

It looks like an attiny10 might be a little awkward since it has no eeprom. There are other methods to remember a byte or two between power-ups though, right?

In any case, just like the 18650 version, the driver is an odd size and will be hard to replace. I guess that’s the tradeoff for being smaller than almost every other light in its class.

18

Interesting that I stumble across this right after ordering an XP-E2 Blue emitter.

Can a BLFTiny10 be used with one or two 7135 chips? Adaptation would be necessary to attain the 14mm circumference, but this should be doable. This would require Li-ion of course.

Would this light be a likely candidate for the Blue emitter? I think it has a 1.1A max drive current, I’m wanting it in a low level application for checking maps and such in the car at night while on the road.

19

Oh, err, I didn’t realize that it had no EEPROM! I see that now. Glancing at the datasheet, it has no non-volatile memory which the firmware (our program) is able to write to. 1 capacitor could easily give 2 modes based on offtime, but I don’t know that the ADCs can be juggled quickly enough to manage 2 capacitors for a 3 mode firmware based on offtime timing.

The ATtiny13A is available in a 10M1 (DFN-10 I think) package which is small enough to fit in the space allotted, but will not fit the pinout at all. A new PCB would be required.

20

About the BLFTiny10, I have no idea. I haven’t researched that driver yet.

For a blue emitter though… why not? You could do a simple emitter swap and use the stock driver with an Eneloop. The output level spacing should be similar to what I posted in the OP, though I don’t know how many lumens 100% would be.

The thing I’m confused about is why you would want to use a blue light for reading maps while driving. A red light would be much easier on your night vision.