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? 

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

[ovrebekk]

Hi Kevin

Please find my example here:
https://github.com/NordicPlayground/nrf52-ble-app-uart-relay

Give it a go and see how it works. 

I tried to pull the peripheral/server and central/client parts of the examples into separate files to avoid making the main file too cluttered, and implemented a simple relaying mechanism to pass data from one link to the other. 

This is controlled from main.c and can be changed if you like. 

Best regards
Torbjørn

[Kevin Kachikian]

You absolutely ROCK Torbjørn. Tusen takk! That little sample will likely save me countless hours of unwinding the, IMHO, convoluted codebase Nordic provides for these amazing BLE parts.

If I ever make it to Norway, I owe you a lunch.

Take care,

Kevin

[Kevin Kachikian]

This might just be dumb user error on my part but when I try to connect to nRF Toolbox's UART, app_nus_server.c crashes on line 292 with a Busy Error: 

 app: ERROR 17 [NRF_ERROR_BUSY] at line 292, PC is 0x0003014D in '...rt-relay-master/app_nus_server.c' 

It seems to be trying to change some aspect of the PHY. Perhaps some incompatibility with the iOS app itself? Thoughts?

I am running this on a Taiyo Yuden nRD52832 board using S132 on SES but I don't think that would matter.

[ovrebekk]

Hi Kevin

Which iOS version and phone are you using?

Did you have a ble_app_uart device connected to the relay when the error occured?

I just tested the nRF Toolbox app on an iPhone 7 running iOS 12.4, and didn't see this issue. 

Do you have an nRF52DK or nRF52840DK to test with for comparison?

Best regards
Torbjørn

[Kevin Kachikian]

Hi T. 

I’m running the latest iOS on an iPhone XS Max - v13.3. There was no 3rd device connected. I just launched the BLE example from SES running it on my Taiyo Yuden board then ran nRF Toolbox on the phone. When I connect from the UART tool to the BLE board, it connects then pops up with the error. Unfortunately I don’t have any other dev boards other than ones from Taiyo. The exact message sequence is:

 app_timer: RTC: initialized.
 app: BLE UART central example started.
 app: Connecting to target C2A4069DD176
 app: Peripheral connected
 app: ATT MTU exchange completed.
 app: Ble NUS max data length set to 0xB6(182)
 app: ERROR 17 [NRF_ERROR_BUSY] at line 292, PC is 0x0003014D in '...rt-relay-master/app_nus_server.c' 

Any thoughts as to what this error is trying to indicate?

Also, unrelated: when I run the UART project on two different Taiyo boards, shouldn't they auto connect? Right now they don’t auto connect when running the sample on 2 boards.

Thanks, Kevin

[Kevin Kachikian]

Any thoughts about the BUSY error? Thanks.