Dongle in server mode with connect needs 100-400 ms to answer Read or Write response

[jean-marc]

Using a Peripheral set in Central mode and write then read data back in the Dongle nRF5240 set in Server Mode.

Once connected and exchange MTU (extended) I write and then read my data. The read response or the write response are very long up to 400 ms for the read response.

Sending 1 byte or 240 bytes does not make any differences.

Why is this delay for?

My Interval connection is set to the minimum 7.5 ms.

Are this timing correct? Can I made then shorter?

Thank for helping.

Jean-Marc

[Edvin]

Yes, you can run it on the dongle. See how to set up the "UART" (usb) viewer as linked in the example. Remember to use both "Terminal settings" and "UART and USB settings".

BR,

Edvin

[jean-marc]

No problem for a terminal setup, but for the dongle, the nRFgo does not detect the dongle. How can I flash the hex file?

[Edvin]

That is because the dongle doesn't have a programming chip, like nRFgo is actually looking for. When you connect a DK, it will actually look for and discover the programming chip.

To program the dongle, you must either use nRF Programmer v. 1.0.0-experimental.6 (see screenshot below), which is part of the new nRF Connect, which you can find here.

Alternatively, you can use Nordic Command Line Tools (nrfjprog) to perform the DFU.

So since the dongle doesn't have a programming chip, you must use the preprogrammed bootloader to change the application on the dongle. Please see this guide:

http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52%2Fdita%2Fnrf52%2Fdevelopment%2Fnrf52840_dongle%2Fprogramming.html

Best regards,

Edvin

[jean-marc]

Again I got lost on the different link.

1) nRF Connect has the experimental 5 as default. Found a new version available experimental 6. -> OK.

But now what hex file should I load? "the ble_app_uart_pca10056_s140.hex" is for pca10056 board.

My dongle is pca10059. I loaded the pca10056 but the dongle is not functioning.

2) Do not understand what is the DFU Trigger, if it is useful for my problem.

3) For the nRF5x-Command-Line_Tool-Win32, I will probably have the same problem for the hex file to upload.

I appreciate the time you spend to help me... :-)

BTW I just received my DK now and will probably drop the dongle.

Jean-Marc

[Edvin]

Good morning, Jean-Marc!

1) 5 worked fine as well, but nRF Connect got an update recently, so I thought I should refer to the latest version. It is just important that you use the experimental 5/6, as this is the only version that can program the softdevice and the application.

Can you specify what you mean with "dongle is not functioning"? Are you able to program it? (Do you get any errors in nRF Programmer?)

It may be that the application is running, but you will not get the UART information, because the dongle is not connected with the pins used for UART. 

This will be easier to understand now that you can compare it with the DK.

If you program the same hex file (It is the one you found in the SDK\examples\ble_peripheral\ble_app_uart\hex folder, right?), and you open Putty or Termite (UART terminals) you should see some text like "UART example started". Remember that when you compile the project yourself, you also need to program the softdevice, located in SDK\components\softdevice\s140\hex. If you use Segger Embedded Studio, you don't need to think about this, as it programs the softdevice for you.

For your dongle, please try the example file: SDK\examples\peripheral\usbd_ble_uart\pca10056\

You need to compile this project, as it doesn't have precompiled hex-files.

The reason that it is different for the dongle is that the USB part of the dongle is the part that you plug into your computer, and it is not the same as the USB on the short side of the DK, it is the same as the USB on the long side. Basically, you can't use the USB pins on the dongle to transfer UART data. This is probably why you think that the .hex file doesn't work.