UART the best way to exploit the full bandwith of nRF52840 Dongle? Send images with UART?

[Researcher123]

Hello,

I am using a nRF52840 dongle to communicate between a laptop running Ubuntu and a phone running Android.

Right now I set up a UART-BLE communication using an adapted version of the usbd_ble_uart example from the Nordic nRF5_SDK:

- A small C script sends data from the laptop to the dongle via serial port communication.

- The dongle sends the data to the phone via BLE.

- The data is received on the phone using one of the many UART app that are availabe on the Play Store (I like Bluefruit Connect for example).

- The same works the other way too (from phone to laptop).

I have 2 questions about this:

1. Is UART the best way to exploit the full bandwith of the nRF52840 dongle or is there maybe a better way to send data between those two devices? I need it to be BLE between the dongle and the phone though.

2. Is it also possible to send/receive images with UART? Until now I have only successfully sent text. (When I tried to send images, I got a chain of characters as output.)

Thank you for your help.

[awneil]

Researcher123 said:

Is it also possible to send/receive images with UART?

Yes.

It just send bytes - it neither knows nor cares what those bytes represent

[hmolesworth]

Ah, would that be the case <sigh>, but this is a Dongle and I expect it is using the USB uart (if not ignore this post :-) So yes the BLE transmission is just data bytes, but in this case the "uart" is actually USB and the Nordic USB handler helpfully messes up non-ascii data. Look for this line in main.c:

#define ENDLINE_STRING "\r\n"

Here is how it's used:

static void nus_data_handler(ble_nus_evt_t * p_evt)
{
    if (p_evt->type == BLE_NUS_EVT_RX_DATA)
    {
        bsp_board_led_invert(LED_BLE_NUS_RX);
        NRF_LOG_DEBUG("Received data from BLE NUS. Writing data on CDC ACM.");
        NRF_LOG_HEXDUMP_DEBUG(p_evt->params.rx_data.p_data, p_evt->params.rx_data.length);
        memcpy(m_nus_data_array, p_evt->params.rx_data.p_data, p_evt->params.rx_data.length);
        // Add endline characters
        uint16_t length = p_evt->params.rx_data.length;
        if (length + sizeof(ENDLINE_STRING) < BLE_NUS_MAX_DATA_LEN)
        {
            memcpy(m_nus_data_array + length, ENDLINE_STRING, sizeof(ENDLINE_STRING));
            length += sizeof(ENDLINE_STRING);
        }
        // Send data through CDC ACM
        ret_code_t ret = app_usbd_cdc_acm_write(&m_app_cdc_acm,
                                                m_nus_data_array,
                                                length);
        if(ret != NRF_SUCCESS)
        {
            NRF_LOG_INFO("CDC ACM unavailable, data received: %s", m_nus_data_array);
        }
    }
}

.. and here:

        case APP_USBD_CDC_ACM_USER_EVT_RX_DONE:
        {
            ret_code_t ret;
            static uint8_t index = 0;
            index++;
            do
            {
                if ((m_cdc_data_array[index - 1] == '\n') ||
                    (m_cdc_data_array[index - 1] == '\r') ||
                    (index >= (m_ble_nus_max_data_len)))
                {
                    if (index > 1)
                    {
                        bsp_board_led_invert(LED_CDC_ACM_RX);
                        NRF_LOG_DEBUG("Ready to send data over BLE NUS");
                        NRF_LOG_HEXDUMP_DEBUG(m_cdc_data_array, index);
                        do
                        {
                            uint16_t length = (uint16_t)index;
                            if (length + sizeof(ENDLINE_STRING) < BLE_NUS_MAX_DATA_LEN)
                            {
                                memcpy(m_cdc_data_array + length, ENDLINE_STRING, sizeof(ENDLINE_STRING));
                                length += sizeof(ENDLINE_STRING);
                            }

This is in .\examples\peripheral\usbd_ble_uart\main.c

This caught me out a while back; best to remove the end-of-line insertion.

[ovrebekk]

Hi Hugh

It is true that the example is set up to handle ASCII strings, but with some changes to the handler you can make pass through the data more indiscriminately. 

As for maximizing throughput this is not really dependent on which services or characteristics are used, as long as the example is set up to utilize larger attributes, long data length (aka data length extension), and the 2M high speed mode when available on the phone side. 

It is also important to set up the USB handlers to buffer the data into longer packets, to make the BLE communication more efficient. 

Best regards
Torbjørn