How to send (simple) data from GATT client to server?

Question

I have a PCB which is using a TI Bluetooth LE chip (CC2541). I'm hoping to send some simple weather data from the client (e.g., phone) to the server (CC2541) infrequently (once a day/week). Will a custom profile need to be implemented for this? Could an established profile be modified to handle the data, e.g., the Proximity Profile but with larger attributes?

If every type of data needs a profile, it seems rather clumsy. What is the canonical approach to sending/handling simple data streams?

Thanks

• Andy aka: Is there an EE aspect to this question that I missed?
• John M.: I'm trying to implement the firmwares for both the client and the server, so I'm hoping to get a grasp of the handling of the data streams.

Answer 1

The right way to do it would be to use a custom service that you've created for your specific data, but if this is just for your personal use you could piggyback off an existing service (like what could be in an example project) and add whatever characteristics for the data as you see fit.

Another approach would be to emulate the classic Serial Port Profile (SPP), which basically acts as a virtual serial port between the two devices. So, you could imagine how this could work with simple ASCII transmission of the weather data. There are some examples of this on the web if you search "BLE SPP". Bluegiga (https://bluegiga.zendesk.com/attachments/token/rx8se3yhwe3tlnh/?name=BLE_Application_Note_SPP_over_BLE.pdf) and other BLE modules have implemented this over the Generic Attribute Profile (GATT).

Link to SPP: https://developer.bluetooth.org/TechnologyOverview/Pages/SPP.aspx

Although, I think it would be more efficient to create a custom service for the weather data, because you might want to read or write different pieces at different times and it would be easier to manage the data. You could have a characteristic on the service for each piece of data you want (e.g. temperature, wind speed, wind direction, humidity, etc.) or you could create multiple services that represent different types of weather data (e.g. a wind service that has speed and direction characteristics, and a temperature service that has current, min, and max characteristics, etc.).

• John M.: Thanks. You mentioned specifically "for personal use". Why piggybacking is appropriate only for personal use? Is the "proper" approach to actually give it both a custom profile and a custom service?
• jose.angel.jimenez: Serial Port Profile (SPP) is defined in the Bluetooth Classic specification. There is no such thing in Bluetooth Low Energy (BLE). Under BLE all properties/characteristics (exchanged data) is handled at the GAT/GATT level. However, you may emulate a SSP on your own.
• DigitalNinja: Jose is correct that SPP is not a part of GATT. I've updated my answer to reflect this.
• DigitalNinja: I mentioned personal use because all of the predefined services adopted by Bluetooth SIG should only be used for that purpose. For example, I used an example project that used the heart rate service, I added characteristics and sent data that had nothing to do with a heart rate sensor until I was comfortable with the process and had everything working. I then just changed it to be my own custom service. Otherwise, some device or running app could have seen the heart rate service advertisement and thought it was a heart rate sensor.

Answer 2

If there is no public service for weather data, then create a private (custom) service. That's the canonical approach. That's why BLE has got private services.

[ I'm in a similar predicament as the O.P. I'm adding BLE to an industrial pump. Obviously, there is no public service defined for a pump. ]

• John M.: I see. But is it a custom service or a custom profile that's needed?
• Nick Alexeev: Custom service should be sufficient. Client can discover a service without a profile. I've tested that with Android 4.3 .
• John M.: Oh right. I didn't know profiles were optional.