Faster respond for midi application ?

[Lola]

I am using nrf52 , it's always connected to an iPhone, and I need a truly real time respond. I am sending short messages, like 2 characters at a time, and play a sound on the phone according to the messages( e.g "A","B")

Right now, it's fast but not enough for , lets say, play music, there is a 80-150ms delay from when I push the button , till I get the data on the phone, so if you would like to play a song it would be slowly.

Is sending new data every time via characteristic is the right way to go ? or is there another way like doing it without connection, and updating advertising data only ?

How you get the fastest respond for very short messages? what you usually do in these cases ?

Thanx

[endnode]

Hi Lola,

BLE isn't really suited for real-time things as it's based on "little bit of action and lot of silence" principle. Anyway you should be able to achieve 30ms reactivity on iOS assuming you are sending asynchronously data from one side to another over Write or Notify GATT methods (depending if from Server or Client side). That's all iOS can do today, lower intervals then 30ms are achievable only if you can be declared as HID (human Interface Device).

Cheers Jan

Edit 2017-06-11

By "cheating" I mean you could expose Standard HID over GATT Primary Service on your peripheral HW so once it gets discovered by iOS device it should go to faster connection interval then 30ms. You would indeed never send any mouse or keyboard emulating data over HID Service and its Characteristics, but all your other GATT Services will indeed leverage from that short connection interval (= lower latency).

Another "trick" would be to use Peripheral Connection Parameter Update procedure which allows you to request some range of connection interval (this assume your MIDI device is GAP Peripheral similar to Apple keyboard etc.) The central can go to lower range if it want or you could try to limit the range below 30ms so it should go down in every case. Of course this would involve some testing because different HW and SW releases can behave differently (it can also be influenced by fact if there is another BLE connection running on the Central side or not etc.) But in the end you could influence Connection Interval even you have neither access to this through API on mobile side, hence I call it "trick" (but it's standard BLE procedure according to the specification so I might be too big drama queen here).

The last "trick" is to reverse the GAP roles. All iOS devices since release 6 should support GAP Peripheral and GATT Server functions so if your MIDI device can be GAP Central and GATT Client (assuming it supports it - which is the case of all nRF5x devices with Nordic Stack - but also your power budget allows it because it will most probably need slightly more energy even it should be almost equal to operate GAP Peripheral or Central role during continuous connection) you could use any Connection Interval down to theoretical minimum of 7.5ms. According to BT SIG spec GAP Peripheral should accept all values however implementations might differ so iOS device can either try to change it (through that Peripheral Connection Parameter Update procedure) or simply terminate the connection (which is valid way how to "politely" refuse such connection interval and still be compliant with the spec;) Anyway again in the end after some experiments you might find configuration which will be better then standard 30ms of latency.

If you are satisfied with latency of some BLE peripheral such as keyboard and you think your custom device is performing worse then simply load sniffer FW to your nRF5x board (nRF51 DK and Dongle are officially supported but there is unofficial FW for nRF52 DK as well), install Wireshark and record traces of both communication samples (from advertising/scanning phase through connection up to normal operation when commands/data flow over the link) and compare what is different. Note that if devices are using static GATT Server stack or they use Pairing with Bonding you might need to unpair and/or wipe network settings/cache of the device to see full communication flow including GATT Service Discovery (which might be important because you want to see what GATT Services and Characteristics are there).

[endnode]

OK, I will amend my answer to elaborate more on these "cheating" and "forcing" options;)