Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of WikiWatershed, a web toolkit designed to help citizens, conservation practitioners, municipal decision-makers, researchers, educators, and students advance knowledge and stewardship of fresh water. New to EnviroDIY? Start here

Monitoring power consumption

Home Forums Mayfly Data Logger Monitoring power consumption

Viewing 11 reply threads
  • Author
    Posts
    • #14611
      Matt Barney
      Participant

      I’m wondering what techniques people have used to monitor power consumption by their Mayfly installations in the field. On the desktop, I suppose you can measure the current being drawn from the battery by using a multimeter, though I haven’t done that yet. And you can measure the current drawn by a sensor during its operation as well. Ideally, it would be great to be able to have the Mayfly itself take these measurements and report them as a variable. Is that even a realistic idea?

      I have a couple of use cases for this idea. We have stations in the field that we suspect are consuming more than usual power due to marginal cell signal, but it would be nice to know what they are actually experiencing under field conditions. Second, as we investigate new sensors to try, it would be nice to be able to field test them under various conditions and to be able to monitor their current draw over time.

      I’ve done this kind of measurement on solar power systems using a shunt to calculate and log net power use (charging minus draw), but I don’t know whether it’s feasible to have a microcontroller like the Mayfly to monitor itself as I’ve described.

      Hope this makes sense!

      Matt

      Trout Unlimited

    • #14613
      Matt Barney
      Participant

      It looks like this power sensor from Adafruit could work: https://www.adafruit.com/product/4226

      This sensor, with accompanying library from Adafruit, returns milliamps, millivolts, and milliwatts via I2C, so seems promising.

      This is new territory for me, so if anyone has insights or advice, I’m happy to hear it!

      Matt

    • #14614
      Jim Moore
      Participant

      @mbarney

      I have the same issue.  I have my LEC stations (GMI_ECxx) running with 2G cell service and I did have one station that the solar charge chip failed and caused battery to drop below the 3.55  volt threshold for upload.  However GMI_EC5 seems to be getting a charge during the day but is still not keeping up.  I attached a screen from MMW TSA and you can see the drop-off in voltage on this sensor station vs the others.  I also noticed a general drop off which I presume is amount of daylight.  I am using the 2.5 AH batteries.  I plan to check current draw to see if it is abnormal or caused by poor cell service.

    • #14619
      Matt Barney
      Participant

      Interesting, thanks Jim. I’ve been wondering whether one of our problem stations has a charge controller chip that’s impeding its charging, so we’re preparing to swap out the Mayfly to troubleshoot.

      -Matt

    • #14623
      Jim Moore
      Participant

      @shicks

      I checked my GMI_EC5 station that I mentioned above that was not keeping up and I measured about 2.4 mA current draw when the mayfly is in sleep mode.  I thought it should be close to zero when in sleep mode.

      Any thoughts Shannon?

       

      • #14629
        Shannon Hicks
        Participant

        Without having been to that station myself, it’s hard for me to guess why that station is having more battery trouble than your other ones. I’m guessing maybe it’s more shaded, or possibly the solar panel isn’t pointed in an optimal direction? You could also try putting a voltmeter on the panel on a sunny day and make sure it’s putting out around 6v (or even better, put an ammeter in line and read the charging current). We’ve had a couple of panels fail over time and don’t provide enough power to fully charge a battery. We’ve also seen issues where the charge controller circuitry on the Mayfly would partially fail and cause it to default to the trickle charge rate instead of full current charge. We’ve also had malfunctioning GPRSbee modules that tend to drain the battery power quicker even when asleep. I’ve also seen problems with microSD cards that start to go bad and draw excess current when the Mayfly is supposed to be sleeping.

        So I’d say check your solar panel voltage, remove your GPRSbee, and replace the microSD card. If none of those fix the issue, put a new Mayfly in there. If the battery levels still fall, then replace the solar panel. If none of that solves the problem, then it’s likely just a shady location. If you’ve got deciduous trees around the station, sunlight should be improving in the coming weeks as the leaves fall, so that may also affect your results. We have a few stations that always struggle to stay charged during summer because of the full canopy above them, but they do great the rest of the year, even in the winter when the sun angle is lower.

    • #14631
      Jim Moore
      Participant

      Thanks for the info Shannon.  I will check out the GPRSbee and sd card to see if they are the cause of the 2.4 mA draw when in sleep mode.  I’ll try a new Mayfly board next.

    • #14656
      neilh
      Participant

      I’ve been using the INA219 and contributed sensors\TINA219
      I’ve used it for measuring a working Mayfly on the lab bench. For  field monitoring, I would think you need a coloumb counter ~ eg LTC2941 ~ I have an adafruit version but haven’t tried it.

      On the lab bench I have the INA219 on a separate Mayfly with console and put in in series with the target systems LiIon battery.
      https://github.com/neilh10/ModularSensors/wiki/Test-equipment-cable-monitor-LiIon

      For measuring a working Mayfly current I disconnect all other sources of power, and even have a special version of the FTDI cable to plug into the FTDI debug (instead of USB data/power) with the Ftdi Tx cut (as its held high and leaks current)
      https://github.com/neilh10/ModularSensors/wiki/Test-Equipment-FTDI-cable

      Using this arrangement, sampling every 2secs to get an idea of the instantaneous current
      https://github.com/neilh10/ModularSensors/tree/release1/tools/current_logging

      There has been past discussion on Mayfly sleep current. IMHO I’ve got to be in reasonable shape, but perhaps not meeting what a calculated minimum suggests it could be. https://github.com/EnviroDIY/EnviroDIY_Mayfly_Logger/issues/21

      I figured for reliability of systems in the field a software based Battery Management System was more viable than trying to tweak down the sleep current. The target is reliable data collection, and reliable delivery for low cost LiIon/4Ahr battery and solar panel/5W.  Note the Mayfly Vbat monitor becomes non-linear at about 3.6V

      The figures I got for Mayfly sleep was 2~4ma.  I have some notes that when I started taking measurements it was about 5mA. I did some tweaks got it down. Here are the measurements I made in my log with a Digi Xbee WiFi.
      <h3>2018Dec12 sleep Current readings</h3>
      with INA219 monitoring from another Mayfly
      1st time through from RESET
      02:13:24.972 mA: 3.80, V: 0.908
      02:13:26.971 mA: 1.90, V: 0.936
      02:13:28.972 mA: 2.10, V: 4.048
      02:13:30.973 mA: 7.70, V: 4.044
      02:13:32.972 mA: 4.00, V: 4.048
      02:13:34.999 mA: 3.60, V: 4.048
      02:13:36.999 mA: 38.20, V: 4.020 <sensors starting

      02:13:38.999 mA: 38.20, V: 4.024
      02:13:40.999 mA: 38.20, V: 4.020
      02:13:42.999 mA: 38.20, V: 4.020
      02:13:44.999 mA: 38.20, V: 4.020
      02:13:46.999 mA: 105.30, V: 3.972 <1st time Xbee including setup
      02:13:48.999 mA: 90.00, V: 3.972
      02:13:50.999 mA: 107.20, V: 3.968
      02:13:52.999 mA: 106.80, V: 3.968
      02:13:54.999 mA: 107.20, V: 3.968
      02:13:56.999 mA: 106.70, V: 3.968
      02:13:58.999 mA: 53.80, V: 4.000
      02:14:00.976 mA: 107.50, V: 3.964
      02:14:02.977 mA: 121.90, V: 3.964
      02:14:04.976 mA: 106.80, V: 3.960
      02:14:06.977 mA: 106.80, V: 3.964
      02:14:08.977 mA: 106.40, V: 3.964
      02:14:10.976 mA: 121.10, V: 3.960
      02:14:12.977 mA: 106.60, V: 3.956
      02:14:14.978 mA: 107.40, V: 3.956
      02:14:16.979 mA: 3.60, V: 4.028    <off sleep
      02:14:18.978 mA: 3.60, V: 4.032
      02:14:20.979 mA: 3.60, V: 4.032
      02:14:22.980 mA: 3.60, V: 4.036
      02:14:24.978 mA: 3.60, V: 4.03

    • #14657
      neilh
      Participant

      I should note, that for real world solar panels, the power supplied by the panel is  dependent on the solar photons received. For a  slow change in power delivery some circuits have some strange behaviour.  I’ve had a Mayfly with an LTE  module, and a 2Ahr battery, and at sunset it started resetting. It continued resetting for about 30minutes until the sun’s power was completely gone. I had let it run and this repeated every night for a week.  I changed out for a 4Ahr battery and the resetting stopped. The 2Ahr battery was being fully charged every day, and when the sun was down it ran OK overnight – just in the twilight zone it had a problem. Was OK with sunrise.

      I was monitoring the LiIon battery voltage with both the Vbat ADC and also externalV with 100K-100K divider. The Vbat ADC was showing a funny dip in voltage before it reset – but I never investigated further – just made sure I used the 4Ahr battery.   I am doing some characterization work how to measure a battery that is below 3.7V – but still ongoing.

    • #14663
      Matt Barney
      Participant

      Thanks for sharing this good work, Neil. This does get technical, and I have a lot to learn, but your experiences will be helpful. For the short term, our team is primarily interested in knowing approximately what the limits are, for a given site, for a given set of sensors, whether the available solar power will keep our stations running for the site-specific constraints. Larger panels and batteries are a potentially cheap solution, relative to my R&D time, though Issue#23 describes the existing limitations of the Mayfly circuit’s charging current, which I was not aware of until just now. We’ll have the option (usually) to reduce sampling frequency to save power. Another avenue for power savings might be to implement 2 Loggers: one that logs frequently to the SD card, and one that runs less frequently to transmit via cellular, which can be a high drain, as I understand it. Just thinking out loud.

      -Matt

    • #14664
      neilh
      Participant

      Hi Matt, power is a challenge. I always think of those battery watches with a tiny battery in them. How do they do it.

      My take is this. a) what is the minimum energy its going to collect across the really low solar months  eg winter months  b) What is the longest I want the system to run for with no solar power – that is usually a storm of some sort.

      Then the stored power can be budgeted into two sections – one for the time period that it needs to be working/sampling to run with no solar energy input, 2) when there is “excess” energy that can be used to transmit the readings to the cloud.  An assumption in this is of course that the readings will be stored (on uSD), and when there is available energy can be reliably delivered to the cloud . (https://github.com/EnviroDIY/ModularSensors/issues/194)

      The current Mayfly charging circuit assumes a relatively low impedance on the solar side, and for all practical purposes its easy to over specify the solar panel to 5-10W (for Mayfly) so it is likely to delivery the 0.5A at 4.5V when ever there is solar power there.   For a 4Ahr battery, it would be charged in 8hrs  ~ a summers day but in winter?

      On the consumption side  – I’ve put a spread sheet together in mA-secs or mA-minutes to estimate usage. So using mA/minutes a 4Ahr battery has 4,000mA*60minutes – 240,000mAmin.

      For 24hrs if sampling is every 15minutes and takes 0.5min of running current – say 38mA and the other 14.5min are at a sleep current of 2mA. Then every 15min it consumes 38*0.5+2*14.5 or 17+29 or 46mAminutes – and in a day – 96 sampling periods ~ would take 4,416mAminutes. So for 4Ahr this would likely last over 54days without any solar power.  However with the battery power “budgeted”, if the 4Ahr can be divided into 2Ahr for communications and 2Ahrs for guaranteed core taking readings then using 4,414mA it would have 27days.

      I’ve created a Battery Management System to be able to partly implement this in a “simple” way. Yet to be entirely proven.  The basic premise is that at critical points in the program a call to the BMS asks is there enough power for the operation to be performed? One of these points, after wake up is to check if there is enough power to transmit readings. If the answer is NO, it just does logging, if Yes it does LoggingAnd Transmisson. (Uses the current Class entry points)

      So far I haven’t considered the power cost of transmitting the readings to the internet, as its expensive in power, but this would only happen when there is enough power. So a separate budget power exercise needs to be performed for the cost of transmitting, but it can be gated so it only does it when there is sufficient power (for a winter that might happen  after the sun has risen enough to be charging the battery).

      In practice the LiIon voltage is partly dependent on ambient temperature (cold in winter), and Mayfly mega1284  Vref tied to Vcc at 3.3V, and combined with charging/Solar input. So Vbat does not reflect LiIon battery at all times. So for NO solar the Vbat ADC results are accurate from 4.2V to about 3.6V, when it becomes non-linear due to power cct LDO dropouts. For ~~good~~ solar the Vbat ADC reflects how well the battery is being charged and is likely above 4.2V ~ mostly not a problem.  So hopefully the Vbat absolute voltage could have a number 3.8V? (…. 3.9V) that is  crudely interpreted as a  50% (or 75% ) “fuel gauge”  for a reasonably large LiIon battery. The problem may be when there is weak solar, and when the Vbat absolute readings are taken may indicate a solar charging voltage, that doesn’t reflect the power stored in the battery. The Modem takes power at different time than when the Vbat ADC reads the LiIon voltage ~ so there could be nonlinear Vbat readings just at the most needed time when the LiIon is run down. That is with a weak solar charging current the Vbat is the solar charge voltage, not the LiIon battery voltage.   I’ve been investigating a separate battery monitor on the external ADC, and potentially also the  Xbee LTE’s has a voltage converter that can measure the Vcc (which should be ~ 3.3V).

      https://batteryuniversity.com/learn/article/discharge_characteristics_li

      For being able to do shorter time period testing I’ve been using a 500mA hr battery for testing the BMS transition thresholds, and I’ve built in an option for different types of batteries 2Ahr ..4Ahr with different thresholds.

      Well hope its not too much detail, but I’d be interested if this going in the direction you think might answer your questions. 🙂

    • #14670
      neilh
      Participant

      I’ve had a simple system soak testing. Its not meant to be a deployable system, but I’m using it for testing out powering related algorithms.

      It has an Xbee WiFi, LiIon 500mA, measuring MayflyVbat and ADS1115 extVbat. When the extVbat voltage is >=3.85V it will

      Logger dataLogger.logDataAndPublish();

      and when below <3.85V only

      Logger dataLogger.logData();

      I’ve used the 3.85 threshold as I found the Mayfly was resetting when the WiFi turned on and LiIon battery was around 3.7V.

      For the “Solar Panel” I’ve got it connected to a power supply and simulating low sunlight conditions with a charge typically round 25mA.

      The graph of this running since Oct 10th is

       

    • #14711
      neilh
      Participant

      I’m sharing some integration test results. I’ve been using a Vbat=4.0V threshold – that is under Vbat=4.0V it does sensor readings only, and stores the readings for later reliable data delivery.

      When the battery voltage is over Vbat=4.0V it POSTs the readings to MMW.
      Discharge and Charge Graph

      A feature of using 4.0V is that probably works for the Mayfly Vbat measurement, and really extends the effective life of the battery when there is no solar. A wrinkle is that a lot of readings can be stored, which could exhaust the available power in the battery if all transmitted in one shot. So when a connection is made after X(default=10)  retransmission of POSTS from the FIFO file, it checks the battery again to see if it is still over 4.0V.

      These are all on my “rel1_dvlp1m” branch – https://github.com/neilh10/ModularSensors/tree/rel1_dvlp1m   – and I’ll plan to describe it and make a release in the near future.

Viewing 11 reply threads
  • You must be logged in to reply to this topic.