Reading time: ~45 Minutes — By Saman Niksiar
Formula Sun Grand Prix 2025 was our second outing with Brightside, UBC Solar’s third-generation car (which also raced in FSGP and ASC 2024). Due to a series of challenges—detailed later in this reflection—we were only able to complete five laps on the track. The majority of these issues stemmed from mechanical and electrical integration and communication, as well as misinterpretations of observations. Throughout the past year, we focused on enhancing existing systems, assuming that the core functions were already dependable. Yet, once we hit competition, it was precisely those unmodified systems—the ones we believed needed no work—that let us down.
Brightside 25 at FSGP (Chris P, Mueez M)
In this document, I will revisit the key events at FSGP (and some pre-race activities), share my personal insights, and explain how the team and I addressed each issue. My memory is slightly foggy for some sections, and the order of some events might be flipped. However, the core flow of our work is stated as follows. Furthermore, in this document, I mainly focused on the technical concepts of the Electrical subteams, where I was most involved. For more mechanical reflection check the FSGP 2025 Major Issues Debugging and Reflection on google docs.
In 2024, Brightside made history by competing in the American Solar Challenge for the first time. Despite a compressed timeline, the team executed an outstanding preparation effort and logged nearly 100 laps at last year’s Formula Sun Grand Prix. For the 2025 FSGP, we entered the same vehicle with targeted modifications. These updates on Brightside 25 were designed to set performance benchmarks for future cars and address areas for improvement identified on Brightside 24, all while retaining the core systems and configurations.
At first glance, one might assume that one-year improvements to the car would automatically yield better performance, but that overlooks the trade-offs we encountered. Between Brightside 24 and 25, we upgraded many systems, yet some advantages inevitably declined. Some points over the past year:
Based on all of the above, I expected us to match or do slightly better than last year’s performance, largely because we had a solid strategy in place. My top priority was that the car’s actual results align with our strategy subteam’s predictions, with our state-of-charge model accurate to within a few percentage points, and to demonstrate that we can reliably model both the vehicle and the event conditions. Success, in my view, would mean aligning with Strategy's predictions, which results in maximizing lap count and achieving the most efficient energy consumption—proof that, given the resources and car at hand, our car performed at its very best possible.
3 Elmar MPPTs, which replaced our old Nomura ones as we reconfigured our arrays to 3 strings
Newly added supplemental battery, which removed the horn from the LV bus of the pack, keeping it isolated from the rest of the LVS. (Horn usage was tracked on the steering wheel on an isolated circuit)
Secondly, I defined success as having every team member fully engaged throughout the competition, from scrutineering and debugging to interviews and peer chats. This went better than I expected. Alongside me, at scrutineering stations our leads took ownership, having studied and prepared questions in advance to evaluate each system; Michelle conducted the array tests, Krish helped me flawlessly run the BPS station, Krish, Deev, and Prisha handled Steve’s battery questions, and Aarjav, Chris, Evan, and Hemat managed the tools, recording, and documentation. Their preparedness and confidence not only earned us passes at every station but also proved they’re ready to train and mentor future team members. Seeing members run around, do interviews, ask questions from other teams, come back with excitement sparking in their eyes, with the thought that “I have an idea that would make our car better” was the definition of fulfilling to me.
On June 29th, once the flying and driving teams arrived at the competition site and settled in, we powered up the battery pack to charge it for scrutineering and the days ahead—only to discover that Module 5 sat about 0.1 V below the other modules, exceeding our 0.05 V balancing threshold built into the firmware. I wasn’t fully sure how when no BMS commands have been sent to slave boards that can happen but Krish suspects that balancing has been activated during the drive from the ISO SPI connection. Therefore, we enabled balancing to ensure all modules matched before charging to full capacity, but immediately ran into familiar slave-board glitches—likely stemming from the LTC6813 chips, an intermittent ISO-SPI link, or one of the other errors we’d already battled throughout the term.