@monte yes, makes sense. I know it takes quite a lot of energy to do one cycle due to multiple (slow) sensors and sending those, but have not really looked into a short wake, skip everything and back to sleep. Could easily count wakeups and only do the sensors every Nth wakeup. Maybe it's actually a good way.
I have some weird issues for which I need the WDG. Found and fixed one forever loop in I2C, but it did not fix all. Can't pinpoint the issue and now it drains the battery randomly by getting stuck somewhere after a week or a few months.

Now I remember one experiment over a year ago with NRF51 based small board I used as mysensors remote. It has just one push button. This silicon version had problem with high current draw if waiting for pin change, so I just made it wakeup every 750ms, poll the button and if not pressed go back to sleep. CR2032 lasted way over a year. Had already forgotten that, good that you reminded!

yep.

So if the description is wrong you can't really use WDG with sleeping sensors, unless the sleep period is less than WDG period ?

@monte understood, however the MySensorsNRF5 says

"*The MySensors port for nRF5 supports using the Watchdog. You can use the same commands like defined in "avr/wdt.h" but disable cannot disable the watchdog. The watchdog is set to a period of 36h of CPU runtime.

When the CPU is in a sleep mode, the watchdog timer is stopped*."

Especially the suspend, or better lack of, under sleep is my problem. I could set it for >20 minutes (sleep time) perhaps, but if the CPU hangs the long period will use a lot of battery before recovering.

Have I missed something or is there an issue with watchdog on NRF52 - watchdog does not get suspended when sleeping ?

Using mysensors 2.3.1 and NRF52832 (Ebyte module) with myboardNRF5. I finally took the time to simplify the code and seems you only need minimum sketch to replicate this, just sleep for longer than wdg period.

Disabling it manually (wdg_disable) before entering sleep does not change this. I did read the disable is not working, but should set it for long period. Now testing with 20s sleep and 10s wdg period, reboots at every sleep after 10s.

Ignore the TEST_PIN stuff, it's there to make it easier to re-program (STlink can't connect while sleeping).
wait() seems to be calling wdg_reset since it doesn't boot there.

#define MY_DEBUG
#define MY_RADIO_NRF5_ESB
#include <MySensors.h>

#ifdef MY_DEBUG
#define DBG_PRINT(...)    Serial.print(__VA_ARGS__)
#define DBG_PRINTLN(...)    Serial.println(__VA_ARGS__)
#else
#define DBG_PRINT(...)    do {} while (0)
#define DBG_PRINTLN(...)    do {} while (0)
#endif


#define REED_PIN	18
#define TEST_PIN	29	// sleep -> wait



void setup()
{
	hwPinMode(REED_PIN, INPUT_PULLUP);
	hwPinMode(TEST_PIN, INPUT_PULLUP);
	Serial.begin(115200);

	DBG_PRINT("PART: ");
	DBG_PRINTLN((uint32_t)NRF_FICR->INFO.PART, HEX);
	DBG_PRINT("VARIANT: ");
	DBG_PRINTLN((uint32_t)NRF_FICR->INFO.VARIANT, HEX);

	wdt_enable(10000);
}

void loop()
{
	int8_t stat=0;

	if (digitalRead(TEST_PIN)) {
		DBG_PRINTLN("sleep");
		//wdt_disable();

		//int8_t stat = smartSleep(digitalPinToInterrupt(REED_PIN), FALLING, 20000);
		//int8_t stat = sleep(digitalPinToInterrupt(REED_PIN), FALLING, 20000);
		int8_t stat = sleep(20000);

		//wdt_enable(10000);
	}
	else {
		DBG_PRINTLN("wait");
		wait(20000);
	}

	DBG_PRINT("Wakeup, stat ");
	DBG_PRINTLN(stat);
	wdt_reset();
}

I tried all the options and maybe got a bit better battery life. However I have now found out, that the actual problem is not likely radio connection after all, but I2C related problem. Started getting more of random drops and after adding some more debug stuff I finally found, that it sometimes get stuck in HTU21 driver, that had a forever loop if there was no proper response. The driver code has later been modified (Adafruit) to avoid this loop. I had my own async version of it, which had the same bug (same code, but split into start() and read() to avoid the delay saving run time).

So likely this random dead battery issue was forever loop draining the battery. Have no idea why it sometimes rebooted by itself, recently it has just died and after reset (battery off and back on) the battery is more or less empty.

@nagelc

good point, have to try. Actually I now have one repeater, but can remove it or maybe move it even closer and use that as static.

I have NRF52-based rain gauge. works well and got finally proper power consumption, but seem to have one problem to solve.
It sends multiple sensor values and then goes to sleep for 20 minutes. This one is on the edge of radio coverage and occasionally seem to loose connection. Below is battery voltage measurement. You can see, that when there's a gap in the values (something wrong in radio coverage) the battery voltage drops rapidly, which suggests it does not sleep, but keeps trying something:

So the question is is there a good set of compile options to remove all checks etc, as I only want this one to send the values? If it fails just try again after the sleep period.

Currently I have

#define MY_SMART_SLEEP_WAIT_DURATION_MS  400
#define MY_TRANSPORT_UPLINK_CHECK_DISABLED
#define MY_TRANSPORT_WAIT_READY_MS  5000
#define MY_RADIO_NRF5_ESB

values are sent like

send(msg);

Any suggestions?

@nca78

about 27uA (Rigol DM3085) @3.2V. It only drops 1-2uA if I disconnect the sensors (all wires towards HTU21,BMP085,VEML6075, BH1750) which is about what the datasheet for those say under shutdown. So most is taken by NRF52. There can be other peripherals that could be turned off still before sleep maybe. Now I only handle the I2C errata and then shut it off before sleep (wire.end), the rest is in mysensors code for sleep.
Sleep current does not change if I don't enable the DCDC. Perhaps the active current does a bit but can't measure it accurately (too fast).

Just estimated that using AA-batteries it should last over 2 years. It only wakes up every 20min and runs about 400ms to send 7 values. But still I'd like to get better.

This is my rain gauge / multisensor under upgrade. It was earlier powered by mega328+NRF24. Worked fine about a year, but then something happened and it started taking 2mA while sleeping. Didn't see any visible reason why.

@omemanti
somehow missed that discussion...

@omemanti

yes, I noticed it uses 3mA after re-program. Seems to keep debug circuits on. After power on/off goes down

Hmm, should read the manual?

ERRATA [89] TWI: Static 400 µA current while using GPIOTE

after adding the workaround before sleep

*(volatile uint32_t *)0x40004FFC = 0;
*(volatile uint32_t *)0x40004FFC;
*(volatile uint32_t *)0x40004FFC = 1;

sleep current goes down to 29uA. It's a bit high still but usable with AA batteries!

NRF_FICR->INFO.VARIANT tells my chip is version AAB0

yes, you're right!
Started experimenting and noticed I was stupid assuming the sensors have nothing to do with this because if I disconnect them while sleeping nothing changes. Well they do. The issue is I2C/TWI. If I comment out all sensorcode sleep current goes down to a few uA. It looks like I can do Wire.init() without this problem, but as soon as the first transaction is done it won't sleep properly. Wire.end() before sleeping does not help (disables TWI). So something changes after a transaction.
To get it to minimum I commented all sensor code and only added (in setup())

Wire.begin();
 Wire.beginTransmission(0x40);
Wire.write(0xFE);
Wire.endTransmission();

if the last line is commented sleep works fine (this is reset command to HTU21, one byte transaction).
I've tried undoing everything the wire-driver does before sleep, but can't figure out what helps.
Any ideas?

I think the 250uA difference is related to whether HFCLK is running or not - if the device uses 250uA while sleeping my STlinkV2 works fine (re-program). If it goes down to a few uamps STlink does not work ,"can't connect target" (no reset pin used).

hmm, I experimented with DCDC. Don't have correct inductors, but added 2x 4u7 axials in series and NRF_POWER->DCDCEN=1 in setup(). Active current did not change, but sleep went down to .25mA. Still way too high.

Ordered SMD inductors, will see if it changes anything.

I started experimenting with NRF52 /Ebyte E73 module and mysensors. Code works fine, but the issue is sleep current. It seems to take ~0.5mA under sleep(). Anyone else using batteries with this module?
I'm on latest dev mysensors and arduino 1.8.8, sandeep nrf5 0.6.0.

About a year ago I tried mysensors on small NRF51 board. It has the interrupt wakeup errata, so my code sleeps 750ms, wakes up and checks button press (it's a simple remote). If not pressed sleep again This has now lasted over half a year on CR2032, so I'm surpriced by the E73 sleep current.

I do not have the inductor for DCDC, but as I read from Nordic articles it mainly saves on higher currents plus I don't know how to enable it on myseonsrs environment...

The module seems to use ~16mA while working and then .5 after sleep() powered from 2x1.5V battery. It does have multiple I2C sensors, but if I disconnect the sensor cable while it's sleeping the .5mA does not change.

@manutremo

now merged, thanks!

So this should fix the bootloader hang without pullups. The binary got a bit bigger again, but does not change much of anything since it still fits into 2k (1024W).
I tested it with 8 and 16MHz pro mini with a few different EEPROMs (256 and 512kb).

@manutremo

been quite busy lately, can't promise anything but I'll try. It is an issue, but I don't think it's very urgent since if one uses I2C bootloader at least the pullups should be there.

I was thinking of two things to try. Perhaps enabling the internal pullups may help (need to check if it works when TWI is enabled) or better fix the forever loops in the I2C code. There's already some retry counters for errors, but not everywhere. I guess when the pullups are not there TWI controller gets weird states and the code just loops retries somewhere. So perhaps add a counter to all the retrys (several locations in i2c.h, begin-label at readbyte would be my first choice. restart-label already has a counter).

There's also OpenLog. Haven't tested yet, but just got one (China clone for about $4, Sparkfun $14.95). It's about the size of microSD card and logs all serial input. Spec says "2mA idle, 6mA at maximum recording rate" which means something like 2 weeks with 2xAA. One issue might be voltage, it says 3.3 - 12V input, don't know if it works unmodified with less, i.e. without step-up.

I might also like to use the BT you included in your version.

@manutremo

Good to hear. I'm aware of one issue only as described above by @melwinek, haven't found time to fix. So "seems to work", but have done limited testing.

Yes, you need older Arduino IDE version. I have actually two versions installed, latest and 1.0.6. Using latest for all except bootloader.
I don't have to copy anything, I just cd to the bootloader located under old arduino tree (git cloned to Program Files (x86)\arduino-1.0.6\hardware\arduino\bootloaders\DualOptiboot) and do

omake atmega328_e8

from windows cmd prompt.

This is forked from mysensors bootloader, maybe it could be merged back there some day with step by step instructions.

One more update:

have not fully verified, but it seems like this was RF interference issue (maybe a transmitted ACK??).

I added a 100n ceramic cap to power in line (at the GPIO connector) and 10nF caps from UART TX and RX to ground (small SMD caps at the connector). I also moved the antenna a bit higher by soldering coaxial cable to RFM and then peeling off the outer shield of the coax for the ~80mm. Problem gone!

I'll add a ground plane to the antenna by putting aluminium tape to the top cover (missing here) and connecting the coax shield to it. Makes a better antenna and better shielding towards RPi. Have not re-checked range yet, but checked the UART signals with scope and the 10nF looks good as noise filter.

Note about RS485:

I've had (non-MySensors) issues with RS485 with some setups due to the fact that while the bus is not driven (no one sends anything) it's floating and not in idle state. This makes receivers pick random garbage. To make it stable you'd need to add pullup to the A line and pulldown to the B line (hope I remember polarity right way). Those will make sure the line stays idle. With two 120R terminators (both ends) the pullup/down needs to be quite small to create enough voltage across 60R. One could calculate (I think spec says 200mV), but I've used 470..680R with 5V system. Some interface modules may have these or similar current source on board.

Termination with low speeds and short lines seems not so critical in practise.