Mac OS 10.11.6, choppy data stream flow

ali1632ali1632 barcelona
edited August 2017 in OpenBCI_GUI
I'm hoping someone has seen this before. 

I built my own Mark III for use with the Cyton board, and I had it up and running with OpenBCI_GUI for over a week, with consistent results. But now when I connect it, the stream is choppy, with the bit rate (bps displayed in the app header) dropping to zero for about half of each second. The time plot stops and starts with each drop, so the plot looks consistent, but doesn't advance when the stream drops out. (So, there are no visual gaps in the line.) I was initially getting good results at 60fps, but no longer. At 30fps, it "looks" a little less jumpy but I can see the signal still dropping out - it's just spreading the data out over each cycle a bit more smoothly.

A friend of mine suggested that this could be a synchronization issue with the USB port or the radio...(???) I am a beginner with such things and don't know how to troubleshoot this. 

I'm using mac OS 10.11.6 on a 2016 macbook pro, with v2.2.1 of OpenBCI_GUI, and the latest FTDI drivers for 64bit mac os. 

We tried installing on another mac (10.12) and had the same result. We also tried manually changing the channel settings. No change. 

Also, the v2.2.1 download still displays version 1(1) inside the app's "about" detail. 

Thanks to anyone who can lend some help. 
-Alicia


Comments

  • ali1632ali1632 barcelona
    An update after analyzing the data output a bit more: 

    Based on looking at timestamps in a pivot table, I am getting up to 5-7 packets per millisecond, when I'm getting them. But large gaps appear of about 460ms in length, with roughly 21ms of good data in between, which drops the average to only about 240 packets received per second. If the ideal capability is 7000/sec, then I'm getting less than 3.5% throughput. 

    I have tried to use the OpenBCI_Radio_Configuration_Utility to toggle the baud rate and see if that helps, but every time I successfully change this setting, the dongle becomes unresponsive until I reset it, and it leaves a ghost device in my USB tree. So resetting obv. trashes the updated baud rate... and I can't get anywhere with that. 

    So what can I troubleshoot to figure out an almost 97% packet loss? 
  • ali1632ali1632 barcelona
    And a short screen capture of the "jumpy" data and finicky usb connection. 
  • wjcroftwjcroft Mount Shasta, CA
    Alicia, hi.

    Have you seen this page?


    William

  • ali1632ali1632 barcelona
    edited August 2017
    Hi, William, @wjcroft ;
    Yes, I had seen it back when I set the system up. Thank you for the reminder. But.... I have driver v2.4.2 (May 2017), and this doc's last update is Dec 2016. The 2.3 described here is no longer the one recommended for OS 10.11..... I figured since it worked at first it wasn't relevant to 2.4.2. 

    It worked like a dream every day for over a week. Then this issue was intermittent for one session, then has persisted ever since.

    Worth a shot, I can always revert. Thank you again for the link. :)
  • wjcroftwjcroft Mount Shasta, CA
    The older driver is apparently needed for this buffering trick to work. Ideally FTDI would provide a way to modify the buffering more easily, like it does with the Windows driver. But until that time, this workaround is what solved the issue for many others.

  • ali1632ali1632 barcelona
    Thank you!!!!!!
    This fixed it, at first glance. I will run another analysis on the timestamps but the stream is no longer jumpy and the bps rate is not bottoming out as far as I can see.
    I think I am back on track, thank you again. :)
Sign In or Register to comment.