1. “Smart Bottle” Is Four Different Weighing Jobs

The enquiry arrives as one sentence — “we need load cells for our smart water bottle” — and it can mean four quite different pieces of hardware. They share a word and almost nothing else.

Before any of that, there is a fork in the road that decides whether the rest of this article applies to you. The industry builds two families of smart bottle sensors, and only one of them is a weighing problem:

Family one deserves an honest sentence rather than a dismissal. A capacitive rod reads the level from the inside, so it does not care what the bottle is standing on, it does not care who is holding it, and it will give you a number while the bottle is still in someone’s hand. The weight-based family has one advantage that the level family cannot match — mass is mass regardless of geometry, foam, ice or a bottle that is not a cylinder — and one weakness that no sensor choice can repair: it only knows what happens while the bottle is resting on it. Everything the user does between put-downs is invisible.

The public description of how the best-known product in this category works is a fair summary of the whole family: the sensor puck “weighs the bottle each time it is set down on a flat surface”, and the app works from the difference. Holding the bottle is not measured. Pouring water out of it is not measured as pouring. Sharing it with a colleague is not measured at all. That is not a limitation of a particular brand; it is what a scale under a bottle can know.

I should state my own boundary here, because it is the most useful thing I can say to an OEM. I make the sensing element and the parts that go around it — load cells, weighing modules, junction boxes, indicators. I do not make bottles, I do not write Bluetooth firmware, I do not write the app, and I do not certify the appliance. When a project goes wrong it is usually in one of those, not in the cell. If you want the general selection logic before the bottle-specific parts, the project selection guide covers it without the bottle context.

2. A 20 g Sip on a 1,073 g Bottle

Here is the whole product in one table. Every row is a real container size, and the last two columns are the numbers that decide whether your idea is buildable.

Two things stand out, and they pull in opposite directions from the way most weighing projects behave.

The tare is 42 %, and it is the part you already know. In a silo or a hopper the tare is the enemy because it drifts and you cannot see it. Here the bottle is a moulding with a mass your supplier controls to a gram or two, and it is the same bottle every time. What you do not know is how much water is in it — which ranges from nothing to everything. So the instrument has to be honest across the entire 454–1,073 g band, and it visits both ends every day. In fact it spends far more minutes at the low end than at the high end, because a bottle is usually part-full or empty and only briefly full. Remember that in section 9, because it turns a small drift into a visible one.

The sip is 1.9 % of the bottle — and “a sip” is not one number. The clinical literature on swallowing measured one mouthful of water at about 21 mL in men and 14 mL in women, while the average volume per swallow during continuous drinking comes out lower still, around 12 mL and 8 mL. Natural sip volumes are reported across a 6–34 mL range depending on age and instruction. So if you design your event detector around a 20 g sip, you have designed for the average and you will lose the small ones: the case you actually have to survive is closer to 8 g, which is 0.75 % of a full 21 oz bottle. Section 6 turns that into a hard ceiling on container size.

3. You Are Weighing a Difference, Not a Bottle

This is the part I wish every smart-bottle spec sheet started with. Your app never uses the weight of the bottle. It uses one weight minus another weight. The quantity your product sells is Δm = m_after − m_before, and it is on the order of 20 grams.

That single observation redistributes the entire datasheet. Most of what a load cell manufacturer puts in a table — the accuracy class, the comprehensive error, the linearity, the hysteresis, the rated-output tolerance — describes how far the absolute reading can be from the truth. When you subtract two readings taken moments apart on the same cell at almost the same load, those terms either cancel outright or move so little across a 20 g interval that they disappear into the rounding.

Let me do that arithmetic on a real cell rather than assert it. Take a micro cell in the 2 kg range — the WST109 class, 1.0 mV/V, recommended 5 V excitation, so a 5 mV full-scale output. Every term below is converted into grams, because %FS is not comparable between ranges and grams are.

Add it all up honestly and the datasheet costs you about 4 grams on a difference measurement — a fifth of one sip, and half of a small 8 g sip. The two numbers that matter are the two that are not in any headline: zero stability and short-term repeatability. Everything you would be tempted to spend money on — a higher accuracy class, a lower comprehensive error, a laboratory-grade beam — is the specification you cannot use.

Two practical consequences follow, and they are worth writing next to your firmware spec.

First: “full” is not a reference and you can never zero at it. There is no such thing as a full bottle. Filled to the neck, filled to the shoulder, filled in the sink with the tap running, and filled from a filtered jug are four different masses, and the app cannot know which one it is looking at. Any calibration routine that starts from “assume a full bottle” is assuming something the user is not obliged to supply.

Second: the difference is only as good as the two states being comparable. Everything in the next five sections — where the bottle sits, how the water is still moving, whether the hand has let go, what the temperature did, whether the lid is on — is about making the before and the after genuinely the same measurement. That, not the cell, is the engineering. It is also why the same load cell appears in a product that tracks beautifully and in one that reports sips all night: the sensor was identical, the state machine was not.

4. Resolution Is Not the Bottleneck, and Never Was

Almost every second email I get in this category asks for more resolution. It is the easiest thing to ask for and the least useful thing to buy, and three lines of arithmetic show why.

Take that same 2 kg-range micro cell at 1.0 mV/V with 5 V excitation. Full scale is 5 mV. A good modern ΣΔ converter runs a 24-bit conversion over a ±10 mV input window with around 5,000,000 counts, which puts one count at 4 nV. Divide: 5 mV over 4 nV gives 1,250,000 counts across 2,000 g, or 625 counts per gram. A small 8 g sip is 5,000 counts. A 20 g sip is 12,500.

A count is 0.00008 % of full scale. On the worst line in that table — a 5 kg cell in a tray — a small sip is still two thousand counts deep. There is no converter upgrade, no 32-bit front end and no averaging scheme that changes anything here, because resolution is four orders of magnitude away from being your limit.

The legal-metrology version of the same number makes the point in the other direction. The minimum verification interval for a cell is V_min = E_max ÷ Y, where Y is an empirical factor — around 10,000 for C3 and 5,000 for C2 on beam-type cells. On a 2 kg range that puts the legal floor at 0.2 g for C3 and 0.4 g for C2. Field minimums for micro cells are in the same territory: a typical 100–750 g pocket-scale cell is quoted down to 0.01 g, and miniature cells are commonly listed with 0.1 g minimums below 3 kg. The finest resolution you can legally claim is 50 to 200 times finer than the smallest sip you have to detect.

5. Three Load Paths, Five Cells

There are only three ways to put a scale under a drink, and they differ in what sits on the sensor rather than in what the sensor is.

WST109 is the one I would put in a bottle. Its ranges start at 300 g, which is a bottle-sized scale rather than a person-sized one, and its input resistance is 1,000 Ω rather than the usual 350 Ω — that matters more than any accuracy figure, for reasons I will get to in section 10. It is aluminium with a silicone seal, IP65, and its published applications already include water coolers and coffee scales. One honest caveat before you design around it: its safe overload is 120 % of range and its ultimate overload 150 %, so on a 2 kg range you are protected to 2.4 kg and you survive 3 kg. A full 32 oz bottle is 1.65 kg — fine. A 1.5 L jug on the same cell is not.

WST101 is the tray cell. Its flat frame with a mounting hole at each corner is exactly what a coaster or a weighing dock wants, and its 5–200 kg range covers anything up to a catering tray of bottles. Two things I will not pretend about: its datasheet publishes an ultimate overload of 150 % but no separate safe overload, so if your design leans on the cell you need that number from us in writing before you finish the housing; and its input resistance is not published, which is an odd gap for a battery-powered product and one I would rather flag than paper over.

WST601 is the abuse cell, not the accuracy cell. This is the most counter-intuitive recommendation on the page, so let me put the number in front of you. It is stainless, IP66, rated 0.1–20 kN, with a comprehensive error of ±0.5 %FS — and on its smallest range, 0.1 kN, that is 51 grams, or two and a half sips. As an absolute reading it is worse than useless for tracking hydration. What you are actually buying for a dispenser base is the 20.4 kg ultimate overload, the 15.3 kg safe overload, and the 5.1 g zero stability — you are buying the day somebody leans on the fountain, not the day somebody drinks from it. If your dispenser is a bottle-scale in disguise, use WST109 and put a mechanical stop under it instead.

For completeness: four half-bridge cells wired in series make one full bridge and one 4-corner platform, which is the plumbing behind almost every bathroom scale ever built — and it is a genuinely good answer here, because a four-point platform averages an off-centre load by construction instead of levering it into one cell. Section 6 is about why that matters more than anything on the datasheet. The same idea appears in the smart home products and smart coffee machine write-ups, where the same load path sits under very different products.

6. The Error Nobody Puts in a Datasheet

Section 3 concluded that the entire datasheet costs about 4 grams on a difference measurement, and section 4 showed you have four orders of magnitude of resolution in hand. So if your product is missing sips, something is delivering an error that is not in either place. It is.

The largest error in a bottle scale is where the bottle lands. Not the cell, not the converter — the seat. Three mechanisms do it, and none of them has a column on any datasheet I have ever been sent:

All three produce the same signature: the reading depends on the position of the load rather than its size. That makes for a beautiful, zero-cost test that needs no certificate, no master weight and no supplier. Fill the bottle to a known level, then weigh it in eight positions around the base — north, north-east, east and so on. Log all eight. Your maximum minus your minimum is your real position repeatability, and in my experience it is between ten and fifty times bigger than every term on the datasheet combined.

Why that particular number is the one that matters: a difference measurement needs the same reading to be reproducible, not a true one. Position error is reproducible in the worst possible way — it is stable, it looks tidy, it never announces itself as a fault, and it is different every time the user puts the bottle down slightly differently. It is exactly the “it’s very repeatable and still wrong” situation, and here it is the dominant term, by a factor of ten.

Now combine that with the sip size and you get a hard, honest ceiling on container capacity. If a difference is only worth trusting when it clears roughly three times the position repeatability, then:

Read the bottom row again, because it is the punchline of this whole article. With a bad seat, you cannot build an honest scale for a 500 mL bottle. With a good one, a one-gallon dispenser is comfortable. The load cell is the same in both cases. Your bottle’s capacity limit is set by how well you control where the user puts it down, and by nothing else.

7. Slosh, and Why Your Settling Window Is Too Short

Put a bottle of water down and the water keeps moving. Everybody knows this. Almost nobody puts it in the timing budget, and it is the second-largest error in the product after the seat.

The first slosh mode of a cylinder is easy to work out. For a bottle with a 73 mm bore the mode number is k = 1.841 ÷ R, which gives about 50.4 m⁻¹, and the natural frequency is ω = √(g k tanh(k h)). The tanh term saturates almost immediately, so the answer barely depends on how much water is in there:

So a half-empty bottle is just as bad as a full one, and the disturbance repeats every 0.28 seconds. Now the part that reaches the sensor. Sloshing water moves its centre of mass up and down, and a mass accelerating vertically presses on the base with m (g + a_z) ÷ g. The vertical acceleration scales as ω² times the surface amplitude, and ω² here is about 494 s⁻² — a big multiplier for a very small wave.

A ±40 to ±125 gram oscillation at 3.5 Hz, arriving every time the user sets the bottle down. Your cell’s contribution to the same measurement was 4 grams. This is where the error actually lives.

There are two ways to handle it and only one of them is expensive. The cheap way is arithmetic: average over an integer number of slosh periods. A 0.8 second window is 2.83 periods, which leaves 2.8 % of the fundamental behind; 1.4 seconds is 4.96 periods and leaves 0.12 %; 3.4 seconds is 12 periods and leaves 0.03 %. Averaging is nearly free and it destroys the error almost completely.

There is a second trap hiding in the sample rate, and it catches people who are being careful about power. If your firmware runs at about 3.5 Hz to save battery, then a 3.5 Hz slosh aliases to zero — a standing offset that slowly wanders with the envelope of the slosh. From the app’s side that is indistinguishable from a drift, and a slow drift in a bottle is indistinguishable from drinking. Sampling at 5 Hz moves the slosh to 1.46 Hz where a filter catches it; sampling at 2 Hz puts it at 0.46 Hz, which is worse than doing nothing. In other words, the cheapest sample rates are the dangerous ones.

The physics also tells you something useful about mechanics. Slosh frequency goes as 1 ÷ R, so a wider container sloshes more slowly — a 130 mm tray of water runs nearer 2 Hz, and a narrow bottle near 4 Hz. If you are designing a dock rather than a bottle, the two are not the same problem and they do not want the same time constants. And if you want to know your own numbers instead of my arithmetic, tape a phone to the base with an accelerometer app running and set the bottle down a few times. That measurement costs nothing and it beats any assumption.

8. Presence, Stillness, and “Is the New Level Still There?”

Sections 6 and 7 say that the seat and the liquid dominate the error. Both of them are conditions on when you are allowed to read. So the practical form of everything above is a three-state machine, and I would write it into the requirements document rather than leave it to firmware.

T_min is the big one. Three different settling times are in play: the converter’s own settling time, which is a few hundred milliseconds; the time it takes the user’s hand to leave the bottle, which is about half a second to a second and a half; and the slosh settling time, which from section 7 is two to four seconds. Firmware people naturally pick the first one, because it is the one the electronics manual mentions. T_min has to be the largest of the three. Three to four seconds, minimum, and I would write “at least 12 slosh periods” into the spec so that a later firmware optimisation cannot quietly walk it back.

The deadband must be sized to the ripple, not the resolution. A ±1 g deadband on a 2 kg cell is 0.05 %FS, which is finer than the room you are standing in and far finer than the water. After settling, the residual ripple on a bottle is a few grams, so a deadband around 8–10 g is honest. A too-small deadband does not make the product more sensitive; it makes it fire more often, on nothing.

The “is it still there” test is the one that removes the last class of phantom drinks. The rule is to test the new level rather than the transition: a hand pressing on a bottle, a bottle leaning against a wall, a bottle being nudged — all of those produce a short pulse, whereas a genuine drink produces a step that stays. If the level comes straight back, it was not a drink. This is the same reasoning used in gravity-sensing retail shelves, where a press is a narrow pulse and a real pick-up is a step, and the discriminator is whether the new level persists rather than how big the change was. That write-up is worth reading alongside this one: load cells for smart shelves.

9. Zero Policy and Temperature: What Actually Drifts

Let me start with the temperature question, because the industry worries about it in the wrong direction and I can show that with five lines of arithmetic.

A bottle lives between about 4 °C in a fridge and 60 °C in a car parked in the sun — a 56-degree swing. Take the zero temperature coefficient of the three cells I recommended in section 5 and multiply each by its own range, because that is the only honest way to compare them:

Look at what just happened. The published coefficients differ by a factor of four — 0.05 %FS against 0.2 %FS, which reads like a night-and-day difference on a spec sheet. But the actual drift in grams differs by only 27.5 %, because the cells’ ranges differ by a factor of five in the opposite direction. %FS coefficients are not comparable between cells. Multiply by the range, or do not compare at all. I have watched people choose a cell on a coefficient and get a worse number in grams.

Now the zero policy, which is the single highest-value paragraph in this article for anybody commissioning firmware. Recall from section 2 that the bottle spends most of its minutes part-full or empty, and only briefly full. That matters here:

Which leaves one rule, and I would put it in writing and get somebody senior to sign it: the only honest zero is an empty bottle. Not “full”, because full is not defined. Not “as delivered”, because the user will not repeat it. An empty bottle is the one state that is mass-defined, repeatable and reachable, and it is the state the product should re-zero to whenever it can be sure of it. In practice that means three conditions together: the load is inside the empty-bottle band, it has been still for hours rather than seconds, and the temperature has been stable to within about a degree. If all three hold, re-zero and log it. If not, do not — a re-zero taken with a dead fly on the plate is worse than no re-zero at all.

The same discipline shows up in every outdoor container I have worked on — beehive scales, LPG cylinders, feed hoppers — and the reason is always identical: nobody can press a zero button at a moment they control. The smart beehive scale and smart LPG cylinder articles both end up in the same place, for the same reason.

10. The Battery Arithmetic: You Are Optimising 0.3 mAh/day

The other email I get constantly in this category is about power, and it is asked in the form of a sensor request: “we need a lower-power load cell so we can hit our battery claim.” Let me do that arithmetic properly, because it usually ends with me selling nothing, and I would rather you found that out here than after a redesign.

A strain-gauge bridge is a resistor, so it is easy to cost. Take a 1,000 Ω micro cell at its recommended 5 V: 5 mA, 25 mW while energised. Take the alternative, a 350 Ω cell at the 10 V its datasheet recommends: 28.6 mA and 286 mW. Now put it against a battery. A 1,000 mAh cell at 3.7 V holds 3.7 Wh, and the two designs behave completely differently:

The first row is the important one, and it is a design decision rather than a component decision: a continuously energised bridge on its own breaks a fourteen-day claim. 162 mAh a day against a 1,000 mAh cell is six days of battery, and you have not powered a radio yet. So switched excitation is not an optimisation; it is the entry ticket.

Once you have switched it, though, the sensing chain becomes almost invisible in the budget. Forty measurement events a day at two seconds each is 80 seconds of excitation out of 86,400 — a duty cycle of 0.09 %. That is 0.023 mW averaged, which is 2.1 mAh across a full fourteen days, or 0.21 % of the cell. A fourteen-day claim on a 1,000 mAh battery needs 71.4 mAh a day, which is a 2.98 mA average draw across everything in the product — radio, display, LEDs, MCU and sensor together. The sensor’s share of that is about 0.15 mAh a day.

If you want the counter-intuitive version: the 1,000 Ω bridge is worth more to you than any accuracy grade in this catalogue, not because of what it measures but because of what it does not draw. It is roughly a seventh of the current of a 350 Ω cell at the same voltage, which is why I led with it in section 5. And if you are building a fountain or a dispenser with a 350 Ω button cell, run it at the lowest excitation your converter can tolerate rather than the highest the datasheet allows — the sensitivity you lose is worth nothing here, as section 4 explained.

The one genuine sensor-side change worth making has nothing to do with battery life at all. Switched excitation also removes a slow self-heating term. A bridge left energised inside a sealed base warms its own elastomer by a fraction of a degree, and a fraction of a degree is a few grams of zero shift on a 2 kg range. Energising only for the measurement window means the cell is always at ambient when you read it. That is a zero-stability improvement, which per section 3 is one of the only two numbers that survives subtraction. Do it for that reason and the battery comes along for free.

11. Ice, Milk and Condensation: Not the Sensor’s Errors

Everything so far has been about making the gram number right. Your app does not show grams. It shows millilitres, a percentage of a goal, and a hydration score, and every one of those is a conversion the software performs. That is where the biggest percentage errors in the product live, and none of them can be fixed with a load cell.

Start with the one everybody asks about, which turns out to be a non-issue. Water is 0.99705 g/mL at 25 °C and 0.99997 g/mL at 4 °C — a spread of 0.29 % across the entire range a person will ever drink at. On a 20 g sip that is 0.06 mL. The density of water is a rounding error; if somebody is proposing to compensate for it, they are selling you something.

The real conversion error is every drink that is not water. Milk is about 1.030 g/mL, orange juice around 1.045, a cola around 1.04. Weigh 20 g of milk and call it 20 mL and you are 3 % low; on a 250 mL glass you are reporting 7 mL less than the customer poured. If your app offers dozens of drink types, then the conversion factors are doing more work to your accuracy than the sensor is, and they should be treated as a first-class part of the specification rather than a table somebody filled in. The hydration factor for a given drink is a nutrition assumption, not a measurement, and it is fair to say so in the app.

Those three share a property that defines the outer boundary of any weighing bottle: they change the mass without anyone drinking. A scale sees a mass; it cannot see intent. Ice being added, water condensing, a second person drinking, water poured into a glass and drunk from there — the load cell reports all of them identically, and the inference is the OEM’s job, not mine. The published advice from the category leader is disarmingly honest about this: pouring out, adding ice, refilling partially, sharing, and setting the bottle down on an unstable surface all affect the reading, and the app measures bottle movement rather than who consumed it. That is not a marketing failure. It is the correct description of the instrument.

It is the same family of problem as weighing a gas cylinder or a trash bin: the container’s mass and the thing you actually care about are not the same quantity, and the gap between them is where all the interesting engineering sits. The smart LPG cylinder and smart trash can write-ups both start from that same observation.

12. Case: Every Put-Down Became a Sip

A tooling shop in Dongguan building a 600 mL insulated bottle for a US direct-to-consumer brand, late 2025. The bottle base held a single micro cell under a sealed floor plate, the firmware was theirs, and the support tickets were all the same shape: “the app says I drank 200 mL while I was asleep.” By the time they came to me they had already decided the answer was a better cell and asked for a 0.02 % part.

The first thing I asked for was not a datasheet. It was the raw event log — every reading the firmware had committed, with timestamps, for one bad night. That took ten minutes to read and it ended the conversation about the sensor.

The log did not contain eleven separate drink events. It contained eleven pairs, and inside each pair the two events were about 0.9 seconds apart. The second reading in every pair was between 12 and 60 grams lighter than the first, and the amount was different every time. Nothing had been drunk. The firmware had logged the same bottle twice.

What was happening was section 7, exactly. Setting the bottle down on the base excites the first slosh mode at about 3.5 Hz, so the force on the cell oscillates with an amplitude of tens of grams for a couple of seconds while the water settles. Their settle logic waited for the reading to stay inside a ±1 g deadband for two consecutive samples, then stored that value. On a 3.5 Hz wave, two samples a few tens of milliseconds apart can easily both land near a trough. So the firmware captured the bottom of the oscillation as “the bottle as you left it”, and then captured the recovery 0.9 seconds later as a new, lighter level. A phantom sip, with a plausible size, in a plausible time. The deadband was measured in grams of resolution when it needed to be measured in grams of water movement.

The fix took an afternoon and changed no hardware. The window went from a sample-and-hold to a genuine average over 3.4 seconds — twelve slosh periods, which per section 7 leaves about 0.03 % of the fundamental behind. The deadband went from 1 g to 10 g. And the persistence test went in: a new level had to still be there three seconds later before the app was allowed to call it a drink. The phantom events fell from roughly eleven a night to under one a fortnight, and the “better cell” conversation ended.

One thing I did agree to supply, and it was not a load cell. They had been assuming the slosh behaviour instead of knowing it, so I asked them to tape a phone to the base with an accelerometer app running and set the bottle down twenty times: on a bench, on a tablecloth, on a desk mat, from 1 cm and from 5 cm. Twenty minutes of work, no equipment, and it told them their real settling time and how much of it came from how the user puts the bottle down. Every project in this category should do that before writing the state machine, and almost none do.

13. Case: The Same Jug, 24 g Heavier One Position Over

A fitness brand in Ningbo, 2026, scaling a successful bottle design up to a 1 L gym jug. The sensor was unchanged, the firmware was unchanged, and the product did not work. Their own testers could not reproduce the app’s totals with a kitchen scale, and short sips had started disappearing. They sent me a three-page specification asking for 0.01 g resolution and a six-point calibration, which told me they had already diagnosed the problem as accuracy.

I asked for one thing instead: a photograph of the loaded base, from the side, taken while the jug was standing on it. It came back the next morning and it was enough. The jug’s base was a 1.2 mm aluminium plate, and with 1.7 kg of water sitting on it you could see the plate had dished — bowed down in the middle where the cell was, lifting at the rim where it met the housing. That is the first mechanism in section 6: a second load path that appears and disappears. Whether the rim was carrying part of the jug’s weight depended entirely on where the user had put it down.

The diagnosis cost nothing and needed no instrument. I asked them to fill the jug to a marked level and weigh it in eight positions around the base — north, north-east, east, south-east and so on — writing down every reading. It took about ten minutes:

Twenty-four grams of error, introduced purely by the position of the jug, on a 1,697 g gross. For scale: the maximum and minimum landed on opposite sides of the base, which is the signature of a rocker or a rim contact rather than anything electronic. And the number is roughly six times the entire datasheet error budget from section 3, in a product that was being asked to resolve 8 g sips.

Their proposed fix — a six-point calibration with laboratory weights — would have produced a beautiful certificate for a machine that did not exist. What we actually did was three mechanical things: a 2 mm base plate with a turned rib so it could not dish, four-point support instead of a single cell in the middle so the seat averages the load instead of levering it, and a specified screw torque on the cell mounting feet so that no two units were pre-bent differently. No electronics changed and the accuracy grade did not move. The spread went from 24 g to 3 g — eight times better — and the short sips came back, because they had never been missing.

14. Case: The Battery Complaint That Was Not About the Sensor

A German brand, spring 2026, building a counter-top hydration station with a 1.5 L reservoir. Their headline claim was fourteen days per charge. The product was shipping at nine. They asked two suppliers, me and one other, for a lower-power load cell to claw the difference back, and their assumption was that the sensing chain was the culprit.

I did the arithmetic from section 10 out in front of them, on a call, with their own numbers. A 1,000 mAh cell. Fourteen days needs 71.4 mAh a day. Nine days means they were drawing 111.1 mAh a day, so they had to find 39.7 mAh a day from somewhere. And the sensing chain — a 1,000 Ω micro cell, energised only during measurement, forty events a day — was costing them 0.15 mAh a day.

Which means the honest answer was the one nobody wants to give: if you removed the load cell entirely — no sensor, no excitation, no conversion, nothing — the product would go from 9.0 days to 9.01 days. About twenty minutes of battery, for the entire measurement function. It is a slightly absurd way to make the point, which is why I used it, and it landed. They had been optimising 0.1 % of the problem because it was the part with a supplier attached to it.

What was actually drawing the current was, in order, the Bluetooth connection interval, the LED animation, and the sleep current of everything else on the board — and none of that was mine to fix. I told them so. They went back to their firmware and radio settings, and the product came back at fifteen days without a new sensor in it. The only sensor-side change I made was switching the excitation so the bridge is only energised inside the measurement window.

One thing did come out of that project that I now recommend to everyone building a sealed base. Because the excitation is switched, the cell is only warm while it is measuring, and it is otherwise at ambient. On a 2 kg range that is worth a few grams of zero stability — exactly the term we identified in section 3 as one of the only two that survives subtraction. It cost nothing. I would do it even if the battery were free.

15. The Worksheet, and What I Supply

Every quotation conversation I have about a smart bottle reduces to nine numbers. If you can answer them, I can tell you in one reply whether a load cell is the right answer at all — and if it is, which of the two or three terms in section 3 will be the one that limits you.

If you want the general version of this worksheet rather than the bottle-specific one, I wrote a longer load cell selection guide that walks the same questions in a different order. The bottle version above differs in one way: the mass range is small enough that mechanical architecture matters more than the sensor, and that is unusual.

What I supply, and what I do not

I make weighing components. I do not make bottles, and I am not going to pretend that the interesting engineering in a smart bottle is the sensor — it is not. Here is the honest split, in the same form I use on calls.

16. Questions I Get From Bottle Builders

Recommended Models

The five parts below cover every load path in section 5. Ranges are per model; if none of them brackets your bottle mass and the sip size you need to resolve, send me the nine numbers from section 15 and I will tell you honestly whether we have something that fits.