...
Input Voltage | Input Voltage source | Minicom |
|---|---|---|
12.5V | Power Supply | [0] projects/smoke_spv1020/src/main.c:100 SPV1020 #5 voltage_in is: 0x1e1 |
14.5V | Power Supply | [0] projects/smoke_spv1020/src/main.c:100 SPV1020 #5 voltage_in is: 0x22d |
22V | Li-ion battery pack | [0] projects/smoke_spv1020/src/main.c:100: SPV1020 #5 voltage_in is: 0x344 |
This testing was continued sept 8th:
i placed a really big (can dissipate a lot of power) 15 ohm resistance on the output of the mppt across from the input of where the fuse should be and the through hole where the output of the 15th mppt is. I looked at the current readings over spi and found that they were constantly switching between 0 and a number, werent entirely accurate, but did change as I increased and decreased the current across the load (only for a range of about 600mA to 800mA). Note that the power source is a power supply because for some reason my battery harness isnt working rn. Some of the inaccuracy can be attributed to using a power supply source without caps to smoothen the ripple.
heres a sample log from minicom:
[0] projects/smoke_spv1020/src/main.c:107: SPV1020 #5 current is: 0x2e
[0] projects/smoke_spv1020/src/main.c:86: SPV1020 #5 status is: 0x0
[0] projects/smoke_spv1020/src/main.c:93: SPV1020 #5 pwm is: 0x56
[0] projects/smoke_spv1020/src/main.c:100: SPV1020 #5 voltage_in is: 0x2c9
[0] projects/smoke_spv1020/src/main.c:107: SPV1020 #5 current is: 0x2e
[0] projects/smoke_spv1020/src/main.c:86: SPV1020 #5 status is: 0x0
[0] projects/smoke_spv1020/src/main.c:93: SPV1020 #5 pwm is: 0x66
[0] projects/smoke_spv1020/src/main.c:100: SPV1020 #5 voltage_in is: 0x2ca
[0] projects/smoke_spv1020/src/main.c:107: SPV1020 #5 current is: 0x0
[0] projects/smoke_spv1020/src/main.c:86: SPV1020 #5 status is: 0x0
[0] projects/smoke_spv1020/src/main.c:93: SPV1020 #5 pwm is: 0x56
[0] projects/smoke_spv1020/src/main.c:100: SPV1020 #5 voltage_in is: 0x2ca
[0] projects/smoke_spv1020/src/main.c:107: SPV1020 #5 current is: 0x2e
[0] projects/smoke_spv1020/src/main.c:86: SPV1020 #5 status is: 0x0
[0] projects/smoke_spv1020/src/main.c:93: SPV1020 #5 pwm is: 0x56
[0] projects/smoke_spv1020/src/main.c:100: SPV1020 #5 voltage_in is: 0x2c9
[0] projects/smoke_spv1020/src/main.c:107: SPV1020 #5 current is: 0x2e
[0] projects/smoke_spv1020/src/main.c:86: SPV1020 #5 status is: 0x0
[0] projects/smoke_spv1020/src/main.c:93: SPV1020 #5 pwm is: 0x66
[0] projects/smoke_spv1020/src/main.c:100: SPV1020 #5 voltage_in is: 0x2ca
[0] projects/smoke_spv1020/src/main.c:107: SPV1020 #5 current is: 0x0
However since we have tested these mppts out before and have gotten both accurate voltage and current readings, this investigation for hardware functionality with the SPV1020 can be closed out (FW still needs to process the reads off the registers I think).
Moving on for now to MCP3427 validation, I cannot probe any I2C on any of the pins and see traffic. I then realized that i put the pullup resistors on the other side of the board which was not a good idea (R33 and R32) so i made a note of that for revisions, and will populate and test.
well, still no communication. I do see that both sda and scl are just staying at 3v3 (thanks to the pullups) but I dont see them being driven low by the I2C pins.
i touched up the controller board pins with solder and finally see something on SDA! (nothing on scl yet). An important note is to not hand assemble the next rev of solar sense and use a stencil instead.
After many hours later, i finally fixed the scl contact issue with the controller board connector 😑 i will 100% use a stencil next time.
I can now see communication with clock and data on CB side. (see images - SDA & SCL)
...
Still cant get I2C to work, so I started probing to see if maybe theres a signal integrity issue. The green is SCL and yellow is SDA. If this is a signal integrity issue, it will be investigated tomorrow (or I guess today since its 2am)
...
to continue the troubleshooting process and see if the signal integrity was the issue, I connected the current sense mcp3247 that does not have to go through any layers of isolation and gets its analog input from the hall effect sensor. for this testing, the actual voltage on the input didnt matter too much as the hall effect wasnt being tested, but the adc was. I figured out there was a CB solder problem (again) and then was able to see SDA and SCL on the lines to the U3 mcp.
SCL:
...
SDA:
...
Although the lines are apparent, there was still no communication from minicom 😞 . This leads me to believe that it might be a FW issue rather than signal integrity, as both these MCPs failed to communicate. Investigation to be continued.