Main Problem

Hi wjcroft , thanks. My problem was like in poddubny message : 80% of seconds contain 240/241 samples, and others are narrow distributed, up to 370 samples per second.  I have changed OS latency setti

However, by editing the LatencyTimer in the FTDI settings in the Registry Editor, everything seems to be working! LabVIEW and the GUI!

http://openbci.com/forum/index.php?p=/discussion/199/latencytimer-inbuffersize-for-os-x-new-info-plist

was only updating roughly twice per second. The LatencyTimer was 16ms. Changing to 1ms smoothed out the GUI and I assume would have also helped with my timing issue using the Python timers. Of course

Can you please confirm that you have set the LatencyTimer? Without that adjustment, the serial link is indeed bursty. And shows as such on the GUI.

Have you configured the LatencyTimer as suggested?

http://openbci.com/forum/index.php?p=/search&Search=LatencyTimer

http://openbci.com/forum/index.php?p=/discussion/199/latencytimer-inbuffersize-for-os-x-new-info-plist

http://openbci.com/forum/index.php?p=/discussion/199/latencytimer-inbuffersize-for-os-x-new-info-plist#latest

It's remotely possible that FTDI could eventually fix the LatencyTimer bug under Yosemite / Mavericks, if we keep bugging them. The early release we got in March apparently missed their development wi

It tuns out that setting the LatencyTimer option does not change anything, but changing the buffer read size does.

The new driver does not have a specified LatencyTimer configuration for the FT X Series and so, as expected, out of the box the latency persists. 

Both Mac and Windows are using the FTDI VCP virtual com port, (usb serial port emulation driver.)  For the related setting on Windows see this post.