Measure between Transmissions

[jhbruhn]

Arguably, the transmission of the sensor data is the most battery-expensive part of a measurement cycle. Could we decouple measuring and transmitting and measure between transmission intervals as well, and communicate those measurements in a batch transmission? This could give us a higher measurement resolution for less overall consumption in theory.

These transmissions could either be triggered by an internal counter, or optionally using alarms when a value deviates heavily from it's previous value, or for example the soil moisture is under a certain predefined threshold.

This would make the firmware and receiving logic quite complicated though. Also, I don't know whether more than 1 or 2 data packets could fit into a BLE packet anyways.

[rbaron]

That's an interesting idea that has been brought up in the past.

You are right, transmitting the data is by far the most power hungry stage, both with higher currents (in the order of 10 mA) and in time (~1 second). On the other hand, we can sample the sensors super fast, usually in the order of milliseconds. To keep the power consumption down, we need to do this faster and/or less often. Some ideas are:

1. Only transmit when the data changes We sample all the sensors with some frequency and only transmit when some of them change enough. The upside is that it saves battery. The downside is that it makes it a little harder to debug and detect when the sensors are dead or misbehaving, since now local state comes into play. It's another moving part that adds a little overhead. It adds up when you have 10+ b-parasites. Still, it's an okay optimization IMO.

2. Transmit in batches All the sensor data fits in a (simple) BLE advertisement packet, and it requires some tuning to figure out for how long it should keep repeating the same packet. I set it to 1 s, which seems enough time for the gateways to pick at least one packet up most of the time. With the naive approach, we would have to again send each entry in the batch for ~1 s, which would negate the optimization. An interesting possibility is to use BLE 5's advertising extensions, which apparently can ship 255+ bytes in one packet. I think there would be some energy overhead in this, but it's most likely worth it.

Having said all this, I would like to challenge the gains we're after here. With the simple setup we currently have, we can easily have "always fresh" sensor readings every 10 minutes and we'll have battery life of well over a year. For 20-minutes-fresh-data, we can roughly double that. I think given the nature of what we're measuring, having smaller duty cycles starts to yield diminishing returns, since our plants are not super dynamic.

Let me know your thoughts on this. I would love to be convinced that this is worth working on!

[jhbruhn]

I agree that a transmission / measurement interval of 10 minutes (heck, even 30 minutes i guess) does not really add value for soil moisture measurements, thus I was thinking about keeping the measurement interval at ~10 minutes, but transmitting only in aforementioned cases, maybe if deviation of the current measurements from the last transmissions value is really high. Thus a battery runtime of a couple of years might be possible.

I know that battery consumption is not a problem financially because the batteries we use are really cheap, but actually I'm afraid of all the electro waste one produces with those used up batteries, especially if one uses a lot of b-parasites (I have around 19 deployed right now). Alternatively, rechargeable batteries like an LIR2032 could be an option, but would be expensive and possibly dangerous because of voltages which are too high(?). This is my main motivation for power consumption improvements.

[rbaron]

I think those are super valid and noble motivations and I really sympathize with them. I am in favor of us trying to explore some of those possibilities, specially if we can make it opt-in for users, at least in the beginning, while leaving the simpler setup as a default.

It's a little off topic, but since we're brainstorming here, I would also like to understand more what's possible in this world of ultra low power. Some Ideas on the back of my mind:

• As a thought exercise, let's imagine we could somehow 5x out battery life. Does this mean we get 6-7 years out of a CR2032? Or at some point something else kicks in (like some self discharging effect or simply some natural degradation process)? If so, when would that happen? What role does our spiky power consumption profile in this process (I did a tiny investigation in #1, but we need more info)?
• Can we use a small PCB photocell and a supercap instead of a battery? For how long should we use this setup so it's more environmentally friendly than swapping batteries?

[pvvx]

The duty cycle of the PWM is tuned for the DC component of the voltage drop across the diode.

For real example (Soc:TLSR8253), set the PWM parameters to 1/12. Those. cycle = 12 periods 24 MHz, of which 1 period is an impulse. Total frequency over the period - 2 MHz. Pulse envelope - 12 MHz. R=7.5к, C=100nF. The final sensitivity on the probe is less than 1 pF. A piece of wires in a couple of cm is a sensor for bringing the hand to the case (checking for XiaomiLYWSD03MMC through its case). The voltage with the hand drops to 350 mV and below. Without - more than 405 mV. Test without setting the duty cycle and duration of PWM. Automatic adjustment of PWM parameters for any sensors is possible and uncomplicated.

At C=10 nF, the measurement time is up to 2 ms. Measurement in this case takes up to 2 ms with current consumption up to (!) 5 mA. If measurements are made every minute, then the consumption per measurement will be: (0.002sec*0.005A)/60sec = 0.000000167A = 0.167uA It is necessary to add to it the sleep current (power on: SRAM and RTC) of the SoC - 1.8 uA. When advertising is broadcast every 3 seconds, the average SoC consumption is 5..7 uA (RF TX 0dB). Depends on the transmission encoding. For connectivity on most user equipment (adapters and operating systems), the BLE advertising interval should not exceed 3 seconds. The data is given and consistent with the real test on SoC TLSR8253. When transmitting in the extended advertise c LongRange (Coded PHY) format, the average current is doubled. With RF TX at +3dB, the increase is no more than 1.3 times. Transmission to RF TX with +8dB is not possible from CR2032. There is not enough peak current (25+ mA) from a half-discharged CR2032. Requires the installation of a tantalum capacitor with a large capacitance...