Hardware & Device Development
We take a physical product from requirements to a working prototype that has actually been measured — circuit design, firmware, mechanical design, and the software behind it. Sensing devices are where we go deepest, because we built one ourselves and published what it does. The same engineering applies to products that have nothing to do with sound.
Why this transfers
Four things make a device hard to build. Our own product needed all four.
Timing
Several sensors that have to be compared, not merely read. That means one clock across all of them, because the comparison is only as good as the clock behind it.
Geometry
Where a sensor physically sits is part of what it measures. Mechanical design is then an engineering problem rather than a packaging one.
Processing on the device
The answer has to be computed where the data is, because moving all of it somewhere else is not an option — no bandwidth, no power, or no connection.
The field
It has to work outdoors, against something real, and be measured against an independent reference rather than declared working.
Most devices need one or two of these. Ours needed all four, and all four are held here: the boards, the firmware, the enclosure, and the field testing. That is the reason to bring us a product with nothing to do with acoustics. Its physics will be different; the loop that takes a device from architecture through measurement and failure analysis to a revised board is the same.
What we do
Hardware and the software that runs on it — as much or as little of the stack as you need.
Engagements usually start at one of these points and grow. If the hardware already exists and only needs the firmware on it, start with Firmware & Embedded Software below.
Embedded Engineering
The whole system — board and the software on it, from architecture through hardware prototyping to a working device.
Firmware & Embedded Software
On boards we build with you or on hardware that already exists: bring-up through to a stable, field-ready image.
PCB Design
Schematic capture and layout, from concept to a board that is actually manufacturable.
3D CAD Design
Enclosures, mechanical parts and product geometry modelled in FreeCAD, printed here, and fitted against the electronics.
Sensor System Development
Multi-sensor systems, sensor fusion, and signal processing that runs on the device.
Connected Device Development
One product end to end — device, firmware, and the service behind it.
Where this gets used
Sensing devices first, because that is where the experience is. The discipline is not specific to sound.
Detection and situational awareness
Passive acoustic detection and direction finding, perimeter and site monitoring, vehicle and machinery signatures, event localization. Defence, critical infrastructure, airports and ports — the family our own product belongs to.
Industrial and process sensing
Condition monitoring on rotating machinery, vibration and acoustic signatures that show a bearing failing before it fails, flow and pressure in pipes, leak detection, tank and silo level, and retrofit sensing on machines that were never built to report anything.
Safety and environment
Gas and chemical detection, air quality and particulates, water quality, noise and radiation monitoring. Long deployments, tight power budgets, and readings that somebody has to be able to act on.
Consumer and professional devices
Anything with a microcontroller, a sensor, a battery and an interface: audio devices, wearables, handhelds, connected home hardware, professional tools. Fewer constraints than an eight-channel array, and the same discipline.
Instruments, loggers and test equipment
Bench and field instruments, data loggers, automated test rigs and calibration fixtures. Small volumes, high correctness requirements, and buyers who read the methodology before they read the price.
Connected equipment
Machines that have to report: gateways, telemetry, asset and fleet monitoring, and equipment that talks to a platform — which we can build as well, rather than hand to somebody else.
The sensing element itself is usually the part we integrate, not the part that is hard. We have not built a gas sensor. We have built everything that sits around one — acquisition, timing, processing, the enclosure, and the field validation — and that is normally what decides whether a sensing product works.
The transducer changes. The engineering around it does not.
What we have actually built
Three board designs and the enclosure around them — modelled, assembled, and measured in-house.
And the bench it came off
These are the boards and parts behind our own sensing platform. They were designed here, sourced here, assembled here, brought up here, and revised on what the testing showed — then measured against RTK-GPS ground truth, with the results and their limits published rather than asserted.
That full cycle is the point. Plenty of people can produce a layout. Far fewer have sourced the BOM, placed the parts, found out what was wrong on the bench, and spun the revision that fixed it.
The mechanical side is ours too. The enclosure above was modelled in FreeCAD as an engineering part, not a shell drawn around the electronics: microphone seats placed to the array geometry, recessed, and the acoustic depth in front of every microphone held at 3.2 mm so all eight channels see the same path. More complex geometry has been built than this, including the faceted array above, assembled from roughly fifty-five reference planes.
See the product and its measurements →What that means for your device
The left column is ours. The right column is what it buys you.
| What we built | What it means for your device |
|---|---|
| Eight microphones sampled on one shared clock | Any product where several sensors have to agree in time, not merely report one after another. |
| A second unit held in the same time domain across tens of metres of ordinary cable | Distributed devices that stay in step without GNSS timing or a wireless synchronization scheme. |
| Acoustic depth held at 3.2 mm across all eight seats | Mechanical design driven by the physics of the measurement, not drawn around a finished board. |
| Ten CAD models, 297 constrained sketches, three design generations | Enclosures and mechanical parts that go through real iteration — printed, fitted and revised alongside the electronics. |
| Three board designs sourced, assembled, brought up and revised here | Your board gets built and measured, not exported as Gerbers and hoped for. |
| Detection and bearing computed on the node itself | Processing on the device, so the product still works when the connection does not. |
| Validated against RTK-GPS ground truth, limits published | You get told what your device actually does — including where it stops working. |
The whole picture
A product is rarely only hardware. Four layers, and we build all of them.
Hardware — this section
SENSOR & BOARD
analog front end, acquisition, power, interfaces
FIRMWARE
real-time capture, processing on the device
Software — the other section
DATA & BACKEND
where readings go, and what happens to them
INTERFACE
the web or app somebody actually uses
The last two layers are our software side — applications, backends and integrations, plus the site that has to explain the product once it exists. See Software Engineering & Web Development →
How a board gets made here
The same sequence whether it is our hardware or yours.
- 01
Requirements and architecture
What the device has to measure or do, under what constraints — power, size, environment, cost, and what it has to talk to.
- 02
Schematic and part selection
Components chosen for availability and lifecycle as much as for datasheet performance. A perfect part you cannot buy is not a part.
- 03
Layout
Placement and routing done against the physics — return paths, impedance, and thermal behaviour — not just design-rule compliance.
- 04
Mechanical design
Enclosure and mounting modelled in CAD around the electronics and whatever the sensor physically needs — printed, fitted, and adjusted alongside the board rather than after it.
- 05
Sourcing and assembly
BOM sourced and boards populated in-house for prototype quantities, which keeps the loop between a design decision and a physical board short.
- 06
Bring-up and test
Power up, prove each subsystem, then measure it. Findings get written down, including the ones that are inconvenient.
- 07
Revision
A second spin informed by what the bench actually showed. Boards that have never been revised have usually never been tested properly.
Why Nodomic
Most engineering services are sold on capability described in the abstract. Ours is sold on a device you can look at: the boards above exist, they work, and the numbers taken with them are published with their limits stated.
The company is small and founder-led, which means design, assembly, bring-up and the report on what went wrong stay in the same hands. There is no layer in between to lose information. More on who builds this →
Have a device in mind?
Bring the constraints and whatever exists already — a sketch, a spec, a board that half works. You get an honest read on feasibility, approach, and whether we are the right people for it.
Discuss a project →