Sending a complete file at once from SD card to Mobile App using NRF52840.

[Samiulhaq]

Hello Nordic Family. I hope this post finds you well. 

I am working on a project where I have connected multiple sensors to the NRF52840. I have collected all the sensor's data and saved it on the SD card as a CSV file. The file size is about 240MB which has 60 Hours of data from all the sensors(client requirements). Now I want to send this complete file at once from the SD card to the Mobile App in the fastest possible way. I have run the below program on my board

/cfs-file/__key/communityserver-discussions-components-files/4/8204.ble_5F00_app_5F00_uart_5F00_fatfs_5F00_send_5F00_sdk_5F00_16.0.0.zip.

but this program reads data one by one byte from the SD card and sends it byte by byte to the mobile app which I don't want. I want to send the whole file at once in the fastest possible way not byte by byte. Any help regarding this will be highly appreciated. 

Best Regards,

Sami 

[Håkon Alseth]

Hi,

 

sends it byte by byte to the mobile app

Buffer up the read out data from the SD card and send them in size of "BLE_NUS_MAX_DATA_LEN" instead?

 

Kind regards,

Håkon

[Samiulhaq]

Hi Hakon, thank you for your kind suggestion. Yes, I am sending the data in the size of "BLE_NUS_MAX_DATA_LEN"( 243byte) but it can't solve my problem because the data is sent in chunks of 243bytes per chunk and I want to send the complete file at once, not in chunks. My file size is about 240MB, will it be fully sent to the mobile App at once? If yes Can you please recommend to me the fastest possible way?

Best Regards,

Sami

[Håkon Alseth]

Hi Sami,

 

If you're sending, over BLE, in chunks of 243 bytes, your application is optimized wrt. size.

Q1: What is the throughput that you're seeing?

Q2: Have you tried adjusting sdk_config.h::NRF_SDH_BLE_GAP_EVENT_LENGTH?

Note that you might need to adjust the RAM start address to accommodate the added RAM requirements that the stack needs.

 

Note that you're sending a large amount of data, and it will take a long time. Assume you're getting 300 kBit/s (37.5 kByte/s), it will take approx. 7000 seconds (~2hours) to send this amount of data.

 

Kind regards,

Håkon

[Samiulhaq]

Hello Hakon, thanks for your reply.

Håkon Alseth said:

If you're sending, over BLE, in chunks of 243 bytes, your application is optimized wrt. size.

Yes, I am sending data to the mobile App using ble_uart with the chunk size=BLE_NUS_MAX_DATA_LEN-3 which in turn is equal to NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247, so chunk size= 247-3= 244 bytes/chunks

Håkon Alseth said:

What is the throughput that you're seeing?

Does throughput mean bytes/second? If yes, my current throughput is 55,000 bytes/second. For this, I have the chunks size= 247-3= 244bytes/chunk, NRF_SDH_BLE_GAP_EVENT_LENGTH= 100  and MIN_CONN_INTERVAL and MAX_CONN_INTERVAL to 7.5 and 200 respectively

Håkon Alseth said:

Q2: Have you tried adjusting sdk_config.h::NRF_SDH_BLE_GAP_EVENT_LENGTH?

Yes, I have changed that value to 100(of course by changing the RAM start address), by doing this the rate of sending chunks/seconds is increased. Also, I have changed the MIN_CONN_INTERVAL and MAX_CONN_INTERVAL to 7.5 and 200 respectively which also increases the rate. But the bytes/chunk is 244

Håkon Alseth said:

Note that you're sending a large amount of data, and it will take a long time. Assume you're getting 300 kBit/s (37.5 kByte/s), it will take approx. 7000 seconds (~2hours) to send this amount of data.

Have you read this blog in which they claim "The throughput measured may vary depending on the environment, but the maximum throughput should be around 1365 Kbps for BLE 5 High Speed, 775 Kbps for BLE 4.2, 128 Kbps for BLE 4.1 and 21.3 Kbps for BLE 5 Long Range. Be aware that there may be some inaccuracies in the measurements." Your comment about this?

My goal is to send the complete whole file at once not in chunks so that I can easily manage and control it on the mobile App side. I think NRF52 only sends small chunks at one time, not a complete large file, is that right?  If Yes, what will be the other fastest way to such a large file to the mobile App?

Best Regards,

Sami

[Håkon Alseth]

Hi,

 

Samiulhaq said:

Yes, I am sending data to the mobile App using ble_uart with the chunk size=BLE_NUS_MAX_DATA_LEN-3 which in turn is equal to NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247, so chunk size= 247-3= 244 bytes/chunks

Good, you're maximizing the MTU size.

Samiulhaq said:

Does throughput mean bytes/second? If yes, my current throughput is 55,000 bytes/second. For this, I have the chunks size= 247-3= 244bytes/chunk, NRF_SDH_BLE_GAP_EVENT_LENGTH= 100  and MIN_CONN_INTERVAL and MAX_CONN_INTERVAL to 7.5 and 200 respectively

When you have a high event length, it is actually better to have a larger connection interval. When using the minimum of 7.5 ms, you are hopping to a new channel every connection interval, which can reduce the overall throughput a bit.

However, the event length given by the central will also change from phone-to-phone.

 

Try setting the min conn interval to 50 ms and see if this has any impact on the overall throughput.

 

Samiulhaq said:

Have you read this blog in which they claim "The throughput measured may vary depending on the environment, but the maximum throughput should be around 1365 Kbps for BLE 5 High Speed, 775 Kbps for BLE 4.2, 128 Kbps for BLE 4.1 and 21.3 Kbps for BLE 5 Long Range. Be aware that there may be some inaccuracies in the measurements." Your comment about this?

Your overall throughput will depend on what the parameters that the central device accepts. It is true that you can technically achieve these numbers, but that also depends on a phone that allows such optimal parameters.

Samiulhaq said:

My goal is to send the complete whole file at once not in chunks so that I can easily manage and control it on the mobile App side. I think NRF52 only sends small chunks at one time, not a complete large file, is that right?  If Yes, what will be the other fastest way to such a large file to the mobile App?

You have to transfer the file in chunks of the max. data length that you can send, ie. 244 bytes in your scenario.

 

Kind regards,

Håkon

[Samiulhaq]

Hi Hakon, 

Håkon Alseth said:

Your overall throughput will depend on what the parameters that the central device accepts. It is true that you can technically achieve these numbers, but that also depends on a phone that allows such optimal parameters.

I have applied all the suggestions from multiple similar threads but still, I can only send 220KB(of 234MB file) per 4 seconds which is 55KB/second. This figure is far beyond the 1Mbps speed. 

Håkon Alseth said:

You have to transfer the file in chunks of the max. data length that you can send, ie. 244 bytes in your scenario.

Yes, I am sending in chunks of 244 bytes but the rate of sending chunks is very low. I am very tired of looking at this problem for more than a week and studied a lot of threads but no one help me. I just want to read a 234MB file from the SD card and send it to the mobile app in the fastest possible way(up to 1Mbps)

Best Regards,

Sami Ul Haq. 

[Håkon Alseth]

Hi,

 

Samiulhaq said:

I have applied all the suggestions from multiple similar threads but still, I can only send 220KB(of 234MB file) per 4 seconds which is 55KB/second. This figure is far beyond the 1Mbps speed. 

55 kiloBytes per second -> 440kbit/s, which is quite fast when using the BLE 1Mbit on-air data rate.

Have you checked what the connection parameters that you receive from your phone is? This might be the maximum based on the event length, connection interval, etc. that the central provides you with.

 

Have you tried requesting 2MBit PHY in the BLE_GAP_EVT_CONNECTED event?

Here's a snippet on how to request that:  enabling 2Mb phy Windows 10 (1909) 

 

Kind regards,

Håkon

[Samiulhaq]

Hi Hakan, thanks for the reply.

Håkon Alseth said:

55 kiloBytes per second -> 440kbit/s, which is quite fast when using the BLE 1Mbit on-air data rate.

No, I am not using IMbit on-air data rate, rather I am using 2MBPS as I have set BLE_GAP_EVT_PHY_UPDATE_REQUEST: to 

                .rx_phys = BLE_GAP_PHY_2MBPS,
.                tx_phys = BLE_GAP_PHY_2MBPS,

Is this the correct way to set the 2MBPS on-air data rate? 

Håkon Alseth said:

Have you tried requesting 2MBit PHY in the BLE_GAP_EVT_CONNECTED event?

The below is my Ble_connected Case:

case BLE_GAP_EVT_CONNECTED:
            NRF_LOG_INFO("Connected");
            err_code = bsp_indication_set(BSP_INDICATE_CONNECTED);
            APP_ERROR_CHECK(err_code);
            m_conn_handle = p_ble_evt->evt.gap_evt.conn_handle;
            err_code = nrf_ble_qwr_conn_handle_assign(&m_qwr, m_conn_handle);
            APP_ERROR_CHECK(err_code);
            break;

How do I check whether the 2MBit PHY is requested or not in the BLE_GAP_EVT_CONNECTED case?

Håkon Alseth said:

Have you checked what the connection parameters that you receive from your phone is? This might be the maximum based on the event length, connection interval, etc. that the central provides you with.

Yes Sir, this might be the case, How do I check these parameters in my mobile App? I am using a Vivo phone and the mobile App which I am using to get the data is nRF Toolbox in which I am using UART. How to check connection parameters in my case? 

Best Regards,

Sami Ul Haq

[Håkon Alseth]

Hi Sami,

 

Samiulhaq said:

No, I am not using IMbit on-air data rate, rather I am using 2MBPS as I have set BLE_GAP_EVT_PHY_UPDATE_REQUEST: to 

                .rx_phys = BLE_GAP_PHY_2MBPS,
.                tx_phys = BLE_GAP_PHY_2MBPS,

Is this the correct way to set the 2MBPS on-air data rate? 

You should call the snippet from the BLE_GAP_EVT_CONNECTED, similar to this:

case BLE_GAP_EVT_CONNECTED:
{
    ble_gap_phys_t const phys =
    {
       .rx_phys = BLE_GAP_PHY_2MBPS,
       .tx_phys = BLE_GAP_PHY_2MBPS,
    };
    err_code = sd_ble_gap_phy_update(p_ble_evt->evt.gap_evt.conn_handle, &phys);
    ...
    break;
};

Samiulhaq said:

Yes Sir, this might be the case, How do I check these parameters in my mobile App? I am using a Vivo phone and the mobile App which I am using to get the data is nRF Toolbox in which I am using UART. How to check connection parameters in my case? 

You can use the BLE sniffer to see the details of the link:

https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le

 

Note that you should also include the pairing process, so that the sniffer can follow (ie. decode) the rest of the communication as well.

You can do this by deleting the bonds on both phone and nRF, then the sniffer shall be able to pick it up.

 

Kind regards,

Håkon

[Samiulhaq]

Hello Hakan, thanks for the replay. 

Håkon Alseth said:

You should call the snippet from the BLE_GAP_EVT_CONNECTED, similar to this:

Yes, I have included these lines in the BLE_GAP_EVT_CONNECTED.  Thanks for the snippet.

Håkon Alseth said:

You can use the BLE sniffer to see the details of the link:

I have set up the Sniffer with Wireshark, but I am new to the sniffer and can't analyze the packets correctly that is how I can find the packet size, number of bits/bytes per packet, connection interval, time taken by1 packet, and other related parameters in the sniffer/Wireshark. I have attached the Wireshark result to this reply, can you please analyze it and extract the required information from it? I will be very thankful for this kind act. 

Sniffer_Result.pcapng

Håkon Alseth said:

Note that you should also include the pairing process, so that the sniffer can follow (ie. decode) the rest of the communication as well.

You can do this by deleting the bonds on both phone and nRF, then the sniffer shall be able to pick it up.

 

I didn't understand this as I am new to Sniffer. I have the sniffer running in one NRF52840 Eval kit and another NRF2840 DK for the main task to send the data to the app. Can you please refer me to a blog/ticket etc for more clarification?

Best Regards,

Sami  

[Håkon Alseth]

Hi Sami,

 

Sniffer trace was good, thanks for sharing this one.

 

The PHY is changed successfully to 2MBit in frame #867.

What is the throughput you're seeing now?

From the traces it seems that the central (phone) does not poll the peripheral (nrf), which can indicate that it is doing something else. The problem with using a phone is that most bluetooth chipsets there are combo-chipsets, and also uses the same radio to server multiple services.

 

Kind regards,

Håkon