Issue when streaming Ganglion + BLED112 Dongle + USB C + Mac

[TenTennyson]

Problem

Slow data showing in GUI v5.1.0 on macOS

Expected

Data will resume normal expectancy that is showed in Windows

Operating System and Version

macOS Big Sur Version 11.6 MacBook Pro (13-inch, M1, 2020) Chip Apple M1 Memory 8GB

GUI Version

GUI v5.1.0

Running standalone app

Running the downloaded app

Type of OpenBCI Board

Ganglion

Are you using a WiFi Shield?

No

Console Log

[retiutut]

Works on this Mac

[retiutut]

Does not work on this Mac

[retiutut]

Does work on this Mac

[retiutut]

https://github.com/brainflow-dev/brainflow/issues/568

[retiutut]

This issue occurs when plugging in the BLED112 Dongle (USB Type A) into a USB C Hub or a USB Type C to Type A converter. We see a slower sampling rate which ranges from 82Hz (worst case) to 195Hz (best case). The desired sampling rate is 200Hz. An issue has been logged at the BrainFlow level to see if we can go back to using the built-in bluetooth on Macs. This was possible with the now-deprecate OpenBCI Hub (GUI v4 and NodeJS). But now, Apple silicon exists and we have the BrainFlow backend. This issue has been fully investigated with quite a few USB C adapters and hubs and we believe this is the path forward to resolve this for Mac users.

[wjcroft]

Another perspective on the assumption that this is caused by ‘bad’ USB-C to USB-A adapters.

Instead, the slight USB system timing differences induced by these adapters, may be aggravating a BLED112 protocol / timing bug. And could be solved by refactoring how the BLED serial port interfaces is being interacted with. As you might know, I believe AJ Keller wrote the first version of this BLED code for the original ‘Hub’ implementation. I believe that code was then adapted by Andrey to offer BLED interface in Brainflow. But likely with minimal BLED serial protocol mods.

The BLED serial port protocol is quite complex and likely AJ just lucked out in the original implementation that more timing variances were not present in the earlier generations of USB.

Some monitoring and analysis of the USB serial port commands / responses with the BLED, may turn up the source of these glitches.

https://www.google.com/search?q=mac+usb+serial+port+sniffer

[wjcroft]

I have not looked at AJ’s BLED packet receive code, but the situation may be as simple as this: Inside the BLED112, available packets are added to the tail of a delivery queue as they are received. When the Mac code polls for an available packet, it may only ask for one and assume that is all that will ever be available. If timing is such that more than one packet is available, but not asked for — then they will pile up inside the BLED112 delivery queue.

[mgroth0]

Thanks @wjcroft for pursuing this issue. I'm following up from our thread

I as a user would benefit so greatly from this fix. I'm working on a research project on an M1 mac with a Ganglion.

I can easily reproduce different input frequencies. If I use one USB-C to USB-A adapter I get a frequency in the 80s. If I use another adapter I get 190-200. I have already shown this to Andrey and people at OpenBCI are aware of which adapter I used to get the good sample rate.

I currently can not get a reliable 200Hz. Whether I get 190 or 200 for now is all about luck as I have not yet identified what makes the difference.

Please let me know if I can help with testing or anything.

Out of curiosity, what competencies would be required for one such as myself to try to implement a fix for this? Given that I'm not even all that comfortable with C++ (I'm a java/kotlin/python person) I'm guessing it wouldn't be too realistic for me, or would it? I do currently have a fork of BrainFlow and know how to build it (even the native parts), but I don't know if that brings me anywhere close to being able to tackle an issue like this.

[wjcroft]

Mentioning @Andrey1994 and @retiutut. I believe that Andrey is contacting engineering support at the BLED manufacturer (Silicon Labs), to see if they have any suggestions in terms of timing adjustments. Or if other customers have reported these USB-C issues. This is certainly an issue with the BLED timing, aggravated by the USB-C connection.

Here is a comment made by Andrey last week on an internal Slack thread:

Andrey 7 days ago I mentioned that there are some variables responsible for timing, here is a PR which did the trick for all OSes when I was working on it https://github.com/brainflow-dev/brainflow/pull/57/files . Maybe by adding extra adapters they can be tuned further but I doubt in it. Regarding how packets are received and processed, I dont call read from bglib(its slow and leads to lost packets) instead it's done by notifications and such notifications should be triggered automatically. Maybe there are some com port properties\ioctl calls\libusb calls which will help but I am not aware of them and have no hardware to try.

[Andrey1994]

I believe it will solve the issue partially https://github.com/brainflow-dev/brainflow/pull/574

[mgroth0]

If it is any help, I am doing SSVEP stimulation and seeing peaks at the power spectrum that are slightly less Hz than expected.

I stimulate at 12Hz, and the total number of samples I get over the course of about 1 or 2 minutes averages is about 190Hz. The peak in the power spectrum for SSVEP is around 11.8 Hz or something. This is a reliable result. To me this suggests that buffer is gradually accumulating values over the course of a minute or two, but they all seem to make it through eventually. So rather than loosing data, I'm getting a slow-motion view of it. If samples were actually lost during the recording and the data I received eventually caught-up to the present, I would still expect a peak at exactly 12Hz despite the less-dense signal.

Maybe if I recorded for longer than 2 minutes the samples would start getting lost since we don't think there can be an infinite buffer.

[wjcroft]

Matt, as I mentioned on the Forum thread, you cannot infer your sample rate from the 190 Hz rate the USB-C port is providing you. Your sample rate is very close to 200 Hz, regardless of how much delay is imposed by the usb pipeline. The sample rate stays constant at 200.x Hz, as the 'delay' to receive the samples creeps up continuously (10 samples per second).

https://openbci.com/forum/index.php?p=/discussion/comment/18435/#Comment_18435

Yes, it certainly looks like the buffer in the BLED112 is accumulating these delayed samples. @Andrey1994 informed me that each sample should be accompanied by a BLE 'notification'. But if these notifications happen to be occasionally lost, then the sample will not be collected immediately, but instead will pile up in the buffer, to be eventually collected after some growing delay factor.

[mgroth0]

You're right, you did explain this and apologies for not understanding it correctly the first time.

This of course means we are saying that no matter how much of a traffic jam there is at the port, the ganglion will never slow down its readings. And if this is true, then logically what I said above about a slow-motion view doesn't make sense since in my calculations I assume 200Hz and do no resampling.

I can imagine lag in some of my stimulus presentation methods possibly causing the flicker to be slightly less than what I programmed.

[wjcroft]

If you are delivering the stimulation via a monitor flashing pattern, there has been much written about how to be sure this is calibrated correctly. In particular the links I gave to the MindAffect calibration tools.

[retiutut]

Hey everyone! We have a great solution coming down the pipe with native BLE access for Ganglion and Mac!

[retiutut]

The fix for this issue has been merged into the development branch! The next release of the GUI will support connecting to Ganglion using built-in bluetooth! Thank you everyone for your patience and assistance with this issue. Shoutout to @Andrey1994 for implementing SimpleBLE on the BrainFlow side.