Good approach for write/read caracteritics

[Anonymous]

Hello,

I use a PRoC in a project where it communicate with an uart to an other device (the main device).

The user use his phone to send commands and or parameters to the main device, and the phone app should be able to tell him that the orders have been correctly received by the main device.

So after a command, the PRoC receive the data, send it throught UART, the device make some action according to the received command and send an UART frame to confirm that it have take the command into account.

Where it's not clear it's how i should create characteristics.

Does i have to create many characterisitics for each parameters, or few big ones :

1)

Few larges characteristics, with a 20 bytes arrays, and each one contains many parameters (like 5-6 parameters)

The problem with that solution is, that if the user change one parameters on the phone the app phone have to read the entire caracteristics and then change only one parameter with a mask.

2) one parameter per characteritic, its very structured, but the problem is that we have a lots of parameters to read and lots information to read from the main device (like date of first entry into service, software version etc, lots of  large 32 or 64 bits long parameters). So with that solution, i need like at least 30 differents characteristics.

Other question, about the verification ( be sure that the data have been received by the main device).

Does i have to use :

1)

one characteritics  write and read per parameters ( or set of parameters) : the phone app send data to the caracteristic in the BLE device, but the handle is updated only when and if the confirmation is returned from the main device by an uart frame.

2)  2 characterisitics, one for the phone app to write the data and the other one to read the data (this second one is only writed by the main device with uart frame). The uart app suscribe from notification on the read characteritics

3) Just write the data in characteritics and assume that the data have been correctly delivered to the main device

What approches are best suited for our application ?

Thanks for you help.

[Anonymous · Accepted solution]

The separation of data into characteristics is entirely an application-base question on how structured you need it versus how compact you want the data stored/transmitted.

(Note: You can implement another characteristic that updates multiple characteristics separately from a single characteristic read/write if you want a combination of both functionalities. E.G. Char. A, Char. B, Writing to Char. C will update both Char. A and B)

For ensuring reliable data delivery and confirmation, try looking at the Reliable Write, Write, and Indicate functions for delivering data to and from the peripheral device ("main device"). (There is also a signed write, but that is a security feature, and not necessarily a handshake feature)

With using the reliable write, you can confirm the data was delivered reliably with a handshake response before updating the "handle" as you called it. This would discard any changes not confirmed with a handshake reply.

Let me know if you need more clarification or have more questions.

[Anonymous]

Tanks for your answer !

It's a litte more clear, but i'm still confused

For the separation of  data, i wonder what is the more "efficient" way to procced in a custom characteristic (in a custom service).

Because i don't see why i should use like 20 characteritics ( 1 set of parameters per characteristics), if i can just use one unique characteristic and switch the set of data with a page byte.

So for example 1 unique characteristic like : 0xP1 0xP2 0xSS 0xSS 0xSS 0xSS. With 0xP1, and 0xP2 the page selector, and the rest the set of parameters/data

So with that  organization/structure the gatt table size could be reduce to the minimum (but does it really matter ?)

And in the futur if there is a need of more characterisics i could just use a second service with a new service UUID and add the new things inside, and recognize old peripheral and new peripheral ( with the new functionnilties allowed by the new service) by recognize the new service UUID.

In all the exemple i see, most of time there is just a little set of value to transmit. But for my application it is a bit different plus i have to be sure of the correct delivery from smartphone to the end device.

Most of the time the smartphone  (central) command the peripheral ( very small data and latency have to be minimum)

But the smartphone is used for configuration too,so sometimes write and read lots of information too (larges set of  32 or 64 bits parameters).

For ensuring the data delivery,

With reliable write we can know that data was transmitted correctly to the ble, but if i have to recheck the "handle" after the handcheck (of uart transmission) is it still necessary ? But the problem if with this solution app have to manage the retries if errors in ble transmissions and then we don't use all the already existent stuff..

[Anonymous]

No worries:

The GATTDB database automatically stores and updates data that it communicates with the remote device over BLE; Thus, if you have a value that you store in the database, then the application running on the peripheral doesn't need to tell the database the value on every read request, as the database has it stores and automates the reply. Thus, if you have multiple characteristics, it simplifies the peripheral application to having data requested being automatically sent/replied to the central device. The paging method you describe would work for sending and receiving data, but would have slightly more latency for you needing to handle the data received and respond with the response explicitly in your peripheral firmware code (the GATT Database is built into the BLE stack, and thus is one layer less of latency from responses).

Plus, if you are adding new services on a new version, you can just directly add the new services with new names for each new one; For example: Version 1 has Name, Number, and Location characteristics. Version 2 then adds a Second_Number, Second_Location, Location_one_Times, Location_two_Times. Version 3 then adds Last_Name, Middle_Name, Email_Address

Etc. There isn't a large difference in how easy each method is to implement, as they are both similar complexity imo. I think the characteristics are nicely defined however, so it makes it easier for documentation on what is there, and what is going on.

Since all of the characteristics would be broken into different packets of data, then when you send them each one would be a small amount of data with low latency; There would just be more/longer communication for the setup exchanges. (Changing how you interact with the characteristics won't change this I'm pretty sure)

If you are planning on reading the characteristic after writing to it, then you might be able to just do a write response with no verification, knowing that you will verify it immediately afterwards when you read it.

Alternatively, if you are only reading it to verify it, then using the reliable write allows you to discard changed values if the writes fail to work, or don't get a response for one of them. (It holds all of the write changes as temporary until you confirm them at the end, where it finishes changing all the values). You are still going to need to handle the retry of writing the data at the application level, the only difference would be whether you add an extra read after each write, and where in the application code on the central device that you handle the retries; I would see write, read, retry being similar to write,confirm/retry with some less overhead on the reliable write(s) method.