How BC_RADIO_MODE_NODE_LISTENING affects battery lifetime?

TOWER
1

Hi,
Yesterday I totaly drained my batteries in climate module. It works for about two weeks :slight_smile: Yes, it is short lifetime… At this moment I am not sure if I made some changes which causes this abnormal battery consumption, or it is normal, because I am using listening mode.

I modified bcf-radio-climate-monitor example. I changed mode to “radio listening mode” and I modified some intervals. I am checking new values every 20s…

I know, that during some tests, I checked new values so frequently, but I repaired it (i hope).

For next time I am considering to use listening mode only for some period. But at this moment I dont’t know if it is reason of this problem or not.

Thanks for your ideas.

2

In the listening mode, consumption is 10mA.
We use listening mode only for control led-strip,where power is supplied from the network.

3

But If you use BC_RADIO_MODE_NODE_SLEEPING

you can set, how long has listening after send data
void bc_radio_set_rx_timeout_for_sleeping_node(bc_tick_t timeout)

4

Thank you. I am looking for some solution for switching between listening and sleeping mode. I made two functions (“switch to sleeping mode” and “switch to listening mode”), but it works four times and then it stops. I am not so familiar with bc_scheduler_unregister (because I thought that scheduler is scheduled to some tick and after completition of function it die)

Your idea is good, but for me is enough to run listening mode once a day for ten seconds. It is not needed to listen after every published message. Do you have any idea why it doesn’t work? Or is any other (better) solution for changing between sleeping and listening mode?

Thank you very much

Functions: (My idea is that it should work for infinite time…)

04
Screen Shot 2018-11-01 at 19.22.04.png828Ă—486 62 KB

Log: ( It stucks everytime after third switch to listening mode)

42
Screen Shot 2018-11-01 at 19.29.42.png320Ă—615 5.28 KB

5

bc_radio_init creates its new internal tasks everytime. You cannot call init more than once. When the task array is full, the Core Module thwors an error and stays in the infinite loop.

For your use case you would need to have API that can switch between modes on runtime.

If you take a look to the SDK to file bc_radio.c then the variable _bc_radio.mode decides what action is done after transmission. If you would like to change radio to listen, you have to change that mode and then call function _bc_radio_go_to_state_rx_or_sleep(void) which based on that modevariable sets radio RX timeout to infinity.

This is from my head, needs further testing…

Martin

6

OK, thank you… Unfortunately it is totally over my knoweldge at this moment… I need some time to study it… If I understand correctly, at this moment there is not any function which provides ability to change from listening mode to sleeping mode.

There is only option to listen some time after publishing data as Karel mentioned.

This method, as you wrote, means, that I need to modify SDK and globally change function for using radio module…

Am I understand it correctly?

7

Yes, you need to add some functions to the SDK.

I invented a small workaround for now. If you call bc_radio_set_rx_timeout_for_sleeping_node with a parameter BC_TICK_INFINITY then you basically stay in RX all the time after TX. You just have to send any single packet which sends the data (but this will be any dummy data to start radio state machine and after that stay in listen mode).

Later you call the same function with zero, send any packet and radio listening is off.

With infinity there could be an issue with bc_tick overflow. So instead of infinity I would suggest use some high value of milliseconds spanning a day, week… it depends what your constant RX cycles will be.

8

Thanks for detailed explantation and your ivention! I little modified my functions, where I replaced radio_init by calling bc_radio_set_rx_timeout_for_sleeping_node and initialy I am using only LISTENING_MODE. Instead of ifinity loop I used thousands of miliseconds as you mentioned…

At the evening I will try it and I will give you a message! Thank you once again.

20
Screen Shot 2018-11-02 at 07.14.20.png859Ă—319 40.9 KB

9

Hi,
I tried the code above, but without success… It is still listening. Then I tried something more simple - to use this timeout globally in the init function. (I set it only once in the init not in any other function) But it is still listening. I am not sure If I need to do somethig more. I tried to change timeout to some different values, but it is still same. Very weird is that publishing of “Sleeping after this msg” is not performed. But standard publishing of sensor values still goes. Please see the code below. I am not able (with my begginers knowledge) to recognize where is the error :frowning:

I also tried modification which Karel mentioned:

But still without success… I also don’t know why the “trigger” message is still not sent. But it can’t be a problem (I hope) when the sensors publishes their data. It should trigger it instead of the “trigger message”…

Here is my next try:

10

It is almost works!!! Finally… :sweat: :+1:

I made repeating publishing of some message every second using external script. Then I listened same topic on the climate module… Then I experiment with timeouts in bc_radio_set_rx_timeout_for_sleeping_node and slowly catched how it works :grinning:

My previous code doesn’t work because I had too large timeout and I also used timeout wrong… Now I am confirming every received message by another message --> I extend interval for listening.

I wrote that It almost works… because it is still some messages receive in the sleeping mode. (I am still sending messages every second…) I am not sure why, but I need to experiment little bit more.

Thank you very much for your help!

11

It is the Trigger message sent when you for example put it into the init or button press event? It can have issues with long topic+payload text. Try for example bc_radio_pub_int.

I have quite busy weekend now, but next week I could take a look at your code.

If you update your code, please publish the application.c/.h files so we can test exactly the same code you have.
Martin

12

Yes exactly. When I shorten it, it works…

Thanks a lot for your patience with me!

1 Like
13

Ok, so does this shortening of transmitted text resolved the issue that some messages from your script on computer did not get confirmed?

14

Shortening of transmitted text resolved the issue that message was not published from the climate module. At this moment it is publishing without problem.

I am not sure how it works, but there must be some queue or something like that and every message has information about rx_timeout_for_sleeping_node timeout. Because when I change this interval to 0 (stop listening), some messages are still received. It depends on how long is timeout. At this moment I have timeout set to “100” and it works good. I don’t know why, but there must be something which can switch radio to listening (or something is scheduled to publish message with timeout from time, when I had iterval changed to some value - listening).
For example I have blocks 10s for listening and 30min for sleeping. During that 30minutes of sleeping it received approx. 7-10 messages during whole interval randomly. (not only some seconds after I switched that mode). I found it, because I am still publishing messages every second…

17
Screen Shot 2018-11-03 at 08.41.17.png821Ă—1220 79.4 KB

15

Because the node enters listening mode after being sent and waiting for the ACK dongle packet. And timeout set over rx_timeout_for_sleeping_node si calculated after receive ACK.