16ch Daisy v1 firmware -- Missed packets?

RPSpicerRPSpicer Los Angeles, CA
in Cyton
I'm doing some work with the 16 ch 32-bit OpenBCI running (I think) V1 firmware -- I haven't reflashed; I'm just running whatever shipped on the 32-bit + daisy setup as of a couple of months ago. Most of the time everything works fine, but sometimes the system will get into a state where the packet counts are not consistent and the data is junky. The only way to get it back is to fully restart the OpenBCI board, which takes several seconds because I have to resend all the channel setup info, etc (since I'm running EEG + EMG). Any ideas what I should check to minimize the frequency with which this happens?

Comments

  • wjcroftwjcroft Mount Shasta, CA
    RP, hi.

    Mentioning AJ Keller @pushtheworld. My understanding is that the V2 firmware solves most (more likely all) of these issues.

    With the V1 firmware it's noted in several other threads on the forum here, that long sessions (thru the dongle) are problematic in terms of freezing up or glitching. V1 firmware does allow long SD card recordings.

    http://openbci.com/forum/index.php?p=/discussion/595/data-stream-freezes-after-some-minutes-of-use

    http://openbci.com/forum/index.php?p=/discussion/324/data-stream-freezes-during-long-sessions

    William

  • pushtheworldpushtheworld
    the packet counts are not consistent and the data is junky

    Could you please elaborate more? 

    Perhaps these questions can jolt some direction into a solution:
    Are packets are dropped? 
    The device continues to stream? 
    Is there any correlation to the occurrence of this "freeze" event with heavy CPU usage? 
    Is there any change in distance from the computer when the event starts?
    What driver are you using? 
    Are you able to stop streaming and start again once in the state?


  • RPSpicerRPSpicer Los Angeles, CA
    Thanks William and PushTheWorld. 

    We are not using the SD card  and do not have a SD card inserted into our 32-bit board -- we are only streaming to the dongle.

    Good to hear that V2 firmware appears to resolve many of the issues. How different is the control protocol? I would like to adopt V2 if it's where the OpenBCI organization is going, and if it isn't too hard to port the PC side to. 

    > Are packets are dropped? 

    Looks like it -- either packets are dropped or the device starts sending packets with completely meaningless packet IDs. My understanding of the protocol spec is that the packet ID (0-255) should monotonically increase until it wraps around to 0 at 255. My code flags a potential error state if the packet ID does not monotonically increase, and I'm seeing that + noise.

    > The device continues to stream? 

    Yes -- or at least it emits packets.

    > Is there any correlation to the occurrence of this "freeze" event with heavy CPU usage? 

    Not that I've noticed.

    > Is there any change in distance from the computer when the event starts?

    No. In my use case the dongle is connected to a laptop's USB port and the participant wearing the OpenBCI cap is seated in front of the laptop. They remain seated throughout, so distance changes maybe +/- 10cm. 

    > What driver are you using? 

    I rolled my own C# port of the V1 Processing UI. I've tried to iron out some of the weird update()-loop driven weirdness, but it still has a lot in common.

    > Are you able to stop streaming and start again once in the state?

    Unclear -- I've had poor luck with starting and stopping streaming in general, so my "recover from an error" procedure has been to power-cycle everything. I'll try it though, if I can recreate the error in the lab.
  • wjcroftwjcroft Mount Shasta, CA
    The V1 firmware had (I think) several modes of failure on long sessions. In one mode that I have seen with BrainBay, the packets kept coming in, but as you say were not monotonically increasing the packet counter. In BrainBay this then resulted in an on screen (Packet Sync Error) counter increasing continuously. In other words, 250 times per second.

    Other failure modes just froze up completely. And required powering the mainboard down and up again. Some failures required also removing and reinserting the dongle as well. So hopefully V2 firmware solves all of this.

  • RPSpicerRPSpicer Los Angeles, CA
    Ok, thank you! Will upgrade and see if I can recreate the issue! Unfortunately it seems to be the sort of thing that happens mostly in live use with participants, not on my test bench (I don't love wearing our cap for 40+ minutes if I don't have to, ha). Will give it a go and report back!

    Also looks like the V2 firmware solves some things that made my life less pleasant, like the required delay between sending successive commands (which made restarting streaming take a long time, since I set up all 16 channels).
  • pushtheworldpushtheworld
    I set up all 16 channels

    @RPSpicer send it all in one chunk now!!!! I always forget about this new feature haha, i need to implement this in the NodeJS driver ASAP.
  • likeoolikeoo America
    HMMM. Sorry , I am not quite sure about it
Sign In or Register to comment.

© Vanilla Keystone Theme 2026