Digital gauge inspection
We build systems that take measurements straight from your gauges, testers and sensors, store them with the calibration record attached, and raise an alarm the moment a value drifts out of tolerance.
Book a 30-minute scoping call See the instrument integrations
Send us the model numbers of your instruments. We will tell you which ones we can read before you spend anything.
| Reading from instrument KTC wrench, over Bluetooth | 112.4 Nm |
|---|---|
| Target and tolerance 110 Nm, plus or minus 5 | In range |
| Calibration certificate Valid to 14 March 2027 | Valid |
| Operator and asset Signed on device, asset tag scanned | Recorded |
| Previous reading Same asset, 30 days ago | 109.8 Nm |
Where manual readings go wrong
Every manual gauge process has the same four leaks. None of them show up until an auditor or a customer goes looking.
What a clipboard cannot do
A spreadsheet fixes none of these. It just moves the same numbers somewhere tidier.
What we build instead
We have done the hard part already. For Hydrajaws we integrated the KTC SDK so torque and pull values land in the record as measured.
Plain definitions
Both come up before anyone talks about budget. Both change what you should be shopping for.
It is software that takes a measured value from an instrument and stores it as a record, together with the context that makes the value defensible. That context is specific. The asset, the operator, the time, the procedure, and whether the instrument was in calibration on the day.
The distinction from a checklist app is narrow and expensive. A checklist app collects a number somebody typed. A gauge system collects the number the instrument produced, then checks it against a tolerance held per asset before the part is allowed to move on.
Calibration management tracks the instruments themselves. Certificate, interval, due date, who performed the calibration and against which reference standard. ISO 9001 clause 7.1.5 and ISO/IEC 17025 both turn on producing that record on demand, and most plants already run something for it.
The gap is that the calibration register and the measurement system rarely speak to each other. So a reading gets taken on an instrument whose certificate expired last week, and nobody finds out until an auditor pulls the file. Closing that gap is often the whole reason a custom build gets approved.
Case study, United Kingdom
Hydrajaws makes portable pull testers used in construction and safety compliance. Their old app could not read the instruments, so an engineer copied numbers onto a form and typed them again later. We rebuilt the apps and integrated the KTC SDK for digital torque measurement, so the value in the record is the value the instrument produced.
Case study, telemetry at scale
IoT Workz needed measurement data from device fleets without renting it back from a SaaS vendor. We built a self-hosted platform on ThingsBoard with white labelling, single sign-on through Keycloak, a rule engine for alarms, over-the-air firmware updates and multi-tenant separation. Readings arrive over MQTT, CoAP and HTTP and land in TimescaleDB, so a year of history queries as fast as yesterday.
What we build
Where the readings come from
The first three sit behind builds you can read about. The fourth is where those builds get extended most often, and we mark it as such rather than dress it up.
How the work runs
The whole system rests on whether we can read your devices. So that is the first thing we prove, not the last.
Week 1
You send model numbers. We find out what interface each one exposes and tell you honestly which are readable and which are not.
Week 2 to 3
Procedures, tolerances, asset structure, calibration rules and what a certificate has to look like.
Week 4 to 12
One line or one team runs it on real measurements while we are still building. Demo every two weeks.
Ongoing
More instruments, more sites, then the link into your ERP, MES or quality system.
Technology and integration
Two halves. Getting the value off the device, then keeping years of values queryable once you have them.
Who does the work
Instrument work punishes hand-offs. The engineer who reads the SDK documentation is the engineer who writes the integration, and the one who joins the call when a reading looks wrong.
You interview whoever we put forward, and you keep the right to say no. On a team this size there is nobody to hide behind.
How we work
The models differ in one thing: how much of the management you hand over. Everything else, including who owns the code, is the same in all five.
Changing model later is normal. Augmentation into a dedicated team is the common direction, and the people stay.
Engineers join your team and work inside your process, your board and your code review.
A team that works only on your product, with a lead on our side running delivery.
A long-term engineering site under your standards, where we carry recruitment, HR, payroll and equipment.
04
One price for a scope that is genuinely settled, with the overrun carried by us.
Everything in the centre model, with the whole team moving into your own Vietnamese entity on an agreed date.
FAQs
Any device that exposes a Bluetooth profile, a serial interface or a vendor SDK. We integrated the KTC SDK for Hydrajaws to read digital torque measurement. Send us the model numbers and we will check each one before you commit to anything.
A purely analogue dial with no output cannot be read automatically without adding hardware such as a camera or a retrofit sensor. We will tell you that plainly rather than sell you a system that quietly falls back to typing. In most plants a mixed approach works: automatic capture where the instrument allows it, guided manual entry with tolerance checks everywhere else.
Yes, and we recommend it. Each instrument holds its certificate and expiry date, and a reading taken on an expired instrument is flagged at the point of capture rather than found during an audit.
Yes. Readings capture on the device and sync when coverage returns, with conflict rules agreed with you.
Wherever your policy requires, usually your own cloud tenant. For high-volume telemetry we use a time series database. On the IoT Workz platform that was TimescaleDB with data arriving over MQTT.
Yes. This is normally the reason a generic app is not enough. We have built API integrations against ERP, MES and IoT systems, including legacy ones with no modern interface.
You do, both. The IoT Workz platform was built specifically so the client owned it outright with no vendor lock-in.
Often yes, and we will say so on the first call. If your existing register already holds certificates, intervals and reference standards, the cheaper route is to leave it there and read from it, so a reading is checked against live calibration state at the moment of capture. Replacing a calibration register that works rarely pays for itself.
We can build the capture and the calculation, and we have built statistical reporting before. We have not shipped a Gage R and R module specifically, so we will not pretend otherwise. If IATF 16949 makes measurement system analysis a hard requirement for you, say so early and we scope it as its own piece of work.
The auditor asks the same thing every time. Show me the reading, the instrument it came from, and evidence that instrument was in calibration that day. A system that captures those together answers it in one screen, and we build the record so it exports as evidence rather than being reassembled from three places.
Model numbers are enough to start. We will tell you which ones can be read automatically, which cannot, and what that means for the build.
Book a 30-minute scoping call See the instrument integrations
