You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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.
The text was updated successfully, but these errors were encountered:
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:)
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.
The text was updated successfully, but these errors were encountered: