Arnali Saha
Let's talk
Interested in problems where behaviour isn't obvious.
If you're working on something where the system layers don't all agree with each other — I'd like to hear about it.
Karlsruhe, Germany
Somewhere between physics and firmware, things get weird. I work there.
From electrochemistry to embedded firmware to machine learning — not because I planned it that way, but because each layer kept raising questions the one above couldn't answer.
Battery systems don't fail cleanly. They fail quietly — in the gap between what the model assumes and what the physics is actually doing. I've spent years developing a deep discomfort with that gap. It's where the most interesting engineering lives.
My background spans electrical design, embedded firmware, electrochemical research, machine learning and validation — not because I ticked boxes, but because each question I asked pulled me one layer deeper into the system.
I came from India to Karlsruhe to do my master's, built a BMS for a Formula Student race car before I really knew what I was doing, and somehow ended up doing my thesis at Mercedes-Benz modelling battery ageing with hybrid physics-ML frameworks. The thread through all of it is the same: what is the system actually doing, and why does it diverge from what we think?
It's a chain of transformations — and every link speaks a different language. I've spent years learning all of them, especially the parts where they fail to talk to each other.
ECM parameterisation, EIS analysis, ageing behaviour characterisation. Real lifecycle data — messy, incomplete, contradictory. I've learned to love the noise because that's where the ageing actually lives.
High-voltage BMS development (KA-RaceIng), state estimation logic, real-time and safety-critical constraints. Accuracy that can only run offline is a lovely idea, not an engineering solution.
HiL/SiL test environments, ISO 26262, Vector CANoe. Transient system behaviour. Model vs real-world mismatch. The most interesting failures don't happen in steady state — they happen in the edges.
My communication systems background gave me something unexpected: a healthy distrust of signals. A voltage reading is not voltage. It's a sampled, filtered, quantised approximation — shaped by hardware choices made upstream.
FPGA design (VHDL), embedded C/C++ firmware, PCB prototyping (Altium), IoT system design (ESP32). I've debugged enough hardware-firmware interaction to take the acquisition layer seriously before touching a dataset.
Hybrid ECM + ML frameworks, anomaly detection (Isolation Forest), synthetic data generation. I don't think of ML as a shortcut. I think of it as a different kind of question — one you ask where physics runs out of language.
This isn't a list of jobs. It's a series of questions — each one pulling me one layer deeper.
Hardware doesn't behave the way theory says it should. That gap is where the learning happens. Built a self-balancing UAV, a hexapod robot, published at an international conference, won a hackathon with Amazon and NIT Trichy.
Electrical schematics, control diagrams, industrial automation. The difference between a system that works and one that works reliably became an obsession.
Every semester raised a question the previous one couldn't answer. Ended with an ML thesis validated inside an automotive production environment.
Designed the HVBMS from scratch — PCB hardware, protection circuitry, embedded C++ firmware. Shipped something that ran races without catching fire.
First sustained exposure to real electrochemical data — noisy, ambiguous, refusing to match expectations cleanly. I started asking why measurement and model disagreed.
Python automation for battery module assembly, Docker containerisation, traceability databases. Factory-floor decisions echo into downstream diagnostics.
HiL/SiL validation of safety-critical BMS under dynamic profiles. EIS-based temperature estimation research taught me more about electrochemical measurement than any course.
EIS and polarisation measurements on PEM fuel cells. The underlying questions about degradation are the same regardless of whether the chemistry is lithium-ion or polymer electrolyte.
Extended ECM power prediction from impedance data. Understanding why models fail to generalise — and detecting when they're about to — became the thread I carried into my thesis.
ML-based battery lifecycle diagnostics. 98% model–measurement correlation. The answer to every question I'd been asking since IAM-ESS.
Built a full-stack IoT sensor system from scratch — ESP32 microcontrollers reading soil, temperature, and light data over WiFi and TCP/IP, feeding into cloud LLM APIs for natural language diagnostics. N8N pipelines tie the whole thing together end-to-end.
Not because it was required. Because the gap between raw sensor data and a model that can explain what it means in plain language is exactly the kind of gap I like closing.
Every battery that reaches end-of-life arrives with the same documentation: numbers. SOH curves. Impedance plots. Capacity fade tables. And every engineer who receives it has to do the same mental work — reconstruct the story, decide what actually happened inside. I kept thinking there had to be a better way. Not another dashboard. Not another plot. A readable, continuously updated account of what is happening physically, grounded in measured behaviour. So I started building it.
R0, RC dynamics, diffusion signatures — captured weekly, automatically.
I'm looking for environments where someone needs to hold the whole chain in their head — physics, implementation, data, model — and ask uncomfortable questions about where it breaks.
Competitive Olympic air-pistol shooting teaches you something that no engineering course does: how to be completely still while your body refuses to cooperate. You learn to work with imperfection rather than wait for it to disappear. It's the same skill I use when the model and the data don't agree.
I write music — bass, vocals, lyrics. I've learned that structure and intuition aren't opposites. The most interesting things happen when they argue with each other. Which is also, it turns out, how the best engineering problems work.
Probably because I think the hardest skill in engineering is making something complex legible. When you work across physics, signals, firmware, and data all at once, you need a visual language to make it communicable. I find it easier to practise that in a medium where the feedback is immediate.
If you're working on something where the system layers don't all agree with each other — I'd like to hear about it.