Observe a physical condition
Read a sensor on a defined schedule, flag an out-of-range value and show the responsible operator what happened.
- Sample and check
- Buffer through a network outage
- Review the event in the admin
DEVICE · FIRMWARE · CONNECTED SOFTWARE
Connect what the device does to what the team needs to see
We scope sensing, control, firmware and communication around the environment where a device will run. Start by proving the critical hardware path, then decide whether custom PCB work, edge processing and connected software belong in the next stage.
At the device
Sensors · Firmware · Local control
Communication
Device identity · Recovery
For the operator
App / Web · Review · Action
BUILT AROUND THE WORK
Where this work starts
Define the device action before choosing the board
The first decision is what must be sensed or controlled, under which power and network conditions, and what happens when a connection fails.
- A physical process needs reliable sensing or control
- An existing device needs status reporting and remote operations
- A prototype must prove power, communication and software integration
EXAMPLE WORKFLOWS
Three device tasks worth validating
These illustrate possible scopes, not completed client hardware. Each follows the signal from a physical event to an accountable action.
Example workflows · no client device implied
Control with a manual override
A device receives an authorized command, reports its actual state and retains a local way to stop or override automation.
- Authorize the command
- Confirm device state
- Keep local override available
Connect an existing device
Expose useful status and maintenance events from a supported device through a gateway or documented interface.
- Audit the device interface
- Map events and identity
- Show actionable status to staff
CHOOSING THE PATH
Choose the device path from its constraints
Power, network, update method, location and expected volume determine the platform and the next prototype step.
MCU prototype
- Good fit
- Focused sensing or control with tight power and cost limits; assess STM32 or ESP32 against the task.
- Confirm first
- Sampling, memory, interfaces, power and recovery behavior.
Edge computer or gateway
- Good fit
- Local aggregation or computation beyond an MCU; assess Raspberry Pi or embedded Linux hardware.
- Confirm first
- Operating system upkeep, connectivity and field replacement.
Existing device integration
- Good fit
- The hardware already works and exposes a documented interface.
- Confirm first
- Protocol access, credentials, event quality and vendor limits.
HOW THE SYSTEM CONNECTS
Trace the signal and the command
The connected system must explain both the data path and who can act on the device.
Sensor or actuator
Physical input, output and calibration needs
Firmware or edge host
Sampling, control, local state and recovery
Communication
BLE, Wi-Fi, gateway or wired link in scope
API and data service
Device identity, messages and permissions
App or web admin
Status, review, alerts and authorized commands
AI analysis is optional and may run at the edge or in a service only after latency, power, privacy and cost are assessed.
TECHNICAL CAPABILITIES & SCOPE
What the engineering covers
Choose methods to fit your existing equipment, systems and project requirements.
Device and firmware prototype
Prove the essential measurement or control path on suitable hardware before widening the design.
- MCU and sensor or actuator selection for the task
- Sampling, calibration, timing, power and local fail-safe behavior
- Firmware build, logging, fault recovery and update approach
- GPIO, ADC, UART, SPI and I²C interfaces where required
Communication and connected software
Carry trustworthy device status to the people and systems that use it.
- BLE, Wi-Fi, gateway or wired protocol selection
- Device identity, command authorization and MQTT or HTTP message format where appropriate
- Offline buffering, reconnect, retransmission and duplicate handling
- API, data service and app or admin integration
Hardware design and edge processing
Advance only after the prototype answers the critical questions.
- Circuit, power and interface plan for a custom PCB if in scope
- Prototype board files, bring-up notes and test record if contracted
- Evaluate rules, TinyML or a larger edge computer only when the task justifies it
- Enclosure, radio, certification and manufacturing responsibilities scoped separately
DELIVERABLES
What you receive
Agree the deliverables and acceptance criteria before work starts.
System and component plan
Task, environment, interfaces, selected parts and acceptance checks.
Firmware and prototype
Working device path, source, build instructions and recorded limitations.
Connected interfaces
Protocol, API and app or admin integration within the agreed scope.
Test and handover record
Sampling/control results, outage and recovery checks, board files if included, and operating notes.
Move from a verified signal to a maintainable device
Each stage records what worked, what failed and what the next hardware commitment requires.
Define the environment
Agree the physical action, power, network, quantity and connected systems.
Prove the device path
Use a development board and representative modules to test sensing or control.
Connect and recover
Verify device identity, message delivery, outage behavior and operator action.
Decide the next build
Review evidence before custom PCB, enclosure, edge AI or productization work.
DEPLOYMENT & HANDOVER
Deployment, handover and ongoing responsibilities
Prototype and product boundaries
Agree separately who owns custom PCB, enclosure, radio work, certification, manufacturing, supply chain and support.
Field operation and changes
Define device identity, update method, rollback or recovery route, spare-device handling and access to the connected service.
ACCEPTANCE
Agree what completion means
- The target device performs the agreed sensing or control task under recorded conditions.
- Loss of power or network has a defined local state and an observed recovery path.
- Authorized operators see the correct status and unauthorized commands are rejected.
- The customer receives and can rebuild the contracted firmware and connected service assets.
BEFORE WE START
A few practical questions
Can we start on a development board?
Yes. We first prove the sensor, control and communication path on representative hardware. A custom board is a separate decision after the results are reviewed.
Does this include PCB manufacturing and certification?
Circuit and PCB prototype work can be scoped. Enclosure, radio, certification, production and supply-chain responsibilities are defined separately for the specific product.
Does every device need edge AI?
No. Simple thresholds or rules may solve the task. Edge inference is considered only when its latency, privacy or offline value justifies its compute, power and maintenance costs.
EXPLORE RELATED SPECIALTIES
Related specialist services
EXPLORE THE NEXT STEP
Discuss your project
Describe what the device must do, its power and network conditions, expected quantity and the system it should connect to.