Firmware and board bring-up
Getting a new board from first power-on to something that behaves reliably — start-up, storage, communication between chips, and working out what's wrong when a board doesn't do what the schematic says it should.
What I work on
The areas I've spent most of my time in
Most of my work sits between hardware and software, where it isn't obvious which side a problem belongs to. These are the areas I've built up so far, and the ones I'd like to keep developing.
Real-time sensor data
Getting a continuous stream of data off hardware, through processing, and into a usable result quickly enough to matter — without dropping data, and without the whole thing falling over when something upstream misbehaves.
Desktop and mobile applications
The layer where the hardware becomes something a person can use. Architecture and the interface, plus the less visible parts — packaging, releases, and logging that lets someone else work out what went wrong.
Regulated medical device software
Working under IEC 62304 and ISO 13485 — the documentation, risk analysis and traceability that turn research code into something a regulator will accept. I've learned a lot from this and would like to keep working in it.
Build and release process
Build pipelines, release procedures, documentation and internal tools. Usually because I've picked up something fragile and would rather not have to pick it up again.
Debugging
Intermittent faults, faults that only show up in the field, and faults where the obvious explanations have already been ruled out. This is the work I get asked for most, and the work I most want to get better at.
Projects
What I've worked on
All at EarSwitch Ltd, a Bristol medtech company working on in-ear sensing technology. It was started by a GP after seeing motor neurone disease patients lose the ability to communicate. There are two product lines and I've worked across both.
A clinical vital-signs monitoring device
Taking a research prototype and getting it to a state where it could be used in a clinical study — while it was still being actively developed.
The device measures vital signs from ear-based sensors. When I started on it, it was research code. It worked, in the sense that it produced numbers, but nothing about it was ready for use in a study. My job was that transition: getting it to a point where it could support a UK regulatory submission, and where the software's behaviour was documented rather than just observed.
That was two kinds of work at the same time. The engineering side was making the data pipeline reliable enough to run continuously without losing frames, and building the on-device display that shows readings and warnings to whoever is running the session. The regulatory side was the development plan, the risk analysis, and the record connecting each requirement to a test proving it was met.
What I did
- The software transition — from research code to software meeting medical device requirements, on a device that was still changing while I worked on it.
- The real-time pipeline — capture and analysis running at the same time, restructured so the two don't get in each other's way.
- The regulatory documentation — development plan, procedures, risk analysis, configuration management and traceability through to verification.
- Requirements work across a team of clinical, hardware and software people who didn't share a vocabulary at the start.
- Support for deployed devices — diagnosing and fixing issues on units already in the field, under change control.
What was hard about it
Two pressures that pull against each other. Regulated development wants things specified before they're built; an early-stage device wants to keep changing. Managing both meant being clear about what was frozen and what wasn't, and being upfront with the team about which was which.
An assistive gaming controller
A device that lets you trigger a game action with an ear movement — aimed at streamers, and at players who can't reliably use their hands.
This is the commercial side of the business, and I'm the only software engineer on it. That means the whole stack: the firmware on the custom board, the protocol it uses to talk to a computer, the Windows application most people will use, and the Android app for playing on a phone or tablet.
The main constraint is that it has to feel instant and it can't misfire. An assistive input device that occasionally misses is worse than not having one, so most of the effort goes into reliability rather than features.
What I did
- Firmware for the custom board — start-up, storage, communication with the host, and the process for provisioning new units in production.
- The Windows application — architecture designed from scratch so it could absorb changing requirements without rewrites, plus detection, per-user calibration, packaging and releases.
- The Android application — from the product spec through architecture and build to preparing it for store release, including the accessibility permissions the product depends on.
- Consistency across platforms — making sure the device behaves the same whether it's plugged into a PC or a phone, which was harder than building either.
- Release process — automated builds and checks, versioned artifacts, and a written procedure so releasing isn't done from memory.
- User testing with domain consultants, and using it to prioritise the interface work.
What was hard about it
Deciding what not to build. Early on the product vision included things the platforms don't actually allow. I put together a prioritised breakdown, was clear about which requirements weren't achievable and why, and suggested alternatives, so the schedule was based on what was possible.
The research project both products came out of
A funded research programme looking at health metrics from ear-based sensors, and the prototype software that made the results visible to everyone else on the team.
I was the software person on a Healthy Ageing research project, working with clinicians and hardware engineers. The output was a working proof of concept: an application that pulled in live sensor data, processed it, and displayed the results so a non-engineer could read and question them. I also built cross-platform tools the wider team used to check sensor data over different connection types.
I set up the basic engineering practices too — version control and written procedures for a team where most people hadn't worked that way before. Not glamorous, but it's the reason the later regulated work was possible.
Something I got wrong
I picked a heavy web framework for the prototype interface. It was a reasonable choice for a quick demo on a laptop and the wrong one once the target moved to constrained hardware — the processing core ported over fine, but the interface had to be rebuilt from scratch.
The real mistake was earlier than the rebuild. On a project with that many unknowns I should have checked where the software would eventually have to run before committing to a framework. It's changed how I approach these decisions: keep the tested core separate from the interface, and ask about the hardware target before the demo target.
Problems I've worked on
A few worth mentioning
Short versions here. I'm happy to go through any of them properly in a conversation.
A chip taking over a shared connection
Programming new units kept failing partway through, at a different point each time. I went through nine plausible explanations and ruled each one out by testing it before the real cause turned up: a neighbouring chip was taking over the shared connection about a second after power-up, regardless of what anyone else was doing with it.
The workaround got production moving the same week, and the permanent fix went into the next hardware revision.
What I took from it: the test that found it was the one that observed the system directly instead of reasoning about it. It should have been my first test, not my ninth.A clock that reported itself as fine
Devices already deployed for a clinical study were intermittently losing track of time, which is a bad fault to have anywhere near a data record. The system reported the clock as healthy the whole time.
The hardware had a warning signal for exactly this condition and the software layer above it was swallowing that warning. The underlying cause was mundane. The fix went out to deployed units along with a written analysis and a test procedure, so it's now something that gets checked rather than something one person happens to remember.
What I took from it: a component reporting itself as healthy isn't the same as it being healthy. The work wasn't the fix, it was making the failure visible.The same code behaving differently on two platforms
The same detection logic was noticeably more sensitive on mobile than on desktop, which meant someone plugging the device into a phone was effectively getting a different product.
Working through it under deadline pressure, I traced it back to an optimisation I'd made myself that had raised the noise level in the data without anyone noticing. Corrected, and the two brought back in line.
What I took from it: the cause being my own change is the point. Checking there early would have been quicker than checking there last.Setting up process where none was required
The regulated product has standards forcing discipline on it. The consumer product had nothing forcing anything, which is how early-stage software ends up unmaintainable but shipped anyway.
I set up build automation, a release procedure, interface documentation and a record of design decisions for the commercial software — taking the parts of regulated practice that are worth having and leaving out the parts that only exist to satisfy an auditor.
What I took from it: working under a formal standard teaches you which process is doing real work. What I wanted was software someone other than me could maintain.How I work
Raising things early
When a system's requirements outrun what the platform can actually do, I'd rather say so early than quietly try to make it work.
It sounds obvious and it often doesn't happen, because the early conversation is the uncomfortable one. But a scope problem raised in month one is a planning decision, and the same problem raised in month six is a failure. I'd rather bring a prioritised breakdown and a concrete alternative than deliver a surprise later on.
The same thing applies to debugging. If two things behave differently, say so as soon as you notice, find out why, and don't ship both hoping nobody spots it.
About
A bit more about me
The thread running through most of my work is finding hidden or unclear system state and making it visible.
A signal buried in raw sensor data. A chip quietly taking over a connection it was supposed to share. A fault that reads as healthy while producing invalid results. It's usually the same shape of problem: work out what's actually happening, prove it, build something reliable on top of it, and write it down so the next person doesn't have to find it again.
I've been at EarSwitch for three years, working closely with the CTO across firmware, signal processing, application software and regulatory documentation. Before that I did an MSc in Computer Science and an undergraduate degree in electronics and instrumentation engineering.
What I'd like next is a role with more people around me to learn from. Working as the only software engineer on a product has taught me a lot and forced me to cover ground quickly, but I've had limited exposure to code review from more experienced engineers and to established engineering practice in a larger team. That's the main thing I'm looking for.
Languages
C · C++ · C# (.NET) · Python · Kotlin/Java · JavaScript/TypeScript
Embedded & hardware
ARM Cortex-M · STM32 · FreeRTOS · ESP-IDF · bare-metal firmware · Linux single-board computers · sensor and camera interfacing · serial bus protocols · Bluetooth · hardware debugging and logic analysis · EMC testing
Applications
WPF / .NET · Android · PyQt · Electron · REST and gRPC services · AWS
Signal & data
Real-time acquisition pipelines · on-device detection and classification · calibration · concurrency and latency-bounded processing
Practice
System design · architecture documentation · code review · testing · CI/CD and release engineering · root-cause analysis · technical writing
Standards & quality
IEC 62304 · ISO 13485 · ISO 14971 · risk analysis · safety-critical design · traceability
Education
- MSc Computer Science — Queen Mary University of London. Distinction. Thesis: classifying musical emotion from EEG and survey data using a hybrid deep learning model.
- BTech Electronics & Instrumentation Engineering — Amrita School of Engineering, Bangalore. 2017–2021. Instrumentation internship at ONGC.
Also
- AI in medtech startupsA talk I gave at a company strategy offsite on practical adoption, risk, and what transfers into a regulated environment.
- AI tooling rolloutRisk assessment, a written governance procedure and a team-wide rollout, presented to the CTO.
Personal projects
Things I've built outside work
Small projects, mostly built either to learn something properly or to solve a problem I had.
Bare-metal firmware projectC · ARM Cortex-M
Firmware written directly against the hardware with no vendor abstraction layer — peripherals, interrupts, boot sequence and memory layout set up from scratch. I built it to understand what the usual libraries are doing on my behalf.
Working
Wireless audio deviceC · FreeRTOS · ESP-IDF
A Bluetooth audio device with a small display and playback controls, built on a real-time operating system. I'm currently adding microphone input and frequency analysis for basic sound classification.
In progress
Project MapHTML · CSS · JS
A local mind-mapping tool for software projects — modules, tasks and risks as nodes, with readiness states and completion tracking. One self-contained file, nothing to install.
Working
Sponsor CheckerJS · Chrome extension
A browser extension that cross-references job listings against the Home Office licensed sponsor register. I built it to solve a real constraint in my own job search.
Working
Contact
I'm looking for my next role — get in touch.
Bristol-based, interested in embedded, systems and firmware-to-application work. Happy to talk through any of the projects above in more detail.