Buck and Boost Drivers, Testing, Modding, and Discussion (Pic Heavy)

I also have the KX70 Schematic, and a simple upgrade. Will grab scope plots for KX70 when I get a chance. Here is stock, followed by a simple mod that will keep it regulated, and best of all the PCB supports it!

If we look at pictures of the PCB we can see the 0-ohm jumper to the left of the inductor, cleaning the board up and we see pads for an SOT23 regulator. Also, anyone have any guesses to a compatible MCU?

Don’t mind the big hole in the IC… That’s why we don’t short the output. This driver is back together and working though!

Have anyone managed to connect a e-switch to a H1-A?

I want to remember reading in some thread that it had been done, might have been the H2-C driver though.

I do remember reading about someone getting an e-switch on H1-A or H2-C, they were just shorting power at the MCU for mode changes.

If we rewrite the firmware we have 2 free pins that could be used for e-switch.

That was me, on a H2 - I think I was grounding pin 1, which is probably a bad idea, looking at the diagrams above…

Nevertheless, it scrolls through the modes.

Easy e-switch to change modes:

  1. Raise boost IC's pin 1.
  2. Between the power input trace and the boost IC raised pin, place a normally closed momentary pushbutton.
  3. Finished! :-)

Ild like to here more about converting to eswitch

Did you mean MCU pin 1? A normally closed momentary switch on MCU pin 1 would do what you describe, and is IMO a good option for e-switch on H1-A.

Putting a switch between the TPS61088 Boost IC pin 1 I don’t think would work, as the MCU won’t know power to the converter cycled. It is also very difficult to lift a pin on QFN package parts.

I have noticed an error in the H1-A Schematic, the resistor on Boost IC pin 19 (Ilim) should be 100k not 10k. I also would suggest we go to a 2.5V LDO regulator on both KX70 and H1-A vs the 2.8V LDO H1-A uses.

This would allow us to maintain regulation right down to the 2.7V minimum input for the TPS61088 IC. A big improvement I think we can make with custom firmware is a lower voltage cutoff for the LVP.

:facepalm: LoL! Sort of that, yes. Undercooked reply. :-)

By the way, is there some sort of really tiny latching pushbutton switch? I believe a tail MOSFET switch could be made using 2 × CR1216 cells, but heck…

P.S.:

:THUMBS-UP:

I have a Lumintop Elfin which uses a tail MOSFET switch with a super tiny button cell. SR416 I think.

Working on the drawings for H2-C and I think I finally figured out the Boost IC, I believe it to be a Monolithic Power Systems MP3428.

I realized I was wrong about it being integrated switch, the MOSFET on board is just to between the boosted output and the LED+ terminal, not entirely sure of its purpose, but I will read through the data sheet.

They also feed the ground through 2 n-channel MOSFETs which are always on. Not sure why they did that either. Between these 3 drivers I have had quite a few “why did they do it like that?” moments.

What happens if we put a switch to control the grounding MOSFET gates?

^:)

We get an e-switch H2-C ;).

I also updated my post above, it is MP3428 not MP3429, I checked another driver and was careful not to scratch too much when removing epoxy this time.

For MP3428 we do have a datasheet!

MP3429 would have been a better choice for single cell with its 2.7V input limit, as opposed to 3.0V limit of MP3428, but likely that chip is too new. We don’t even get MP3428A revision. I see H2-C as being primarily for 2S input anyhow, though I know not everyone shares that opinion.

Cheers ^:)

Problem is, because they ran the GND through FETs the heat transfer path is very poor, the whole ground ring is effectively thermally isolated from the circuitry, so heat transfer to the host will be very poor. If they wanted e-switch function the MCU has 2 free pins.

What if the MOSFETs are removed and the contact is bridged well?

P.S.: Maybe do not even need to remove them?

I’m sure this is an ignorant question but…

What would happen if the output signal from the on board MCU were held constant regardless of the sense resistor and An MCU running Narsil were then used to control the ground fets ? I have no idea how that signal could remain constant and I’m sure there would be all sorts of troubles but had to ask cause it would be awesome if this could be controlled by a BLF firmware!

Barkuti:
That would help, although it still wouldn’t be as good as it could be if it were layed out as one pour to start with. Personally I won’t be removing them on my drivers. The heat just is what it is, if they burn out quick I will look for another driver, if they don’t, awesome.

I think I did discover the purpose of having them though. Reverse input protection with ultra low voltage drop. This does however mean they could not have their gates driven to use e-switch, as current would still flow through body diode.

LightRider:

That wouldn’t control brightness unfortunately, the MCU needs to send it’s signals to the actual Boost IC.

It could possibly be controlled by BLF firmware, both H1-A and H2-C share a PIC12F683 MCU, which we are working on getting some custom firmware for. Both boards have 2 free pins on the MCU as well, though in different locations.

There has also been talk of modifying to swap an ATTiny, that would require a bit of PCB modification though.

Looking at the MP3429 IC, I think once it is available to buy I want to try to design a boost driver with it.

It has 2x the input current capability of TPS61088 along with being able to output a higher voltage which suits the XHP35.

It also is fully integrated like TPS61088 so no external FET needed like on H2-C. Basically would be the ultimate compact boost driver for up to 3S input voltages and up to 4 or 5 emitters in series (16V maximum output)

Going to start drawing up a schematic for it now. Any reason not to use the ATTiny1616 instead of ATTiny817?

MP3429

It depends on who you want to be able to build and work with these drivers. AVRDude currently has no support for the 1616 (at least when I check a month ago or so), so flashing them might require an Atmel ICE or similar. Also, the 1616 is not yet in full production if I remember correctly, currently only samples are available. Us in Europe prefer to buy from sources that don’t have crazy shipping costs, and so far the 1616 has not reached these sources. Another thing to consider is the small package of the 1616. It is small enough to cause shorting issues when applying solder paste by hand. However, the 817 will have the same issues as it has more pins. How many pins do you need?

I was previously using the 841 but wanted 16KB for firmware instead of 8KB, so I opted for the 1634 for these drivers: Mike C drivers: v8 series, ATtiny1634 based.
I’ve been using it for awhile and I’m happy with this choice. It’s got 20 pins on the 4x4mm package (no dead DNC pins), 16KB flash space, draws 0.1uA in power down sleep mode if used in a light with E-switch only, easily available and is supported by AVRDude.

So, if the goal is to have people build and flash drivers themselves, then consider looking at the 1634. If the goal is to have them manufactured, then ignore everything above.