...
Pin
...
Reading (volts)
...
1: OUT(put)
...
0.0558
...
2: SPARE 2 3 IS
...
0.0001
...
3: STR_PDL_IS
...
0.0032
...
4: SPEAKER/SOLAR_SENS_IS
...
0.0014
...
5: L R DVR DISP IS
...
0.0031
...
6: MCI_IS
...
0.0023
...
7: 5V SPARE IS
...
0.0005
...
8: MAIN_REAR_PI_IS
...
0.0015
...
9: DVR_REAR_DISP
...
0.0032
...
10: PA6 MUX SEL1
...
3.3055 (periodically changes)
...
11: PA5 MUX SEL2
...
3.3057 (periodically changes)
...
12: GND
...
0.0002
...
13: PA3_MUX_SEL4
...
3.3052 (periodically changes)
...
14: PA4 MUX SEL3
...
3.3054 (periodically changes)
...
15: Ē
...
0.0014
...
16: UV_VBAT_IS
...
0.0129
...
17: FAN IS
...
0.0031
...
18: MAIN_DISP/BMS_IS
...
0.0013
...
19: LEFT/REAR_RIGHT_CAM_IS
...
0.0014
...
20: SPARE 1 IS
...
0.0012
...
21: (closed)
...
0.0028
...
22: FRONT/REAR_TURN_LIGHT_IS
...
0.0021
...
23: DAYTIME/REAR_BRK_IS
...
0.0003
...
24: 3V3
...
3.3055
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)
...
July 21, 2021
General notes:
used a Rev 3.0 PD assembled as rear
used one 12V nocuta fan
used an electronic load as a substitute for horn (set to 3 ohms)
anytime I refer to power_distribution 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 FROM 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.
I tried taping the opening of the horn to reduce the sound, but it was still very loud and it even vibrated.
So instead of continuing to use the horn to test UV cutoff, I used an electronic load set to 3 ohms
(13.5V / 4.7A ≈ 3 ohms).
After connecting the electronic load to the horn terminal block, I connected the fan to one of the fan connectors.
I flashed a controller board with power_distribution from the pd_smoketest branch and placed in onto a rear, Rev 3.0 PD (firmware accounts for rear and front). I connected the board together through the 6 interfacing wires (see P6 on UV cutoff, and see UV Cutoff Interface on PD).
I first powered on PD (with 13.5V), and then UV cutoff (with 13.5V) using separate power supplies. The fan should spin and you should see something like this from the electronic load:
...
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:
...
Test point
...
Reading (volts)
...
FAN_I_SENSE
...
0.0033
...
HORN_I_SENSE
...
0.2569
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.
...
Test point
...
Reading (volts)
...
FAN_I_SENSE
...
0.1486
...
HORN_I_SENSE
...
0.0002
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.
I first decremented the voltage for UV cutoff by 1V. I found out that the board “locks out/cuts off” at 8.5V (the fan stopped spinning and the voltage of the electronic load dropped to zero). When I decremented the voltage at 7.5V, I got a message through minicom that said “UV lockout was triggered”.
...
I then incremented (by 1V) and the fan started spinning once the voltage reached 10.5V (and the voltage of the electronic load went up to ~10.476V).
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 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).
Validating UV_VBAT_I_SENSE
While UV cutoff was connected to PD, I decided to measure the test points:
UV cutoff powered on:
...
Test point
...
Reading (volts)
...
FAN_I_SENSE
...
0.1678
...
HORN_I_SENSE
...
0.2575
...
C13 (VBAT_I_SENSE)
...
3.2725
UV cutoff powered off:
...
Test point
...
Reading (volts)
...
FAN_I_SENSE
...
0.0004
...
HORN_I_SENSE
...
0.0002
...
C13 (VBAT_I_SENSE)
...
3.2840
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):
...
Pin
...
Reading (volts)
...
1: OUT(put)
...
2.7819
...
2: SPARE 2 3 IS
...
0.0002
...
3: STR_PDL_IS
...
0.0003
...
4: SPEAKER/SOLAR_SENS_IS
...
0.0015
...
5: L R DVR DISP IS
...
0.0032
...
6: MCI_IS
...
0.0005
...
7: 5V SPARE IS
...
0.0004
...
8: MAIN_REAR_PI_IS
...
0.0014
...
9: DVR_REAR_DISP
...
0.0029
...
10: PA6 MUX SEL1
...
3.3041
...
11: PA5 MUX SEL2
...
3.3039
...
12: GND
...
0.0003
...
13: PA3_MUX_SEL4
...
3.3039
...
14: PA4 MUX SEL3
...
3.3039
...
15: Ē
...
0.0009
...
16: UV_VBAT_IS
...
3.2776
...
17: FAN IS
...
0.0031
...
18: MAIN_DISP/BMS_IS
...
0.0013
...
19: LEFT/REAR_RIGHT_CAM_IS
...
0.0015
...
20: SPARE 1 IS
...
0.0011
...
21: (closed)
...
0.0004
...
22: FRONT/REAR_TURN_LIGHT_IS
...
0.0004
...
23: DAYTIME/REAR_BRK_IS
...
0.0003
...
24: 3V3
...
3.3041
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:
...
Pin
...
Reading (volts)
...
1: OUT(put)
...
0.0268
...
4: SPEAKER/SOLAR_SENS_IS
...
0.0268
...
16: UV_VBAT_IS
...
3.2937
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:
...
Pin
...
Reading (volts)
...
1: OUT(put)
...
0.0300
...
4: SPEAKER/SOLAR_SENS_IS
...
0.0012
...
16: UV_VBAT_IS
...
3.2930
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:
...
Pin
...
Reading (volts)
...
1: OUT(put)
...
2.7769
...
4: SPEAKER/SOLAR_SENS_IS
...
0.0013
...
16: UV_VBAT_IS
...
3.2776
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):
...
General notes:
used a Rev 3.0 PD assembled as rear
12V nocuta fans
one NF-F12
three NF-A9’s
used an electronic load as a substitute for horn (set to 3 ohms)
anytime I refer to power_distribution 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 (unless I have specified something else)
U2 IS NOT POPULATED FROM 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.
I tried taping the opening of the horn to reduce the sound, but it was still very loud and it even vibrated.
So instead of continuing to use the horn to test UV cutoff, I used an electronic load set to 3 ohms
(13.5V / 4.7A ≈ 3 ohms).
After connecting the electronic load to the horn terminal block, I connected the fan to one of the fan connectors.
I flashed a controller board with power_distribution from the pd_smoketest branch and placed in onto a rear, Rev 3.0 PD (firmware accounts for rear and front). I connected the board together through the 6 interfacing wires (see P6 on UV cutoff, and see UV Cutoff Interface on PD).
I first powered on PD (with 13.5V), and then UV cutoff (with 13.5V) using separate power supplies. The fan should spin and you should see something like this from the electronic load:
...
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:
Test point | Reading (volts) |
|---|---|
FAN_I_SENSE | 0.0033 |
HORN_I_SENSE | 0.2569 |
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.
Test point | Reading (volts) |
|---|---|
FAN_I_SENSE | 0.1486 |
HORN_I_SENSE | 0.0002 |
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.
I first decremented the voltage for UV cutoff by 1V. I found out that the board “locks out/cuts off” at 8.5V (the fan stopped spinning and the voltage of the electronic load dropped to zero). When I decremented the voltage at 7.5V, I got a message through minicom that said “UV lockout was triggered”.
...
I then incremented (by 1V) and the fan started spinning once the voltage reached 10.5V (and the voltage of the electronic load went up to ~10.476V).
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 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).
These specific values aren’t really important since U2 was not populated during this testing.
Validating UV_VBAT_I_SENSE
While UV cutoff was connected to PD, I decided to measure the test points:
UV cutoff powered on:
Test point | Reading (volts) |
|---|---|
FAN_I_SENSE | 0.1678 |
HORN_I_SENSE | 0.2575 |
C13 (VBAT_I_SENSE) | 3.2725 |
UV cutoff powered off:
Test point | Reading (volts) |
|---|---|
FAN_I_SENSE | 0.0004 |
HORN_I_SENSE | 0.0002 |
C13 (VBAT_I_SENSE) | 3.2840 |
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):
Pin | Reading (volts) |
|---|---|
1: OUT(put) | 2.7819 |
2: SPARE 2 3 IS | 0.0002 |
3: STR_PDL_IS | 0.0003 |
4: SPEAKER/SOLAR_SENS_IS | 0.0015 |
5: L R DVR DISP IS | 0.0032 |
6: MCI_IS | 0.0005 |
7: 5V SPARE IS | 0.0004 |
8: MAIN_REAR_PI_IS | 0.0014 |
9: DVR_REAR_DISP | 0.0029 |
10: PA6 MUX SEL1 | 3.3041 |
11: PA5 MUX SEL2 | 3.3039 |
12: GND | 0.0003 |
13: PA3_MUX_SEL4 | 3.3039 |
14: PA4 MUX SEL3 | 3.3039 |
15: Ē | 0.0009 |
16: UV_VBAT_IS | 3.2776 |
17: FAN IS | 0.0031 |
18: MAIN_DISP/BMS_IS | 0.0013 |
19: LEFT/REAR_RIGHT_CAM_IS | 0.0015 |
20: SPARE 1 IS | 0.0011 |
21: (closed) | 0.0004 |
22: FRONT/REAR_TURN_LIGHT_IS | 0.0004 |
23: DAYTIME/REAR_BRK_IS | 0.0003 |
24: 3V3 | 3.3041 |
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:
Pin | Reading (volts) |
|---|---|
1: OUT(put) | 0.0268 |
4: SPEAKER/SOLAR_SENS_IS | 0.0268 |
16: UV_VBAT_IS | 3.2937 |
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:
Pin | Reading (volts) |
|---|---|
1: OUT(put) | 0.0300 |
4: SPEAKER/SOLAR_SENS_IS | 0.0012 |
16: UV_VBAT_IS | 3.2930 |
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:
Pin | Reading (volts) |
|---|---|
1: OUT(put) | 2.7769 |
4: SPEAKER/SOLAR_SENS_IS | 0.0013 |
16: UV_VBAT_IS | 3.2776 |
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):
Pin | Reading (volts) |
|---|---|
1: OUT(put) | 0.0558 |
2: SPARE 2 3 IS | 0.0001 |
3: STR_PDL_IS | 0.0032 |
4: SPEAKER/SOLAR_SENS_IS | 0.0014 |
5: L R DVR DISP IS | 0.0031 |
6: MCI_IS | 0.0023 |
7: 5V SPARE IS | 0.0005 |
8: MAIN_REAR_PI_IS | 0.0015 |
9: DVR_REAR_DISP | 0.0032 |
10: PA6 MUX SEL1 | 3.3055 (periodically changes) |
11: PA5 MUX SEL2 | 3.3057 (periodically changes) |
12: GND | 0.0002 |
13: PA3_MUX_SEL4 | 3.3052 (periodically changes) |
14: PA4 MUX SEL3 | 3.3054 (periodically changes) |
15: Ē | 0.0014 |
16: UV_VBAT_IS | 0.0129 |
17: FAN IS | 0.0031 |
18: MAIN_DISP/BMS_IS | 0.0013 |
19: LEFT/REAR_RIGHT_CAM_IS | 0.0014 |
20: SPARE 1 IS | 0.0012 |
21: (closed) | 0.0028 |
22: FRONT/REAR_TURN_LIGHT_IS | 0.0021 |
23: DAYTIME/REAR_BRK_IS | 0.0003 |
24: 3V3 | 3.3055 |
Now you can see that the voltage at pin 16 is something much more reasonable now that I have replaced U11. However, there is still an issue where the current readings in minicom as shown here:
...
When I have one fan and the horn connected to UV cutoff, the current draw is ranges from 32 - 39mA which doesn’t make sense because the power supply connected to UV cutoff displays a current of about 4.29A. I decided to check the voltage of the IS pins (pin 4) of the following load switches:
Component | Reading (volts) |
|---|---|
U4 | 0.0033 |
U5 | 0.2501 |
U1 | 0.1498 |
As you can see from the table, 0.0033V is quite a bit lower than 0.1498V and 0.2501V. Referring back to the datasheet of U4:
...
This basically means that if the DEN pin is low (low voltage), then IS becomes high impedance (which explains the low voltage 0.0033V).
So then I decided to check the voltage of the DEN pins (pin 3) of the load switches:
Component | Reading (volts) |
|---|---|
U4 | 0.0404 |
U5 | 2.7325 |
U1 | 2.7244 |
As you can see from the table, 0.0404V is significantly lower than 2.7V so I knew that the DEN pin of U4 was set to low, but it needs to be set to high so that the IS pin does not become a high impedance.
Through inspection, I found that R24 and R22 weren’t soldered properly.
R24 connects to the IS pin (after resoldering it closes the connection between the IS pin and R25 [to 6-pin PD connector])
R22 connects to the DEN pin (after resoldering it closes the connection between the DEN pin and FUSED_VBAT+)
After resoldering both resistors, the voltages for the IS and DEN pins of U4 are:
Pin | Reading (volts) |
|---|---|
IS | 0.2621 |
DEN | 2.6721 |
So now the voltages are more in line with the other load switches.
Current Readings in minicom
This section contains screenshots of the UV VBAT current readings in minicom for different scenarios. In the publish_data.c file located in /firmware_xiv/projects/power_distribition/src/, I’ve commented out this line here so I could focus on current readings:
...
As of July 26, 2021, the current is scaled for a BTS7040 rather than a BTS7004 which is the MPN of U4. The current readings are off (minicom doesn’t match what the power supply draws). I will try to update this once there’s an update for the pd_smoketest branch.
Test case | Power supply current draw (amps) | minicom current readings |
|---|---|---|
4 fans running + horn | 4.81 |  |
3 fans running + horn (three NF-A9’s) | 4.45 |  |
2 fans running + horn (two NF-A9’s), | 4.36 |  |
1 fan running + horn (one NF-A9) | 4.29 |  |
horn by itself | 4.19 |  |
4 fans running w/o horn | 0.69 |  |
3 fans running w/o horn (three NF-A9’s) | 0.28 |  |
2 fans running w/o horn (two NF-A9’s) | 0.19 |  |
1 fan running w/o horn (one NF-A9) | 0.09 |  |
0 fans and no horn | 0.02 |  |
U2 IS NOW POPULATED FROM HERE ON OUT (July 27, 2021):
I soldered on an alternative op amp: TLV2401QDBVRQ1 (made by Texas Instruments)
the op amp used in the schematic is a: OPA197 (also made by Texas Instruments)
Now that I soldered on the alternative op amp, I decided to check the cutoff functionality of the board again (I specifically decided to look for when the current draw to UV cutoff dropped to 0.00A rather than looking for the lock out message in minicom).
So for the first time powering the board after soldering the new op amp, I found out that the cutoff voltage was at 11.80V, which is not close to the ideal 10V. Using Falstad and LTspice, I decided to simulate a different cutoff voltage by changing the following resistors:
R1
R2
R6
R9
This Falstad simulation can be found here.
you can adjust the “Power supply” voltage to simulate using a real power supply
I started at 13.5V, then decreased the voltage until the test point (connected to the 100 ohm resistor) turned gray, which kinda represents zero volts
note that the 10V rail represents the LDO regulator and the 12V rail represents the connection from PD
...
The LTspice file made by Liam Hawkins can be found here:
| View file | ||
|---|---|---|
|
the file looks like this and when you run the simulation, you should be able to get something like this when you probe Vin and Vout (Vin represents would represent a power supply and Vout would simply be the test point [technically pin 1 of U2])
notice that Vout turns “on” when Vin is about 11V (red dotted line) and
notice that Vout turns “off” when Vin is about 10V
...
So for whatever reason, the original design configuration where:
R1 = R9 = 1k
R2 = R6 = 10k
was not providing the correct cutoff voltage (whether that would be because of impedance in the bay or the biasing of the amp, which is most likely the issue since we are using a different op amp).
Below is a table that shows different resistor combinations that I have tried:
PD supplied with 12V, using 4 fans and horn (default resistor values shown in purple):
R1 (ohms) | R2 (ohms) | R6 (ohms) | R9 (ohms) | Cutoff voltage (volts) | Pin 4 reference (U2) at 13.5V (volts) | Falstad cutoff (volts) | Reference where board starts drawing current (volts) |
|---|---|---|---|---|---|---|---|
1k | 10k | 10k | 1k | 11.80V | 11.440V | 10V | did not test |
1k | 10k | 10k | 100 | 11.80V | 11.436V | 9.7 | did not test |
100 | 10k | 10k | 1k | 11.42V | 11.441 | 10.3V | did not test |
100 | 100 | 10k | 1k | 7.02V | 11.441 | 8.5V | did not test |
100 | 100 | 10k | 100 | 7.06V | 11.438 | 8V | did not test |
1k | 1k | 3.3k | 1k | 8.14 | 11.878 | 8.9V | did not test |
10k | 1M | 1M | 10k | 10.02 | 10.018 | 10V | 10.14V |
100k | 1M | 1M | 100k | 10.46V | 10.110 | 10V | 11.20V |
(At the time of changing the resistors, I didn’t screenshot all the simulations in LTspice)
So as you can see in the table, the row with the blue values provide a pretty nice cutoff voltage. My thinking behind choosing those values was to kinda keep the same ratio between the resistors from the original design. Although the cutoff voltage is essentially at 10.00V, the voltage where the board turns back on is 10.14V (which isn’t really an issue even though it isn’t close to 11V).
I then tested using the row with the green values (multiply the purple values by 100) which shows that I got a cutoff voltage of 10.46V and the board turns back on at 11.20V. These values are close to the original LTspice sim and this test kinda also confirms that the biasing of the op amp was an issue in the purple row.
Simulating the green row in LTspice:
...
Testing VBAT_STATUS
...
So using the configuration from the green row:
R1 = R9 = 100k
R2 = R6 = 1M
I measured the voltage of pin 1 while the board was on and when the board “locked out”:
Test case | Reading (volts) |
|---|---|
13.5V | 9.505 |
10V (cutoff) | 0.0894 |
I also checked the voltage of this trace shown here (from PD):
...
Test case | Reading (volts) |
|---|---|
13.5V | 9.424 |
10V (cutoff) | 0.0891 |
I then checked the voltage of this trace shown here:
...
Test case | Reading (volts) |
|---|---|
13.5V | 2.2065 |
10V (cutoff) | 0.0210 |
These values from these 3 tables make sense and it seems that VBAT_STATUS is working correctly.