• State Verified Answer
  • Replies 3 replies
  • Subscribers 72 subscribers
  • Views 850 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 239486
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE throughput to Android central quick start

yf13

Just got my first nRF52DK (PCA10040) device today and the blinky sample simply works.

Since my ultimate purpose is to use it collect data from SPI then stream it to Android devices via BLE notifications, as a starting point I am wondering if I can quickly use an nRF52 sample to send notifications to an Android app in one way manner? If yes, which nRF52 sample should I use? I checked the ble_app_att_mtu_thoughput sample but found it seems needing two nRF devices to run (but I don't have extra nRF devices yet and I am more interested to know the result with Android devices).

I am wondering if someone has similar issue and already found an easy way to start with?

Parents
  • +1

    Hello,

    ble_app_uart_TP.zip

    I wrote this example once for SDK14.1.0. It prints the throughput in the log. Connect to your phone with nRF Connect, and enable notifications on the TX Characteristic, and the nRF should print the throughpt every second or so. 

    If you want to use a later SDK, you can look at this one for inspiration, and port it to SDK16.

    Best regards,

    Edvin

  • 0 in reply to Edvin

    Thank you !

    It seems that this nRF program will show the throughput at nRF sender side and it uses NUS for sending in a loop and will quit with any error. 

    I feel that using NUS might be simpler than using a custom GATTS service --- is this right?  Will NUS add any overhead to the one-way data streaming problem? 

    regards,

    yf13

  • +1 in reply to yf13

    Hello,

     

    yf13 said:
    It seems that this nRF program will show the throughput at nRF sender side and it uses NUS for sending in a loop and will quit with any error. 

     Yes. It uses NUS, and will send as long as there is free space in the queue for the softdevice. When it returns NRF_ERROR_RESOURCES, it means that it can't queue any more packets, and it will wait until the next TX complete event and try to queue more packets. 

    NUS is a custom service. It will not add any more overhead to the data stream than using any other service. I don't know if you noticed, but it should also print out what MTU size you get when you connect with your phone. This will typically vary from phone to phone. It also takes some time to change from 1MBPS to 2MBPS after the connected event. 

    Best regards,

    Edvin

Reply
  • +1 in reply to yf13

    Hello,

     

    yf13 said:
    It seems that this nRF program will show the throughput at nRF sender side and it uses NUS for sending in a loop and will quit with any error. 

     Yes. It uses NUS, and will send as long as there is free space in the queue for the softdevice. When it returns NRF_ERROR_RESOURCES, it means that it can't queue any more packets, and it will wait until the next TX complete event and try to queue more packets. 

    NUS is a custom service. It will not add any more overhead to the data stream than using any other service. I don't know if you noticed, but it should also print out what MTU size you get when you connect with your phone. This will typically vary from phone to phone. It also takes some time to change from 1MBPS to 2MBPS after the connected event. 

    Best regards,

    Edvin

Children
No Data
Related
Terms of service