Hi All,
I have a system with an nRF52840-dongle (PCA10059) acting as a serial port in windows 10. It runs extremely slowly. Sending 8kB over the interface takes 3 minutes.
Is there any way in Windows to adjust memory allocation, or see why the driver is running so slow?
The system is used for testing hundreds of bluetooth units, resulting in huge wasted time.
Thanks,
Rob.
Hi Edvin,
Yes the interface runs about 360 bits/s judging by the time it takes to send the data. As Bluetooth LE is in the megabits/s range this is very disappointing.
We use the nRF52840 dongle (PCA1059 issue 2.0) as a serial port (CDC). The transfer is triggered by the PC side. The PC software is 'node' which has the front end in a web browser. I didn't write the PC software.
I have the larger nrf52840 DK board here but it will take some time to get this running like the dongle.
The 8kB of data is used as a configuration file on an embedded/industrial device. During test we write a configuration file (from PC > nRF52840 device) with various serial numbers and calibration values. Then read it back to check it was written correctly. The transfer is frustratingly slow in both directions.
There is an nRF52840 on each end, as the embedded device has one inside. When communicating they sit a few inches from each other.
I don't know about different types of BLE connection, assumed this was BLE V5, but will look into it.
I am embedded programmer for the product but know little about programing in Windows.
Thanks for help
-Rob
Hello Rob,
Sorry for the late reply.
What SDK version are you using?
What I need you to do is try to debug the application. Either you need to solder on a debug connector on the dongle (on the bottom side), or you need to port the application to run on the DK.
What happens when you send the data over CDC? Do you get everything in one chunk? Or do you get bytewise interrupts? Is the USB the bottleneck in your throughput, or is the BLE the bottleneck of the throughput? Or perhaps the storing of the data? How do you store it?
This is where debugging becomes handy. Is it equally slow if you don't transfer the data over BLE? Just send it over USB and discard it, and send the same amount of dummy data back. Does that take as long? If not, then it is not the USB that is your bottleneck.
Equally, if you transfer the data over BLE, but don't store it however you are storing it now. Is it as slow? If not, then BLE is not your bottleneck either. How about storing and reading back the data? Is that your bottleneck?
Hanowar123 said:I don't know about different types of BLE connection, assumed this was BLE V5, but will look into it.
That doesn't really say anything. What is your MTU, what is your connection event length? What is your connection interval? What is the actual packet size you are using? Sending one byte in each packet is very little efficient, since the header/payload ratio becomes very low. Also, a BLE link can be either very power efficient or "very high throughput". The maximum throughput should be around 1.3MBPS of actual payload data (with MTU = 247, connection interval = 50ms and connection event length also 50ms. Also you need to keep sending buffers with length 247 all the time to keep up with this throughput).
Best regards,
Edvin
Hello Rob,
Sorry for the late reply.
What SDK version are you using?
What I need you to do is try to debug the application. Either you need to solder on a debug connector on the dongle (on the bottom side), or you need to port the application to run on the DK.
What happens when you send the data over CDC? Do you get everything in one chunk? Or do you get bytewise interrupts? Is the USB the bottleneck in your throughput, or is the BLE the bottleneck of the throughput? Or perhaps the storing of the data? How do you store it?
This is where debugging becomes handy. Is it equally slow if you don't transfer the data over BLE? Just send it over USB and discard it, and send the same amount of dummy data back. Does that take as long? If not, then it is not the USB that is your bottleneck.
Equally, if you transfer the data over BLE, but don't store it however you are storing it now. Is it as slow? If not, then BLE is not your bottleneck either. How about storing and reading back the data? Is that your bottleneck?
Hanowar123 said:I don't know about different types of BLE connection, assumed this was BLE V5, but will look into it.
That doesn't really say anything. What is your MTU, what is your connection event length? What is your connection interval? What is the actual packet size you are using? Sending one byte in each packet is very little efficient, since the header/payload ratio becomes very low. Also, a BLE link can be either very power efficient or "very high throughput". The maximum throughput should be around 1.3MBPS of actual payload data (with MTU = 247, connection interval = 50ms and connection event length also 50ms. Also you need to keep sending buffers with length 247 all the time to keep up with this throughput).
Best regards,
Edvin
