Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extended sleep mode challenge #1622

Closed
Juanduino opened this issue Jan 29, 2019 · 1 comment
Closed

Extended sleep mode challenge #1622

Juanduino opened this issue Jan 29, 2019 · 1 comment

Comments

@Juanduino
Copy link

Juanduino commented Jan 29, 2019

Helo

This issue is related to the BLE spec itself. The reason why im bringing this up in this thread, is because you are the one´s who can make this happen. I just watched a talk about the NimBle stack and could se the level of knowledge in your group. Well here goes...

Since you control the core, you have the freedom to challenge the framework. Vis a vis, the architecture.

As it is now, the restrictions on connect and adv. interval is in place to keep a steady connection to devises. The iOs restrictions is to my knowledge quite strict and POWER consuming for a minute BLE device running on a limited POWER source.

How about you peeps at Apache show them, how a carefully timed and synchronized handler could negotiate a radio-silence interval of lets say, up to 5 minuttes. This would significantly increase battery life for a BLE device (Not the beacon type). To sum it up. Could you create a custom connection mode, where the connect interval is negotiabel and able to exceed the current restrictions and still maintain viable radio communication by setting exact timers on both ends. Would it drift?

We could call this Silence Mode.

First connection should obliviously be set up by human-machine-interface and the Master/Listener should allow for the periferi device to control the synchronization, in order for multible listeners to subscribe.

Edit: This mode would not make sense for a beacon type application. In a sensor type application on the other hand, it could bring down the average current consumption drastically. I ques it would be a kind of beacon, just not a traditional one, since it needs HMI to set up the first connection, in order to synchronize. The listener could also scan for a given period of time, and then synchronize when it sees the device, which would require some patience. From the user point of view there are many use cases where the interaction would not be a problem, if the connection is maintained.

The question is, will it drift? Or how much will it drift? What should be the window of opportunity?

https://devzone.nordicsemi.com/f/nordic-q-a/16963/app-timer-rtc1-drift

https://www.maximintegrated.com/en/design/tools/calculators/product-design/rtc.cfm

In a mesh configuration i dont know how this plays, its not like i´m some kind of oracle. But to implement it smart, i ques the drift could be measured, averaged, and taken into account.

@sjanc
Copy link
Contributor

sjanc commented Aug 2, 2019

At least for peripheral device you can experiment with getting 5 minutes radio silence by setting 1 sec connection interval and 300 slave latency. Not sure how well this will work due to clocks drift but at least central device would widen its scan window to counter that.

Other option would be to simply drop link and reestablish after 5 minutes:)

@sjanc sjanc closed this as completed May 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants