PCB Design

Schematic

• Optoisolators draw a relatively high amount of current since they require turning on an internal LED. They can also get hot easily

  • They were more needed when we had a layer of isolation between 3V3 and 12V, but now that we don’t have isolation, we should use PMOS or NMOS to shift logic levels

  • Optoisolators have their place when you are worried about higher voltages or you need a more assured 0 or 1

• Place unity gain amplifiers on any analog circuit (more specifically, ADC readings into a microcontroller). Sensors can get messed up, and their current output drops significantly

  • If you really want to be fancy use a dual package op amp and put a filter on the first amp and then a unity gain on the 2nd

  • Place a 0 ohm feedback resistor so you have the option to apply gain if you want

• Any power or signal line going out of a PCB should have some form of protection

  • Analog or digital should have diodes

    • This is overvoltage / clipping protection

    • Any connection leaving an enclosure should be 24v tolerant

  • Power should be fused

  • Try and use blade fuses since they are easily swappable. When space constrained use PTCs, but have only a few bins of values to avoid needing to carry many differnent fuses

    • Should really only need 10mA for BPS, 500mA for signals, and 1A for other stuff idk

    • There are more compact (shorter) versions of the blade fuses we currently use

  • The SMD fuses we currently use are incredibly easy to rip off

• When you have access to a microcontroller avoid doing things in hardware directly and just do it in software

Layout

• Don’t route signals through other pins, i.e if I have 2 GND pins on a chip don’t route GND to pin a then go through pin a to route it to GND. This makes it hard to botch / cut traces. Shared nets should branch rather than be in series (TODO: add example)

  • Same applies for testpoints

• Your signal path matters, esp in signals with termination.

Battery/BPS

Packaging

• Make cells easily accessible without requiring many other connections/bus bars to be removed. Steve will count cells each time battery has to be re-sealed.

• Keep HV distribution and BPS in separate compartment from pack, allowing battery to be sealed while leaving those components accessible/serviceable.

• BPS scrutineering has to happen with the car in a drivable state. Should have an easy interface to plug stuff into the battery to inject external signals into the BPS or make extension cables for all the car harnesses and have the battery outside the car. They liked our debug e-stop and strobe connection so it’s a possibility. They do make the car move a slight bit so it may be safer to do have an interface for it while the battery is in the car.

Ongoing Issues

A few issues we are currently running into, should fix before running Daybreak extensively.

• BPS stops sending CAN messages after a certain period of time until we reach a fault state. Not sure if this is a BPS software issue or an issue with our CAN bus.

• Module 3/4 are not reading voltage properly, could be due to a short causing one to discharge into the other. Readings are turned off for now, need to investigate further.

• One volt tap (don’t remember which) reads an undervoltage condition when 3.3v is injected. This is likely what causes us to undervoltage fault when pack voltage falls to ~103v.

Considerations for 2026 BPS Design

• Long segment PCB is susceptible to EMI from cells and motor, along with higher chance of dust or environmental conditions affecting many readings. Smaller segment PCBs with MCU on each segment (8x - current design) would likely produce better results. (Note: there will be significantly less dust with the switch from forced air to liquid cooling, interior of battery box is no longer open to outside air, mostly)

• You should be able to see the error/see the state of the BPS by just looking at it. Put addressable leds that correspond to each voltage or temperature on the VoltTemp boards so during a fault you can look at it directly

• Add an indicator for if HV is on, and indicators for when which contactors were on

Power Distribution

Fusing

• Max estimated current draw (HV) must be greater than half of main fuse value.

• Battery connection to array (PDE) must be fused independently. Same fusing and wire gauge regs apply.

HV → LV Conversion

• Have a slow-blow fuse on the input (HV) side to prevent damage to the converter. Check inrush current of the next DC-DC converter we use.

• Considering switch to Vicor DC-DC converters for our next 24v LV system. Should think about cooling, size/packing, efficiency at expected LV draw.

Powerboard

• Update schematic and DNP any components removed from the iteration that ran at comp.

• Document dashboard fixes (diode, etc)

• Most likely going to stick with LTC4421, but with addition of a MCU powered off of supp (to avoid bootlegging power issue)

• Should have an MCU to indicate which supply is active so the driver knows when supplemental battery is being drained (maybe even fault when this happens?)

• Implement critical/non-critical power properly to reduce draw on the supp.

• Consider adding a BMS to the supplemental battery to allow for charging off the car’s LV system

HV Distribution

• Can speed up precharge by downsizing the precharge resistor and increasing the inline fuse values. Look into possibility of board mount resistors and other packaging types as well.

• Had issues with active precharge where it would consistently timeout under ~117v, could be due to incorrect or badly toleranced resistors on the board. Software setpoints for threshold voltages would allow for easier workarounds and debugging.

• All HV hardware/software must work through the range of 80-135v, not just around 120v.

LV Distribution

• Must account for LV draw of each component, as we really do have a tight power budget (dropping 10v over 5 laps is not good ). Specifically, any high-power devices like lights, fans, contactors, etc should be chosen carefully. We should be able to turn off/PWM all lights and throttle fan speeds when necessary.

Motor/Motor Controller

WaveSculptor 22

• The WS22 does not have enough bulk capacitance on its DC bus, which can cause current spikes affecting other components connected to HV (MPPTs, DC-DC converter). We added 710 uF of capacitance across the HV input at the motor controller, which alleviated this issue. Not sure if we want to reduce this, will have to adjust precharge timeouts accordingly.

• Figure out issue with motor thermistor (reading very low value) and adjust setpoints to protect motor from overtemp. This will allow us to confidently push the motor harder knowing that the controller will cut it off at a certain temperature.

• Investigate issues with the non-functional motor interface board (phase B hall sensor input is not reading). Try to find the root cause, can reference Sasha’s schematics for this -

• Document Sasha’s processes for configuring the motor (values, ParamExtract, etc) and best practices to reference when bringing up motor/controller for the 2026 car. Need to write knowledge base articles for all of these.

Cooling

• Motor controller fans currently always run at max speed. Need to add MCU to read motor controller temperature over CAN and control fan tach accordingly. (Battery fans too)

Array/MPPT

Sensors

• Blackbody sensors can be under the top shell in the gaps between cells to measure irradiance and temperature. Reference these hole cutouts when discussing with aero/composites

• I am now even less convinced that off-board i2c will work between these, especially near the back of the car due to motor/battery - ravi

MPPT/Curve Tracing

• Are there any optimizations we can do in software to improve the MPPT algo? We were charging quite slowly even in direct sunlight from both arrays.

  • I think before we start trying to change the algo, I need to test with the TPEE MPPT, array, and battery because I cannot fix something that I don’t have a benchmark for

  • When time isn’t a major constraint, we should try to charge the battery with array and not power supplies

Array Layout

• Implement protection for array when not in use

  • saran wrap

• Connection between modules under so leads aren’t exposed

• Make main output leads more accessible for scrutineering and general testing

  • Reduce risk of shorting

• With new layout, make VDR documentation easier for judges to read

  • No need to label individual modules (judges thought they were different type of cells)

Driver Interface

Lighting

• All lights should be individually controllable in software, including headlights, turn signals, hazards, brake lights, etc. Should also allow for PWM brightness control of all lights to reduce power draw.

• we shoudl also have power monitoring to see how much draw there is

Communication

• Need better driver comms. Functional push-to-talk, etc.

• some teams integrated this on their dashboard (i.e. a radio with a push to talk or just a push to talk button and a radio earpiece)

Display

• Should display LV power source (main/supplemental pack)

• bc nextion stupid, it should be easier to access the sd card slot to flash stuff to it to change it

Wheel/Dashboard

• thankfully we kept the cruise buttons as those got repurposed

Telemetry

How Comp went 

• Data Streaming (Telemetry Board) 

  • Was able to stream data out in real time and see on Photon (very big success)

  • Able to send wirelessly faster than car CAN comes in, so never lost data from that 

  • Had strong singal strength the entire time so thats not a problem (shell did not attenuate signal) 

  • Problem: Kept having power issues that resulted in loss of data. I think that we would momentarily loose power and then the LTE Module would take a while to reconnect and start sending. 

    • Know loss of power is the case b/c every time the MCU resets I wirelessly send a “reset” message first, and I saw this every time we would start getting data again (after not getting data for a bit). Also the SW FIFO was getting pretty full which implies the MCU is starting up long before the LTE is able to reconnect. 

    • Why is this happening? Best guess the LTE module can pull up to ~1A plus semi jank power design right now with interface board.

• Visulization (Photon) 

  • Matthew’s Take: 

    • Good: 

      • Photon was able to visulize real time data from Daybreak in a largely useful way (very big deal!) 

      • Was able to log and time stamp all received data 

      • Was able to get feedback from people who did use photon for what we could improve. 

      • This was a really good proof of concent in the development of Photon 

    • Bad: 

      • I think the largest pain point is that Photon is mostly in a very minimum viable product state, not in a fully developed state. I did not communicate this clearly so there was a large mis match in people’s expectations for Photon and where Photon is right now. That is largely my fault. (See Akshay’s Take for elaboration) 

      • Not a Photon issue, more of an integration issue, but right now we are not getting some data at a fast enough rate. Ex: the battery voltage, temp was almost never filled out. This is an integration issue that we can iron out with more testing. 

    • Key next Steps for Photon (not necessarily in order): 

      • 1) User customizable graphing (via a UI, don’t have to code anything). We plan to provide a “hard coded” default view like we had at comp, however we want anyone to be able to create any arbitrary graph (supporting many different visulization techniques) of an arbitrary graph in the way that they want. This will really help because we dont know exactly what everyone wants, so by allowing for easy customization people can view the data the way they want. 

      • 2) Able to replay logged data. Pretty self explanatory, use the time stamped log file to replay what just happened. Details are still up in the air, but this is a planned feature. Will probably set up a server to host recorded data so that everyone can easily share data and replay what happened. 

      • 3) Better interactions with graphs. Pretty much want the graphing experience to be like Desmos but with a moving time axis. So being able to scroll to zoom in and out on the axis and use the mouse to drag around on the graph. 

      • Extra: 

        • Pablo is going to recruit people to work on Photon (better instructions will be made to build from source). 

        • Better communication :) 

  • Akshay’s Take: 

    • lots of frustration during comp 

    • Akshay opinion:

      • photon looks really cool and was very nice but it worked for us only near the end of comp; its great that it worked but it defeated the whole point of it being a tool for debugging 

      • an exe drop is only acceptable if there are engineers right there who are making changes immediately; i am for the idea of photon however it is not a personal project for it to be so closed source as it also risks project continuity should its developers (hopefully) graduate and do bigger things

      • would like a cloud based instance like as a website or smth as a backup for if photon cannot be updated fast enough

  • Someone’s Take: 

    • reality: the project spec is for a ui that can display the data relayed thru lte/rf and that was not possible in critical moments when debugging electrical stuff; the features requested were later added however it was beyond the time frame of testing

    • We should get a domain name and make credentials/access to telemetry server public, shouldn’t be restricted to just certain members

      • Also have some kind of data storage and access of historical data through this website

      • Should have a way of tagging certain data for a specific setup or track day so we can see how setup changes affect the car

Market Reserach on Other Teams

• Sensors 

  • Matthew: Didnt get a chance to talk to any other teams :( 

  • Akshay: some other teams only have certain sensors such as suspension travel n stuff only for mech sim validation because they did not experimentally see it as a variable that affects much. i lowk forgot the team that did this but they had like a small hook and fastener type thing to easily put and remove sensors they only wanted fro debugging/ mechanical tuning etc. might be worth looking into 

• Data Streaming

  • Matthew: 

    • Polytechnique Montréal (Esteban) uses XBee LTE module (95% sure. Saw this at last comp) 

    • ÉTS Montréal (not at race) uses XBee LTE module. (100% sure. Saw this at last comp) 

    • Saw some team (maybe App State) set up an antenna at time keeping. 

  • Akshay: 

    • UC Irvine uses XBee LTE module

      • Was doing UDP (we do TCP) 

    • Some other Mystery Team uses XBee LTE module  

    • App State has some RF set up (dont really know specifics). They have a big antenna (4 or 5ft) strapped to their pickup truck. 

    • Want to test the RF module (its 90Mhz, and mitsuba motor has a harmonic in the 1-100 MHz, so could interfere) 

• Visulization 

  • Matthew: 

    • Polytechnique Montréal (Esteban) has an Iphone App (didnt see it at this race, saw it at last race) 

    • Did not see any other teams using a real time vishulization application at time keeping. They could have been using in the pit? 

Wire Harnessing

Wire Gauge/Type

• We use 6AWG cable for all high-current HV, this is rated for 106A so have to fuse at 75% or less. Alternatively, switch to thicker gauge wire?

• Since we are moving to a 24v LV system, it should be safe to use 22 AWG wire for all low-voltage connections. Should run calcs for expected peak/constant current draw and acceptable temperature rise for the wires we’re considering.

• Should use pretwisted, shielded CAN cable to make harnessing easier and prevent EMI issues. CAN shields should be grounded at each node.

• Well thought out car harnessing plan ahead of time. I had to cut zip ties and redo a few parts due to pinches between frame/bulkheads, loose bundles sticking into battery box area, bundling making enclosure screw holes inaccessible, etc. This should be made slightly easier since mppts, interface, blackbodies will all be mounted on top shell so the harnessing for those is done up there. Also when adjusting harness routing, a big issue was harnesses were locked into place due to the breakouts being tangled making them semi permanent.

• Consider adding an extra layer of insulation to the harnesses such as coroplast tape over wires and under outer insulation. This is the industry standard for exposed wiring and we cannot afford any damage to harnesses during competition.

EMI/Shielding

• HV lines, especially the 3-phase connection from motor controller to motor, are extremely noisy and affect nearby analog signals drastically. These cables should be shielded and grounded at one end to prevent ground loops.

• Ideally all LV signals should be routed on the opposite side of the car as HV to prevent noise from being an issue. In cases where this isn’t possible (e.g. motor hall sensors & thermistor), HV and LV should be separated as much as possible. LV lines to the motor should also be shielded and grounded properly.

• Motor phase lines should be routed to minimize overlapping cross-sectional area to reduce EMI.

• Buy twisited and shieled cabling for CAN to avoid needing to QA wires made by us

Surface Protection

• Electrical tape does not like heat. Use Tesa (PET) tape instead to tape off ends/connections of sheathing. Heat shrink over connector backshells.

• Design the harness to house all cables traveling on a frame tube in the same wire wrap. Might be useful to use split-braided sheathing to modify later on.

• Array silicone wire gets cut easily by bulkheads. All holes drilled into top/middle shell should have some soft insulating material on the inside. Also, all array wires should have additional sheathing to prevent degradation.

Connectors

• Never use Microfit connectors between enclosures. Microfits expand under high heat and any stress can cause the PCB mount pins to pull out of the connector, leading to bad/no contact. Instead of using these in the fusebox (BBPDU), we should switch to a more robust connector that can tolerate heat and stress. Amass XT-30 could be an option if we design a locking mechanism to keep them in place.

• Quick disconnect between frame and top/middle shell connections can be much better than our current solution. The 2026 car will also have a lot more connections going to top/middle shell, so we must take this into consideration. Stanford uses Deutsch HDP20 connectors which seem to work well (easy twist and push to mate), it’s worth trying these out. There are versions with up to 47 pins supporting 20-22 gauge wire (more than enough for us). Also pretty sure they have high-current/voltage versions of these if we wanna replace array Andersons (can use Amphenol as well, but need to keep in mind we have 3 now).

• Sorta unrelated but we should split camera USB or for that matter anything else that can be split on top/middle shell. Really need to reduce wires going up there, as thats the most sensitive and breakage-prone part of our harness.

• Amphenol ePower-Lite 2 and 3 pin worked well for HV connections. Contacts were resistant to water/dust particles and are very easy to mate/remove (important for impound).

• Should switch main HV out from battery to a 90 degree connector to reduce wire bending (more of an issue with placement of battery relative to enclosures in 2026 car).

• Array connection to enclosures should be Amphenol ePower-Lite Mini.

• MX150s worked well for CAN/LV connections between enclosures. As we will have a lot more small boards, it’s worth using smaller connectors (potentially enclosure-integrated). Additionally, any enclosure with two MX150s with the same number of pins must have different keyways for each connector to avoid confusion (this almost happened at comp).

• Standard pinout for leader/periphs

  • Create standard symbols in KiCAD with standard pinouts, footprints, and part numbers to minimize risk of messing it up

  • Make the pinout such that if you flip it you just short 12V to 12V and gnd to gnd.

Integration/Testing

Debugging

• Flashing via ST-Link was annoying due to a few reasons - namely, with the top shell on the car it’s difficult to access and open enclosures on the interior of the frame other than in the occupant cell. Having debug/flash ports on the outside of such enclosures would make this process easier. Capability for wireless flashing or flashing over CAN bus from an easily-accessible node could also improve this.

  • Instead of plugging in wires individually. We could get some form of qwic connector and crimp a connector to the st-link for programming

• Consider using a different connector instead of DB-9 for CAN debugging. DB-9 without latching screws fall out easily when the car is moving. Possibility of having an MX150-type connector to DB-9 latching extension so we don’t have to modify the CANdapter.

  • Maybe also a direct OBD2 connector

• Every board should have a 1x2 connector with CAN H and L for debugging

• Phase out Ewert CANdapter and move to Peak to avoid pinout confusion between motor and other CAN busses.

• Instead of using some m x n pin header for a logic analyzer, get a keyed connector that matches the pinout of the shitty amazon logic analzyer so it can be slid in easily without needing to plug wires into

Logistics

Scrutineering

• BPS boards for scrutineering shouldn’t be floating. Have a dedicated area/enclosure to prevent jank shit. Should have a connector/interface for Dan’s probes to clip to with relevant temp/volt/current taps easily accessible to reduce risk of shorts.

• Have an additional HV output on the battery/PDE to probe since Steve wants everything energized during isolation test (this can be the Elcon charging port). Maybe even a better solution cause there is still a risk of shorting with that. If top/middle shell can tilt and stay in place we can explore other options as well.

• Array scrutineering was jank asf too (lakshay knows). Figure out a better way → hopefully this is easier with topshell on tilting mechanism? Again, want to reduce the chance of any shorts/unsafe situation while scrutineering. The more put-together shit looks the more lenient judges would be.

• ways to make easier/smoother

• important considerations

Impound

• Need to have people designated to work charging/impound for each day. This was a major pain point as we barely had enough ppl to lift the battery out of the car. Ideally this should have a few mechanical and electrical people who are well-versed in the integration of the battery with the car.

• Start preparing for impound 30 minutes before time (get box/cart, safety equipment ready). Begin impound at first whistle to allow ourselves enough time as we’re still learning the proper methods. The penalty for late impound is very harsh, so its worth skipping some charging time to do this.

• Hopefully designing for an in-car impound will alleviate most of these issues, but we need more organization of people and tools required regardless.

Design Reviews

• We connected with many people (students & volunteers) at comp who could give us valuable insight at CDR and further design reviews. Should make a list with contacts and officially invite them once we finalize a date for ELC/PTN (tentatively early fall sem)