Please fill out this document with all updates made for this term!
Date
Individual
Progress
Date
Individual
Progress
June 28th
Aashmika
cleant up the mockup table for easier use and searching - please keep it this clean or cleaner!
Added all ESD mats, ground connections and wrist straps (did this last week but will add it here)
Whenever testing on mockup or motor bench, please use the wrist-strap to minimize ESD effecting components
Found telemetry stuff including PoE module, bullet, rpi, gps/lte hat, antennas (all from MSXII besides gps hat which I picked up yesterday from James) → will go in later to set it up and see if the PoE module is working as it should
June 28th
Brandon
reflowed UV Cutoff board (ready for validation)
June 29th
Aashmika
set up the “telemetry mockup” after finding all the telemetry stuff used in MSXII. It is a “tapey” solution for now once i confirm everything is included as needed. Installed raspbian on one of the Pis from MSXII for the purposes of telemtry testing, not sure what else fw would like. TLDR: Turn on the supply and it should be good to go! The following briefly explains setup:
Set up the pi to interface over ethernet to the poe module that is connected to ubiquiti bullet. The power supply connects to a 12V breakout board from MSXII that supplies power to a 12V-5V OTS regulator meant for car usage, that with some barrel jacks in between powers the pi (i had to sacrifice the usb B end of a usb to microusb connector for the easier powering option). HDMI from pi to monitor and logi unifying device for mouse and keyboard on USB port. GPS+LTE hat on top of the rpi connected with usb-microusb. The ubiquity bullet has an antenna, the rpi hat has a connector for gps and lte to either antenna (note: do not unplug the connector too much it is a fragile board connector and can survive very few connector cycling). Finally I just connected the peak-can dongle cuz there was one in the MSXII telemetry components.
tested ps for main rails when supplied with the power supply input, and saw that it maintained a output 13.5V to front pd! this means jump start definitely works, but need to check if the cell is disconnected once the output is maintained. Did not see any shorts, and did not try any other inputs. Will check all this once I start load testing
June 29th
Brandon
finished soldering remaining components for Center Console board (ready for validation)
July 3rd
Jess + Aashmika
POWER DISTRIBUTION
checked fan control front curve by forcing the new rear rev to be front
works but range is limited from 0-49 (just printing fan speed)
checked physically by slow-mo filming the fan lol, you can see the different speeds
POWER SELECTION
small bug: not initializing the adc pin for 3v3 cell sense @Hewitt McGaughey
printing doesn't work very well with the PRI etc etc formatters on ARM @Hewitt McGaughey
[0] projects/power_select/src/power_select.c:115: Voltage hu: 0 mV
[0] projects/power_select/src/power_select.c:115: Voltage hu: 1 mV
[0] projects/power_select/src/power_select.c:115: Voltage hu: 2 mV
[0] projects/power_select/src/power_select.c:153: Current hu: 0 mA
[0] projects/power_select/src/power_select.c:153: Current hu: 1 mA
[0] projects/power_select/src/power_select.c:153: Current hu: 2 mA
[0] projects/power_select/src/power_select.c:126: Temp hu: 0 C
[0] projects/power_select/src/power_select.c:126: Temp hu: 1 C
with fix in place, still gives wrong input
powering from aux constantly power cycles the controller board?? no good
swapped the big LT4417 with the old power selection
may have fried parts of it by putting it on backwards (may it rest in peace)
Continued after jess left:
Replaced the LTC4417 once again, but found that the power supplies would be turned on and connected but still would either cycle the board or make loud sizzling sounds
Probing the 3V3 rails when the power supplies were off resulted in around 2.5V being recorded, which was weird since by itself the cell was 3.3V. The 3V3 rails on the board itself also probed to about 1V with some randomness that might be attributed to the probes being used at the time
took out the cell and tried again without it connected, and the power path switching started to work consistently with all three power supplies! Not sure why this worked talked with Nita who found this in the block diagram of the LTC4417, which shows it might get temporarily powered through the V1-V3 and might get enabled through the following
The sequence for how it turns on almost seems like an inbuilt turn on function, in which when one of the power supplies is turned on, the vbat on the output turns on, then off (briefly) then on again for the rest of the duration of the board getting power. I took pictures of the scope with the following images:
Nita will be helping me look through the datasheet to see if this is an intentional possibility. From those consistent waveforms, it seems like this is being done by the IC and not due to surge or any transients.
there is still some issue when I turn on the aux power supply in which the vbat starts to turn off and on repeatedly and not hold vbat steady. This makes me believe that there might be a transient cuasing the vbat line to go high temporarily and for it to hold the timing has to work with a high pulse to enable the IC for the right amount of time before connecting an input.
One thing to note is that this behaviour although not well documented was observed with the previous revision of power select, and was kind of used but not looked into so that it could be incorporated with the rest of the mockup table to give power to other boards.
CENTRE CONSOLE
all the LED buttons should be in the right-ish place for the new rev
LED neutral and drive switched or something but no biggie
didn't test extensively with states but things seem broken
July 5
Brandon
began assembling Solar Sense rev 2
was not able to place all components before using reflow oven
July 6
Brandon
continued assembling Solar Sense rev 2 by hand using heat gun and soldering iron
July 7
Brandon
continued assembling Solar Sense rev 2 by hand using heat gun and soldering iron
also got a cart from graeme to eventually hold our solar testing rig once we get to testing with the old array!
July 10
Jess
SOLAR MPPTs
Swapped SEL pins to match schematics and got readings!
scaling factor seems way off
Basically, they have unique scaling factors?
turning the left pot (near the input) changes the reading
scaling factor is (voltage measured at MPPT input terminals) / (raw reading)
have to figure out how to test range / what settings we want before tuning all the MPPTs and finding a scaling factor
32 cells, voc .73V. Max input is 23.36V. We want to capture 0-max.
NOTE: 0x3ff is the max reading. We want 0x3ff to be at 24 or something then.
actually, since scaling factor is already 26.1, we want 26.1 to be at 0x3e8
range is 7.210-26.3 ish
counter-clockwise to increase scaling factor (decrease raw), clockwise to decrease scaling factor (increase raw)
PROCESS FOR TUNING MPPT:
Set input voltage to ~21.6
Run smoke_spv1020 and watch output
use a sharp thing to twirl the left MPPT pot until the raw voltage reads 0x3e8, +/- a few
current was reading 0 for the MPPT which is probably fine because it's output current SOLAR MCP3427s
smoketest should be on channel 2 lol
can read voltage, need to tune pots to be at correct output voltage (26V)
range is 17-28 V
resistors have to be modified, since 28V scaled by hardware is out of range for mcp3427
STEERING
updated the smoketest a bit, tested it and it works ok, merged because it would be convenient to have on master
July 10
Mitchell
CHARGER:
was able to send and receive can message to controller, activating charge state, and activating charger controller
Charger controller is sending messages, but nothing is going over the mcp2515 network. Ran the smoketest in loopback mode to verify the mcp2515 but it fails, indicating that the issue is with the mcp2515. Next steps are to scope the different pins of the mcp2515 to see where the issue may be arising
TELEMETRY:
Ran installation on the pi, so all the software needed should be on it now.
Looked through the GPS code, need to verify pins are correct for operation of SIM7600, goal is to be able to read GPS data.
July 14th
Jess + Aashmika
SOLAR MCP3427
with the new resistors, we can calibrate it:
range is 25-32 V
25 - 23520
27 - 25296 (+1776)
29 - 27184 (+1888)
31 - 29088 (+1904)
32 - 30064 (+976)
linear regression shows a scaling of 1.067x-47.3, tested from ~5V to ~32V
reading from mcp3247s for 0 and 1 work well, tested from 5-32 V and it's within 250 mv.
updated note in smoketest about channels for mppt and current sense adcs.
address pins were wrong in smoketest for mcp3427#2, fixed them.
added relay control to the mcp3427 smoketest SOLAR MPPT
select pins are wrong in smoketest
switched smoketest to read from multiple smoketests
tested with mppts 129 and 130, they're tuned and we tested for 5-12 V for vin successfully. SOLAR general
when we put a load solar current, the voltage at the mppt output drops in half weirdly, hardware has to debug that
salvaged the rest of the MPPTs off the old array NEXT UP
measure current sense? mcp3427 current sense was reading 0 in smoketest even though there should've been current
thermistors
smoketest fan control
mppt fault status readings for all fault modes
verify getting right relay status
July 14
Brandon
changed R15s of Solar Sense: 100k → 75k ohm
reflowed top side of BMS carrier board
July 15
Brandon
soldered remaining components onto BMS carrier excluding test points and 100 thou headers
July 16
Aashmika + Jess
SOLAR CURRENT SENSE
I was actually wrong on the mcp3427 channel last time, everything is channel 2
Linear regression on current readings, range from 25-42V on e-load (current inversely proportional)
relationship: in tenths of milliamps: y = 4.847 * x - 123355;
y is tenths of milliamps, x is the raw value from ADC
tested in range ~18 mA - 1.6 A, it's pretty accurate! within ~9 mA everywhere
with all MPPTs in series and the array as input, the output isn't boosted
hypothesis: could be array connection? can test this with 3 power supplies, constant voltage input
if mppts in series, the output current must all be the same, so all are forced to lowest current
however, none of them boosted.
want to test in sunlight (rather than lamps) to really see input power
want to figure out how to see status and current over spi from mppts, also understand PWM
working branch is soft_151_solar_validation HARDWARE NOTES:
must prep more MPPTs
midsun solar cart is pretty lit (see slack for picture)
July 17
Aashmika + Jess
SOLAR
current doesn't read unless it's above ~140 mA
added a small delay in reading since that helped get consistent readings (printf("...........\n");)
linear regression between ~150 mA to 5890 mA
160, 125
300, 130
400, 136
500, 140
700, 156
1000, 166
2000, 240
3000, 269
4000, 313
5000, 402
5800, 584
y = 3912.2ln(x) - 18870 is kinda weird?
y = -0.0249x2 + 30.285x - 3315.3 seems good for mppt#263, but not for #270
it's definitely not linear, the curve is weird, not consistent between MPPTs
they still don't seem to be boosting
Status bit 2 (0x2) seems to be over voltage, not over temp as we expected
July 17
Mitchell (And Kyle)
CHARGER:
Wrote mini program to attempt to read/write to the mcp2515 over SPI
Called mcp2515_init (which in turn sends config info to the device using spi_exchange()). There didn’t appear to be any issues, but there is no way of knowing whether the info was written successfully
Then attempted unsuccessfully to read registers of mcp2515. The spi_exchange() call gets stuck, not returning
Possible issues for this could be
SPI Configuration is wrong (I will check the schematic again), but would assume that it is the same as other mcp2515 projects, and almost all projects use same port
Connections are having issues: may need to scope the SPI lines to see if data is actually being sent properly? Might be a problem with the stm32 connector or something not sure
Maybe try replacing the can transceiver for the mcp2515. This shouldn’t affect spi, but Hewitt said that this was a fix that got the MCI mcp2515 working
POWER DISTRIBUTION:
Kyle Chan came to the bay for the first time, and we went through some orientation tasks
Attempted to verify power distribution gpio expanders, but I made the mistake of not setting the right I2C pins 🤬 🤬 🤬
Moral of the story, I owe Aashmika many crimps 🥲
July 19th
Aashmika + Jess
POWER DISTRIBUTION
the sda/scl were for i2c port 2 but we needed for port 1 lol
STEERING
turn signal seems pulled high? no good
otherwise things mostly work, some of the active-high/low seems mixed up
On the stalk white connector,
pin 1: ground (blue wire)
pin 2: cc set (brown wire)
pin 3: distance +/- dial
pin 4: garbage
pin 5: cc on/off
pin 6: ground
pin 7: ground
pin 8: cc resume
pin 9: lane assist (green wire)
pin 10: high beam rear
pin 11: high beam forward
We took it apart. The resistor divider for the turn signal seemed to be loose. Up: 2.2 kohms Down: 0.68 kohms
still was sketchy when testing it, so we cleaned with alcohol
fixed it finally by raising the contacts on the slidey metal bits with tweezers
in the end it stopped working, the mechanical bits must be really flaky
SOLAR
next steps: message nomura on facebook to figure out how the input works
July 20th
Aashmika
STEERING:
investigating why the contact for the turn signal seems to be loose still and not giving input
re-cleaned the contacts for the turn signal slidy thing
realized the reason the turn signal wasnt working after yesterday was because it needs the pressure from the screws to make a solid contact → put the screws back on and now it is a solid change of 9k to 10k for the right vs left respectively (the middle position is high z). In the below image a value of 2984 is right and left is 3026. Off for turn signal stays at 3308.
was starting to test if steering would read the right values, and it seemed to not for a few buttons and the inputs from the stalk. I checked if the pins were right in the code as per the schematics, and they were. I then realized that the pins were not in the correct order @Frank Yan you gotta fix the naming for all the pins because we cannot move pins around on the cb connector, we only have one CB design and it needs to match correctly
ryan made a super quick update to the project on pd_smoketest, and now everything works except for the high beam forward and back
to fix:
not sure why it doesnt work, will talk to ryan but basically when i probe the tespoints for either signal, they both are about 1.51V when I press the stalk in either direction
btw i think hw-fw may have different ideas about the high beams, basically the high beam forward input should turn on both the drls, and the high beam rear input should turn off both drls
also note that the turn stalk gets not useful inputs when turning the high beam forward or rear on, so we should not be looking to turn on the turn signal if the high beam forward or rear is signalling
turn signal right and left are currently switched -> 3025 for left and 2984 for right oops → need to fix
July 20
Brandon
UV cutoff
loud car horn: inrush current of ~9A, then draws at 4.7A
the board “cuts off” when VBAT drops to ~8.5V (i.e. fan stops spinning and horn stops making sound)
U2 (op amp) had incorrect voltage readings at its pins so it was replaced with a: opa376aqdbvrq1
this replacement part started getting really hot and started smoking so it was taken off (possible issue with IC or issue with board)
fan enable and horn enable turn on such that fan spins and horn makes sound - tested with e-load instead of using actual horn
horn (e-load): ~3 ohms → ~13.5V
I will try each fan connector to make sure that each works and I will need to figure out the U2 situation
VBAT_I_SENSE is about 3.27V for when board is off and on (???) when connected to a powered on PD
will replace U4 to check if that’s the issue or not
July 22
Mitchell
CHARGER:
Spent some more time trying to get the mcp2515 to work. Verified SPI port, pins with the schematic.
Using the smoke_test and driver on master I read register values before and after spi writes in mcp2515_init()
they are not changing as they should be
The commands executed without issues, which leads me to believe that there is some hardware issue (It may be that the cs line is not working? I tried setting some delays and scoping the nss where it comes out of the board, and it wasn’t changing. could be something to look into)
It is possible that the commands are wrong but unlikely as this driver works for MCI
This is the same issue that I had before leading me (from advice from hewitt) to think that the IC was bricked. It’s been replaced now, so that shouldn’t be the issue.
July 22
Brandon
PD (and UV cutoff)
VBAT_I_SENSE was about 3.27V because of issue with U11 → 25 ohm resistance between pin 16 (UV_VBAT_IS) and pin 24 (3V3)
I know this because I measured voltages for the other current sense pins on U11 and they were around ~0.0015V (i.e. not close to 3V3)
replaced the broken U11 with a U11 from an old PD rev
VBAT_I_SENSE is no longer 3.27V
running the PD firmware in minicom, UV_vbat current hovers around 42mA instead of 4A (makes more sense)
i will double check the voltages for the other pins on U11 and then connect UV cutoff to PD and test again
July 23
Brandon
UV cutoff
fixed issue where in minicom, UV_VBAT current used to hover around 42mA
soldering issue with R24 and R22
now minicom readings make more sense:
0mA when neither fan nor horn is being powered
0-10mA when one fan is being powered
368-381mA when one fan and horn is being powered
apparently scaling of the readings if off (FW is based for BTS7040 but it should be for BTS7004)
July 26
Brandon
UV cutoff
added screenshots of minicom UV VBAT current readings to validation page (scaling is still off, waiting for update to BTS7004)
Charger interface:
found continuity issues between test points and bergstak → resoldered bergstak
“before write 0” and “after write 5”
July 27
Brandon
Power selection:
wasn’t able to see if mosfets were turning on and off repeatedly
added more solder to pins of mosfets
UV cutoff:
soldered on U2 (TLV2401QDBVRQ1 instead of OPA197)
cutoff is at 11.80V → fiddling with resistors in Falstad to reduce cutoff voltage
July 28
Brandon
UV cutoff
fiddling with resistors in Falstad and LTspice to change cutoff voltage (was at 11.80V instead of 10V)
decided to use:
R1 = 10k
R2 = 1M
R6 = 1M
R9 = 10k
my thinking was to kinda keep the same resistor ratios from the schematic → was able to get a cutoff voltage of ~10.02V (which is much better)
board turns back on at around 10.14V
pin 1 of U2 (VBAT_STATUS) also works accordingly to cutoff voltage
I will need to add these to validation page
July 28
Mitchell
CHARGER:
Thanks to Brandon’s efforts, mcp2515 is able to be written to via spi
Running smoketest in loopback mode is now successful, which means that the mcp2515 is now functional
However, still not able to receive messages over the mcp2515 by reading the output via socketcan. Don’t get anything with either the python cantool and candump
I think this may be an issue with the can transceiver or the connector which the can dongle connects to. I tried scoping the can lines at the transceiver input and output, and where it enters the connector and wasn’t able to get any meaningful results.
July 29
Brandon
UV cutoff
decided to use following configuration (for op amp):
R1 = R9 = 100k
R2 = R6 = 1M
cutoff voltage is about 10.46V and board turns back on at around 11.20V
so the issue about not getting the correct cutoff voltage when using the original design configuration probably has something to do with biasing the new op amp
verified/validated VBAT_STATUS
will still need to verify current readings in minicom once FW updates pd_smoketest branch
PS
was able to replicate LED flickering issue on DCDC input connector and Power supply input connector
D1 might also be backwards (judging from the same orientation as D2)
July 30th
Aashmika + Jess
SOLAR
we took things outside with the midsun solar cart
MPPT input/output voltages:
2: 18v/32v
1: 17v/22v
0: 18v/22v
total is ~76
output to load is 60v
in constant voltage mode in 55v drawing ~1A
when the clouds are covering the sun, they don't boost
in passthrough mode they don't provide an input voltage reading
then we cleaned the array lol
New clean MPPT input/output voltages (moderate sunlight):
2: 19v/30v
1: 17.4v/17.6v
0: 19v/18.8v
array in full sunlight on #2 side gives 19v
middle 17.5v (#1)
#0 gives 18.8v
stopped reading anything, then realized mppt #2 was super toasty
input voltage seemed weird, maybe a short on the mppt board
mppt #2 had ~5ohms between high and ground on the input voltage
mcp3427 #0, 1, and 4 seem fried, but the others work fine
the isolators aren't regulating 3v3 on the broken mcp3427s
3v3 is a physical short to ground on the broken isolators
On the broken isolators, the 0th and 1th mppt slot, the 3v3 pin is shorted to ground on HV side on the IC itself
**working branch is soft_151_solar_validation, to change devices being read on smoke_mcp3427 and smoke_spv1020 change the values in the s_test_devices array
After jess left:
replaced the isow7841 for mppt 0 and mppt 1, not mppt 4 because there wasnt actually a short on that mppt → so i replaced the mcp3427 for mppt 4 to see if that was our longstanding i2c timeout issues
flashed smoke_mcp3427 code for 0 and 1 mppts → no longer any timeout errors
theres still a timeout error on mppt 4 meaning that the replacing the mcp3427 wasnt the issue (possibly an issue with the isolator or somewhere in the circuit)
can try replacing iso1504dr instead next time or using a scope to see where the i2c stops
figured out after much probing that all the CS pins were high, so i took off the cs mux
realized that all the miso lines were ground as well which then made me realize that all the select pins on both muxes might be high → probed them and they were
need to figure out why all select pins are high, because there isnt a hw short → it seems either fw or the controller board is setting each of those select pins high, when really it should be a combination of high and low to just mux one pin at a time
I dont think it’s an issue with the controller board because i switched it and reprogrammed and all the pins are still high
will look through code and test with just toggling gpios tomorrow
July 31st
Aashmika, Mitchell, Jess
SOLAR
SPI didn't seem to be working, so we scoped it
clock and mosi are outputting, nothing's on miso
discovered if you put pressure on the clock line it works, so resoldered stuff
realized we didn't connect ground references lol, so we did that
it started working
went outside and tested with solar cart (clear sky, no clouds, moderate heat, 18C)
vsense isn't working for mppt0
vsense for mppts
1: 16V
2: 16.5v
0: (from dmm) 17.2
open circuit voltage of entire array is 58v
current clamp measurements (eload in CV mode, 50v)
2: 3A
1: 2.5A
0: 3A
current reading from current sense mcp3427: 2.77A
eload says 2.777A, pretty close!
voltage readings / actual (dmm) from mcp3427s for mppts 0, 1, 2:
0: 21.25 / 21.3
1: 15.97 / 15.98
2: 17.30 / 17.3
really close!
note: relay is closed so everything in series, but no current is being drawn
1, 2 are not boosting? for later testing, should check if they boost from a different source
tested mppt2 with 12.2v battery and it boosted just fine
swapped back to the array and it still boosted! could need to get jump started??
put mppt1 on battery and it boosted intermittently, swapping between 12 and 25v
mppt1 also stayed boosted when swapped back to the array
closed relay with all the mppts boosted and we get 77v at the eload
set them all to 26.2v (boosted), but then mppt1 stopped boosting :(((
if we're never able to figure out the issue, we'll always be limited to the mppts that can boost
will be really annoying and soul crushing and time wasting fixing each mppt
the only solution to one mppt not boosting is making other mppts higher
if none boost, it could be bad. This seems like the problem Pei had
July 31
Mitchell
CHARGER:
Spent time with aashmika debugging mcp2515 can interface. Turns out that the issue was the connector pins were reversed (which has been noted on altium)
Created a new, charger specific PEAK CAN connector
Now able to send and read values over the mcp2515 CAN!!!
Spent some time hooking up the charger interface to try and communicate with the elcon charger
Plugged in the elcon can connector to the board, plugged in the EVSE charger to the wall and connected it to the J1772 plug connected to the Elcon. Connected the proximity sense/evse control pilot plug into the board.
charger firmware runs as expected, proximity sense reads the state correctly, and messages with the ID 0x1806E5F4 (which I verified in the documents describing the J1772 standard) are sent and can be read with socketcan.
However, nothing comes back from the elcon. We should be receiving status messages every second with ID 18FF50E5, but nothing is getting read on the can bus
Possible reasons for this:
Elcon errors:
power/load is not properly connected (Wall charger was plugged in, and the CAN connector has 12V pins which connect to the elcon. Not sure if there is another source I am missing. Also, does the load need to be connected for it to work?
Can connector issue:
I verified pins were in correct orientation at connector out. However, there may be a faulty connection here or something
EVSE control pilot:
I saw reference to the fact that the evse control pilot has some role in enabling the Elcon, but not sure what it is. Will look into this
Also we got to use the sexy scope
Aug 3
Brandon
PS
I’ve noticed that while the LED flickers on and off repeatedly, the controller board firmware doesn’t run (i.e. minicom doesn’t show any code running)
removed LTC4417 and checked for shorts using resistance mode
nothing really stood out
resoldered some passives and Q14
resoldered a new LTC4417 (did not get to power board yet)
Aug 13
Brandon
PS
still getting the flickering LED issue even after replacing the LTC4417 (supplying with 13.5V)
DCDC input seems to stabilize a bit faster (but still flickering issue)
Power Supply input shows no change from previous LTC4417 (flickering doesn’t stop)
AUX input doesn’t flicker at all
Aug 14
Jess + Aashmika
SOLAR
validating thermistors
used smoke_steering for the periodic adc reading, thermistor an PA2
data saved in csv posted on this page, data is first column temp, second column converted voltage reading
curve fit voltage reading (converted) to temp: y = -2E-05x2 + 0.0237x + 81.808
