• State Suggested Answer
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 62 subscribers
  • Views 1627 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 206914
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

getting max S132 connectivity fw throughput

gkovelman_tap

Hi,

I'm trying to transmit data at about 500kbps from custom nRF52 board (peripheral, s132 v5, SDK14.0) to a PCA10040 board with a connectivity FW (based on v3.0.1) connected to a PC and pc-ble-driver (central).

Currently, with the max throughput settings,

  • ATT MTU at 247,
  • PDU at 251,
  • tried conn interval at different settings (11.25, 15, 30, 45),
  • max event length at 320 (on both sides)
  • hvn_tx_queue_size (on peripheral side) at 20
  • transmitting 2 packets of 240 bytes in size every ~8ms

I can reach 40 KBps (320 kbps).

I keep getting NRF_ERROR_RESOURCES from sd_ble_gatts_hvx on the peripheral side.
I'm not sure where the bottleneck is or whether it's bad configuration.

Any known issues with the connectivity FW? Could this be feasible?

I'll appreciate the help.

  • 0 in reply to Bjørn Kvaale

    Thanks for the answer.

    Any suggestions on how to queue the message on the FW side?

  • 0

    Queue the messages? I would suggest that you start by just chucking them away! Work out the available throughput by just ignoring all the received data and only then start looking at how that data can be shifted off the PCA10040 board. The uart is very inefficient and the hardware handshake is upside down as I mention elsewhere so not useful without hardware mods. To really shift data off the board you need one or more 8MHz SPI channels or something similar; if you are using something like this start by commenting out the call and see how much throughput increases.

    I have a similar issue and just want to get the data to Wi-Fi; a Pi can give you an SPI connection, and it could even give you BLE direct if we could get it to work ..

    static void ble_nus_chars_received_uart_print(uint8_t * p_data, uint16_t data_len)

  • 0 in reply to hmolesworth

    Maybe there's just a quick fix to buffer multiple notifications on the nordic and then TXing them over UART as one large packet, reducing the handshake overhead.

    If the changes are more than that, it'd probably be smarter to use an android/iphone 7 device as the central since they support DLE.

Related