Is my understanding of BLE model wrong?

RE: Is my understanding of BLE model wrong?

Bill Siever — Thu, 22 Sep 2016 22:58:37 GMT

No, that's not at all what I meant. I was assuming you when you meant "struct" you meant a C struct (record). You can not directly use an arbitrary C struct for a service. You can use the concept of a struct and convert it into a service programmatically. For example, given this set of data elements:

struct RemoteControlCar {
   uint8 speed;  // I want this to be an unsigned 8-bit value that is readable & writeable
   uint8 steeringDirection // I want this to be an 8-signed value that is readable & writeable
   bool bumpSensor;  // This indicates the bump sensor has hit something.  It should be readable & notifiable.
};

You can use code to create a service with three characteristics that match this sort of functionality. You do this by passing in C-structs that are used to specify the data sizes, permissions, and where the actual backing data is stored.

RE: Is my understanding of BLE model wrong?

Erik — Thu, 22 Sep 2016 22:43:58 GMT

Thank you for your very informative reply, on point 3, am I to understand that Nord Semi provided a series of lego blocks, and the best thing you can do is to build something resembles best the picture in your mind, instead of EXACTLY the thing in your mind, because you can't make your own lego blocks? Isn't that kinda wasteful? I would hate to build a room Temp monitor based on a heart-rate monitor services, I could be wrong though, since the function of the two may be virtually the same.

RE: Is my understanding of BLE model wrong?

Bill Siever — Wed, 21 Sep 2016 23:56:09 GMT

BLE's GATT Services/Characteristics tend to have protocols that are comparable to those often used by Objects.
GATT is a layer of the BLE network stack. If you are just using the GATT services all the lower level details are hidden from you. Nordic's Softdevice architecture (the SXXX stuff) helps hide most of these lower level details from the application developer. You DO have to decide on the specific format yourself. So you have to worry about the kind of data, but not the low level details of how it is sent.
The way a service (or profile) is constructed depends on the specific platform. Nordic's APIs use structs to pass information. If you are designing a specific service you have to use their API to construct the service. You can't just construct your own arbitrary struct and have it automatically converted to a service. The conversion is somewhat mechanical, so tools could do this --- I believe Nordic's plugin for Bluetooth Developer Studio would be pretty close to this. Different embedded platforms take different approaches. In my experience it's usually a little easier to construct services on Mobile/Desktop platforms than embedded ones because of the added power of the platform (less severe memory constraints can allow for more freedom).
Your "server" would have to provide a service. Assuming you're using a Nordic device: Ideally the server would write updated values to the characteristic periodically so the data would actually change. The client could poll for it, but that's a poor use of services. It would be better if the characteristic supported Notifications or Indications, which would allow the server to "push" updates to the client when they occurred. Using Nordic's API you do have to use "sd_ble_gatts_hvx()" to push the update. Other platforms may automatically push updates when characteristic data is updated.