From Woodworking Machines to Fault Diagnosis

I didn't set out to become a researcher. I set out to keep a wood dryer from ruining a batch of lumber at two in the morning.

That's not a metaphor. For over ten years I've chaired the board of Venonwood, a company I founded to design and build woodworking machinery. Somewhere along the way we ended up designing and implementing the control systems for more than 200 industrial wood dryers — the kind of machines that run for 25 days straight, holding temperature and humidity inside a tight band while a few thousand board-feet of lumber slowly gives up its moisture. Get it wrong and you don't get a warning label. You get warped, cracked, unsellable wood, and a very unhappy customer.

What the machines actually taught me

Engineering school teaches you the equations. It doesn't really teach you what a 25-day process feels like when you're the one responsible for it not failing.

What I learned instead, from years of actually running these systems, is that almost nothing fails the way you'd expect from a textbook. A sensor drifts slowly instead of dying cleanly. A fan bearing starts making a sound three weeks before it seizes, if you know what to listen for. A boiler's response curve changes shape a little at a time as scale builds up inside it, and by the time the temperature overshoot is obvious, you've already lost a batch. The failure is never really sudden — it's just that nobody was watching the right signal early enough to see it coming.

That's the problem that actually grabbed me. Not "how do I control this system" — I already knew how to do that. It was "how do I know, from the data this system is already producing, that something is starting to go wrong, before it costs me anything."

From boilers to signal processing

I'd already picked up a lot of the pieces without calling them research. Building control systems for wood dryers and industrial boilers meant living inside Simulink and MATLAB. Automating temperature and humidity monitoring at industrial scale meant getting genuinely good with Raspberry Pi, microcontrollers, and Arduino — reading sensors, closing control loops, logging enough data to actually see what a system was doing over weeks, not seconds. None of that was academic. It was just what the job required.

The turn toward formal research happened because I kept running into the same wall: the tools I had were good at controlling a known system, but bad at telling me when the system itself was quietly changing underneath me. That's a different problem — it's fault diagnosis and condition monitoring, not control — and it needed a different toolkit: signal processing, feature extraction, and eventually machine learning applied to the actual waveforms a machine produces, not just its setpoint error.

That's what took me back to school. I did a master's in aerospace engineering — a different domain, but the same instinct, since combustion instability is its own kind of signal you have to understand before you can trust a system around it. And it's what I'm doing now in my PhD at the University of Guilan, working with Dr. Ali Chaibakhsh and, through a collaboration with the Intelligent Control, Analysis, and Modeling (iCAM) Lab at the University of Windsor, with Dr. Afshin Rahimi. My current focus is physics-guided transformer networks for diagnosing and forecasting problems in heavy-duty aero engines — which sounds like a long way from a wood dryer in a shop in Iran, until you notice it's the exact same question I was asking back then, just with a much harder machine and a much bigger cost of getting it wrong.

Along the way, that same instinct — "what is this signal actually telling me" — has shown up in places I didn't plan for. Some of my published work is on classifying EEG signals for brain-computer interfaces: different sensor, different machine (a person, this time), same underlying problem of separating a real signal from noise you don't care about.

Why this still feels like the same job

I still think about research the way I thought about that wood dryer at two in the morning. The question that matters isn't "does the model have high accuracy on a benchmark." It's "would this actually tell someone, in time, that something's about to go wrong." Everything I build — the control systems at Venonwood, the diagnostic models in my PhD, even Dashcaf, which exists so other people can simulate and test these ideas without needing my particular ten years of scar tissue — comes back to that same test.

I don't think of "researcher" and "the guy who used to fix boiler control loops at 2am" as two different people. They're the same job, just at different scales. That's the through-line, and it's the reason I don't think I'll ever stop building things alongside the papers.