Embedded systems · Edge AI · Firmware
Intelligent
embedded systems
Hardware, firmware, and on-device AI engineered as one system — so intelligence runs where the data is created, inside the power budget, and keeps working when the network doesn't.
Embedded engineering services
We build systems that have to work.
AXIOMEKH develops embedded hardware, firmware, and on-device AI across microcontrollers, sensors, ultra-low-power wireless, and edge machine learning.
Founder-led, so you work directly with the principal engineer — and hear early when an approach won't survive contact with the field.
What we do
Three layers, one firm, no handoffs between vendors.
Most embedded programmes fail at the seams — between the board house, the firmware contractor, and the ML team. We hold all three, so the trade-offs get made once, by the people who have to live with them.
Solutions & use cases
Where the intelligence sits in the hardware path.
Four reference architectures for problems that do not survive a round trip to the cloud. Each one is broken down into its signal chain — the path a signal takes from the physical world to a transmitted result, and the point of every stage along the way.
Ultra-low-power edge AI module
The problem
Every battery-powered product wants on-device intelligence, and almost none can afford the power budget it normally costs. Streaming raw sensor data to the cloud drains the cell and leaks the data.
The approach
A system-on-module that keeps the radio dark. A low-power always-on stage watches the sensor stream and wakes the main inference path only on a candidate event, so the expensive work runs in short bursts measured in milliseconds rather than continuously.
Design targets
- < 100 µA
- Duty-cycled draw
- < 20 ms
- Inference window
- < 128 KB
- Model footprint
- ~10³× smaller
- Radio payload
average, 1 Hz event rate
Cortex-M4F at 64 MHz
int8, weights + arena
event vs. raw stream
Engineering targets this architecture is designed against — not measured results from a delivered system.
Signal chain
What happens between the sensor and the result.
Each stage exists to avoid doing expensive work. Cheap checks run constantly; the costly ones run only when something has earned them.
- 01Sense
Sense
The physical signal arrives — vibration, sound, or motion.
MEMS / analogue front end
- 02Condition
Condition
Clean it up and cut it into fixed windows the model can read.
Filter · calibrate · frame
- 03Wake gate
Wake gate
A cheap check running constantly, asking only whether anything happened. Almost always nothing has, so nothing else runs.
Always-on threshold, µA class
- 04Infer
Infer
The network runs — but only on the windows the gate let through.Inference
Quantised CNN, CMSIS-NN
- 05Transmit
Transmit
Send the conclusion, not the recording. The radio costs the most power, so it stays dark.
BLE event, payload in bytes
Vibration anomaly detection on the machine
The problem
Unplanned downtime is priced in hours of lost production, but retrofitting a fleet of legacy machines with cloud-connected monitoring means running network to equipment that was never meant to have it.
The approach
A self-contained sensor node that learns the machine's normal vibration signature during commissioning and reports deviation, not waveforms. No plant network dependency, no raw data leaving the floor, and a bandwidth bill that does not scale with machine count.
Design targets
- 3–5 yr
- Service life
- < 1 s
- Detection latency
- < 24 B
- Uplink volume
- None on-prem
- Network need
primary cell, 15 min cadence
from window close
per scheduled report
gateway-backhauled
Engineering targets this architecture is designed against — not measured results from a delivered system.
Signal chain
What happens between the sensor and the result.
Each stage exists to avoid doing expensive work. Cheap checks run constantly; the costly ones run only when something has earned them.
- 01Sense
Sense
Read vibration and temperature straight off the machine.
3-axis accel + temp
- 02Transform
Transform
Turn the raw waveform into a frequency signature — the shape a fault actually shows up in.
FFT · spectral features
- 03Infer
Infer
Compare that signature against what this specific machine's healthy state looks like.Inference
On-device anomaly score
- 04Decide
Decide
Hold the alarm until the deviation persists, so a single odd reading doesn't call out a technician.
Hysteresis, alarm state
- 05Report
Report
A short message over long-range radio. No plant network, no cabling to add.
LoRaWAN uplink
Hazard & environmental sensing
The problem
Detection equipment is trusted to sense what people cannot, in conditions where a false reading is not an inconvenience. Cross-sensitivity, drift, and environmental swing are what actually break these systems in the field.
The approach
Sensor fusion with compensation as a first-class design concern — the analogue front end, the calibration routine, and the classifier are engineered together, and the device reports quality-of-measurement alongside every reading rather than a bare number.
Design targets
- 1 Hz sustained
- Reading cadence
- Per-unit
- Drift correction
- Value + confidence
- Output
- Defined
- Degraded mode
continuous operation
factory + field calibration
never a bare number
sensor-fault behaviour specified
Engineering targets this architecture is designed against — not measured results from a delivered system.
Signal chain
What happens between the sensor and the result.
Each stage exists to avoid doing expensive work. Cheap checks run constantly; the costly ones run only when something has earned them.
- 01Sense
Sense
Several sensors read the same environment at once.
Multi-sensor array
- 02Compensate
Compensate
Correct for temperature, humidity, and the drift every sensor develops as it ages.
Temp · humidity · drift
- 03Fuse
Fuse
Work out what the combined readings mean when sensors disagree or respond to the wrong thing.Inference
Cross-sensitivity model
- 04Qualify
Qualify
Attach a confidence to the number before anyone acts on it.
Confidence + validity flag
- 05Alert
Alert
Warn on the device itself and pass it up the mesh.
Local + mesh uplink
Zero-trust smart-building gateway
The problem
Building automation is assembled from closed, proprietary nodes. That leaves operators with a wide attack surface they cannot audit and a vendor lock-in they cannot exit.
The approach
An open-protocol gateway that treats every connected node as untrusted. Messages are schema-validated before they reach the controller plane, and each node's traffic is scored against a learned baseline of its own normal behaviour — so a device that starts acting unlike itself is contained locally rather than trusted because it holds a valid key.
Design targets
- Zero-trust
- Trust model
- On-gateway
- Anomaly scoring
- On-premise
- Data residency
- Survives WAN loss
- Control loop
no implicit node authority
no cloud dependency
cloud optional, not required
local-first rules
Engineering targets this architecture is designed against — not measured results from a delivered system.
Signal chain
What happens between the sensor and the result.
Each stage exists to avoid doing expensive work. Cheap checks run constantly; the costly ones run only when something has earned them.
- 01Ingest
Ingest
Accept traffic from every connected device in the building.
Matter · ESPHome · MQTT
- 02Validate
Validate
Reject anything malformed before it can reach the control logic.
Schema + bounds check
- 03Profile
Profile
Learn what normal traffic looks like for each device, and score how far it has strayed.Inference
Per-node behaviour model
- 04Control
Control
Run the building's rules on-site, so it keeps working when the internet doesn't.
Local rules engine
- 05Audit
Audit
Write a tamper-evident record of what happened and when.
Signed local event log
Technology stack
The whole cross-section, silicon to screen.
What we take into an engagement. Read it bottom-up — every layer below has to hold before the one above it means anything.
Platform & Interfaces
The services and screens that make a fleet operable
Edge AI
Inference that fits in kilobytes and microwatts
Connectivity
Getting data off the device without spending the power budget
Firmware & RTOS
Real-time behaviour, memory bounds, and defined failure modes
Silicon & Hardware
The physical layer — compute, sensing, and the analogue path
About AXIOMEKH
Built for devices that think for themselves.
AXIOMEKH is a founder-led engineering firm working at the intersection of embedded hardware, firmware, and applied AI. Engagements run directly with the principal engineer — a software engineer with a U.S. military CBRN background, a discipline where equipment is trusted to detect what people cannot sense and a false reading is not an inconvenience.
That standard carries into everything we ship, including the systems with far lower stakes.
Intelligence belongs at the edge
The next decade of connected devices will not stream everything to a datacentre and wait. Latency, privacy, and power all point the same direction.
Reliable beats novel
A clever system that fails in the field is worth less than a plain one that doesn't. We optimise for the behaviour you get on day 400, not the demo on day one.
Say the hard thing early
If an approach won't survive contact with the field, the useful time to say so is before the budget is committed — not in the post-mortem.
Contact
Get your project started.
Tell us what you're trying to build. Most projects start with a conversation about the problem rather than the technology — including the honest answer when an approach won't survive contact with the field.
- 01Tell us the problem
The constraint that matters is usually power, latency, certification, or all three. Say which one you're up against.
- 02A technical reply, not a sales call
You get an engineer's read on feasibility and the risks we'd want to close first.
- 03Scope, then build
If it's a fit, we scope a phase small enough to prove the hard part before the budget commits.