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.
Here is the H2-C Schematic for anyone who was waiting.
Here is the first revision of a schematic for my own boost driver. I decided to go with the MP3431 instead of the MP3429. They are basically the same chip but the MP3431 has an optional input current limit pin if we want to set a limit below the 21A switch limit.
I’d like others to look over the MCU circuitry and see if I am missing any critical features we might want. Right now I have included both a driver mounted thermistor and a port for an external thermistor, as well as a port for a momentary switch. Then we just have battery voltage input. Once I get the schematic mostly finalized I will start trying to lay out the PCB.
I hope you are able to complete this project successfully. There is a need to advance the hardware of BLF drivers to catch up to the wonderful firmware available. Unfortunately this wonderful firmware is limited to mostly linear drivers at this point in time.
In your schematic you have an ntc resistor as well as ntc resistor port. Will this give the firmware two separate thermal data points to control temp? Or just one or the other?
Hardware will support both, so really it’s up to the software. Supporting both at once was the plan though, at 20A input current the IC will be shedding a lot of heat so driver temp may become important.
Very nice! I just had this image in my head of a graph charted and recorded by an MCU. Then able to load that information back to a computer for easy observation of heat flow. Or an MCU in calibration mode that monitors the heat flow on any given level and calculates the best thermal performance for that particular setup.
Edit: After reading this, it sounds the same as what BLF firmware is already doing. However, it’s different in my head anyway. Maybe just more detailed and more complicated than needed. :person_facepalming:
Noob question :
The lower resistance the sense resistor is the higher the output ?.
I was changing the emitter in my C8S and damaged the sense resistor, I don’t have a R025 but I have a R018 but I think that’s a to low value making the driver over heat?
Correct. R018 may be a bit too low unless you have a good thermal connection between the driver and the host.
Thanks for the fast reply.
I went ahead and changed the resistor to R018 and the driver works 
.
It steps down fast and starts to blink, but at least it works. I don’t know if I damaged something else when I shorted the reflector but I will try to find a higher value resistor and see how that works out.
Just the fact that I made it work again I consider a victory I am more of a solder two wires kind of guy.