Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE_CONN_BW_HIGH / Packets per Connection clarification

Can someone please clarify a few things!

I'm trying to get high bandwidth on some to and from phone transfers. I have control and data gatt boxes, control has the connection request and meta data for the transfer, data holds packet after packet of data.

1. If my MTU for this connection is 20 bytes, and my control gatt maps to a 20 byte array, no issues. What happens if the MTU for this session is 243 bytes? Does the softdevice only "route" 20 bytes because that's the GATT size for that characteristic? Does it write 20 bytes where it should can keep going into other RAM like it shouldn't? In order to fix this do I need to make sure that despite not using more than 20 bytes my GATT is sized for a 243 byte MTU?

2. My device is the peripheral and server. I want as many packets per interval as possible. For device to phone sending, I can put the data in the physical array, and the phone will be notified. But I can't do anything else in this connection event right? I can't actually "send" data, so what is happening with the nrf softdevice and it's tx buffer?

3. Same device is peripheral and server scenario. If I want data as fast as the phone can send it, can it write to this GATT more than once per interval? If from the phone I use WriteWithoutResponse twice in the same packet, is there a chance I'll miss this in on my device? For example, if the phone sends two packets in the same interval they must load up into a softdevice rx queue right? If they don't it seems like the softdevice will update the interal array, give me an event, and immediately start replacing that data with the second incoming packet. Am I just supposed to grab it in time? Will the softdevice re-trigger the event after I check that first transfer?

Basically I just don't even remotely get how multiple packets per interval/event are supposed to work. I get the mbps and connection interval. I see everyone discussing bandwidth in terms of packets per event, but on the same GATT it makes no sense to me, but I have never seen anyone talking about cyclic queues of GATT data in order to reassemble long objects from multiple GATT locations.

I'm looking over the Nordic github code for sending video over BLE as example, but other than an RX/TX and control box and the UART service, I don't see much explanation.

Parents
  • Hello,

    1)

    If your MTU is 243 bytes, and you don't use DLE (data length extension), then you can queue several packets of 20 Bytes, calling sd_ble_gatts_hvx() until it no longer returns NRF_SUCCESS. It will return NRF_ERROR_RESOURCES when the queue is full. This is explained in ble_gatts.h (line 632).

    If you enable DLE, you can also send packets larger than 20 bytes.

     

    2)

    As I mentioned in 1), you can queue several packets in the softdevice using sd_ble_gatts_hvx(). All the packets that you queue which returns NRF_SUCCESS will be sent to the central/phone/client. When it is queued, and it returns NRF_SUCCESS, the data is stored in the softdevice, and you can can consider it sent. If for some reason a packet is lost, the softdevice will re-transmit it for you.

     

    3)

    You will get one event pr. packet that is received by the softdevice. If two packs are received, one is stored in a buffer in the softdevice while you handle the first one.

     

    If you are interrested, I have a project that is sending a lot of dummy data. You can connect with either a phone or another nRF. It uses DLE (if it is accepted by the central). I recommend using DLE if possible, as it reduces the header/payload ratio, which will increase the payload throughput rate.

     

    Best regards,

    Edvin

Reply
  • Hello,

    1)

    If your MTU is 243 bytes, and you don't use DLE (data length extension), then you can queue several packets of 20 Bytes, calling sd_ble_gatts_hvx() until it no longer returns NRF_SUCCESS. It will return NRF_ERROR_RESOURCES when the queue is full. This is explained in ble_gatts.h (line 632).

    If you enable DLE, you can also send packets larger than 20 bytes.

     

    2)

    As I mentioned in 1), you can queue several packets in the softdevice using sd_ble_gatts_hvx(). All the packets that you queue which returns NRF_SUCCESS will be sent to the central/phone/client. When it is queued, and it returns NRF_SUCCESS, the data is stored in the softdevice, and you can can consider it sent. If for some reason a packet is lost, the softdevice will re-transmit it for you.

     

    3)

    You will get one event pr. packet that is received by the softdevice. If two packs are received, one is stored in a buffer in the softdevice while you handle the first one.

     

    If you are interrested, I have a project that is sending a lot of dummy data. You can connect with either a phone or another nRF. It uses DLE (if it is accepted by the central). I recommend using DLE if possible, as it reduces the header/payload ratio, which will increase the payload throughput rate.

     

    Best regards,

    Edvin

Children
No Data
Related