Power delivery redesign

[darraghbr]

Now we have identified a number of fans that can deliver the required airflow we can now develop our power delivery circuitry to support it.

One of the fans we have identified (CUI CBM-979533B-154) can deliver the 4 CFM target but only for about half of the battery life, once the battery voltage drops below ~11V the fan can no longer deliver the required flow rate, these tests can be found in https://github.com/tetrabiodistributed/papr-print-files/issues/150

Our other option is to use the bigger brother of that fan (CUI CBM-979533B-168) which can deliver the required airflow at all usable battery voltages.

There are multiple options ahead of us, including using a higher voltage battery or a boost converter circuit with the -154 fan.

However the percieved path of least resistance is to use the current battery system with the -168 fan and accept the loss of runtime (~2 1/2 hours as opposed to 3 1/2 hours)

We need to replace the polyfuse on the board to increase the current carrying capacity and potentially rethink the way we do the reverse polarity protection circuit.

A new version of the firmware will be required to better control the CUI fan.

The BNC connectors should be checked to ensure sufficient current carrying capacity.

[mechatroniks-git]

The go-forward path would be:

• [ ] Replace 2A reverse polarity diode with this circuit
• [ ] Change fuse to 1812 2.6A
• [ ] Add ability for ATtiny to sense current or wattage being delivered to blower

OR

• [ ] Add TPS259472ARPWR to provide all of the above

[mechatroniks-git]

If we were to use an eFuse, which @darraghbr had brought up prior, one chip (with caps and resistors) could replace the fuse and reverse polarity mosfet circuit, while giving us reverse polarity, over-current, under and over voltage, and over-temp protection, all for ~$1.50, but not available at JLC.

https://www.digikey.com/en/products/detail/texas-instruments/TPS259472ARPWR/14124020

[darraghbr]

I believe it can also provide a current monitor signal as well, bottom of page 38 on the datasheet. If there was a package we could easily hand solder I'd say go for it. What are your thoughts @mechatroniks-git ?

[darraghbr]

It's also a really bizzare looking footprint. I wonder how they get away with such a tiny little GND pad.

[mechatroniks-git]

Well @darraghbr, it solves all the design issues, but we complicates the assembly, as JLC won't have it. We would have to make them elsewhere, but It's worth a try.

Yea, the ground pin can be small as no current should be flowing to ground it under normal operation. It will go from IN to OUT. During fault, it should shut it all down.

[darraghbr]

Ah ok, that makes sense, I was mainly thinking from a thermal point of view.

Alright do you want to edit the check boxes to add this in?

[darraghbr]

I think we want to select from the bottom two models as they work as a circuit breaker rather than trying to limit the current? The only way we would get an over current is from a short somewhere?

[mechatroniks-git]

Seeing that only 2 flavors of the chip are available:

• there are ~5000 of the TPS259472ARPWR - pin selectable overvoltage, currentl limit, auto-retry on fault (plus 10K at factory)
• there are 150 of the TPS259474LRPW - Circuit breaker, latch off

The decision will likely be the more available one. Pads are the same, so I'll design in the chip.

The neat thing is we can use the active current limit to control the max power to the fan, if we wanted to keep it at a certain wattage, although we can do that in the micro by setting the max PWM duty cycle.

[darraghbr]

Makes sense, I have had a first stab at the design calcs and I will send you the spreadsheet via DM.

[mechatroniks-git]

Library Symbol vs Datasheet

[mechatroniks-git]

Footprint

[mechatroniks-git]

Schematic roughed in, values of R & C TBD for now

DRC errors need to be cleaned up, it doesn't like the clearances.

[mechatroniks-git]

Schematic for review attached. Still need to specify R & C values for E-Fuse.

Papra v0.6 - preliminary for review.pdf

[darraghbr]

Page 59 of the data sheet:

"For all applications, a ceramic decoupling capacitor of 0.1 μF or greater is recommended between the IN terminal and GND terminal."

I'll keep looking and update this comment with anything else I find.

[mechatroniks-git]

Good catch, updated schematic: Papra v0.6 - preliminary for review 2.pdf

[darraghbr]

I've had a crack at using the spreadsheet to get some intial values, any ones I'm really not sure about have a question mark after them.

These are the main inputs that I have used, I don't know what the load capacitance is (not very much considering it should be mostly inductive?) or the load at startup so I left them both default.

[mechatroniks-git]

The battery when discharging will tolerate 2.5V/cell x 3 cells = 7.5V per datasheet. In software, we shut down at 2.8V/cell = 8.4V. With the 3% tolerance, we should set the UVLO Set Point to 8.15V, instead of 9V.

We have 11uF worth of caps at the input to the voltage regulator (c1 + c4). Being that we turn on with delays in code to startup, that will be the only capacitance this will see.

C7 can be fairly low since we have a stiff supply (battery just a few mm away) and shouldn't see much voltage droop. We don't need 470uF, I'd leave it 1uF and rely on that 10uF tantalum to deliver.

[darraghbr]

Makes sense with the lower cap value.

Changing the UVLO set point down to 8.15V. With the closest resistor that gives us a undervolt set point at 7.4V on the VIN falling threshold (seems low)

Because we aren't so interested in the VIN Rising threshold does it make sense to bump R2 to 75K which would give us a VIN falling threshold of 7.99V?

[darraghbr]

Also holy vias batman.

[mmroden]

Reopening because we haven't physically tested that the fix works

[mmroden]

Boards are in hand, digikey on Monday, Stencils on Tuesday, lots of tiny soldering, so there's a risk that we can't get the fused circuitboard

[mmroden]

Patrick has build 3 boards, visual inspection has fail, fail, maybe pass

[mmroden]

Should eventually take to a build house, very difficult to do by hand. $1k/run, but at least 100 boards per run, maybe up to 250 boards.

[mmroden]

Looking like best case scenario now is 1 board that's passing visual inspection, other two are likely broken from overwork. May require a microscope for further work.

[darraghbr]

@mechatroniks-git What do you think the issue is? Is it getting that weird eFuse package soldered properly?

[mechatroniks-git]

Mostly a manufacturing issue, due to inability to see solder blobs on the .35mm pitch QFN package. Shorts have been removed, but power up was not successful. Will debug more later.

[darraghbr]

That's a shame, it would be nice to get one working just to prove that we can and to de-risk a larger batch that we can get a boardhouse to assemble. We could also park the eFuse board as a fork and then once we are happy with the boards work the eFuse back in for a larger production run.

[mmroden]

dv/dt change (instantaneous voltage spike on powerup) is causing issues.

[mmroden]

sorry during runtime.

[mmroden]

Continued in issue #59