iOS / Background scanning / Data logging


#1

We have a huge problem with implementing iOS app that could listen to beacon (not iBeacon) messages as background operation.

What does success look like?

  • There are 20 Ruuvitags sending data to one iOS device that is on the table. Once opened and authenticated to some cloud, it just listens to the beaconing and transfers the data time-to-time to cloud. It continues the operation also tomorrow and day after that without opening the app - as background function.

Notice that the protocol for tag can be rewritten also. If there is some way to implement this operation, I’m really interested.

Is this possible?

If someone has already implemented this or is able to implement this => Award.


#2

iOS background scan is far from being as reliable as on Android (which has its own issues too). Tagging @io53 and @NoHalfBits here.


#3

Can you be a bit more specific on what problems exactly you encountered, and what the deployment path will be (in house, Apple Appstore).
I can think of a few ways to do this, but it depends on requirements and where you are already with this…


#4
  1. The app is going to be put to Appstore
  2. This is not a audio service, so the native way to use background functionality = no go
  3. The app is a simple BT device scanner with logging functionality, must work weeks after one login
  4. The sensors are sending every minute with few kilobytes of payload
  5. We can’t use iBeacon because it’s not suitable for carrying data that changes all the time
  6. Peripheral connection is also maybe no go, because phones can’t handle so many sensors simultaneously

Is this helping at all? :slight_smile:


#5

Just a quick comment on

One BLE advertisement has 34 bytes (iirc), of which 24 or 27 bytes is useable payload depending on if the advertisement is advertisement or a scan response. Sending kilobytes in advertisement would probably require getting creative with BLE5 advertisement extensions, and supporting them on iOS would probably require even more creativity.

Peripheral connection and sending data over Nordic UART Service (for example) would sound easier approach to me. Connections don’t have to be simultaneous, a tag could advertise “Hey, I’ve data, read me!” and stop advertising after read. Phone would then get data from one beacon at a time


#6

I too would suggest peripheral connections to read the data.

The problem though with iOS/CoreBluetooth is that an app will (almost) never see advertisements when in the background. And connections - which offer notifications on value changes - are problematic because of the (undocumented, as far as I’m aware of) limit on the number of concurrent connections, and simply connecting round-robin to all known peripherals is killed by another detail of CoreBluetooth.

But, just out of the back of my head: With the given requirements, and if there is full control of the peripherals radio, the CoreLocation-API may be usable for the “Hey, I’ve data, read me”-announcement. There will be some pitfalls and tricky details, but on the technical side*, this may be the best bet.

@Jarmo_Hiljanen: I may come up with a proof-of-concept implementation; if you’re interested, please feel free to contact me

*) I think this will not violate any AppStore-rules upfront, but it will still require an ugly amount of capabilities and “creative” usage of APIs; with this, app review may turn into a bit of a fight


#7

Hi!

Thank you guys!

I’ve scanned few best Finnish SW companies, had meetings with them and come to same assumption - Beacon is going to be very tricky or impossible to implement like we want.

We have decided to continue development with PoCs. We just have to find the way to do this somehow. So, thanks @NoHalfBits for the offer, I’ll be in touch if our way does not work.


#8

Hello, can a ruuvitag connect to hundreds of mobile phones at the same time and return data?


#9

RuuviTag does not connect to phones. BLE capable devices can listen RuuviTag’s broadcasts. So there is no limit on how many devices can simultaneously hear the messages .


#11

Well, thank you. I see.