← All work
Embedded & IoT / Architecture walkthrough

From sensor
to screen.

Explore a water measurement platform across six connected layers. See what each part does, what it produces, and how it connects to the next.

An architecture walkthrough, not a live device feed. TDS, conductivity, and temperature readings do not establish whether water is safe to drink.

Explore the system

Select a layer. Use arrow keys to move between tabs.

01 / The measurement layer

Hardware & PCB design

Custom sensing hardware provides the measurements that every software layer depends on.

Custom PCBAnalog DevicesConductivity / TDS

What happens here

  • The PCB connects the sensor interface, signal conditioning, and measurement electronics.
  • Analog Devices components support the conductivity and TDS measurement path.
  • Board layout, grounding, and interfaces shape the behavior of the assembled system.

What connects next

  • Measurement electronics expose data to the embedded application.
  • Electrical interfaces and signal requirements must agree with the firmware design.
  • Hardware validation is specific to the device, operating conditions, and intended use.
The interface that mattersThe analog design sets the boundaries for the data available to firmware. Software cannot recover information that the measurement path did not capture.
02 / Device behavior

Firmware & data acquisition

MicroPython application code works alongside custom C modules for lower-level device functions.

MicroPythonC extensionsData acquisition

What happens here

  • The application coordinates measurement acquisition and device behavior.
  • Custom C modules provide access to lower-level functions alongside MicroPython.
  • Calibration converts readings into measurement values for the rest of the system.

What connects next

  • Measurement records need defined units, timestamps, and a consistent structure.
  • Device behavior and network behavior are separate concerns with a clear interface.
  • Firmware changes need verification against the actual hardware and sensor path.
The interface that mattersA useful measurement is more than a number. Its units, timing, and calibration context must remain meaningful as it moves through the system.
03 / The device-to-service link

Connectivity & provisioning

WiFi connects the device to cloud services. A low-energy wireless connection supports local setup through the mobile application.

WiFiLocal wirelessDevice setup

What happens here

  • The device joins the network used for its cloud connection.
  • The mobile application supports a local wireless provisioning flow.
  • Device-to-cloud communication connects the local measurement system to remote services.

What connects next

  • Provisioning needs a clear path from a new device to a usable connection.
  • Connection state needs to be distinguished from measurement state.
  • Authentication and transport protection must be verified for each connection in a deployment.
The interface that mattersThe device, cloud service, and mobile app have different connection states. Making those boundaries explicit helps explain missing or delayed data.
04 / Application services

Cloud backend

Google Cloud Functions and Firebase connect device data to application behavior.

Google CloudCloud FunctionsFirebase

What happens here

  • Cloud services coordinate data processing and application requests.
  • Functions provide event-driven backend processing around the stored measurements.
  • The backend connects device-facing interfaces with the application data model.

What connects next

  • The device and backend need an agreed message structure.
  • Data processing needs to preserve the meaning of the source measurement.
  • Deployment, monitoring, and operating limits remain part of the service design.
The interface that mattersServerless infrastructure reduces some infrastructure work. The application still needs clear data contracts, operating limits, and maintenance ownership.
05 / Shared application state

Database & storage

Cloud Firestore provides the application data layer for device records and measurement history.

Cloud FirestoreDocument dataMeasurement history

What happens here

  • A document data model organizes device information and measurements.
  • Stored history gives mobile views context beyond the latest reading.
  • Firestore listeners update connected applications as records change.

What connects next

  • Queries and access rules need to match the application data model.
  • The user interface needs to distinguish current readings from historical records.
  • Retention, device identity, and access boundaries are deployment decisions.
The interface that mattersThe data model is an interface too. It connects what the device produces with what the application needs to show.
06 / The user interface

Mobile applications

Cross-platform Ionic applications bring device setup and measurement views into one interface.

IonicCross-platformMeasurement views

What happens here

  • The application presents TDS, conductivity, and temperature measurements.
  • Historical views help people understand changes over time.
  • Local wireless provisioning supports the device setup experience.

What connects next

  • Labels and units make raw measurements understandable.
  • Connection and data freshness should be clear to the user.
  • Measurement thresholds describe measured conditions, not a drinking-water safety determination.
The interface that mattersThe interface should communicate what the device measures and what those measurements can establish. Clear language is part of the system design.

The same thinking, in business workflows.

See how spreadsheets, documents, and customer systems connect.

Explore automation
Start a conversation

Building a
connected product?

A short overview is enough to start. We can use it to discuss fit, scope, and the right next step.

Email a project brief

A useful first note

  • 01Your system, tools, or current workflow
  • 02The problem and the outcome you need
  • 03Your timeline and important constraints