Page Comparison

https://university-of-waterloo-solar-car-team.365.altium.com/designs/4CDFD99A-AAE8-4765-A5CD-FDD08CF73953?variant=[No Variations]#design

...

• used a Rev 3.0 PD assembled as rear

• used a one 12V nocuta fan

• used an electronic load as a substitute for horn (set to 3 ohms)

• firmware: anytime I refer to power_distribution from firmware, it is under the pd_smoketest branch

• two separate power supplies (, one for PD , and one for UV cutoff), both supplied with 13.5V

U2 IS NOT POPULATED CURRENTLYFROM HERE ON OUT

Testing Fan and Horn

First I tested the horn with a power supply; I simply soldered two wires to both terminals (I’m pretty sure the horn is not polarized) and I set a power supply for 12V with a 5.0A limit.

...

Once I powered on the power supply, the horn didn’t make any noise. So I turned of the supply and incremented the current limit by 1A. I repeated this process until I got to 9A which was when the horn started blasting very loudly (be prepared to turn it off). I then turned on the supply again and waited for about 3 seconds to see the current draw of the horn, which was about 4.7A → the horn has an inrush of 9A and then it will draw 4.7A.

You can try I tried taping the opening of the horn to reduce the sound, but it will was still be very loud and it may vibrate as welleven vibrated.

So instead of continuing to use the horn to test UV cutoff, I used an electronic load set to 3 ohms

...

I then powered off UV cutoff and plugged in the fan into a different plug; I did this until I confirmed that all fan connectors work.

Testing fan enable and horn enable

This section is for making sure that I didn’t mess up the 6-pin harness that connects both UV cutoff and PD together.

In the smoke_test.h file under /powerdistribution/inc/, I first commented out FRONT_OUTPUT_FAN.

...

Then when I powered on both UV cutoff and PD, I checked to make sure that neither one of the four fan connectors would spin a fan. I was able to see that the electronic load was drawing about 4.1802A and the voltage for each fan connector was around 0.0004V (very close to zero).

Test point readings:

Then I commented out FRONT_OUT_HORN (and uncommented FRONT_OUTPUT_FAN). Then when I powered both boards, I checked to make sure that zero current/no current was being drawn by the electronic load, which happened (the terminals of the horn was also 0V). Also each fan connector was around 13.488V.

Testing UV lockout/cutoff function

I first powered PD with 13.5V, and then I powered UV cutoff (connected with a fan and an electronic load set to 3 ohms) with 13.5V using separate power supplies.

...

Now I decided to decrement the voltage for UV cutoff by 0.1V (starting at 13.5V). I found out that the board “locks out/cuts off” at 8.7V (the fan stopped spinning and the voltage of the electronic loaddropped load dropped to zero). When I decremented the voltage to 7.8V, that’s when I got the “UV lockout was triggered” message.

I then incremented (by 0.1V) and the fan started spinning once the voltage reached 10.2V (and the voltage of the electronic load went up to ~10.176V).Voltage readings (IGNORE)

Validating UV_VBAT_I_SENSE

While UV cutoff was connected to PD, I decided to measure the test points:

UV cutoff

...

powered on:

...

...

UV cutoff powered off:

...

...

...

UV cutoff is turned off

...

VBAT_I_SENSE: 3.2840V

...

FAN_I_SENSE: 0.0004

...

In both situations, it doesn’t make sense that VBAT_I_SENSE is about 3.27V.

Another problem I have noticed while running the power_distribution firmware is that the current displayed in minicom was around 4000mA for these situations where:

...

• UV cutoff was powered on and connected to PD

• UV cutoff was powered off and connected to PD

• UV cutoff was powered off and disconnected from PD

This gave me reason to believe that the issue wasn’t from UV cutoff but from PD instead. With UV cutoff disconnected, I powered on PD and measured its UV_VBAT_IS pad/pin/trace, which was about 3.276V. This voltage matched the VBAT_I_SENSE pad/pin/trace on UV cutoff when UV cutoff was connected to PD, even when UV cutoff was powered off or powered on. Because the UV_VBAT_IS trace on PD only connected to U11, I then decided to measure the voltage at each pin.

...

U11 of PD (while UV cutoff is disconnected):

As shown in the above table, every current sense pin is very close to zero, where as pin 16 (UV_VBAT_IS) is almost 3.3V. I decided to check for a short (using a DMM) at this point but I didn’t hear an audible “beep” - I should’ve been looking at the resistance on the screen of the DMM because it would have saved me time from doing this next section of modifying code.

The original PD code was configured such that every 0.5s (maybe 1.5s), U11 will be quickly flip through all the mux selections (which are the current sense pins). That is the output of U11 (pin 1) should have the same reference voltage as the selected/muxed pin.

...

So now I wanted to try muxing a pin other than pin 16; I did this by modifying current_measurement_config.c file located here: firmware_xiv/projects/power_distribution/src/

Since minicom automatically detects the PD as a front variant, I decided to comment out all of the rear_current_measurements.

So I decided to test FRONT_OUTPUT_SPEAKER with UV_VBAT_IS. First I muxed FRONT_OUTPUT_SPEAKER:

...

FRONT_OUTPUT_SPEAKER left uncommented:

As you can see from the table, pin 1 matches pin 4, by my even if pin 4 is being muxed, it is nowhere near 3.3V. Also pin 16 is around 3.3V.

Then I tested all pins off:

...

All outputs commented:

You can see that pin 1 drops closer to zero, but pin 16 is still near 3.3V.

Then I muxed FRONT_OUTPUT_UV_VBAT:

...

FRONT_OUTPUT_UV_VBAT left uncommented:

Even though pin 1 is about 0.5V less than pin 16, I still assumed that pin 16 was being muxed - which doesn’t change the fact that pin 16 is still near 3.3V.

...

At this point I decided to check PD again for shorts between 3V3 and pin 16, but there weren’t any definite locations since the UV_VBAT_IS trace directly connects to pin 16 of U11 (i.e. there are no other components in between).

So using the DMM again, I probed a resistance roughly 25 ohms between pin 16 and 3V3. I also tried measuring other current sense pins with 3V3, and their resistances were in the Megaohms - this meant that there was an issue with the soldering of U11, the board itself, or U11 itself. There were no visual bridges between the pins of U11 and the likelihood of the board being the issue itself is very unlikely, so I decided to take U11 off with a heat gun. I then probed the resistance between pin 16 and pin 24 (the 3V3 pin of U11) and I measured the same resistance of 25 ohms. I also probed the resistance between pad 16 and 3V3 on PD just to make sure it wasn’t the board’s fault (I got a zero load). This confirmed that there was an issue with U11 all long.

I replaced U11 with the same component from an old rev PD and to double check that there aren’t issues with this newly replaced U11, the voltages of the pins are as follows (resetting the power_distribution code to its original state):

(UV cutoff disconnected):

TO BE EDITED:

...

IS pin was: 0.0033V

• other IS pins from other load switches were: 0.2501V (U5), 0.1498V (U1)

DEN pin was: 0.0404V

• other DEN pins from other load switches were: ~2.67V

Problem:

• R24 wasn’t soldered down properly (connected to IS pin)

• R22 wasn’t either (connected to den pin)