Faster respond for midi application ?

RE: Faster respond for midi application ?

endnode — Sun, 11 Jun 2017 09:49:10 GMT

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

RE: Faster respond for midi application ?

Lola — Sat, 10 Jun 2017 21:32:21 GMT

Thanks, obviously i am using nrf52, so if HID is faster, I am not sure why i have to cheat, I can just use HID because according to Google it is faster for some reason (maybe because there is no direct connection? only updates of advertising data?)

BTW- examples for BLE devices are simply the Apple wireless keyboard that connects to my iPad, and works flowlessly in real time, same goes for the remote track pad.

RE: Faster respond for midi application ?

endnode — Sat, 10 Jun 2017 21:28:50 GMT

There are not many ways from iOS app side, what is possible to "force" or "trick" the protocol from the other side. If you have control over the other side of the link (e.g. if it is embedded device running your FW) you can try what I've suggested: pretend to be HID device, ask for lower connection interval after iOS connects with these 30ms. If this doesn't work another option is to let iOS advertise and connect from the other side. I hope these are at least three things you could try;) Good luck

RE: Faster respond for midi application ?

Lola — Sat, 10 Jun 2017 21:19:40 GMT

I know there are tones of midi controllers for iPhone, so there probably is some way. Not sure I understood your explanation on how to achieve faster speed on regular BLE, but I am using the iOS API for a long time, and other then few parameters I never saw something that can be related to speed or advertising interval(only in iBeacon). I will keep reading to understand your suggestion.

RE: Faster respond for midi application ?

endnode — Sat, 10 Jun 2017 21:13:45 GMT

That's not true, you can use GAP Broadcaster/Peripheral API since certain iOS version so you can do the opposite scenario. To the MIDI: is there any "solution" working with iOS which has lower latency then 30ms? I guess you can use that trick with HID device service and piggy back on lower connection interval (to go below 15ms) or completely reverse the flow and go even to theoretical minimum of 7.5ms. It should be pretty easy to reverse engineer: purchase or borrow the device you like and sniff with nRF51 DK sniffer the protocol. You will see connection interval used, what GATT features it uses etc.

RE: Faster respond for midi application ?

Lola — Sat, 10 Jun 2017 21:08:48 GMT

iOS do not give you any access to the stack(intervals etc) , you can just be central , register to characteristic and get notified, thats it, and that's what I do right now. It's fast enough for remote control, but not to play music. I wonder how other BLE midi controllers works, and how midi solves that.

RE: Faster respond for midi application ?

Lola — Sat, 10 Jun 2017 21:06:31 GMT

I did not understand a word from your last note :) Anyway, I think I am at the maximum, I use a regular uart example to send a single letter every time I push a button, and it's not fast enough .

I still wonder how midi solves that ( your link says it's 2.7x more faster )

RE: Faster respond for midi application ?

endnode — Sat, 10 Jun 2017 21:06:30 GMT

I assume iOS device is GAP Central aka master so it selects connection interval. There is a method to ask for better parameters but it has limited effect (most of mobile devices follow, some ignore it and some will disconnect in reaction). You could try to reverse the flow and let iOS device to Advertise (= GAP Peripheral) while embedded device can be GAP Central. Then you should be able to go below 30ms with connection interval (I would not hope to go down to 7.5ms which is limit by BT SIG Core specification but you could achieve 15ms).

RE: Faster respond for midi application ?

endnode — Sat, 10 Jun 2017 21:03:19 GMT

Oh my bad, I'd never thought you use unreliable transfer media such as Advertisement for MIDI;) Sure, you can try to use 20ms adv. interval but you will be loosing packets, iOS scanning will keep up only if screen is woken up, device unlocked and your app on the foreground (and even then I would assume at least 1% loss over some longer time). If you really just advertise then you can easily blame ~100ms delay to simply slow transport of scanning events through the system (I'm not the mobile dev unfortunately to provide more experience). With connection-based link you should easily achieve "every connection interval" latency so delays up to 30ms but not more.

RE: Faster respond for midi application ?

Lola — Sat, 10 Jun 2017 20:57:30 GMT

Wait, so is connection interval matter ? I was thinking that it's about interval between advertising..

My intervals are :

#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(20, UNIT_1_25_MS)             /**< Minimum acceptable connection interval (20 ms), Connection interval uses 1.25 ms units. */
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(75, UNIT_1_25_MS)

RE: Faster respond for midi application ?

Lola — Sat, 10 Jun 2017 20:55:37 GMT

Thanks, I actually can't see any problem in firmware/mobile. I print on the firmware when I push the button, and I see in my eyes that it prints fast enough, then it should send via ble, and I print again on mobile right when I get it, but it will print a little bit later, and if I can see in my eyes the little delay that means it's much more then 30ms :) , I wonder if that is the limit here .

Regarding HID:

So if it's only about setting the right service, how do you send the relevant data on the nrf52 side ? in the exact same way via characteristic? if so, why would it be faster ?
Is there anyone who implemented it using iOS? I couldn't find.

RE: Faster respond for midi application ?

endnode — Sat, 10 Jun 2017 20:54:58 GMT

(2/2) There should be more all over the internet and this forum, I've found this useful article among first 10 Google search hits (it's focused on throughput but that is related to connection interval - or latency if you want- closely;).

RE: Faster respond for midi application ?

endnode — Sat, 10 Jun 2017 20:49:28 GMT

For the start if you are unclear what is really happening on the radio (= why you think you send data as fast as possible but they don't arrive sooner then ~100ms) then get BLE trace through some sniffer. Frontline (Teledyne) or similar pricier device is better but Nordic DK with sniffer software and Wireshark will usually do the job. Then you either will see that data are going optimally over BLE and problem is somewhere in the mobile API/APP (then you are done here and need to employ some mobile dev magic) or you will see that you are wasting some time on embedded side and then back to FW and rework/debug/optimize. To the HID profile on iOS that is managed by the system so simply presence of that Service UUID on GATT Server side shod be enough. And as side effect other services on that device might be able to leverage that short connection interval... (1/2)

RE: Faster respond for midi application ?

Lola — Sat, 10 Jun 2017 20:36:37 GMT

Thanks a lot, well so how are all the Bluetooth LE keyboards works? they do work on HID, but they still use the same exact Bluetooth technology, so did you mean that it's possible in another configuration? how is HID different in speed? it uses the exact same BLE protocols.

How all these midi bluetooth controllers works anyway ? (in iOS you have access to recieve HID midi?) btw - 30ms is great but I think I am pretty far from it right now, can't figure why .

RE: Faster respond for midi application ?

endnode — Sat, 10 Jun 2017 20:22:52 GMT

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).