Mayfly power on during sleep.

[fisherba]

I'm testing all of the new fixes today on two stations:
http://data.envirodiy.org/sites/OMS01/
http://data.envirodiy.org/sites/BIXBY_1/

The logging intervals are exhibiting the expected behavior, and I really like that they are rounding to log at an easy to use time interval (00, 15, 30, 45, etc).

However, as I sit at my desk with the stations running next to me, I can see that the red LED3 on the corner of the board by the analog connectors is aways on. I confirmed that the I2C and Pins 4-5, the pins I'm using, are on "switched" power. Then I checked the voltage for each board and when they are not logging, I get a voltages of 1.97 (BIXBY_1) and 2.28 (OMS01).

[SRGDamia1]

At the OMS site, I'm guessing this a duplicate of #140, where the RS485 adapter is sucking power from the data pins. Can you try writing out your loop?

When you write out the loop:

Add ModemSerial.begin(ModemBaud); just before sensorsPowerUp()?
Add ModemSerial.end(); digitalWrite(5, LOW); digitalWrite(6, LOW); just after sensorsPowerDown()

[SRGDamia1]

The Bixby site, with no RS485 adapter does puzzle me. I've never noticed the DS18 or the BME280 sucking power from the data lines, but that doesn't mean they aren't. I know nothing about the MS5803. Can you take off peripherals one at a time and record voltages? Don't change the code, just let the code run as if the sensors were connected. That should help to show if it's some sort of parasitic data pin draw or if it's a code problem.

[fisherba]

I did two rounds of removing sensors on the Bixby site and both had the same result. Also, when the sensor reads I get 3.29 V.

Starting value: 1.97 (as before)
Remove BME280 (sparkfun): 1.87
Replace BME280: 1.97
Remove MS5803: 1.95
Replace MS5803: 1.97
Remove DS18: 1.97
Replace DS18: 1.97

I'll have to grab the RS485 stuff later.

[SRGDamia1]

Can you remove both I2C together? Is it sitting at 1.97V with nothing attached?

I'm reading up on how to do a better job of ending the I2C instances so the pins aren't left hanging. I will also look at ensuring the OneWire bus pin is set low at the end.

You don't need to test removing the RS485; we know it steals power via the Tx/Rx pins. The only thing that's not tested is if the begin/end/set pins fixes it.

[fisherba]

Removing all I2C drops it down to 0.05 V. So it seems that the whole I2C situation is the culprit. Also, when we unplug I2C the LED3 goes off.

[fisherba]

Looks like @aufdenkampe made progress on #140, but I have several stations with I2C and RS485, so I'm excited that you are pursuing your ideas on I2C.

[SRGDamia1]

Try the i2cparasites branch and let me know if it works. I'm actually killing and reviving the I2C pins in the main logger sleep functions. It's a bit less code to do it that way, and the I2C is crucial to the "logger" as much as it is to any sensor because that's how the logger talks to the clock. This does mean that the i2c power-suckers will have a little bit of extra time to steal power between the sensorPowerDown and the logger sleep, but that should be a pretty short gap.

[fisherba]

Trying the branch right now.

[fisherba]

No change in the power usage by I2C devices using fd7db5e

[SRGDamia1]

I don't have many more ideas. I'll read more. Are you sure you can't just buy some better sensors? The BME280 I have definitely isn't stealing power. Can you physically isolate the sensors some other way?

[SRGDamia1]

You can try again with the latest commit. If that doesn't work, I really am out of ideas. Make sure you run a "clean" in PlatformIO before uploading.

This is the BME280 I have: https://smile.amazon.com/gp/product/B0118XCKTG/ref=oh_aui_search_detailpage?ie=UTF8&psc=1

[SRGDamia1]

Okay, reading more, looking at diagrams, and talking to @s-hicks2 , there is nothing I can do in the code to stop the problem. The Mayfly has external pull-up resistors on the SCL and SDA lines. So no matter what the code sets the pins to, those pins are still going to be connected to power via those pull-ups. You will have to find a hardware solution; either adding some sort of board between the offending sensors and the Mayfly or getting different sensors.

[SRGDamia1]

In theory, you could solve this with software if you switched to software i2c without pull-ups on the data lines, but that's not something this library is likely to support in the near future (#149 ).

[bschulz1701]

@fisherba asked me to take a look at this, firstly I can confirm the consensus of all here and @s-hicks2, I have definitely run into the issues of phantom power flow through the I2C pins due to pullups. In my applications I have dealt with this currently by not having on board I2C pullups, instead using the internal pullups on the device (which are automatically activated by the Wire library). The external pullups can be useful to increase the transmission rate or to deal with stray capacitance on the I2C lines, however I have yet to run into an issue where this has caused a problem, especially if you have pullups on the slave devices. If this is done, when the device goes to sleep, then the output buffers will be shut down and those pullups should be released, preventing any tangible current draw. And if there are pullups on the slave devices, these should be defeated by turning off the external power to them.

This could be accomplished by simply removing the on board pullup resistors, I could provide further details/instructions for this.

Also, @fisherba a potential hot fix could be to cut jumper SJ3 on the bottom of the mayfly, this would be a non-permanent modification which could effectively solve the problem. Even when current is being pulled through the I2C lines into the sensors, it is likely quite small (<1mA potentially, depending on the device), but having an LED at that voltage will draw more significant current, likely several mAs. So you could try measuring the current draw in the current configuration, then cut the SJ3 trace, then repeat this measurement and see if the current value is sufficiently reduced to give the longevity you need.