Unable to transmit at 100Hz with nRF51822

RE: Unable to transmit at 100Hz with nRF51822

Rune Holmgren — Thu, 01 Mar 2018 18:05:54 GMT

Hi,

I suspect this has changed a between SoftDevice versions, but I suspect the event you should be looking for is of type "BLE_GATTS_EVT_WRITE". Check the switch statement in the function "ble_nus_on_ble_evt" and you can see how it is handled internally by the NUS module.

If memory serves BLE_EVT_TX_COMPLETE relates to L2CAP packets which is not how you are transmitting packets.

Best regards,
Rune Holmgren

RE: Unable to transmit at 100Hz with nRF51822

Abhishek Satish — Tue, 27 Feb 2018 18:25:54 GMT

Thanks for the reply! I'm actually doing an nRF51822 to nRF51822 connection. But I'll still try checking this out!

RE: Unable to transmit at 100Hz with nRF51822

Abhishek Satish — Tue, 27 Feb 2018 18:24:59 GMT

Hi there! Thanks for the reply. How do I listen to these packet sent events on NUS? I tried listening for the BLE_EVT_TX_COMPLETE and then sent a packet everytime that triggered. But it didn't work. It never really triggered. Any suggestions?

RE: Unable to transmit at 100Hz with nRF51822

Turbo J — Mon, 26 Feb 2018 16:49:38 GMT

I strongly recommend checking the actual numbers in connection events (connect / conn param update). Android, for example, uses a 15ms interval which would roughly fit your 60Hz.

RE: Unable to transmit at 100Hz with nRF51822

Rune Holmgren — Mon, 26 Feb 2018 16:05:03 GMT

Hi,

The nRF51822 is capable of running a BLE with an interval of 7.5ms. For some reason, your system is not running at this max frequency.

The first thing I would do to debug this is temporarily removing the code you have for queuing data and adding a short code snippet which queues a packet for sending every time a packet is sent (listen to SoftDevice events and queue packets). This is simply to make sure that there is constant data to send and then you should be able to see if the problem is in the configuration of the Bluetooth link or in the way your implementation give data to the SoftDevice.

Another solution which can be very effective to debug this is to run a sniffer like the nRF sniffer 2.0 beta and see what connection parameters the devices are actually using. I suspect that you are either sending about half your packets empty or that the connection parameters are wrong. Feel free to share a sniffer log with me if you need help analyzing it.

Best regards,
Rune Holmgren