Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

    • Code Block
      [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

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:

    1. Set input voltage to ~21.6

    2. Run smoke_spv1020 and watch output

    3. 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

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

    • 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

  • 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

    • 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

    • maybe has something to do with this:

  • will need to double check LTC4417 Calculations

Charger interface:

  • from inspection:

    • D10 is backwards

    • 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

View file
nameaug 14 solar therm data temp to converted voltage.csv