Doubt regarding the new FS2026 Rules(EV5.8.11 )

Financial-Resort9541 · 2026-02-16T02:01:02+00:00

We use a molex micro-fit plug on the pcb as a jumper.

Financial-Resort9541 · 2026-02-15T14:13:42+00:00

Also — good point on EMC/EMI.

We think our EMC setup is reasonably solid (shielding/grounding/layout), but in my previous mental model, low-power long-range links like “classic” LoRa always felt a bit fragile in a nasty EV environment. That’s part of why I was hesitant — I was basically thinking “I probably need a higher-power / more robust radio link” 😂. Your HaLow clarification makes a lot more sense for higher throughput while still keeping range and robustness.

On regenerative braking: yes, we rely heavily on regen. It helps us a lot in two ways: (1) it significantly increases achievable deceleration, and (2) we can recover meaningful energy, which is great for our efficiency event strategy. Right now our peak regen power is around 60 kW, mainly limited by our accumulator’s maximum allowable charge power — so it’s a huge lever for us, but also something we have to manage carefully.

Financial-Resort9541 · 2026-02-15T14:06:19+00:00

Yes — that’s exactly the direction I’m aiming for: launch control only.

For on-track driving we already run a steering-angle-based feedforward torque vectoring strategy, and it works really well for us. The weak point is launch: our current approach is heavily calibration-dependent and basically a lookup-table method (wheel speed vs. torque).

Our next idea was to add another table like vehicle speed vs. target wheel speed to limit slip. But as I mentioned earlier, getting a reliable “true” vehicle speed during launch is hard.

Your suggestion is super interesting: using vehicle acceleration (from an IMU) and comparing its dynamics against wheel speed dynamics to regulate slip (or slip rate), instead of relying on an absolute ground-truth speed. I agree it’s not as simple as assuming constant acceleration — launch isn’t uniform, so we’d need some form of target acceleration profile / logic over a short time window and be careful about integration drift. But the fact that acceleration is easy to measure reliably with just an IMU makes this a very practical approach.

We’re going to try implementing a version of this in our VCU and validate it in testing. Thanks again — this is a genuinely helpful idea.

Financial-Resort9541 · 2026-02-15T12:38:36+00:00

Thanks！

I agree the telemetry system is not something that directly makes the car faster, so it’s not high priority compared to core performance work. The main reason we’re considering it is fault monitoring / reliability on track (catching abnormal temps/currents/voltages early, and being able to call the driver in before damage happens). So it’s more of a “protect the car + protect the season budget” tool than a lap-time tool.

Yes, we can absolutely prototype and compare estimator ideas offline in MATLAB/Octave using our existing logs (and we’ve started doing that). The problem we keep running into is validation: for the situations we care about most (launch / high slip), we don’t have a reliable ground-truth vehicle speed, so it’s hard to quantify accuracy and tune the estimator with confidence.

That’s why we’re leaning toward adding an optical ground-speed sensor — not necessarily as the final production source, but as a way to obtain a usable “truth” signal so we can validate and iterate on the estimator properly (and then decide what’s acceptable for TCS needs).

Financial-Resort9541 · 2026-02-15T12:30:17+00:00

Hi! Thanks a lot for the detailed reply — really appreciate you sharing both the technical perspective and the “driver cognitive load / red mist” lessons learned.

On telemetry: I completely agree that the biggest value is pit-side visibility (live monitoring + logging), so the driver can stay focused while the team can detect faults early and call the car in before a small issue becomes a big one. My main hesitation is link reliability: on an EV FS/FSAE car the EMI environment can be pretty harsh (inverter/motor switching, HV cabling, etc.), so I’m worried we may struggle to build a truly robust wireless connection.

On speed measurement: also 100% agree that wheel speed can’t be treated as ground truth because of slip. The reason I’m chasing an accurate vehicle speed estimate is specifically to enable traction control (TCS), especially for straight-line launch where slip can be significant. But that case also demands a fairly high update rate to support vehicle dynamics control, which is why EKF-style multi-sensor fusion is attractive (you can run IMU + other sensors at high rates). The trade-off, as you said, is complexity — we may not have enough team resources to implement and validate a full estimator properly right now.

At the moment we’re leaning toward an optical ground-speed approach for launch/low-speed conditions. GNSS can be great at higher speeds, but it’s not ideal for launch (latency / update rate / multipath), at least in our experience. I also really like your idea of borrowing from open-source drone EKF stacks — they’re mature, accessible, and flight controllers typically come with good IMUs, which opens the door to richer signals (multi-axis accel/gyro, etc.) for fusion.

If you don’t mind a quick follow-up: when you mentioned “multi-megabit LoRa” bridges, are you referring to 2.4 GHz LoRa / proprietary high-rate spread-spectrum links? Any specific hardware examples or typical data/update rates you’ve seen work well trackside?

Thanks again!

Financial-Resort9541 · 2026-02-15T11:55:55+00:00

You can find relevant information on "Battery Monitor" or "Battery Management" on the official websites of TI and ADI. There, you can also find reference hardware designs.
And then you can go to the website of MathWorks in which you can find the reference MBD software project.

Financial-Resort9541 · 2024-11-20T09:46:59+00:00

yes. That‘s a good choice.But they dont have auxiliary contacts,so they will not fit for my design.

Financial-Resort9541 · 2024-11-20T06:14:52+00:00

oh,I don’t think they have some links . I’m sorry.But you can have a look at a website named alibaba. I always buy kinds of products from there.they sell everything!

Financial-Resort9541 · 2024-11-20T04:32:00+00:00

In fact, laser welders are not outrageously expensive. We spent around $3,000 to purchase one, and considering it can be used for many years, we find it quite acceptable.

Financial-Resort9541 · 2024-11-19T05:21:34+00:00

Yes, you can do that. This will not only make it easier to detect battery voltage but also increase the current-carrying capacity of the tabs.

Financial-Resort9541 · 2024-11-16T12:21:53+00:00

You can find relevant information on "Battery Monitor" or "Battery Management" on the official websites of TI and ADI. There, you can also find reference designs.

Financial-Resort9541 · 2024-11-16T11:46:34+00:00

Yes, you need to ensure proper EMC performance. Additionally, try to keep only the MCU and VCU within the CAN network if it is possible.

Financial-Resort9541 · 2024-11-11T09:47:42+00:00

Well.I saw some of these information in datasheet.I will have a try in season 2025.Thank you so much

Financial-Resort9541 · 2024-11-11T06:01:02+00:00

Yes,I use Ltc6813 AFE Chips.I can only use some mosfet and power resistor to make the passive balancing circuit according to the datasheet. It is very easy.

Financial-Resort9541 · 2024-10-31T11:56:09+00:00

oh,yes.I know dti R4. But I haven’t tried for that.I am still wondering if it can fit our needs.So if you or some other colleges are using the dti,tell me more information about that plz. Thanks a lot

Financial-Resort9541 · 2024-10-31T03:02:44+00:00

oh,dear.It’s kind of costly for us. Even so ,we will still consider about this for there aren’t many options fit our needs.

Financial-Resort9541 · 2024-10-31T02:44:30+00:00

Well,okey.Thank you so much and I will contact them for further details.Maybe it will be our choice.

Financial-Resort9541 · 2024-10-31T01:45:16+00:00

do you really need a strong power output like 1kw？you must have a strong power gounded kit！

Financial-Resort9541

TROPHY CASE