Sensebender Micro Battery Code
-
Hello together,
i have bought a sensebender micro to test as temp and humidity sensor. I use the example sketch from sensebender, and for test i used a cd2032 battery but the battery is after 14 days empty.
So i have to optimize my code and would like to ask you which settings are you using for battery nodes.How often do you transmit the temp / humidity?
Which threshold for changing the temp / humidity?Thanks a lot
Greets Eddie -
Hello together,
i have bought a sensebender micro to test as temp and humidity sensor. I use the example sketch from sensebender, and for test i used a cd2032 battery but the battery is after 14 days empty.
So i have to optimize my code and would like to ask you which settings are you using for battery nodes.How often do you transmit the temp / humidity?
Which threshold for changing the temp / humidity?Thanks a lot
Greets Eddie@meddie As far as I'm concerned you should use the sleep() function. Also it's a good idea to use internal oscillator down to 1mhz and set the BOD to 1,8v. Also I think reading the temperature and humidity once in 5-10 minutes is enough,and transmit if it changes. There is a thread of the forum about cr2032 temperature node.
-
@meddie As far as I'm concerned you should use the sleep() function. Also it's a good idea to use internal oscillator down to 1mhz and set the BOD to 1,8v. Also I think reading the temperature and humidity once in 5-10 minutes is enough,and transmit if it changes. There is a thread of the forum about cr2032 temperature node.
@Tigroenot BOD is increasing the sleep consumption. I am not using any BOD for the battery nodes.
-
I throw my 2 cents, because I am now also designing some battery powered nodes and have some thoughts.
First of all, You have to minimize power consumption during sleep, for cr2032 batteries it should be around 10uA or less. To do that all the peripheral devices must be also in sleep mode (the radio sleep is handled by the MySensors sleep function). Check also for any passive components (pull-up resistors {CPU internal pull-ups also} that are held to the ground for a long time , LEDs), those will drain Your battery fast.
The next step is to implement the proper algorithm for sending the data. On the one side you want to send as little as possible (so send only when the value changes more that x%) but on the other side You want the reliable transmission that is resistant to packet loses. One way to implement that is to just send always at the given interval, but that will contradict the fist requirement. So I would suggest to use ack'ing, that way You know when You really need to resend the data. But this is not all, You can't just resend every time immediately when you do not get ack from the GW - that would drain your battery very fast if the GW would be out of reach for an hour or more. So You need to resend smart. I do this by increasing sleep time after every consecutive send failure, so after first failure i sleep for 1s, then if retransmission fails, i sleep for 2s, if next also fails sleep for 4s, then 8s, then 16s and so on up to 1 or 2 hours.
I have some code to handle this resending algorith, so If You are interested I could put it on github. -
I throw my 2 cents, because I am now also designing some battery powered nodes and have some thoughts.
First of all, You have to minimize power consumption during sleep, for cr2032 batteries it should be around 10uA or less. To do that all the peripheral devices must be also in sleep mode (the radio sleep is handled by the MySensors sleep function). Check also for any passive components (pull-up resistors {CPU internal pull-ups also} that are held to the ground for a long time , LEDs), those will drain Your battery fast.
The next step is to implement the proper algorithm for sending the data. On the one side you want to send as little as possible (so send only when the value changes more that x%) but on the other side You want the reliable transmission that is resistant to packet loses. One way to implement that is to just send always at the given interval, but that will contradict the fist requirement. So I would suggest to use ack'ing, that way You know when You really need to resend the data. But this is not all, You can't just resend every time immediately when you do not get ack from the GW - that would drain your battery very fast if the GW would be out of reach for an hour or more. So You need to resend smart. I do this by increasing sleep time after every consecutive send failure, so after first failure i sleep for 1s, then if retransmission fails, i sleep for 2s, if next also fails sleep for 4s, then 8s, then 16s and so on up to 1 or 2 hours.
I have some code to handle this resending algorith, so If You are interested I could put it on github.@rozpruwacz I am very interested in handling the ack, I think it is not that well documented feature, great if you can share your take on it
-
I throw my 2 cents, because I am now also designing some battery powered nodes and have some thoughts.
First of all, You have to minimize power consumption during sleep, for cr2032 batteries it should be around 10uA or less. To do that all the peripheral devices must be also in sleep mode (the radio sleep is handled by the MySensors sleep function). Check also for any passive components (pull-up resistors {CPU internal pull-ups also} that are held to the ground for a long time , LEDs), those will drain Your battery fast.
The next step is to implement the proper algorithm for sending the data. On the one side you want to send as little as possible (so send only when the value changes more that x%) but on the other side You want the reliable transmission that is resistant to packet loses. One way to implement that is to just send always at the given interval, but that will contradict the fist requirement. So I would suggest to use ack'ing, that way You know when You really need to resend the data. But this is not all, You can't just resend every time immediately when you do not get ack from the GW - that would drain your battery very fast if the GW would be out of reach for an hour or more. So You need to resend smart. I do this by increasing sleep time after every consecutive send failure, so after first failure i sleep for 1s, then if retransmission fails, i sleep for 2s, if next also fails sleep for 4s, then 8s, then 16s and so on up to 1 or 2 hours.
I have some code to handle this resending algorith, so If You are interested I could put it on github.@rozpruwacz Sure, please share. It will all help a lot to see from the other perspective all the smart lifehucks and to finally get to desirable 3uA sleep consumption :)
-
@Tigroenot said in Sensebender Micro Battery Code:
consumption
OK, i upload my code to github and share it with all, but I must warn that it is work in progress and it will change a lot and is not tested very well (just on my 3 different sensors).
@Tigroenot 3uA ? hehe :P my multimeter showed 4uA on 2000uA range (the lowest i have) for a door/window sensor (atmega + nrf24 + battery voltage divider + pull up resistor on one of the gpios + all powered with directly from cr2032 battery), but probably the measurement error is significant ... -
@Tigroenot said in Sensebender Micro Battery Code:
consumption
OK, i upload my code to github and share it with all, but I must warn that it is work in progress and it will change a lot and is not tested very well (just on my 3 different sensors).
@Tigroenot 3uA ? hehe :P my multimeter showed 4uA on 2000uA range (the lowest i have) for a door/window sensor (atmega + nrf24 + battery voltage divider + pull up resistor on one of the gpios + all powered with directly from cr2032 battery), but probably the measurement error is significant ...@rozpruwacz said in Sensebender Micro Battery Code:
@Tigroenot said in Sensebender Micro Battery Code:
consumption
OK, i upload my code to github and share it with all, but I must warn that it is work in progress and it will change a lot and is not tested very well (just on my 3 different sensors).
@Tigroenot 3uA ? hehe :P my multimeter showed 4uA on 2000uA range (the lowest i have) for a door/window sensor (atmega + nrf24 + battery voltage divider + pull up resistor on one of the gpios + all powered with directly from cr2032 battery), but probably the measurement error is significant ...No error, it's just a matter of faith :)
-
The lib for handling sensors values (sending them to GW when needed and resending on filures) is here https://github.com/mczerski/MyMySensors and the example that uses it is here https://github.com/mczerski/DHTSensor. It probably have bugs :) so any suggestions will be appreciated.
