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?
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.
If new firmware is written it would not be too hard to wire any mcu to the existing circuit using breakout board and hard wiring that board into the circuit.
Yes, would be nice to avoid that an just be able to have the MCU properly soldered to the board, though. Putting something like an ATTiny45 on the board would not be too difficult, only a few traces to modify and re-route. May not be worth the time when RMM is releasing his own version soon though.
As for my own designed driver and MCU selection, I think I will go for the Tiny1616 even though it does not have great availability yet. Digikey does have ~1500 in stock, and the MP3429 IC is not readily available yet anyway. I/O wise I probably only need about 4 pins, so any of the newer QFN chips is overkill, I would do a super tiny QFN12 if they had it.
I don’t plan to commercialize it, but with the MP3429 IC hot air or reflow oven is a requirement to solder it anyway, so going with similarly difficult peripheral devices is not a big deal IMO. Keeping it smaller is a bigger priority for me. I’m shooting for a 17mm version, with 20, 22, 30, 32 all available, and better heat sinking for the IC as size goes up.
One thing to think about, you may not need more in out pins right now but revisions and advancements in the future would be possible with more pin options.
The 20 pin QFN package should give more than enough future expandability. I have thought about future development, part of the reason I decided I will stick with the 1616, I want to use the newest generation of MCU I can. Really I would love to go with an MSP430, but I want to take advantage of all the great work the UI gurus have put in, so will stick with ATTiny.
