data stream freezes during long sessions

TFNANO · February 2015

Hello,

The OpenBCI GUI from https://github.com/OpenBCI/OpenBCI_Processing freezes after running for an hour. I am trying to record EEG signals for an 8 hour period. Should that be possible with the GUI provided? Is this an issue with my personal computer (although I doubt it since there doesn't seem to be anything preventing it from running)? Is there a setting in the code that forces data recording or visualization to stop after a certain period of time?

Thanks.

wjcroft · February 2015

TFnano, hi.

Can you provide a few more details on your environment, which OpenBCI board, what OS and version, type of batteries and voltage, etc. Do you have a record of the amount of time passed from start to freeze; you say one hour, how consistent is that?

Have you tried running with another computer or OS, to rule out that element?

When the freeze happens, does the red led on the dongle go out? Normally it flickers gently as the data is coming in over the radio link.

When the freeze happens, does the OpenBCI GUI let you stop and restart using the GUI buttons. Or do you have to power cycle the OpenBCI.

I don't believe the GUI code has any built in time or file size constraints, but I'll let @chipaudette and @conor_obci comment.

Regards, William

TFNANO · February 2015

Hey William,

32-bit board with Daisy Module (but I'm currently only using 8 channes), Windows 8 computer, 4 AA batteries in the battery pack that came with the kit. I have not tried running it on another computer.

Currently the GUI saves data for about 30-40 minutes consistently and I have not been able to record for longer. The red light on the dongle stays on and flickers for longer, maybe 2-3 hours but then it goes out but there is no data being saved for that period. The GUI freezes completely and the buttons do not work or the control panel. I have to stop the processing file and restart it for the GUI to work again. It seems that this is a software issue, maybe a Processing issue, but I am not sure.

I tried running the GUI on Ubuntu 14.04 but the dongle could not synch with board, even though it showed as an available port, there was no signals showing and the GUI could not get passed the control panel - but that is another issue.

Is there anything I can do to troubleshoot the GUI?

Thanks

wjcroft · February 2015

TFnano, thanks.

By using these '@' references Conor and Chip will get a notification of our comments here: @chipaudette and @conor_obci . They might have suggestions on your question of troubleshooting the GUI.

Since the GUI buttons are freezing up, it does sound like some kind of Processing related glitch.

Re: running on Ubuntu, have you seen this post,

http://openbci.com/forum/index.php?p=/discussion/224/openbci-gui-linux64-needs-jssc-jar-update

I believe it still would be helpful to see if this failure persists with another computer or OS.

William

TFNANO · March 2015

Hello @chipaudette @conor_obci,

Here is an update. I've tried running the experiment an another Windows 8 computer and on a Ubuntu 14 computer; it is still has the same issue even on these OS - signal montage freezes after 1.5 - 2 hours, the red light on the dongle goes off and no data is recorded. Sometimes the buttons freeze too, but when they are not frozen I am able to stop and start and the recording continues but only for another 15-20mins before everything freezes again.

It is very important that I find a solution to this glitch as soon as possible. Do you guys have any suggestions on how to resolve this?

Thanks.

TFNANO · March 2015

Could this be a bug related with the GUI? Maybe there needs to be memory clean up? I am not that familiar with Processing garbage collection, so how should I check if it's a memory issue with the visualization? Would throwing a System.gc() somewhere in draw() be useful and where should I place it?

wjcroft · March 2015

TFnano, thanks for those other tests you tried.

That does seem to eliminate the OS or laptop as cause. And the fact that you can sometimes stop/start the GUI for another 20 mins -- seems to eliminate the GUI / Processing as the culprit as well.

We assume you are checking your battery pack voltages periodically. With the 32 bit board you need to be above 3.3v for the regulator to function properly.

I'm wondering if Joel @biomurph might comment here. Regarding:

* has the OpenBCI team ever seen the board and GUI running continuously for 2+ hours, with no issues? As TFnano states, I think this would have to be a continuous run, and not one where there are manual starts / stops.

* is it possible that a component might heat up slightly over such a time period. (Like one of the RFduinos). And then something goes "out of spec", triggering the freeze? Could this be an isolated case of a certain board or dongle that would work ok, if replaced? The failure modes described in TF's previous posts do seem to point to some kind of warmup period as essential. Then once 'hot' the component will re-fail within a shorter interval (20 mins vs. 1.5 hours.)

Also mentioning @chipaudette again, if he has done any extended runs.

TF, why don't you send an email to [email protected] , and see if a board swap is something they would explore or recommend. Or any other suggested tests.

William

biomurph · March 2015

@tfnano have you tried to record the data to SD card?

It sounds like a software issue. Recording to SD card would test this.

TFNANO · April 2015

Hello,

Yes I have tried to save to SD card, but because the software stops acquiring it also stops saving to the SD card. Is that suppose to happen? Or should the board continue saving to SD even when the acquisition software stops running? Is there a away to force it to write to SD without an acquisition software?

We have also tried running the acquisition with the python scripts you guys have. And we are experiencing different issues with that (on both Windows 8 and Ubuntu 14) not related to long acquisition time. The python scripts issue is with the serial connection or bluetooth connection is not being maintained - we get an error "unexpected END_BYTE found.." and the red light is not consistently on after /start. Has anyone else experienced this issue and has it be resolved? So my group has not been able to record data properly with both the processing and python downloaded from the openbci git repos.

I have had success recording and viewing signals for 8+ hours with the OpenViBE platform. I used its acquisition server and designer to setup a acquisition client and signal display. This has been the best way so far to observe and record data for long periods of time (the processing software worked well but it crashed after 1 to 2 hours).

The openvibe acquisition server measures and tolerates a set amount of time (ms) of "device drift". As I understand it device drift is how much your system is lagging in its data transfer process. The acquisition server performs a correction to the signal if the drift exceeds a set amount. Is it possible that the python and processing acquisition software do not properly handle such drifts and cause it to either lose connection or crash after a period of time?

The only problem I have with openvibe is that the openbci drive (that is in openvibe) does not allow one to change channel settings or other command settings. Is there a way that I can change the default settings in the board? So that when I start the openvibe server and turn on the board it loads the default settings that I want.

wjcroft · April 2015

TFnano, thanks for that update, very useful.

I'm mentioning Jeremy @jfrey so he will comment on your Python and OpenViBE observations. Your ability to acquire long sessions with OpenViBE does indeed imply that there is some kind of glitch in the Processing environment. I'm wondering since that is Java based if there might be some sort of automatic garbage collection issues with the Java virtual machine; such that it runs for a couple hours, then some resource becomes exhausted. But perhaps with some kind of adjustment of those GC settings, that would be eliminated. Such as:

https://processing.org/discourse/beta/num_1202914234.html

Here is some info on the GC tuning options. Maybe @chipaudette has some comments on those.

I don't believe the OpenViBE drift adjustment has anything to do with the Processing hang. That adjustment just inserts or removes extra samples if OpenBCI is not generating exactly 250.00 samples per second.

William

biomurph · April 2015

@tfnano Thanks for the thorough description. It does seem like there is an issue with Processing during long recording runs.

We will be setting up here to do a verification. There is a way to 'manually' adjust the channel settings, by using the key commands from a serial terminal (key commands are explicated here).

Also, you can go into the library and 'hard-code' the settings that you want to use. That requires uploading to the board.

If the streamingData mode is exited, then the SD card will stop getting updated with data. The only way that the board will stop streaming data is to receive an 's' over the serial connection. Even if the board and Dongle loose connection. The streaming data is only one way. there is not a verification or 'ack' sent from the computer.

We will run tests on a Mac laptop, and we also have a Windows 7 machine here.

jfrey · April 2015

Hello,

As I developed the OpenVIBE driver and contributed to the python code, hopefully I'll be able answer some items.

1. 8h+ of recording with OpenViBE. Welll. that's a good info, didn't know it was so robust

There's two differences I see between OpenViBE implementation and pyhton.

a. the low-level code that deals with serial port communication. Either c++ implementation is more reliable than the python (and java?) counterpart... or we may have a positive side effect of some... ahem... not optimized code -- data is not cached, it's a one byte buffer that is used in OpenViBE (shush!)

b. I did experiment some disconnections in the past while I developed the driver. Overheat has been mentioned earlier, but it could also be due the radio link, ie noise in the environment or the board that get to far from the dongle. To counter that, I implemented and "emergency reconnection" feature. If no packets are received during XX ms (don't remember how much I put) then a new initialization sequence is sent (reset board, start streaming again). Seems to do the trick. I have yet to "backport" this feature to the python scripts. There is a message in the console that appears alongside the "emergency" call. Do you see any of those during your prolonged sessions? It could help us to spot the difference with python and java code.

* "unexpected END_BYTE found.." and python script: I'm not sure about this one. I'd say that it is related to the previous point. I'd have to check the implementations, but except for the verbosity I think it's roughly the same between python and OpenViBE, ie one or more bytes have been skipped during reading and python is complaining whereas openvibe tries to issue a new init sequence . Again could be low level / caching / radio link.

* Change channel settings or other command setting: yes you can! (and i'm very proud of this feature

). In the "driver properties" you have a field where you can enter custom commands -- the same as you would use with the python script, eg "1" to disable channel 1, x......X syntax to set bias and co.; see OpenBCI documentation. You could even see the board's responses in the console. Note however that if an "emergency" reconnection occurs those commands will be sent more quickly -- there is a "global timeout" in the acquisition server, if the driver does not output a thing after XX second it is deactivated by the acquisition server, so we have to send the new init sequence quickly.

* drift correction: as William said the drift correction does not relate in any way with the hang. In OpenViBE I hard-coded a 250 or 125Hz sample rate depending on the 8 or 16 channels configuration (could be changed through UI file though) and if the acquisition driver does not receive the right amount of packets it will interpolate (not enough packets) or it will skip some (received too much packets, and it seems to be the case, see the 250.5 Hz discussion elsewhere). The drift correction is optional, see the "preferences" button. Whether it is Processing, python or OpenBCI, all those codes loop on the reading of the serial port and fetch the rest of the programs as fast as possible, that's it. Except *maybe* if the processing that is done behind is very slow, then there could be some kind of jamming in the reading queue, but it's unlikely (could data be discarded if the serial port buffer is full?)

I hope I've been clear enough, if not don't hesitate to ask for clarification. Anyway, thanks again for the feedback, It's thrilling to witness such motivated users of Open(BCI+ViBE)

Gary · April 2015

Hi

I have a problem when I was using the OpenBCI GUI

When I was using the live mode I can correctly capture the signal; however sometimes the data stream would suddenly stop.

I need to click the "Stop Data Stream" button and the "Start button stream" button to continue signal capture.

Does anybody know why does it stop and is their any way to avoid it?

wjcroft · April 2015

@Gary , hi.

I merged your question into this existing thread. Initially it was thought that the freezes could be due to some issue within OpenBCI_GUI or Processing / Java environment. (Such as UI Garbage Collection algorithm.) But other platforms like Python, OpenViBE and BrainBay have also shown to exhibit this behavior. So that is tending to indicate that it is not the particular applications, but possibly something in the main board or RFduino firmwares / hardware. Take a look at some of the previous posts above and see if that coincides with what you have been seeing.

Can you say how long your live data stream operates before stopping? Is that time period consistent? When the stream stops, does the red light on the dongle continue to flicker somewhat? That has been seen by @TFNANO in his description above. The flickering red light is a sign that radio data is being received. However if the packet data stream is frozen in the application, then valid frames may be lacking at some point in the stream flow.

TFNANO also noticed a type of "warm up" effect. When it stopped for him initially at the 1.5 to 2 hour point, if restarted it would then stop again (but sooner), at 15-20 mins.

I'd also like to ask TFNANO if he has seen the message that Jeremy @jfrey mentioned above, when the freeze occurs: that is, a console message from OpenViBE that indicates an automatic board reset has occurred due to timeout.

Joel @biomurph has reproduced this behavior in the lab, and I believe is investigating. But last I heard it was taking a long running data stream of between 3 to 4 hours to trigger the freeze under Mac OS. I wonder if this could also be OS dependent, freezing sooner on Windows because the FTDI driver Latency Timer (if set to 1ms), is delivering packets at consistent 4 ms intervals.

William

Gary · April 2015

Hi

1. 32bit with Daisy module ( using 16 channels ) 4 AA batteries
2. Our Experiment is going to record EEG siganal 30min

3. Data stream would freeze(5-15 mirnutes after start record) and stop captuer signal, need to click the "Stop Data Stream" button and the "Start button stream" button to continue signal capture

4. Dont have warm up effect (only happened one time in the 30 min Experiment )

5. system: win7 64bit, memory 4GB

biomurph · April 2015

@Gary, This is unusual. We have not seen the data stream stop after 5-15 minutes. The problem that we are finding happens during longer data acquisition runs. Your 30 min recording should work ok.

Can you verify that you have the 32Bit board in close proximity to the Dongle?

Folks, thank you for your patience. We are super busy with all of the things, and developing an error checking system for investigating what exactly is happening when these dropouts occur. Will post here when we have something. Please let us know if you are having this problem.

TFNANO · April 2015

Thank you for your comments and support!

@jfrey, 1b) I have not observed any error messages that appear in the console during openvibe server, but I will pay attention to it more. I believe that this "emergency reconnection" feature is what allows the openvibe server to run longer without crashing. The END_BYTE error from the python scripts has to do with the serial connections, probably like you said bytes have been not read or handled properly. For the custom commands in driver properties, does it matter that they are resubmitted based on the delay between init commands? With the python scripts they submitted initially before the acquisition starts, but with the driver properties it looks like they are submitted repeatedly. (Or if I set the delay between init commands to 0 they won;t be resent? Also, how should multiple commands be separated; space, commas? Such as changing the settings of multiple channels?

@wjcroft, I have not experienced any heating issues with the board. We keep the board and the battery pack in a plastic housing. After 2 hours it freezes, so I cannot restart it at all. But I have noticed that after a long period of acquiring data (over an hour) there are issues with the data stream - such as acquiring in a "choppy" way and looking slower. I ran the processing code from the terminal to see if there are any error messages that show, and this is the only message "OpenBCI_ADS1299: apparent sampleIndex jump from Serial data: 70 to 72. Keeping packet. (211)" (with different numbers). What I noticed is: 1. when it is acquiring in a choppy/slow way that message appears, 2. when it is frozen after 2 hours, that message is constantly being thrown. Coming from here https://github.com/OpenBCI/OpenBCI_Processing/blob/master/OpenBCI_GUI/OpenBCI_ADS1299.pde#L511

jfrey · April 2015

Custom commands: they are sent as-is right after the init (or the "emergercy" re-init) sequence, and before the "b" that starts the stream. The delay is here in case some commands need few ms to be registered properly by the board (eg: the "x....X" sequence that configures a channel) or if they send back a verbose output (eg: "?"). If you put "0" as delay each letter will just be sent as fast as possible, which may not be a good idea. If you put commas or spaces, they will be also treated as commands and sent to the board, so don't use separators. You can test more easily beforehand the effect a long command (set a channel, asks for board state, set another channel. etc.) by using the python script ; the result should be the same. I have not tested a lot this feature, so if you see any improvements that could be made, don't hesitate to comment

henriqueandrade · July 2015

The OpenBCI signal, for no clear reason, peaks and then goes to zero. I'm using OpenVIBE to visualize it.

The only way to get it back to work is by resetting the dongle.

Did anyone experience this issue before?

wjcroft · July 2015

Henrique, hi.

I merged your post into this existing thread. When you say "goes to zero", do you mean the stream halts, or the stream still runs but produces all zeros?

OpenViBE OpenBCI acquisition driver has a "freeze detection" built in from Jeremy @jfrey . As far as we know this prevents any lockups. Have you tried that? You say you are using OpenViBE to visualize, but are you also acquiring directly from the acquisition server?

William

henriqueandrade · July 2015

Hey @wjcroft !

Thanks for replying.

It does not halt. As you said, stream produces all zero, but the signal display is running.

What do I need to do to use the 'freeze detection' feature? Isn't it default when running the OpenVIBE acquisition server? And yes, I am visualizing and acquiring the signal using OpenVIBE.

All the best,

Henrique.

jfrey · July 2015

Hello,

The "freeze detection" is there by default -- and in fact there is no option to disable it. I've never experienced recordings filled with 0 -- even noise produces signals. Maybe if there's nothing attached to the pins... Did you try other softwares (eg: Processing) to rule out issues with OpenViBE? Is there anything showing up in the console when you have zeros, like packets drop?

yj · October 2015

Hello ,

@TFNANO : do you still have this problem?

I have the same...

you wrote "Yes I have tried to save to SD card, but because the software stops acquiring it also stops saving to the SD card."

Have found some data on the SD card or nothing at all? (the file could be "not closed"...)

The PIC32 seems to write continously on the SD since the "sendchanneldata" function does not report errors... Look at the main loop code there under.

@Biomurph : Do you know what happens if we delete "OBCI.sendChannelData(sampleCounter);" ? SD card updated and no freezing?

(I could try but I am affraid to break every thing...)

Yannick.

void loop() {

if(is_running){

      while(!(OBCI.isDataAvailable())){}   // wait for DRDY pin...

      OBCI.updateChannelData(); // get the fresh ADS results
      if(OBCI.useAccel && OBCI.LIS3DH_DataAvailable()){
        OBCI.LIS3DH_updateAxisData();    // fresh axis data goes into the X Y Z
        addAccel = true;    // adds accel data to SD card if you like that kind of thing
      }
      if(SDfileOpen){
        writeDataToSDcard(sampleCounter); //
      }
      OBCI.sendChannelData(sampleCounter);
      sampleCounter++;
}

eventSerial();

}

biomurph · October 2015

@tfnano,

don't be afraid to break things!

If you comment out the line

OBCI.sendChannelData(sampleCounter);

it may cause a problem, because the Dongle and the Board expect to go into 'streamingData' mode.

In this case, it is best to make a more comprehensive edit to the code. So I just did that.

You can find the working 'write to SD only code here

https://github.com/OpenBCI/OpenBCI_32-write-to-DS-only

There is a brief description of how it works, but in a nutshell, you should go through the process of setting up the OpenBCI board as usual, but then send an 'N' to start the board, instead of sending a 'b'.

This code does all the stuff that the OpenBCI_32 code does, but the 'write to SD only' functionality is not yet implemented in our OpenBCI GUI. You will need to drive the system from a serial terminal.

Also, we have updated our 'how to program the OpenBCI 32' tutorial. Now you can do it through the Arduino IDE.

Tutorial for that can be found here:

http://docs.openbci.com/tutorials/02-Upload_Code_to_OpenBCI_Board#upload-code-to-openbci-board-32bit-upload-how-to

biomurph · October 2015

Oh, and by the way, while it is writing to the SD card, it has some serial verbosity every 256th block. Here's an example of the serial output on the arduino IDE terminal windodw

OpenBCI V3 16 channel

On Board ADS1299 Device ID: 0x3E

LIS3DH Device ID: 0xFF

$$$Wiring is correct and a card is present.

Corresponding SD file OBCI_24.TXT

$$$SD BLOCKS written: 37

SD BLOCKS written: 74

SD BLOCKS written: 111

SD BLOCKS written: 148

SD BLOCKS written: 185

SD BLOCKS written: 222

SD BLOCKS written: 259

SD BLOCKS written: 296

SD BLOCKS written: 333

SD BLOCKS written: 370

SD BLOCKS written: 407

SD BLOCKS written: 444

SD BLOCKS written: 481

Total Elapsed Time: 26964mS

Max write time: 305 uS

Min write time: 299 uS

Overruns: 0

In addition to the SD card commands that are listed on the SDK page, there is one more for testing.

send 'a' to write only 512 blocks (what I did for the test above)

yj · October 2015

Hello,

@biomurph, thank you for the "write to SD only" code.

I dared the upload, everything passed well, the card survived ...

I used the terminal supplied by Arduino in tools, "serial monitor" :
+?+ ; +v+ ; +a+ ; +N+ ; +j+ ; and so on ... It worked...

Just like you I got :
Max write time: 305 uS
Min write time: 299 uS
Overruns: 0

If I stop recording by +j+ , there is no footer in the sd file...
It is a little bit abrupt...

I tried a 4h recording.

Good news : No freezing...

But time to time "SD BLOCKS written: HHHHHH" was not always well written

for example :

?written: 1755
–KS written: 3661
written: 8836
BLOCKS written: 8926
Kitten: 11226
itten: 11801
@ written: 12376
BLOCKS written: 13708
written: 16582
ôOCKS written: 17067
CKS written: 22635
SÑten: 27507
¦S written: 29201
BLOCKS written: 31017
BLOCKS written: 31683
rwritten: 35011
...
...
The number of bad messages is big ,
much more than 50 (the number of overruns) since last line is 520992...
...
SD BLOCKS written: 520932
SD BLOCKS written: 520962
SD BLOCKS written: 520992

The footer signals
50 overruns ,
Max write time: 153518 uS

"Overrun" : what is it in fact ?
- a problem to write on the SD ? (it would be strange)
- a problem with the radio transmit ?
- some A/N conversion missed ?

I try to read the code to anderstand Which part of the code yields these "overruns"...

Have you any idea?

I also removed the verbosity :
//          if(SDsampleCounter == 0x00){
//            Serial0.print("SD BLOCKS written: ");
//            Serial0.println(blockCounter); // verbosity
//          }

For a one hour record, the end message on the terminal is :

OpenBCI V3 16 channel
On Board ADS1299 Device ID: 0x3E
LIS3DH Device ID: 0x33
$$$Wiring is correct and a card is present.
Corresponding SD file OBCI_06.TXT
$$$Total Elapsed Time: 4606304mS
Max write time: 84956 uS
Min write time: 299 uS
Overruns: 11
fileBlock,micros
8088,29771
24000,5926
40384,10811
56768,10664
73152,14604
89536,10518
97625,84956
97626,7540
114112,11847
122201,83998
122202,12203

There are still some overruns (but because of what???)
is there any kind of hidden dialog between the card and the PC?

50 overruns for 4 hours and messages, statisticaly it is the same that 11 overruns for 1 hour record without verbosity...

Should we use Interrupts by "/dryd" instead pooling (and a big buffer) for the data acquisition?
I have seen a post like that...

Here under the Footer and +?+ answer for the 4hours record. .

Thank you and sorry for my bad english,
Yannick.

Total Elapsed Time: 17689000mS
Max write time: 153518 uS
Min write time: 299 uS
Overruns: 50
fileBlock,micros
28864,16397
45248,4973
61632,12590
78016,9007
94400,16170
110784,5145
127168,12166
143552,5323
157697,147812
157698,107986
157699,3686
176320,15323
192704,8980
206849,153203
206850,120451
225472,11227
241856,9252
256001,153518
256002,120363
274624,20500

+?+ gives :

Board ADS Registers
ADS_ID, 0x00, 0x3E, 0, 0, 1, 1, 1, 1, 1, 0
CONFIG1, 0x01, 0x96, 1, 0, 0, 1, 0, 1, 1, 0
CONFIG2, 0x02, 0xC0, 1, 1, 0, 0, 0, 0, 0, 0
CONFIG3, 0x03, 0xEC, 1, 1, 1, 0, 1, 1, 0, 0
LOFF, 0x04, 0x02, 0, 0, 0, 0, 0, 0, 1, 0
CH1SET, 0x05, 0x68, 0, 1, 1, 0, 1, 0, 0, 0
CH2SET, 0x06, 0x68, 0, 1, 1, 0, 1, 0, 0, 0
CH3SET, 0x07, 0x68, 0, 1, 1, 0, 1, 0, 0, 0
CH4SET, 0x08, 0x68, 0, 1, 1, 0, 1, 0, 0, 0
CH5SET, 0x09, 0x68, 0, 1, 1, 0, 1, 0, 0, 0
CH6SET, 0x0A, 0x68, 0, 1, 1, 0, 1, 0, 0, 0
CH7SET, 0x0B, 0x68, 0, 1, 1, 0, 1, 0, 0, 0
CH8SET, 0x0C, 0x68, 0, 1, 1, 0, 1, 0, 0, 0
BIAS_SENSP, 0x0D, 0xFF, 1, 1, 1, 1, 1, 1, 1, 1
BIAS_SENSN, 0x0E, 0xFF, 1, 1, 1, 1, 1, 1, 1, 1
LOFF_SENSP, 0x0F, 0x00, 0, 0, 0, 0, 0, 0, 0, 0
LOFF_SENSN, 0x10, 0x00, 0, 0, 0, 0, 0, 0, 0, 0
LOFF_FLIP, 0x11, 0x00, 0, 0, 0, 0, 0, 0, 0, 0
LOFF_STATP, 0x12, 0x00, 0, 0, 0, 0, 0, 0, 0, 0
LOFF_STATN, 0x13, 0x00, 0, 0, 0, 0, 0, 0, 0, 0
GPIO, 0x14, 0x0F, 0, 0, 0, 0, 1, 1, 1, 1
MISC1, 0x15, 0x00, 0, 0, 0, 0, 0, 0, 0, 0
MISC2, 0x16, 0x00, 0, 0, 0, 0, 0, 0, 0, 0
CONFIG4, 0x17, 0x00, 0, 0, 0, 0, 0, 0, 0, 0

LIS3DH Registers
0x07    FF
0x08    0
0x09    0
0x0A    0
0x0B    0
0x0C    0
0x0D    0
0x0E    0
0x0F    33

0x1F    0
0x20    8
0x21    0
0x22    0
0x23    18
0x24    0
0x25    0
0x26    0
0x27    0
0x28    0
0x29    0
0x2A    0
0x2B    0
0x2C    0
0x2D    20
0x2E    0
0x2F    20
0x30    0
0x31    0
0x32    0
0x33    0

0x38    0
0x39    0
0x3A    0
0x3B    0
0x3C    0
0x3D    0
$$$

biomurph · October 2015

First of all, when you are controlling the OpenBCI board with a serial terminal, you don't need to add the '+' characters to your commands. Those get added to your single 'v' or 'N' by the Dongle radio. Also, you can start the writeToSDonly functionality by sending an 'N', and stop the writing by sending a 's', if you like. That will add a note in the SD file to mark the stop time, if you want to start again, there will be another timestamp on the file.

The overruns are SD card writes that take longer than 2000 microseconds.

The footer of the file is reporting which block they happen in, and the length of time it took to do the write.

so for example, the report you sent says that block 28864 took 16397 microseconds to write. I guess the good news is that it ran well without hiccups for 28864 blocks! The bad news is that the card writing is not consistent over your desired record time.

What kind of card are you using? you may need to reformat and 'wipe' it by using software to write zeros to all the file locations.

yj · October 2015

Thank you @Biomurph, I feel a bit stupid with my +x+...
and yes , I should have used 's' instead 'j'... Sorry...

I bought a 16Gb card from Transcend ( TS16GUSDHC10 ) Class 10 , 30MB/s, 200x.
How fast are the ones shown at http://docs.openbci.com/tutorials/08-SD_Card ?

To format the card I used as you recommend, SDFormatter.exe
   Format type    : Full Overwrite
   Format size adjustment       : ON

Do we know why the writing time varies so much ?

Thank you very much,
    Yannick.

biomurph · October 2015

This is a good question. I don't know why the writing slows down so much. I think it is important to get the highest quality card that you can in order for it to work well. The Arduino SD card library is notoriously known as a rat's nest of spaghetti. We clock the SD card at 20MHz. It is possible to slow this down a bit, if you think it might help.

yj · October 2015

     @biomurph,

20mHz would induce mistakes? Would they be reported by the soft? Probably , else they retry...

Compared to the 30MBytes/S of a "slow" card the 20/8 MBytes/S of the bus is very slow .
To send the 512octes or 4096 bits , the bus , even slow, needs around 4096/20uS = 0.21mS, it is short...

If something takes so much time it is probably/certainly not due to the bus speed or the average card speed but to some mysterious process inside the card.
These process are not frequent but can require up to hundreds of milli seconds may be even with the fastest cards.
In the file Sd2Card.h I found that SD_WRITE_TIMEOUT=600mS ! ! ! (At 250samples/S, we have less than 4mS to write a block...)

To get the highest quality card is better of coarse but I am not sure that it can solve this overrun problem which is mainly due to the fact that two time dependent chips, the ADS1299 and the SD Card, share the same resource , the SPI Bus...
Without time sharing on the SPI, the collisions are inevitable.

It is only a personal theory, I am not an expert on the subject ...

   What's your feeling?

   Yannick.

data stream freezes during long sessions

Comments