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) 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 | |
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 | |
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 | |
July 6 | Brandon |  |
July 7 | Brandon |  |
July 9 | Aashmika | started testing solar sense, updates on the validation page here: Solar Sense Rev 2.0 Validation 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 |
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 | |
July 15 | Brandon |   |
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
SOLAR CART
mppt inputs:
2: 13 vin, 13 vout
1: 10.6 vin, 10.6 vout
0: 11.5 vin, 11.5 vout this is no good 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 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 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 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 |
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 fan enable and horn enable turn on such that fan spins and horn makes sound - tested with e-load instead of using actual horn I will try each fan connector to make sure that each works and I will need to figure out the U2 situation need to also test VBAT_I_SENSE
|
July 21 | Brandon | UV cutoff (validation page: UV Cutoff rev 1 validation ) note: U2 is not currently populated each fan connector works “lock out” triggers at about ~7.8V VBAT_I_SENSE is about 3.27V for when board is off and on (???) when connected to a powered on PD
|
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) |
July 23 | Brandon | UV cutoff fixed issue where in minicom, UV_VBAT current used to hover around 42mA 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 Charger interface: |
July 27 | Brandon | Power selection: UV cutoff: |
July 28 | Brandon | UV cutoff |
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 Charger interface: |
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 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) 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
|
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 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) current reading from current sense mcp3427: 2.77A 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: EVSE control pilot:
|
