Community news, upcoming events and general discussions
Threads: 36 Posts: 88
Get technical support from the community
Threads: 1416 Posts: 7565
Threads: 18 Posts: 64
Tell us how to make XDK better!
Threads: 36 Posts: 119
Share and discuss community member projects
Threads: 78 Posts: 343
after my BLE device is now running and active I am facing the next ,,problem'':
The plan is to let two XDKs communicate with one mobile phone. To ensure that the right devices are connected in the correct order, the idea was to config one XDK as bridge, getting data from the second device and send the gathered information to the handheld.
My question is: how to configure a xdk as BLE server and client?
My idea was to use the functions provided in BleAlpwDataExchange_Client.h and BleAlpwDataExchange_Server.h but howto?! And are the functions in there the ones that I need, when I am using specific Characteristics, like in DVX_demoVirtualXDK ?
Hi Markus, Glad to hear you're working on an interesting BLE setup. You are already pointing out to the correct libraries of the BLE Alpwise Data Exchange Service to achieve your use case. You will need the XDK1 as BLE server which is already covered in the BLE Guide provided for the XDK in both ways of communication as in receiving data from XDK2 and sending to APP. For more detailed information on implementing the BLE Alpwise Data Exchange Server see: SDK\xdk110\Libraries\BLEStack\Alpwise\Service\Data_Exchange_Service\Documentation\BLESW-ALPWDataExchange SERVER implementer's guide.pdf. The XDK2 needs to be configured as BLE client - this is not covered in the BLE guide but is also possible with the BLE Alpwise Data Exchange Service. In the BLE client of XDK2 you will need to discover the XDK1 BLE Server which will be awaiting a connection from XDK2. After connecting your XDK2 to the XDK1 you will need to discover the characteristics of the BLE Alpwise Data Exchange Service in order to exchange data in TX and RX direction. For more detailed information on implementing the BLE Alpwise Data Exchange Client see: SDK\xdk110\Libraries\BLEStack\Alpwise\Service\Data_Exchange_Service\Documentation\BLESW-ALPWDataExchange CLIENT implementer's guide.pdf. The functions described in the BLE Alpwise Data Exchange Service libraries are defined for exchanging data via the Alpwise Data Exchange Characteristics and their given UUIDs. In the same way, all the BLE services and characteristics in the demo DVX_demoVirtualXDK are accessible by their UUIDs, so you could change the services and characteristics you are searching for after connecting to the XDK1 in your application. Kind regards, Manuel
thanks for your advice I think this works for me (by now i've not tested it, first there are other problems to solve).
In my actual project I need at least two data streams (XDK - XDK and XDK - mobile device (two streams here)) via BLE, but with the standard Alpwise config there is only one stream in each direction. The alpwise documentation did not help me in this direction, so is it possible to define own characteristics via alpwise? I've already tried a solution among the virtualXDK demo but there are few problems occuring, e.g. the discovering services service gets stuck (XDK side) and the connection interrupts.
Thanks so far
Hi Markus, I am glad to hear about your progress. As you have already guessed it the complexity of your use case lies in the two BLE connections that need to be established in the one XDK2 that acts as bridge between another XDK1 and an App. The Alpwise Data Exchange Service only offers the given RX and TX data characteristics as you can see in the BLE guide or in the Alpwise documentation, see chapter 4 in: SDK\xdk110\Libraries\BLEStack\Alpwise\Documentation\BLESW-ALPWDataExchange_Service_specification.pdf. When talking about Alpwise as the BLE SDK it offers a great variety of official Bluetooth SIG profiles/services/characteristics (e.g. Heart Rate Profile) and ALPWISE proprietary profiles/services/characteristics (e.g. ALPWISE Data Exchange Service) as described for example in SDK\xdk110\Libraries\BLEStack\Alpwise\Documentation\AN_BLE008_-_ALPWISE_i-BLE_users_guide.pdf. Furthermore you can even define your application specific services/characteristics as described in SDK\xdk110\Libraries\BLEStack\Alpwise\Documentation\AN_BLE005_-_Using_ALPWISE_SDK_and_customer_specific_services.pdf. However, the problem you are facing might be not on the level of characteristics but rather on the level of establishing multiple active BLE connections in one single XDK simultaneously. Since this use case is a very new (and interesting) one for us as well, I will further investigate on this topic in the next couple of days and provide an update to you around the beginning of next week. Kind regards, Manuel
thanks for your answer. My idea was to set the bridge XDK (let's call it XDK1) as a server and a client.
Server: Communication XDK - Handheld
Client: Communication XDK - XDK
So each XDK has to manage one connection, the activity should be kept up by the client, as far as i understand BLE stuff. Hit me, if I'm wrong (-;
The characteristics problem can be solved by segmenting a string, values separated by a defined separator. That's fine so far, my message will by now not exceed the 20char limit.
Thanks for your efford so far,
Hi Markus, your ideas for server and client are correct but the problem with this bridging solution lies deeper in the connection layer. Nevertheless I would first like to know: why do you want to configure the XDK1 as a BLE bridge? Is it because you need a higher range between the Handheld and the XDK2? Or is there any other reason? Secondly we need to distinguish two layers in BLE communication which are theoretically independent from another:
Of course practically speaken usually the GAP central device takes up the GATT client role (e.g. smartphone) and the GAP peripheral device acts as the GATT server (e.g. BLE beacon) but that is not defined as a strict rule in the BLE specification. Let's look at two scenarios involving your setup with a handheld, one bridging XDK "XDK1" and another XDK "XDK2" providing data for example. In Scenario 1 you could configure on the layer of connection link / GAP roles the handheld as a central device, the XDK1 as a peripheral device and the XDK2 as a central device: Each central device will now try to connect an advertising peripheral device (-> XDK1). The connection attempt from the handheld will lead to the XDK1, as a regular peripheral is supposed to act, stopping the advertising as soon as connection request is received so that a connection with the handheld can be established. This will leave the XDK2 searching for a XDK1 device that is not advertising anymore and hence not being able to be discovered since it is already in an established connection with the handheld. In Scenario 2 you could configure on the layer of connection link / GAP roles the handheld as a peripheral device, the XDK1 as a central device and the XDK2 as a peripheral device: Since a BLE central device can connect to multiple peripheral devices your XDK1 needs to connect to the advertising handheld in peripheral role and afterwards to the advertising XDK2 in peripheral role. After the connections are established both GAP peripheral devices can access the data from the GATT server in the XDK1 using their GATT clients in RX (read characteristics, enable notifications for characteristics) / TX direction (write with/without response). Please keep me updated on your progress with scenario 2 and feel free to ask follow-up questions. Best regards, Manuel