This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Multithreading on nrf9160

Hello Nordic gang.

I'm reading sensor data on the nrf9160DK, the sensors have a fifo with 96 entries. If I can't read the sensors fast enough, the fifo overflows and I get data loss.
The sampling rate is 4000 SPS and the sample size is 64bit. Therefore, there is not enough RAM to hold data and there is a need of continuously writing data to memory.

Now, I have integrated a micro sd card, it writes fast, faster than the external flash. If I do a measurement of 20 seconds, sometimes there is no fifo overflow but sometimes there are 2-3 entries being lost during the recording. I find it interesting that it is inconsistent.

However, it is extremely close to being fast enough, and sometimes it actually is. Now, as for solutions I've been considering multi-threading.

The write speed is fast enough and the fifo queue is decreased to its lowest value but then we reach entry #64, there is a delay. I'm guessing this has to do with the cluster or page size of the FAT32 format and the allocation of new memory units takes a bit of time. Every multiple of 64 there is a delay. Each entry is 64 bits so it's every 4096 bits this occurs.

Sometimes this resizing makes the queue overflow but not always. Sometimes it goes from 0 to 40 entries in the fifo, which is fine, other times it goes from 0 to 96 and we have data loss. I thought that maybe you could multithread this so that during the write, we still take down data from the fifo and store it in a variable until the write function is done, thus ensuring there is no data loss. Would this be possible? If so, how is it implemented in code?


I've been using fs_write when writing to a file on the sd card.

Edit: The idea I had was to implement a fifo structure where data from sensor is continuously added and written to memory. Thus, under cluster allocation delay, the fifo grows while waiting for the sd-card.


Thanks for brainstorming with me

Warmest regards

nWre

Parents
  • Hello nWre,

    If I understand the issue correctly, you are poking the limit of the sd card communication, because of the rate of which the data is coming from your sensor, right?

    Have you considered/tried to either:

    Increase the SPI speed (I assume that the SD card reader uses SPI or TWI (I2C)? Is it possible to increase the clock speed of that peripheral?

    Buffer up more data before you write to the SD card. Larger chunks means less overhead with the communication with the SD card.

    Perhaps one of the two can get you below the threshold, so that you can keep up with the sensor data?

    Best regards,

    Edvin

  • Hi Edvin! I'm running SPI at the highest possible speed. I thought about larger chunks but wont there still be a resizing problem once the page size is reached? Writing 8 bytes at a time is fast enough, it is just the page resizing that slows it down. I will of course try this and get back to you.

    The question of multithreading is still relevant for me though as when data is recorded and saved, I then need to send this via FTP so server. During the transmission of this, I still need the sensors to be active and ready to record in a triggering event, that is, the system can't be occupied fully if you understand what I mean.

    Thanks for the help!

  • Hi again Edvin! Sure, I drew a picture that might explain it better.
    Is there an example of running threads with prio and datatransfer like you described?
    As shown in the picture, at multiple of 4096 bits, there is a delay using fs_write. I'm thinking this might be because of the page/cluster size of the fileformat fat32 but I'm not sure. I formatted it with 32kB cluster size so it might rather be a different problem entirely.

  • nWre said:
    there is a delay using fs_write

    Is the delay caused by the call to fs_write(), or do you call fs_write all the time, and every 64 samples fs_write() takes longer than usual?

  • I call fs_write all the time, and every 64 samples fs_write() takes longer than usual. That is why I'm thinking of allocation of new memory space. I'm using a 32gb sd-card because that is what I had on hand but a 2gb would do just fine. I ordered one (hard to find a 2gb sd-card in modern times haha) to see if maybe that speeds things up a bit.

  • A bit outside my field, but have you tried to reformat the SD card to see if changing the "allocation unit size" changes the behavior?

    Best regards,

    Edvin

  • The only way it detects the SD-card is if it is formatted with the official sd-cart-formatter. Windows wont do. In that formatter you can't set your preferred cluster size but it detects the size of the sd-card and sets cluster size according to that. My card has a cluster size of 32kB and not 512 bytes(64 entries * 8 bytes per entry = 512 bytes). If I can't work around this, is it possible to write code such that when the writing operation is busy, I simultaneously read the sensor and store it in a variable until the fs_write function is done and then write that data to the card?

    Thanks Edvin, I really appreciate your help!

Reply
  • The only way it detects the SD-card is if it is formatted with the official sd-cart-formatter. Windows wont do. In that formatter you can't set your preferred cluster size but it detects the size of the sd-card and sets cluster size according to that. My card has a cluster size of 32kB and not 512 bytes(64 entries * 8 bytes per entry = 512 bytes). If I can't work around this, is it possible to write code such that when the writing operation is busy, I simultaneously read the sensor and store it in a variable until the fs_write function is done and then write that data to the card?

    Thanks Edvin, I really appreciate your help!

Children
Related