Community
OpenEnergyMonitor

OpenEnergyMonitor Community

emonTH V2 - now in the shop

Tags: #<Tag:0x00007f1bd88d7138> #<Tag:0x00007f1bd88d6f08> #<Tag:0x00007f1bd88d6d78>

Update emonTH V2 is now in the shop: :tada:


Following on from my post on sensor evaluation:

The first prototype of emonTH V2 with Si72021 sensor is up and running :smiley:

Spot the tiny sensor with the white top in the top RHS of the board. SMT soldering this was quite intense! Managed to get it done using a hot air gun.

Code and hardware files are up on github: https://github.com/openenergymonitor/emonth2

If all goes to plan we hope to get this unit into the shop in the next few months.

2 Likes

emonTH V2 Battery Life Estimate

from: https://github.com/openenergymonitor/emonth2/blob/master/docs/power_consumption.md


The motivation behind replacing the DHT22 Temperature & Humidity sensor used on the emonTH V1 with the Si7021 Temperature & Humidity sensor on the emonTH V2 was the power saving benefits.

See the sensor folder in the emonth2 repo for a power consumption comparision between the DHT22 and Si7021.

This document contains real-world emonTH2 power consumption as measured using a multi-meter & scope resistor voltage drop method explained in previous blog post.

Here is a scope trace illustrating the emonTH power consumption during a sensor sample:

  1. Atmega328 wakes up, starts sensors and takes readings: 17.5ms @ 8.4mA

  2. Atmega328 goes back to watchdog sleep but leaves SPI initialised waiting for wait for RFM to initialise: 100ms @ 2mA

  3. RFM69CW transmission: 4ms @ 44mA

  4. Wait for RF transmission to finish: 100ms @ 0.06mA

  5. ATmega328 wakes up to Print data to serial UART: 5ms @ 7.2mA

Time taken for sample = 17.5 + 100 + 4 + 100 + 5 = 226.5ms

Average current per sample = (17.58.4) + (1002) + (444) + (1000.06) + (5*7.2) / 225.5 = 565 / 225.5 = 2.5mA

After sensor sample is complete the ATmega328 goes back to full watchdog sleep for consuming 0.06mA. This base quiescent consumption includes the quiescent power consumption of the LTC3525 DC-DC converter. See original emonTH hardware blog post for emonTH DC-DC converter design.

Assuming one reading per min (current default) the emonTH is off (sleeping for): number of ms in one min - on time = 60000ms - 225.5ms = 59774.5


To summarise:

  • On current = 2.5mA (average)
  • On time = 226ms
  • Off current = 0.06mA
  • Off time = 59774.5 ms

Oregon Embedded online battery life calculator tool can now be used to calculate battery live. Assuming using 2 x AA alkaline batteries @ 2700 mAhr each = 5400

Given the measured power consumption the emonTh2 is estimated to have a battery life of 7.6 years!

Plugging in the power consumption figures from the emonTh V1 (with DHT22) into the calculator a 1.4 year battery life is estimated.

From real world testing is been established that the emonTh V1 actually achieves a 8 month battery life. This is 57% less than the estimated figure.

Assuming the battery life calculator is overestimating by the same amount for the emonTH V2 we can expect a real world battery life of just over 5 years, which is not too bad :-p

I have setup a battery life test with the emonTh V2 with Si7021 sensor, I will report back in a couple of years :slight_smile:

1 Like

yeah but the dev cycle is a bit long, 5 years to release this enhanced version ? :nerd:

For batteries connected in series, the mAh rating is that of one battery.
(assuming batteries of equal mAh rating)
So your calculation should’ve used 2700 vice 5400 mAh. Still a respectable result though!

Yes, this. And 60 uA is HUGE. A sleeping 328p is only a few uA, IIRC about 3-4 uA for 15 years @ 2700 mAh (including TX+sample). So the most of the power is drawn by the DCDC and the consumption during the time spent in waiting. No way you need to wait 100 ms for SPI to init, and transmission is only a few ms, too. Even after starting sampling, you can make the MCU sleep for those 17.5 ms. RFM startup is way below 1 ms, too. Anyway, still better than v1.

I forgot about the boost converter, which, if It’s fed by batteries in parallel, means 5400mAh is correct.

I think they never were in parallel. It makes little sense to lower the voltage for a boost converter since the lower the voltage the worse the efficiency. Plus it’s better practice to use them in series. OTOH, a DC-DC converter essentially conserves power (in contrary to LDOs) - so indeed, the full capacity is closer to 2x2700 mAh than 2700 mAh. I still would find a stepper-less device a simpler design when the parts can run on very low voltages.

The emonTH was launched in Nov 2013…so three years! Also to our excuses the Si7021 has only been available for the past 24 months…I do my best :confounded:

This is what I’m currently measuring, I might well be hitting the limits of my multimeter. I’ll have another go at measuring. Agree, we should be able to do better. In theory, this is what’s possible:

  • Atmega382 WDT sleep: 4uA
  • Si7021 sleep: 0.06uA
  • RFM69CW sleep: 0.1uA
  • DC-DC: 7uA

Total: 4+0.06+0.1+7 = 11.6uA sleep current should be theoretically possible.

Agree, I’m playing it very safe here as we have had trouble with RFM reliability due to sleeping in the past. I was trying to ensure it has plenty of time to wake up. Since making that scope trace, I have actually reduced the wakeup time to 50ms. I can probably reduce further, I will do some more testing. Reliability… is a top priority over an extra few weeks battery. Thanks for your suggestions, I’ll report back!

How do you mean? The MCU needs to be awake to read from the sensors and take an ADC reading of the battery life. Here is the code during those first 17.5ms. A DS18B20 was not connected during my testing & scope trace capture only si7021. One idea could be to only take an ADC reading of the battery life once per day since this is quite an energy intensive operation. What do you think?

Yes, it would be a nice cost saving to ditch the DC-DC. The reason for using the DC-DC originally to hold the voltage at 3.3V as the batteries discharged was the DHT22 cannot operate below 3.3V. The SI7021 can work down to 1.9V, RFMC9CW down to 1.8V. HOWEVER many users connect external DS28B20 sensors to the emonTH and plug in optical pulse sensor into the terminal block connectors, these sensors require a min of 3V / 3.3V thefore the DC-DC converter is here to say I’m afraid.


Sample Interval?

What are your thoughts on sample interval? Currently, emonTH default is once per min. If the default sample rate could be decreased to once every 2 min this would have a BIG effect on battery. My feeling is once every 2min is perfectly fine for monitoring domestic room temperature (emonTH target application). However, I am aware that some users use the emonTH heat-pump monitoring and control applications where 2min might be a bit slow. What do you think? I’m leaning towards making 2min the default sample time.

You forget the efficiency at that current, which is around 50% IIRC. That would about double the amperage needed in sleep - possibly a lot more.

Well, the Eneloops are NiMH, that have bad self-discharge characteristics. Obviously the best would be using Lithium batteries (like the Energizer Ultimate Lithium or similar) since their shelf life/self dc. is astounding and have the best voltage retention in their lifecycle. But they cost a bit more.

I mean, start T/H sampling, sleep, and at wakeup check/read out the results (I remember making it work with DHT22 but I’m avoiding that sensor now). Considering other factors it might not worth this single saving, though.

I might be missing some details, but why is taking ADC readings such a penalty? I don’t recall it being one. ADC naturally needs to be switched off when sleeping. I don’t think it sohuld be a problem.

I don’t experience such issues but you can use the modeready flag in a loop to check if the radio is in the desired state, instead of fixed waiting periods. I think it’s not only a lot shorter wait but a more robust approach. I generally use the LowPowerLab RFM69 lib and it works quite nicely, with all these nuances handled.

Booster: OK, I can understand why you need the boost converter - I was not aware how important this is IRW extra sensor usage, but it apparently is :slight_smile:

Sampling interval: for room temperature monitoring even 5 minutes is fine. Other usages do require different frequencies - not a simple question. I’d say an ability to configure it would be nice, but it has implications on cost and simplicity of usage…

1 Like

Does the DC-DC converter have an enable pin? If so you could power the bits that go to a low voltage directly from the battery and only switch on the DC-DC converter when using the external sensors.

Yeah, might be a feasible approach. According to the datasheet, it does have a shutdown pin with <1 uA shutdown current.

Interesting idea, it won’t save any cost on components but would result in slight power savings when only using si7021.

It would require a hardware change to connect the enable pin. I’ve committed to a first manufacturing run with the current emonTH V2 hardware. I’ll keep it in mind for the next revision.

You could always not populate the DC-DC converter components (and terminals) and sell a lite/internal only version :wink:

Guess we can circle back to this on the next revision :wink:

I’d personally buy a bunch of the lite, should it ever see daylight. But it seems that the addons requiring the 3.3V booster are much more important so cost saving is not possible, sadly. It’s not simply leaving off some parts, though, the power path is different. So either a slightly modified design or some parts shorted/populated with 0 Ohm resistors.

1 Like

Just to put the cost saving in perspective the LTC3525 is £1.60 1K qty, therefore the lite version would probably come in at about £2-£3 cheaper.

I’m keen to keep variation to the minimum, manufacture is hard enough already!

Power consumption calcs have been re-done using a figure of 2700mAh for the AA capacity, the batteries are in series:

I also agree with @kobuki, 5 minutes is fine for normal temperature measurements, that’s how my emonTX reports now, and I haven’t changed it’s battery since!
If it’s clear in the firmware/read.me how to change this, then people using this for bespoke purposes can set it to what they need, or better still, make is user selectable via a board link?

Paul

If you use the booster, the power is conserved irw. input and output. So you have effectively 2xAA capacity (~5400 mAh) minus losses, as I noted earlier, fixing the presumption of not using a booster. It could still do better with a single Si7021. The 225 ms is excessive. Radio wakeup is around 0.5 ms IIRC. Waiting for 100 ms when you know the TX finishes in 4 ms is not a good idea either, IMO. Though, realistically speaking, after 2 years people forget when they swapped the batteries the last time :slight_smile:

Ah, ok I have reverted the calculations and added a note regarding the losses.

I’m a little confused, is the new EmonTH product discussed above that is sold here? Also, did an option exist earlier without T/H sensor? It might be that only the descriptions haven’t been updated yet…