TL;DR
We are UPB Drive, a Formula Student Team from Bucharest, Romania, competing in international competitions while designing, manufacturing and running our own formula-style single-seater. We design our own systems, from the chassis, the powertrain, down to individual electronics components. This article covers one of our favorite projects and most advanced PCBs ever designed, the TimoECU, our custom ECU solution.
Introduction
We’re UPB Drive, the Formula Student team of the Politehnica University of Bucharest. Most of us study engineering here, mechanical, automotive, electrical, and computer science mostly, and we spend a good part of our free time in the workshop building a single seater race car from scratch every season.
The team started because a few students wanted to do something with what they were learning instead of only reading about it in lectures. That’s still pretty much why people join. You get to design a part, manufacture it, put it on the car, and then watch it either work or fail on track, which teaches you more in one weekend than a semester of theory does. It’s also just fun to be around people who care about the same thing.
As a team, our goal for this season was to get the car running earlier than last year so we have more testing time before competition. Testing is usually where everything falls apart, and the teams that do well are the ones that found their problems in March instead of in the paddock. Individually, most of us are here to learn the practical side of engineering and to figure out what kind of work we actually want to do after university. A few people are aiming for jobs in motorsport, others just want the hands on experience.
We compete in Formula Student, and we’re preparing for the events we’ve entered this season. It’s a tough environment, but that’s the point.
Our project
This season the main project is the car itself. We set out to develop it fully in house rather than buying our way around the hard parts, mostly because our budget doesn’t leave much room for that anyway. A lot of what we do comes down to working with what we already have, reusing components where it makes sense, and being honest with ourselves about which upgrades are actually worth the money and which ones just look good on paper.
The bigger risk we took was designing our own ECU from scratch instead of running an off the shelf unit. On paper that’s the wrong decision. A commercial ECU works, it’s supported, and you spend your time tuning instead of debugging. But nobody on the team learns much from plugging in a black box. Building it ourselves meant we had to understand the whole chain, sensor inputs, signal conditioning, the control logic, how it talks to the rest of the car over CAN, and what happens when something goes wrong at 12000 rpm. That’s a lot of ground to cover for students who mostly learned this from coursework.
Our electronics
The project is a custom Engine Control Unit called the TimoECU TimoUnu, built in house to replace the commercial ECUMaster Black currently running on UPB Drive’s car.
The reason is simple. The ECUMaster is expensive, and since we only own one, it has to be moved from car to car every season, which leaves every previous car dead in the workshop. Building our own means each car can keep its own ECU, and at a fraction of the cost.
It’s designed for the Honda CBR600F4i we run (idle around 2000 RPM, redline at 13000), but it works with both single and four cylinder engines. The core is an NXP S32K344 automotive grade microcontroller with a lockstep core, 24 ADC channels and an integrated CAN controller, running AUTOSAR drivers.
What it does:
- Injection and ignition: four injector and four ignition output stages, each with its own MOSFET driver and flyback protection. We measured the real engine with current probes to size them properly, then validated everything on the bench with a programmable load.
- Crank and cam decoding: signals from the crank and cam sensors are conditioned and squared up by a comparator, then fed into hardware interrupts. This gives us engine position tracking accurate to the microsecond, which is what everything else depends on.
- Sensor acquisition: inputs for MAP (on-board sensor plus an external option), throttle position, fuel pressure, intake and coolant temperature, oil temperature and pressure, battery voltage and vehicle speed, with four spare programmable analog inputs. Every input is protected against overvoltage, and pull-ups can be switched by DIP switch so we can swap sensor types without touching the board.
- Race features: launch control with wheel slip mitigation, shift cut, rev limiter, and high current outputs for things like the cooling fans.
- Communication and logging: CAN at 500 kbps with fully programmable packet definitions, live tuning from a laptop over USB while the engine is running, and logging at up to 50 Hz to a MicroSD card with proper timestamps. Engine maps and configuration live in internal flash with validity checking and a fallback if something is corrupted.
- Power and reliability: an automotive PMIC supplies separate 5 V rails for digital logic and analog sensors from a 9 to 21 V input. The board was hand assembled and then validated block by block before it ever went near the engine.
The firmware puts a hardware agnostic API on top of the AUTOSAR drivers, so the control logic carries over to future board revisions or a different platform without a rewrite.
What is our favorite AISLER feature?
The one click export from Altium is probably the thing we use most. Getting from a finished design to an order without exporting Gerbers, checking layer mappings and second guessing whether we set something up wrong removes a whole step where students usually make mistakes. For a team where a lot of people are ordering their first board, that matters more than it sounds.
The other one is less of a feature and more of an experience. The help we got on the sponsorship side was straightforward and quick, which is not something we can say about every company we approach. When you’re a student team, most of your time goes into chasing replies, so dealing with people who actually respond makes a real difference to how much you get done.
And then the boards themselves. The ENIG finish came out clean and the quality was consistent across what we ordered, which is exactly what you want when you’re hand assembling under a microscope and don’t have spare boards to waste. Good pads make soldering easier, and easier soldering means fewer mystery faults later on the car.
What is our proudest achievement?
There are the obvious ones, and most of them are small. A dashboard that finally showed the right values instead of garbage after we fixed the CAN termination resistor. The shutdown circuit passing scrutineering without a single comment (fellow FSAE enjoyers, that’s with a working BSPD!). Sensor boards that we designed, ordered, assembled and then never had to think about again, because they just worked all season. Every one of those was somebody’s first PCB, and watching a student hold a board they drew themselves and see it come alive is a good moment every time.
But as technical advisor, my honest answer is different. My proudest achievement is watching the students grow past me.
At the start of a project like this, people come to you with everything. Why doesn’t this rail come up, is this the right MOSFET, how do I read this datasheet. You answer, they go off, they come back. Then somewhere in the middle of the season the questions change. They stop asking what to do and start telling you what they found, and the explanation is better than the one you would have given. At some point on this project I was reviewing decisions I would not have known how to make myself a few years ago.
That’s the part that stays. The car gets scrapped or rebuilt, the boards get a revision, but the people who built them walk out knowing embedded software, power electronics and how to debug a system nobody has ever debugged before. Being useful to them early and unnecessary by the end is the whole job, and getting there is better than any result we could put on a scoresheet.
What 's something that went wrong?
Our best one is not a spectacular explosion, just a very basic thing we walked straight into.
The injector and ignition stages use a small BC847 as a pre driver with a pull up resistor to 12 V feeding the MOSFET gate. We started with 10k there. It simulated fine, but on the real thing the gates charged too slowly and the MOSFETs never fully saturated when switching quickly, which showed up as heat where we didn’t want it. The obvious fix was to drop the pull ups to 100 ohms so the gates would actually get driven.
That worked. It also meant that every time the pre driver is on, we’re pulling around 120 mA straight from 12 V through a small resistor, which is well over a watt sitting in an 0603. They got hot enough that you didn’t need a thermal camera to find them.
The annoying part is that this is first year electronics. Our simulation told us the circuit worked, and we took that as the circuit being correct. It never occurred to us to ask what the parts were dissipating, because simulation happily runs a resistor at ten times its rating and doesn’t complain. There’s no smoke in LTspice.
So the lesson we actually took away is that simulating behaviour and simulating reality are not the same thing, and that a power budget for every passive component should be part of the review before the board goes out, not something you discover with your finger. Since then, checking dissipation and package rating is a step in our schematic review, and we’ve stopped treating a clean simulation as proof that anything is fine.
Tips, tricks & offers
Following on from the last answer, the one thing we’d pass on is that the devil is always in the details, and it’s almost never the detail you were worried about.
We spent weeks on the hard parts of this project. Crank decoding, interrupt timing, getting the maps into flash safely. Those all worked. What actually cost us time was a resistor value, a missing decoupling cap on a PMIC pin, and gate drive we never questioned because the simulation was happy. The complicated things get your full attention, so they tend to be fine. The basic things get waved through, and that’s exactly where the board bites you.
So the practical version of that advice:
- Do a power budget for every part, including the passives. A resistor that works in simulation can still be running at ten times its package rating.
- Check the boring pins on your ICs. Datasheets bury requirements in the application notes, and the reference schematic is not always complete.
- Bring up a new board block by block, powered separately if you can, instead of plugging everything in and hoping. It takes longer on paper and saves days in practice.
- Write down what you tested and what the result was. Six months later, nobody remembers whether that revision was validated or just assumed to be fine.
- Review each other’s schematics, even when the other person clearly knows more than you do. Fresh eyes catch the obvious things that the designer stopped seeing weeks ago.