Hi MT_dialog,
I would like to design a sleeping timer for DA14580, so to implement this I will try with the BLE barebone example. I would like to know how should I start? I know that from UM-B-006, I need to use those API in section 7 but where should I put it in? In the main loop of the arch_main.c?
My algorithm will be this:
DA14580 starts up
DA14580 runs in full speed without getting in sleep mode
DA14580 gets into extended sleep mode after 2 mins (<<
Device:
Hi brian1025,
Yes, thats correct, you can change the sleep mode dynamically by using the arch_disable_sleep(), arch_set_extended_sleep(), arch_set_deep_sleep() (its the API in the SDK5). Regarding your implementation you should have a kernel timer set in 2 minutes, that you can enable after your device is ready to go, for example after your device has done configuring your database or when the device has done configuring the role it has (more specifically in the app_on_db_init_complete or in the app_on_set_dev_config_complete) or even when you device starts advertising. When the timer hits you can invoke in the timer handler the sleep mode you want.
Thanks MT_dialog
Thanks for the advice.
Now I would like to check the lifetime of the board if it never goes to sleep mode. I have measured the current on the board when it is advertising would be 740uA with 700ms adv. interval (not sure, but the comment of the code in app_dialog_beacon_proj.h mentioned 700ms). So, I wonder how can I calculate the lifetime as the table in UM-B-019? I found that the charge consumed per interval won't be (740uA*700ms) as it's not advertising for the whole 700ms interval, thus what will be the duration of the advertisement? Always 9.85ms as UM-B-019 mentioned?
Please advice, thank you!
Hi brian1025,
The 580 advertises once every advertising interval, so your will have to find the time and the charge consumed from the advertising event (check the Figure 19) then subtract the time of the advertising event (which it isn't fixed at 9.85ms at the beacon the advertising event is slightly reduced in order to reach that length) from the advertising interval (the advertising interval isn't always fixed, a random delay +-10ms is inserted into the interval to avoid colliding advertising messages) in order to find the charge that your device consumes while it sleeps/stays idle. This way you will find out how much your device consumes during an advertising cycle and eventually your battery's lifetime.
Thanks MT_dialog