0

So this is a weird one, but we have written a monitoring iOS app that does two things: (1) acts as a BLE central that acquires data from a device, and (2) acts as a BLE peripheral that transmits data to another observing iOS app (which we have also written).

The data that the monitor iOS app acquires from the device is FAR more important than the data it transmits to the observer iOS app, in that it must display this data with minimal latency to the screen. In fact we have latency checks that make sure we are receiving and displaying this data within 200msec or so. The transmission of data to the observer BLE app is the lower priority function. However, we have currently written it so that every data point that comes in from the device (a) updates the screen and then (b) is written to the local characteristic (as a peripheral) for reading by the observing iOS app (as a central).

What we are seeing is that when the monitoring iOS app is being observed by the observer iOS app, sometimes the monitoring iOS app fails the latency checks. We want this to NEVER happen, we want the data to be transmitted to the observer ONLY when time allows after servicing the incoming data from the device.

Is there a way to structure this so that the monitoring iOS app will prioritize using the incoming data over BLE over sending outgoing data over BLE? Or is there a way to make the transmitting of BLE data to a central less time-consuming? Maybe I can reduce handshaking or something to make it less demanding on the send side.

Any thoughts are welcome. Thank you.

Chris
  • 629
  • 1
  • 10
  • 28
  • Are you using another queue to perform the write? Show some code. – Paulw11 Aug 13 '18 at 20:15
  • It would be a LOT of code... it's more of an approach question than a debugging question. No, no queue on either end. When we RX a value (at 10Hz) we update the screen with the value. Then we just write the same value to the BLE characteristic. Although explaining this makes me think I should decouple this, and that wouldnt be too hard... thanks! – Chris Aug 13 '18 at 21:43
  • Yes, you are probably relying too much on the main thread. Dispatch your writes to another serial queue with a utility QoS – Paulw11 Aug 13 '18 at 21:49
  • Maybe you can try around with different connection interval also. – Emil Aug 14 '18 at 00:06

0 Answers0