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

How to store efficiently an array with over 100 000 byte elements and send it over BLE?

Hi!

I'm using nRF51DK with s110_nRF51_8.0.0 Soft Device and SDK_9.0.0. My application reads ADC with frequency 500Hz (2 bytes of data from one sensor each read), and twi with frequency 20Hz(6 bytes of data from another sensor each read) and sends each measurment over BLE instantly. Now i would like to modify it so that it stores measurments for 90 seconds and then sends all the data over BLE. I assume that i can not just make such a big array by simply writing in my code uint8_t arr[100800];, and i should, for example, use Persistant Storage Manager or some other method to store the data in flash memory. and here is my question: what method/ driver should i use to store my data so that it wont disturb reading ADC with high frequency (and so that i could write data into array after every read from sensor)? And how to send data over BLE after I read and store them? Should I use long-write or just split it by 20 bytes and send one after another (sending doesnt have to be done fast)?

Regards, Ina

Parents
  • It is not possible to store over 100kbytes in RAM (as the nrf51822 is limited to 16/32 kbytes), so simply writing uint8_t arr[100800]; wouldn't work indeed.

    I don't think using flash memory would be fast enough to store these values, but if it even did, number of write cycles to flash memory is limited so I wouldn't recommend continuous writes to flash.

    I suggest using external sram memory (ex. on SPI) to store data. To send this data the fastest way is to use notifications (20b data packets)

  • Thanks for your reply Wojtek.

    Why I asked example code is I have a code developed by some one else (with hardware) and now I am continuing the the development. Hardware designed using SPANSION S25FL164K - 64Mbit (8Mbyte) flash on SPI.

    We are using Gazell protocol to communicate between Reader(Host) and Tags(Devices).

    At TAG side

    1. Tag will take sample of temp, battery level at every predefined interval and stores data to flash. For ex: every 2sec.
    2. Tag will try to report to Reader every predefined interval. Tag can contain several records in flash and enable gazelle then in loop send all packets to reader then disable gazelle. Ex: Everry 1min send 30 records (as 2sec in sample interval: Point 1)

    Above functionality is working very well.

    At READER side

    1. Gazelle is enabled as HOST and listen for the packets (nrf_gzll_host_rx_data_ready). once received store the data in flash. Here is problem. If I use local RAM (char array buffer) instead of flash there is no problem. If I am writing to flash randomly after some packets the nrf_gzll_host_rx_data_ready function is not triggering.

    What could be the problem?

Reply
  • Thanks for your reply Wojtek.

    Why I asked example code is I have a code developed by some one else (with hardware) and now I am continuing the the development. Hardware designed using SPANSION S25FL164K - 64Mbit (8Mbyte) flash on SPI.

    We are using Gazell protocol to communicate between Reader(Host) and Tags(Devices).

    At TAG side

    1. Tag will take sample of temp, battery level at every predefined interval and stores data to flash. For ex: every 2sec.
    2. Tag will try to report to Reader every predefined interval. Tag can contain several records in flash and enable gazelle then in loop send all packets to reader then disable gazelle. Ex: Everry 1min send 30 records (as 2sec in sample interval: Point 1)

    Above functionality is working very well.

    At READER side

    1. Gazelle is enabled as HOST and listen for the packets (nrf_gzll_host_rx_data_ready). once received store the data in flash. Here is problem. If I use local RAM (char array buffer) instead of flash there is no problem. If I am writing to flash randomly after some packets the nrf_gzll_host_rx_data_ready function is not triggering.

    What could be the problem?

Children
No Data
Related