Long running data BLE data syncing in the background

Question

Created 2w

Replies 3

Boosts 0

Participants 2

I am working on a Flutter application which is use solely to collect data from a bluetooth low energy (BLE) peripheral and then upload the data to our cloud.

The application runs in the background 99% of the time after the initial login and BLE pairing which is causing us some issues.

After the Application is backgrounded it would work for a day to 2 days and then stop working. (What I mean with working is to download data from the BLE peripheral and then upload the data to our cloud). Once the data syncing has stopped it would take up to 12 hours until data starts flowing again.

I have read in a couple of places that iOS implements some sort of "budget/heuristics" when the application is running in the background to keep track of the application and when this "budget" is used up iOS will stop servicing the application until iOS decides that the application can run in the background again.

My question, is it possible via a enablement or some other mechanism to prevent iOS from blocking our application from running in the background to enable 24/7 periodic data uploads every 30 minutes.

We have implemented the following so far;

The data sync process is triggered from the BLE peripheral using a notification. This notification is sent every 30 minutes.
Each sync duration is currently 24 seconds on average, we are working on reducing this to below 10 seconds.
We implemented State Restoration to assist iOS in starting the application more efficiently.
We are considering using Silent Push Notifications from the Cloud to wake up the application when data hasn't synced in 6 hours.

Any assistance would be high appreciated.

Boost

Answer 1

Engineer OP

Apple

2w

It is not possible to guess what is going wrong with the setup when data flow stops and what is the cause of a 12 hour startup time, without knowing how exactly you have implemented this.

But whatever your implementation is, the only viable way to implement such a system in a deterministic fashion is to control everything from the peripheral. I suppose that is what you are doing based on your steps:

1- the peripheral is triggering a notification and waking up the app. That is the correct way. But, disconnections will happen. I suspect the delay in restarting the data flow could be a disconnection and a delay in reconnection. Once disconnected the peripheral should start advertising as fast as it can. When the scanning app is in the background, the scan rate slows down significantly, so it is important for the peripheral to advertise as fast as it can.

While it is a balance between power requirements and time to connection in the field, during development, you can advertise at 20ms intervals to see if that will resolve the reconnection issue.

2- When woken up with the BLE notification the app will be given about 10 seconds to finish its work. S, cutting it down to below 10 seconds will be important

3- States restoration is good, but you still have the 10 second limitation, so you will want the app startup in response to restoration to be as quick and efficient as possible.

4- Silent push notifications will not help in this situation. Those are heavily throttled and will not be guaranteed that they will reach the app. And even so, it won't help with connection and re-connection issues.

My recommendation will be to solve this from the peripheral side. On the app side, all you need to do is that you send a scan or connect command as soon as you notice the peripheral connection has dropped.

Argun Tekant /  DTS Engineer / Core Technologies

0

Answer 2

reinhartf OP

2w

Hi Argun,

Thank you for the detailed response. Gives us peace of mind that we are on the right track.

I completely understand that it is very difficult to guess why things are going wrong without knowing how we implemented it. Is there a way we could use to give you a better idea on our implementation which could help point to what the cause of our problems could be?

One follow up item which I completely forgot to mention. We have setup the peripheral to advertise as a iBeacon when the connection is broken.

How it is setup is that when the BLE connection is broken the peripheral advertises as a iBeacon for 10 seconds and then switches to normal advertising for 5 minutes and repeats this iBeacon and normal advertising loop until the BLE connection is established again. On the App side we setup Region monitoring so that when the peripheral advertises as a iBeacon the region monitoring starts the Application up. Would this have a negative affect on what you mentioned in point 1 above with trying to connect as soon as possible? Or any other negative side effects we don't know off?

Thanks again for you assistance in the matter.

Reinhart Fourie

0

Answer 3

reinhartf OP

2w

Sorry Argun,

I missed one detail around using the iBeacon.

We are trying to cover a edge case where the user swipes the application out of history.

We use the iBeacon to start the App again due to iOS seeing the user termination as a user event and won't allow the app to run in the background.

We are planning to change the advertising of the iBeacon so that it is only advertised before we send the sync notification as highlighted in point one of my original post.

Hope it clarifies things a bit.

Reinhart Fourie

0