Weird 60Hz burst on some Ultracortex electrodes only

drivasdrivas Montreal CA
edited May 2019 in Headware
Hi, maybe some of you with more experience could help me identify the source of this strange artifact that appears from time to time (office settings)

image

In particular, I am looking for a explanation as to why the frontal electrodes seem to be almost unnaffected whereas the occipital ones are always the noisiest, not matter how much I readjust the Ultracortex on my head. Any leads? could it It be a huge equipment turning on? but why some electrodes only?


Thanks!

Comments

  • wjcroftwjcroft Mount Shasta, CA
    Daniel, hi.

    Have you used the 'ohm' symbol on each electrode (near the colored buttons), to check the impedance per electrode?

    Electrodes with high / higher skin impedance are more likely to be affected by noise issues. Your occipital electrodes might be worn or not contacting well.

    Regards,

    William
  • wjcroftwjcroft Mount Shasta, CA
    "but why some electrodes only?"

    In the FFT I see MOST of your electrodes see this burst, 6 channels. Only two are not affected. In terms of skin surface contact the Fp1 and Fp2 electrodes use a cone with more surface area on bare skin. Thus likely have lower impedance.

    Have you tried this experiment in other areas, with other computers, etc.? Are you near any AC/DC power supplies, AC extension cords, conduits (under floor, in walls, ceiling).
  • drivasdrivas Montreal CA
    Interesting, I did not know the impedance difference could have such an effect. Indeed, impedance checks reveal that O1 and O2 have the worst impedance at around 8000 Ohms. Would I be correct in saying that having different ranges of impedances among elctrodes is the source of the bad signal to noise ratio, and that rather than looking for the lowest impedance I should strive for consistency among the sensors?
  • wjcroftwjcroft Mount Shasta, CA
    Daniel, hi.

    No, lower is always better. The other electrodes don't see the skin impedance of their neighboring electrodes.

    Regards,
  • drivasdrivas Montreal CA
    Ok got it, thank you! do you have a recommendation of an acceptable impedance range ?
  • Hi @drivas, are you using the WiFi Shield or RF dongle?
  • wjcroftwjcroft Mount Shasta, CA
    Well, the standard in the academic paper field (up until recently) has been 5K or less. However current EEG amps have very high input impedances. For example, the ADS1299 in the Cyton is 1 gigaohm. For implications of that, see,


    In other words, with modern amps, skin impedance can actually be higher. But signal quality may be dependent on noise in your environment. This seems to be the case in the images you've shown. So lower impedance might help your issues.

    Particularly with the type of mains noise (60 Hz) you are seeing, consider using some EMF meters to localize the source of that, and position yourself away from the source. Conduits, power supplies, extension cords, ceiling light fixtures, all can be sources.
  • drivasdrivas Montreal CA
    Hi @alwayswearshats, I am using the RF dongle, but we will be changing that for the WiFi shield soon due to sampling rate necessities.

    @wjcroft thank you so much for providing a reference. I think less than 5kohms is achievable but it takes a lot of fiddling around, especially for the occipital electrodes.

    My current office development environment is indeed high interference, but there is little we can do about that right now. In particular, I have found another kind of noise, this time translating into actual jumbling of the packet order as recorded by the latest GUI v4.1.2. Here is an excerpt from a recent data acquisition:

    0, -207.87, 6161.57, -61935.23, -34603.83, -57732.39, -53142.77, -82841.66, -51829.54, 0.000, 0.000, 0.000, 12:05:10.031, 1559232310031
    1, -157.16, 6233.59, -61914.38, -34625.00, -57703.04, -53138.10, -82822.62, -51785.61, -0.102, 0.892, 0.470, 12:05:10.034, 1559232310034
    2, -252.89, 6097.87, -61930.45, -34676.61, -57767.43, -53164.09, -82834.80, -51804.91, 0.000, 0.000, 0.000, 12:05:10.038, 1559232310038
    3, -293.77, 6045.45, -61931.09, -34662.70, -57782.14, -53166.62, -82841.95, -51821.45, 0.000, 0.000, 0.000, 12:05:10.042, 1559232310042
    25, -80.18, 6290.03, -61848.50, -34525.84, -57648.81, -53171.42, -82819.85, -51694.87, 0.000, 0.000, 0.000, 12:05:10.065, 1559232310065
    23, -164.60, 6172.34, -61872.35, -34611.12, -57715.76, -53200.55, -82817.21, -51731.50, 0.000, 0.000, 0.000, 12:05:10.096, 1559232310096
    6, -183.95, 6182.85, -61914.89, -34674.30, -57734.75, -53165.05, -82804.65, -51769.93, 0.000, 0.000, 0.000, 12:05:10.100, 1559232310100
    7, -255.23, 6088.55, -61923.74, -34709.46, -57766.05, -53178.00, -82826.76, -51812.59, 0.000, 0.000, 0.000, 12:05:10.103, 1559232310103
    21, -95.82, 6287.55, -61854.07, -34566.61, -57670.74, -53186.13, -82808.61, -51745.83, -0.072, 0.840, 0.464, 12:05:10.107, 1559232310107
    9, -75.86, 6340.77, -61873.72, -34608.52, -57654.76, -53157.45, -82828.92, -51864.90, 0.000, 0.000, 0.000, 12:05:10.110, 1559232310110
    19, -211.87, 6122.32, -61871.39, -34659.08, -57751.27, -53208.64, -82797.99, -51777.19, 0.000, 0.000, 0.000, 12:05:10.114, 1559232310114
    11, -215.11, 6106.85, -61892.85, -34661.90, -57748.90, -53180.03, -82815.09, -51853.56, -0.080, 0.828, 0.458, 12:05:10.121, 1559232310121
    17, -90.08, 6310.03, -61843.86, -34591.63, -57669.93, -53182.53, -82796.94, -51744.13, 0.000, 0.000, 0.000, 12:05:10.124, 1559232310124
    13, -65.58, 6337.68, -61845.17, -34593.32, -57651.16, -53159.51, -82788.24, -51753.52, 0.000, 0.000, 0.000, 12:05:10.128, 1559232310128
    14, -95.60, 6281.51, -61850.89, -34633.38, -57690.50, -53174.71, -82777.70, -51751.71, 0.000, 0.000, 0.000, 12:05:10.131, 1559232310131
    15, -222.22, 6108.64, -61872.24, -34680.77, -57762.25, -53197.06, -82798.10, -51771.29, 0.000, 0.000, 0.000, 12:05:10.135, 1559232310135
    26, -24.65, 6372.79, -61848.71, -34511.85, -57620.31, -53170.48, -82813.77, -51677.93, 0.000, 0.000, 0.000, 12:05:10.138, 1559232310138
    27, -118.62, 6238.68, -61885.25, -34565.79, -57685.36, -53196.08, -82827.27, -51707.43, 0.000, 0.000, 0.000, 12:05:10.141, 1559232310141
    28, -176.82, 6155.56, -61909.39, -34564.87, -57713.07, -53205.24, -82842.76, -51734.36, 0.000, 0.000, 0.000, 12:05:10.144, 1559232310144
    53, -111.36, 6229.99, -61834.55, -34505.26, -57638.42, -53166.06, -82851.32, -53404.46, 0.000, 0.000, 0.000, 12:05:10.148, 1559232310148
    35, -42.69, 6323.11, -61854.20, -34571.00, -57631.76, -53185.86, -82825.91, -51967.60, 0.000, 0.000, 0.000, 12:05:10.163, 1559232310163
    31, -62.41, 6286.92, -61871.53, -34509.06, -57640.92, -53172.00, -82807.00, -51768.29, -0.082, 0.894, 0.468, 12:05:10.167, 1559232310167
    32, -143.92, 6172.86, -61890.35, -34535.37, -57678.99, -53182.44, -82831.67, -51834.68, 0.000, 0.000, 0.000, 12:05:10.171, 1559232310171


    Could these events be due to a large number of Bluetooth devices ? They seem to appear as very short-lived pulses across all electrodes during live viewing through the GUI. 
  • wjcroftwjcroft Mount Shasta, CA
    Mentioning @retiutut.Very interesting. Is this just a recent phenomena? What changed?
  • drivasdrivas Montreal CA
    I probably should make a different post just about that issue, but these are not recent phenomena, I have been noticing some "scrambling" of a few samples here and there for the past few months (Cyton with firmware 3.1.1). In this 8 min recording, about 2.5% of samples were out-of-place or missing. I had never tought that interference in the bluetooth range could change the order of the packets, though a quick check on my phone show 18 discoverable devices at any time
  • wjcroftwjcroft Mount Shasta, CA
    It's possible the RFduinos do some kind of retransmission in noisy environments. Can you try a test at home with your laptop?
  • drivasdrivas Montreal CA
    Hum interesting, the retransmission would explain the scrambling. Is there a way to see which Bluetooth channels are less prone to noise?

    I will try running tests in a cleaner environment, should I keep you updated on this thread or on a github issue? Also, would the move to the WiFi shield eliminate this kind of problem?

    thanks
  • wjcroftwjcroft Mount Shasta, CA
    As I understand it, normal Bluetooth operation 'skips' around constantly to the various radio channels that are available. Conversely, the customized 'Gazelle' protocol that RFDigital created for OpenBCI, just uses a single channel, that the user can set, so as to avoid other Cytons. I'm not sure changing the channel would avoid the other Bluetooth devices in your area. But go ahead and experiment.

    Here's one thing that you COULD do. Get a usb 'extension' cable, with male on one end and female on the other. Position the dongle as close to the Cyton as you can. That way the signal strength should be at maximum. You might try running your recording session in that environment to see if you find any difference.

  • wjcroftwjcroft Mount Shasta, CA
    I forgot to mention, there are several Android apps available for phones, that can show you graphically which wifi channels are most heavily in use in your area. The apps are typically used to find less used wifi channels to move your router to. There is a mapping somewhere of how wifi channels map to Bluetooth channels. Using the map and graph, you might better guess which Bluetooth channels are less likely to interfere with wifi, and potentially less likely to interfere with other Bluetooths.


    DARPA is supposedly exploring how to use AI to avoid channel interference. Umm, this is years off and next generation Bluetooth.

    https://spectrum.ieee.org/telecom/wireless/if-darpa-has-its-way-ai-will-rule-the-wireless-spectrum

    The bottom line is that wifi uses fixed channels and had the 2.4 GHz space to itself for awhile (apart from microwave ovens). Then Bluetooth came along and tried to coexist in the same space. This is why they had to resort to channel hopping to avoid Wifi channels. Cyton uses a fixed channel to gain maximum bandwidth and latency. The channel hopping causes delays and slowdowns.
Sign In or Register to comment.