How are frequent writeCharactristic() calls handled?

[sarkreth]

I'm working on an app that communicates the position of a quickly changing "slider" button (a single byte) over BLE. I haven't tested it yet, but I sense trouble depending on how writeCharacteristic() behaves at the interface to the actual Bluetooth stack implementation.

Bluetooth communications happen in regular intervals, but touch events fire as often as a new thing happens. What exactly happens if these events happen more frequently than the communications?

Do they get buffered? If so, how does the data get written? Are there just a bunch of overwrites? What I'm mainly afraid of is only one value being written for every communication, which would cause fast changes in the slider's position to be communicated and read in the peripheral device too slowly.

[Fredrik]

The cordova-ble plugin queues up all writes. The next pending write is executed when the remote device's response arrives. Queing more writes over time than the system can process will cause increasingly old data to be written to the remote, and eventually cause an out-of-memory crash.

I suggest you use the writeCharacteristic callback to keep track of pending writes, and write a new value only when the previous write is finished.

[sarkreth]

You may be on to something there, but I'm still a bit unclear on how to use the writeCharacteristic() success callback. Does wC() write the value to a buffer, then register the callback to be called when the value actually gets written, then return asynchronously? This would be perfect!

[Fredrik]

Does wC() return asynchronously, and register the callback to be called when the value actually gets written?

Yes.

It also depends a bit on the remote device. There are two types of characteristic write settings: with and without response. The remote decides which one must be used.

In the first case, the plugin waits for the remote to acknowledge the write, then calls the callback.

In the second case, the plugin calls the callback as soon as the data packet has been transmitted.

Even in the second case, the queing effect may appear, since each packet must wait for a transmission time slot, and those are separated by 7 to 30 milliseconds (iirc).

[sarkreth]

You just caused me to have an epiphany about Javascript, dude! Thanks!