• State Verified Answer
  • Replies 4 replies
  • Subscribers 74 subscribers
  • Views 957 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 219923
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Few questions to understand BLE working better

SK

Hello all,

I am using nRF52832 IC, Segger ES as IDE, SDK 14.20 and SD v5.0


I have around 70 bytes of data to be sent to a smartphone. I am using nRFConnect app to check for the incoming data.
I had few questions to understand BLE working better.


1. I wanted to understand on how does the central (smartphone) know that complete 70 bytes has been sent? Is it somehow related to sn and nesn of data channel PDU?


2. How does CRC work here in data channel PDU? Is it that for each packet that will be made out of 70 bytes of data will have its own CRC? And it is validated on the central side with each packet reception? Is CRC internally calculated in the link layer somewhere because i did not see CRC16 library to be used anywhere in the source code.

3. How is incoming data from peripheral, if corrupted, reported on the central? Is there a notification or event to signify that?


Could you guys please point me to a link or a forum from where i can understand this better if this has already been discussed before? That will be a great help!
Apologies for being a noob here. Still trying to understand the nitty gritty of BLE working.

Thank you!

Parents
  • +1

    Q1 and Q2: Bluetooth 4.2 and 5.0 support payload lengths from 20 - 251 bytes. If the payload length is lower then the number of bytes that should be sent, then the data will be segmented and each packet will have its own CRC. If the payload length is larger or equal to the number of bytes that is to be sent, then all the data will fit and only one packet is sent.   Yes, the CRC is generated and verified in the Link Layer. 

    Q3: Bluetooth Low Energy has a reliable transport layer that will detect bit errors/corruption and request the data to be re-transmitted. Our protocol stacks (SOftDevices) will notify the application when valid data has been received or notify you if any timeout occurs etc. 

    Bjørn

  • 0 in reply to bjorn-spockeli

    Hi , 

    Thanks for your reply.

    For Q1 and Q2 reply: Do you mean that the 70 bytes will be packeted as one single payload and then sent over BLE? I had this notion that only 20 bytes per payload can be sent over. Thus meaning that there be will be 4 packets of 20,20,20 and 10 bytes respectively each of them having their own CRC. 

    This is what i got from BLE 4.2 spec which indicates PDU to be a max of 257 bytes

    But in BLE NUS code if i see, BLE_GATT_ATT_MTU_DEFAULT is defined as 23 bytes, which led to my question.

    For Q3: Could you let me know what kind of error or notification is generated from the SD so i can look into it further? Also, nRFConnect app, for example, on Android/iOS phones will not have the SD protocol stack in them or does it?. How does that work in checking bit errors/corruption? 

Reply
  • 0 in reply to bjorn-spockeli

    Hi , 

    Thanks for your reply.

    For Q1 and Q2 reply: Do you mean that the 70 bytes will be packeted as one single payload and then sent over BLE? I had this notion that only 20 bytes per payload can be sent over. Thus meaning that there be will be 4 packets of 20,20,20 and 10 bytes respectively each of them having their own CRC. 

    This is what i got from BLE 4.2 spec which indicates PDU to be a max of 257 bytes

    But in BLE NUS code if i see, BLE_GATT_ATT_MTU_DEFAULT is defined as 23 bytes, which led to my question.

    For Q3: Could you let me know what kind of error or notification is generated from the SD so i can look into it further? Also, nRFConnect app, for example, on Android/iOS phones will not have the SD protocol stack in them or does it?. How does that work in checking bit errors/corruption? 

Children
No Data
Related
Terms of service