Front Power Distribution:
- Wurth terminals for M4 screw size
- Do we need to have parking lights?
- label PCB
- key the connnectors
- driver fans
- validate load switch on old board
Solar:
- spec ideal diodes
- finish block diagram layout
MCI:
- led for when discharge is done
- added thermistor
- finish adding fans connector to turn it on
- put voltage divider for vout of opto-isolator
BMS Carrier:
- going to validate with firmware for enable pulled low
- power budget for BMS because of Rpi
- USB connectors on rpi for IMU ← confirm I2C to usb connector and vacant ports
Steering
- no push to talk on steering wheel
NOTES:
SOLAR SENSE
how are you getting power from the nppts?
don't think we should use nomura's until we figure out all the problems with the whole system
talk to shio about sourcing the other nppts? if you want the nomuras need to prove spi gives you enough accuracy, make sure you can get entire solar system to work on MS12. validate on ms12
use two boards, one for each array
two arrays in parallel because of wiring
adc for output voltage sense
is there a way to use SPI for the entire thing?
- not saving much complexity by combining the boards
- should have temperature sense on each array section
- why bidirectional mosfet switch? --> space savings instead of relay
- relay fails safer, mosfet fails shorted. For simplicity, relay is better. higher risk of things failing with gate driver. realistically you have space in the car, not a huge problem
-talk to shio about nppts, do extensive testing on ours. didn't have a reliable array in the last car
- what was the failure point of the last system? --> panels themselves seemed fine, front would charge, back would charge, but not both of them
once battery is at 140V doesn't work, possible if battery voltage is lower that it will work
drained it to 133V and still didn't work
mena: it isn't necessarily the nppts, could be the panels/something else
test the array panels sections seperately
what's the plan for physically connecting the nppts? - sounds like a mess wires wise. what about 2 nppt boards on top of each other/daisy chained, run CAN to power them --> would just be 4 wires.
right now you'd have a lot of wires that aren't protected by anything. wires could short to something between panels/nppts, nppts/nppts.
vs having individual nppts connected and fuses
inline solution will get messy/hard to manufacture
use ports instead of harnesses
port is directional
root-cause the issue of the current solar setup
since you are doing 6 channels in each board, do hierarchical design instead of copy-pasting. Altium's hierarchical design feature
pei had a problem with the thermistors where they could only measure up to a certain range
power budget for each rail ->3V3 line (isn't it being boosted?)
POWER DISTRIBUTION
d3 is backwards dude
i sense calculations, calculate the maximum current you can read to make sure you aren't saturating the maximum current
1.21k resistor, i sense pin outputs a proportional current, that multiplied by the resistance gives you the voltage. you need to make sure your current sense value is something your microcontroller can read
parking light → get rid of them
need to include the side of car turn signals
would it make more sense to have a microfit for right and one for left? physically you'll have a harness going to the left side one to the right assembly
put the output from rear power distribution connector with the other ones
would you ever want separate fans for driver and passenger? Taiping does not recommend PWM, concerned with noise outputted to car
are you going to add fans in the back? what about the people in the back? → CHECK WITH INTERIORS.
- if each person gets their own fans how will you control the speed?
what's the plan for telemetry? Josh forgot
- pi? you need something to transmit. raspberry pi would be very inefficient in terms of power.
- figure out where telemetry is, where it's gonna go!!!
why do you need bootloader in the beginning?
- easier debugging and programming? who's going to do that right now?
- you shouldn't need a separate microcontroller to do this, seems like a waste of time to do when you need functional firmware for the rest of the car
Taiping recommends adding a few more spares, at least put one of the dual channel and single channels, ideally 2 extra of each
BMS CARRIER
why do you need a pi to do your math? taiping thinks it seems unnecessary, uses so much more power
- taiping says nothing stopping you from using the front pi to do calcs
- Mena: raspberry pi draws a lot of power, make sure
- Taiping: for this car you need to be optimizing for every watt to be a competitive solar car. Microcontroller should be more than enough, recommend pushing firmware to doing it on that or the front pi
- we were trying to not use any pis in the car at all
remember to double check footprints for new parts and that they're linked to the right part
c10 10nF - taiping says that value was chosen and then the goal was to tune it experimentally, look into maybe tuning it
add a series resistor to the PWM, 5ohm or 10ohm, then later on when you get the board look at slew rate of rising edges. if it's too fast use the series resistor to slow it down. fast rising edge → emitting more noise to the rest of the car, could cause other EMI
add 10nF cap on the output just in case you need it
STEERING:
regen brake toggle - pedal to change the strength, or selector switch to pick different levels of regen, binary on or off or need inbetweens
which stalk are we using? double check
what radio are we using? will push to talk work
form factor? will it be too large with a controller board
have enough height for controller board, because it sticks out a lot
ask adrian if he needs something else to use the existent stalk
use stalk for steering wheel then have push to talk on the wheel ← taipings suggestion
stalk is from audi A6
MOTOR CONTROLLER INTERFACE:
two series resistor on pwm input and caps on output for fans
why cant use contactors to sense continuity
check current on regulator for LED to check if the power consumption by LED is too much
will contact sense be enough for checking when precharge is done?
have temperature of Q3, feed it into comparator, then put that value in micro to know how overheated that FET is getting
also have temperature of Q1, Q2 and maybe R5, R9, R10, R14 and tie together with an open drain comparator logic circuit so that if one of them overheats, fault message is sent
look st S-R latch and maybe have latch just be two FETS for simplicity
change R6-R9 to be higher since the caps on this wavesculptor do not need to precharge as quickly, and this in turn may allow us to get rid of heatsinks
look at confluence for the datasheets of wavesculptor
fix P3 so that matches the CAN connector for wavesculptors for orientation and shielding
email taiping for questions
LIGHTS:
why is C6 a bulk cap? it is too large → verify if there is a voltage spike for that cap (47uF = lots of inrush)
how did C9 get determined? why is it recommended? test the output ripple with and without C9
why is R7 existent → get rid of it its not on the datasheet
C9 is not close enough to output of U3
taiping wants regulator layout to be worked on a lot → follow datasheet
regenerater u4 and u3 to the actual models so leads are accurately positioned
reformat schematic so that it is clear which are the switch nodes, current path, feedback
why is sense resistor on the LED board
does the thermal pad need to be connected to ground ? isolate that and then have the LEDS on the led board with output from cathode to the connector and sense resistors on the other board
do thermal calculations for power dissipation on LED driver, inductor and diode → may require redesign if too much
put a series resistor on the control out to slow down edges on PWM
look at input vpp on vbat across C7 to figure out if cap on P4 is needed
AUX CHARGER:
find buck boost IC instead current one so that it can charge effectively
is there a waste of power to charge aux instead of charging it externally ← taiping does not think it is a practicality
sleep current calculations ← is it really super low power
is this bms redundancy necessary → might make software for power distribution more complicated
assuming not charging within car, sense on power distribution is sufficient
is charging worth additional complexity
what happens if contactors open? is complexity worth it
taiping thinks minimal gain for complexity
is it worth switching to a lead acid?
debugging at the track can be done externally anyways (for aux)
talk to interiors for how they want start of car to work
GENERAL:
core functionality should be addressed first
any fancy stuff should have backup option
focus in what cannot be used in 12 for redesign, and then look at nice to haves
figure out when firmware will be done for each board
sync with firmware for their deadlines so integration will run smoothly
want more competent people on more important boards for firmware
power dist., driver controls, BMS, maybe lights, old solar sense ← first to validate
late to change micros unless there is a significant reason to do so
motor controllers → should CAN be integrated with system CAN by not using those CAN IDs elsewhere
motor controller CAN is not reliable in passing messages between buses apparently (would stop communicating)
validate charger interface board → need it to race