Is my understanding of BLE model wrong?

[Erik]

Through a few days of studying, I now decided that: (please correct any statements I said wrong below)

• The BLE is more friendly to object oriented programming

• The BLE focus more on OOP concepts like Objects and Events, instead of transmission protocols and formats themselves. Once you correctly initiated OBJECTS (e.g. the profile object) on both parties of comm., you do not have to worry to much about what kind of data they send and how they send them. The S1x0 devices take care of the rest once properly configurated.

• You can use struct or class (in C++ or JAVA) to easily compose a profile, with all the proper services you need.

• Say you are a server measuring temperature of a room. You do not need to take the initiative to send a data once you detect a change, all you have to ensure is that this change is corresponded to certain characteristics, and the client device will poll all these characteristics periodically, and will eventually get the changed data.

[Bill Siever]

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

[Erik]

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.

[Bill Siever]

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.