How Long a Wireless Vibration Sensor's Battery Actually Lasts

Ask any supplier of wireless vibration sensors how long the battery lasts and you will get a range with an asterisk. One to four years. Up to five years. Four years at two readings a day. All of those statements can be true of the same sensor at the same time, and none of them tells you what you actually need to know, which is how long the battery will last on YOUR machines with YOUR measurement plan in YOUR plant.

The reason is not evasiveness. It is that battery life is not a property of the sensor at all. It is a property of the duty cycle you impose on it — how often it wakes, how much it measures when it does, how many bytes it has to push through a radio to get that measurement to a gateway, and how hot the wall it is bolted to happens to be. Change any one of those and the answer changes by a factor that is often larger than the difference between two competing sensors.

So the honest answer is arithmetic, and there is not much of it. A cell holds a certain number of joules. Every reading costs a certain number of joules. The sensor sleeps between readings and that costs joules too, continuously, whether it measures anything or not. Divide the first by the sum of the rest and you have a life. That is the whole model, and this post derives it, prints it, and hands you a bench that runs it.

What comes out of that bench is more useful than a number. It is an ITEMISED number: how much of your battery goes to waking up, how much to running the converter, how much to the radio, and how much to simply existing. Once you can see which of those four is the big one, you know what to change — and in most real cases it is not the one people assume.

A wireless sensor's life is four repeating events. It sleeps, drawing microwatts. It wakes, which costs a fixed lump of energy to bring the analogue front end up, settle it, and establish a radio link. It acquires, running the converter for as long as the record lasts. Then it transmits, which costs roughly in proportion to the number of bytes it has to deliver.

Three of those four scale with something you control. Transmit scales with the payload. Acquire scales with the record length. Sleep scales with time, which you cannot avoid at all. But WAKE DOES NOT SCALE. It is a fixed cost, paid in full every single time the sensor gets up, and it is the same whether the reading that follows is one number or a quarter of a million samples.

That single fact produces the result most people find counter-intuitive, and it is the point of the figure below. Take a modest record — a single axis, 1,600 samples — and price it. The converter runs for 62.5 milliseconds. The radio delivers a little over three kilobytes. Together those cost about a thirtieth of a joule. And the wake-up that had to happen before either of them could cost half a joule on its own. Ninety-four per cent of what you paid for that reading went on getting the sensor out of bed.

The consequence is practical and it runs against the usual instinct. If wake dominates, shortening your record saves you almost nothing, because the record was never what you were paying for. What saves energy is waking up less often — and, having woken up, taking a record long enough to be worth the trip. A sensor that wakes four times a day for a short record can easily use more energy than one that wakes twice a day and takes a record sixteen times longer.

The payload arithmetic is simple enough to do in your head, and it is worth doing before anybody quotes you a battery life. A reading's payload is the number of axes, times the number of samples per axis, times the bytes per sample, plus a fixed overhead for the header, the timestamp and the settings echo. That is all.

Take the two ends of the range, and be careful with the small one, because it is not one number per axis. These sensors publish Peak, RMS and Pk-Pk on each of three axes — nine scalars — plus a temperature, so ten in all. The nine off the axes are three times three times four bytes, and with the 64 bytes of overhead the radio puts round a sensor-to-gateway message that is 100 bytes; the temperature adds four more and changes nothing. A full triaxial WAVEFORM at the largest record these sensors offer is three axes times 25,600 samples times two bytes for a 16-bit word, plus the same 64 bytes of overhead: 153,664 bytes. The waveform is about fifteen hundred times the payload of the overall reading.

That ratio is the whole design tension of wireless condition monitoring, and it is why the sensor families split the way they do. An overall-only node can be extraordinarily frugal because it barely uses its radio at all; a dynamic node that returns real waveform samples cannot, because the waveform is the product. The frugal node's problem is that an overall value cannot diagnose anything — it can only trend and screen — which is the subject of a different post on this site. Here the point is narrower: the two duty cycles are not competing at the same price, and any comparison of battery life between them is meaningless unless the payload is stated alongside it.

There is a middle path worth asking every supplier about, and the arithmetic shows why it is attractive. If the node computes a spectrum at the edge and sends the spectrum instead of the waveform, the payload drops by whatever the transform and any band reduction save — often an order of magnitude — while the diagnostic content that matters is largely retained. That trades radio energy for processor energy, and whether it wins depends on the part. It is a question with a numeric answer, and a supplier who has done the work will have it.

Every published battery-life figure you will ever be shown is quoted at a benign temperature. The CTC ConnectSens pages on this site, for instance, state four years based on two readings taken per day with excellent signal strength at 20 °C. Read that sentence carefully: it names a cadence, a link quality AND a temperature, and all three are load-bearing.

Twenty degrees is not an Indian plant. It is TIERA's engineering judgement, from installing and supporting instrumentation in Indian industry, that the ambient at a sensor bolted to a motor or a pump in a plant here is routinely 45 to 50 °C for much of the year — not as an extreme case on a bad day in May, but as the ordinary operating condition. Near a compressor, a kiln, a boiler feed pump or anything under a metal roof in Gujarat or Tamil Nadu in summer, higher still. The cell does not care what the specification was measured at; it lives where you put it.

A lithium thionyl chloride primary cell is a good chemistry for this job — high energy density, very low self-discharge, a wide temperature range — but it does not deliver its full rating when it spends its whole life hot. The derating ladder in the simulator below is TIERA's engineering judgement of the shape of that loss and nothing more; it is an order-of-magnitude curve, not a datasheet figure, and the reader should treat it as a starting point to be replaced by the cell manufacturer's own data.

It is anchored at two points that are not judgement, though. Twenty degrees is 1.0 by definition, because that is the temperature the published figures are quoted at. And 50 °C is 0.5 — a halving — because CTC's own WS100 datasheet instructs that the cell be replaced every four years normally but every TWO years above 50 °C, which is the same factor of two arriving by a different route (recorded 2026-08-20 in TIERA's technical brief on the CTC wireless range). When you click the 50 °C case on the bench below, the model returns 2.1 years for a duty cycle that gives 4.3 years at 20 °C. Nothing about the measurement changed. Only the plant did.

The practical consequence is a planning one. If your business case for a hundred wireless points assumed a four-year battery and your plant runs at 45 to 50 °C, you have understated the number of site visits by a factor of about two — and at fleet scale the labour of walking to a hundred sensors with a spanner is a larger line in the budget than the cells.

Here is the bench. Seven controls, four energy terms, and a life at the end of it. The chips along the top load the cases this post discusses, so you can reproduce every figure in the table further down rather than taking it on trust.

Watch the stacked bar rather than the months. The months are the answer to a question you cannot act on; the bar is the answer to the one you can. If the sleep block is widest, cutting readings can only ever recover the share the readings hold, so check that share before you compromise a measurement to save a battery. If the wake block is widest, read less often rather than shorter. If the transmit block is widest, bytes are your currency — and so is the quality of your radio link, because a node at the edge of its range re-sends packets and pays for every re-send out of the same cell. That is why the published figure says 'with excellent signal strength' in its own fine print, and why the weak-link chip, which changes nothing except the cost of delivering a byte, drops the same sensor from 4.3 years to twelve months.

Two of the chips are deliberate failures. The hourly-waveform case and the weak-link case both come back short, for entirely different reasons, and the bench says so plainly. A tool that only ever tells you yes is not a tool.

The table below is the post in one picture. One sensor, one 3.6 V 1 Ah cell, one plant at 20 °C, and three measurement plans. Nothing about the hardware differs between the rows.

The first row is an overall-only reading twice a day: 100 bytes, half a joule per reading almost all of which is the wake-up, and a modelled 6.8 years. At that duty cycle sleep alone is 81.2 per cent of the day's energy, so what is consuming the cell is mostly not the measuring at all — it is the existing. That is worth internalising, because it means that for a frugal duty cycle, arguing about record length is arguing about the wrong term.

The second row keeps the cadence and changes only the payload, to a full triaxial waveform: 153,664 bytes, two joules per reading, a modelled 4.3 years. Sleep still just edges the day, but transmit has taken over inside each reading. This is the case that lands in the same region as the published four-year figure for this duty cycle — which is a reassuring order-of-magnitude check on the model, and emphatically not a reproduction of anybody's specification.

The third row keeps that payload and changes only the cadence, to hourly: a modelled 0.7 years — 8.1 months. This is the row that ends most 'can we just monitor continuously?' conversations, and it ends them with arithmetic rather than with a sales position. Twelve times the readings and about a sixth of the life — not a twelfth, and the gap is the lesson. The twice-daily row is still half sleep, so there is a floor underneath it that cadence alone cannot push through. Only once the duty cycle dominates, as it does by the hourly row, does life become very nearly inversely proportional to how often you look.

Two more cases are worth clicking on the bench. The same twice-daily triaxial plan at 50 °C gives 2.1 years, purely from derating. And the same plan over a weak radio link, where every delivered byte costs ten times as much because of retries, gives twelve months. Neither of those changed the measurement by one sample.

A battery-life claim becomes checkable the moment you ask for the conditions attached to it, and there are only six of them. Ask for all six in writing and the answer stops being marketing.

First: at what cadence? A life figure without readings-per-day is not a figure. Second: with what payload — how many axes, how many samples, at what sample resolution, and is a spectrum computed on the node or sent as a waveform? Third: at what temperature, and what does the life become at 50 °C? Fourth: assuming what link quality, and what happens to it at the edge of range where the node is re-sending packets? Fifth: what is the sleep current, because at low cadences that number alone sets the answer? Sixth: what is the cell's rating in ampere-hours and volts, so you can do the division yourself.

Then ask the two questions that actually decide the programme's cost. What is the replacement policy — the interval at which the cell should be changed regardless of what it is reporting — and does the system tell you a per-sensor state of charge, or only a low-battery flag when it is already too late to plan the visit? For the CTC range, the published policy on this site's own store pages is a user-replaceable cell, and CTC's WS100 datasheet instructs replacement every four years regardless, halving to two years above 50 °C. A policy stated that plainly is a good sign, not a limitation.

And a last one, which is the honest core of this whole post: ask the supplier to do this arithmetic WITH you, on your machines and your measurement plan, and to show you the four terms rather than the answer. If the four terms cannot be produced, the number at the end was never derived from anything.

One thing the arithmetic will not do is rescue a measurement plan that was wrong to begin with. If the fault you need to catch needs a waveform, no amount of battery cleverness makes an overall reading diagnose it; and if it needs a noise floor a wireless node does not have, the battery question is moot. Decide what you need to measure first, then price it. This post prices it.

TIERA supplies the CTC ConnectSens wireless range in India — the single-axis and triaxial dynamic nodes, the mounting hardware, and the replacement cells — and supports them here rather than pointing you at a portal. Every one of those nodes lets you set the cadence, the record length and the resolution, which means every one of them has a battery life you choose rather than a battery life you are told.

What is more useful than a quotation is the calculation. Send us your points, the faults you are trying to catch, and how often you need to look at each of them. We will come back with the payload per reading, the four energy terms, a modelled life per point at your plant's real ambient temperature rather than at 20 °C, and where the plan needs a wired or route measurement instead. Where a figure is not published for a part, we will say so and ask the manufacturer rather than fill the gap.