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

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 

  • 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

  • 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

  • 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

  • Hello Hakon, thanks for your reply.

    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

    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_LENGTH100  and MIN_CONN_INTERVAL and MAX_CONN_INTERVAL to 7.5 and 200 respectively

    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

    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

  • 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_LENGTH100  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

Related