pc-ble-driver 1.0 - maximum data throughput

RE: pc-ble-driver 1.0 - maximum data throughput

Eric Stutzenberger — Mon, 02 Oct 2017 18:09:04 GMT

Mike, are you able to add your upload your patch or post it on pastebin?

RE: pc-ble-driver 1.0 - maximum data throughput

Bjørn Inge — Mon, 07 Nov 2016 11:28:07 GMT

Hi, good to hear that patching the flow control worked out. Running without software handshaking is possible, with a little effort. It would require implementing an alternative variant of the transport in pc-ble-driver that is compatible with the non-hci uart transport of connectivity firmware.

RE: pc-ble-driver 1.0 - maximum data throughput

Mike — Mon, 07 Nov 2016 10:24:13 GMT

Hello, I've followed your hint and made patch for hardware flow control. Now it works with 1Mbps baud rate but I still wonder if it is possible to disclaim software handshaking?

RE: pc-ble-driver 1.0 - maximum data throughput

Bjørn Inge — Wed, 26 Oct 2016 06:49:07 GMT

Hi, this error message seems to be due to Boost not allowing this setting on the OS you are running. stackoverflow issue. One workaround could be to use the Boost native handles to get access to the underlying native serial port object of the OS. This would require modifying and recompiling pc-ble-driver (uart_boost.cpp).

RE: pc-ble-driver 1.0 - maximum data throughput

Mike — Tue, 25 Oct 2016 13:07:15 GMT

Ok, but If I changed SD_RPC_FLOW_CONTROLE_NONE to SD_RPC_FLOW_CONTROL_HARDWARE I get the following error:

terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >'

what():  set_option: Operation not supported

RE: pc-ble-driver 1.0 - maximum data throughput

Bjørn Inge — Fri, 21 Oct 2016 21:01:18 GMT

In this case (no jlink) you should probably keep flow control ensbled to avoid flooding the nrf5 chip. In our code we confugure flow control disabled, but this is because that is required to make JLink enable flow control. Confusing, I know. When in doubt, hook up a logic analyzer to the uart lines to see that flow control is being respected.

RE: pc-ble-driver 1.0 - maximum data throughput

Mike — Fri, 21 Oct 2016 12:06:49 GMT

The nRF51 is connected to the ARM application processor, similar to this on the RaspberryPi, where Linux is running. There is nothing between them. Hardware flow control is disabled.

RE: pc-ble-driver 1.0 - maximum data throughput

Bjørn Inge — Fri, 21 Oct 2016 11:48:50 GMT

To clarify, what is connected to the uart of the nRF51, meaning who is responsible for controlling the UART hardware flow control lines? The UART of the nRF51 has fewer buffers than the nRF52 and so is more vulnerable to slow response to the flow control lines. On our kits, the Segger JLink has been made to be sufficiently responsive. That may or may not be the case on custom cards.

RE: pc-ble-driver 1.0 - maximum data throughput

Mike — Fri, 21 Oct 2016 09:33:43 GMT

SD_RPC_FLOW_CONTROL_NONE is set.

I am running on Linux.

I have my own custom board with nRF51822QFAC. I connected it to an application processor directly through the UART. The same I do with the PCA10040 (but I recompiled connectivity firmware with changed UART pins to bypass SEGGER). So, the configuration is the same for both (the same main processor, application, UART, baud rate).

RE: pc-ble-driver 1.0 - maximum data throughput

Bjørn Inge — Fri, 21 Oct 2016 07:04:28 GMT

If you are not doing so already, set uart to use SD_RPC_FLOW_CONTROL_NONE (this to make auto flow control actually be enabled on jlink)
Are you running on Windows or macOS? What board are you running (pca10028, pca10031)?

RE: pc-ble-driver 1.0 - maximum data throughput

Mike — Fri, 21 Oct 2016 06:56:10 GMT

I' ve compiled the same connectivity firmware for nRF51 and nRF52 with baud 1Mbps and tested with the same application which use pc-ble-driver. So configuration in both cases was the same. The thing is that application works with the nRF52 at baud 1Mbps but doesn't with the nRF51. I have also made more tests with different baud rates using nRF51. It works only with baud 115200 and lower like 9600.

RE: pc-ble-driver 1.0 - maximum data throughput

Bjørn Inge — Fri, 21 Oct 2016 05:23:26 GMT

Hi, both nRF51 and nRF52 have been tested with 1Mbps. There are no provided connectivity firmware for 1Mbps so you have to modify the baud rate in connectivity project and recompile it.

RE: pc-ble-driver 1.0 - maximum data throughput

Mike — Wed, 19 Oct 2016 14:14:12 GMT

Hi again,

I tried to check it with higher UART baud rates but I it doesn't work with bauds higher than 115200. I always get NRF_ERROR_INTERNAL on sd_ble_enable... With baud 115200 works fine... Have you tested the nRF51 as ble_connectivity chip with bauds higher then 115200? Is there any limitation?

Edit:

I've also made tests with the nRF52 and there is no problem with baud 1Mbps (using this baud rate I am able to achieve around 90kbps throughput), so it seems to be problem specified to the nRF51. What it could be?

Unfortunately, I can not use nRF52 instead of nRF51 in my project...

RE: pc-ble-driver 1.0 - maximum data throughput

Bjørn Inge — Fri, 14 Oct 2016 13:21:26 GMT

Hi,
there are a couple of reasons why Master Control Panel runs faster than pc-ble-driver

MCP uses 1Mbps baud rate, pc-ble-driver connectivity hex is set to 115200
pc-ble-driver uses a software handshaking protocol over UART meaning it's a lot more afflicted by the latency added by JLink, MCP uses no handshaking

RE: pc-ble-driver 1.0 - maximum data throughput

Mike — Thu, 13 Oct 2016 16:19:32 GMT

Hi Bjørn,

thank you for the answer but I do not use a development kit. My central device is the nRF51 chip connected directly to a second processor via UART.

I do not think that the Segger chip is a bottleneck because I've also made some tests with the same peripheral device and Master Control Panel with PCA10000 (which has a Segger chip) as a central. There was no problem with data throughput...

Best regards

Mike

EDIT: Maybe the UART speed is a problem. I use default 115200 baudrate... I will try to investigate it.

RE: pc-ble-driver 1.0 - maximum data throughput

bjorn-spockeli — Thu, 13 Oct 2016 14:17:08 GMT

Hi Mike,

I spoke to one of the pc-ble-driver developers and it appears that you have reached the throughput( ~16kbit/s) possible using the nRF5x DKs and dongles.

This is due to delays introduced by passing all the data through the Segger chip and that there are handshakes which further restricts the max communication speed.

Best regards

Bjørn