Hardware / Connected Device Development

Connected Device Development

Firmware, embedded software, the service behind the device, and the device itself — owned by one team, not split across three vendors who each blame the others when something does not work.

What this covers

Device firmware and embedded software
The backend the device reports to
Mobile or web interface
Physical device design, built here in prototype quantities
Pre-compliance design for CE / FCC / EMC
Field updates and recovery

Where connected-device projects go wrong

Rarely inside any one of the four layers. Almost always in the joint between two of them.

The device

HARDWARE

sensors, board, power, enclosure

FIRMWARE

what runs on it, unattended, for years

The service

BACKEND

where readings land and what happens to them

INTERFACE

the web or app somebody actually uses

Split these across separate suppliers and the boundary between firmware and backend becomes a contract nobody owns. It is where the schedule goes: the protocol drifts, the timestamps disagree, an update bricks a unit in the field, and each side can show that their half works.

What actually breaks at the seam

Protocol drift

The device sends one shape of message, the backend expects another, and each was right when it was written. Owning both means the change lands on both sides in the same afternoon.

Time and identity

Whose clock is authoritative, and how a reading is tied to the unit that took it. Cheap to decide early, expensive to retrofit once there is a year of data.

Updates and rollback

A device that cannot be updated safely is a device that will not be updated. A failed update has to end with a working unit, not a site visit.

Volume and cost

What the device sends, how often, and what that costs over a fleet. Usually the argument for computing more on the device and sending less.

We have done this to ourselves first

The finished sensor node, closed, with its status LED lit — The deviceEnclosure, boards and firmware developed together rather than in sequence.

A hand holding the underside of a node top plate with microphone carrier boards mounted around its edge — And what is inside itSensors seated to a geometry that the mechanical design exists to hold.

Our own product is a connected device: sensing hardware we designed, firmware we wrote, results computed on the node, and a second node held in the same time domain. Every seam in that list is one we have had to get right ourselves, in both directions, with nobody else to hand the problem to.

What we are not is a hosting company. We build the service your device reports to and hand it over running on infrastructure you own, with the documentation to keep it. Boards are assembled here in prototype quantities for development and testing, not at production volume — when a design is ready for series production we prepare the documentation and work with your manufacturer rather than pretending to be one. We design with CE, FCC and EMC in mind and prepare for testing; the formal testing is carried out by accredited third parties.

See the device and its measurements →

Embedded Engineering

Architecture, part selection and hardware bring-up.

Sensor System Development

Multi-sensor systems and processing on the device.

One product, four layers?

Bring whatever exists — a sketch, a spec, a board that half works, or an app with no device under it. You get an honest read on what the seams will cost and where the risk actually sits.

Discuss a project →