BLE is meant to be connectionless, so you should be connect/disconnecting whenever you have nothing new to do, as leaving the link active wastes power, adds RF noise, and prevents other devices using them. That said, you can turn off the supervision timeout, and change it to be higher if you still want it to disconnect eventually.
My advice: Connect, send the MIDI data, then disconnect. Repeat for each, or only stay connected for a maximum time, and then reconnect on new data.
Thank you "e.pratt_1639216" for answering me, I totally agree with you, so taking your point I must ask, how can I connect and disconnect automatically the BLE link?, because this app is meant to have some push buttons (each one of them sends one MIDI data), so if I want to connect, send the MIDI data, disconnect and repeat that loop for each time i want to a play a note, how can I do it? because connecting manually; where I have to search for available BLE devices, see their characteristics, and so on, this will make my app not that practical. Having said that, another question would be, how can I increase the maximum connection time?, let's say I want it to keep the LE link active for at least 1 or 2 min for example.
As far as the connectionless implementation: Once you have the BD address of the device you want to connect with to "update", all you need to call is GapcConnect(BDAddress), then send notification, then disconnect(). If you got really clever, you could set it up to do the data updates/connections asynchronously so that it is always reconnecting and sending data whenever new data is available, and then disconnecting after it doesn't receive new data from some x amount of time.
Under the BLE component, Gap Settings, Central Role->Connection Parameters, Connection Supervision should allow you to change the timeout value; Unfortunately, I think it only goes up to 65535 milliseconds, which is just over a minute.
That function is really useful and seems to be really to implement, but I noticed the function "cyBle_GapcConnectDevice (BD address) " must be used by the Client device which in this app would be the Iphone, the PSoC 4 BLE that I'm using is working as a peripheral. I looked for some projects examples and I found one called BLE proximity sensor and when I tested it maintained the connection without any disconnection message coming from the peripheral. As far as I know the LE link goes down when there is no other event to handle, that said, in my app I have in the "while (1)" loop the process event function and some interruptions for the push buttons, so is there another event or something related that I need to call in order avoid the disconnection?, in addition to this If the callback function always gives the same event (e.g., "CYBLE_EVT_GATT_CONNECT_IND" when the connection is successfully established), so it doesn't change the event value and therefore it turns off the BLE connection ,do you think this might be the issue?
I would clarify the "connectionless" statement by noting that BLE supports connectionless design cases, but not that it is necessarily meant to be connectionless. For point-to-point links such as what you have in a MIDI device, or a mouse or keyboard, or remote I/O control, or many other applications, maintaining an active connection is preferable. You can still achieve very low power consumption as long as you update the slave/peripheral connection parameters to have some combination of a long connection interval or non-zero slave latency.
For a MIDI device, I would recommend maintaining the connection and using a short connection interval with long supervision timeout and slave latency of perhaps 4 or 5 to start with. MIDI requires fairly low latency to avoid a perceptible lag in instrument response, and continuously closing and re-opening connections will necessarily increase the latency.
Note that you will have to trigger a connection parameter update from the peripheral side if the client device is iOS, since the iOS CoreBluetooth APIs do not provide any way to customize the connection parameters either before or after establishing the connection.
Hello "jrow" and thank you very much for your response, yes I totally get that, and I wasn't sure about what value I should fill in the "Gap settings / Peripheral preferred connection parameters" but i did saw some equations and try to set some values (according to the constraints), but they didn't solve my problem. Talking about the update of the connection parameters from the peripheral, I did some research and found that the request is being sent by the peripheral with this function "CyBle_L2capLeConnectionParamUpdateRequest(...)" that takes as parameters the peer device's BD handle and the pointer to the connection parameter structure. In addition what confuses me is that it need the approval from the Peer device (Iphone) so my question is when I implement this function and generates the event that is received after the Iphone has received the update request, will I have to accept that request everytime I send a note in the Iphone side? Can use this function and do not accept the update request in the Iphone and still work?
As Jrow said, I was wrong about the connectionless statement :(
I guess I've been too caught up in the low-power application I've been working on.
I would suspect the Iphone only needs to accept the update request upon changing the parameters for the connection, thus, you would only need to change it once after connecting, and then it would stay with the same parameters while connected.
Ok I get it now, something that I did and worked was that I turn off and turn on the Bluetooth in the Iphone, it was fine the first two shots but now It doesn't seem to work. I thought as the Iphone does not updates the value if I just clean its let's say buffer with the data from my PSoC 4 BLE device, It would be enough with just turn off and on the Bluetooth in it.
After some googling, I believe I might have found some useful information, let me know if it helps you:
"3.6 Connection Parameters The accessory is responsible for the connection parameters used for the Low Energy connection. The accessory should request connection parameters appropriate for its use case by sending an L2CAP Connection Parameter Update Request at the appropriate time. See the Bluetooth 4.0 specification, Volume 3, Part A, Section 4.20 for details. The connection parameter request may be rejected if it does not comply with all of these rules:
● Interval Max * (Slave Latency + 1) ≤ 2 seconds
● Interval Min ≥ 20 ms
● Interval Min + 20 ms ≤ Interval Max Slave Latency ≤ 4
● connSupervisionTimeout ≤ 6 seconds
● Interval Max * (Slave Latency + 1) * 3 < connSupervisionTimeout
If Bluetooth Low Energy HID is one of the connected services of an accessory, connection interval down to 11.25 ms may be accepted by the Apple product. The Apple product will not read or use the parameters in the Peripheral Preferred Connection Parameters characteristic. See the Bluetooth 4.0 specification, Volume 3, Part C, Section 12.5"
The link to a forum talking about interfacing bluetooth devices with iphones here: https://developer.apple.com/library/content/qa/qa1931/_index.html
The link to the documentation from apple about the requirements for bluetooth peripherals is here: https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf
1 of 1 people found this helpful
Thanks a lot both of you, I already saw the links you posted and they talked about other important consideration, but I wanted to tell you is that I manage to solve the problem, and It was that the UUID from the characteristic as well as from the respective descriptor wasn't the same size (i.e., UUID of the characteristic is a value of 128-bit and the descriptor was 16-bit), I found one guy that commented that had the same issue I was having today, so he said that when he changed the size of the descriptor UUID the problem was already solved, so what I did was I copy the same UUID from the characteristic and placed it into the field of the UUID from the respective descriptor; however, I changed the last number (the least significant nibble) to the next hexadecimal number, and that is how the problem was solved.