SD Card file is empty

max_eastwoodmax_eastwood Thailand
edited February 4 in Cyton

I'm using my OpenBCI on a daily basis for psg eeg sleep study for about 2 months. Almost all recordings went smoothly but 2 times i got weird sd file.
When i look at start of file by using "less OBCI_89.TXT" i see this

My usual output is

Any idea on why is that happening and how to avoid it? Problem is not too big, happening like for 1 out of 50 nights, but i want to fix it.
I have 2 Cytons bought at different times and it happened at both, each one have own different sd card model, so problem doesnt look like specific to single sd card or device. All channels were good for sure, i've verified impendances and signals before starting sd card writing session. It seems that file were initialized but write to sd didnt started for some reason... Led were on for full night, so its not battery issue also.

Comments

  • wjcroftwjcroft Mount Shasta, CA

    Hi Max. Thanks for reporting this. I've pointed the hardware team at your thread here. I also suggest you email (contact at openbci.com) which is customer support. That will get you in the queue for resolution. When did you purchase these Cytons? I assume from OpenBCI directly, correct?

  • wjcroftwjcroft Mount Shasta, CA

    The other obvious first step would be to try with a different type of SD card, to eliminate possibility of incompatibility.

    https://docs.openbci.com/Cyton/CytonSDCard/

  • @wjcroft said:
    The other obvious first step would be to try with a different type of SD card, to eliminate possibility of incompatibility.

    https://docs.openbci.com/Cyton/CytonSDCard/

    I've tried 2 different sd cards models, both original sandisk but with different sizes and speeds. I've already gone through that manual, thanks. Still not see why that is happened. Most of nights are totally fine, so if there were major incompability i except more nights broken or may be some breaks in the middle of the night. Here it seems device just not starting write after file were initialized.

    When did you purchase these Cytons? I assume from OpenBCI directly, correct?

    First one i've purchased about 1 year ago. The second one just about a month ago. Both were bought at official OpenBCI shop.
    Thanks, for now its not a big deal, but i'll wait here if someone have any ideas...

  • @max_eastwood
    What's the storage capacity of the microSD cards you use?
    We strongly recommend to use a card that has 8, 16, or maximum, 32 GB of storage.

    Secondly, we need to know what firmware version your board is running.
    Two ways to view the firmware version:
    1. https://docs.openbci.com/Cyton/CytonSDK/#cyton-command-protocol-overview
    2. https://docs.openbci.com/Cyton/CytonSDK/#miscellaneous
    This should be done from Arduino serial monitor or similar serial monitor program.
    cc @retiutut

  • @Shirley said:
    @max_eastwood
    What's the storage capacity of the microSD cards you use?
    We strongly recommend to use a card that has 8, 16, or maximum, 32 GB of storage.

    I've tested big range of storage (from 8gb to 512gb) and came that 32 GB is an optimal. I use sandisk extreme 32GB and have tried sandisk ultra 32 gb. Both card got empty recording once.

    Secondly, we need to know what firmware version your board is running.
    Two ways to view the firmware version:
    1. https://docs.openbci.com/Cyton/CytonSDK/#cyton-command-protocol-overview
    2. https://docs.openbci.com/Cyton/CytonSDK/#miscellaneous
    This should be done from Arduino serial monitor or similar serial monitor program.
    cc @retiutut

    I've just realized that i use firmware with sd card unlocked sampling rate https://github.com/roflecopter/OpenBCI_Cyton_Library_SD/pulls?q=is:pr+is:closed which is a fork of master branch https://github.com/OpenBCI/OpenBCI_Cyton_Library
    I use 500Hz sampling rate, not sure but may can that be a reason?

  • wjcroftwjcroft Mount Shasta, CA

    @max_eastwood said:
    ...
    I use 500Hz sampling rate, not sure but may can that be a reason?

    I think I recall seeing that there is a limitation in how fast the sd card device can process block writes. In other words a tradeoff in the block size and write speed. It may be possible that you have to go to larger block sizes / buffering with higher sample rates.

    re: sd card size, if you calculate out the amount written overnight, doesnt it seem likely that this would be no where near 32 GB? What is the file size you usually end up with? Suggest going with the smallest size card that fits that requirement. Or perhaps storing several days of recordings if that is a requirement. Bigger card sizes may come with tighter timing restrictions.

  • max_eastwoodmax_eastwood Thailand
    edited February 6

    @wjcroft said:

    @max_eastwood said:
    ...
    I use 500Hz sampling rate, not sure but may can that be a reason?

    I think I recall seeing that there is a limitation in how fast the sd card device can process block writes. In other words a tradeoff in the block size and write speed. It may be possible that you have to go to larger block sizes / buffering with higher sample rates.

    But how block write processing speed can result in totally empty sd file? Shouldn't it just result in dropped / delayed samples? In my case whole file is empty, but other ~40 nights are fine, so it looks like something happened at start of recording and it seems like a rare thing...

    re: sd card size, if you calculate out the amount written overnight, doesnt it seem likely that this would be no where near 32 GB? What is the file size you usually end up with? Suggest going with the smallest size card that fits that requirement. Or perhaps storing several days of recordings if that is a requirement. Bigger card sizes may come with tighter timing restrictions.

    Both cards have 32 GB size, each session file have fixed size of 2.5GB (500Hz 12 hours session, it might be more than needed, but anyway for sure is enough) and every 2-3 nights i empty sd card. Cards are Sandisk Extreme PRO 32GB U3 and Sandisk Ultra 32GB Class 10. I will try to switch to 8/16 GB versions and will see how it goes. For now it looks like issue with start recording into file after it was successfully initialized and since it happens rarely i'm not sure how to reproduce / debug it... Anyway thanks for suggestions, i'm going to try smaller sd cards, maybe that helps.

  • wjcroftwjcroft Mount Shasta, CA

    @max_eastwood said:
    ...
    But how block write processing speed can result in totally empty sd file? Shouldn't it just result in dropped / delayed samples? In my case whole file is empty, but other ~40 nights are fine, so it looks like something happened at start of recording and it seems like a rare thing...

    I'm just throwing out speculations about the sd card hardware malfunctioning if stressed. In terms of the 'empty' sd file, is the file length exactly the same as normal files, just all zeros? It's possible that if some timing related glitch is triggered, it stays busted for the entire session.

    Thanks, for trying alternative scenarios.

  • max_eastwoodmax_eastwood Thailand
    edited February 6

    @wjcroft said:
    In terms of the 'empty' sd file, is the file length exactly the same as normal files, just all zeros? It's possible that if some timing related glitch is triggered, it stays busted for the entire session.

    Correct, file is of same size as normal ones. It seems device successfully allocating space on sd card for a session file and then for some reason do not write into file, even "%STOP AT" at first line which is always being presented in all sd files.

  • In which format do you format the cards and on what kind of PC windows or Mac?
    Try to format in fat32, is an old and more stable format then exfat.
    And try to format it best on on a Windows PC (or if on Mac over Windows running in a VM)

  • @pinky said:
    In which format do you format the cards and on what kind of PC windows or Mac?

    Mac, i format in Fat using diskutil

    Try to format in fat32, is an old and more stable format then exfat.

    It is in fat32

    And try to format it best on on a Windows PC (or if on Mac over Windows running in a VM)

    I will try, but OpenBCI guide describes to use Mac Disk Utility, so i'm not sure how that can help... I expect macos use same fat32 format as windows, isnt it?

  • wjcroftwjcroft Mount Shasta, CA

    Pinky, thanks.

    He is already formatting correctly and the glitch only happens 1 out of 50 times approximately. Max is going to try tests with smaller card sizes to see if that makes any difference.

    @max_eastwood said:

    ,,,
    I will try, but OpenBCI guide describes to use Mac Disk Utility, so i'm not sure how that can help... I expect macos use same fat32 format as windows, isnt it?

    Yes FAT32 is the same on both Mac and Windows.

    William

  • max_eastwoodmax_eastwood Thailand
    edited April 30

    About 2.5 months have past and issue happened again once. I'm not sure, but may issue is that single night generates ~2.5GB file each time (due to 8 ch and sf=500Hz) and 32GB card should be reformatted every ~32/2.5=13 days to re-fill space with zeroes... Not sure if that is the case, but i'm going to try reformatting once a week.
    I'm still not too much concerned about that, since its happens very rarely.

  • The issue just happened again. Still count this as very rare.
    Yesterday i bough new sd card (sandisk extreme 32GB U3 A1) and formatted it as usual. Then i've started recording and in the morning got result as in first post. Since that was freshly formatted new sd card i dont think that problem is with re-formatting (my previous post) but something else...

  • wjcroftwjcroft Mount Shasta, CA

    Max, hi.

    If you still have the email reply from customer service in February, I suggest replying to that to keep staff informed who are tracking this issue in Zendesk (the customer service call tracking app.)

    We still don't know if there as any relation to your higher sample rate firmware mod. Mentioning @Shirley.

    William

  • max_eastwoodmax_eastwood Thailand
    edited June 17

    This time i notice file looks a bit different than first time.
    less OBCI_31.TXT
    @wjcroft I understand this may be due mods i've made to firmware and using 500 Hz sampling rate. Since issue is rare i dont bother customer support. If someone would catch this on default firmware i would try to involve support. For now just sharing my experience and frequency of occurence.

  • wjcroftwjcroft Mount Shasta, CA

    The only way to get engineering staff attention is to email (contact at openbci.com), which creates a Zendesk ticket. If you never did that, then no one in engineering is looking at this thread. Engineering staff is generally too busy to check Forum posts here.

  • As another data point, I'm hitting various intermittent issues with SD cards also (https://openbci.com/forum/index.php?p=/discussion/3916/uneven-results-with-sd-card-files#latest), and have hit this same "^@" issue more than once (along with other problems). Same symptoms as above: the file is preallocated with standard size (1.2 GiB for a 12 hour recording), but contains nothing but ^@ bytes:

    I am using stock firmware and not doing anything very sophisticated, just trying to get reliable recordings - see the other thread for details.
    I've sent an email to OpenBCI support for help.

  • @programmatix said:
    As another data point, I'm hitting various intermittent issues with SD cards also (https://openbci.com/forum/index.php?p=/discussion/3916/uneven-results-with-sd-card-files#latest), and have hit this same "^@" issue more than once (along with other problems). Same symptoms as above: the file is preallocated with standard size (1.2 GiB for a 12 hour recording), but contains nothing but ^@ bytes:

    I am using stock firmware and not doing anything very sophisticated, just trying to get reliable recordings - see the other thread for details.
    I've sent an email to OpenBCI support for help.

    Good to know that its not a problem with custom firmwares modification I've made.

Sign In or Register to comment.