AI & edge systems
Inference that runs on the device, inside the control loop, within a power budget that survives contact with a real product.
Intelligence is moving into the device. Not because the cloud stopped working, but because a machine that has to react in two milliseconds, keep running when the link drops, and never send its images anywhere cannot wait for a round trip.
That shift turns a data-science problem into an engineering one. The model has to fit in flash. The inference has to finish inside the control loop. The sensor data has to arrive conditioned and time-stamped. The enclosure has to dissipate the heat of running inference continuously, in a factory, in August.
Those are the constraints we design against — and because we build the board, the firmware and the logic as well, they are decided together rather than negotiated between three suppliers.
Where the inference runs
Microcontroller
Cortex-M class devices running quantised, pruned models. Vibration signatures, audio events, anomaly scores — where the answer is small and the power budget is a coin cell.
Application SoC / NPU
When there is a camera, a screen, or more than one model in flight. We build the board, the Yocto image, the accelerator integration and the pipeline that keeps the frames moving.
FPGA
Line-scan cameras, multi-sensor fronts, and decisions that must happen in microseconds every time rather than usually. Inference sits on the data path instead of behind it.
How we run an edge AI project
Before any model, we put sensors on your machine and capture real data in the real environment. A model trained on a clean dataset fails on a factory floor in August.
What accuracy is actually required, at what latency, in what power envelope? These three numbers decide the silicon, and they are cheaper to argue about now than after the board exists.
MCU, SoC or FPGA — and sometimes none of them. If a well-tuned signal-processing algorithm beats a neural network here, we will tell you, and it will be smaller and easier to certify.
Memory, flash, thermal path, power rails and sensor front end sized for continuous inference, not for the datasheet idle figure.
Capture, conditioning, time-stamping, pre-processing, inference, post-processing, decision — written as production firmware, in version control, with tests.
Latency, jitter, current draw, accuracy on held-out field data, behaviour at temperature. Reported as numbers you can put in front of your own customer.
On-device capture of hard cases, a path for retraining, and a secure update mechanism so an improved model can actually reach the fleet.
Straight answers
Often not. A threshold, a filter or a well-chosen transform solves a surprising number of problems with a fraction of the memory, no training data and a far easier certification story. We check that first — it is a shorter and cheaper project for you, and we would rather be trusted than booked.
This is usually the real project risk. If you have no representative field data, the first phase is building the capture rig, not the model. We plan for that explicitly instead of discovering it in month three.
On-device when latency, availability, bandwidth cost or data privacy make the round trip unacceptable. Hybrid when heavy analysis can be deferred. We will happily talk you out of on-device inference if your constraints do not require it.
You do — weights, training scripts, dataset and the pipeline around them, in the same handover as the schematics and the firmware.
Get in touch
Send us the constraint that matters — the latency, the power budget, the accuracy you need — and we will tell you what is realistic on which silicon, before anyone signs anything.
