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

[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!