This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52840 Dongle (PCA10059) - BLE Central UART / USB CDC ACM - Bluetooth Range is Very Limited?

Hi,

I'm working on a project where we are receiving sensor data from a BLE peripheral (BL654), and publishing it to a piece of PC software via UART/FTDI cable from a BLE central (nRF52840 Dongle PCA10059).

The next logic development step is to implement a virtual USB COM port using the nRF Dongle itself, so we can do away with the FDTI breakout and enclosure.

I've successfully implemented the USB CDC ACM example alongside the BLE UART in my code project, using SDK v15.3.0 and based off the integrated example available in SDK v15.3.0. The COM port itself works fine and I can see valid data over TeraTerm, however the BLE range is extremely limited (< 10cm). Using exactly the same hardware (plus the FTDI cable), and replacing the COM port code with the previous UART code, the range is very good (> 10m).

Is there a bug in the SDK (v15.3.0) or SoftDevice (S140 v6.1.1) that could reduce BLE Tx power when USB CDC ACM is used? Do you have any other suggestions?

I'd be happy to share the project privately if necessary.

Many thanks,

Adam

Parents
  • Hello Adam,

    There is no reason why the range should drop when you change from the UART to the USBD peripheral.

    What do you mean by the range being so short? What are the symptoms? Do you see packet loss or disconnection? 

    Do you have an nRF52840 DK? The dongle is not really that good for development, as it doesn't have a debugger. Try to see if you can develop this on a DK before porting it to the dongle. Then you can see if the signal strength of the received packets is lower when you change from the UART to USB, or if there is some other reason.

    There is an example in the SDK:
    SDK\examples\peripheral\usbd_ble_uart, which probably does about what you are trying to do (this is a peripheral in the BLE connection). Perhaps you can test this one? There is no dongle project for this one, but perhaps you can port it to the dongle using this guide:

    https://devzone.nordicsemi.com/nordic/short-range-guides/b/getting-started/posts/nrf52840-dongle-programming-tutorial

    BR,

    Edvin

Reply
  • Hello Adam,

    There is no reason why the range should drop when you change from the UART to the USBD peripheral.

    What do you mean by the range being so short? What are the symptoms? Do you see packet loss or disconnection? 

    Do you have an nRF52840 DK? The dongle is not really that good for development, as it doesn't have a debugger. Try to see if you can develop this on a DK before porting it to the dongle. Then you can see if the signal strength of the received packets is lower when you change from the UART to USB, or if there is some other reason.

    There is an example in the SDK:
    SDK\examples\peripheral\usbd_ble_uart, which probably does about what you are trying to do (this is a peripheral in the BLE connection). Perhaps you can test this one? There is no dongle project for this one, but perhaps you can port it to the dongle using this guide:

    https://devzone.nordicsemi.com/nordic/short-range-guides/b/getting-started/posts/nrf52840-dongle-programming-tutorial

    BR,

    Edvin

Children
  • Hi Edvin,

    Thanks for your reply :-)

    In answer to your questions:

    1) I mean that the PCA10059 does not receive data via BLE UART from the BL654 module at ranges >10cm. I haven't investigated any further than this, as I wasn't sure how to test for packet loss and signal strength. As it is only the receiver-side firmware that has been modified during my testing, on second thoughts I'm not sure whether power could have anything to do with my problem - perhaps the USB idle state is interfering with BLE background tasks.

    2) I am developing on the PCA10059 but using a PCA10056 connected over SWD via a TagConnect 2050 cable, meaning that I can download to and debug on the PCA10059 using the PCA10056's onboard hardware. I'm not sure how I would go about comparing signal strength of the received packets, however.

    3) I was developing based on the example you've mentioned ("usbd_ble_uart"), but I haven't tried testing with that exact project yet. Thank you for linking the guide for porting to PCA10059, I'll give it a read.

    I hope this helps.

    Many thanks,

    Adam

  • Keep in mind that the printed antenna (aerial) on the USB Dongle performs very poorly compared with a chip antenna typically used on other boards and modules; ie it is never going to work as well, but in addition it may be next to a large ground (laptop) which kills 2.4GHz signals quite well. Better performance is possible using a USB cable extension so the dongle is not close to a ground sink.

  • Hi,

    Thank you for the suggestion :-)

    This is exactly what we thought, so I tested the PCA10059 whilst it was hooked up to a USB extension cable (approx. 45cm) and still had problems. I also positioned the BL654 module as close to the chip antenna on the bottom of the PCA10059 as possible.

    Many thanks,

    Adam

  • hmolesworth said:
    Keep in mind that the printed antenna (aerial) on the USB Dongle performs very poorly compared with a chip antenna typically used on other boards and modules;

     that is a valid point. I didn't think of that Slight smile

     

    AdamWilsonCPI said:
    1) I mean that the PCA10059 does not receive data via BLE UART from the BL654 module at ranges >10cm. I haven't investigated any further than this, as I wasn't sure how to test for packet loss and signal strength. As it is only the receiver-side firmware that has been modified during my testing, on second thoughts I'm not sure whether power could have anything to do with my problem - perhaps the USB idle state is interfering with BLE background tasks.

     Actually, there is no packet loss in BLE. If a packet is not ACKed, it will be retransmitted until it is ACKed. The only way a packet is not reaching the destination is if the devices disconnect. 

    It is however possible that you spend too much time in the BLE events (notification / write received). If so, you will block for the incoming notification/write events, even though the softdevice has received the packet. I don't know what your application looks like, but see if it behaves the same if you try to just copy the data from the BLE event to a temporary buffer, and then use the main loop to handle this data. But if that was not an issue when you were using UART, it is hard to believe that it is an issue with USB, as this is a faster protocol. 

     

    AdamWilsonCPI said:
    2) I am developing on the PCA10059 but using a PCA10056 connected over SWD via a TagConnect 2050 cable, meaning that I can download to and debug on the PCA10059 using the PCA10056's onboard hardware. I'm not sure how I would go about comparing signal strength of the received packets, however.

     That is good. Then you have the possibility to debug, which I assumed you did not.

     

    AdamWilsonCPI said:
    3) I was developing based on the example you've mentioned ("usbd_ble_uart"), but I haven't tried testing with that exact project yet. Thank you for linking the guide for porting to PCA10059, I'll give it a read.

     Let me know if the behavior is similar there. If it is, does it also happen if you test with another dongle (if you have more)? Does your device disconnect from the central, or do you seemingly only have "packet loss"?

    Is it possible for me to reproduce this? Preferrably on an nRF52840 DK, but if it is too much work to port it, I can give it a go myself. It should be straight forward. Just remember that I don't have any other HW devices that you may have, so if it is possible to reproduce with either a phone or another DK as a central, that would be the easiest. 

    Best regards,

    Edvin

  • Hi Edvin,

    Thanks for getting back to me :) 

    I understand what you mean, thank you. BLE read events should only be occurring every 200ms with only 100 bytes of data, so it shouldn't be too taxing for the system - however, I believe that missing events is the problem, but this was not the cause.

    I went over the differences between my project and "usbd_ble_uart" (I couldn't use this one directly, as this is for a peripheral and not a central) with a fine-toothed comb, and found a call to "nrf_cli_process()" in the idle state function which must have been left over following integration. I've removed the call, and both the BLE and USBD seem to be working fine now!

    I'll continue testing and let you know if anything changes. Thanks for all your help!

    Many thanks,

    Adam

Related