Water sports...

...(i.e. Tracking water for sport, obv.)

With the data reporting I was getting with my latest tracker, I had a new idea in the week before my last race...

What if it was possible to also monitor, track and report fluids drunk? 

I like to run with a water bladder rather than soft bottles, but it's always awkward knowing exactly how much you've had or got left. You can get a reasonable idea from the weight, or patting your bag but obviously it's not as simple as having an empty bottle in your hand.

In the past I had tried to use the little Camelbak fluid display gadget... but it was pretty useless on the whole , and impossible to read the tiny display, outside, running, with bifocals on.

So I had about a week... and an idea... and already had the framework with the tracker how hard could it be. I ordered a load of random stuff.... and started tinkering.

Standard random internet orders, nothing to see here...

I picked an ESP32 board for this, my idea is to use it to broadcast data with BLE and I'd had a good experience playing with the ESP for the VO2 max device project.

Parts: 

• ESP32 Beetle board - shop.pimoroni.com
• Mini flow sensor: ebay
• Battery: 850mA spare.
• Case: Hammond
• a few pipe connectors and spare tube depending on need! :)
• Code - github.com/ihewitt/bleflow

The flow sensor s a little bigger than I'd like so I'll keep an eye out for more compact options, but it's handy while developing to have something manageable. I just tried a smaller one, but the smaller pipe inlet diameter means it's actually unusable for drinking water through.

I *am* tempted to rip apart that old Camelbak sensor and use that.

Old Camelbak innards... perhaps just wire in that sensor instead?

First test play with the sensor, I reckon this is a go-er.

Blowing through to test with basic/trivial code.

Testing

A few iterations of code and it was time for a test in the kitchen lab.

With a bit of fine tuning, it seemed to be able to read volumes within 1% of measured poured amounts, the code on the ESP32 is absolutely stripped down to the basics since I just "want it to work", so it counts the sensor ticks, keeps a total then outputs the value as a Bluetooth BLE "manufacturer data" broadcast. No need for any complex pairing or communications it's just shouting out its current tally into the radio waves.

For testing message reception I had a basic javascript app on a Bangle.js watch to listen for and print the data. So so simple, so amazingly easy and simple.

HUD v0.0

I experimented with a few batteries (tried super small) but in the end I went for a (relatively) massive option, just to make sure it lasted when I needed it. (and I was on a timeline)
For the future it will be good to calculate actual requirements and possibly improve the code to be more frugal.

At the moment the code is reasonably well behaved, it wakes up once every fifteen seconds and broadcasts, the state, it has an interrupt set on the sensor so wakes up when the sensor triggers and broadcasts the state every second until there's a whole second with no more flow.

That sounds like it's doing a lot, but in the world of microprocessors that basically means it's in sleep mode the majority of the time, but again, that can still be improved, but I was on a timeline and the priorities were. 1. make it work. 2. make it reliable. 3 make it good. in that order.

There's no reset button, I thought about it, but to keep it super simple, with nothing to go wrong, it just has an on off switch, if for some reason a reset is needed.... just the standard... turn it off, and on again.

A minor upgrade was made to the GPS tracker to also listen for, display and store the water data, but at the same time took the opportunity to get the tracker also doing the same type of status "shouting" so I could use a Bangle.js watch as a HUD on the day, this is rather cool and definitely has scope for some more features/ideas.

Tracker HUD

After a couple of very quick test walks it all seemed good to go.

Slick.

Packed up into a case and strapped to the bladder and it's ready to stress test this for real. (full detail of that written up in the other write-up, but there is/was a design flaw only identified *actually* running properly for hours.)

Improvements

So... during the run it turned out that the water was sloshing up and down in the tube so the readings were just ticking up constantly as I ran along, the old Camelbak sensor has a one-way valve clearly for this reason, so decided we'll need to add one in here also.

Improvement made, added in a non-return value, tested... but discovered that the flow is now reduced too much, so ordered a handful of alternative valves to try.... if that doesn't work then perhaps it'll be back to hacking the Camelbak sensor.

I've also decided to switch to a smaller, slicker case:

New bits...

Trimming and fitting

Packing it in.

Packed

All set, for the next test.

I've switched to a slightly smaller battery, but made some code improvements also. At the moment all the code is written with the Arduino sdk option, I had thought of switching to the  Espressif ESP-IDF SDK and I'd quite like to but after a quick look and spending an hour trying to get it setup decided I just didn't have the time yet. But I'll probably switch a future build over, it should be possible to make the code more frugal and improve the broadcast format (e.g the Arduino API only allows a string in the broadcast).

Once the new valves arrive it'll be time for another test outing, and time to think of any other improvements.