Quickest path to BLE data exchange...

[Kevin Kachikian]

Hi,

Given the too many examples in the nRF5 SDK that are provided to implement BLE and the unclear documentation on how to best proceed, what would you say is the quickest path to begin development of a bidirectional data transmission in a BLE embedded device? I am seeking to transmit small chunks of proprietary data (maybe 100 bytes/sec) from an embedded device and have it received by another embedded device in close proximity then send the data from the second embedded device on to an iPhone also very close by. I need bidirectional data from iPhone to second device to first device as well, so a two way data stream. Make sense?

I am using v16 (latest I believe) of the nRF5 SDK on an nRF52832.

Thanks,

Kevin

[ovrebekk]

Hi Kevin

I would say the ble_app_uart example is the best place to start if you are looking for a simple two directional proprietary BLE example. 

It sets up a simple service (NUS) with one characteristic for TX and one for RX, allowing you to send strings of variable length from the client to the server and vice versa. 

The ble_app_uart example also integrates nicely with our Android and iOS phone apps, allowing you to test the phone connectivity without having to develop the app yourself. 

You can read more about the example here. 

Best regards
Torbjørn

[Kevin Kachikian]

Thanks Torbjørn. Can you tell me the utility and difference between the BLE Peripheral/UART/Serial Port Emulation over BLE that you recommend and BLE Central/Nordic UART Service Client? 

[Kevin Kachikian]

Thanks Darren. Actually Device 1 will transmit data to Device 2. Device 2 will receive Device 1's data and do some calculations and transmit to the iPhone. However we need bidirectional data channels open between all devices, ideally. So Device 1 will Tx and Rx to 2 and Device 2 will Tx and Rx to Device 1. And Device 2 will also Tx and Rx to the iPhone. In this situation, what would you say are good starting projects for Device 1 and Device 2?

[Kevin Kachikian]

Hi Torbjørn. It occurs to me that the starting projects I need are: a two device BLE communications system where a device (either device) can say "I have some data for you" and can push their data to the other device (likely using an interrupt on the Rx end). At the same time, each device can also send a "pull" data request to the other device when it has some data ready for the other end (again probably in an interrupt notification situation). This would all be irrespective of who is the central and who is the peripheral - either can be I think, however one device also needs bidirectional communications with the iPhone sending and receiving data as needed.

IOW: Device A (or B) has some data for Device B (or A) and sends out a push notification. Device B (or A) responds "OK I'm listening" and starts receiving the data. Later on, Device A (or B) needs some data from Device B (or A) and sends out a "please fulfill data" request. Device B (or A) then sends out the requested data. In this situation I'm not sure who is the central and who is the peripheral and it might not matter, however one of the devices, say Device B needs to also be able to send and receive data to the iPhone app.

So I am looking for two good starting embedded projects for such communications setup. What would you recommend given all the sample apps?

Make sense? Thanks!

[ovrebekk]

Hi Kevin

It sounds to me like you need one device (B?) to be connected to both device A and the phone at the same time, while device A only needs to connect to device B. 

In this case device B will need to be both central and peripheral at the same time, acting as a central towards device A, and as a peripheral to the phone. 

The client/server relationship is actually independent of the central/peripheral relationship, but the most common configuration is to have the central be the client and the peripheral be the server, and when using the NUS service this is the configuration I would recommend. 

Then you are looking at a total system where you have a phone being the central/client towards device B. 

Device B is a peripheral/server towards the phone while also being a central/client towards device A. 

Device A is a peripheral/server towards device B. 

The phone would be able to use the standard apps, and device A could use the ble_app_uart example, while device B would have to use a combination of the ble_app_uart and ble_app_uart_c examples. 

You can send data whenever you want on both the client and server side of the link. 

The client would use write commands to send data, while the server would use notifications.

Best regards
Torbjørn

[Kevin Kachikian]

Excellent Torbjørn. Thank You. So on Device B I need to manually mix the relevant code from the ble_app_uart and ble_app_uart_c examples, right? Is there an existing code base that already does this so I don't have to reinvent the wheel, perhaps an example starting project inside of Nordic for the dual capability of Device B?

Thanks so much.

[ovrebekk]

Hi Kevin

Essentially you have to copy all the client specific code from the ble_app_uart_c example into the ble_app_uart examples, yes, or vice versa. 

You would also have to change the NRF_SDH_BLE_PERIPHERAL_LINK_COUNT, NRF_SDH_BLE_CENTRAL_LINK_COUNT and NRF_SDH_BLE_TOTAL_LINK_COUNT defines in sdk_config.h to allow for more links than what the examples support out of the box. 

There is no example out of the box showing how to do this unfortunately. 

The closest in the SDK would be the ble_app_hrs_rscs_relay example in the examples/ble_central_and_peripheral/experimental folder. 

This example essentially does the same thing, but uses different services. 

Best regards
Torbjørn

[Kevin Kachikian]

Thanks. I think the best approach would be to use the ble_app_hrs_rscs_relay example.

I'm a little surprised how non-turnkey the BLE codebase is for non standard services and characteristics. Ideally to make it easiest for new development, there should be a library of files that are easy to add new services and characteristics and have the corresponding data easy to access from app code as well. Given the Nordic samples, it is of course doable but requires much more time and work to understand the Nordic codebase when this part should be pretty simple and plug and play.

Will I find it to be a challenge to add more characteristics or services to the ble_app_hrs_rscs_relay sample?

Also, what sample code on the iOS app side would be a good place to start if using the ble_app_hrs_rscs_relay sample? Is there anything available for the relay info. I don't see anything in nRF Toolbox.

Thanks again for the help.

[ovrebekk]

Hi Kevin

I agree the service setup is not very straight forward. Ideally there would be some tool or script to simplify the process, like the Bluetooth SIG tried with the Bluetooth Developer Studio, but that tool never saw a lot of popularity and was eventually discontinued. 

The main challenge of using the ble_app_hrs_rscs_relay sample is that you need to change the services to use a proprietary 128-bit UUID, rather than a 16-bit short one, but you can obviously have a look at the NUS files to see how this is done. 

Also, there is a lot of hrs/rscs related code in these services that you probably don't care about in a proprietary example. 

I should be able to put together a small example showing how to merge ble_app_uart and ble_app_uart_c into one, giving you an easier starting point, but I can't promise anything until some time next week. 

Best regards
Torbjørn

[Kevin Kachikian]

Hi Torbjørn. A generic data sample code example would help a lot to at least get started. Thank You so much!

I have the relay sample working relaying heart rate data from one device to the relay in the middle then on to an iPhone app.

Should you modify the ble_app_hrs_rscs_relay sample instead of trying to combine the two UART samples - would that be easier? Or, in fact, is that not appropriate because I need bidirectional data flow from all 3 devices (BLE Device A, BLE Device B, iPhone app)? Maybe combining the two UART code bases is more appropriate as you mention. Not sure...

Tusen takk!

[ovrebekk]

Hi Kevin

The UART example is very popular because it shows how to implement a simple proprietary profile that can be easily expanded to cover a multitude of use cases. 

The HRS and RSCS services are standard services only meant to be used for those use cases specifically. 

In other words I think an example based on the UART service will be more valuable in the long run

Best regards
Torbjørn

[Kevin Kachikian]

Thank you Torbjørn. Yes, if you could get me started with a working merged ble_app_uart and ble_app_uart_c sample, that would be greatly appreciated.

Thanks!